AWS SCP: Tutorials & Best Practices for MSPs

Access management plays a critical role in protecting your cloud resources. Constantly changing services, resources, and security policies can make it hard to track who accesses what and when in your cloud environment. AWS Service Control Policies (AWS SCPs) are a powerful tool within AWS Organizations to manage AWS resource access at scale centrally. You can ensure security and compliance by enforcing policies across multiple accounts and services. More importantly, you get granular control and can limit the actions specific users can perform on a particular resource in a specific account. No wonder AWS SCPs are popular with managed service providers (MSPs) around the globe.

Despite its advantages, AWS SCP has its limitations covered later in this article, most importantly its lack of hybrid and multi-cloud support – requiring MSPs to adopt cloud management platforms (CMP) to uncover inconsistent cloud security and governance policies across cloud providers. 

This article will discuss AWS SCPs in detail and learn how to configure them. We’ll also share the best practices and limitations of AWS SCPs. If you are comfortable using Identity and Access Management (IAM), we’ll also share the differences and similarities between IAM Permission Policies and SCPs.  But before we begin, let’s briefly overview AWS Organizations and how to set up this service.

What is AWS Organization?

AWS Organizations is a centralized governance tool for managing multiple AWS user accounts. MSPs use the service to ensure that their clients’ AWS accounts are being used cost-effectively and in compliance with the client’s security policies. For instance, MSPs can:

• Create and manage multiple AWS accounts centrally.
• Set up policies and permissions simultaneously for several accounts.
• Monitor and control usage across all accounts.
• Set up consolidated billing to a single payment method.

How to set up AWS Organization. 

Login to your AWS account and search for the service. Click it.

Click on Add an AWS account.

AWS allows you to either create a new account or invite an existing user.

Fill in the required details and click Create AWS account at the bottom of the page.

You should now have an organization under AWS accounts, as shown in the screenshot below.

Under your Organization, you can set up different accounts in a hierarchy described by Organization Units. You can define permissions at three levels:

1. Root level – applicable to all AWS accounts in your Organization
2. OU level – relevant to all AWS accounts within an Organization Unit
3. Member level – applicable only to the individual AWS account

Now that we’ve set up the Organization, let’s understand the concept of service control policies in detail before looking at how to configure them. 

What is AWS SCP?

Amazon takes a shared responsibility approach to cloud security. It provides a secure infrastructure to set up your cloud environment, but companies are responsible for protecting their cloud data and applications. Industry regulations like SOC 2, PCI DSS, and HIPAA have strict requirements for data access and control, and companies must develop rules (or policies) around resource access. They can use AWS Management and Governance services to enforce these policies across their AWS cloud. AWS SCP is one such service feature of the broader AWS Organizations service.

Within Organizations, you can think of policies as a configuration setting or service feature. They allow you to manage your AWS accounts more flexibly. Service Control Policy (SCP) is a special policy category called authorization policy.

SCPs offer administrators central control over the maximum possible permissions available for all AWS accounts. You use SCPs to restrict your administrators from doing two main things:

1. Grant extra privileges to specific accounts that should not have access.
2. Limit access to authorized accounts which should have access.

For example, let’s say all your managers have read-and-write access, but you want suspended managers to get read-only access. You can create a Suspended OU under your Managers Organization and define a Read-Only SCP at the OU level.

The difference between SCPs and IAM Permission Policies

AWS Identity and Access Management (IAM) is another popular service that lets companies centrally manage, analyze, and refine access permissions in the AWS cloud. This service enables you to define an AWS Identity that could be a specific user, role, or user group. You then create policies and attach them to your IAM identities or AWS resources. In developer speak, a policy is an object that defines the permissions associated with the AWS resource or Identity.

The following example shows an IAM permission policy that allows the Identity to perform all Amazon DynamoDB actions (dynamodb:*) on the Customers table in the 3456789034 account within the us-west-2 Region.

{
  "Version": "2023-2-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "dynamodb:*",
    "Resource": "arn:aws:dynamodb:us-west-2:3456789034:table/Customers"
  }
}

Organization SCPs are similar to IAM policies in the way you write and express them. They are also JSON objects like below: (Example from AWS docs-This SCP denies the user from making changes to Amazon Cloudwatch dashboards and alarms)

  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "cloudwatch:DeleteAlarms",
        "cloudwatch:DeleteDashboards",
        "cloudwatch:DisableAlarmActions",
        "cloudwatch:PutDashboard",
        "cloudwatch:PutMetricAlarm",
        "cloudwatch:SetAlarmState"
      ],
      "Resource": "*"
    }
  ]
}

The key difference is that an SCP never grants any type of permissions. Instead, an SCP only specifies the maximum allowable permissions for the associated accounts.

