构建您的安全架构 — 分阶段的方法 - AWS 规范性指导
第 1 阶段：构建 OU 和账户结构第 2 阶段：建立坚实的身份基础第 3 阶段：保持可追溯性第 4 阶段：在所有层面应用安全措施第 5 阶段：保护传输中的数据和静态数据第 6 阶段：为安全事件做好准备

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

构建您的安全架构 — 分阶段的方法

通过进行简短的调查来影响 AWS 安全参考架构 (AWS SRA) 的未来。

AWS SRA 推荐的多账户安全架构是一种基准架构，可帮助您在设计过程中尽早注入安全性。每个组织的云之旅都是独一无二的。要成功发展您的云安全架构，您需要设想所需的目标状态，了解您当前的云就绪情况，并采用敏捷的方法来缩小任何差距。 AWS SRA 为您的安全架构提供了参考目标状态。渐进式转型使您能够快速展示价值，同时最大限度地减少做出深远预测的需求。

AWS 云采用框架 (AWS CAF) 推荐了四个迭代和增量云转型阶段：构想、调整、启动和扩展。当你进入启动阶段并专注于在生产环境中交付试点计划时，你应该专注于构建一个强大的安全架构，作为扩展阶段的基础，这样你就有技术能力满怀信心地迁移和操作最关键业务的工作负载。如果您是一家初创公司、想要扩展业务的中小型公司，或者正在收购新业务部门或正在进行合并和收购的企业，则这种分阶段的方法适用。 AWS SRA 可帮助您实现该安全基准架构，以便您可以在不断扩大的组织中统一应用安全控制。 AWS Organizations基准架构由多个 AWS 账户 和服务组成。规划和实施应该是一个多阶段的过程，这样您就可以对较小的里程碑进行迭代，以实现设置基准安全架构的更大目标。本节基于结构化方法描述云之旅的典型阶段。这些阶段符合 Well-Architect AWS ed Framework 的安全设计原则。  

第 1 阶段：构建 OU 和账户结构

精心设计的 AWS 组织和账户结构是建立牢固安全基础的先决条件。如本指南前面的 SRA 构造块部分所述，拥有多个构 AWS 账户 件可以帮助您通过设计隔离不同的业务和安全功能。一开始这似乎是不必要的工作，但这是一项可以帮助您快速安全地扩展规模的投资。该部分还说明了 AWS Organizations 如何使用管理多个账户 AWS 账户，以及如何使用可信访问权限和委派管理员功能对这 AWS 服务 多个账户进行集中管理。

你可以AWS Control Tower按照本指南前面概述的方法来编排你的着陆区。如果您目前正在使用单个账户 AWS 账户，请参阅《过渡到多个账户 AWS 账户》指南，尽早迁移到多个账户。例如，如果您的初创公司目前正在单一构思和原型设计您的产品 AWS 账户，那么在将产品投放市场之前，您应该考虑采用多账户策略。同样，中小型和企业组织应在规划初始生产工作负载后立即开始制定其多账户战略。从基础开始 AWS 账户， OUs然后添加与工作负载相关的账户 OUs 和账户。

有关 AWS 账户 AWS SRA 中提供的内容之外的 OU 结构建议，请参阅中小型企业多账户策略博客文章。在最终确定 OU 和账户结构时，请考虑要使用服务控制策略 (SCPs)、资源控制策略 () 和声明性策略在组织范围内实施的高级安全控制。RCPs

设计注意事项

在设计组织单位和账户结构时，请勿复制公司的报告结构。您 OUs 应该基于工作负载功能和一组适用于工作负载的常用安全控制措施。不要试图从一开始就设计完整的账户结构。专注于基础知识 OUs，然后根据需要添加工作负载 OUs 。在设计的早期阶段，您可以在账户之间移动 OUs以尝试其他方法。但是，这可能会导致在管理逻辑权限方面产生一些开销，具体取决于 SCPs、 RCPs、声明性策略以及基于 OU 和账户路径的 IAM 条件。

实现示例

AWS SRA 代码库提供了 “账户备用联系人” 的实现示例。此解决方案为组织内的所有账户设置账单、运营和安全备用联系人。

第 2 阶段：建立坚实的身份基础

