Assumptions

This article assumes that you have good knowledge of

• AWS Organizations
• AWS IAM, policies and roles

Introduction

A while ago, while studying for the AWS Architect Professional and the AWS Security Specialty certifications, I learned about SCPs (Service Control Policies). This special type of permission policy, usable only in an AWS Organization, has many useful features, which can simplify the administration and security management of your AWS Organization.

Since I passed both those certifications successfully, I believed that I had a good understanding of SCPs until a recent client project showed me that I had in fact misunderstood some of the basics of SCPs when I tried to add them to the organization setup. I also realized that not everyone uses SCPs despite the many features it offers.

To address both issues I decided to take another look at them in more detail and to figure out exactly what SCPs can and cannot do, and to figure out what arguments I could use to inspire organizations to use them more often.

This article is one of the results of this re-learning process about SCPs, and I hope it will help some of you to understand SCPs, their use cases and their limitations better.

A simple organizational example

The following diagram represents a basic organization with 3 organizational units:

• the Application unit is used to run the company website and sell its products
• the Intelligence unit contains the accounts dealing with data ingestion and analytics dashboards
• the Billing unit handles bills, company income and all matters related to money

The next part describes two classic problems that could arise in an organization such as the one described above, and explains why it would be difficult to solve them using only IAM permissions.

Scenario #1: service restriction

In this organization, the accounting department recently doubled in size because the company grew so quickly, and many of the new employees have very little experience with AWS. Being very aware of the cost of AWS services, they are worried that someone might accidentally start using a very expensive service (someone heard about some service called Redshift), and incur unnecessary and excessive expenses. They decide to talk to the DevOps team and see what they can do to prevent this from happening.

“No worries”, says the DevOps team. “Every user of the Accountancy account belongs to an IAM Group, which doesn’t allow use of any unnecessary services!” The accountants don’t really understand what this technical jargon means, but they are reassured and return to their columns of numbers.

However, this event has made some accountants realize that some AWS services are very expensive. They think it would be a good idea to prevent the usage of any service that is not deemed “necessary” for the business throughout the entire organization, not just the accountancy department. This would avoid uncontrolled costs from possible mistakes or experiments. They submit this idea to their higher-ups, which is eventually approved and handed over to the DevOps team for implementation.

The team starts planning the necessary IAM changes to groups, roles and users, but quickly realizes that with already 5 AWS accounts, each containing dozens of roles and groups, preventing a service provisioning (like Redshift) via IAM alone for the whole organization will be a complicated and hard to maintain operation. And this is not even considering future new accounts and IAM entities.

The team needs a more effective and simpler solution. This is when they start to consider SCPs (more details on the solution later).

Scenario #2: region restriction

A little while later, some of the Data team members attend a GDPR focused training. When they come back they realize that it is critical that any PII (Personal Identifiable Information) that the company handles does not leave Germany where the company operates.

One of their priority is to prevent some instance or AWS service started in a non-German AWS region to download some PII data. There are many ways to achieve this, for instance via Network lockdown or by making sure that no service can transfer data between regions.

However, since the company does not operate outside Germany (eu-central-1), there is no reason to even allow any activity in any other AWS Region. Because of this, the DevOps team decides to find a way to prevent any AWS resources to be provisioned outside of Germany. Here again, doing this via IAM alone would be complex to configure and to maintain, while this is easily achievable via SCPs.

How can SCPs help?

SCPs or Service Control Policies are Organization specific policies that can be used to apply guardrails or limits to what the members of an organization can do.

An important point to remember is that an SCP alone is never enough to allow a user to perform an action. The user will still need an IAM permission. SCP can only forbid actions.

Usage

They are typically used to:

• apply organization or organization unit wide policies
• prevent members from using some services, for security, compliance or economical reasons
• limit resource creation to specific AWS regions

An SCP can be attached to any element of an organization (or to several at once), with different effects:

• if attached to an account, the policy will only affect this account
• if attached to an organizational unit, the policy will affect all accounts in this OU and all sub-OU as well
• if attached to the root of the organization, the policy will affect every single account in the organization (except for the management account)

Note: any Organization element (root, OU, account) must have at least one SCP attached, by default this is the FullAWSAccess managed policy.

Decision logic

