本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# AWS SRA 的价值
<a name="value"></a>


|  | 
| --- |
| 通过进行[简短的调查](https://amazonmr.au1.qualtrics.com/jfe/form/SV_e3XI1t37KMHU2ua)来影响 AWS 安全参考架构 (AWS SRA) 的未来。 | 

AWS 拥有大量（而且还在不断增长）[的安全和安全相关服务](https://aws.amazon.com/products/security)。客户对通过我们的服务文档、博客文章、教程、峰会和会议提供的详细信息表示感谢。他们还告诉我们，他们希望更好地了解大局并从战略角度看待 AWS 安全服务。当我们与客户合作以更深入地了解他们的需求时，会出现三个优先事项：
+ 客户需要更多信息和推荐模式，以了解他们如何全面部署、配置和运营 AWS 安全服务。应在哪些账户中部署和管理服务，以实现哪些安全目标？ 是否有一个安全账户可以运行所有或大多数服务？ 地点（组织单位或 AWS 账户）的选择如何为安全目标提供依据？ 客户应该注意哪些权衡取舍（设计注意事项）？
+ 客户有兴趣看到逻辑组织许多 AWS 安全服务的不同视角。除了每项服务（例如身份服务或日志服务）的主要功能外，这些替代观点还可以帮助客户规划、设计和实施其安全架构。本文档稍后分享的一个示例根据与您的 AWS 环境推荐结构一致的保护层对服务进行分组。
+ 客户正在寻找指导和示例，以最有效的方式集成安全服务。例如，他们应该如何最好地 AWS Config 与其他服务协调和连接，以完成自动化审计和监控管道中的繁重工作？ 客户正在寻求有关每项 AWS 安全服务如何依赖或支持其他安全服务的指导。

我们在 AWS SRA中逐一解决了这些问题。列表中的第一要务（事情进展如何）是主架构图的重点以及本文档中随附的讨论。我们提供了推荐的 AWS Organizations 架构，并 account-by-account描述了哪些服务的去向。要开始了解列表中的第二个优先级（如何考虑全套安全服务），请阅读在[整个 AWS 组织中应用安全服务一节。](security-services.md)本节介绍一种根据 AWS 组织中元素的结构对安全服务进行分组的方法。此外，同样的想法也反映在关于[应用程序账户](application.md)的讨论中，其中重点介绍了如何运营安全服务以专注于账户的某些层：亚马逊弹性计算云 (Amazon EC2) 实例、亚马逊虚拟私有云 (Amazon VPC) 网络以及更广泛的账户。最后，第三个优先事项（服务集成）反映在整个指南中，尤其是在SRA库的[深入研究指南中对单个服务的讨论以及 AWS SRA代码库](about-sra-library.md)中的代码中 AWS 。

## 如何使用 AWS SRA
<a name="how-to-use"></a>

根据您在云采用之旅中所处的阶段，有不同的使用 AWS SRA 的方法。以下列出了从 AWS SRA 资产中获得最大洞察力的方法（架构图、书面指南和代码示例）。
+ 为自己的安全架构@@ *定义*目标状态。

  无论您是刚刚开始 AWS 云 旅程（设置第一组帐户），还是计划增强已建立的 AWS 环境， AWS SRA 都是开始构建安全架构的地方。从全面的账户结构和安全服务基础开始，然后根据您的特定技术堆栈、技能、安全目标和合规性要求进行调整。如果您知道自己将构建和启动更多工作负载，则可以采用自定义版本的 AWS SRA，将其用作组织安全参考架构的基础。要了解如何实现 AWS SRA 描述的目标状态，请参阅 “[构建您的安全架构 — 分阶段方法” 一](phases.md)节。 
+ *审查*（并修改）您已经实施的设计和功能。

  如果你已经有了安全设计和实现，那么值得花点时间将你所拥有的与 AWS SRA进行比较。 AWS SRA 的设计非常全面，可为审查您自己的安全性提供诊断基准。如果您的安全设计符合 AWS SRA，则可以更有信心在使用 AWS 服务时遵循最佳实践。如果你的安全设计与 AWS SRA 中的指导意见存在分歧甚至不一致，这不一定表明你做错了什么。相反，这个观察结果为你提供了回顾决策过程的机会。出于正当的业务和技术原因，您可能会偏离 AWS SRA 最佳实践。也许您的特定合规性、监管或组织安全要求需要特定的服务配置。或者，您可能不使用 AWS 服务，而是对自己构建和管理的自定义应用程序中的产品 AWS Partner Network 或自定义应用程序有功能偏好。有时，在这次审查中，您可能会发现您之前的决定是基于已不再适用的旧技术、 AWS 功能或业务限制做出的。这是一个很好的机会，可以查看所有更新，确定其优先顺序，并将它们添加到工程待办事项列表的相应位置。无论您在根据 AWS SRA评估安全架构时发现什么，都将发现记录该分析很有价值。拥有决策及其理由的历史记录可以帮助为未来的决策提供信息并确定其优先顺序。
+ *引导*您自己的安全架构的实现。

   AWS SRA 基础设施即代码 (IaC) 模块提供了一种快速、可靠的方式来开始构建和实施您的安全架构。[代码存储库部分和[公共 GitHub ](https://github.com/aws-samples/aws-security-reference-architecture-examples)存储库](code-repo.md)中对这些模块进行了更深入的描述。它们不仅使工程师能够在 AWS SRA 指南中的高质量模式示例基础上再接再厉，而且还纳入了推荐的安全控制措施，例如 IAM 密码策略、亚马逊简单存储服务 (Amazon S3) Simple Storage 封锁账户公开访问、亚马逊 EC2 默认亚马逊弹性区块存储 (Amazon EBS) Elastic Block Store 加密以及与之 AWS Control Tower 集成，以便在新控制措施上线时应用或移除控件退役。 AWS 账户 
+ *了解*有关 AWS 安全服务和功能的更多信息。

   AWS SRA 中的指导和讨论包括个人 AWS 安全和安全相关服务的重要功能以及部署和管理注意事项。 AWS SRA 的一个特点是，它提供了对 AWS 安全服务的广泛性以及它们如何在多账户环境中协同工作的高级介绍。这补充了对其他来源中每项服务的功能和配置的深入研究。这方面的一个例子是关于 AWS Security Hub 云安全态势管理 (AWS Security Hub CSPM) 如何从各种 AWS Partner 产品甚至你自己的应用程序中提取安全发现的[AWS 服务讨论](security-tooling.md#tool-security-hub)。
+ *推动*关于组织治理和安全责任的讨论。

  设计和实施任何安全架构或策略的一个重要因素是了解组织中谁负有哪些与安全相关的责任。例如，在何处汇总和监控安全调查结果的问题与哪个小组将负责该活动有关。整个组织的所有调查结果是否都由需要访问专用安全工具帐户的中央团队监控？ 还是个别应用团队（或业务部门）负责某些监控活动，因此需要访问某些警报和监控工具？ 再举一个例子，如果你的组织有一个集中管理所有加密密钥的群组，那将影响谁有权创建 AWS Key Management Service (AWS KMS) 密钥以及这些密钥将在哪些账户中进行管理。了解组织的特征（不同的团队和职责）将有助于您量身定制最适合您需求的 AWS SRA。相反，有时对安全架构的讨论会成为讨论现有组织职责和考虑潜在变化的动力。 AWS 建议采用分散决策流程，由工作量小组负责根据其工作量职能和要求确定安全控制措施。集中式安全和治理团队的目标是构建一个系统，使工作负载所有者能够做出明智的决策，并使所有各方都能了解配置、发现和事件。 AWS SRA可以成为识别和通报这些讨论的工具。

## AWS SRA 的关键实施指南
<a name="key-guidelines"></a>

在设计和实施安全措施时，请记住以下 AWS SRA的八个关键要点。  
+ AWS Organizations 适当的多账户策略是您的安全架构的必要元素。正确分离工作负载、团队和职能为职责和 defense-in-depth策略的分离奠定了基础。本指南[将在后面的章节](account-structure.md)中对此进行进一步介绍。
+ Defense-in-depth 是为组织选择安全控制措施的重要设计考虑因素。它可以帮助您在 AWS Organizations 结构的不同层面注入适当的安全控制措施，这有助于最大限度地减少问题的影响：如果某一层存在问题，则有控制措施可以隔离其他宝贵的 IT 资源。 AWS SRA 演示了 AWS 技术堆栈不同层次的不同 AWS 服务 功能，以及组合使用这些服务如何帮助您实现目标 defense-in-depth。[后面的章节](security-services.md)将进一步讨论这个 defense-in-depth概念，并在[应用程序帐户](application.md)下显示设计示例。 AWS 
+ 使用涵盖多个 AWS 服务 和功能的各种安全构建块来构建强大而有弹性的云基础架构。在根据您的特定需求定制 AWS SRA 时，不仅要考虑其主要功能 AWS 服务 和功能（例如身份验证、加密、监控、权限策略），还要考虑它们如何融入您的架构结构。本指南的[后面部分](security-services.md#orgwide)将介绍某些服务在整个 AWS 组织中的运行方式。其他服务最好在一个账户内运行，有些服务旨在向个人委托人授予或拒绝许可。考虑这两个角度可以帮助您构建更灵活、更分层的安全方法。
+ 在可能的情况下（详见后面的章节），利用可在每个账户（分布式而不是集中式）中部署的功能，并构建一组一致的共享护栏，以帮助保护您的工作负载免遭滥用，并帮助减少安全事件的影响。 AWS 服务 AWS SRA 使用 AWS Security Hub CSPM （集中式发现监控和合规性检查）、Amazon GuardDuty（威胁检测和异常检测）、 AWS Config （资源监控和变更检测）、IAM Access Analyzer AWS CloudTrail （资源访问监控）、（记录环境中的服务 API 活动）和 Amazon Macie（数据分类）作为在每个环境中部署的基础集 AWS 服务 。 AWS 账户
+ 使用支持的委托管理功能 AWS Organizations，如本指南的[委托管理](security-tooling.md#tool-delegated-admin)部分稍后所述。这样，您就可以将 AWS 成员帐户注册为受支持服务的管理员。委托管理为企业内的不同团队提供了灵活性，允许他们根据自己的职责使用不同的账户来管理 AWS 服务 整个环境。此外，使用委派管理员可以帮助您限制对管理账户的访问权限并 AWS Organizations 管理其权限开销。
+ 在整个 AWS 组织中实施集中式监控、管理和治理。通过使用 AWS 服务 支持多账户（有时还有多区域）聚合以及委托管理功能，您可以让中央安全、网络和云工程团队对适当的安全配置和数据收集拥有广泛的可见性和控制力。此外，可以将数据提供给工作负载团队，使他们能够在软件开发生命周期 (SDLC) 的早期做出有效的安全决策。
+ 使用预先构建的安全控制 AWS Control Tower 来设置和管理您的多账户 AWS 环境，从而引导您的安全参考架构构建。 AWS Control Tower 提供了一个蓝图，用于提供身份管理、账户联合访问权限、集中式日志记录以及用于配置其他账户的已定义工作流程。然后，您可以使用 “[定制” AWS Control Tower (cfcT)](https://aws.amazon.com/solutions/implementations/customizations-for-aws-control-tower/) 解决方案，通过其他安全控制、服务配置和监管来对所 AWS Control Tower 管理的账户进行基准，如 AWS SRA 代码存储库所示。账户工厂功能可根据已批准的账户配置，使用可配置的模板自动配置新账户，以标准化 AWS 组织内的账户。您还可以将管理范围扩展到已受其管理的组织单位 (OU)， AWS 账户 从而将治理范围扩大到现有个人。 AWS Control Tower
+  AWS SRA 代码示例演示了如何使用基础设施即代码 (IaC) 在 AWS SRA 指南中自动实现模式。通过编纂模式，您可以像对待组织中的其他应用程序一样对待 IaC，并在部署代码之前自动进行测试。IaC 还通过在多个（例如 SDLC 或特定区域）环境中部署护栏，帮助确保一致性和可重复性。SRA 代码示例可以在带或不带的 AWS Organizations 多账户环境中部署。 AWS Control Tower此存储库中需要的解决方案 AWS Control Tower 已通过使用和[定制 AWS Control Tower (cfCT) 在AWS Control Tower环境中进行](https://aws.amazon.com/solutions/implementations/customizations-for-aws-control-tower/)部署 AWS CloudFormation和测试。不需要的解决方案 AWS Control Tower 已在AWS Organizations环境中使用进行了测试AWS CloudFormation。如果您不使用 AWS Control Tower，则可以使用[AWS Organizations基于的部署](https://github.com/aws-samples/aws-security-reference-architecture-examples#getting-started-using-aws-sra-in-aws-organizations-environments)解决方案。