How to use AWS Organizations to simplify security at enormous scale

AWS Organizations provides central governance and management across AWS accounts. In this post, we explain how AWS Organizations can make the lives of your Information Security engineers easier, based on our experience in the Information Security team at Amazon. The service control policies (SCPs) feature in AWS Organizations offers you central control over permissions for all accounts in your organization, which helps you to ensure that your accounts stay within your organization’s access control guidelines. This can give your Information Security team an effective mechanism to prevent unsafe actions in your AWS accounts. You can modify or add more SCPs if needed based on your specific business requirements.

In this post, we show you how to implement SCPs to restrict the types of actions that can be performed by your employees within your company’s AWS accounts, and we provide example SCPs that are used by Amazon’s Information Security team for the following restrictions:

Prevent deletion or modification of AWS Identity and Access Management (IAM) roles created by the Information Security team
Prevent creation of IAM users with a login profile
Prevent tampering with AWS CloudTrail
Prevent public Amazon Simple Storage Service (Amazon S3) access
Prevent users from performing any action related to AWS Organizations

All of these rules, and the reasons for implementing them, are described in detail in this post. Note that Amazon uses many more SCPs than those listed above, but these are some examples that we consider to be best practices and that can be shared publicly.

Scope of problem

At Amazon, security is the number one priority, and it’s a common challenge in the technology industry to keep pace with emerging security threats while still encouraging experimentation and innovation. The Information Security team at Amazon is responsible for ensuring that employees can rapidly develop new products and services built on AWS technologies, while enforcing robust security standards. How do we do this? Among other things we use AWS Organizations and SCPs to uphold our security requirements.

Amazon has thousands of AWS accounts, and before the launch of AWS Organizations, the Information Security team at Amazon had to implement custom-built reactive rules in each account by using AWS Config, AWS CloudTrail, and Amazon CloudWatch to detect and mitigate any possible security concerns. This was effective, but managing all of the rules for thousands of AWS accounts was challenging. The Information Security team needed to tackle two specific challenges:

How can we shift to a preventive approach—that is, blocking unsafe actions from happening in the first place—and then use reactive controls solely as a fallback mechanism?
How can we continue to ensure that our critical infrastructure running in AWS accounts is tamper proof, without building custom monitoring and remediation infrastructure? For example, we create custom IAM roles to broker single sign-on access to our AWS accounts. We need to ensure that employees cannot delete these roles accidentally, and that unauthorized users cannot delete these roles maliciously.

The launch of AWS Organizations provided the Information Security team at Amazon with a way to tackle both challenges.

Replace reactive controls with preventive controls

Let’s take a look at some of the key rules that the Information Security team at Amazon has in place for managing security posture across AWS accounts. These are company-wide security controls, so we defined them in the organization root so that they are enforced across all AWS accounts in the organization. You can also implement these security controls at the organizational unit (OU) or individual account level, which gives you flexibility to implement different sets of guardrails for different parts of your organization.

Rule 1: Prevent deletion or modification of IAM roles created by the Information Security team

The Information Security team at Amazon creates IAM roles in every AWS account that is used by Amazon, and we use these IAM roles to centrally monitor and control access in accordance with Amazon security policies. Accordingly, no one other than the Information Security team should be able to delete or modify these roles.

Before the use of AWS Organizations and SCPs, the Information Security team at Amazon used reactive controls to scan every account, to make sure that nobody had deleted these important roles. Reactive controls detect whether someone has made a configuration update that does not comply with company security policies.

What are some possible drawbacks to this approach?

This is a reactive approach that detects a problem only after it has occurred—in this case, after somebody has deleted one of the important roles.
It puts the responsibility for security in the hands of your employees, and you rely on their goodwill and expertise to ensure that they uphold the rules.

Your employees want to focus on their core competencies and getting their jobs done effectively. Requiring that they also be information security experts is not an effective strategy. It’s much easier for everyone in your organization if you simply remove this burden in the first place. SCPs allow Amazon to do this. With SCPs, you can help avoid giving unwanted access to employees outside your security access team. As you will see in the following example, you can ensure that all roles required for the Information Security team begin with the string InfoSec, and you can create an SCP that prevents employees from deleting these roles.

The following is an example of an SCP that prevents the deletion or modification of any IAM role that begins with InfoSec in all accounts, unless the initiator uses an InfoSec role. This example demonstrates how you can use condition statements in your SCPs, which give you a lot of flexibility in determining when your SCP should be applied.


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PreventInfoSecRoleActions",
            "Effect": "Deny",
            "Action": [
                "*"
            ],
            "Resource": [
                "arn:aws:iam::*:role/InfoSec*"
            ],
            "Condition": {
                "StringNotLike": {
                    "aws:PrincipalARN": "arn:aws:iam::*:role/InfoSec*"
                }
            }
        }
    ]
}

Rule 2: Prevent creation of IAM users with a login profile

