SCP Best Practices : AWS Service Control Policies

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

With AWS Organizations, you can structure AWS accounts hierarchically around organizational units (OU). The administration account is located at the top level in the root directory. Below it are OUs as subordinate units, which can have further subordinate OUs. In this tree, you can configure restrictions for accounts based on their OU. A simple example is the separation between development, test and production accounts. SCPs act as a guardrail that limits the permissions for a group of accounts.

If you want to grant authorizations to accounts, SCPs alone are not enough. You still need to grant authorizations to accounts or groups via IAMs. Both SCPs and IAM users and roles define the effective authorizations:

‍

SCPs allow you to define the maximum set of actions that are allowed and not allowed for all accounts. These are the guardrails. In addition, the AWS administrator must attach policies to IAM users, roles or resources. The logical interface between what SCPs, IAM and resource-based policies allow is the set of effective permissions. If SCP or IAM block an operation, the user cannot perform that operation even if it is allowed by the other side.

The standard SCP FullAWSAccess "Allow * on *". Think of this as an empty guardrail, meaning that no restrictions are defined by this SCP. Keep in mind that this does not mean that everyone can do everything, because there must be IAM policies in place that define the permissions granted. Using the default policy, your strategy would be to implement a deny list, a series of SCPs consisting of deny statements to restrict the account's permissions. The opposite strategy would be to delete the default SCP FullAWSAccess and implement an Allow list.

Further details on the effects on authorizations can be found here. JSON syntax with one or more statement elements represents SCPs.

The standard SCP FullAWSAccess mentioned above looks as follows:

Click here to find a list of quotas including some minimum and maximum values. For SCPs, you must ensure that there is a limit of 5120 bytes (not characters). Pay particular attention to extra spaces (spaces and line breaks) in the JSON files: When you save an SCP using the AWS Management Console, spaces between JSON elements and outside quotes are removed and not counted. There are other ways to save SCPs without automation.

Testing and debugging SCPs is a difficult task because a member account cannot see the SCPs applied to them. And if something goes wrong due to a lack of permissions, you won't see the reason why, so you won't be able to tell if an SCP or an IAM policy is the reason for the rejection. Here you can find tips for testing SCPs.

As mentioned above, there are two ways to configure the SCPs in your organization: either as a blocked list or as an allowed list. As described here, the block list configuration means that all actions are allowed by default (see the default SCP mentioned above) and you only specify which services and actions are prohibited. The configuration via the allow list is the other way round: by default, everything is prohibited and certain services and actions are permitted.

The AWS documentation contains several sample SCPs as a starting point in your own environment. Below we present some of them as best practices.

Prohibit actions as root user

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

‍

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

Prevent member accounts from leaving the organization.

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

Only use selected regions

Sometimes restrictions regarding regions are required for operations. The following code excerpt denies access to all operations outside the specified two European regions:

Please note that this is only an excerpt of the complete SCP that you need for this region restriction. The full SCP can be found here. In addition, an additional list of actions in global services includes endpoints that are physically hosted by a different region (us-east-1). Without this exception list, these actions would be denied due to the SCP.

Restrict access from outside

When you set up an account, you usually define permitted network 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 the full SCP click here:

‍

Interested in other security best practices? Check out the tips in the AWS documentation. If you have further questions about AWS security in general, our AWS-certified solution architects and engineers will be happy to assist you!

‍