When it comes to deciding which policy applies and if a user is allowed to perform an action, SCPs behave similarly to IAM policies:

Requirements

There are a few requirements to fulfill before using SCPs:

• have an organization (with at least 2 accounts in total, otherwise the SCPs will have no effect)
• enable “all features” on the organization
• enable the SCP policies

Examples

Preventing a specific service usage

If we want to solve the first problem mentioned above, where we would like to prevent anyone in the member accounts from using Redshift (or any other costly service), we could use the following SCP:

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

This SCP specifies that no Redshift action is allowed. When attaching this policy to the root of the organization, it becomes impossible from anyone in any of the member accounts to perform any Redshift related actions, such as starting a Redshift cluster for instance. You can test that easily by using the IAM simulator.

Restricting to a specific region

Just like IAM policies, SCPs can include global conditions, which allow imposing restrictions depending on an action’s context. This can be used to solve issues like in our second problem, where the goal was to limit AWS usage to a specific region.

The following SCP, if attached to the root of the organization, would limit any actions to the AWS German region.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Statement1",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "eu-central-1"
          ]
        }
      }
    }
  ]
}

We can see the results of this if we try to access the EC2 console in any other region:

Note that in practice, you would usually exclude from the list of forbidden actions some specific action for Global services, such as S3, STS or IAM. Otherwise many basic activities, like even listing S3 buckets in ANY region would become impossible. You can find a list of those actions in the first example of the AWS docs.

Are they all powerful?

While you can do a lot with SCPs, they have their limitations. Some actions like the AWS Support level or some Alexa specific operations cannot be affected by SCPs (see the complete list in the docs).

Also, an SCP will never have any effect on the management account. It doesn’t matter if the SCP is attached to the root or to the management account directly. SCPs were designed to prevent AWS organization users from accidentally locking themselves out of key services and being unable to use their account properly.

Then there is the matter of service-linked roles and IAM resource-based policies.

Resources-based policies targeting external entities

Some AWS resources such as S3 buckets and KMS keys can be given resource-based policies. Such policies are normally affected by SCPs, but only if the entity allowed access to a resource is part of the organization. The following example will demonstrate this.

Let’s associate the following SCP to the root of our organization.

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

A look at the IAM Simulator will show us that a normal user cannot perform any S3 action as expected.

Now let’s assume that we have an account in this organization with the ID “11111111”, and that another organization has an account with the ID “2222222”. If we add the following policy to the S3 bucket, then the user “jack”, who is a member of the other organization, will be allowed to upload/download a file to the S3 bucket with the ID “11111111”, despite the SCP clearly forbidding such actions.

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Sid": "Statement1",
			"Effect": "Allow",
			"Principal": {
				"AWS": "arn:aws:iam::2222222:user/jack"
			},
			"Action": "*",
			"Resource": "arn:aws:s3:::11111111-scp-test-bucket/*"
		}
	]
}

This is because an SCP never affects entities outside the organization, as the AWS documentation clearly states:

“SCPs affect only IAM users and roles that are managed by accounts that are part of the organization. SCPs don’t affect resource-based policies directly. They also don’t affect users or roles from accounts outside the organization.”

Service-linked policies

A service-linked policy is a policy created by AWS services for AWS services inside your account. You cannot modify those roles, nor the policies they use.

SCPs do not affect those roles. The reason AWS made this choice is most likely because those roles are essential to allow AWS services to function, and if any unintentional SCP association could prevent them from working, the consequences would be organization wide and unpredictable.

A very good example are the roles created by an organization in all member accounts.

If an SCP could affect those roles, you might end up with broken accounts or with some serious and hard to define security issues.

Conclusion

SCPs are a powerful tool in the AWS Organization arsenal. They can and should be used extensively since they provide features hard to replicate otherwise. However, they have their weaknesses and should not be the sole security focus point in any organization using AWS, especially when your resources are accessed by people other than the ones in your organization.

If you found this interesting, know that a lot more can be achieved with SCPs by combining them with tools such as Global conditions (IPs, VPC endpoints…) or permission boundaries. They can also be managed using a variety of strategies, such as deny lists (the default approach) or allow lists. In future articles, I will use examples to further demonstrate what can be achieved. Stay tuned!

If you want to read more about SCPs and see more examples, have a look at this other article.