AWS SRA 的价值 - AWS 规范性指导
如何使用 AWS SRAAWS SRA 的关键实施指南

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

AWS SRA 的价值

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

AWS 拥有大量与安全和安全相关的服务（而且还在不断增长）。客户对通过我们的服务文档、博客文章、教程、峰会和会议提供的详细信息表示感谢。他们还告诉我们，他们希望更好地了解大局并从战略角度了解 AWS 安全服务。当我们与客户合作以更深入地了解他们的需求时，会出现三个优先事项：

  • 客户需要更多信息和推荐模式，了解他们如何全面部署、配置和运营 AWS 安全服务。应在哪些账户中部署和管理服务，以实现哪些安全目标？  是否有一个安全账户可以运行所有或大多数服务？  地点（组织单位或 AWS 账户）的选择如何影响安全目标？ 客户应该注意哪些权衡取舍（设计注意事项）？

  • 客户有兴趣看到逻辑组织许多 AWS 安全服务的不同视角。除了每项服务（例如身份服务或日志服务）的主要功能外，这些替代观点还可以帮助客户规划、设计和实施其安全架构。本指南稍后分享的示例根据与 AWS 环境推荐结构一致的保护层对服务进行分组。

  • 客户正在寻找指导和示例，以最有效的方式集成安全服务。例如，他们应如何最好地将 AWS Config 与其他服务协调和连接，以完成自动审计和监控管道中的繁重工作？  客户正在寻求有关每个 AWS 安全服务如何依赖或支持其他安全服务的指导。

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

如何使用 AWS SRA

AWS SRA 的使用方式各不相同，具体取决于您在云采用之旅中所处的阶段。以下列出了从 AWS SRA 资产中获得最大洞察力的方法（架构图、书面指南和代码示例）。

  • 为自己的安全架构@@ 定义目标状态。

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

  • 审查（并修改）您已经实施的设计和功能。

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

  • 引导您自己的安全架构的实现。

AWS SRA 基础设施即代码 (IaC) 模块提供了一种快速、可靠的方式来开始构建和实施您的安全架构。在代码存储库部分和公共 GitHub 存储库中对这些模块进行了更深入的描述。它们不仅使工程师能够在 AWS SRA 指南中的高质量模式示例的基础上再接再厉，而且还纳入了推荐的安全控制措施，例如 AWS 身份和访问管理 (IAM) 密码策略、亚马逊简单存储服务 (Amazon S3) Simple Storage Service 封锁账户公开访问、亚马逊 EC2 默认亚马逊弹性区块存储 (Amazon EBS) Elastic Block Store 加密以及与 AWS 的集成 Control Tower，以便在新的 AWS 账户加入或停用时应用或删除控制措施。

  • 了解有关 AWS 安全服务和功能的更多信息。

AWS SRA 中的指导和讨论包括各个 AWS 安全和安全相关服务的重要功能以及部署和管理注意事项。AWS SRA 的一个特点是，它提供了对 AWS 安全服务的广泛性以及它们如何在多账户环境中协同工作的高级介绍。这补充了对其他来源中每项服务的功能和配置的深入研究。这方面的一个例子是讨论 AWS Security Hub 如何从各种 AWS 服务、AWS 合作伙伴产品甚至您自己的应用程序中提取安全发现。

  • 推动关于组织治理和安全责任的讨论。

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

AWS SRA 的关键实施指南

