OU 设计：第 1 阶段 - AWS 规范性指导
架构设计安全 OU基础设施平台 OU额外 OUs

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

OU 设计：第 1 阶段

对于跨国制药公司来说，在我们的例子中，组织的最初设计和 OUs AWS Organizations 严格遵循了设立 AWS 的建议 AWS Control Tower。有关示例，请参阅针对医疗保健开启 AWS 的着陆区加速器。 AWS Control Tower 最初配置了一个具有共同基础的简单 OU 结构 OUs，如博客文章《组织单位最佳实践》中所述 AWS Organizations，包括安全 OU、平台基础架构 OU 和公司特定的 OU。 OUs

架构设计

下图显示了最初的 OU 架构。

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

安全 OU

安全 OU 将与安全功能 AWS 账户 相关的广泛分组在一起，并使用两个帐户（审计和日志存档）来存储安全操作数据，以便集中记录和审核对环境的访问。 AWS 诸如 Amazon 之类 GuardDuty 的核心安全服务 AWS Security Hub 位于审计账户中。

基础设施平台 OU

基础架构平台 OU 组合在一起 AWS 账户 ，提供基础架构基础。最初部署在此 OU 中的是 AWS 账户 用于中央网络组件（网关、防火墙、中央网络集线器和类似服务）的组件。 

额外 OUs

其他公司特定的组织 OUs （例如临床组织单位）增强了低级层次结构 OUs 中的基础。工作负载是通过多账户结构实现的，并在这些 OUs结构中使用不同的环境来实现。

有几个考虑因素推动了这个最初的设计：

  • Nested OUs 当时不可用，需要 AWS Control Tower 进行大量自定义。

  • 为云端指定的初始工作负载侧重于公司的特定方面，例如临床试验或制造设备分析（功能视图）。

  • 该公司区分了五种工作负载环境（开发、验证、集成、培训和生产）。该公司需要一个在没有生产工作负载所需严格 AWS 控制的情况下开发应用程序的游乐场。为此目的分配了 OUs 诸如制造开发OU之类的开发部门。

  • 工作负载自动化是每个应用程序生态系统的一部分，不需要分离。

  • 基础设施认证 (IQ) 和 GxP 合规流程不需要区分 OU 级别的 AWS 控制措施。