一旦你创建了多个账户 AWS 账户，你就应该允许你的团队访问这些账户中的 AWS 资源。身份管理一般分为两类：员工身份和访问管理以及客户身份和访问管理 (CIAM)。Workforce IAM 适用于员工和自动化工作负载需要登录 AWS 才能完成工作的组织。当组织需要一种方法来对用户进行身份验证以提供对组织应用程序的访问权限时，使用 CIAM。您首先需要制定员工 IAM 策略，这样您的团队才能构建和迁移应用程序。您应始终使用 IAM 角色而不是 IAM 用户来向人类或机器用户提供访问权限。按照 AWS SRA 指南，了解如何在组织管理和共享服务账户 AWS IAM Identity Center 中使用来集中管理对您的单点登录 (SSO) 访问权限。 AWS 账户该指南还提供了在您无法使用 IAM 身份中心时使用 IAM 联合身份验证的设计注意事项。

在使用 IAM 角色为用户提供 AWS 资源访问权限时，您应按照本指南的安全工具和组织管理部分所述使用 IAM Access Analyzer 和 IAM 访问顾问。这些服务可帮助您实现最低权限，这是一项重要的预防性控制措施，可帮助您建立良好的安全态势。 

设计注意事项

要实现最低权限，请设计流程以定期审查和了解您的身份与其正常运行所需的权限之间的关系。在学习过程中，请微调这些权限，并逐渐将其缩小到尽可能少的权限。为了实现可扩展性，这应该由您的中央安全团队和应用程序团队共同负责。使用基于资源的策略、权限边界、基于属性的访问控制和会话策略等功能，帮助应用程序所有者定义精细的访问控制。 

实施示例

AWS SRA 代码库提供了两个适用于此阶段的示例实现：

  • IAM 密码策略为用户设置账户密码策略，使其符合常见的合规性标准。

  • Access Analyz er 在委派的管理员账户中配置组织级分析器，在每个账户中配置账户级分析器。

第 3 阶段：保持可追溯性

当您的用户可以访问 AWS 并开始构建时，您将想知道谁在做什么、何时以及从何处开始做什么。您还需要了解潜在的安全配置错误、威胁或意外行为。更好地了解安全威胁可以使您确定适当的安全控制的优先顺序。要监控 AWS 活动，请按照 AWS SRA 的建议设置组织跟踪，方法是使用日志存档AWS CloudTrail帐户并将日志集中在日志存档帐户中。要监控安全事件 AWS Security Hub CSPM，请使用 Amazon 和 Ama GuardDuty zon Security Lake，如安全工具账户部分所述。 AWS Config 

设计注意事项

开始使用新版本时 AWS 服务，请确保为该服务启用特定于服务的日志，并将其存储为中央日志存储库的一部分。 

实施示例

AWS SRA 代码库提供了以下适用于此阶段的示例实现： 

第 4 阶段：在所有层面应用安全措施

此时，你应该：

  • 适合您的安全控制措施 AWS 账户。

  • 定义明确的账户和 OU 结构，其预防控制措施通过 SCPs、 RCPs、声明性策略以及最低权限 IAM 角色和策略进行定义。

  • 能够使用记录 AWS 活动 AWS CloudTrail；使用 AWS Security Hub CSPM、Amazon 和检测安全事件 AWS Config；使用 Amazon GuardDuty Security Lake 对专门构建的数据湖进行高级分析，以确保安全。

在此阶段，计划在组织的其他层面上应用安全保护，如在整个 AWS 组织中应用安全服务一节中所述。 AWS 您可以使用、、、、 AWS Certificate Manager (ACM)、Amazon、Amazon AWS WAF AWS Shield AWS Firewall Manager AWS Network Firewall、Amazon Route 53 和 Ama CloudFront zon VPC 等服务为您的网络层构建安全控制，如网络账户部分所述。当您向下移动技术堆栈时，请应用特定于您的工作负载或应用程序堆栈的安全控制。使用 VPC 终端节点、Amazon Inspector AWS Systems Manager AWS Secrets Manager、、和 Amazon Cognito，如应用程序账户部分所述。 

设计注意事项

在设计深度防御 (DiD) 安全控制时，请考虑缩放系数。您的中央安全团队不会有足够的带宽或完全了解每个应用程序在您的环境中的行为。让您的应用程序团队负责为其应用程序识别和设计正确的安全控制措施，并承担责任。中央安全团队应专注于提供正确的工具和咨询，以支持应用团队。要了解过去采用更加左移的安全方法的扩展机制， AWS 请参阅博客文章《Security Guardians 计划是如何 AWS 构建的，这是一种分配安全所有权的机制》。 

实施示例

AWS SRA 代码库提供了以下适用于此阶段的示例实现：

第 5 阶段：保护传输中的数据和静态数据

您的业务和客户数据是您需要保护的宝贵资产。 AWS 提供各种安全服务和功能，以保护动态和静态数据。如网络账户部分所述 AWS Certificate Manager，使用Amaz CloudFront on来保护通过互联网收集的动态数据。对于内部网络中的动态数据，请使用带的 Application Load Balancer AWS 私有证书颁发机构，如应用程序帐户部分所述。 AWS KMS 并 AWS CloudHSM 帮助您提供加密密钥管理以保护静态数据。 

第 6 阶段：为安全事件做好准备

在运行 IT 环境时，您会遇到安全事件，这些事件是 IT 环境日常操作的变化，表明可能存在违反安全策略或安全控制失败的情况。适当的可追溯性至关重要，这样您才能尽快意识到安全事件。同样重要的是要做好对此类安全事件进行分类和响应的准备，以便在安全事件升级之前采取适当的措施。准备工作可帮助您快速对安全事件进行分类，以了解其潜在影响。

AWS SRA 通过设计安全工具账户并在所有账户中部署常用安全服务 AWS 账户，使您能够检测整个 AWS 组织中的安全事件。 安全工具@@ 账户中的 Amazon Detective 可帮助您对安全事件进行分类并确定根本原因。在安全调查期间，您必须能够查看相关日志，以记录和了解事件的全部范围和时间表。当发生感兴趣的特定操作时，还需要日志来生成警报。 AWS SRA 建议使用中央日志存档帐户，用于所有安全和操作日志的不可变存储。您可以使用 CloudWatch Logs Insights 查询存储在 CloudWatch 日志组中的数据，使用 Amazon Athena 和 OpenSearch 亚马逊服务查询存储在 Amazon S3 中的数据。使用 Amazon Security Lake 自动集中来自 AWS 环境、软件即服务 (SaaS) 提供商、本地和其他云提供商的安全数据。按照 AWS SRA 的规定，在 Security Tools 帐户或任何专用帐户中@@ 设置订阅者，以查询这些日志以进行调查。 

AWS 安全事件响应帮助您自动执行安全事件响应、调查和修复。它提供了预先构建的行动手册和工作流程，可帮助您快速、一致地响应安全事件。启用主动响应功能后，安全事件响应将与 Security Hub CSPM 集成，并在 GuardDuty检测到安全发现时自动触发响应工作流程。该服务可帮助您在整个 AWS 组织中实现事件响应流程的标准化和自动化。如果您需要其他帮助，可以提出服务支持的案例，与 AWS 客户事件响应小组 (CIRT) 接触。

设计注意事项

  • 您应该从云之旅的一开始就开始做好检测和响应安全事件的准备。为了更好地利用有限的资源，请为您的 AWS 资源分配数据和业务重要性，以便在检测到安全事件时，可以根据所涉及资源的重要性确定分类和响应的优先级。 

  • 如本节所述，构建云安全架构的各个阶段本质上是按顺序排列的。但是，您不必等到一个阶段完全完成后再开始下一阶段。我们建议您采用迭代方法，即开始并行处理多个阶段，并随着云安全态势的发展而逐渐发展每个阶段。当你经历不同的阶段时，你的设计将不断演变。考虑根据您的特定需求量身定制下图所示的建议顺序。

构建云安全架构的顺序和迭代阶段。
实现示例

AWS SRA 代码库提供了侦探组织的示例实现，该组织通过将管理委托给账户（例如审计或安全工具）来自动启用 Amazon Detective，并为现有和未来的 AWS Organizations 账户配置 Detective。