Establish permissions guardrails using data perimeters - AWS Identity and Access Management
Data perimeter controlsIdentity perimeterResource perimeterNetwork perimeterResources to learn more about data perimeters

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:VpceAccount

aws:VpceOrgPaths

aws:VpceOrgID

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.

To enforce network perimeter controls, we recommend that you use aws:VpceOrgID, aws:VpceOrgPaths, and aws:VpceAccount only if all services you want to restrict access to are currently supported. Using these condition keys with unsupported services can lead to unintended authorization results. For a list of services that support the keys, see the AWS global condition context keys. If you need to enforce the controls on a wider range of services, consider using aws:SourceVpc and aws:SourceVpce instead.

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 usually 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 based on your definition of trusted identities. Use these keys in resource control policies to restrict access to resources, or in VPC endpoint policies to restrict access to your networks.

Identities owned by you

You can use the following condition keys to define IAM principals that you create and manage in your AWS accounts.

  • 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, AWS STS federated user principal, SAML federated principal, OIDC federated principal, or AWS 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.

Identities of AWS services acting on your behalf

You can use the following condition keys to allow AWS services to use their own identities to access your resources when they act on your behalf.

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 usually 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 based on your definition of trusted resources. Use these keys in Service control policies (SCPs) to restrict which resources can be accessed by your identities, or in VPC endpoint policies to restrict which resources can be accessed from your networks.

Resources owned by you

You can use the following condition keys to define AWS resources that you create and manage in your AWS accounts.

  • 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 AWS account.

Resources of AWS services acting on your behalf

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 usually 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 based on your definition of expected networks. 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.

Networks owned by you

You can use the following condition keys to define networks your employees and applications are expected to use to access your resources, such as your corporate IP CIDR range and your VPCs.

  • 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:VpceAccount – You can use this condition key to ensure requests come through VPC endpoints owned by the specified AWS account.

  • aws:VpceOrgPaths – You can use this condition key to ensure that IAM principals making the request belong to the specified organizational unit (OU) in AWS Organizations.

  • aws:VpceOrgID – You can use this condition key to ensure requests come through VPC endpoints owned by accounts in the specified organization in AWS Organizations.

aws:VpceAccount, aws:VpceOrgPaths, and aws:VpceOrgID are particularly useful for implementing network perimeter controls that scale automatically with your VPC endpoint usage, without requiring updates to policies when you create new endpoints. See the AWS global condition context keys for the list of AWS services that support these keys.

Networks of AWS services acting on your behalf

You can use the following condition keys to allow AWS services to access your resources from their networks when they act on your behalf.

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.