Establishing a data perimeter on AWS: Overview

November 13, 2024: This post has been updated with guidance on how to use resource control policies (RCPs) and the aws:SourceOrgID condition key to establish your organization’s data perimeter.

November 23, 2022: This post had been updated to align with a related post: Establishing a data perimeter on AWS: Allow only trusted identities to access company data

For your sensitive data on AWS, you should implement security controls, including identity and access management, infrastructure security, and data protection. Amazon Web Services (AWS) recommends that you set up multiple accounts as your workloads grow to isolate applications and data that have specific security requirements. AWS tools can help you establish a data perimeter between your multiple accounts, while blocking unintended access from outside of your organization. Data perimeters on AWS span many different features and capabilities. Based on your security requirements, you should decide which capabilities are appropriate for your organization. In this first blog post on data perimeters, I discuss which AWS Identity and Access Management (IAM) features and capabilities you can use to establish a data perimeter on AWS. Subsequent posts will provide implementation guidance and IAM policy examples for establishing your identity, resource, and network data perimeters.

A data perimeter is a set of preventive controls that help ensure that only your trusted identities are accessing trusted resources from expected networks. These terms are defined as follows:

• Trusted identities – Principals (IAM roles or users) within your AWS accounts, or AWS services that are acting on your behalf
• Trusted resources – Resources that are owned by your AWS accounts, or by AWS services that are acting on your behalf
• Expected networks – Your on-premises data centers and virtual private clouds (VPCs), or networks of AWS services that are acting on your behalf

Data perimeter controls

You typically implement data perimeters as coarse-grained access controls that apply across a broad set of AWS accounts and resources. When you implement a data perimeter, consider the following six primary control objectives.

Note that the controls in the preceding table are coarse in nature and are meant to serve as always-on boundaries. You can think of data perimeters as creating a firm boundary around your data to help prevent unintended access patterns. Although data perimeters can mitigate broad unintended access, you still need to make fine-grained access control decisions. Establishing a data perimeter does not diminish the need to continuously fine-tune permissions by using tools such as IAM Access Analyzer as part of your journey to least privilege.

To implement the preceding control objectives on AWS, use three primary capabilities:

• Service control policies (SCPs) – AWS Organizations policies that you can use to establish the maximum available permissions for your principals (IAM roles or users) within your organization. SCPs help you ensure that your principals stay within your organization’s access control guidelines. In the context of data perimeters, use SCPs so your identities can only access trusted resources from expected networks.
• Resource control policies (RCPs) – AWS Organizations policies that can be used to establish the maximum available permissions for the resources in your organization. RCPs help you ensure that resources in your accounts stay within your organization’s access control guidelines. In the context of data perimeters, use RCPs so that your resources can be accessed only by trusted identities and from expected networks. See the AWS Organizations User Guide for the List of AWS services that support RCPs.
• VPC endpoint policies – Policies you attach to VPC endpoints to control which principals, actions, and resources can be accessed by using a VPC endpoint. In the context of data perimeters, use VPC endpoint policies to specify that your network can be used only by trusted identities to access only trusted resources. For a list of services that support VPC endpoints and VPC endpoint policies, see AWS services that integrate with AWS PrivateLink.

Let’s expand the previous table to include the corresponding policies you would use to implement the controls for each of the control objectives.

As you can see in the preceding table, the correct policy for each control objective depends on which resource you are trying to secure. RCPs can be used to filter access based on the calling principal and the network from which they are making a call. VPC endpoint policies are used to inspect the principal that is making the API call and the resource they are trying to access. SCPs are used to restrict your identities from accessing resources outside your control or from outside your network. Note that SCPs apply only to your principals within your AWS organization, whereas RCPs and VPC endpoint policies can be used to limit access to other principals.

If you need to enforce data perimeter controls on resources that are currently not supported by RCPs, you can use resource-based policies that are attached to resources directly. For a list of services that support resource-based policies, see AWS services that work with IAM.

The last components are the specific IAM controls or condition keys that enforce the control objective. For effective data perimeter controls, use the following primary IAM condition keys:

• aws:PrincipalOrgID – Use this condition key to restrict access to trusted identities, your principals (roles or users) that belong to your organization. In the context of a data perimeter, you will use this condition key with your RCPs and VPC endpoint policies.
• aws:SourceOrgID – Use this condition key in your RCPs to restrict access to the AWS services where requests originate in your organization. You will use this key in your RCPs to help prevent the cross-service confused deputy problem and further strengthen the perimeter around your resources.
• aws:ResourceOrgID – Use this condition key to restrict access to resources that belong to your AWS organization. To establish a data perimeter, use this condition key within SCPs and VPC endpoint policies.
• aws:SourceIp, aws:SourceVpc, aws:SourceVpce – Use these condition keys to restrict access to expected network locations, such as your corporate network or your VPCs. In the context of a data perimeter, use these keys within SCPs and RCPs.

We can now complete the table that we’ve been developing throughout this post.

For the identity perimeter, the primary condition key is aws:PrincipalOrgID, which you can use in RCPs and VPC endpoint policies so that only your identities are allowed access. Use aws:PrincipalIsAWSService to allow AWS services to access your resources or your networks by using their own identities—for example, AWS CloudTrail can use its service principal, cloudtrail.amazonaws.com, to write data to your bucket. Use aws:SourceOrgID to help ensure that when AWS service principals access your resources, they do it only on behalf of a resource in your organization—for example, a CloudTrail trail that belongs to one of your accounts.

For the resource perimeter, the primary condition key is aws:ResourceOrgID, which you can use in an SCP or VPC endpoint policy to allow your identities and network to access only the resources that belong to your AWS organization.

Last, for the network perimeter, use the aws:SourceIp, aws:SourceVpc, and aws:SourceVpce condition keys in SCPs and RCPs to make sure that your identities and resources are accessed only from your expected network. Use the aws:PrincipalIsAWSService and aws:ViaAWSService condition keys to allow AWS services to access your resources from outside your network locations. For example, CloudTrail can use this access to write data to one of your S3 buckets, or Amazon Athena can query data in your S3 buckets. For more information about using these keys as part of your data perimeter strategy, see the blog post IAM makes it easier for you to manage permissions for AWS services accessing your resources.

Conclusion

In this blog post, you learned the foundational elements that are needed to implement an identity, resource, and network perimeter on AWS, including the primary IAM capabilities that are used to implement each of the control objectives. See the follow-up posts in the Establishing a data perimeter on AWS blog post series, which will provide prescriptive guidance on establishing your identity, resource, and network perimeters.

The following are additional resources that will help you further explore the data perimeter topic, including a whitepaper and a hands-on workshop. We have also curated several blog posts related to the key IAM capabilities discussed in this post.

• Data perimeters on AWS webpage
• Establishing a data perimeter on AWS blog post series
• Building a Data Perimeter on AWS (whitepaper)
• Data Perimeter (hands-on workshop)
• Data perimeter sample policy repository
• How to control access to AWS resources based on AWS account, OU, or organization
• IAM makes it easier for you to manage permissions for AWS services accessing your resources
• Use scalable controls for AWS services accessing your resources

If you have any questions, comments, or concerns, contact AWS Support or start a new thread on the IAM forum. If you have feedback about this post, submit comments in the Comments section below.