AWS Security Blog
Transfer data across AWS partitions with IAM Roles Anywhere
Transfer across AWS Cloud partitions. Different identity planes. Long-lived IAM user credentials.
As an enterprise customer, you might need to bring together security, operational, and compliance data from multiple AWS partitions. Creating a holistic view of these types of data is critical to support operations and applications but understanding how to accomplish this while maintaining compliance can be a challenge.
In this post, we show you a past method for securing cross-partition data movement using AWS Identity and Access Management (IAM) user keys and why that’s no longer recommended. We continue by showing you the recommended best practice of using AWS IAM Roles Anywhere to support cross-partition data movement.
Security and compliance and AWS Regions and partitions
Before you begin, it’s important to understand how AWS Regions and partitions are designed. AWS partitions are hard boundaries designed to meet isolation requirements for compliance purposes and consist of one or more Regions, with each partition controlled by an independent instance of IAM. AWS provides multiple partitions; AWS Commercial Regions use an aws partition identifier within the Amazon Resource Name (ARN), AWS GovCloud Regions use an aws-us-gov partition identifier, and the AWS China Regions use an aws-cn partition identifier. AWS account IDs and Region designations are reserved to make sure that they exist only within that respective AWS partition. The IAM instance profile, within each AWS partition, prohibits the creation of trust policies that cross partitions. If you attempt to construct a cross-account trust policy across two partitions, they will receive a CREATE_FAILED error as shown in Figure 1. This isolation between partitions is part of the security that we provide our customers.
Figure 1: Failure message for cross partition trust policy
It’s critical that you understand your compliance requirements and build a unified dashboard and workflows in the appropriate partition. For example, data should only flow from the AWS Commercial partition to the AWS GovCloud partition—not the other way around. To adhere to the FedRAMP boundary policy FRR211, data about workloads within the AWS GovCloud partition should not be shared with AWS Commercial partition. Thus, it’s a best practice when you create a unified dashboard and automation to design the architecture and solution to operate within the AWS GovCloud partition. This approach enables a consolidated view of your security and cloud operations. From this centralized data plane, automated remediations, notifications, and escalations can be triggered by using Amazon EventBridge against data collected from Commercial and GovCloud Regional resources. These automated workflows can be used for operational triage within a ticketing system (such as Service Now or Atlassian JIRA), security detections within a cloud-native application protection platform (CNAPP) (such as AWS Security Hub or CrowdStrike), and application alerting from enterprise notification systems (such as Slack, Microsoft Teams, or email).
In addition to data partition isolation, it’s a FedRAMP security best practice to make sure that the credentials used to access GovCloud Regions are isolated to exist only within those Regions. It’s also a best practice to make sure that data access requests originate from the GovCloud partition, and to pull data from the less restrictive partition, such as the aws Commercial partition. This requirement is designed to help prevent exposure of GovCloud partition resources to the Commercial partition through open ports, APIs, endpoints, or credentials to a commercial partition. Because AWS Commercial partition resources can support connectivity from the internet, you can put appropriate security controls to limit access to endpoints, ports, APIs and load balancers using short-term or long-term credentials.
Cross-partition data transfer using IAM access keys (Not recommended)
Though this is no longer a recommended best practice, data transfer requirements were met previously by using Data Sync, s3api, data transfer hub, and other SDK methods by creating an IAM user access key in the AWS Commercial partition. You would then store the aws partition IAM user access key in AWS Secrets Manager in the aws-us-gov partition. By using this method, one of these applications would operate within AWS GovCloud; the application would then use the aws partition IAM user access key to access and read data from the commercial partition Amazon Simple Storage Service (Amazon S3) bucket and then write it to the AWS GovCloud Partition S3 bucket. The application could then process the data within the application running in the AWS GovCloud partition. That legacy architecture is shown in Figure 2.
Figure 2: Cross-partition data movement using IAM access keys
This solution requires an audit exception to allow the use of long-term user credentials. Using long-term user credentials for workloads or service accounts deviates from AWS security best practices and NIST 800-53 IA2, because they can be compromised and difficult to rotate and change. Temporary credentials align with AWS security best practices and are provided by AWS roles. Additionally, the use of x509 certificates has been a standard for establishing secure communications with applications operating processes on remote devices and comply with NIST 800.53r5 IA8.
Cross-partition data transfer using IAM Roles Anywhere (Recommended)
To meet the requirement to use short-term credentials and enable access across an AWS partition, you can use IAM Roles Anywhere, which avoids the need for long-term access key or secret access key credentials. Using IAM Roles Anywhere, you can use your existing certificate authority (CA) or AWS Private Certificate Authority to issue and manage X.509 certificates to specific workloads and applications. You can register your external CA with IAM Roles Anywhere as a trust anchor to establish a trust between your external CA and IAM Roles Anywhere. If you don’t manage your own private key infrastructure (PKI), a trust can be established with AWS Private CA to create a CA as the trust anchor. For detailed steps for setting up IAM Roles Anywhere, see Planning for your IAM Roles Anywhere deployment.
Figure 3: Architecture for cross-partition data movement using IAM Roles Anywhere with an external CA
Figure 3 demonstrates how you can use IAM Roles Anywhere with an external CA to enable data transfer between partitions. By using this pattern, which is an AWS security best practice, you can pull data from your AWS Commercial partition into your AWS GovCloud partition. By using an external CA, you can use your existing PKI. For compliance purposes, internal CAs are often required to issue certificates for internal applications and services, device authentication, internal web services, employee authentication, and other tasks. Internal PKI consists of a root CA, intermediate CA and an issuing CA. The root CA is often disconnected from the internet to help prevent tampering or issuing of PKI to untrusted resources. The root CA will issue a certificate for an intermediate CA and the intermediate CA will create certificates for one or more issuing CAs. When the GovCloud application creates a certificate signing request (CSR), it will maintain the private key that goes with the CSR in Secrets Manager. The customer’s external issuing CA will then sign the CSR and provide an end-entity certificate for the GovCloud application in addition to the external CA bundle. This CA bundle contains the root CA, intermediate CA, and issuing CA certificates. All three of which will be stored in GovCloud application’s Secrets Manager so that the workload can then interact with AWS Commercial partition resources.
As shown in Figure 3 you can initiate a temporary session from GovCloud (right) to AWS Commercial (left). IAM Roles Anywhere is configured within the Commercial partition to use your existing PKI as the trust anchor. As you vend PKI certificates to workloads that run in GovCloud, they’re stored in Secrets Manager, and your Amazon Elastic Kubernetes Service (Amazon EKS) role allows access to the certificates. In the Commercial Region, you configured a role that allows access to Amazon Simple Notification Service (Amazon SNS), Amazon Simple Queue Service (Amazon SQS), and Amazon S3. You then configure the trust policy on that role to allow IAM Roles Anywhere access. Based on your GovCloud application scheduling, the Amazon EKS pipeline provides the credential helper process temporary security credentials for the Commercial Region. It does this by using the certificates, private key, Commercial Region IAM Roles Anywhere role ARN, profile ARN, and trust anchor ARN that are provided to the GovCloud application as it prepares to connect from the GovCloud Region to the Commercial Region.
Figure 4: Cross-partition data movement using IAM Roles Anywhere with AWS Private CA
If you don’t have an existing PKI in place, or don’t want to build your own offline PKI, you can use AWS Private CA, as shown if Figure 4. Using AWS Private CA, you don’t have to maintain hardware or software. As a managed service, AWS handles the high availability, scalability, and durability, in addition to patching and maintenance. You also benefit from seamless integration with other AWS services such as AWS Elastic Load Balancing, Amazon CloudFront, and Amazon API Gateway. AWS Private CA also integrates with AWS CloudTrail, so that you can audit what actions have been taken.
Conclusion
In this post, we explained the compliance requirements that need to be considered when migrating data across AWS partitions. We also outlined architectural options AWS customers and partners can take when implementing a solution to address this need.
IAM Roles Anywhere is a great solution that AWS Customers and software as a service (SaaS) partners can use when they want to access AWS resources from across AWS partitions without needing to use long-lived credentials for IAM users.
To learn more about IAM Roles Anywhere, see the feature’s documentation, this IAM Roles Anywhere workshop, or this re:Inforce presentation featuring Hertz.
If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, start a new thread on AWS Security, Identity, and Compliance re:Post or contact AWS Support.
If you have feedback about this post, submit comments in the Comments section below.