What happens when a particular account has both permissions and AWS SCPs associated with it? AWS evaluates the SCP first. So if:

• Both the IAM permission policy and SCP grant access to a particular action, the user can perform it.
• IAM permission policy grants access, but SCP denies access, then the user cannot perform the action.

How to configures AWS SCPs?

There are two ways to configure SCP. 

1. Deny list is where actions are allowed by default. You configure the deny list to deny specific actions.
2. Allow list where actions are denied by default. You configure the allow list needs to allow specific actions. 

For example, several database administrators from multiple departments have read-only access to your database. But you set up allow list SCPs that give them write access once they complete your internal data security training. Or there are business analysts with full access to your dashboards across multiple AWS services. But you set up Deny list SCPs to restrict their access to specific confidential databases. How exactly to do this is given below.

Login to your AWS Organization console

To create an SCP, login to your AWS Organization console. Click on Policies and choose Service control policies from the list, as shown in the screenshot below.

Check for default full access 

Under the Service control policies page, you should check for the default full access “FullAWSAccess” policy.

The “FullAWSAccess” policy looks like the following.

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

This gives administrators complete access to all the AWS services. To deny specific services, a deny list has to be created.

Create a new AWS SCP

We can now add deny rules to deny permissions explicitly. This could be done under the same default policy shown above or a new policy that could be created to deny permissions.

Let’s create a new policy to deny all permissions to EC2 autoscaling. Click on Create policy in the Service control policies window.

Add a policy name, description, and tag. Description and tag are optional.

Scroll down to the statement editor. There are three sections to creating a statement. Choose the following to create a statement to deny all permission to EC2 Autoscaling.

• Select EC2 Auto Scaling under Add actions. 
• Select All resources under Add a resource. 
• Add conditions that would trigger this policy

For example, this policy will only be applied to a specific administrator or a group.

Check the New AWS SCP

This is what the policy will look like

Apply the AWS SCP

Now that we have created a policy, we need to apply it to an organization or an OU. 

Select the new SCP from the policy list.

Click Attach under Targets

This will show you all the organizations and OU managed by you. Choose which organization or the OU to attach this policy. 

To detach, go back to the policy that needs to be detached. Please select the organization it needs to be detached from and click detach.

AWS SCPs best practices

SCPs grant limitless flexibility on how you manage permissions on the AWS cloud. Following the best practices given below will ensure that flexibility does not increase security risks. 

Use the least privilege principle

Grant the minimum level of access necessary for users to perform their tasks. Do not create allow lists unless there is a very good reason to do so. You want to make sure your SCPs do not inadvertently grant unauthorized access, resulting in a data leak.

Limit access to sensitive data

Deny lists are a must have for highly sensitive data. You will need to map the AWS services that access sensitive data and create Deny lists for all users with free permission to such services.

Set up IAM policies for all new users

You must grant permissions with appropriate IAM policies to all users and roles. A new user without any defined IAM policies has no access, even if you create SCPs for them that allows all services and all actions.

Update and review policies regularly

Review and update your SCP policies regularly to ensure they are still appropriate and effective. This helps ensure that your policies align with your organization’s security needs.

Do AWS SCPs have any limitations?

Like all technologies, AWS SCP has a few limitations. These should be kept in mind when configuring policies. 

Limited policy complexity

AWS SCP has a 5,120-byte character limit. You can only attach up to 5 policies to any organizational unit. It is also more challenging to create advanced access controls as you cannot develop policies with multiple conditions or logical operators.

Limited scope of control

AWS SCP only allows for the restriction or granting of specific actions on a resource rather than providing more granular control over those actions. Additionally, you can only apply the SCP to resources within an AWS account, not external resources or third-party services.

Enforcing governance policies consistently across data centers and multiple cloud providers requires MSPs to adopt a cloud management platform (CMP), such as the functionality provided by CloudBolt, to automate security and compliance measures and avoid manual configuration mistakes. 

Modern platforms such as CloudBolt also provide support for cloud cost management functionality in addition to security, governance, and regulatory compliance features – proactively offering recommendations to reduce operating costs and automating the configuration changes required to implement them – which effectively improve MSP profit margins.

Conclusion 

AWS SCP is one feature of AWS Organizations—a management and governance service for the AWS cloud. AWS Organizations lets you scale your cloud environment by centrally creating and managing multiple AWS accounts. AWS SCPs allow you to define limits on what actions those accounts can perform on your cloud resources.

It’s essential to understand that SCPs provide an authorization framework for an organization but do not control permissions to individual resources. You have to use another AWS service called IAM to manage permission for resources. You will never find a situation where you want to use one or the other because even though both these tools deal with permissions, they do so at different levels. You can deploy both services simultaneously to get the desired result.