SCP Principles

SCP Types

SCPs are classified as either system-defined policies or custom policies, depending on who creates them.

• System-defined policies

Huawei Cloud has preset a system-defined policy named FullAccess for organizations. The organization administrator can directly use the system-defined policy when attaching SCPs to OUs or accounts. Such policies cannot be modified. For details about available system-defined SCPs, see System-defined SCPs.

• Custom policies

If the system-defined policy cannot meet your authorization requirements, you can use the management account to create and modify custom policies based on the actions supported by each service. Custom policies extend and supplement system-defined policies. You can create custom policies for Organizations in a policy editor or JSON view. For details, see Creating an SCP and Modifying or Deleting an SCP.

SCP Effects on Permissions

• Allow rules

  If you want to allow a service action at the member account level, you must allow that action at every level between the member account and the root OU of your organization. Specifically, you must attach SCPs that allow the given action to every level from the root OU to the member account.

  Therefore, when SCPs are enabled for an organization, the FullAccess policy is attached to all OUs and accounts by default. This policy allows all operations and grants all cloud service permissions. If the default policy is deleted from any level and no alternative policy is configured, all OUs and member accounts under that level are denied access to all cloud resources.

  As shown in Figure 1, to allow a specific member account to use a cloud service, the SCP that allows the required actions must be attached to the root OU, all intermediate OUs, and the target member account.

  Figure 1 SCP attached at all three levels
  

  SCPs follow the principle of default deny. Any action not explicitly allowed by SCPs at every level is automatically denied. If the required permission is missing from the root OU, lower-level OUs, or the target account, the action will fail.

• Deny rules

  In the path from the root OU to the target member account, a deny rule configured at any level results in the action being denied.

  As shown in Figure 2, if an OU has a policy that denies actions on a cloud service, all member accounts under that OU are prohibited from using the service. This applies even if the root OU and the target member accounts have SCPs that allow those operations. A deny rule configured at a higher level applies to all lower-level OUs and member accounts.

  Figure 2 How deny permissions are applied
  
• General SCP Configuration Suggestions

  Administrators can combine allow and deny rules to control service permissions across an enterprise. Because deny policies have high precedence, you can configure them at the root or core OU levels to quickly enforce security standards across numerous services and accounts.

  Periodically review and optimize SCPs based on actual access logs. By following the principle of least privilege (granting only necessary permissions), you can significantly improve your security posture.

  By default, the root OU, OUs, and member accounts are granted the FullAccess policy. To mitigate risks from new service rollouts, administrators can transition to a whitelist model, replacing the default policy with one that explicitly permits only authorized services.

• Two main approaches to implementing permission control
  • Configuring a unified whitelist policy at the root node: The rules are automatically inherited by all resources throughout the entire organization, ensuring standardized permission control.
  • Creating dedicated policies for specific OUs and independent accounts: Administrators can configure permissions based on distinct service scenarios, enabling refined management and granular control over different business units.
  

  Relying solely on allow rules and the default deny mechanism can be risky. Broad or overlapping allow rules may lead to permission redundancy and unauthorized access.

• Typical scenarios
  • Scenario 1: Hierarchical Constraints of Deny Policies

    In this scenario, OU1 is configured with both the FullAccess policy and a policy that denies OBS permissions. Within this OU, Account y also has an ECS deny policy applied directly. As a result, Account x and Account y (both under OU1) are prohibited from using OBS due to the inherited deny policy. Account y is further restricted from performing any ECS-related operations.

    Figure 3 Inheritance and constraints of deny rules
    
  • Scenario 2: Necessity of Configuring Allow Rules at Every Level

    A prerequisite for using services is to configure allow rules across the entire organizational link, from the root down to the member account. For instance, if a parent OU (such as OU1) is configured only with permissions for ECS, all member accounts under it (Account x and Account y) are restricted to using only ECS.

    Figure 4 Hierarchical requirements for allow rules
    
  • Scenario 3: Impact of Missing Allow Rules in the Root OU

    If no allow policy is configured at the root OU level, all member accounts within the organization will be blocked from accessing or operating any cloud services.

    Figure 5 Organizational access blocked by root OU constraints
    
  • Scenario 4: Multi-Level Deny Rules Taking Effect Together

    In a multi-level hierarchy, deny rules take effect collectively across all levels. Suppose the root OU and the upper-level OU (OU1) both retain the default FullAccess policy. However, OU2 is configured with an additional policy that explicitly denies access to ECS, while OU3 has no such restriction. As a result, only Account x (under OU2) is prohibited from using ECS. Account y and Account z (under OU3) retain their full service permissions as granted.

    Figure 6 Multi-level deny rules taking effect together
    
  • Scenario 5: OU-Level Whitelists for Refined Management and Control

    In this scenario, OU2 is limited to a whitelist containing only ECS, while OU3 remains unrestricted with a FullAccess policy. This approach achieves strict permission isolation between different OUs and enables the on-demand allocation of resource access based on specific operational needs.

    Figure 7 OU-level whitelist for refined management
    
  • Scenario 6: Precedence of Deny Rules at the Root OU

    If OBS is disabled at the root OU, the restriction remains in effect for all subordinate accounts and cannot be overridden by allow rules at lower levels. Consequently, even if OU2 is granted OBS permissions, Account x remains unable to access the service. Similarly, other lower-level member accounts, such as Account y and Account z, can use all cloud services except OBS.

    Figure 8 Deny rules in the root OU taking precedence
    
  • Scenario 7: Root OU Whitelist for Global Management and Control

    By applying a service whitelist to the root OU, you can implement unified control across the entire organization. In this configuration, even if lower-level OUs are attached a FullAccess policy, the "intersection of permissions" rule ensures that no account can exceed the limits set at the root. All member accounts, including Account x and Account y, are limited to the services allowed by the root OU policy.

    Figure 9 Global management via root OU whitelisting
    

Differences Between Explicit Deny and Implicit Deny

The effect of Deny indicates the permission to deny an operation.

If there are no applicable Deny statements, all requests are denied by default. This is called an implicit deny.

If a policy includes an applicable Deny statement, requests will be denied. This is called an explicit deny.

The following figure shows the logic for authenticating an access request.

1. A principal sends an access request.
2. The system looks for a Deny statement that applies to the request. If the system finds an applicable Deny, it returns a final decision of Deny, and the authentication ends.
3. If no applicable Deny is found, the system looks for an Allow that would apply to the request. If the system finds an applicable Allow, it returns a final decision of Allow, and the authentication ends.
4. If no applicable Allow is found, the system returns a final decision of Deny, and the authentication ends.