以下是 AWS SRA 的八个关键要点，供您在设计和实施安全措施时牢记在心。  

  • AWS Organizations 和适当的多账户策略是您的安全架构的必要元素。正确分离工作负载、团队和职能为职责和 defense-in-depth 策略的分离奠定了基础。本指南将在后面的章节中对此进行进一步介绍。

  • D efense-in-depth 是为组织选择安全控制措施的重要设计考虑因素。它可以帮助您在 AWS Organizations 结构的不同层面注入适当的安全控制措施，这有助于最大限度地减少问题的影响：如果某一层存在问题，则有控制措施可以隔离其他宝贵的 IT 资源。AWS SRA 演示了不同的 AWS 服务如何在 AWS 技术堆栈的不同层面发挥作用，以及将这些服务结合使用如何帮助您实现目标 defense-in-depth。AWS 上的这个 defense-in-depth 概念将在后面的章节中进一步讨论，并在应用程序账户下显示设计示例。

  • 使用跨多个 AWS 服务和功能的各种安全构建块来构建强大而有弹性的云基础设施。在根据您的特定需求定制 AWS SRA 时，不仅要考虑 AWS 服务和功能的主要功能（例如身份验证、加密、监控、权限策略），还要考虑它们如何融入您的架构结构。本指南的后面部分将介绍某些服务如何在整个 AWS 组织中运行。其他服务最好在单个账户中运行，有些服务旨在向个人委托人授予或拒绝许可。考虑这两个角度可以帮助您构建更灵活、更分层的安全方法。

  • 在可能的情况下（详见后面的章节），使用可在每个账户中部署的 AWS 服务（分布式而非集中式），并构建一组一致的共享护栏，以帮助保护您的工作负载免遭滥用并帮助减少安全事件的影响。AWS SRA 使用 AWS Security Hub（集中式发现监控和合规性检查）、亚马逊 GuardDuty （威胁检测和异常检测）、AWS Config（资源监控和变更检测）、IAM 访问分析器 CloudTrail （资源访问监控、AWS（记录环境中的服务 API 活动）和 Amazon Macie（数据分类）作为在每个 AWS 账户中部署的 AWS 服务的基础。

  • 使用 AWS Organizations 的委托管理功能，该功能受支持，如本指南的委托管理部分稍后所述。这样，您就可以将 AWS 成员账户注册为受支持服务的管理员。委托管理为企业内的不同团队提供了灵活性，让他们能够根据自己的职责使用不同的账户来管理整个环境中的 AWS 服务。此外，使用授权管理员可以帮助您限制对 AWS Organizations 管理账户的访问权限并管理其权限开销。

  • 在您的 AWS 组织中实施集中式监控、管理和治理。通过使用支持多账户（有时是多区域）聚合的 AWS 服务以及委托管理功能，您可以让您的中央安全、网络和云工程团队能够广泛了解和控制适当的安全配置和数据收集。此外，可以将数据提供给工作负载团队，使他们能够在软件开发生命周期 (SDLC) 的早期做出有效的安全决策。

  • 使用 AWS Control Tower 来设置和管理您的多账户 AWS 环境，通过实施预先构建的安全控制来启动您的安全参考架构构建。AWS Control Tower 提供了一个蓝图，用于提供身份管理、账户联合访问权限、集中日志记录以及用于配置其他账户的定义工作流程。然后，您可以使用 AWS Control Tower 的定制 (cfcT) 解决方案，为 AWS Control Tower 管理的账户提供额外的安全控制、服务配置和治理，如 AWS SRA 代码存储库所示。账户出厂功能可根据已批准的账户配置自动使用可配置的模板为新账户配置以实现您的 AWS Organizations 中的账户标准化。您还可以通过将现有的 AWS 账户注册到已由 AWS Control Tower 管理的组织单位 (OU) 来将监管范围扩展到该账户。

  • AWS SRA 代码示例演示了如何使用基础设施即代码 (IaC) 自动实施 AWS SRA 指南中的模式。通过编纂模式，您可以像对待组织中的其他应用程序一样对待 IaC，并在部署代码之前自动进行测试。IaC 还通过在多个（例如 SDLC 或特定区域）环境中部署护栏，帮助确保一致性和可重复性。SRA 代码示例可以部署在带或不带 AWS Control Tower 的 AWS Organizations 多账户环境中。此存储库中需要 AWS Control Tower 的解决方案已在 AWS 控制塔环境中使用 AWS CloudFormation 和 AWS 控制塔定制 (cfcT) 进行部署和测试。不需要 AWS Control Tower 的解决方案已在 AWS Organizations 环境中使用 AWS 进行了测试 CloudFormation。如果您不使用 AWS Control Tower，则可以使用基于 AWS 组织的部署解决方案。