What Are AWS Service Control Policies (SCP)? A Complete Guide

Originally published by Sonrai Security.

Written by Tally Shea.

The cloud is all about innovation at a speed never before possible. This can often lead to rapid development sprints and a proliferation of identities and infrastructure – and with that, excessive privilege. In large scale enterprises, IAM governance can be difficult. To accommodate this, Amazon Web Services (AWS) created Service Control Policies. The following guide will:

• Define what a Service Control Policy (SCP) is.
• Define its functionality in a larger governance strategy.
• Detail challenges associated with implementing them.

Are you working multi-cloud? Learn about Azure Policy here and Google Organization Policy here.

Understanding Service Control Policies in AWS

A service control policy is a set of controls at the organizational unit that restricts the maximum level of permissions that users, roles, and even root users in AWS accounts can hold. They act as guardrails, trumping all other levels of policy to ensure security standards are consistently applied across the organization.

SCPs are particularly important in large-scale enterprises where managing and enforcing consistent policies across numerous accounts is a complex task. This centralized governance model is essential for maintaining a balance between enabling access and enforcing security and compliance across the AWS environment.

SCP benefits include:

• Accommodate enterprise-grade scale and multi account environments.
• Centralized control over privilege governance.
• Help meet regulatory or corporate requirements.
• Helps build custom environments tailored to specific data security or access management needs.
• Inheritance of policy from OU down the hierarchy to accounts means less manual efforts
• More development freedom to manage their own permissions because you’ve set guardrails for them.

Components of Service Control Policy

Understanding the components of an SCP is the first step before implementing them:

• Statement: The core of the policy, defining permissions or restrictions.
• Statement ID (Sid): A unique identifier for each statement, aiding in policy management and troubleshooting – e.g. DenyAllOutsideEU
• Effect: Determines whether the policy results in an ‘allow’ or ‘deny’ statement.
• Action: Specifies the actions the policy allows or denies – e.g. s3:* for all Amazon S3 actions.
• NotAction: Specifies what is not covered by the policy, useful for broad permissions with specific exceptions.
• Resource: Defines the AWS resources to which the policy applies, using ARNs (Amazon Resource Names).
• Condition: Additional criteria that refine the policy’s application, such as date, time, or user attributes – e.g. aws:SourceIp

How Do AWS Service Control Policies Work?

SCPs are part of the AWS Identity and Access Management (IAM) framework but serve a distinct purpose. Unlike IAM policies that grant permissions, SCPs are used to define limits and restrictions. They do not grant permissions but instead act as a filter over the permissions that can be exercised within an AWS account.

SCPs are applied at the AWS Organization or Organizational Unit (OU) level, affecting all accounts within that scope.

SCP Allow: Sets the boundaries for what actions IAM policies can permit but does not grant permissions itself. For ‘allow’ to work, there must be a statement made at every level from root through each OU to the account you want affected. An SCP is deny-by-default otherwise.

SCP Deny: When an SCP includes a ‘deny’ statement, it explicitly prohibits certain actions, regardless of any other permissions that might be granted elsewhere. In the example below you can see a ‘deny’ statement at the OU level disrupting the ‘allow’ statement at the account level.

Source: https://docs.aws.amazon.com/organizations/latest/u...

AWS SCP vs IAM Policy: Key Differences

With so many variations of policies in AWS, it can get difficult to keep track. Here are how SCPs and IAM policies compare:

• Scope: SCPs apply at the organization or OU level, while IAM policies are applied at the user, group, or role level within an individual AWS account. Within IAM policies there are identity-based and resource-based policies in AWS.
• Permissions Granting: IAM policies grant permissions, whereas SCPs only restrict or filter permissions.
• Hierarchy: SCPs are at the top of the permission hierarchy in AWS. Even if an IAM policy grants a permission, an SCP can override this by denying it.

Setting Up a Service Control Policy

Before actually implementing an SCP in AWS, your team will likely follow a process similar to the following: 1) Pitching the use case for one 2) Requesting usage 3) Security Team or equivalent team analysis of the SCP use case 4) Map possible usage scenarios and necessary testing. Finally, you’ll be ready to actually execute building one out.

To set up SCPs in AWS, follow these steps:

1. Create an AWS Organization: Establish your AWS Organization for centralized management.
2. Enable Service Control Policies: Activate SCPs within your organization settings.
3. Create an AWS SCP: Define your SCP, specifying the allowed or denied actions and resources.
4. Choose Your Statement: Decide between ‘Allow’ and ‘Deny’ statements based on your requirements.
5. Add Conditions (Optional): Specify conditions for more granular control.

Source: https://aws.amazon.com/blogs/mt/implement-aws-reso...

3 AWS SCP Best Practices and Tips

• Use the management account judiciously: Reserve the management account for administrative tasks only and apply SCPs primarily at the OU level.
• Test your SCPs before application: Implement SCPs in a controlled environment before rolling them out organization-wide to avoid disrupting or breaking other processes.
• Give your policy a name and description that will make it easily recognizable and understandable, e.g. ‘DenyChangestoS3.’

AWS SCP Example

Sensitive data protection.

Here’s an example of an SCP used for sensitive data protection. It denies users from deleting S3 buckets or objects:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": [
                "s3:DeleteBucket",
                "s3:DeleteBucketPolicy",
                "s3:DeleteObject",
                "s3:DeleteObjectVersion",
                "s3:DeleteObjectTagging",
                "s3:DeleteObjectVersionTagging"
            ],
            "Resource": [
                "arn:aws:s3:::[BUCKET_TO_PROTECT]",
                "arn:aws:s3:::[BUCKET_TO_PROTECT]/*"
            ]
        }
    ]}

Denying Root User

This example enforces a security best practice – denying any usage from the root user. See below:

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

Service Control Policy Use Cases

As we know, SCPs are used to enforce organizational guardrails and uphold security. Some more specific use cases for them include:

Denying changes to security services: AWS offers security monitoring and detection services that help keep an eye on your environment and alert to threats. You can use guardrails to ensure no accounts can alter these services and disrupt protection.

Privileged access controls: If your organization has certain privilege or access standards you want maintained across the org, you can use an SCP to limit maximum permissions.

Regional controls: In multi-account environments, you can inhibit usage within certain regions.

Data security and protection: To protect data, you can use an AWS SCP to ensure only specified identities are accessing specific data or enforce that no members can change configurations on data services like S3.

AWS SCPs: Addressing the Challenge

Visibility

The complexity of managing multiple overlapping policies, including SCPs and IAM policies, can lead to a lack of visibility and control. It’s essential to have a clear understanding of the cumulative effect of these policies on your AWS environment, otherwise potential challenges arise.

Without proper visibility your identities can end up with access you never authorized. As we know, privilege can easily be inherited in the cloud, making it harder to see ‘on paper.’ This type of unseen privilege can result in opportunities for lateral movement. That lateral movement can be exploited by malicious attackers.

On the contrary, implementing too conservative of a strategy with hefty denial via Service Control Policies, you end up with development interruption and inefficient request processes.

Responsibility

Cloud security generally faces a confusing distribution of responsibility because it is a new frontier. There is discrepancy between who builds the cloud (and consequentially influences the security of it) and who manages security and IAM. Defining who owns Service Control Policies is up to the discretion of an enterprise (e.g. DevOps vs. Security teams vs. Governance teams) but this lack of definition can lead to gaps, confusion and not using the feature to its full potential.

The answer is a solution with both the technology to compute effective permissions – the logical intersection of how all these IAM policies and SCPs interact with each other — and operationalized workflows for building and remediating.