AWS prescriptive-guidance documentation change
Summary
Updated AWS Security Reference Architecture documentation with editorial improvements, link corrections, content reorganization, and terminology updates. Changes include fixing broken URLs, improving service references, adding documentation structure clarity, and refining explanations of security service integrations.
Security assessment
The changes are editorial and organizational in nature, focusing on documentation clarity and accuracy. There is no evidence of addressing specific vulnerabilities or security incidents. While the content discusses security services, the modifications don't introduce new security features or address identified weaknesses.
Diff
diff --git a/prescriptive-guidance/latest/security-reference-architecture/value.md b/prescriptive-guidance/latest/security-reference-architecture/value.md index 3894670da..eddb5d6aa 100644 --- a//prescriptive-guidance/latest/security-reference-architecture/value.md +++ b//prescriptive-guidance/latest/security-reference-architecture/value.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) @@ -12 +12 @@ Influence the future of the AWS Security Reference Architecture (AWS SRA) by tak -AWS has a large (and growing) [set of security and security-related services](https://aws.amazon.com/products/security/). Customers have expressed appreciation for the detailed information available through our service documentation, blog posts, tutorials, summits, and conferences. They also tell us that they want to better understand the big picture and get a strategic view of AWS security services. When we work with customers to get a deeper appreciation for what they need, three priorities emerge: +AWS has a large (and growing) [set of security and security-related services](https://aws.amazon.com/products/security). Customers have expressed appreciation for the detailed information available through our service documentation, blog posts, tutorials, summits, and conferences. They also tell us that they want to better understand the big picture and get a strategic view of AWS security services. When we work with customers to get a deeper appreciation for what they need, three priorities emerge: @@ -16 +16 @@ AWS has a large (and growing) [set of security and security-related services](ht - * Customers are interested in seeing different perspectives for logically organizing the many AWS security services. Beyond the primary function of each service (for example, identity services or logging services), these alternate viewpoints help customers plan, design, and implement their security architecture. An example shared later in this guide groups the services based on the layers of protection aligned to the recommended structure of your AWS environment. + * Customers are interested in seeing different perspectives for logically organizing the many AWS security services. Beyond the primary function of each service (for example, identity services or logging services), these alternate viewpoints help customers plan, design, and implement their security architecture. An example shared later in this document groups the services based on the layers of protection aligned to the recommended structure of your AWS environment. @@ -23 +23 @@ AWS has a large (and growing) [set of security and security-related services](ht -We address each of these in the AWS SRA. The first priority in the list (where things go) is the focus of the main architecture diagram and the accompanying discussions in this document. We provide a recommended AWS Organizations architecture and an account-by-account description of which services go where. To get started with the second priority in the list (how to think about the full set of security services), read the section, [Apply security services across your AWS organization](./security-services.html). This section describes a way to group security services according to the structure of the elements in your AWS organization. In addition, those same ideas are reflected in the discussion of the [Application account](./application.html), which highlights how security services can be operated to focus on certain layers of the account: Amazon Elastic Compute Cloud (Amazon EC2) instances, Amazon Virtual Private Cloud (Amazon VPC) networks, and the broader account. Finally, the third priority (service integration) is reflected throughout the guidance—particularly in the discussion of individual services in the account deep-dives sections of this documentation and the code in the AWS SRA code repository. +We address each of these in the AWS SRA. The first priority in the list (where things go) is the focus of the main architecture diagram and the accompanying discussions in this document. We provide a recommended AWS Organizations architecture and an account-by-account description of which services go where. To get started with the second priority in the list (how to think about the full set of security services), read the section, [Apply security services across your AWS organization.](./security-services.html) This section describes a way to group security services according to the structure of the elements in your AWS organization. In addition, those same ideas are reflected in the discussion of the [Application account](./application.html), which highlights how security services can be operated to focus on certain layers of the account: Amazon Elastic Compute Cloud (Amazon EC2) instances, Amazon Virtual Private Cloud (Amazon VPC) networks, and the broader account. Finally, the third priority (service integration) is reflected throughout the guidance―particularly in the discussion of individual services in the [deep dive guides in the AWS SRA library](./about-sra-library.html) and the code in the AWS SRA code repository. @@ -31,4 +31 @@ There are different ways to use the AWS SRA depending on where you are in your c - - - -Whether you are just starting your AWS Cloud journey—setting up your first set of accounts—or planning to enhance an established AWS environment, the AWS SRA is the place to start building your security architecture. Begin with a comprehensive foundation of account structure and security services, and then adjust based on your particular technology stack, skills, security objectives, and compliance requirements. If you know you will be building and launching more workloads, you can take your customized version of the AWS SRA and use it as the basis for your organization's security reference architecture. To find out how you can achieve the target state described by the AWS SRA, see the section [Building your security architecture – A phased approach](./phases.html). +Whether you are just starting your AWS Cloud journey―setting up your first set of accounts―or planning to enhance an established AWS environment, the AWS SRA is the place to start building your security architecture. Begin with a comprehensive foundation of account structure and security services, and then adjust based on your particular technology stack, skills, security objectives, and compliance requirements. If you know you will be building and launching more workloads, you can take your customized version of the AWS SRA and use it as the basis for your organization's security reference architecture. To find out how you can achieve the target state described by the AWS SRA, see the section [Building your security architecture – A phased approach](./phases.html). @@ -45,4 +39 @@ If you already have a security design and implementation, it is worth taking som - - - -The AWS SRA infrastructure as code (IaC) modules provide a fast, reliable way to start building and implementing your security architecture. These modules are described more deeply in the [code repository](./code-repo.html) section and in the [public GitHub repository](https://github.com/aws-samples/aws-security-reference-architecture-examples). They not only enable engineers to build upon high-quality examples of the patterns in the AWS SRA guidance, but they also incorporate recommended security controls such as AWS Identity and Access Management (IAM) password policies, Amazon Simple Storage Service (Amazon S3) block account public access, Amazon EC2 default Amazon Elastic Block Store (Amazon EBS) encryption, and integration with AWS Control Tower so that the controls are applied or removed as new AWS accounts are onboarded or decommissioned. +The AWS SRA infrastructure as code (IaC) modules provide a fast, reliable way to start building and implementing your security architecture. These modules are described more deeply in the [code repository](./code-repo.html) section and in the [public GitHub repository](https://github.com/aws-samples/aws-security-reference-architecture-examples). They not only enable engineers to build upon high-quality examples of the patterns in the AWS SRA guidance, but they also incorporate recommended security controls such as IAM password policies, Amazon Simple Storage Service (Amazon S3) block account public access, Amazon EC2 default Amazon Elastic Block Store (Amazon EBS) encryption, and integration with AWS Control Tower so that the controls are applied or removed as new AWS accounts are onboarded or decommissioned. @@ -52,4 +43 @@ The AWS SRA infrastructure as code (IaC) modules provide a fast, reliable way to - - - -The guidance and discussions in the AWS SRA include important features as well as deployment and management considerations for individual AWS security and security-related services. One feature of the AWS SRA is that it provides a high-level introduction to the breadth of the AWS security services and how they work together in a multi-account environment. This complements the deep dive into the features and configuration for each service found in other sources. One example of this is the [discussion](./security-tooling.html#tool-security-hub) of how AWS Security Hub CSPM ingests security findings from a variety of AWS services, AWS Partner products, and even your own applications. +The guidance and discussions in the AWS SRA include important features as well as deployment and management considerations for individual AWS security and security-related services. One feature of the AWS SRA is that it provides a high-level introduction to the breadth of the AWS security services and how they work together in a multi-account environment. This complements the deep dive into the features and configuration for each service found in other sources. One example of this is the [discussion](./security-tooling.html#tool-security-hub) of how AWS Security Hub Cloud Security Posture Management (AWS Security Hub CSPM) ingests security findings from a variety of AWS services, AWS Partner products, and even your own applications. @@ -58,0 +47 @@ The guidance and discussions in the AWS SRA include important features as well a +An important element of designing and implementing any security architecture or strategy is understanding who in your organization has which security-related responsibilities. For example, the question of where to aggregate and monitor security findings is tied to the question of which team will be responsible for that activity. Are all findings across the organization monitored by a central team that needs access to a dedicated Security Tooling account? Or are individual application teams (or business units) responsible for certain monitoring activities and therefore need access to certain alerting and monitoring tools? As another example, if your organization has a group that manages all encryption keys centrally, that will influence who has permission to create AWS Key Management Service (AWS KMS) keys and which accounts those keys will be managed in. Understanding the characteristics of your organization―the various teams and responsibilities―will help you tailor the AWS SRA to best fit your needs. Conversely, sometimes the discussion of the security architecture becomes the impetus for discussing the existing organizational responsibilities and considering potential changes. AWS recommends a decentralized decision-making process where workload teams are responsible for defining the security controls based on their workload functions and requirements. The goal of centralized security and governance team is to build a system that allows the workload owners to make informed decisions and for all parties to get visibility of configuration, findings, and events. The AWS SRA can be a vehicle for identifying and informing these discussions. @@ -62 +50,0 @@ The guidance and discussions in the AWS SRA include important features as well a -An important element of designing and implementing any security architecture or strategy is understanding who in your organization has which security-related responsibilities. For example, the question of where to aggregate and monitor security findings is tied to the question of which team will be responsible for that activity. Are all findings across the organization monitored by a central team that needs access to a dedicated Security Tooling account? Or are individual application teams (or business units) responsible for certain monitoring activities and therefore need access to certain alerting and monitoring tools? As another example, if your organization has a group that manages all encryption keys centrally, that will influence who has permission to create AWS Key Management Service (AWS KMS) keys and which accounts those keys will be managed in. Understanding the characteristics of your organization—the various teams and responsibilities—will help you tailor the AWS SRA to best fit your needs. Conversely, sometimes the discussion of the security architecture becomes the impetus for discussing the existing organizational responsibilities and considering potential changes. AWS recommends a decentralized decision-making process where workload teams are responsible for defining the security controls based on their workload functions and requirements. The goal of centralized security and governance team is to build a system that allows the workload owners to make informed decisions and for all parties to get visibility of configuration, findings, and events. The AWS SRA can be a vehicle for identifying and informing these discussions. @@ -74 +62 @@ Here are eight key takeaways from the AWS SRA to keep in mind as you design and - * Where possible (as detailed in later sections), make use of AWS services that can be deployed in every account (distributed instead of centralized) and build a consistent set of shared guardrails that can help protect your workloads from misuse and help reduce the impact of security events. The AWS SRA uses AWS Security Hub CSPM (centralized finding monitoring and compliance checks), Amazon GuardDuty (threat detection and anomaly detection), AWS Config (resource monitoring and change detection), IAM Access Analyzer (resource access monitoring, AWS CloudTrail (logging service API activity across your environment) and Amazon Macie (data classification) as a base set of AWS services to be deployed across every AWS account. + * Where possible (as detailed in later sections), make use of AWS services that can be deployed in every account (distributed instead of centralized) and build a consistent set of shared guardrails that can help protect your workloads from misuse and help reduce the impact of security events. The AWS SRA uses AWS Security Hub CSPM (centralized finding monitoring and compliance checks), Amazon GuardDuty (threat detection and anomaly detection), AWS Config (resource monitoring and change detection), IAM Access Analyzer (resource access monitoring), AWS CloudTrail (logging service API activity across your environment), and Amazon Macie (data classification) as a base set of AWS services to be deployed across every AWS account. @@ -80 +68 @@ Here are eight key takeaways from the AWS SRA to keep in mind as you design and - * Use AWS Control Tower to set up and govern your multi-account AWS environment with the implementation of pre-built security controls to bootstrap your security reference architecture build. AWS Control Tower provides a blueprint to provide identity management, federated access to accounts, centralized logging, and defined workflows for provisioning additional accounts. You can then use the [Customizations for AWS Control Tower (CfCT)](https://aws.amazon.com/solutions/implementations/customizations-for-aws-control-tower/) solution to baseline the accounts managed by AWS Control Tower with additional security controls, service configurations, and governance, as demonstrated by the AWS SRA code repository. The account factory feature automatically provisions new accounts with configurable templates based on approved account configuration to standardize accounts within your AWS Organizations. You can also extend the governance to an individual existing AWS account by enrolling it into an organizational unit (OU) that is already governed by AWS Control Tower. + * Use AWS Control Tower to set up and govern your multi-account AWS environment with the implementation of pre-built security controls to bootstrap your security reference architecture build. AWS Control Tower provides a blueprint to provide identity management, federated access to accounts, centralized logging, and defined workflows for provisioning additional accounts. You can then use the [Customizations for AWS Control Tower (CfCT)](https://aws.amazon.com/solutions/implementations/customizations-for-aws-control-tower/) solution to baseline the accounts managed by AWS Control Tower with additional security controls, service configurations, and governance, as demonstrated by the AWS SRA code repository. The account factory feature automatically provisions new accounts with configurable templates based on approved account configuration to standardize accounts within your AWS organizations. You can also extend the governance to an individual existing AWS account by enrolling it into an organizational unit (OU) that is already governed by AWS Control Tower. @@ -82 +70 @@ Here are eight key takeaways from the AWS SRA to keep in mind as you design and - * The AWS SRA code examples demonstrate how you can automate the implementation of patterns within the AWS SRA guide by using infrastructure as code (IaC). By codifying the patterns, you can treat IaC like other applications in your organization, and automate testing before you deploy code. IaC also helps ensure consistency and repeatability by deploying guardrails across multiple (for example, SDLC or Region-specific) environments. The SRA code examples can be deployed in an AWS Organizations multi-account environment with or without AWS Control Tower. The solutions in this repository that require AWS Control Tower have been deployed and tested in an AWS Control Tower environment by using AWS CloudFormation and [Customizations for AWS Control Tower (CfCT)](https://aws.amazon.com/solutions/implementations/customizations-for-aws-control-tower/). Solutions that don’t require AWS Control Tower have been tested in an AWS Organizations environment by using AWS CloudFormation. If you do not use AWS Control Tower, you can use the [AWS Organizations-based deployment](https://github.com/aws-samples/aws-security-reference-architecture-examples#getting-started-using-aws-sra-in-aws-organizations-environments) solution. + * The AWS SRA code examples demonstrate how you can automate the implementation of patterns within the AWS SRA guide by using infrastructure as code (IaC). By codifying the patterns, you can treat IaC like other applications in your organization, and automate testing before you deploy code. IaC also helps ensure consistency and repeatability by deploying guardrails across multiple (for example, SDLC or Region-specific) environments. The SRA code examples can be deployed in an AWS Organizations multi-account environment with or without AWS Control Tower. The solutions in this repository that require AWS Control Tower have been deployed and tested in an AWS Control Tower environment by using AWS CloudFormation and [Customizations for AWS Control Tower (CfCT)](https://aws.amazon.com/solutions/implementations/customizations-for-aws-control-tower/). Solutions that don't require AWS Control Tower have been tested in an AWS Organizations environment by using AWS CloudFormation. If you do not use AWS Control Tower, you can use the [AWS Organizations-based deployment](https://github.com/aws-samples/aws-security-reference-architecture-examples#getting-started-using-aws-sra-in-aws-organizations-environments) solution. @@ -93 +81 @@ To use the Amazon Web Services Documentation, Javascript must be enabled. Please -Introduction +About the AWS SRA library