Establish permissions guardrails using data perimeters
Data perimeter guardrails are meant to serve as always-on boundaries to help protect your data across a broad set of AWS accounts and resources. Data perimeters follow IAM security best practices to establish permissions guardrails across multiple accounts. These organization-wide permissions guardrails do not replace your existing fine-grained access controls. Instead, they work as coarse-grained access controls that help improve your security strategy by ensuring users, roles, and resources adhere to a set of defined security standards.
A data perimeter is set of permission guardrails in your AWS environment which help ensure that only your trusted identities are accessing trusted resources from expected networks.
-
Trusted identities: Principals (IAM roles or users) in your AWS accounts and AWS services acting on your behalf.
-
Trusted resources: Resources owned by your AWS accounts or by AWS services acting on your behalf.
-
Expected networks: Your on-premises data centers and virtual private clouds (VPCs), or networks of AWS services acting on your behalf.
Note
In some cases, you may need to extend your data perimeter to also include access by your trusted business partners. You should consider all intended data access patterns when you create a definition of trusted identities, trusted resources, and expected networks specific to your company and your use of AWS services.
Data perimeter controls should be treated as any other security control within the information security and risk management program. This means that you should perform a threat analysis to identify potential risks within your cloud environment, and then, based on your own risk acceptance criteria, select and implement appropriated data perimeter controls. To better inform the iterative risk-based approach to data perimeter implementation, you need to understand what security risks and threat vectors are addressed by data perimeter controls as well as your security priorities.
Data perimeter controls
Data perimeter coarse-grained controls help you achieve six distinct security objectives across three data perimeters through the implementation of different combinations of Policy types and condition keys.
| Perimeter | Control objective | Using | Applied on | Global condition context keys |
|---|---|---|---|---|
Identity |
Only trusted identities can access my resources |
RCP |
Resources |
aws:PrincipalOrgID aws:PrincipalOrgPaths aws:PrincipalAccount aws:PrincipalIsAwsService aws:SourceOrgID aws:SourceOrgPath aws:SourceAccount |
Only trusted identities are allowed from my network |
VPC endpoint policy |
Network |
||
Resources |
Your identities can access only trusted resources |
SCP |
Identities |
aws:ResourceOrgID aws:ResourceOrgPaths aws:ResourceAccount |
Only trusted resources can be accessed from your network |
VPC endpoint policy |
Network |
||
Network |
Your identities can access resources only from expected networks |
SCP |
Identities |
aws:SourceIp aws:SourceVpc aws:SourceVpce aws:ViaAWSService aws:PrincipalIsAwsService |
Your resources can only be accessed from expected networks |
RCP |
Resources |
You can think of data perimeters as creating a firm boundary around your data to prevent unintended access patterns. Although data perimeters can prevent 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 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 RCPs and resource-based policies, see Resource control policies (RCPs) and AWS services that work with IAM.
Identity perimeter
An identity perimeter is a set of coarse-grained preventative access controls that help ensure only trusted identities can access your resources and only trusted identities are allowed from your network. Trusted identities include principals (roles or users) in your AWS accounts and AWS services acting on your behalf. All other identities are considered untrusted and are prevented by the identity perimeter unless an explicit exception is granted.
The following global condition keys help enforce identity perimeter controls. Use these keys in resource control policies to restrict access to resources, or in VPC endpoint policies to restrict access to your networks.
-
aws:PrincipalOrgID – You can use this condition key to ensure that IAM principals making the request belong to the specified organization in AWS Organizations.
-
aws:PrincipalOrgPaths – You can use this condition key to ensure that the IAM user , IAM role, federated user, or AAWS account root user making the request belong to the specified organizational unit (OU) in AWS Organizations.
-
aws:PrincipalAccount – You can use this condition key to ensure resources can only be accessed by the principal account that you specify in the policy.
-
aws:PrincipalIsAWSService and aws:SourceOrgID (alternatately aws:SourceOrgPaths and aws:SourceAccount) – You can use these condition key to ensure that when AWS service principals access your resources, they do it only on behalf of a resource in the specified organization, organizational unit, or an account in AWS Organizations.
For more information, see Establishing a data perimeter on AWS: Allow only trusted identities to access
company data
Resource perimeter
A resource perimeter is a set of coarse-grained preventative access controls that help ensure your identities can access only trusted resources and only trusted resources can be accessed from your network. Trusted resources include resources owned by your AWS accounts or by AWS services acting on your behalf.
The following global condition keys help enforce resource perimeter controls. Use these keys in Service control policies (SCPs) to restrict which which resources can be accessed by your identities, or in VPC endpoint policies to restrict which resources can be accessed from your networks.
-
aws:ResourceOrgID – You can use this condition key to ensure the resource that is being accessed belongs to the specified organization in AWS Organizations.
-
aws:ResourceOrgPaths – You can use this condition key to ensure the resource that is being accessed belongs to the specified organizational unit(OU) in AWS Organizations.
-
aws:ResourceAccount – You can use this condition key to ensure the resource that is being accessed belongs to the specified account in AWS Organizations.
In some cases, you may need to permit access to AWS owned resources, resources that
do not belong to your organization and that are accessed by your principals or by AWS
services acting on your behalf. For more information about these scenarios, see Establishing a data perimeter on AWS: Allow only trusted resources from my
organization
Network perimeter
A network perimeter is a set of coarse-grained preventative access controls that help ensure your identities can access resources only from expected networks and your resources can only be accessed from expected networks. Expected networks include your on-premises data centers and virtual private clouds (VPCs) and networks of AWS services acting on your behalf.
The following global condition keys help enforce network perimeter controls. Use these keys in service control policies (SCPs) to restrict networks your identities can communicate from, or in resource control policies (RCPs) to constrain resource access to expected networks.
-
aws:SourceIp – You can use this condition key to ensure the requester's IP address is within a specified IP range.
-
aws:SourceVpc – You can use this condition key to ensure the VPC endpoint the request travels through belongs to the specified VPC.
-
aws:SourceVpce – You can use this condition key to ensure the request travels through the specified VPC endpoint.
-
aws:ViaAWSService – You can use this condition key to ensure that AWS services can make requests on behalf of your principal using Forward access sessions (FAS).
-
aws:PrincipalIsAWSService – You can use this condition key to ensure that AWS services can access your resources using AWS service principals.
There are additional scenarios where you need to permit access to AWS services that
access your resources from outside your network. For more information, see Establishing a data perimeter on AWS: Allow access to company data only from
expected networks
Resources to learn more about data perimeters
The following resources can help you learn more about data perimeters across AWS.
-
Data perimeters on AWS
– Learn about data perimeters and their benefits and use cases. -
Blog Post Series: Establishing a Data Perimeter on AWS
– These blog posts cover prescriptive guidance about establishing your data perimeter at scale, including key security and implementation considerations. -
Data perimeter policy examples
– This GitHub repository contains example policies that cover some common patterns to help you implement a data perimeter on AWS. -
Data perimeter helper
– This tool helps you design and anticipate the impact of your data perimeter controls by analyzing access activity in your AWS CloudTrail logs. -
Whitepaper: Building a Data Perimeter on AWS – This paper outlines the best practices and available services for creating a perimeter around your identities, resources, and networks in AWS.
-
Webinar: Building a data perimeter in AWS
– Learn where and how to implement data perimeter controls based on different risk scenarios.
