Achieving operational excellence with design considerations for AWS Organizations SCPs

Service control policies (SCPs) are a set of policies that allow organizations to manage permissions using AWS Organizations. SCPs help control access to AWS services and resources provisioned across multiple accounts created within an organization. In addition, SCPs enable you to set up permission guardrails by defining the maximum available permissions for IAM principals in an account, enabling organizations to enforce compliance, security, and governance policies. By defining SCPs with AWS Organizations, you can enable teams responsible for protecting information security to establish controls that all IAM principals (users and roles) must adhere to. In this way, SCPs provide an additional layer of control over IAM permissions and help organizations maintain a secure and compliant AWS environment.

You can apply SCPs to any AWS environment. While it may not be an issue with small to mid-size AWS account setups, enterprise customers who deal with hundreds to thousands of AWS accounts spread across several organizational units (OUs) need to consider their SCP design for addressing future scaling needs. This post dives deep into the design principles for SCPs and provides key considerations for defining and managing SCPs that enable operational excellence. It will explain and illustrate the impact of OU structure on the SCPs, what actions you should include in the SCPs as compared to other IAM policy types, and provide specific implementation considerations.

Optimize SCP usage with organizational units (OUs)

Organizational units (OUs) allow you to group AWS accounts together to administer as a single unit. This simplifies the management of your accounts, as you can apply common policies and share, provision, and manage common resources. We recommend you to organize OUs based on security and operational needs, or compliance and data residency needs rather than mirroring your company’s reporting structure. When you have multiple accounts that perform either similar or related functions, you can benefit from grouping these accounts into distinct top-level OUs that can help your teams better understand the overall structure of your AWS accounts and apply controls. You can create multiple OUs within a single organization. You can also create nested OUs that can be up to five levels deep. Each OU can contain multiple accounts, and you can move accounts from one OU to another.

By attaching SCPs to OUs rather than to individual accounts, you can simplify the management of policies across groups of similar accounts. As the number of accounts in your environment grows, applying SCPs at the OU level offers advantages such as granular control, simplified management, flexible governance, and scalability, allowing for tailored security policy and centralized enforcement within an organization. If you’d like to learn more about designing and operating your multi-account environment with OUs, visit Organizing your AWS environment using multiple accounts, and refer to Best Practices for organizational units with AWS Organizations for recommendations and best practices for building OU structures using AWS Organizations.

Understand the quota limit for service control policies

Before developing SCPs, you should have a good understanding of service limits and quotas. You have the flexibility to attach multiple policies to the root of the organization, to an OU, or to an account. For example, in an organization that has the root, one OU, and one account, attaching five SCPs to each of them would result in a total of 15 SCPs (5x SCPs at the root, 5x SCPs at the OU, and 5x SCPs on an account).

The current published quotas are:

1. Maximum number of SCPs attached to the root: 5
2. Maximum number of SCPs attached to each OU: 5
3. OU maximum nesting in a root: 5 levels of OUs under a root
4. Maximum number of SCPs attached to each account: 5
5. Number of SCPs that you can define in an organization: 1000
6. Maximum size of an SCP document: 5120 bytes (not characters)

Note: For the latest information on quotas, see Quotas for AWS Organizations.

If you are running against policy size quota, we recommend you to consider strategies outlined get more out of service control policies in a multi-account environment for guidelines on authoring compact SCPs. We recommend considering alternatives to enforce similar controls when you cannot add additional SCPs to your environment. For example: a requirement to restrict users from deleting either S3 buckets or objects within those S3 buckets can be accomplished by applying appropriate S3 bucket policies instead of using a deny users from deleting Amazon S3 Buckets or objects SCP.

Scale with organizational units (OUs)

For organizations experiencing organic growth, engaging in mergers and acquisitions, or have the desire to implement additional security controls, you might want to add additional OUs in your AWS environment to be able to leverage more SCPs or a landing spot for accounts from newly acquired business units. However, prior to introducing another layer of OUs, we suggest carefully considering the guidance provided on the potential impact it may have on member accounts, AWS services, and related permissions.

For example, consider an organization structure like below, with organizational units A, B, C and D. Organization unit D is a nested OU under OU A. If you want to expand your OU structure, you need to create new OUs under existing OUs. You would then move the accounts from the existing OU to the newly created OU. You cannot move an entire OU after you create it.

Figure 1: Example AWS Organizations structure showing OUs and nested OU

When you move an account from an OU to another, the principals in the account might no longer be affected by SCPs that were defined in previous OU. This means that restrictions imposed by those SCPs are no longer applicable, and the users and roles in the account might have more permissions than they had before. Thus, we recommend you consider making a note of the SCPs and their target resources before moving accounts or restructuring OUs.

If you use global conditions keys that take into account the organization path like aws:PrincipalOrgPaths and aws:ResourceOrgPaths in IAM policies, resource policies or SCPs, or use AWS Resource Access Manager to share resources, OU structural changes can impact permissions set through policies mentioned above. We recommend you to update the values for the condition keys appropriately aligned to the new organization structure. You can use Account Assessment for AWS Organizations solution to understand AWS Organizations dependencies in policies across some or all the accounts in an AWS Organizations.

There might be an impact on AWS services tied to your AWS Organizations structure because of OU structural changes, check configuration on AWS services that you can use with AWS Organizations in use in your environment to confirm if they are set up with OU as target and understand how the services behave when you add new OUs. For example, AWS CloudFormation helps you to implement an Infrastructure as Code model. AWS CloudFormation StackSets enables you to create, update, or delete stacks across multiple accounts and AWS Regions with a single operation. Using a central account, you can define and manage an AWS CloudFormation template, and use the template as the basis for provisioning stacks into selected target accounts or OUs across the list of specified AWS Regions. For customers deploying CloudFormation StackSets targeted at an OU level, it is important to understand the impact of adding new OUs and make relevant changes for not disrupting the deployment workflow. For an OU restructuring, we suggest disabling automatic StackSet deployment before making changes. You can enable it after making the changes to your OU using new OU structure created.

Understand SCP evaluation

As you can attach multiple SCPs at different levels in your AWS Organizations, understanding how SCPs are evaluated can help you write SCPs that yield the right outcome. Note: For a permission to be allowed for a specific account, there must be an explicit allow at every level from the root through each OU in the direct path to the account (including account itself). This is why when you enable SCPs, AWS Organizations attaches an AWS managed SCP named FullAWSAccess policy allowing all services and actions. If you remove this policy at any level of the organization, all inheriting OUs and accounts would be blocked from taking any actions.

Let us walk through an example shown in figure 2 and 3. For a permission or a service to be allowed at the member account B, an SCP that allows the permission or service should be attached at root, at the productions OU, and to account B itself. SCP evaluation follows a deny-by-default model, meaning that any permissions not explicitly allowed in the SCPs are denied. If SCP with an allow is not present at any of the levels such as root, production OU or account B, the access is denied like you do for deny statement under figure 3.

Note:

An Allow statement in an SCP permits the Resource element to only have a “*” entry.

An Allow statement in an SCP can’t have a Condition element at all.

Figure 2: Example AWS Organizations structure with an Allow statement attached at root, production OU and account B

Figure 3: Example AWS Organizations structure with an Allow statement missing at production OU and impact on account B

For a permission to be denied for a specific account, any SCP from the root through each OU in the direct path to the account (including account itself) can deny that permission.  Now, let’s consider an SCP that denies a service is attached to the production OU and an SCP allowing the same service is attached to the root of the organization and account B as shown in Figure 4. Both accounts A and B will be denied access to the service as a deny policy attached at any any level in the organization is evaluated for all the OUs and member accounts underneath them.

Figure 4: Example AWS Organizations structure with a Deny statement attached at production OU that is inherited by account B

While writing SCPs, you can make use of a combination of allow and deny statements to make sure you allow intended actions and services in your organization. Deny statements are a powerful way to implement restrictions that should be true for the broader part of your organization or OU, as when applied at the root or the OU level, affect all the accounts under it. For example, you can implement a policy using deny restricting member accounts from leaving organization at the root level which will be effective for all the accounts in the organization. Deny statements also support condition element which can be helpful to create exceptions.

You can replace FullAWSAccess with a policy allowing only a set of services so that new AWS services are not allowed unless they are explicitly allowed by updating SCPs. For example, if you need to abide by a compliance framework and you want to make sure only AWS services compliant with the framework are used in your environment, you can use an allow statement to only allow compliant services.

We strongly encourage you to read SCP effects on permissions to understand the effect of SCPs on tasks and principals. AWS strongly recommends that you don’t attach SCPs without thoroughly testing the impact that the policy on accounts.

Define broader set of controls in SCPs

You should consider using identity-based and resource-based policies to implement fine grained guardrails and use SCPs to implement coarse-grained controls.

If you attach SCPs to individual accounts, you may get close to the quota on total number of SCPs in an organization, restricting your ability to add additional policies. You can use a deny statements with AWS global condition keys to scope the SCP statements to sets of principals or particular accounts. You can write an SCP and attach it to an OU instead of an account, and use the aws:PrincipalAccount condition key to include or exclude certain accounts. For example, if you need to allow a different set of AWS services in different accounts, you can implement an SCP similar to the following:

Example Policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "service:*",
      "Resource": [
        "*"
      ],
      "Condition": {
        "StringNotEquals": {
          "aws:PrincipalAccount": [
            "123456789012"
          ]
        }
      }
    }
  ]
}

Automate SCP validation and deployment

Defining and provisioning SCPs via Infrastructure as Code (IaC) can simplify infrastructure management, quickly add multiple SCPs concurrently, easily control and track changes to accounts, OUs, and policies and improve transparency and accountability for the review process. You can create SCPs using AWS CloudFormation. You can choose to add a step in the deployment pipeline to validate the SCP against AWS IAM access analyzer for policy grammar and best practices and remove white spaces. SCPs allow you to add a policy description that can be used to store code commit version helping you with audit-ability, as shown here.

Conclusion

In this post, we demonstrated SCP design principles to help you apply SCPs at the OU level, noted the importance of being aware of service limits and quotas. We also discussed considerations as you expand or modify your OU structure. These considerations enable reducing complexity and addressing scaling needs. For SCP automation and deployment, we discussed tools that can help you organize and audit elements of your policies prior to implementing them, enabling operational excellence in managing SCPs.

If you are getting started with SCPs or want to mature your SCP usage, we suggest looking into service control policy examples. While these examples provide a platform for getting started, these do not represent a complete list and you should tailor and extend them to suit the needs of your environment.

About the Author