View a markdown version of this page

OU 设计：第 2 阶段 - AWS 规范性指导
架构设计安全 OU基础设施平台 OU合格的 OU不合格的 OU自动化 OU异常 OUGraveyard OU

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

OU 设计：第 2 阶段

在我们的示例中，这家制药公司通过将合格的生产工作负载部署到现有的 OU 中，加快进入了云技术发展的新阶段。这启动了对初始设计的审查，而随着越来越多的工作负载迁移到受监管的 AWS 登录区，第 1 阶段的结构受到了挑战。

以下新的要求和见解变得至关重要：

  • 该公司实施了数据共享工作负载模式，这样一来，应用程序便具备了多用途特性，不再能够被分配到诸如“临床”或“制造”这样的独立 OU 中了。

  • 资格认证（尤其是持续性的资格认证）成为了许多工作负载至关重要的环节。这些工作负载必须被纳整合到运营流程中，以便它们能够更轻松地遵循安全最佳实践。合格的工作负载需要更严格的 AWS 控件，这些控件在第 1 阶段在 OU 级别设置。

  • 嵌套的 OU 功能现已在 AWS Control Tower 中可用。

  • 通过提升技能和积累经验，我们对哪些特定策略适用于工作负载有了更深入的理解。

  • 该公司明确并达成了一个基于责任协调的运营模式。

  • 工作负载分段和结构蓝图已经成熟，并被用于工作负载迁移。

由于这些原因，在第二阶段实施了新的设计并 AWS 账户迁移到了该新结构。这个新结构包含了以下部分中描述的 OU。

架构设计

以下图表展示了第 2 阶段的 OU 架构。

OU 结构第 2 阶段的架构设计

安全 OU

安全 OU 包含与安全功能广泛相关的 AWS 账户，并使用两个账户（审计账户和日志归档账户）来存储安全操作数据，以便能够对环境进行集中日志记录和审计。诸如 Amazon GuardDuty 和 AWS Security Hub CSPM 等 AWS 核心安全服务则存放在审计账户中。此 OU 与最初的设计保持不变。

基础设施平台 OU

基础设施平台 OU 包含基本的基础设施帐户，例如跨 AWS 登录区的网络和共享自动化。此 OU 与最初的设计保持不变。

合格的 OU

合格的 OU 包含需要合格基础设施（例如严格的变更管理、资格认证和验证）的工作负载。

不合格的 OU

不合格的 OU 包含不具有 GxP 要求或非业务关键型的工作负载。

自动化 OU

自动化 OU 包含用于工作负载自动化的共享资源，例如用于基础设施管理的持续集成和持续交付（CI/CD）管道。根据需求的不同，自动化操作可以分散到不同的环境中，也可以托管在单个 AWS 账户中。

异常 OU

异常 OU 包含需要特殊处理的工作负载，若不特殊处理，这些工作负载会被策略阻止。例如，可广泛访问和可读的 Amazon Simple Storage Service（Amazon S3）存储桶将属于异常 OU。

Graveyard OU

Graveyard OU 包含将要删除的工作负载的 AWS 账户。在账户到期或被删除之前，应删除这些账户中的策略，以便实现高效且简便的管理访问权限。