AWS Service Control Policies (SCP), the why, the what and the how.

As organizations continue to expand their use of AWS, maintaining security baselines is crucial to ensuring compliance, preventing data breaches, and maintaining a secure cloud infrastructure. One powerful tool to achieve this is AWS Service Control Policies (SCPs). In this article , we'll explore what SCPs are, how they work how to use them effectively to protect your security baselines in AWS and how to troubleshoot them when IAM permissions are blocked by them.

We're happy to announce general availability of SCP support with the Lightlytics platform. These capabilities help better understand these overlapping abstract layers, troubleshoot and optimize more effectively. Before we dive into Lightlytics's new capabilities, let's start with a quick overview of SCPs: 

Understanding AWS Service Control Policies

Service Control Policies are a type of policy statement that allows you to set fine-grained permissions and restrictions across your AWS accounts in an organization. SCPs enable you to define the maximum permissions for a specific account or organizational unit (OU), ensuring that users and roles within the account cannot exceed these permissions, even if their individual IAM policies grant them more access. This helps to maintain a consistent security baseline across your organization.

How AWS SCPs Work

SCPs operate at the AWS Organizations level, which means they are applied to accounts within an organization, rather than to individual IAM users or roles. SCPs work alongside IAM policies, but they do not grant permissions themselves. Instead, they serve as a guardrail, limiting the permissions that IAM policies can grant within an account.

Steps to Implement AWS SCPs for Security Baselines

Step 1 - Setup AWS Organizations: To get started with SCPs, you'll need to setup AWS Organizations. If you haven't already, create an organization from your master account and invite or create member accounts.

Step 2 - Organize Accounts into OUs: Organize your accounts into OUs to simplify policy management. OUs allow you to group accounts with similar requirements or purposes, making it easier to apply SCPs consistently across your organization.

Step 3 - Create Service Control Policies: To create an SCP, navigate to the AWS Organizations console, select "Policies," and click "Create policy." Write your policy using the AWS Policy Language, specifying the permissions and restrictions you want to enforce for your security baseline.

Step 4 - Attach SCPs to OUs or Accounts: Attach the SCPs to the appropriate OUs or accounts within your organization. Remember that SCPs can be inherited through the OU hierarchy, so be mindful of how you apply them.

Step 5 - Test and Validate: After attaching SCPs, test and validate the permissions in each account. Ensure that the policies are working as intended and that they effectively enforce your desired security baseline.

Step 6 - Monitor and Adjust: Regularly review your SCPs and adjust them as needed to maintain your security baselines. As your organization grows and your security requirements change, your SCPs should evolve to keep pace.

Best Practices for Using AWS SCPs

1. Use least privilege: When crafting SCPs, adhere to the principle of least privilege. Grant only the minimum permissions necessary for users and roles to perform their tasks.
2. Leverage AWS-managed SCPs: AWS provides several managed SCPs that you can use as a starting point, such as FullAWSAccess or ReadOnlyAccess.
3. Use policy conditions: Make use of policy conditions in SCPs to further restrict permissions based on factors like time, IP address, or resource tags.
4. Continuously monitor and audit: Use AWS CloudTrail and AWS Config to monitor and audit changes in your environment, helping to identify any deviations from your security baseline.
5. Regularly review and update: Periodically review your SCPs to ensure they remain relevant and up-to-date with your organization's security requirements.

The challenges SCP Creates When Troubleshooting IAM Permissions and how to solve them

Troubleshooting IAM permissions can be a daunting task when SCP comes into play. Here are some common challenges: 

Challenge 1: Understanding the Intersection of Policies

IAM policies, SCPs, and resource policies all play a part in defining permissions for a user. Understanding the intersection of these policies is critical for troubleshooting IAM permissions effectively. The evaluation logic for determining the final permissions can become increasingly complex when multiple policies overlap, making it challenging to pinpoint the exact source of an issue.

Tip: To overcome this challenge use Lightlytics to analyze the impact of SCP (Easily identify which SCP policies block permissions)

Challenge 2: Inherited Permissions and Delegated Administration

In an organization with multiple accounts, SCPs can be inherited from the parent Organizational Unit (OU) or the root. This can create challenges when troubleshooting IAM permissions, as it may not be immediately clear which SCP is affecting a particular permission. Furthermore, delegated administrators may not have the necessary permissions to modify the SCPs, making it difficult to troubleshoot issues.

Tip: Maintain a clear hierarchy for your AWS Organizations and OUs, along with proper documentation. This will help you quickly identify the source of inherited SCPs. In addition, ensure that delegated administrators have the necessary permissions to access and modify SCPs when needed.

Challenge 3: Lack of Visibility into Denied Actions

When an action is denied due to an SCP, AWS does not provide detailed error messages explaining the reason behind the denial. This can make it difficult for administrators to determine which specific SCP is causing the issue.

Tip: Use Lightlytics to see the effect of each SCP on any resource as well as see the specific actions that are failing for each identity.

Challenge 4: Frequent Policy Changes

In fast-paced environments, policies can be updated frequently, making it difficult to keep track of changes and their impact on user permissions. If an issue arises, it can be challenging to identify the specific policy change that caused it.

Tip: Use Lightlytics to track all SCP changes and their impact on the resources in your Organizational Units. You can compare the current version of configuration with previous versions and dive into the who, the what and the how with a couple of clicks.

Practical Examples of AWS Service Control Policies and When to Use Them

These practical examples of AWS Service Control Policies demonstrate how to use SCPs to manage permissions and maintain security baselines across your AWS accounts effectively. By understanding the scenarios in which SCPs are most useful, you can tailor them to your organization's specific needs and ensure the security and compliance of your AWS infrastructure. As your organization evolves, remember to review and update your SCPs to keep pace with changing requirements.

1. Deny Access to Specific Services

You might want to prevent certain accounts from accessing specific AWS services, either for security reasons or to avoid unnecessary costs. The following SCP denies access to Amazon EC2 and Amazon RDS for the accounts it is attached to:

{
 "Version": "2012-10-17",
 "Statement": [
   {
     "Effect": "Deny",
     "Action": [
       "ec2:*",
       "rds:*"
     ],
     "Resource": "*"
   }
 ]
}

2. Restrict Access to Specific Regions

To ensure that your data stays within specific geographic regions or the use of specific regions that your org uses, you can use an SCP to limit access to AWS services within those regions only. This example allows access to AWS services only in the us-west-2 and us-east-1 regions:

{
 "Version": "2012-10-17",
 "Statement": [
   {
     "Effect": "Deny",
     "Action": "*",
     "Resource": "*",
     "Condition": {
       "StringNotEquals": {
         "aws:RequestedRegion": [
           "us-west-2",
           "us-east-1"
         ]
       }
     }
   }
 ]
}

3. Limit IAM Policy Changes

To prevent users from modifying IAM policies that grant higher privileges than necessary, you can use an SCP to restrict IAM actions. The following policy denies actions related to IAM policy management:

{
 "Version": "2012-10-17",
 "Statement": [
   {
     "Effect": "Deny",
     "Action": [
       "iam:CreatePolicy",
       "iam:CreatePolicyVersion",
       "iam:DeletePolicy",
       "iam:DeletePolicyVersion",
       "iam:AttachPolicy",
       "iam:DetachPolicy"
     ],
     "Resource": "*"
   }
 ]
}

4. Enforcing Tagging on Resources

To ensure that resources are consistently tagged and can be easily tracked, you can use an SCP to require specific tags on resources. This example enforces the presence of a Project tag for creating Amazon EC2 instances:

{
 "Version": "2012-10-17",
 "Statement": [
   {
     "Effect": "Deny",
     "Action": "ec2:RunInstances",
     "Resource": "arn:aws:ec2:*:*:instance/*",
     "Condition": {
       "Null": {
         "aws:RequestTag/Project": "true"
       }
     }
   }
 ]
}

5. Restricting Instance Types

You can use SCPs to restrict the types of instances that can be launched in specific accounts or OUs, ensuring cost control and compliance with your organization's policies. The following SCP allows only t2.micro and t2.small instance types:

{
 "Version": "2012-10-17",
 "Statement": [
   {
     "Effect": "Deny",
     "Action": "ec2:RunInstances",
     "Resource": "arn:aws:ec2:*:*:instance/*",
     "Condition": {
       "StringNotEquals": {
         "ec2:InstanceType": ["t2.micro","t2.small"]}}}]}

6. Preventing Public Access to Amazon S3 Buckets

To protect sensitive data, you may want to prevent the creation of public S3 buckets. The following SCP denies the creation of S3 buckets with public read or write permissions:

{
 "Version": "2012-10-17",
 "Statement": [
   {
     "Effect": "Deny",
     "Action": "s3:CreateBucket",
     "Resource": "*",
     "Condition": {
       "AnyPrincipal": {
         "aws:PrincipalIsPublic": "true"
       }
     }
   },
   {
     "Effect": "Deny",
     "Action": "s3:PutBucketAcl",
     "Resource": "arn:aws:s3:::*",
     "Condition": {
       "AnyPrincipal": {
         "aws:PrincipalIsPublic": "true"
       }
     }
   }
 ]
}

7. Restricting Access to Amazon RDS Based on IP, VPC, and Tag Conditions

In this example, we'll create an SCP that restricts data access to specific Amazon RDS instances based on IP address, VPC, and resource tags. This SCP ensures that only RDS instances within a particular VPC, tagged with a specific project name, can be accessed by users connecting from a designated IP address range.

{
 "Version": "2012-10-17",
 "Statement": [
   {
     "Effect": "Deny",
     "Action": [
       "rds-data:ExecuteStatement",
       "rds-data:BatchExecuteStatement"
     ],
     "Resource": "arn:aws:rds:*:*:cluster:*",
     "Condition": {
       "StringNotEquals": {
         "aws:ResourceTag/Project": "example-project"
       },
       "ArnNotLike": {
         "aws:SourceArn": "arn:aws:ec2:*:*:vpc/vpc-12345678"
       },
       "NotIpAddress": {
         "aws:SourceIp": "192.0.2.0/24"
       }
     }
   }
 ]
}

Start a free trial today, and see how Lightlytics can help manage AWS SCPs at scale!