All articles in
Identity and Access Management
Service Control Policies (SCPs)
AWS Service Control Policy (SCP) is a limiting AWS policy, which limits the maximum permission for a particular AWS Account or multiple AWS accounts onboarded to AWS Organizations. Thus it can be used to create Security and Compliance Guardrails/preventative controls across multiple AWS accounts in an organization. SCPs are the fourth kind of AWS Policies that we are introducing in this course after IAM policies, Resource policies and Permission Boundaries. Unlike the other three policies which are applicable to identities (IAM policy, Permissions Boundary) and resources (Resource policy) within only a single AWS account, SCPs can be applied to multiple AWS accounts which are organized and managed using AWS Organizations.
Security Scenario
Are you a scenario-driven learner? Let’s walk-through a scenario below:
Company X has 1000 AWS accounts (size is pretty common for most medium-large tier software organizations today). Oleg, the Security Engineer, wants to create a preventative security policy or security guardrail to protect the company’s AWS accounts from using insecure third-party Compute images. So Oleg creates the below AWS policy to enforce the use of only Security-approved images (from account – secure-images-aws-account) by requiring that all EC2 instances launched in the account must use AMIs owned by that same account. This prevents principals in the account from leveraging any unauthorized third-party images.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "GuardrailAgainstThirdPartyImages",
"Action": [
"ec2:RunInstances"
],
"Effect": "Deny",
"Resource": "arn:aws:ec2:*::image/ami-*",
"Condition": {
"StringNotEquals": {
"ec2:Owner": [
"secure-images-aws-account"
]
}
}
]
}
Where and how would you apply the policy
With the policy created, the only question Oleg has is how to apply the policy so it’s applicable to all the 1000 Company-owned AWS accounts. If Oleg did not have the option of using SCP, the answer to this question would require some pretty heavy automation. Why? Because without SCP, the best option for Oleg would be to use Permissions Boundary for this policy, but it is only applicable to an identity within a single account. So the Permissions Boundary would need to be applied to each identity in each of the 1000 AWS accounts, plus automation should guarantee that any new identities also have the Permissions Boundary attached. That is some serious automation!
SCPs for your rescue
Using SCPs, the job to apply multi-account security and compliance policies has become much simpler. As a prerequisite for SCP though, you need to have AWS Organizations setup and all of your AWS accounts onboarded to it, take a look at our AWS Organizations article to learn more about this process. Once the Organization is setup, Oleg can either apply the above policy as a SCP to all the the accounts onboarded to Organization or to a subset depending on the organizational needs by setting up OUs like Environment (Prod, Dev, Test), Departments (Software, Security, HR), etc.
For our visual learners, here is a diagram showing the different layers at which the IAM, Resource, Permission Boundary and SCP policy operate:
Another important use of SCP
Apart from the multi-account implementation use case, there is another use case for SCPs that differentiates it from other AWS policies – it can be used to restrict access of the Root user. In all the AWS Security texts, we have read that the Root user is the super administrator whose privileges cannot be restricted, so it’s best to store its credentials in a vault and never use it for any daily activities. But SCPs present an opportunity to safeguard against any sensitive actions that you do not want even the Root user performing, if at all used in an emergency or (may know one ever sees this day but) if exposed to malicious parties. AWS SCP is the only AWS policy that can restrict Root user activity.
AWS Security Nerd Quiz
Q
Apart from SCP, there is an “exceptional” case of an AWS policy that is also able to restrict Root user activity. Do you know the policy?
Take a look at the AWS Resource policy article to learn about the exceptional case of KMS resource policy which can restrict Root user activity.
Video Demo
In this demo lab we would create our very first SCP to restrict running of EC2 instances using third-party AWS AMIs or images, and only allow the usage of AMIs from a particular AWS account. We will then test if the SCP is working as expected by trying to run an EC2 from the AWS console.