AWS Service Control Policies (SCPs) - A Complete Guide with examples

Service Control Policies, or SCPs for short, are a big step forward in getting more centralized control over which AWS services are being used in your AWS Organization. So If you are in a position where you have responsibility for the AWS Cloud infrastructure, then you must read this post!

In short, to make use of AWS Service Control Policies you'll need to create an AWS organization in your AWS account. After that, you can enable Service Control policies and attach them to an AWS account or Organizational Unit (OU).

Now you can create your own SCPs, but how can you be so certain whether our SCP is implemented properly, and if it's effective or not? This guide explains what AWS Service Control Policies (SCPs) are and shows you how to create SCPs and test them. To help you get started I'll be sharing three examples SCPs using best practices that you can apply in your own AWS Organization to secure it immediately!

Introduction: What is an AWS Service Control Policy

A Service Control Policy (SCP) is a set of rules you can create to control access on your AWS resources within the accounts in your AWS Organization. SCPs are managed centrally within AWS Organizations.

Benefits of using AWS Service Control policies

When your organization grows bigger and you need to manage more AWS accounts for different teams and workloads, it becomes harder to maintain rules and guardrails strictly via IAM. IAM allows you to control users and roles within an account, but it becomes harder to manage permissions and policies when you have to deal with multiple roles on different AWS accounts.

That's where SCPs become utterly important because it acts as an extra layer of security that overrules the permission that is set on IAM resources. The biggest benefit is that you have better control over what an account can and cannot use and therefore reduce costs dramatically, especially when the number of accounts is growing over time. To give an example; developers on their development account are spinning up very large EC2 instance types for testing because they have no idea which EC2 instance to use. With an SCP you have control over which EC2 instances are allowed to be used by that specific account.

OUs are groups of AWS accounts that can be managed like a single unit. That means that if you apply an SCP on an OU, the whole group of AWS Accounts activates these permissions as configured in the SCP.

To show you an example, here is what an AWS Organization with multiple AWS accounts under OUs would look like.

The OUs are categorized in the type of workload that is hosted on these accounts within an OU. The application OU contains the actual business application accounts separated between test and production. The development OU contains the development and sandbox accounts where developers can test their changes and experiment with new features and services. As you can imagine these accounts typically need fewer restrictions compared to the accounts in the application OU.

Since the accounts are categorized in the type of workload via OUs it becomes a lot easier to manage and restrict actions on multiple AWS accounts. But be aware that if you plan on making various SCPS, you're allowed to attach a maximum of 5 SCPs to a root, OU, or account.

Create an AWS organization

To be able to start using AWS Service Control Policies you need to enable AWS Organizations first in the AWS Console

Click on the orange Create an organization button to create an AWS Organization with all features enabled. You'll want all features enabled because that allows you to configure and delegate SCPs. Once you've created an AWS Organization you'll see the organization structure in the AWS Console

From this overview, you can manage and control how the AWS accounts are organized and grouped together using OUs.

Enable Service Control Policies in AWS organizations

Now that we've created an organization, you see that all the policies are disabled by default.

we can now enable AWS Service Control Policies in the AWS console by clicking on the button Enable service control policies.

After enabling service control policies a new SCP is added automatically called FullAWSAccess. This is a policy that's managed by AWS and can't be modified. This SCP allows access to every operation and is attached to the Root of the AWS organization, this means that all AWS accounts inherit this SCP. Without this SCP the accounts are useless since you can't perform any action on them anymore, so it's important to keep it attached to the Root OU.

Create an AWS Service Control Policy

From within the Service control policies tab in the AWS console you can create a new policy.

You can add a policy name and description to describe what the SCP is supposed to restrict or allow. Service Controle Policies are structured in JSON format and use a similar syntax to that is used by AWS IAM. The AWS console provides an editor that you can use to easily add statements to your policy. For this example, we'll add a deny rule for the AWS service: AWS Shield service.

Now you can click the Create policy button to create the SCP. Note: keep in mind that the maximum size of an SCP can only be 5120 bytes, see Quoatas for AWS Organizations.

Activate and attach a Service control Policy

Now that the SCP is created it's not activated yet. You need to attach it to an OU or account to activate the rule and restrict access. In order to do so, you need to go to the targets tab of the rule and click attach.

Then you can pick the account you wish to apply the SCP with the deny AWS Shield statement.

The SCP will immediately be in effect on your chosen AWS account or OU. This means every IAM user or role doesn't have access to call any AWS Shield actions on behalf of all AWS resources.

Test a Service Control Policy

Now that you've seen how to create an SCP using the basic example in the previous section, you want to customize it even further by making more complex rules. Adding more complex rules to an existing organization calls for testing before you apply it to for example a production account. Because you can imagine that if you make a mistake by for example denying certain actions or services that are used by important users or services that it can have a devastating effect since SCPs overrule all other permissions within the scope of an AWS account.

Therefore to test out a new SCP, you're advised to create a new OU and attach the SCP to it. Don't attach an untested SCP directly to the root of your organization!. This will apply the rules directly to all accounts in your AWS organization. You should move your accounts into the new OU that you created (one at a time), starting with developer and sandbox accounts. Then Gradually move on to staging and production accounts.

