SEC03-BP08 Share resources securely within your organization
As the number of workloads grows, you might need to share access to resources in those workloads or provision the resources multiple times across multiple accounts. You might have constructs to compartmentalize your environment, such as having development, testing, and production environments. However, having separation constructs does not limit you from being able to share securely. By sharing components that overlap, you can reduce operational overhead and allow for a consistent experience without guessing what you might have missed while creating the same resource multiple times.
Desired outcome: Minimize unintended access by using secure methods to share resources within your organization, and help with your data loss prevention initiative. Reduce your operational overhead compared to managing individual components, reduce errors from manually creating the same component multiple times, and increase your workloads’ scalability. You can benefit from decreased time to resolution in multi-point failure scenarios, and increase your confidence in determining when a component is no longer needed. For prescriptive guidance on analyzing externally shared resources, see SEC03-BP07 Analyze public and cross-account access.
Common anti-patterns:
-
Lack of process to continually monitor and automatically alert on unexpected external share.
-
Lack of baseline on what should be shared and what should not.
-
Defaulting to a broadly open policy rather than sharing explicitly when required.
-
Manually creating foundational resources that overlap when required.
Level of risk exposed if this best practice is not established: Medium
Implementation guidance
Architect your access controls and patterns to govern the consumption of shared resources securely and only with trusted entities. Monitor shared resources and review shared resource access continuously, and be alerted on inappropriate or unexpected sharing. Review Analyze public and cross-account access to help you establish governance to reduce the external access to only resources that require it, and to establish a process to monitor continuously and alert automatically.
Cross-account sharing within AWS Organizations is supported by a number of AWS services,
such as AWS Security Hub,
Amazon GuardDuty,
and AWS Backup.
These services allow for data to be shared to a central account, be accessible from a central account, or manage resources
and data from a central account. For example, AWS Security Hub can transfer findings from individual accounts to a
central account where you can view all the findings. AWS Backup can take a backup for a resource and share it
across accounts. You can use AWS Resource Access Manager
To restrict your account to only share resources within your organization, use
service control policies (SCPs)
to prevent access to external principals. When sharing resources, combine identity-based controls and
network controls to create a data perimeter for your organization
to help protect against unintended access. A data perimeter is a set of preventive guardrails to help verify
that only your trusted identities are accessing trusted resources from expected networks. These controls place
appropriate 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 can use VPC endpoint policies and the
AWS:PrincipalOrgId condition to ensure the identities accessing your Amazon S3 buckets
belong to your organization. It is important to note that
SCPs do not apply to service-linked roles or AWS service principals.
When using Amazon S3,
turn off 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
In some cases, you might want to allow sharing resources outside of your organization or grant a third party access to your resources. For prescriptive guidance on managing permissions to share resources externally, see Permissions management.
Implementation steps
-
Use AWS Organizations: AWS Organizations is an account management service that allows you to consolidate multiple AWS accounts into an organization that you create and centrally manage. You can group your accounts into organizational units (OUs) and attach different policies to each OU to help you meet your budgetary, security, and compliance needs. You can also control how AWS artificial intelligence (AI) and machine learning (ML) services can collect and store data, and use the multi-account management of the AWS services integrated with Organizations.
-
Integrate AWS Organizations with AWS services: When you use an AWS service to perform tasks on your behalf in the member accounts of your organization, AWS Organizations creates an IAM service-linked role (SLR) for that service in each member account. You should manage trusted access using the AWS Management Console, the AWS APIs, or the AWS CLI. For prescriptive guidance on turning on trusted access, see Using AWS Organizations with other AWS services and AWS services that you can use with Organizations.
-
Establish a data perimeter: A data perimeter provides a clear boundary of trust and ownership. On AWS, it is typically represented as your AWS organization managed by AWS Organizations, along with any on-premises networks or systems that access your AWS resources. The goal of the data perimeter is to verify that access is allowed if the identity is trusted, the resource is trusted, and the network is expected. However, establishing a data perimeter is not a one-size-fits-all approach. Evaluate and adopt the control objectives outlined in the Building a Perimeter on AWS whitepaper based on your specific security risk models and requirements. You should carefully consider your unique risk posture and implement the perimeter controls that align with your security needs.
-
Use resource sharing in AWS services and restrict accordingly: Many AWS services allow you to share resources with another account, or target a resource in another account, such as Amazon Machine Images (AMIs) and AWS Resource Access Manager (AWS RAM). Restrict the
ModifyImageAttributeAPI to specify the trusted accounts to share the AMI with. Specify theram:RequestedAllowsExternalPrincipalscondition when using AWS RAM to constrain sharing to your organization only, to help prevent access from untrusted identities. For prescriptive guidance and considerations, see Resource sharing and external targets. -
Use AWS RAM to share securely in an account or with other AWS accounts: AWS RAM
helps you securely share the resources that you have created with roles and users in your account and with other AWS accounts. In a multi-account environment, AWS RAM allows you to create a resource once and share it with other accounts. This approach helps reduce your operational overhead while providing consistency, visibility, and auditability through integrations with Amazon CloudWatch and AWS CloudTrail, which you do not receive when using cross-account access. If you have resources that you shared previously using a resource-based policy, you can use the
PromoteResourceShareCreatedFromPolicyAPI or an equivalent to promote the resource share to a full AWS RAM resource share.In some cases, you might need to take additional steps to share resources. For example, to share an encrypted snapshot, you need to share a AWS KMS key.
Resources
Related best practices:
Related documents:
Related videos:
Related tools:
