AWS prescriptive-guidance documentation change
Summary
Updated breadcrumb navigation, fixed link formatting for multi-account strategy, corrected whitepaper title capitalization, and replaced 'IAM entities' with 'IAM principals' terminology.
Security assessment
Changes are editorial improvements (link formatting, terminology consistency, capitalization) without introducing new security concepts or addressing vulnerabilities. The core security content about multi-account strategies and IAM permissions remains unchanged.
Diff
diff --git a/prescriptive-guidance/latest/security-reference-architecture/organizations.md b/prescriptive-guidance/latest/security-reference-architecture/organizations.md index 10559ab04..165c055b6 100644 --- a//prescriptive-guidance/latest/security-reference-architecture/organizations.md +++ b//prescriptive-guidance/latest/security-reference-architecture/organizations.md @@ -3 +3 @@ -[Documentation](/index.html)[AWS Prescriptive Guidance](https://aws.amazon.com/prescriptive-guidance/)[AWS Security Reference Architecture](welcome.html) +[Documentation](/index.html)[AWS Prescriptive Guidance](https://aws.amazon.com/prescriptive-guidance/)[AWS Security Reference Architecture (AWS SRA) – core architecture](introduction.html) @@ -10 +10 @@ Influence the future of the AWS Security Reference Architecture (AWS SRA) by tak -AWS security services, their controls, and interactions are best employed on a foundation of [AWS multi-account strategy](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html) and identity and access management guardrails. These guardrails set the ability for your implementation of least privilege, separation of duties, and privacy, and provide the support for decisions about what types of controls are needed, where each security service is managed, and how they may share data and permissions in the AWS SRA. +AWS security services, their controls, and interactions are best employed on a foundation of AWS[ multi-account strategy](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html) and identity and access management guardrails. These guardrails set the ability for your implementation of least privilege, separation of duties, and privacy, and provide the support for decisions about what types of controls are needed, where each security service is managed, and how they may share data and permissions in the AWS SRA. @@ -12 +12 @@ AWS security services, their controls, and interactions are best employed on a f -An AWS account provides security, access, and billing boundaries for your AWS resources and enables you to achieve resource independence and isolation. Use of multiple AWS accounts plays an important role in how you meet your security requirements, as discussed in the [Benefits of using multiple AWS accounts](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/benefits-of-using-multiple-aws-accounts.html) section of the _Organizing Your AWS Environment Using Multiple Accounts_ whitepaper. For example, you can organize your workloads in separate accounts and group accounts within an organizational unit (OU) based on function, compliance requirements, or a common set of controls instead of mirroring your enterprise's reporting structure. Keep security and infrastructure in mind to enable your enterprise to set common guardrails as your workloads grow. This approach provides robust boundaries and controls between workloads. Account-level separation, in combination with AWS Organizations, is used to isolate production environments from development and test environments, or to provide a strong logical boundary between workloads that process data of different classifications such as Payment Card Industry Data Security Standard (PCI DSS) or Health Insurance Portability and Accountability Act (HIPAA). Although you might begin your AWS journey with a single account, AWS recommends that you set up multiple accounts as your workloads grow in size and complexity. +An AWS account provides security, access, and billing boundaries for your AWS resources and enables you to achieve resource independence and isolation. Use of multiple AWS accounts plays an important role in how you meet your security requirements, as discussed in the [Benefits of using multiple AWS accounts](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/benefits-of-using-multiple-aws-accounts.html) section of the _Organizing your AWS environment using multiple accounts_ whitepaper. For example, you can organize your workloads in separate accounts and group accounts within an organizational unit (OU) based on function, compliance requirements, or a common set of controls instead of mirroring your enterprise's reporting structure. Keep security and infrastructure in mind to enable your enterprise to set common guardrails as your workloads grow. This approach provides robust boundaries and controls between workloads. Account-level separation, in combination with AWS Organizations, is used to isolate production environments from development and test environments, or to provide a strong logical boundary between workloads that process data of different classifications such as Payment Card Industry Data Security Standard (PCI DSS) or Health Insurance Portability and Accountability Act (HIPAA). Although you might begin your AWS journey with a single account, AWS recommends that you set up multiple accounts as your workloads grow in size and complexity. @@ -14 +14 @@ An AWS account provides security, access, and billing boundaries for your AWS re -Permissions let you specify access to AWS resources. Permissions are granted to IAM entities known as _principals_ (users, groups, and roles). By default, principals start with no permissions. IAM entities can do nothing in AWS until you grant them permissions, and you can set up guardrails that apply as broadly as your entire AWS organization or as fine-grained as an individual combination of principal, action, resource, and conditions. +Permissions let you specify access to AWS resources. Permissions are granted to IAM entities known as _principals_ (users, groups, and roles). By default, principals start with no permissions. IAM principals can do nothing in AWS until you grant them permissions, and you can set up guardrails that apply as broadly as your entire AWS organization or as fine-grained as an individual combination of principal, action, resource, and conditions.