Service Control Policies allow administrators central control over the maximum permissions of all accounts within their organization. We define, name strategies and look at the best practices to help you with compliance automation.  

Using AWS Organizations, you can structure AWS accounts around Organizational Units (OU) in a hierarchical way. The management account is in the root at the top level. Below are OUs as children, which can have further child OUs. In this tree, you can configure restrictions for accounts based on their OU. A basic example is separation between development, testing and production accounts. SCPs act as a guardrail, which limits the permissions for a group of accounts.

If you want to grant permissions to accounts, SCPs alone are not sufficient. You still need to grant privileges via IAMs to accounts or groups. Both, SCPs and IAM user and roles, define the effective privileges:

Via SCPs you can define the maximum set of actions allowed and not allowed for all accounts. These are the guardrails. Additionally, the AWS administrator must attach policies to IAM users, roles or resources. The logical intersection between what SCPs, IAM and resource-based policies allow is the set of effective privileges. If SCP or IAM block an operation, the user cannot execute this operation, even if allowed by the other side.

The default SCP FullAWSAccess “Allow * on *”. Consider this an empty guardrail meaning no restrictions defined by this SCP. Remember, this does not mean, that anyone can do anything, because there must be IAM policies defining the granted permissions. Using the default policy your strategy would be implementing a deny list, a set of SCPs consisting of deny statements to limit account’s privileges. The opposite strategy would be to delete the default FullAWSAccess SCP and implement an allow list.

Find more details about effects on permissions here. JSON-syntax with one or more Statement elements represent SCPs.

The default SCP FullAWSAccess mentioned above looks like this:

Click here to find a list of quotas including some min- and max-values. Concerning SCPs you have to ensure that there is a limit of 5120 bytes (not characters). Have a special look at extra white spaces (spaces and line break) in the JSON files: if you save an SCP by using the AWS Management Console, white spaces between JSON elements and outside of quotation marks are removed and not counted. Other ways to save SCPs exist without automation.

Testing and debugging of SCPs is a difficult task, as a member account cannot see the SCPs applied to them. And if something is going wrong due to missing permissions, you will not see the reason for it, so you can’t see whether a SCP or an IAM policy is the reason for the deny. See here for a tips on testing SCPs.

As mentioned above, there are two ways to configure the SCPs in your organization: either as a deny list or as an allow list. As described here configuration via deny list means that by default all actions are allowed (see the default SCP mentioned above) and you only specify what services and actions are prohibited. Configuration via allow list is the opposite way: default prohibits everything and allows specified services and actions.

The AWS documentation contains several example SCPs for a starting point in your own environment. In the following we introduce some of these as best practices.

Disallow actions as a root user

As described in the AWS Control Tower documentation you should disallow account access with root user credentials as follows:

During he initial setup of your AWS environment the root user account is created. You should never allow everyday interaction with your AWS environment with the root user and enforce this by the above SCP. Instead, create AWS Identity and Access Management (IAM) users for everyday work.

Prevent member accounts from leaving the organization.

The following policy blocks use of the LeaveOrganization API operation so that administrators of member accounts can’t remove their accounts from the organization.

Using only selected regions

Sometimes needed are restrictions concerning the regions for operations. The following code extract denies access to any operations outside the specified two European regions:

Note that this is only an extract of the complete SCP you need for this region-restriction, see here for the complete SCP. Further, an additional list of actions in global services includes endpoints that are physically hosted by another region (us-east-1). Without this exception list, these actions would be denied due to the SCP.

Restrict access from outside

If you setup an account, you mostly will define allowed networking resources. It should not be possible to change these settings, for example by granting direct access to the internet. The following SCP can be used to protect the configuration of your Amazon EC2 virtual private clouds. For complete SCP click here:

Interested in more security best practices? Have a look at the tips in the AWS documentation . If you have more questions about AWS Security in general, our AWS certified solution architects and engineers are happy to support you!