AWS whitepapers documentation change
Summary
Standardized apostrophe usage and minor grammatical corrections
Security assessment
Typographical fixes without security implications
Diff
diff --git a/whitepapers/latest/organizing-your-aws-environment/design-principles-for-your-multi-account-strategy.md b/whitepapers/latest/organizing-your-aws-environment/design-principles-for-your-multi-account-strategy.md index 14e4549df..49fc1e589 100644 --- a//whitepapers/latest/organizing-your-aws-environment/design-principles-for-your-multi-account-strategy.md +++ b//whitepapers/latest/organizing-your-aws-environment/design-principles-for-your-multi-account-strategy.md @@ -5 +5 @@ -Organize based on security and operational needsApply security controls to OUs rather than accountsAvoid deep OU hierarchiesStart small and expand as neededAvoid deploying workloads to the organization’s management accountSeparate production from non-production workloadsAssign a single or small set of related workloads to each production accountUse federated access to help simplify managing human access to accountsUse automation to support agility and scaleUse multi-factor authenticationMultiple AWS Regions +Organize based on security and operational needsApply security controls to OUs rather than accountsAvoid deep OU hierarchiesStart small and expand as neededAvoid deploying workloads to the organization's management accountSeparate production from non-production workloadsAssign a single or small set of related workloads to each production accountUse federated access to help simplify managing human access to accountsUse automation to support agility and scaleUse multi-factor authenticationMultiple AWS RegionsBreak glass access @@ -11 +11 @@ The following design principles helped develop the best practices described in t -These design principles complement the _[Benefits of using multiple accounts](./benefits-of-using-multiple-aws-accounts.html)_ and _[Benefits of using OUs](./benefits-of-using-ous.html)_. +These design principles complement the [Benefits of using multiple accounts](./benefits-of-using-multiple-aws-accounts.html) and [Benefits of using OUs](./benefits-of-using-organizational-units-ous.html). @@ -23 +23 @@ These design principles complement the _[Benefits of using multiple accounts](./ - * Avoid deploying workloads to the organization’s management account + * Avoid deploying workloads to the organization's management account @@ -37 +37 @@ These design principles complement the _[Benefits of using multiple accounts](./ - * [Break glass access](./break-glass-access.html) + * Break glass access @@ -44 +44 @@ These design principles complement the _[Benefits of using multiple accounts](./ -We recommend that you organize accounts using _[OUs based on function](./benefits-of-using-ous.html#group-similar-accounts-based-on-function)_ , compliance requirements, or a common set of controls rather than mirroring your organization’s reporting structure. +We recommend that you organize accounts using OUs based on function, compliance requirements, or a common set of controls rather than mirroring your organization's reporting structure. @@ -56 +56 @@ Overly complicated structures can be difficult to understand and maintain. Altho -When you consider the addition of new OU levels, you should review the _[Benefits of using OUs](./benefits-of-using-ous.html)_ and these principles to decide whether the additional complexity adds sufficient value. +When you consider the addition of new OU levels, you should review the Benefits of using OUs and these principles to decide whether the additional complexity adds sufficient value. @@ -60 +60 @@ When you consider the addition of new OU levels, you should review the _[Benefit -We recommend that you start with a subset of the _[Recommended OUs and accounts](./recommended-ous-and-accounts.html)_ , and expand the structure of your AWS accounts when your needs call for the creation of new OUs. +We recommend that you start with a subset of the [Recommended OUs and accounts](./recommended-ous-and-accounts.html) and expand the structure of your AWS accounts when your needs call for the creation of new OUs. @@ -62 +62 @@ We recommend that you start with a subset of the _[Recommended OUs and accounts] -You shouldn’t need to invest a lot of time at the beginning of your adoption journey designing what you expect your AWS account structure will look like in several years. +You shouldn't need to invest a lot of time at the beginning of your adoption journey designing what you expect your AWS account structure will look like in several years. @@ -64 +64 @@ You shouldn’t need to invest a lot of time at the beginning of your adoption j -## Avoid deploying workloads to the organization’s management account +## Avoid deploying workloads to the organization's management account @@ -66 +66 @@ You shouldn’t need to invest a lot of time at the beginning of your adoption j -Since privileged operations can be performed within an organization’s management account and SCPs do not apply to the management account, we recommend that you limit access to an organization’s management account. You should also limit the cloud resources and data contained in the management account to only those that must be managed in the management account. +Since privileged operations can be performed within an organization's management account and SCPs do not apply to the management account, we recommend that you limit access to an organization's management account. You should also limit the cloud resources and data contained in the management account to only those that must be managed in the management account. @@ -68 +68 @@ Since privileged operations can be performed within an organization’s manageme -Many AWS services that integrate with AWS Organizations enable you to reduce the usage of the management account. These services enable you to register one or more member accounts as administrators that can manage all of the organization’s accounts used in the service. These accounts are called [delegated administrators](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_delegated_admin.html) for that specific service. By registering a member account as a delegated administrator for an AWS service, you enable that account to have some administrative permissions for that service, reducing the number of users that require management account access. +Many AWS services that integrate with Organizations enable you to reduce the usage of the management account. These services enable you to register one or more-member accounts as administrators that can manage all of the organization's accounts used in the service. These accounts are called [delegated administrators ](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_delegated_admin.html)for that specific service. By registering a member account as a delegated administrator for an AWS service you enable that account to have some administrative permissions for that service, reducing the number of users that require management account access. @@ -72 +72 @@ Many AWS services that integrate with AWS Organizations enable you to reduce the -We recommend that you separate production workloads from non-production workloads. For overall recommendations on designing this separation, refer to _[Organizing workload-oriented OUs](./organizing-workload-oriented-ous.html)_. +We recommend that you separate production workloads from non-production workloads. For overall recommendations on designing this separation, refer to Organizing workload-oriented OUs. @@ -82 +82 @@ Consider separating workloads that have different owners into their own producti -We recommend that you use AWS identity federation capabilities by using IAM Identity Center. These capabilities enable you to use a common identity provider and your existing processes for controlling human user access to your AWS accounts. +We recommend that you use AWS identity federation capabilities by using AWS IAM Identity Center. These capabilities enable you to use a common identity provider and your existing processes for controlling human user access to your AWS accounts. @@ -90 +90 @@ Use of federated access avoids the creation and management of users in your AWS -For more information about managing identities, refer to [Identity Management](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-management.html) in the AWS Well-Architected Security Pillar and [Identity federation in AWS](https://aws.amazon.com/identity/federation/). +For more information about managing identities, refer to [Identity Management](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-management.html) in the AWS Well- Architected Security Pillar and [Identity federation in AWS.](https://aws.amazon.com/identity/federation/) @@ -119 +119 @@ If you plan to use multiple AWS Regions, keep the following considerations in mi -If you use different AWS Regions that are in the same geographic scope defined by the data protection requirements applicable to your workloads, you can use the same IAM IdPs to federate to all accounts in live, disaster recovery, or load balanced live environments. You can replicate databases between environments using appropriate mechanisms, such as Amazon DynamoDB global tables or Amazon RDS read replicas. In such circumstances, it is also possible for you to distribute core elements of your foundational AWS environment such that the log archive bucket is in one Region and assets in other accounts in other Regions log cross-Region to it. +If you use different AWS Regions that are in the same geographic scope defined by the data protection requirements applicable to your workloads, you can use the same IAM IdP or IdPs to federate to all accounts in live, disaster recovery, or load balanced live environments. You can replicate databases between environments using appropriate mechanisms, such as Amazon DynamoDB global tables or Amazon RDS read replicas. In such circumstances, it is also possible for you to distribute core elements of your foundational AWS environment such that the log archive bucket is in one Region and assets in other accounts in other Regions log cross-Region to it. @@ -127 +127 @@ This might impact your ability to make cross-Region data transfers. (Note that c -There are also performance considerations to keep in mind for certain workloads. Some services are by their nature per-Region, which makes it more sensible for you to deploy such workloads with all assets in the same Region. For example, AWS KMS keys cannot be exported from a Region, and use of a KMS key in another Region is likely going to add latency to an application. We therefore recommend using AWS KMS in the same Region unless specific governance policies, regulatory or corporate, mandate otherwise. +There are also performance considerations to keep in mind for certain workloads. Some services are by their nature per-Region, which makes it more sensible for you to deploy such workloads with all assets in the same Region. For example, AWS KMS keys cannot be exported from a Region, and use of a KMS key in another Region is likely going to add latency to an application. We therefore recommend using AWS KMS in the same Region, unless specific governance policies, regulatory or corporate, mandate otherwise. @@ -129 +129 @@ There are also performance considerations to keep in mind for certain workloads. -Close collaboration between your security and architecture teams and your workload owning teams is important to properly using AWS KMS. Your design of how Amazon S3 objects, Amazon EBS volumes, and other data are encrypted and potentially replicated across Regions should factor in low latency when required. +Close collaboration between your security and architecture teams and your workload owning teams is important to properly using KMS. Your design of how Amazon S3 objects, EBS volumes, and other data are encrypted and potentially replicated across Regions should factor in low latency when required. @@ -131 +131 @@ Close collaboration between your security and architecture teams and your worklo -Where cross-account replication of these assets is required, Amazon S3 Cross-Region Replication (CRR) enables on-the-fly re-encryption of an object with an KMS key in the destination Region. Multi-Region duplication of KMS keys for the decryption of cross-Region copied Amazon EBS volumes can be achieved using the techniques covered in Busy Engineer's Document Bucket. +Where cross-account replication of these assets is required, Amazon S3 Cross-Region Replication (CRR) enables on-the-fly re-encryption of an object with an AWS KMS key in the destination Region. Multi-Region duplication of AWS KMS keys for the decryption of cross-Region copied EBS volumes can be achieved using the techniques covered in Busy Engineer's Document Bucket. @@ -138,0 +139,42 @@ Although AWS CloudTrail has built-in cross-account logging capability and AWS Co +## Break glass access + +The organization management account is used to provide break glass access to AWS accounts within the organization. Break glass (which draws its name from breaking the glass to pull a fire alarm) refers to a quick means for a person who does not have access privileges to certain AWS accounts to gain access in exceptional circumstances by using an approved process. + +The use cases for break glass access include: + + * Failure of the organization's IdP. + + * A security incident involving the organizations' IdP(s). + + * A failure involving IAM Identity Center. + + * A disaster involving the loss of an organization's entire cloud or IdP teams. It is important that access to these roles is monitored, and alarms and alerts are triggered when the roles are used to access the environment. + + + + +In the case of an incident requiring remediation, we recommend that a user with access to an administrative federated role within the AWS account perform the required remediation. In cases where this user is unavailable to carry out a time sensitive action, we recommend that a highly- restricted group or set of groups be preconfigured within your IdP, each providing appropriate [federated access](https://aws.amazon.com/identity/federation/) into the appropriate set of AWS accounts. A user can either be added into one of these groups using a high-priority and temporary change request, or a select group of privileged and trusted users can be prepopulated into these groups. + +Security teams investigating an incident would use this mechanism to access a read-only role in an impacted account, or use the read-only access mechanism provided through the security tooling account. In summary, common high-priority irregular access scenarios need to be incorporated into standard federated access processes and procedures. + +###### Note + +AWS Organizations Service Control Policies do not apply to the organization management account, and administrator access to this account would grant privileged status to the entire organization, given the trust relationship to the management account. Therefore, access to break glass IAM users must be tightly controlled, but accessible through a predefined and strict process. This process often involves one trusted individual having access to the password, and a different trusted individual having access to the hardware multi-factor authentication (MFA) key, meaning it typically requires two people to access any one set of break glass credentials. + +Human access to AWS accounts within the organization should be provided using federated access. Although the use and creation of AWS IAM users is highly discouraged, break glass users are an exception. + +To ensure human break-glass access to your environment, we recommend that you create the following in your AWS organization: + + * At least two IAM users with IAM login credentials to prevent lockdown in case one of them is not available, and additional users depending on your operating model. Do not create unnecessary IAM privileged users in your management account. These users will assume roles in the member accounts in your organization through trust policies. + + * A break glass role that is deployed to all the accounts in the organization, and that can only be assumed by the break glass users from the management account. These roles are needed to allow access from the management account to apply and update controls, to troubleshoot and resolve issues with the automation tooling from the security tooling account, or to remediate security and operational issues in one of the member accounts in the AWS organization. When setting up these roles in your organization, you need to ensure they can be used in emergency situations, bypassing established controls under the situations described earlier in the paragraph, such as service control policies. + + + + +###### Note + +If you are currently using AWS Identity Center and you are not using an external IdP (you are using the IAM Identity Center store or your domain service for your identity source), you can use this break glass access in case of Identity Center failure. Review how to set up [emergency access for your IAM Identity Center.](https://docs.aws.amazon.com/singlesignon/latest/userguide/emergency-access.html) + +We strongly recommend configuring these users with a hardware-based MFA device, which can be used in exceptional circumstances to gain access to the organization management account or sub-accounts within the organization by assuming a role. While we recommend the use of the organization management account for break glass access, some organizations might choose to add a dedicated break glass account. This does not eliminate the need for organizational break glass users in the organization management account. + @@ -147 +189 @@ Multiple organizations -Break glass access +Recommended OUs and accounts