SEC03-BP08 Share resources securely

Govern the consumption of shared resources across accounts or within your AWS Organizations. Monitor shared resources and review shared resource access.

Common anti-patterns:

Level of risk exposed if this best practice is not established: Low

Implementation guidance

As you manage your workloads using multiple AWS accounts, you may need to share resources between accounts. This will very often be cross-account sharing within an AWS Organizations. Several AWS services, such as AWS Security Hub, Amazon GuardDuty, and AWS Backup have cross-account features integrated with Organizations. You can use AWS Resource Access Manager to share other common resources, such as VPC Subnets or Transit Gateway attachments, AWS Network Firewall, or Amazon SageMaker Runtime pipelines. If you want to ensure that your account only shares resources within your Organizations, we recommend using Service Control Policies (SCPs) to prevent access to external principals.

When sharing resources, you should put measures in place to protect against unintended access. We recommend combining identity-based controls and network controls to create a data perimeter for your organization. These controls should place strict limits on what resources can be shared and prevent sharing or exposing resources that should not be allowed. For example, as a part of your data perimeter you could use VPC endpoint policies and the aws:PrincipalOrgId condition to ensure the identities accessing your Amazon S3 buckets belong to your organization.

In some cases, you may want to allow share resources outside of your Organizations or grant third parties access to your account. For example, a partner may provide a monitoring solution that needs to access resources within your account. In those cases, you should create an IAM cross-account role with only the privileges needed by the third party. You should also craft a trust policy using the external ID condition. When using an external ID, you should generate a unique ID for each third party. The unique ID should not be supplied by or controlled by the third party. If the third party no longer needs access to your environment, you should remove the role. You should also avoid providing long-term IAM credentials to a third-party in all cases. Maintain awareness of other AWS services which natively support sharing. For example, the AWS Well-Architected Tool allows sharing a workload with other AWS accounts.

When using service such as Amazon S3, it is recommended to disable ACLs for your Amazon S3 bucket and use IAM policies to define access control. For restricting access to an Amazon S3 origin from Amazon CloudFront, migrate from origin access identity (OAI) to origin access control (OAC) which supports additional features including server-side encryption with AWS KMS.

Resources

Related documents:

Related videos: