AWS SCPs are a preventive type of guardrails or organization policy that you can use to manage permissions in your organization which offers central control over the maximum available permissions for all accounts in your organization. It help you to ensure your accounts stay within your organization’s access control guidelines.
SCPs are available only in an organization that has all features enabled. SCPs aren't available if your organization has enabled only the consolidated billing features.
By default AWS Organizations cascades a FullAWSAccess policy to every OU and account ( meaning that no particular boundary is applied). Organizations uses Deny List strategy, therefore, if you want to set a boundary on some permissions you need to add an explicit Deny List in whatever point of the hierarchy (root, OUs and individual accounts).
The FullAWSAccess policy looks like the following:
The FullAWSAccess can be removed, necessitating the use of an Allow List strategy.
This calls for the creation of SCPs to provide rights, which must then be attached to each account and every OU above it.
In order to better understand SCP evaluation and how it affects access control within your AWS business, we'll discuss AWS Service Control Policies (SCPs) in this post.
Usage of SCPs:
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:
Grant extra privileges to specific accounts that should not have access.
Limit access to authorized accounts which should have access.
How SCPs works?
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 image illustrates how AWS SCP works for Read-only permissions in AWS Organization.
How SCPs works?
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.
There are two ways to configure SCP:
Deny list is where actions are allowed by default. You configure the deny list to deny specific actions.
Allow list where actions are denied by default. You configure the allow list needs to allow specific actions.
When no explicit denial is specified, AWS will verify whether the AWS account is managed by AWS organizations service. In this case it will verify the presence of SCP documents and apply the following rule:
Configuring SCPsExample of SCPs:
The following example shows an IAM permission policy that allows the Identity to perform all Amazon DynamoDB actions (dynamodb:*) on the Books table in the 123456789012 account within the us-east-2 Region.
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)
AWS SCPs Best practices:
SCPs provide us with unrestricted flexibility in managing permissions on the AWS cloud. To mitigate security risks, it is important to follow the recommended best practices outlined below:
1. Use the least privilege principle
Grant users the minimum level of access required for them to perform their tasks. Avoid creating allow lists unless there is a compelling reason to do so. Our goal is to prevent SCPs from unintentionally granting unauthorized access and causing a data leak.
2. Limit access to sensitive data
Deny lists are crucial for protecting highly sensitive data. To ensure its security, we must identify the AWS services that have access to this data and create deny lists for all users who have unrestricted permissions to these services.
3. Set up IAM policies for all new users
Grant appropriate IAM policies to all users and roles to provide them with the necessary permissions. It's important to note that a new user without any defined IAM policies will have no access, even if we create SCPs (Service Control Policies) that allow all services and actions.
4. Update and review policies regularly
Review and update SCP policies regularly to ensure they remain appropriate and effective. This helps ensure that the policies align with your organization's security needs.
Limitations:
We are unable to use SCPs to external resources or third-party services; instead, we can only do so to resources located within an AWS account or on OUs.
It has a 5,120-byte character limit.
We can only attach up to 5 policies to any OUs.
Conclusions:
It is important to understand that while SCPs (Service Control Policies) provide an organization's authorization framework, they do not handle permissions for specific resources. Managing resource permissions requires the use of IAM (Identity and Access Management), another AWS service. Although both tools deal with permissions, they operate at different levels, so there will never be a situation where we prefer to use one over the other. To achieve the desired outcome, both services may need to be deployed simultaneously.
