AWS Security Blog
Establishing a data perimeter on AWS: Allow only trusted identities to access company data
November 13, 2024: This post has been updated with guidance on how to use resource control policies (RCPs) and the
aws:SourceOrgIDcondition key to establish your organization’s identity perimeter.
As described in an earlier blog post, Establishing a data perimeter on AWS, Amazon Web Services (AWS) offers a set of capabilities you can use to implement a data perimeter to help prevent unintended access. One type of unintended access that companies want to prevent is access to corporate data by users who do not belong to the company. A combination of AWS Identity and Access Management (AWS IAM) features and capabilities that can help you achieve this goal in AWS while fostering innovation and agility form the identity perimeter. In this blog post, I will provide an overview of some of the security risks the identity perimeter is designed to address, policy examples, and implementation guidance for establishing the perimeter.
The identity perimeter is a set of coarse-grained preventative controls that help achieve the following objectives:
- Only trusted identities can access my resources
- Only trusted identities are allowed from my network
Trusted identities encompass IAM principals that belong to your company, which is typically represented by an AWS Organizations organization. In AWS, an IAM principal is a person or application that can make a request for an action or operation on an AWS resource. There are also scenarios when AWS services perform actions on your behalf using identities that do not belong to your organization. You should consider both types of data access patterns when you create a definition of trusted identities that is specific to your company and your use of AWS services. All other identities are considered untrusted and should have no access except by explicit exception.
Security risks addressed by the identity perimeter
The identity perimeter helps address several security risks, including the following.
Unintended data disclosure due to misconfiguration. Some AWS services support resource-based IAM policies that you can use to grant principals (including principals outside of your organization) permissions to perform actions on the resources they are attached to. While this allows developers to configure resource-based policies based on their application requirements, you should ensure that access to untrusted identities is prohibited even if the developers grant broad access to your resources, such as Amazon Simple Storage Service (Amazon S3) buckets. Figure 1 illustrates examples of access patterns you would want to prevent—specifically, principals outside of your organization accessing your S3 bucket from a non-corporate AWS account, your on-premises network, or the internet.
Figure 1: Unintended access to your S3 bucket by identities outside of your organization
Unintended access through a cross-service confused deputy. Some AWS services support integrations in which the services access your resources by using their own identities. For example, when you create a flow log with an S3 bucket as the destination, VPC Flow Logs uses a service principal, delivery.logs.amazonaws.com, that does not belong to your organization to publish logs to Amazon S3. When you allow your developers to configure resource-based policies to grant access to AWS service principals, you should make sure that AWS services access your resources only when their requests originate from your organization. Figure 2 illustrates an example access pattern you would want to prevent—specifically, VPC Flow Logs accessing your S3 bucket on behalf of a flow log that belongs to someone else’s account.
Figure 2: Unintended access to your S3 bucket by a VPC Flow Log configured in a non-corporate AWS account
Unintended data disclosure through non-corporate credentials. Some AWS services, such as Amazon Elastic Compute Cloud (Amazon EC2) and AWS Lambda, let you run code using the IAM credentials of your choosing. Similar to on-premises environments where developers might have access to physical and virtual servers, there is a risk that the developers can bring personal IAM credentials to a corporate network and attempt to move company data to personal AWS resources. For example, Figure 3 illustrates unintended access patterns where identities outside of your AWS Organizations organization are used to transfer data from your on-premises networks or VPC to an S3 bucket in a non-corporate AWS account.
Figure 3: Unintended access from your networks by identities outside of your organization
Implementing the identity perimeter
Before you can implement the identity perimeter by using preventative controls, you need to have a way to evaluate whether a principal is trusted and do this evaluation effectively in a multi-account AWS environment. IAM policies allow you to control access based on whether the IAM principal belongs to a particular account or an organization, with the following IAM condition keys:
- The aws:PrincipalOrgID condition key gives you a succinct way to refer to all IAM principals that belong to a particular organization. There are similar condition keys, such as aws:PrincipalOrgPaths and aws:PrincipalAccount, that allow you to define different granularities of trust.
- The aws:PrincipalIsAWSService condition key gives you a way to refer to AWS service principals when those are used to access resources on your behalf.
- The aws:SourceOrgID condition key gives you a way to refer to the resources in a particular organization that can trigger a service to access another resource on your behalf. For example, when VPC Flow Logs publishes logs to an S3 bucket, this key is populated with the ID of the organization that owns the flow log. There are similar condition keys, such as aws:SourceOrgPaths and aws:SourceAccount, for more granular control over service access.
In the context of the identity perimeter, there are two primary IAM policy types that allow you to check whether the call to an AWS resource is made by a trusted identity:
- Resource control policies (RCPs) – AWS Organizations policies that can be used to centrally set the maximum available permissions for resources in your organization. RCPs can be attached to an AWS account, OU, or the root in AWS Organizations. See the AWS Organizations User Guide for the List of AWS services that support RCPs.
- VPC endpoint policies – An IAM resource-based policy that can be used to set the maximum available permissions for access through your network. VPC endpoint policies are attached to VPC endpoints. For a list of services that support VPC endpoints and VPC endpoint policies, see AWS services that integrate with AWS PrivateLink.
Using the global condition keys and the policy types just listed, you can now implement the identity perimeter. The following table illustrates the relationship between identity perimeter objectives and the AWS capabilities that you can use to achieve them.
| Data perimeter | Control objective | Implemented by using | Primary IAM capability |
|---|---|---|---|
| Identity | Only trusted identities can access my resources. | RCPs | aws:PrincipalOrgID aws:PrincipalIsAWSService aws:SourceOrgID |
| Only trusted identities are allowed from my network. | VPC endpoint policies | aws:PrincipalOrgID aws:PrincipalIsAWSService |
If you need to enforce identity perimeter controls on resources that are currently not supported by RCPs, you can use resource-based policies, which are policies that are attached to resources directly. For a list of services that support resource-based policies, see AWS services that work with IAM.
Let’s see how you can use these capabilities to mitigate the risk of unintended access to your data.
Only trusted identities can access my resources
RCPs allow you to centrally enforce access controls on resources in your organization, including identity perimeter controls for mitigating the risk of unintended data disclosure due to misconfiguration. RCPs also help centrally prevent unintended access to your resources in cross-service confused deputy scenarios. The following is an example of an RCP that limits S3 bucket access to only identities that belong to your organization and AWS services acting on your behalf. Make sure to replace <MY-ORG-ID> with your organization ID.
The Deny statements in the preceding policy have multiple condition keys where all conditions must resolve to true to invoke the Deny effect. This means that this policy will deny an S3 action unless it is performed by an IAM principal within your organization (StringNotEqualsIfExists with aws:PrincipalOrgID in the EnforceOrgIdentities statement) or a service principal that interacts with your resources on behalf of accounts that you own (StringNotEqualsIfExists with aws:SourceOrgID in the EnforceConfusedDeputyProtection statement). This policy applies the cross-service confused deputy protection only on service integrations that require the use of the aws:SourceAccount, aws:SourceOrgPaths, and aws:SourceOrgID condition keys. We use the Null condition operator with the aws:SourceAccount condition key so that the EnforceConfusedDeputyProtection statement only applies to requests that have the keys present in the request context. We use aws:SourceAccount instead of aws:SourceOrgID in the Null condition operator so that the control still applies if the request originates from an account that doesn’t belong to an organization. Remember that RCPs do not grant permissions. You need to explicitly grant access permissions with policies such as identity-based policies and resource-based policies.
There are AWS services that offer resources-based policies for granting cross-account access to resources but do not currently support RCPs. If you need to enforce identity perimeter controls on such resources, you can do so in resource-based policies. For example policies, see the data perimeter policy repository.
Some AWS resources allow sharing through the use of AWS Resource Access Manager (AWS RAM). When you create a resource share in AWS RAM, you should choose Allow sharing with principals in your organization only to help prevent access from untrusted identities. In addition to the primary capabilities for the identity perimeter, you should also use the ram:RequestedAllowsExternalPrincipals condition key in the AWS Organizations service control policies (SCPs) to specify that resource shares cannot be created or modified to allow sharing with untrusted identities. For an example SCP, see Example service control policies for AWS Organizations and AWS RAM in the AWS RAM User Guide.
Only trusted identities are allowed from my network
When you access AWS services from on-premises networks or VPCs, you can use public service endpoints or connect to supported AWS services by using VPC endpoints. VPC endpoints allow you to apply identity perimeter controls to mitigate the risk of unintended data disclosure through non-corporate credentials. The following is an example of a VPC endpoint policy that allows access to all actions but limits the access to trusted identities only. Replace <MY-ORG-ID> with your organization ID.
The preceding policy uses Allow statements to enforce the identity perimeter. This is an acceptable method to write the control because like RCPs and SCPs, VPC endpoint policies do not grant any permissions but define the maximum access allowed through the endpoint. Your developers will be using identity-based or resource-based policies to grant permissions required by their applications. We use two statements in this example policy to invoke the Allow effect in two scenarios: if an action is performed by an IAM principal that belongs to your organization (StringEquals with aws:PrincipalOrgID in the AllowRequestsByOrgsIdentities statement) or if an action is performed by a service principal (Bool with aws:PrincipalIsAWSService in the AllowRequestsByAWSServicePrincipals statement). We do not use IfExists in the end of the condition operators in this case, because we want the condition elements to evaluate to true only if the specified keys exist in the request.
It is important to note that in order to apply the VPC endpoint policies to requests originating from your on-premises environment, you need to configure private connectivity to AWS through AWS Direct Connect and/or AWS Site-to-Site VPN. Proper routing rules and DNS configurations will help you to ensure that traffic to AWS services is flowing through your VPC interface endpoints and is governed by the applied policies for supported services. You might also need to implement a mechanism to prevent cross-Region API requests from bypassing the identity perimeter controls within your network.
Extending your identity perimeter
There might be circumstances when you want to grant access to your resources to principals outside of your organization. For example, you might be hosting a dataset in an Amazon S3 bucket that is being accessed by your business partners from their own AWS accounts. In order to support this access pattern, configure the S3 bucket policy to grant access to your business partner identities and edit your identity perimeter policy to include these identities in your perimeter definition. You can use the aws:PrincipalAccount condition key to include third-party account identities as trusted identities in an RCP for direct access to your resources. If a partner configures an AWS service to access your resources, you can use the aws:SourceAccount condition key to permit that access through your perimeter. This is shown in the following RCP example. Replace <MY-ORG-ID>, <THIRD-PARTY-ACCOUNT-A>, and <THIRD-PARTY-ACCOUNT-B> with your information.
The preceding policy adds the aws:PrincipalAccount condition key to the StringNotEqualsIfExists operator in the EnforceOrgIdentities. You now have the EnforceOrgIdentities statement with three condition keys where all three conditions must resolve to true to invoke the Deny effect. Therefore, this statement denies an S3 action unless it is performed by an IAM principal that belongs to your organization (StringNotEqualsIfExists with aws:PrincipalOrgID), by an IAM principal that belongs to specified third-party accounts (StringNotEqualsIfExists with aws:PrincipalAccount), or a service principal (BoolIfExists with aws:PrincipalIsAWSService). We also added the aws:SourceAccount condition key to the StringNotEqualsIfExists operator in the EnforceConfusedDeputyProtection statement so that it denies calls by AWS service principals unless they originate from your organization or from one of the trusted partner accounts.
There might also be circumstances when you want to grant access from your networks to identities external to your organization. For example, your applications could be uploading or downloading objects to or from a third-party S3 bucket by using third-party generated presigned Amazon S3 URLs. The principal that generates the presigned URL will belong to the third-party AWS account. Similar to the previously discussed RCP, you can extend your identity perimeter to include identities that belong to trusted third-party accounts by using the aws:PrincipalAccount condition key.
Additionally, some AWS services make unauthenticated requests to AWS owned resources through your VPC endpoint. An example of such a pattern is Kernel Live Patching on Amazon Linux 2, which allows you to apply security vulnerability and critical bug patches to a running Linux kernel. Amazon EC2 makes an unauthenticated call to Amazon S3 to download packages from Amazon Linux repositories hosted on Amazon EC2 service-owned S3 buckets. To include this access pattern into your identity perimeter definition, you can choose to allow unauthenticated API calls to AWS owned resources in the VPC endpoint policies.
The following example VPC endpoint policy demonstrates how to extend your identity perimeter to include access to Amazon Linux repositories and to Amazon S3 buckets owned by a third-party. Replace <MY-ORG-ID>, <REGION>, <ACTION>, <THIRD-PARTY-ACCOUNT-A>, and <THIRD-PARTY-BUCKET-ARN> with your information.
The preceding example adds two new statements to the VPC endpoint policy. The AllowUnauthenticatedRequestsToAWSResources statement allows the s3:GetObject action on buckets that host Amazon Linux repositories. The AllowRequestsByThirdPartyIdentitiesToThirdPartyResources statement allows actions on resources owned by a third-party entity by principals that belong to the third-party account (StringEquals with aws:PrincipalAccount).
Note that identity perimeter controls do not eliminate the need for additional network protections, such as making sure that your private EC2 instances or databases are not inadvertently exposed to the internet due to overly permissive security groups.
Detecting potential misconfigurations or unintended access
Apart from preventative controls established by the identity perimeter, we also recommend that you configure AWS Identity and Access Management Access Analyzer. IAM Access Analyzer helps you identify unintended access to your resources and data by monitoring policies applied to supported resources. You can review IAM Access Analyzer findings to identify resources that are shared with principals that do not belong to your AWS Organizations organization. You can also use IAM Access Analyzer findings to validate whether your RCPs help prevent unintended access regardless of the resource-based policies applied, and prioritize the remediation of overly permissive policies accordingly.
You should also consider enabling Amazon GuardDuty to detect misconfigurations or anomalous access to your resources that could lead to unintended disclosure of your data. GuardDuty uses threat intelligence, machine learning, and anomaly detection to analyze data from various sources in your AWS accounts. You can review GuardDuty findings to identify unexpected or potentially malicious activity in your AWS environment, such as an IAM principal with no previous history invoking an S3 API.
Additionally, you should consider monitoring management, data, and network activity events in AWS CloudTrail for signs of unintended use of your resources and networks. For tips on how to continuously monitor your controls with AWS CloudTrail and verify that they operate as expected, see the blog post Establishing a data perimeter on AWS: Analyze your account activity to evaluate impact and refine controls.
IAM policy samples
This GitHub repository contains policy examples that illustrate how to implement identity perimeter controls for a variety of AWS services and actions. The policy samples do not represent a complete list of valid data access patterns and are for reference purposes only. They are intended for you to tailor and extend to suit the needs of your environment. Make sure that you thoroughly test the provided example policies before you implement them in your production environment.
Deploying the identity perimeter at scale
As discussed earlier, you implement the identity perimeter as coarse-grained preventative controls. These controls typically need to be implemented for each VPC by using VPC endpoint policies and on resources that support cross-account access by using RCPs. The effectiveness of these controls relies on their ability to scale with the environment and to adapt to its dynamic nature.
The methodology you use to deploy identity perimeter controls will depend on the deployment mechanisms you use to create and manage AWS accounts. For example, you might choose to use AWS Control Tower and the Customizations for AWS Control Tower solution (CfCT) to govern your AWS environment at scale. To streamline implementation of identity perimeter controls in RCPs, you can use a set of data perimeter elective controls within the AWS Control Tower controls library. You can also use CfCT or your custom CI/CD pipeline to deploy VPC endpoint policies and RCPs that include your identity perimeter controls.
For resource types that are not supported by RCPs, you might need to implement automation to enforce identity perimeter controls when those resources are created or their policies are changed. One option is to use custom AWS Config rules. Alternatively, you can choose to enforce resource deployment through AWS Service Catalog or a CI/CD pipeline. With the AWS Service Catalog approach, you can have identity perimeter controls built into the centrally controlled products that are made available to developers to deploy within their accounts. With the CI/CD pipeline approach, the pipeline can have built-in compliance checks that enforce identity perimeter controls during the deployment. If you are deploying resources with your CI/CD pipeline by using AWS CloudFormation, see the blog post Proactively keep resources secure and compliant with AWS CloudFormation Hooks.
Regardless of the deployment tools you select, identity perimeter controls, along with other baseline security controls applicable to your multi-account environment, should be included in your account provisioning process. You should also audit your identity perimeter configurations periodically and upon changes in your organization, which could lead to modifications in your identity perimeter controls (for example, disabling a third-party integration). Keeping your identity perimeter controls up to date will help ensure that they are consistently enforced and help prevent unintended access during the entire account lifecycle.
Conclusion
In this blog post, you learned about the foundational elements that are needed to define and implement the identity perimeter, including sample policies that you can use to start defining guardrails that are applicable to your environment and control objectives.
Following are additional resources that will help you further explore the identity perimeter topic, including a whitepaper and a hands-on-workshop.
- Data perimeters on AWS
- Establishing a data perimeter on AWS blog post series
- Data Perimeter (hands-on workshop)
- An easier way to control access to AWS resources by using the AWS organization of IAM principals (blog)
If you have any questions, comments, or concerns, contact AWS Support or browse AWS re:Post. If you have feedback about this post, submit comments in the Comments section below.