When you’re managing multiple AWS accounts, you need a way to control and restrict usage to for example unused AWS Services or AWS Regions.
A feature from AWS Organizations called AWS Service Control Policies (SCPs) allows you to create a set of rules to restrict or allow access to AWS resources on multiple accounts at once.
In this article, I’ll be sharing 3 AWS SCP examples that you can immediately apply to your own AWS Organization to improve the security of your AWS accounts.
By default, all actions are allowed within an AWS Organization. Therefore the AWS SCPs that we’re sharing here use the deny list strategy.
Note: make sure to review and test the AWS SCP examples before you proceed to activate them in a production account or Organizational Unit (OU).
Table of Contents
AWS SCP example 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"
}
]
}AWS SCP example 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"
}
]
}AWS SCP example 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
The AWS SCP examples provided in this article will help to better secure the multiple environments that you’re managing within your AWS Organization from a central point.
Using the deny list strategy to block access to specific AWS Services or regions, can have a huge impact on the teams and applications that are running on your AWS accounts.
Therefore it’s important to test a new AWS SCP on the development or test account before proceeding to activate the permission policy on production.