When your employees are authenticated in your corporate network, it’s a security best practice to use identity federation to allow them to sign in to your company-owned AWS accounts, rather than to create individual IAM users for all of your employees, each with their own passwords.

The following are some of the reasons that it’s a best practice to use identity federation instead of creating individual IAM users for all of your employees:

Using identity federation makes it easier for the Information Security team, so that they don’t have to control individual credentials across thousands of accounts and users.
When using identity federation, users log into your AWS accounts with temporary credentials, and there is no need to store long-term, persistent passwords, thus reducing the possibility of an external entity guessing a user’s password.

The following is an example of an SCP you can use to prevent employees from creating individual IAM users.


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PreventIAMUserWithLoginprofile",
            "Effect": "Deny",
            "Action": [
                "iam:ChangePassword",
                "iam:CreateLoginProfile",
                "iam:UpdateLoginProfile",
                "iam:UpdateAccountPasswordPolicy"
            ],
            "Resource": [
                "*"
            ]
     }]
}

Rule 3: Prevent tampering with AWS CloudTrail

It’s very important for your Information Security team to be able to track the activities performed by all users in all accounts. In addition to this being a best practice, many compliance standards require you to maintain an accurate history of all user activity in your AWS accounts. You can use AWS CloudTrail to keep this history, and use an SCP to help ensure that unauthorized users cannot disable AWS CloudTrail or modify any of its outputs.

The following is an example of an SCP to prevent tampering with CloudTrail. To use the example, replace exampletrail with the name of the trail that you want to protect.


{
            "Sid": "PreventTamperingWithCloudTrail",
            "Effect": "Deny",
            "Action": [
                "cloudtrail:DeleteTrail",
                "cloudtrail:StopLogging",
		        "cloudtrail:PutEventSelectors",
                "cloudtrail:UpdateTrail"
            ],
            "Resource": [
                "arn:aws:cloudtrail:*:*:trail/exampletrail"
            ]
}

Rule 4: Prevent public S3 access

It’s a security best practice to only allow public access to an S3 bucket and its contents if you specifically want external entities to be able to publicly access those items. However, you need to make sure that information that might be sensitive is securely protected and not made publicly available. For this reason, the Information Security team at Amazon prevents Amazon employees from making S3 buckets or content publicly available, unless they first go through a security review and get explicit approval from the Information Security team. We use the Amazon S3 Block Public Access feature in all of our accounts, and the following is an example of an SCP that prevents employees from changing those settings.


{
            "Sid": "PreventS3PublicAccess",
            "Action": [
                "s3:PutAccountPublicAccessBlock"
            ],
            "Resource": "*",
            "Effect": "Deny"
}

Rule 5: Prevent users from performing any action related to AWS Organizations

We also want to help ensure that only the Information Security team can perform actions related to AWS Organizations, and to prevent other users from performing activities such as leaving the organization or discovering other accounts in the organization. The following SCP prevents users from taking actions in AWS Organizations.


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PreventOrgsActions",
            "Effect": "Deny",
            "Action": [
                "organizations:*"
            ],
            "Resource": [
                "*"
            ]
        }
    ]
}

The preceding SCP also prevents the use of AWS Organizations-related features in some AWS services that rely on read permissions, such as AWS Resource Access Manager (AWS RAM). To allow AWS Organizations to have read permissions for those services, you can modify the SCP to specify more granular actions in the Action section of the SCP definition. For example, you can modify the SCP to prevent member accounts from leaving the organization while still allowing the use of features such as AWS RAM, as demonstrated in the following SCP. For more information about all of the AWS Organizations API actions that you can access in each account, see AWS Organizations API Reference: API operations by account.


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PreventLeavingOrganization",
            "Effect": "Deny",
            "Action": [
                "organizations:LeaveOrganization"
            ],
            "Resource": [
                "*"
            ]
        }
    ]
}

Conclusion

Before the launch of AWS Organizations, the Information Security team at Amazon had to implement custom-built reactive rules to manage security controls across thousands of AWS accounts, and to ensure that all employees were managing their AWS resources in alignment with company policies. AWS Organizations has dramatically simplified these tasks, making it easier to control what Amazon employees are allowed to do in their AWS accounts. We’ve shared this information and examples of SCPs to help you implement similar controls.

Keeping your environment secure is not always something as clear as the “yes/no” of an access control policy. So, in addition to using Organizations SCPs, most large-scale environments also use techniques like AWS Config Rules to monitor for changes that are allowed but, depending on context, may be problematic. For example, in the CloudTrail case, you might want to allow DevOps teams to make some changes to the kinds of events logged by CloudTrail, such as whether to log data events or only management events, in which case you might permit access to an API like PutEventSelectors. In a situation like that, however, you can use a Config managed rule like “cloudtrail-security-trail-enabled” to alert on the edge case of an engineer disabling management events. The best practical security will be achieved by a combination of preventative—such as the ones we focused on in this blog post—and reactive controls, with reactive controls providing some of the flexibility needed to enable fast-moving teams to take full advantage of the features and flexibility of the cloud.