During this process of moving the accounts into the new OU, you should notify the members of the organization that you've activated your new rules. Then you can actively receive feedback if they get denied to a specific service. Then it's up to you or your team to check if you want to revert a specific rule or keep it.

Tools like AWS CloudTrail and the service last accessed data in IAM are good ways to determine whether a specific AWS Service that you wish to block is being used in your target AWS account.

Best practices for creating a Service Control Policy

You can configure the SCPs in your AWS Organization to work as either of the following:

• A deny list – actions are allowed by default, and you specify what services and actions are prohibited
• An allow list – actions are prohibited by default, and you specify what services and actions are allowed

To stay flexible and be prepared for any new AWS services in the future it's best practice for most organizations to manage a deny list instead of an allow list. The reason is that it requires less maintenance and you don't need to update it when AWS announces a new AWS service (which happens often).

By default the organization has the FullAWSAccess SCP enabled on the root OU, which means all accounts have access to every service. We can use that as a starting point to create new SCPs with explicit deny rules.

Three practical examples of AWS service control policies

I've supplied three practical SCPs that you can use in your own AWS Organization using the deny list strategy. Note: make sure to review it first and use the test process as described in the previous paragraph before you deploy it.

Tip: In my code library you can find more practical SCP's which you can copy and use.

Example SCP 1: Deny access to AWS resources for the AWS account root user

It's generally a best practice to not use the root user to do your tasks in your AWS account. Instead, you should create an IAM admin user and use that to do administrative tasks.

Since the root user has full access to all your resources and billing information you should further protect it with the following steps:

• Enable AWS multi-factor authentication (MFA)
• Delete the access keys from the Security credentials page
• Setting up a strong password

As an additional layer of protection, you can set up a guardrail in the form of a Service Control Policy to deny access to AWS resources from the root user.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Condition": {
        "StringLike": {
          "aws:PrincipalArn": "arn:aws:iam::*:root"
        }
      },
      "Action": "*",
      "Resource": "*",
      "Effect": "Deny",
      "Sid": "DenyRootUser"
    }
  ]
}

Example SCP 2: Deny access to AWS services in unsupported AWS regions

This SCP restricts the use of AWS services in unsupported AWS Regions. This is very useful if you only deploy to a single AWS region. By revoking access to other AWS regions you'll effectively limit the blast radius in the event of a security breach.

As you can see in the example below, if the AWS API call doesn't match with the eu-west-1 regions then deny all actions on all resources except for the aws services in the NotAction element.

If you look closer to the NotAction element, the services that are listed there are global services and are hosted in the us-east-1 region by default. Be aware, that blocking the services that are whitelisted in this action might cause issues in your active region.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": ["eu-west-1"]
        }
      },
      "Resource": "*",
      "Effect": "Deny",
      "NotAction": [
        "a4b:*",
        "acm:*",
        "aws-marketplace-management:*",
        "aws-marketplace:*",
        "aws-portal:*",
        "budgets:*",
        "ce:*",
        "chime:*",
        "cloudfront:*",
        "config:*",
        "cur:*",
        "directconnect:*",
        "ec2:DescribeRegions",
        "ec2:DescribeTransitGateways",
        "ec2:DescribeVpnGateways",
        "fms:*",
        "globalaccelerator:*",
        "health:*",
        "iam:*",
        "importexport:*",
        "kms:*",
        "mobileanalytics:*",
        "networkmanager:*",
        "organizations:*",
        "pricing:*",
        "route53:*",
        "route53domains:*",
        "s3:GetAccountPublic*",
        "s3:ListAllMyBuckets",
        "s3:PutAccountPublic*",
        "shield:*",
        "sts:*",
        "support:*",
        "trustedadvisor:*",
        "waf-regional:*",
        "waf:*",
        "wafv2:*",
        "wellarchitected:*"
      ],
      "Sid": "DenyUnsupportedRegions"
    }
  ]
}

Example SCP 3: Enforce S3 Bucket owner

Deny the s3:CreateBucket permission for IAM users or roles unless you set the bucket owner enforced setting for Object Ownership and disable ACLs.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Condition": {
        "StringNotEquals": {
          "s3:x-amz-object-ownership": "BucketOwnerEnforced"
        }
      },
      "Action": ["s3:CreateBucket"],
      "Resource": "*",
      "Effect": "Deny",
      "Sid": "RequireBucketOwnerFullControl"
    }
  ]
}

Conclusion

Cloud security remains an important aspect of distributed computing, and AWS Service Control Policies provide a way to implement best practices in an easy manner. By adopting AWS Service Control Policies you will likely reduce the number of unwanted running AWS services, data breaches, and other catastrophic events that have plagued companies without these restrictions.

So now that you know how Service Control Policies work within AWS, you'll be well prepared to create your own Service Control Policies and use them in your AWS accounts.

If you followed this guide and you're looking to improve your AWS Organizations structure using best practices. I'd highly recommend you to read the Complete Guide I wrote about AWS Organizations using best practices.

---

Originally posted on Towards the Cloud

If you liked this post, then you can subscribe to my newsletter