本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # SRA 的基石 — AWS Organizations、账户和护栏 | | | --- | | 通过进行[简短的调查](https://amazonmr.au1.qualtrics.com/jfe/form/SV_e3XI1t37KMHU2ua)来影响 AWS 安全参考架构 (AWS SRA) 的未来。 | AWS 最好在 AWS[多账户策略](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html)以及身份和访问管理护栏的基础上使用安全服务、其控制和交互。这些护栏设置了您实施最低权限、职责分离和隐私的能力，并为决定需要哪些类型的控制、每项安全服务的管理位置以及它们如何在 SRA 中共享数据和权限提供了支持。 AWS 为您的 AWS 资源 AWS 账户 提供安全性、访问权限和计费界限，使您能够实现资源独立和隔离。如使用多个账户组织环境白皮书的 “使用多个账户*组织 AWS 环境” 的 “使用多个账户[的好处 AWS 账户” 部分所述，使用多个](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/benefits-of-using-multiple-aws-accounts.html)账户*在满足安全要求方面 AWS 账户 起着重要作用。例如，您可以根据职能、合规性要求或一组常用控件将工作负载组织到单独的账户中，并对组织单位 (OU) 内的账户进行分组，而不是镜像企业的报告结构。请牢记安全和基础架构，使您的企业能够随着工作负载的增长设置共同的护栏。这种方法在工作负载之间提供了强大的界限和控制。账户级分离与之相结合，用于将生产环境与 AWS Organizations开发和测试环境隔离开来，或者在处理不同分类（例如支付卡行业数据安全标准 (PCI DSS) 或《健康保险便携性与责任法案》(HIPAA)）等不同类别的数据的工作负载之间提供强大的逻辑界限。尽管您可能从一个账户开始您的 AWS 旅程，但 AWS 建议您随着工作负载规模和复杂性的增加而设置多个帐户。 权限允许您指定对 AWS 资源的访问权限。权限被授予被称为*委托人*（用户、群组和角色）的 IAM 实体。默认情况下，委托人一开始就没有权限。在您向他们授予权限 AWS 之前，IAM 委托人无法在其中执行任何操作，并且您可以设置防护栏，其范围与整个 AWS 组织一样广泛，也可以像委托人、操作、资源和条件的个人组合一样精细地适用。 # AWS Organizations 出于安全考虑 | | | --- | | 通过进行[简短的调查](https://amazonmr.au1.qualtrics.com/jfe/form/SV_e3XI1t37KMHU2ua)来影响 AWS 安全参考架构 (AWS SRA) 的未来。 | [AWS Organizations](https://aws.amazon.com/organizations/)随着 AWS 资源的增长和扩展，可以帮助你集中管理和治理环境。通过使用 AWS Organizations，您可以以编程方式创建新账户 AWS 账户、分配资源、对账户进行分组以组织工作负载，以及将策略应用于账户或账户组进行管理。一个 AWS 组织会整合你的， AWS 账户 这样你就可以把它们当作一个单位来管理。它有一个管理账户以及零个或多个成员账户。您的大部分工作负载都驻留在成员账户中，但某些集中管理的流程除外，这些流程必须位于管理账户或指定为委托管理员的账户中 AWS 服务。您可以从中心位置为安全团队提供工具和访问权限，以代表 AWS 组织管理安全需求。您可以通过在 AWS 组织内共享关键资源来减少资源重复。[您可以将帐户分组为 AWS 组织单位 (OUs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html)，这些单位可以根据工作负载的要求和目的代表不同的环境。 AWS Organizations 还提供了多项策略，使您能够对组织中的所有成员帐户集中应用额外的安全控制。本节重点介绍服务控制策略 (SCPs)、资源控制策略 (RCPs) 和声明性策略。 使用 AWS Organizations，您可以在 AWS 组织、OU 或账户级别使用[SCPs](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)和[RCPs](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html)应用权限护栏。 SCPs 是适用于组织账户内委托人的护栏，但管理账户除外（这是不在此账户中运行工作负载的原因之一）。当您将 SCP 附加到 OU 时，该 SCP 将由该组织下的子女 OUs 和账户继承。 SCPs 不要授予任何权限。相反，它们会指定您的委托人在 AWS 组织、组织单位或账户中可用的最大权限。您仍然需要将[基于身份或基于资源的策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html)附加到您的委托人或资源，才能实际 AWS 账户 向他们授予权限。例如，如果 SCP 拒绝访问所有 Amazon S3，则即使通过 IAM 策略明确****授予访问权限，受 SCP 影响的委托人也无法访问 Amazon S3。有关如何评估 IAM 策略、角色以及最终如何授予或拒绝访问权限的更多信息，请参阅 IAM 文档中的[策略评估逻辑](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html)。 SCPs RCPs 是适用于组织账户内资源的护栏，无论这些资源是否属于同一个组织。比如 SCPs， RCPs不要影响管理账户中的资源，也不要授予任何权限。当您将 RCP 附加到 OU 时，RCP 将由子项 OUs 和 OU 下的帐户继承。 RCPs 提供对组织中资源的最大可用权限的集中控制，目前支持其中的一部分 AWS 服务。在 SCPs 为您的设计时 OUs，我们建议您使用 [IAM 策略模拟器](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_testing-policies.html)评估更改。您还应查看 [IAM 中上次访问的服务数据](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html)，[AWS CloudTrail 并用于在 API 级别记录服务使用情况](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/how-cloudtrail-works.html)，以了解 SCP 更改的潜在影响。 SCPs 并且 RCPs 是独立的控制机构。您可以根据要实施的访问控制选择仅启用 SCPs 或 RCPs，或者同时使用这两种策略类型。例如，如果您想阻止组织的委托人访问组织外部的资源，则可以通过使用 SCPs来强制执行此控制。如果您想限制或阻止外部身份访问您的资源，则可以使用来强制执行此控制 RCPs。有关和的更多 RCPs 信息和用例 SCPs，请参阅 AWS Organizations 文档 RCPs中的[使用 SCPs 和](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_authorization_policies.html#when-to-use-scps-and-rcps)。 您可以使用 AWS Organizations 声明性策略 AWS 服务 在整个组织中大规模地集中声明和强制执行所需的配置。例如，您可以屏蔽整个组织中对 Amazon VPC 资源的公共互联网访问权限。与 SCPs 和等授权策略不同 RCPs，声明式策略是在 AWS 服务的控制平面中强制执行的。授权策略规范对访问的访问 APIs，而声明性策略则直接应用于服务级别以强制执行持久意图。 这些策略有助于确保始终保持的 AWS 服务 基准配置，即使服务引入了新功能或 APIs。当向组织添加新账户或创建新的主体和资源时，也会保持基准配置。声明式策略可以应用于整个组织或特定 OUs 或帐户。 每个用户 AWS 账户 都有一个 [root 用户](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html)，默认情况下该用户对所有 AWS 资源拥有完全权限。  作为安全最佳实践，我们建议您不要使用 root 用户，[只有少数任务](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks)明确需要 root 用户。如果您 AWS 账户 通过管理多个 AWS Organizations，则可以集中禁用 root 登录，然后代表所有成员账户执行 root 权限操作。[集中管理成员账户的根访问权限](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-enable-root-access.html)后，您可以删除根用户密码、访问密钥和签名证书，并停用成员账户的多因素身份验证 (MFA)。默认情况下，在集中管理的 root 访问权限下创建的新账户没有 root 用户证书。成员账户无法使用其根用户登录或为其根用户执行密码恢复。 [AWS Control Tower](https://aws.amazon.com/controltower/)提供了一种设置和管理多个帐户的简化方法。它可以自动设置 AWS 组织中的帐户，自动进行配置，应用[控制措施](https://docs.aws.amazon.com/controltower/latest/controlreference/controls-reference.html)（包括预防和侦查控制），并为您提供可见性的仪表板。附加的 IAM 管理策略（[权限边界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)）附加到特定的 IAM 委托人（用户或角色），用于设置基于身份的策略可以向 IAM 委托人授予的最大权限。 AWS Organizations 帮助您进行适用于[AWS 服务](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html)所有账户的配置。例如，您可以使用配置在 AWS 组织中执行的所有操作的集中日志记录 [CloudTrail，](https://aws.amazon.com/cloudtrail/)并防止成员帐户禁用日志记录。您还可以集中汇总您通过使用定义的规则的数据 [AWS Config](https://aws.amazon.com/config/)，这样您就可以审计工作负载的合规性并对变化做出快速反应。您可以使用[AWS CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html)集中管理各个账户和 AWS 组织 OUs 中的 CloudFormation 堆栈，这样您就可以自动配置一个新帐户以满足您的安全要求。 AWS Organizations 支持使用 SCPs 作为*拒绝列表*的默认配置。通过使用拒绝列表策略，成员账户管理员可以委托所有服务和操作，直到您创建并附加拒绝特定服务或一组操作的 SCP 为止。与允许列表相比，拒绝语句需要更少的维护，因为在 AWS 添加新服务时您不必更新它们。拒绝语句的字符长度通常较短，因此更容易保持在最大长度以内 SCPs。在`Effect`元素值为的语句中`Deny`，您还可以限制对特定资源的访问权限，或者定义何时生效 SCPs 的条件。相比之下，SCP 中的`Allow`语句适用于所有资源 (`"*"`)，并且不能受条件限制。有关更多信息和示例，请参阅 AWS Organizations 文档 SCPs中的[使用策略](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_strategies.html)。 **设计注意事项** 或者，要 SCPs 用作*允许列表*，您必须将 AWS 托管 `FullAWSAccess` SCP 替换为明确仅允许您想要允许的服务和操作的 SCP。要为指定账户启用权限，每个 SCP（从根目录到账户直接路径中的每个 OU，甚至附加到账户本身）都必须允许该权限。这种模式本质上更具限制性，可能适合高度监管和敏感的工作负载。这种方法要求您明确允许从到 OU 的路径中的每个 IAM 服务或操作。 AWS 账户 理想情况下，您可以结合使用拒绝列表和允许列表策略。使用允许列表定义允许在 AWS 组织内使用的 AWS 服务 已批准列表，并将此 SCP 附加到 AWS 组织的根目录。如果您的开发环境允许使用不同的服务集，则需要 SCPs 在每个 OU 中附加相应的服务。然后，您可以使用拒绝列表通过明确拒绝特定的 IAM 操作来定义企业护栏。 RCPs 适用于其子集的资源 AWS 服务。有关更多信息，请参阅 AWS Organizations 文档 RCPs中的[支持列表](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html#rcp-supported-services)。 AWS 服务 默认配置 AWS Organizations 支持使用 RCPs 作为拒绝列表。当您在组织 RCPs 中启用时，名`RCPFullAWSAccess`为的 AWS 托管策略将自动附加到组织根目录、每个 OU 和组织中的每个账户。您无法分离此策略。此默认 RCP 允许所有委托人和操作访问权限通过 RCP 评估。这意味着，在您开始创建和附加之前 RCPs，您的所有现有 IAM 权限将继续按原样运行。此 AWS 托管策略不授予访问权限。然后，您可以创 RCPs 作新的拒绝语句列表，以阻止对组织中资源的访问。 # 管理账户、可信访问权限和委派管理员 | | | --- | | 通过进行[简短的调查](https://amazonmr.au1.qualtrics.com/jfe/form/SV_e3XI1t37KMHU2ua)来影响 AWS 安全参考架构 (AWS SRA) 的未来。 | 管理账户（也称为 AWS 组织管理账户或组织管理账户）是独一无二的，不同于中的所有其他账户 AWS Organizations。创建 AWS 组织的是账户。通过此账户，您可以在 AWS 组织 AWS 账户 中创建、邀请其他现有账户加入 AWS 组织（两种类型均被视为*成员账户*）、从 AWS 组织中移除账户以及将 IAM 策略应用于 AWS 组织内的根账户或账户。 OUs 管理账户通过 SCPs、 RCPs和服务部署（例如 CloudTrail）部署通用安全防护栏，这将影响组织中的所有成员账户。 AWS 为了进一步限制管理账户中的权限，可以尽可能将这些权限委托给其他相应的账户，例如安全账户。 管理账户具有付款人账户的责任，并负责支付成员账户产生的所有费用。您无法切换 AWS 组织的管理帐户。一个 AWS 账户 人一次只能是一个 AWS 组织的成员。 由于管理账户的功能和影响范围，我们建议您限制对该账户的访问权限，并仅向需要权限的角色授予权限。可帮助您实现此目的的两个功能是[可信访问权限](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services.html)和[委派管理员](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrated-services-list.html)。您可以使用可信访问权限来启用您指定的名为 AWS 服务 *可信服务的可信服务*，以代表您执行 AWS 组织及其账户中的任务。这涉及向信任服务授予权限，但不会以其他方式影响 IAM 用户或角色的权限。您可以使用可信访问权限来指定您希望受信任的服务代表您保留在 AWS 组织账户中的设置和配置详细信息。例如， AWS SRA 的[组织管理账户](org-management.md)部分说明了如何向 CloudTrail 服务授予可信访问权限，以便在 CloudTrail 组织中的所有账户中创建 AWS 组织跟踪。 有些 AWS 服务 支持中的委托管理员功能 AWS Organizations。使用此功能*，*兼容的服务可以将 AWS 组织中的 AWS成员帐户注册为该服务中 AWS 组织帐户的管理员。此功能为企业内的不同团队提供了灵活性，使他们能够根据自己的职责使用不同的账户来管理 AWS 服务 整个环境。 AWS SRA 中目前支持委托管理员 AWS 的安全服务包括 IAM 身份中心、、、亚马逊、IAM Access Analyzer AWS Config AWS Firewall Manager、Amazon Macie GuardDuty、云安全态势管理AWS Security Hub CSPM()、Amazon Detective AWS Security Hub 、Amazon Inspector、Amazon Inspector 和。 AWS Audit Manager AWS Systems Manager作为最佳实践， AWS SRA 强调使用委派管理员功能，我们将安全相关服务的管理委托给安全工具账户。 # 专用账户结构 | | | --- | | 通过进行[简短的调查](https://amazonmr.au1.qualtrics.com/jfe/form/SV_e3XI1t37KMHU2ua)来影响 AWS 安全参考架构 (AWS SRA) 的未来。 | 为您的 AWS 资源 AWS 账户 提供安全性、访问权限和计费界限，并使您能够实现资源独立和隔离。默认不允许在账户之间进行访问。 在设计 OU 和账户结构时，首先要考虑安全性和基础架构。我们建议 OUs 为这些特定功能创建一组基础知识，分为 “基础架构” 和 “安全 OUs”。这些 OU 和账户建议包含了我们更广泛、更全面的 AWS Organizations 多账户结构设计指南中的一部分。有关全套建议，请参阅 AWS 文档中的[使用多个账户组织 AWS 环境](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html)，以及博客文章《[组织单位最佳实践](https://aws.amazon.com/blogs/mt/best-practices-for-organizational-units-with-aws-organizations/)》 AWS Organizations。 AWS SRA利用以下帐户来实现有效的安全操作。 AWS这些专用账户有助于确保职责分工，为不同的应用程序和数据敏感度支持不同的治理和访问策略，并有助于减轻安全事件的影响。在接下来的讨论中，我们将重点介绍生产（*生产*）客户及其相关的工作负载。软件开发生命周期 (SDLC) 帐户（通常称为*开发*和*测试*帐户）用于暂存可交付成果，并且可以在与生产帐户不同的安全策略下运行。 | | | **Account** | **OU** | **安全角色** | | --- |--- |--- | | 管理  | — | 对所有人和账户进行中央治理 AWS 区域 和管理。 AWS 账户 承载 AWS 组织根的。 | | 安全工具 | 安全性 | 专门 AWS 账户 用于运营广泛适用的安全服务（例如 Security Hub CSPM GuardDuty、Audit Manager、Detective、Amazon Inspector 和 AWS Config） AWS 账户、监控和自动发送安全警报和响应。（在中 AWS Control Tower，安全 OU 下帐户的默认名称为 “*审核帐户*”。） | | 日志存档 | 安全性 | 专门 AWS 账户 用于接收和存档所有和的所有日志记录和备份。 AWS 区域 AWS 账户这应该设计为不可变的存储。 | | Network | Infrastructure | 您的应用程序和更广泛的互联网之间的网关。网络帐户将更广泛的网络服务、配置和操作与单个应用程序工作负载、安全和其他基础设施隔离开来。 | | 共享服务 | Infrastructure | 此账户支持多个应用程序和团队用来交付成果的服务。示例包括身份中心目录服务（Active Directory）、邮件服务和元数据服务。 | | 应用程序 | 工作负载 | AWS 账户 托管 AWS 组织的应用程序并执行工作负载。（这些帐户有时被称为*工作负载帐户*。） 应创建应用程序帐户以隔离软件服务，而不是映射到您的团队。这使得部署的应用程序更能适应组织变革。 | # AWS AWS SRA 的组织和账户结构 | | | --- | | 通过进行[简短的调查](https://amazonmr.au1.qualtrics.com/jfe/form/SV_e3XI1t37KMHU2ua)来影响 AWS 安全参考架构 (AWS SRA) 的未来。 | 下图捕捉了 AWS SRA 的高级结构，但不显示特定的服务。它反映了上一节中讨论的专用账户结构，我们在此处加入了图表，以围绕架构的主要组件进行讨论： + 图中显示的所有账户都属于一个 AWS 组织。 + 图的左上角是组织管理账户，用于创建 AWS 组织。 + 组织管理账户下方是具有两个特定帐户的安全 OU：一个用于安全工具，另一个用于日志存档。 + 右侧是带有网络帐户和共享服务帐户的基础架构 OU。 + 图的底部是工作负载 OU，它与存放企业应用程序的应用程序帐户相关联。 在本指南中，所有账户都被视为在单个 AWS 区域账户中运行的生产（生产）账户。大多数 AWS 服务 （[全球服务](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/global-services.html)除外）都是按区域划分的，这意味着服务的控制平面和数据平面独立存在于每个服务中。 AWS 区域因此，您必须在计划使用的所有 AWS 区域 内容中复制此架构，以确保覆盖整个 AWS 景观。如果您在特定区域中没有任何工作负载 AWS 区域，则应使用[SCPs](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples_general.html#example-scp-deny-region)或使用日志和监控机制禁用该区域。您可以使用 Security Hub CSPM 将多个聚合区域的发现结果和安全评分汇总 AWS 区域 到单个聚合区域，以实现集中可见性。 在托管拥有大量账户的 AWS 组织时，拥有一个便于账户部署和账户管理的协调层是有益的。 AWS Control Tower 提供了一种设置和管理 AWS 多账户环境的简单方法。[GitHub 存储库](https://github.com/aws-samples/aws-security-reference-architecture-examples)中的 AWS SRA 代码示例演示了如何使用[定制 AWS Control Tower (cfcT)](https://aws.amazon.com/solutions/implementations/customizations-for-aws-control-tower/) 解决方案来部署 AWS SRA 推荐的结构。 ![\[AWS SRA 的高级结构（不含服务）。\]](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/security-reference-architecture/images/consolidated.png) # 在整个 AWS 组织中应用安全服务 | | | --- | | 通过进行[简短的调查](https://amazonmr.au1.qualtrics.com/jfe/form/SV_e3XI1t37KMHU2ua)来影响 AWS 安全参考架构 (AWS SRA) 的未来。 | 如[前一节](value.md)所述，客户正在寻找另一种方法来思考和战略性地组织全套 AWS 安全服务。*当今最常见的组织方法是按主要职能对安全服务进行分组，具体取决于每项服务的用途。* AWS CAF 的安全视角列出了九项功能，包括身份和访问管理、基础设施保护、数据保护和威胁检测。 AWS 服务 与这些功能能力相匹配是在每个领域做出实施决策的实用方法。例如，在考虑身份和访问管理时，IAM 和 IAM 身份中心是需要考虑的服务。在设计威胁检测方法时， GuardDuty 可能是您的首要考虑因素。 作为此功能视图的补充，您还可以使用跨领域的结构视图来查看您的安全性。也就是说，除了问 “我 AWS 服务 应该用哪个来控制和保护我的身份、逻辑访问或威胁检测机制？” ，你也可以问：“我 AWS 服务 应该在整个 AWS 组织中申请哪个？ 我应该设置哪些防御层来保护作为应用程序核心的 Amazon EC2 实例？” 在此视图中，您可以将地图 AWS 服务 和要素映射到 AWS 环境中的图层。有些服务和功能非常适合在整个 AWS 组织中实施控制措施。例如，阻止公众访问 Amazon S3 存储桶是该层的特定控制措施。最好在根组织中完成，而不是作为个人账户设置的一部分。最好使用其他服务和功能来帮助保护内部的个人资源 AWS 账户。此类别的一个例子是，在需要私有 TLS 证书的账户中实现从属证书颁发机构 (CA)。另一个同样重要的分组包括对 AWS 基础架构的虚拟网络层产生影响的服务。下图显示了典型 AWS 环境中的六个层： AWS 组织、组织单位 (OU)、帐户、网络基础架构、委托人和资源。 ![\[AWS 环境中的六层。\]](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/security-reference-architecture/images/six-layers.png) 了解这种结构环境中的服务，包括每层的控制和保护，可以帮助您在整个 AWS 环境中规划和实施 defense-in-depth策略。从这个角度来看，你可以自上而下地回答两个问题（例如，“我使用哪些服务在整个 AWS 组织中实施安全控制？”） 并自下而上（例如，“哪些服务管理对此 EC2 实例的控制？”）。在本节中，我们将介绍 AWS 环境的各个要素，并确定相关的安全服务和功能。当然，有些 AWS 服务 具有广泛的功能集并支持多个安全目标。这些服务可能支持您 AWS 环境的多个元素。 为清楚起见，我们简要描述了某些服务如何符合既定目标。[下一节](architecture.md)将进一步讨论每项服务中的各项服务 AWS 账户。 ## 组织范围的账户或多个账户 在顶层，有 AWS 服务 一些功能旨在将治理和控制能力或护栏应用于组织中的多个帐户（包括整个 AWS 组织或特定 OUs组织）。服务控制策略 (SCPs) 和资源控制策略 (RCPs) 是 IAM 功能的良好示例，这些功能为 AWS 整个组织提供预防性护栏。 AWS Organizations 还提供了一个声明性策略，用于集中定义和强制执行大规模的基准 AWS 服务 配置。另一个例子是 CloudTrail，它通过*组织跟踪提供监控，该跟踪*记录了该 AWS 组织 AWS 账户 中所有人的所有事件。这种全面的跟踪不同于可能在每个账户中创建的单个跟踪。第三个示例是 AWS Firewall Manager，您可以使用它来配置、应用和管理 AWS 组织中所有账户的多种资源： AWS WAF 规则、 AWS WAF 经典规则、 AWS Shield Advanced 保护、Amazon Virtual Private Cloud (Amazon VPC) 安全组、 AWS Network Firewall 策略和 Amazon Route 53 Resolver DNS 防火墙策略。 下图中标有星号 (\$1) 的服务具有双重范围：组织范围和以客户为中心。这些服务从根本上监控或帮助控制个人账户的安全性。但是，它们还支持将多个账户的结果汇总到一个组织范围的账户中，以实现集中可见性和管理。为清楚起见 SCPs ，请考虑这适用于整个 OU 或 AWS 组织。 AWS 账户相比之下，您可以在账户级别（生成个人调查结果的地方）和 AWS 组织级别（使用委托管理员功能）配置和管理 GuardDuty ，在这些级别上，可以聚合查看和管理调查结果。 ![\[全组织范围和以客户为中心的安全服务。\]](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/security-reference-architecture/images/org-multi-account.png) ## AWS 账户 在内部 OUs，有一些服务可以帮助保护其中多种类型的元素 AWS 账户。例如，通常 AWS Secrets Manager 由特定账户进行管理，并保护该账户中的资源（例如数据库凭据或身份验证信息）、应用程序和该账户 AWS 服务 中的资源。可以将 IAM Access Analyzer 配置为在外部委托人可以访问指定资源时生成调查结果。 AWS 账户如上一节所述，其中许多服务也可以在其中配置和管理 AWS Organizations，因此可以跨多个账户进行管理。这些服务在图中标有星号 (\$1)。它们还可以更轻松地汇总来自多个账户的结果并将其发送到单个账户。这为各个应用程序团队提供了灵活性和可见性，以管理特定于其工作负载的安全需求，同时还允许集中式安全团队进行管理和可见性。 GuardDuty 就是此类服务的一个例子。 GuardDuty 监控与单个账户关联的资源和活动，并且可以通过委派的管理员账户收集、查看和管理来自多个成员账户（例如 AWS 组织中的所有账户）的 GuardDuty 调查结果。 ![\[保护 AWS 账户内多种类型元素的安全服务。\]](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/security-reference-architecture/images/aws-account.png) ## 虚拟网络、计算和内容交付 由于网络访问对安全至关重要，而计算基础设施是许多 AWS 工作负载的基本组成部分，因此有许多 AWS 安全服务和功能专用于这些资源。例如，Amazon Inspector 是一项漏洞管理服务，可以持续扫描您的 AWS 工作负载中是否存在漏洞。这些扫描包括网络可访问性检查，这些检查表明您的环境中允许通往 Amazon EC2 实例的网络路径。Amazon VPC 允许您定义一个可以在其中启动 AWS 资源的虚拟网络。该虚拟网络与传统网络非常相似，具有多种功能和优点。VPC 终端节点使您能够私密地将您的 VPC 连接到支持的终端节点服务 AWS 服务 以及由其提供支持的终端节点服务， AWS PrivateLink 而无需访问互联网的路径。下图说明了以网络、计算和内容交付基础设施为重点的安全服务。 ![\[以网络、计算或内容交付基础设施为重点的安全服务\]](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/security-reference-architecture/images/virtual-network.png) ## 校长和资源 AWS 委托人和 AWS 资源（以及 IAM 策略）是上 AWS身份和访问管理的基本要素。中经过身份验证的委托人 AWS 可以执行操作和访问 AWS 资源。委托人可以作为 AWS 账户 根用户和 IAM 用户进行身份验证，也可以通过担任角色进行身份验证。  **注意** 请勿创建与 AWS 根用户账户关联的永久性 API 密钥。root 用户帐户的访问权限应仅限于[需要 root 用户的任务，](https://docs.aws.amazon.com/general/latest/gr/root-vs-iam.html#aws_tasks-that-require-root)并且只能通过严格的例外和批准流程进行访问。有关保护账户根用户的最佳实践，请参阅 [IAM 文档](https://docs.aws.amazon.com/accounts/latest/reference/best-practices-root-user.html)。 AWS 资源是存在于中的一个对象 AWS 服务 ，可供您使用。示例包括 EC2 实例、 CloudFormation 堆栈、亚马逊简单通知服务 (Amazon SNS) Service 主题和 S3 存储桶。IAM 策略是在与 IAM 委托人（用户、群组或角色）或 AWS 资源关联时定义权限的对象。[基于身份的策略****](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html)是您附加到委托人（角色、用户和用户组）的策略文档，用于控制委托人可以执行哪些操作、对哪些资源以及在哪些条件下执行哪些操作。[基于资源的策略****](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html)是您附加到资源（例如 S3 存储桶）的策略文档。这些策略向指定的委托人授予对该资源执行特定操作的权限，并定义该权限的条件。基于资源的策略是内联策略。I [AM 资源](iam-resources.md)部分深入探讨了 IAM 策略的类型及其使用方式。 为了简化本次讨论，我们列出了面向以账户委托人操作或申请账户委托人为主要目的的 IAM 委托人的 AWS 安全服务和功能。我们保持这种简单性，同时承认 IAM 权限策略的灵活性和影响广度。策略中的单个声明可以对多种类型的 AWS 实体产生影响。例如，尽管基于 IAM 身份的策略与 IAM 委托人关联并定义了该委托人的权限（允许、拒绝），但该策略还隐式定义了对指定操作、资源和条件的权限。这样，基于身份的策略可以成为定义资源权限的关键要素。 下图说明了为 AWS 委托人提供的 AWS 安全服务和功能。基于身份的策略附加到 IAM 用户、组或角色。这些策略可让您指定该身份可执行哪些操作（其权限）。IAM 会话策略是用户代入角色时在会话中传递的[内联权限策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html)。您可以自己传递策略，也可以将身份代理配置为[在您的身份联合到 AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html)时插入策略。这使您的管理员能够减少必须创建的角色数量，因为多个用户可以扮演相同的角色，但具有唯一的会话权限。IAM Identity Center 服务与 AWS Organizations AWS API 操作集成，可帮助您管理 SSO 访问权限和用户权限。 AWS 账户 AWS Organizations ![\[AWS 为账户委托人提供的安全服务和功能。\]](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/security-reference-architecture/images/principals.png) 下图说明了账户资源的服务和功能。基于资源的策略附加到某个资源。例如，您可以将基于资源的策略附加到 S3 存储桶、亚马逊简单队列服务 (Amazon SQS) Simple Queue SQUEE 队列、VPC 终端节点和加密密钥。 AWS KMS 您可以使用基于资源的策略来指定谁有权访问资源以及他们可以对资源执行哪些操作。S3 存储桶策略、 AWS KMS 密钥策略和 VPC 终端节点策略是基于资源的策略的类型。IAM Access Analyzer帮助您标识企业和账户中与外部实体共享的资源，例如 S3 存储桶或 IAM 角色。这使您可以识别对您的资源和数据的意外访问，这是一种安全风险。 AWS Config 使您能够评估、审核和评估中受支持 AWS 资源的配置 AWS 账户。 AWS Config 持续监控和记录 AWS 资源配置，并根据所需的配置自动评估记录的配置。 ![\[AWS 账户资源的安全服务和功能。\]](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/security-reference-architecture/images/resources.png)