As an AWS developer, I’ve witnessed firsthand the difficulties that come with managing access and permissions for multiple AWS accounts within an organization. Ensuring compliance and security can quickly become overwhelming with various teams member accounts and projects requiring varying access levels. AWS Service Control Policies (SCPs) come into play here.
That’s where AWS Service Control Policies (SCPs) come in, providing a way to centralize access management and enforce security policies across multiple AWS accounts. In this guide, we’ll explore SCPs in-depth, using personal anecdotes and practical examples to help you understand how to implement SCPs effectively in your organization.
In this 2023 guide, we’ll go over AWS Service Control Policies and how they work. We’ll look at the advantages of using SCPs, as well as the drawbacks and potential pitfalls. Using personal anecdotes and practical examples, we’ll walk you through the process of implementing SCPs in your organization to improve security, streamline access management, and reduce administrative headaches.
What are AWS SCPs?
As an AWS developer, I’ve frequently encountered situations where managing access and permissions for multiple AWS accounts within an organization becomes complicated and time-consuming. AWS SCP provides a solution to this problem by allowing organizations to centralize permission management across multiple accounts.
Fortunately, we discovered AWS Service Control Policies, which allowed us to centralize permission management across all accounts in our organization. With SCPs, we created policies that limited the actions that users, groups, or roles within each account could take, ensuring that all accounts followed the same security protocols.
So, what is an AWS Service Control Policy exactly? AWS SCP is a collection of permissions that can be applied at the root level of an AWS account or an Organizational Unit (OU) within an AWS Organization. These policies serve as guardrails for the accounts in the member account or OU, limiting the actions that users, groups, or roles within the account can take.
One particularly useful feature of SCPs was their ability to limit access to certain services or APIs. For example, we could restrict access to sensitive services like AWS Key Management Service (KMS) and enforce multi-factor authentication for specific actions. This added layer of security was crucial in ensuring that only authorized users had access to sensitive data.
Why Should You Use AWS SCPs?
As an organization grows, managing different teams and workloads using AWS accounts becomes necessary. While AWS Identity and Access Management (IAM) allows for control over user roles within AWS organizations, managing permissions can become difficult when dealing with multiple users across multiple AWS accounts. This is where Service Control Policies (SCPs) come in.
A Service Control Policy is crucial for enabling security and overruling permissions set on IAM resources. In addition, they provide the ability to create and enforce security and compliance policies across multiple AWS accounts. For example, SCPs can be used to restrict access to sensitive data to authorized personnel or limit the creation of certain resources that may pose security risks.
In my personal experience, using SCPs has significantly streamlined permission management and improved the security of our AWS infrastructure. With SCPs in place, we have greater control over our AWS accounts, ensuring that only authorized actions are taken and that our resources are protected from accidental or intentional misuse.
How to Create and Activate an AWS SCP?
Create an AWS Organization
Before you can start utilizing AWS Service Control Policies (SCPs), the first step is to create an AWS Organization. This will allow you to configure and delegate SCPs to your various users or roles. In the AWS Console, you can see the organizational structure of your AWS account and manage how your AWS accounts are structured using Organizational Units (OUs).
Here is an example of a representative OU structure for an FSI banking customer:
Here’s how you can create an AWS Organization:
- Sign in to the AWS Management Console.
- Open the AWS Organizations console at https://console.aws.amazon.com/organizations/.
- Click “Create organization.”
- Choose either “Consolidated billing” or “All features,” depending on your needs.
- Follow the prompts to set up your organization.
To create a new AWS organization, you can use the following command in the AWS CLI:
| aws organizations create-organization –feature-set ALL |
Enable Service Control Policies in AWS organizations
By default, SCPs are deactivated when you create an AWS Organization. To enable SCPs, follow these steps:
- In the AWS Organizations console, select your root account.
- Choose the “Policies” tab.
- Click “Enable Service Control Policies.”
- After enabling SCPs, a default policy named FullAWSAccess will be automatically added to your organization. This policy provides full access to all operations on the AWS root of the organization, and all AWS accounts will inherit this policy. It’s crucial to keep in mind that without this policy, the account will be ineffective and won’t be able to perform any actions. Therefore, it’s important to pin this policy at the RootOU.
Create an AWS Service Control Policy
Now that SCPs are enabled, you can create your own custom SCPs. Here’s how to create an SCP:
- Open the AWS Organizations console and select your root account or an OU.
- Choose the “Policies” tab.
- Click “Create policy” and select “Service control policy.”
- Give your policy a name and description.
- In the policy editor, define the rules for your policy. You can use AWS Managed Policies or create your own custom policies.
To create a new AWS service control policy, you can use the following code:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"shield:*"
],
"Resource": "*"
}
]
}Activate and Attach a Service Control Policy
Once you’ve created your SCP, you’ll need to activate and attach it to your OUs or accounts. Here’s how to do it:
- In the AWS Organizations console, select the root account or an OU.
- Choose the “Policies” tab.
- Click on the SCP that you want to activate and attach.
- Choose the “Targets” tab and click “Add target.”
- Select the accounts or OUs that you want to apply the SCP to.
- Choose “Attach policy” and click “Review.”
- Review your changes and click “Create policy.”
- Once your policy is attached, it will instantly apply to your AWS accounts and OUs. Any IAM account will not be entitled to call any AWS Shield Action for all the AWS services available, meaning that they will adhere to the rules and restrictions set by your SCP.
Difference Between AWS SCP and IAM Policies
SCP policies may appear to be identical to IAM policies at first glance. Both have access control and adhere to principles such as the least privilege access system. However, their respective scopes and applications are vastly different. Here are some of the most significant differences between the two systems.
AWS SCP control policies are applied at the account level, and a user within a specific account can define an IO policy within the account root user’s SCP limits.
For example, here is a sample SCP policy that restricts access to Amazon EC2 actions:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyAccessToEC2Actions",
"Effect": "Deny",
"Action": "ec2:*",
"Resource": "*"
}
]
}This example shows how an SCP policy can explicitly restrict access to all EC2 actions. By applying this policy to multiple accounts within an AWS organization, users in those accounts will be prevented from performing EC2 actions.
On the other hand, IAM policies are applied at the user or group level and define permissions for individual users or groups within an account. The following is an example of an IAM user policy that grants access to Amazon S3 buckets:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": "arn:aws:s3:::examplebucket/*"
}
]
}In this example, the IAM policy grants permission to read and write objects in an S3 bucket named “examplebucket”. This policy can be applied to specific other users and roles or groups in an AWS account.
Overall, AWS SCPs and IAM policies are two distinct systems with distinct functions. SCPs are intended to provide centralized permissions management across multiple AWS accounts, whereas IAM policies are intended to provide granular permissions control within a single account.
Evaluating Actions in AWS
For AWS developers, understanding how actions are evaluated in AWS is critical for efficient security and access management. An action in AWS is evaluated against a set of policies to determine if it should be permitted or denied.
Two types of policies can be used to define and manage permissions together: IAM policies, which apply at the user or group level within an AWS account, and SCPs, which apply at the organizational level across multiple accounts.
The evaluation process is performed in real-time and checks policies in the order they are attached to a resource. AWS also provides extensive auditing capabilities to help monitor and troubleshoot the process.
Besides IAM policies and SCPs, AWS offers various tools like AWS Organizations, AWS RAM, AWS Security Hub, and AWS Control Tower to help manage security and access across resources. Administrators can establish a comprehensive security framework for their AWS environment by utilizing these tools together.
SCP Allow or Denial List
As an AWS developer, you must understand the distinction between allow and deny lists in SCPs. The default option is to use a deny list, which prohibits specific services and actions from being performed on accounts. You can, however, make an allow list by attaching a new allow policy and detaching the FullAWSAccess policy.
Allow lists, in my opinion, are more effective in situations where you only want to allow access to specific services and actions. It allows for more granular control and helps to reduce the risk of accidental or unauthorized access.
Deny lists, on the other hand, can be useful when you need to limit access to specific services or actions that pose a security risk. Again, it is critical to carefully consider the use case and select the best option for your organization.
Whether you use an allow or deny list, it’s critical to review and update your policies on a regular basis to ensure they meet your organization’s security and compliance requirements.
Examples of Service Control Policies at Work
As an AWS developer, you must understand how Service Control Policies (SCPs) work in practice. Here are some real-world examples of SCPs in action:
An SCP is a policy that prevents stopping an EC2 instance unless there has previously been an authentication issue. The following code is used to define this policy:
{
"Version": "2012-10-23",
"Statement": [
{
"Sid": "DonyStopsandTerminationsWhenMFAIsNotReady",
"Effect": "Deny",
"Action": [
"ec2:StopInstances",
"ec2:TerminateInstances"
],
"Resource": "*",
"Condition": {
"BoolIfExists": {
"aws:MultiFactorAuthPresent": "false"
}
}
}
]
}It’s crucial to keep in mind that it’s not feasible to test an SCP’s behavior in a specific mode. Furthermore, creating an SCP might restrict access to the underlying server service and its functions.
Another example of an SCP is a policy that aims to prevent a user from leaving an organization after a change in their account management. Additionally, this SCP prevents individuals from transferring account data to another organization with fewer restrictions than those enforced by the SCP.
Limitations of AWS SCPs
However, it’s worth noting that SCPs can also have some limitations. For instance, they can only restrict access to actions that are explicitly allowed by AWS Identity and Access Management (IAM) policies. Additionally, SCPs cannot grant permissions not already granted by IAM policies. So while SCPs can help ensure that best practices are followed, they are not a complete solution for security and compliance.
Final Thoughts
In conclusion, AWS Service Control Policies (SCPs) are an incredibly powerful tool for managing access and permissions across multiple AWS accounts within an organization. SCPs provide a centralized way to enforce security policies and streamline access management, making it easier for organizations to ensure compliance and security across all their AWS accounts.
As an AWS developer, I can confirm that AWS Service Control Policies (SCPs) are critical in maintaining a secure and well-organized infrastructure. By leveraging SCPs, I have established and enforced fine-grained permissions across all AWS accounts in an organization, guaranteeing that only authorized personnel can access sensitive resources.
While there are some potential drawbacks and pitfalls to using SCPs, such as the potential for unintended consequences if policies are not carefully crafted and tested, the benefits far outweigh the risks. By implementing SCPs in your organization, you can improve security, reduce administrative headaches, and ensure that all teams and projects have the necessary access while maintaining a secure environment.
Overall, AWS Service Control Policies are essential for any organization working with multiple AWS accounts. Proper planning and implementation can significantly improve your security posture and make it easier to manage access and permissions across your organization.
