本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
工作负载 OU — 应用程序帐户
| 通过进行简短的调查 |
下图说明了在应用程序账户中配置的 AWS 安全服务（以及应用程序本身）。
应用程序帐户托管用于运行和维护企业应用程序的主要基础设施和服务。应用程序帐户和工作负载 OU 有几个主要的安全目标。首先，您可以为每个应用程序创建一个单独的帐户，以便在工作负载之间提供界限和控制，从而避免角色、权限、数据和加密密钥混合的问题。你想提供一个单独的账户容器，应用团队可以在不影响其他人的情况下获得管理自己的基础架构的广泛权限。接下来，您可以通过为安全运营团队提供监控和收集安全数据的机制来增加一层保护。采用组织跟踪和本地部署账户安全服务（亚马逊 GuardDuty、AWS Config、AWS Security Hub、亚马逊 EventBridge、AWS IAM Access Analyzer），这些服务由安全团队配置和监控。最后，您可以让企业集中设置控制。您可以使应用程序帐户与更广泛的安全结构保持一致，方法是使其成为 Workdloads OU 的成员，通过该组织单元继承相应的服务权限、约束和护栏。
设计考虑
-
在您的组织中，您可能有多个业务应用程序。工作负载 OU 旨在容纳大多数特定于业务的工作负载，包括生产和非生产环境。这些工作负载可以是商用 off-the-shelf (COTS) 应用程序和您自己内部开发的自定义应用程序和数据服务的混合体。组织不同的业务应用程序及其开发环境的模式很少。一种模式是根据您的开发环境（例如生产、暂存、测试和开发）创建多个子 OU，并在与不同应用程序相关的这些 OU 下使用单独的子 AWS 账户。另一种常见模式是为每个应用程序设置单独的子 OU，然后为各个开发环境使用单独的子 AWS 账户。确切的 OU 和账户结构取决于您的应用程序设计以及管理这些应用程序的团队。考虑一下您要实施的安全控制，无论它们是特定环境还是特定于应用程序，因为将这些控制作为 SCP 在 OU 上实施会更容易。有关组织面向工作负载的 OU 的更多注意事项，请参阅 AWS 白皮书《使用多个账户组织您的 AWS 环境》中的 “组织面向工作负载的 OU” 部分。
应用程序 VPC
应用程序账户中的虚拟私有云 (VPC) 既需要入站访问权限（用于您正在建模的简单 Web 服务），也需要出站访问（用于应用程序需求或 AWS 服务需求）。默认情况下，VPC 内的资源可以相互路由。有两个私有子网：一个用于托管 EC2 实例（应用程序层），另一个用于 Amazon Aurora（数据库层）。不同层（例如应用层和数据库层）之间的网络分段是通过 VPC 安全组完成的，VPC 安全组限制了实例级别的流量。为了提高弹性，工作负载跨越两个或多个可用区，每个区域使用两个子网。
设计考虑
-
您可以使用流量镜像从 EC2 实例的 elastic network 接口复制网络流量。然后，您可以将流量发送到 out-of-band 安全和监控设备进行内容检查、威胁监控或故障排除。例如，您可能想要监控离开您的 VPC 的流量或来源在您的 VPC 之外的流量。在这种情况下，您将镜像除在您的 VPC 内经过的流量之外的所有流量，并将其发送到单个监控设备。Amazon VPC 流日志不捕获镜像流量；它们通常仅从数据包标头中捕获信息。流量镜像允许您分析包括有效载荷在内的实际流量内容，从而更深入地了解网络流量。仅对可能作为敏感工作负载一部分运行或在出现问题时需要详细诊断的 EC2 实例的 elastic network interface 启用流量镜像。
VPC 端点
VPC 端点提供了另一层安全控制以及可扩展性和可靠性。使用它们将您的应用程序 VPC 连接到其他 AWS 服务。（在应用程序账户中，AWS SRA 使用 AWS KMS、AWS Systems Manager 和 Amazon S3 的 VPC 终端节点。） 终端节点是虚拟设备。它们是水平扩展、冗余和高度可用的 VPC 组件。通过它们，可以在 VPC 中的实例与服务之间进行通信，而不会对网络通信带来可用性风险或带宽约束。您可以使用 VPC 终端节点将您的 VPC 私密连接到支持的 AWS 服务和由 AWS 提供支持的 VPC 终端节点服务， PrivateLink 而无需互联网网关、NAT 设备、VPN 连接或 AWS Direct Connect 连接。您的 VPC 中的实例不需要公有 IP 地址即可与其他 AWS 服务通信。您的 VPC 与其他 AWS 服务之间的流量不会离开亚马逊网络。
使用 VPC 终端节点的另一个好处是可以配置终端节点策略。VPC 终端节点策略是一种 IAM 资源策略，您在创建或修改端点时可将它附加到端点。如果您在创建终端节点时未附加 IAM 策略，AWS 会为您附加默认 IAM 策略，允许您完全访问该服务。终端节点策略不会覆盖或替换 IAM 策略或特定于服务的策略（例如 S3 存储桶策略）。它是一个单独的 IAM 策略，用于控制从终端节点到指定服务的访问权限。通过这种方式，它增加了另一层控制 AWS 委托人可以与资源或服务进行通信。
Amazon EC2
构成我们应用程序的 Amazon EC
使用单独的 VPC（作为账户边界的子集）按工作负载分段隔离基础架构。可以使用子网隔离单个 VPC 中的应用程序层（例如，Web、应用程序和数据库）。如果不应直接从 Internet 访问实例，请使用私有子网访问。要在不使用互联网网关的情况下从您的私有子网调用 Amazon EC2 API，请使用 AWS PrivateLink。使用安全组限制对您的实例的访问。使用 VPC Flow Logs 监控到达实例的流量。使用会话管理器（AWS Systems Manager 的一项功能）远程访问您的实例，而不必打开入站 SSH 端口和管理 SSH 密钥。使用单独的 Amazon Elastic Block Store (Amazon EBS) 卷存储操作系统和您的数据。您可以将您的 AWS 账户配置为对您创建的新 EBS 卷和快照副本强制加密。
实现示例
AWS SRA 代码库
Application Load Balancer
应用程序负载均衡器
AWS Certifice Manager (ACM) 以原生方式与应用程序负载均衡器集成，AWS SRA 使用 ACM 生成和管理必要的 X.509（TLS 服务器）公共证书。您可以通过 Application Load Balancer 安全策略为前端连接强制执行 TLS 1.2 和强密码。有关更多信息，请参阅 Elastic Load Balancing 文档。
设计注意事项
-
对于常见场景，例如需要在 Application Load Balancer 上使用私有 TLS 证书的严格内部应用程序，您可以使用此账户中的 ACM 从AWS 私有 CA生成私有证书。在 AWS SRA 中，ACM 根私有 CA 托管在安全工具账户中，可以与整个 AWS 组织或特定 AWS 账户共享，以颁发最终实体证书，如前面安全工具账户部分所述。
-
对于公共证书，您可以使用 ACM 生成并管理这些证书，包括自动轮换。或者，您可以使用 SSL/TLS 工具生成自己的证书，创建证书签名请求 (CSR)，获取由证书颁发机构 (CA) 签署的 CSR 以生成证书，然后将证书导入 ACM 或将证书上传到 IAM，以便与 Application Load Balancer 一起使用。如果将证书导入 ACM，则必须监控证书的到期日期，并在证书到期之前对其进行续订。
-
要获得更多防御层，您可以部署 AWS WAF 策略来保护 Application Load Balancer。拥有边缘策略、应用程序策略，甚至是私有或内部策略实施层，可以提高通信请求的可见性，并提供统一的策略实施。有关更多信息，请参阅博客文章使用适用于 AWS WAF 的 AWS 托管规则深入部署防御
。
AWS 私有 CA
AWS Private Certificate Authority(AWS 私有 CA) 在应用程序账户中用于生成要与 Application Load Balancer 配合使用的私有证书。应用程序负载均衡器通常会通过 TLS 提供安全内容。这需要在 Application Load Balancer 上安装 TLS 证书。对于严格属于内部的应用程序，私有 TLS 证书可以提供安全通道。
在 AWS SRA 中AWS 私有 CA，托管在安全工具账户中，并使用 AWS RAM 共享到应用程序账户。这允许应用程序账户中的开发者向共享的私有 CA 申请证书。在您的组织或多个 AWS 账户之间共享 CA 有助于降低在所有 AWS 账户中创建和管理重复 CA 的成本和复杂性。当您使用 ACM 从共享 CA 颁发私有证书时，证书将在请求的账户中本地生成，并且 ACM 提供完整的生命周期管理和续订。
Amazon Inspector
AWS SRA 使用 A mazon Inspec
Amazon Inspector 被置于应用程序账户中，因为它为该账户中的 EC2 实例提供漏洞管理服务。此外，Amazon Inspector 还会报告进出 EC2 实例的不想要的网络路径。
成员账户中的 Amazon Inspector 由委托管理员账户集中管理。在 AWS SRA 中，安全工具账户是委派的管理员账户。委派的管理员帐户可以管理组织成员的调查结果数据和某些设置。这包括查看所有成员账户的汇总结果详情、启用或禁用对成员账户的扫描，以及查看 AWS 组织内扫描的资源。
设计考虑
-
您可以使用补丁管理器（AWS Systems Manager 的一项功能）来触发按需修补，以修复 Amazon Inspector 未修补漏洞或其他关键安全漏洞。Patch Manager 可以帮助您修补这些漏洞，而无需等待正常的修补计划。补救措施是使用 Systems Manager 自动化运行手册进行的。有关更多信息，请参阅由两部分组成的博客系列使用 Amazon Inspector 和 AWS Systems Manager 在 AWS 中自动管理和修复漏洞
。
亚马逊 Systems Manager
AWS Systems Manager
除了这些常规自动化功能外，Systems Manager 还支持许多预防、检测和响应式安全功能。AWS Systems Manager 代理 (SSM 代理) 是可以在 EC2 实例、本地服务器或虚拟机 (VM) 上安装和配置的亚马逊软件。SSM Agent 让 Systems Manager 可以更新、管理和配置这些资源。Systems Manager 通过扫描这些托管实例并报告（或采取纠正措施）它在您的补丁、配置和自定义策略中检测到的任何违规行为，帮助您维护安全与合规性。
AWS SRA 使用会话管理器（Systems Manager 的一项功能）来提供基于浏览器的交互式外壳和 CLI 体验。这提供了安全且可审计的实例管理，无需打开入站端口、维护堡垒主机或管理 SSH 密钥。AWS SRA 使用补丁管理器（Systems Manager 的一项功能）将补丁应用于操作系统和应用程序的 EC2 实例。
AWS SRA 还使用自动化（Systems Manager 的一项功能）来简化 Amazon EC2 实例和其他 AWS 资源的常见维护和部署任务。自动化可以根据计划简化常见的 IT 任务，如更改一个或多个节点的状态（使用批准自动化流程）和管理节点状态。Systems Manager 包含可通过使用标签帮助您确定大型目标实例组的功能，以及可根据您定义的限制帮助实施更改的速度控制功能。Automation 提供一键式自动化，用于简化复杂任务，例如创建金色 Amazon 机器映像 (AMI) 和恢复无法访问的 EC2 实例。此外，您可以通过授予 IAM 角色访问特定 runbook 的权限来执行某些功能，而无需直接向这些角色授予权限，从而增强运营安全性。例如，如果您希望 IAM 角色有权在补丁更新后重启特定 EC2 实例，但又不想直接向该角色授予权限，则可以创建自动化运行手册并授予该角色仅运行运行手册的权限。
设计注意事项
-
Systems Manager 需要依靠 EC2 实例元数据才能正常运行。Systems Manager 可以使用实例元数据服务（imdsv1 和 imdsv2）的版本 1 或版本 2 访问实例元数据。
-
SSM 代理必须与不同的 AWS 服务和资源进行通信，例如亚马逊 EC2 消息、Systems Manager 和 Amazon S3。要进行这种通信，子网需要出站 Internet 连接或配置相应的 VPC 终端节点。AWS SRA 使用 VPC 终端节点作为 SSM 代理建立通往各种 AWS 服务的私有网络路径。
-
通过使用自动化，您可以与组织中的其余人员分享最佳实践。您可以在运行手册中创建资源管理最佳实践，并在 AWS 区域和群组之间共享这些操作手册。您还可以限制 runbook 参数的允许值。对于这些用例，您可能需要在中央账户（例如安全工具或共享服务）中创建自动化运行手册，并与 AWS 组织的其他成员共享。常见用例包括集中实施修补和安全更新、修复 VPC 配置或 S3 存储桶策略的偏差，以及大规模管理 EC2 实例。有关实现的详细信息，请参阅 S ystems Manager 文档。
Amazon Aurora
在 AWS SRA 中，A mazon Aurora
设计考虑
-
与许多数据库服务一样，Aurora 的安全管理分为三个级别。要控制谁可以对 Aurora 数据库集群和数据库实例执行亚马逊关系数据库服务 (Amazon RDS) 管理操作，您可以使用 IAM。要控制哪些设备和 EC2 实例可以为 VPC 中的 Aurora 数据库集群打开与集群终端节点和数据库实例端口的连接，您可以使用 VPC 安全组。要对 Aurora 数据库集群的登录名和权限进行身份验证，您可以采用与 MySQL 或 PostgreSQL 独立数据库实例相同的方法，也可以对兼容 Aurora MySQL 的版本使用 IAM 数据库身份验证。使用后一种方法，您可以使用 IAM 角色和身份验证令牌对与 Aurora MySQL 兼容的数据库集群进行身份验证。
Amazon S3
Amazon S3
AWS KMS
AWS SRA 说明了推荐的密钥管理分发模式，其中 KMS 密钥与要加密的资源位于同一 AWS 账户中。因此，除了包含在安全工具账户中外，AWS KMS 还用于应用程序账户。在应用程序账户中，AWS KMS 用于管理特定于应用程序资源的密钥。您可以使用密钥策略向本地应用程序角色授予密钥使用权限，并将管理和监控权限限制给密钥保管人，从而实现职责分离。
设计考虑
-
在分布式模型中，AWS KMS 密钥管理责任由应用程序团队承担。但是，您的中央安全团队可以负责管理和监控重要的加密事件，例如：
-
KMS 密钥中导入的密钥材料临近到期日期。
-
KMS 密钥中的密钥材料已自动轮换。
-
KMS 密钥已删除。
-
解密失败率很高。
-
AWS CloudHSM
AWS Cl
设计考虑
-
如果您对 FIPS 140-2 第 3 级有硬性要求，也可以选择将 AWS KMS 配置为使用 CloudHSM 集群作为自定义密钥存储，而不是使用原生 KMS 密钥存储。通过这样做，您可以从 AWS KMS 和 AWS 服务之间的集成中受益，这些服务可以加密您的数据，同时负责保护您的 KMS 密钥的 HSM。这将由您控制的单租户 HSM 与 AWS KMS 的易用性和集成性相结合。要管理您的 CloudHSM 基础架构，您必须使用公钥基础架构 (PKI)，并拥有一支具有管理 HSM 经验的团队。
AWS Secrets Manager
AWS Secrets Manager
借助 Secrets Manager，您可以使用精细的 IAM 策略和基于资源的策略来管理对机密的访问权限。您可以使用 AWS KMS 管理的加密密钥对密钥进行加密，从而帮助保护机密。Secrets Manager 还与 AWS 日志和监控服务集成，用于集中审计。
Secrets Manager 使用带有 AWS KMS 密钥和数据密钥的信封加密来保护每个密钥值。创建密钥时，您可以选择 AWS 账户和区域中的任何对称客户托管密钥，也可以使用 Secrets Manager 的 AWS 托管密钥。
作为最佳实践，您可以监控您的密钥以记录对它们的任何更改。这可以帮助您确保可以调查任何意外的使用或更改。可以回退不需要的更改。Secrets Manager 目前支持两项 AWS 服务，使您能够监控自己的组织和活动：AWS CloudTrail 和 AWS Config。 CloudTrail 将 Secrets Manager 的所有 API 调用捕获为事件，包括来自 Secrets Manager 控制台的调用和对 Secrets Manager API 的代码调用。此外， CloudTrail 捕获可能对您的 AWS 账户造成安全或合规性影响或可能帮助您解决操作问题的其他相关（非 API）事件。其中包括某些密钥轮换事件和秘密版本的删除。AWS Config 可以通过跟踪和监控 Secrets Manager 中机密信息的更改来提供侦探控制。这些更改包括密钥的描述、轮换配置、标签以及与其他 AWS 来源（例如 KMS 加密密钥或用于密钥轮换的 AWS Lambda 函数）的关系。您还可以将接收来自 AWS Config 的配置和合规性更改通知的 Amazon EventBridge 配置为路由特定的机密事件以进行通知或补救操作。
在 AWS SRA 中，Secrets Manager 位于应用程序账户中，用于支持本地应用程序用例并管理接近其使用情况的密钥。在这里，实例配置文件附加到应用程序账户中的 EC2 实例。然后可以在 Secrets Manager 中配置单独的密钥，以允许该实例配置文件检索密钥，例如，加入相应的 Active Directory 或 LDAP 域并访问 Aurora 数据库。Secret s Manager 与 Amazon RDS 集成，可在您创建、修改或恢复 Amazon RDS 数据库实例或多可用区数据库集群时管理用户证书。这可以帮助您管理密钥的创建和轮换，并将代码中的硬编码凭据替换为对 Secrets Manager 的编程 API 调用。
设计考虑
-
通常，请在最接近密钥使用位置的账户中配置和管理 Secrets Manager。这种方法利用了当地对用例的了解，为应用程序开发团队提供了速度和灵活性。对于可能需要额外控制层的严格控制信息，可以由安全工具帐户中的 Secrets Manager 集中管理机密。
Amazon Cognito
Amazon Cognito
Amazon Cognito 为用户注册和登录提供了一个可自定义的内置用户界面。您可以使用适用于 Amazon Cognito 的 Android、iOS 和 JavaScript 软件开发工具包向您的应用程序添加用户注册和登录页面。Amazon Cognito Sync 是一项 AWS 服务和客户端库，支持跨设备同步与应用程序相关的用户数据。
Amazon Cognito 支持对静态数据和传输中的数据进行多因素身份验证和加密。Amazon Cognito 用户池提供高级安全功能，有助于保护对应用程序中账户的访问权限。这些高级安全功能提供基于风险的自适应身份验证，并保护其免受泄露凭据的使用。
设计注意事项
-
您可以创建 AWS Lambda 函数，然后使用 AWS Lambda 触发器在用户池操作期间触发该函数，例如用户注册、确认和登录（身份验证）。您可以添加身份验证质询、迁移用户和自定义验证消息。有关常见操作和用户流程，请参阅 Amazon Cognito 文档。Amazon Cognito 同步调用 Lambda 函数。
-
您可以使用 Amazon Cognito 用户池来保护小型的多租户应用程序。多租户设计的一个常见用例是运行工作负载以支持测试应用程序的多个版本。多租户设计对于使用不同数据集测试单个应用程序也很有用，这样可以充分利用您的集群资源。但是，请确保租户数量和预期容量与相关的 Amazon Cognito 服务配额保持一致。这些配额在应用程序中的所有租户之间共享。
Amazon Verified Permissions
Amazon V
您可以通过 API 将您的应用程序连接到服务，以授权用户访问请求。对于每个授权请求，该服务都会检索相关策略并评估这些策略，以根据用户、角色、群组成员资格和属性等上下文输入来确定是否允许用户对资源采取操作。您可以配置并连接已验证的权限，将您的策略管理和授权日志发送到 AWS CloudTrail。如果您使用 Amazon Cognito 作为身份存储，则可以与已验证权限集成，并使用 Amazon Cognito 在应用程序的授权决策中返回的 ID 和访问令牌。您向已验证权限提供 Amazon Cognito 令牌，该权限使用令牌包含的属性来代表委托人并标识委托人的权利。有关此集成的更多信息，请参阅 AWS 博客文章使用亚马逊验证权限和 Amazon Cognito 简化细粒度授权
已验证权限可帮助您定义基于策略的访问控制 (PBAC)。PBAC 是一种访问控制模型，它使用以策略形式表示的权限来确定谁可以访问应用程序中的哪些资源。PBAC 将基于角色的访问控制 (RBAC) 和基于属性的访问控制 (ABAC) 结合在一起，从而形成了更强大、更灵活的访问控制模型。要了解有关 PBAC 以及如何使用已验证权限设计授权模型的更多信息，请参阅 AWS 博客文章使用 A mazon Verified Permissions 开发应用程序时基于策略的访问控制
在 AWS SRA 中，经过验证的权限位于应用程序账户中，通过与 Amazon Cognito 集成，支持应用程序的权限管理。
分层防御
应用程序账户提供了演示 AWS 支持的分层防御原则的机会。考虑构成 AWS SRA 中简单示例应用程序核心的 EC2 实例的安全性，您可以看到 AWS 服务在分层防御中如何协同工作。这种方法符合 AWS 安全服务的结构视图，如本指南前面的 “在您的 AWS 组织中应用安全服务” 一节中所述。
-
最里面的层是 EC2 实例。如前所述，EC2 实例包含许多原生安全功能，无论是默认还是作为选项。示例包括 imdsv2、Nitro 系统
和亚马逊 EBS 存储加密。 -
第二层保护侧重于 EC2 实例上运行的操作系统和软件。诸如 A mazon Inspector
和 AWS Systems Manager 之类的服务使您能够监控、报告这些配置并采取纠正措施。Inspector 会监控您的软件是否存在漏洞 ，Systems Manager 会扫描托管实例的补丁和配置状态，然后报告并采取您指定的任何纠正措施，从而帮助您努力维护安全与合规性。 -
这些实例和在这些实例上运行的软件与您的 AWS 网络基础设施同在。除了使用 A mazon VPC 的安全功能外，AWS SRA 还利用 VPC 终端节点在 VPC 和支持的 AWS 服务之间提供私有连接，并提供一种将访问策略置于网络边界的机制。
-
以账户为中心的服务（例如 AWS Security Hub、Amazon、AWS、AWS Config、AWS、AWS Config、AWS IAM Access Analyzer 和 GuardDuty Amazon Macie）进一步监控 EC2 实例 CloudTrail、软件、网络以及 IAM 角色和资源的活动和配置。
-
最后，除了应用程序账户之外，AWS RAM 还可以帮助控制与其他账户共享哪些资源，而 IAM 服务控制策略可帮助您在整个 AWS 组织中强制执行一致的权限。
