In November last year, AWS introduced resource control policies, “a new authorization policy managed in AWS Organizations that can be used to set the maximum available permissions on resources within your entire organization.” Their announcement blog article included an example which clearly demonstrates a security improvement for Veeam customers storing their backup data in Amazon S3. I want to highlight this new feature and how it can help improve your security posture for your backups, a topic I am always happy to write about.
A primer on policies
Before we go into resource control policies, we first need to establish the types of policies there are in AWS and what they’re used for.
In general, there are two types of policies in AWS: identity-based policies and resource-based policies. As the names indicate, identity-based policies apply to IAM users, groups, and roles that perform actions within AWS accounts, whether it be a human user or a service. Resource-based policies apply to resources, and these policies control what actions can be performed on certain types of AWS resources that can be used or accessed outside of AWS and, thus, outside the control of any AWS identity.
A prime example would be an S3 bucket that stores images for your website. While the images are publicly accessible so they can be served to any visitor browsing your website, you wouldn’t want the images or the bucket they sit in to be writable for everyone. This seems obvious, and it seems obviously avoidable, but as workflows have become more flexible with how content is stored and served, the security controls governing access have likewise increased in complexity such that avoidable errors are unfortunately committed. It might not be your intention to make an S3 bucket or its contents publicly accessible, but with enough layers of abstraction between the order (“Please set up an S3 bucket for my team to use to store our backups”) and the fulfillment (“Here is an S3 bucket”), bad things can happen.
That is why, in AWS, service control policies and resource control policies are your best friend.
Guardrails for your policies
Building on the example above, let’s say you request an S3 bucket from your IT team, and a bucket is created with improper security policy attached, allowing anyone to access the bucket. With the use of a resource control policy, which is applied at the org or OU level in AWS Organizations, you could deny anyone outside of your AWS organization from accessing the bucket or its contents even if the bucket policy would indicate otherwise. That is because resource control policies are evaluated before the resource policy itself—a deny at any point in the evaluation chain yields a deny to the request. This would keep the bucket and its contents safe even if a configuration error occurred downstream at the account or resource level. These are the kinds of features that help you sleep soundly at night!
So, resource control policies, or RCPs, act as guardrails for your resource permissions. Similarly, service control policies, or SCPs (which I will not cover in this article), allow you to place guardrails around the actions that identities within your AWS environment can take, preventing undesirable and insecure configurations. You can read more about the differences between these policies in the documentation for AWS Organizations.
“How about no!” - Dr. Evil
The AWS announcement blog article I linked at the start provides a great example for how to configure exactly what I described in the previous section: preventing access to your S3 buckets for anyone outside your AWS organization. As SCPs and RCPs should be considered coarse-grained permissions, you will still need to configure your resource policies and IAM policies carefully to avoid any unintended access or unauthorized actions within your AWS organization. That said, using SCPs and RCPs can greatly improve your security posture and governance at scale, giving you peace of mind and the power to systematically say what Dr. Evil says so well: “how about no!”