Service Control Policies (SCPs) are a type of policy that you can use in AWS to manage permissions. SCPs offer central control over the maximum available permissions for all accounts in your organization, allowing you to ensure your accounts stay within your organization’s access control guidelines.
SCPs are a powerful tool in the AWS ecosystem, providing a layer of security that helps manage and control access at the account level. They are part of AWS Organizations, a service that allows you to centrally manage and govern your environment as you grow and scale your AWS resources.
Definition of Service Control Policies
Service Control Policies (SCPs) are a type of access control policy that you can use in AWS to manage permissions. They offer central control over the maximum available permissions for all accounts in your organization. SCPs are JSON policies that specify the maximum permissions for an organization or organizational unit (OU) in AWS Organizations.
SCPs are not standalone policies; instead, they are part of the permission guardrails that you establish for your AWS environment. They do not grant permissions but instead act as a filter for the permissions that are attached to IAM users, groups, and roles in the accounts within your organization.
Structure of Service Control Policies
Like other AWS policies, SCPs are written in JSON format. They consist of a series of statements, each of which includes an effect (either "Allow" or "Deny"), a list of actions (the AWS service actions that the policy controls), and a list of resources (the AWS resources that the actions can affect).
SCPs can also include condition keys, which provide further control over when the policy is in effect. For example, a condition key might specify that a policy is only in effect during certain times of day, or when requests are made from certain IP addresses.
Application of Service Control Policies
SCPs are applied to accounts within an organization or organizational unit (OU) in AWS Organizations. When you attach an SCP to an organization or OU, it affects all the accounts within that organization or OU. If an account belongs to multiple OUs, it is affected by the SCPs attached to each of those OUs.
It's important to note that SCPs do not grant permissions. Instead, they act as a filter for the permissions that are attached to IAM users, groups, and roles in the accounts within your organization. If a user, group, or role has a permission that is not explicitly denied by an SCP, they retain that permission.
History of Service Control Policies
Service Control Policies (SCPs) were introduced by AWS as part of AWS Organizations in 2017. AWS Organizations was designed to provide a way for businesses to manage and govern their AWS resources centrally, and SCPs were a key part of this functionality.
Since their introduction, SCPs have become a critical tool for businesses that need to manage complex AWS environments. They provide a way to enforce consistent access controls across an organization, regardless of the size or complexity of the AWS resources involved.
Evolution of Service Control Policies
Since their initial introduction, SCPs have evolved to become more flexible and powerful. AWS has added new features and capabilities to SCPs over time, including the ability to use condition keys in policy statements, and the ability to attach SCPs to individual AWS accounts in addition to organizations and OUs.
These enhancements have made SCPs an even more valuable tool for businesses that need to manage access to AWS resources. With these features, businesses can create more granular access controls, and can more easily manage access for individual accounts and resources.
Use Cases of Service Control Policies
Service Control Policies (SCPs) are used in a variety of scenarios to manage access to AWS resources. Some common use cases include enforcing consistent access controls across an organization, limiting the actions that users can perform on specific resources, and preventing users from accessing certain services entirely.
For example, an organization might use an SCP to prevent any of its AWS accounts from deleting Amazon S3 buckets. Or, it might use an SCP to deny access to certain AWS services during non-business hours. These are just a few examples of the many ways that SCPs can be used to manage access to AWS resources.
Enforcing Consistent Access Controls
One of the primary use cases for SCPs is to enforce consistent access controls across an organization. By attaching an SCP to an organization or OU, you can ensure that all accounts within that organization or OU adhere to the same access control policies.
This can be particularly useful in large organizations, where it can be difficult to manage access controls on a per-account basis. With SCPs, you can establish a set of baseline permissions that apply to all accounts, and then use other AWS access control mechanisms to grant additional permissions as needed.
Limiting Actions on Resources
SCPs can also be used to limit the actions that users can perform on specific AWS resources. For example, you might use an SCP to prevent users from deleting or modifying important resources, such as databases or storage buckets.
This can be a powerful way to protect critical resources from accidental or malicious changes. By using SCPs in this way, you can ensure that only authorized users are able to perform potentially destructive actions on your AWS resources.
Examples of Service Control Policies
Let's take a look at some specific examples of how SCPs can be used in practice. These examples will illustrate the flexibility and power of SCPs, and will show how they can be used to manage access to AWS resources in a variety of scenarios.
Remember, these are just examples. The actual policies that you create will depend on your specific needs and the structure of your AWS environment.
Example 1: Preventing Deletion of Amazon S3 Buckets
Suppose you want to prevent any of your AWS accounts from deleting Amazon S3 buckets. You could create an SCP with a statement that denies the "s3:DeleteBucket" action. This policy would then be attached to your organization or OU, and would apply to all accounts within that organization or OU.
The JSON for this SCP might look something like this:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "s3:DeleteBucket",
"Resource": "*"
}
]
}
Example 2: Denying Access to AWS Services During Non-Business Hours
Another example might be to deny access to certain AWS services during non-business hours. You could create an SCP with a statement that denies all actions on a specific service, and includes a condition key that specifies the time range during which the policy is in effect.
The JSON for this SCP might look something like this:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "ec2:*",
"Resource": "*",
"Condition": {
"TimeNotInRange": {
"aws:CurrentTime": ["00:00-08:00", "18:00-24:00"]
}
}
}
]
}
In this example, the policy denies all actions on EC2 instances between the hours of 6 PM and 8 AM.
Conclusion
Service Control Policies (SCPs) are a powerful tool for managing access to AWS resources. They provide a way to enforce consistent access controls across an organization, and can be used to limit the actions that users can perform on specific resources.
While SCPs can be complex, they offer a great deal of flexibility and control. By understanding how they work and how to use them effectively, you can ensure that your AWS resources are secure and that your users have the access they need to do their jobs effectively.