如何在 Landing Zone 中实现多账户管理战略

随着越来越多企业客户使用亚马逊云科技的服务，Landing Zone（登录区）可为部署工作负载提供标准化和安全的基础环境。由于原有单账户体系无法满足复杂环境的需求（例如难以清晰划分职责边界、资源无法有效隔离、无法对不同部门独立计费和审计等），因此 Landing Zone 通过 AWS Organizations 为多账户环境提供了有力支持。实现不同的部门/团队、不同的环境（开发/测试/生产）使用不同的 AWS 账号，从而降低风险、实现职责分离、隔离资源以及减少人为故障的影响范围，而如何实现多账户管理战略成为大家关注的话题。

为了实现标准、安全、可扩展 Landing Zone 多账户管理，本文为企业客户提供了一个代表性的组织单元（Organization Unit，简称 OU）参考架构，并且提供了在多账户 AWS 环境中，建立治理和控制的思路。

1. 多账户管理设计原则

• 层次结构设计：明确划分组织单位（OU）的边界，根据业务需求、合规性要求或地理位置等因素合理划分 OU。建立一个合理的 OU 层次结构可以更好地应用服务控制策略（SCP）。
• SCP 继承：SCP 可以在根级别、组织单位或单个账户级别附加。注意到 SCP 具有继承性，子 OU 和成员账户将自动继承上层 OU 和根级别的 SCP 约束。因此，只需在合适的级别定义 SCP，避免重复配置。
• 授权和拒绝策略：在设计 SCP 时，一般建议采用显式拒绝未授权操作的方式，而不是试图列举所有允许的操作。这种拒绝策略有助于降低错误风险，也更易于维护。
• 分阶段部署：在大型组织中部署 SCP 时，建议分阶段推进。首先定义一组基本的 SCP，然后逐步添加更多限制，并根据需要对各个 OU 或账户应用更细化的策略。
• 例外管理：为应对特殊情况，可以提供例外流程让管理员临时解除部分 SCP 限制。这种例外措施需要严格的审批和监控。
• 定期审查：AWS 环境和需求会不断变化，因此需要定期审查现有 SCP，确保其保持有效性和合理性，并根据需求进行调整。
• 测试和验证： 在正式环境中部署 SCP 之前，务必在测试环境中全面测试和验证新策略，以免影响生产系统的正常运行。通过遵循这些最佳实践，组织可以更有效地利用 AWS Organizations 服务控制策略来实现多账户环境下的治理、安全性和合规性管理。

2. 多账户管理最佳实践架构

在复杂的企业环境中，Landing Zone 通常采用多账户环境规划。图 1 提供了一个代表性的企业客户的 OU 参考架构。Management Account 是用于创建组织的 AWS 账户。通过 Management Account 可以管理组织中账户的生命周期，它也充当整个组织的付费账户。该账户可以将策略附加到组织中的实体，各级组织单元（OU）或账户。Orgnizations root 是 Orgnization 层次结构中的顶级父节点。根包含 Organization 中的所有 OU 和账户。

图 1：企业客户的 OU 参考架构

下面部分将解释企业客户 OU 结构层次。在项目中可以从这些参考开始，并灵活调整 OU 与 SCP 组合，以满足组织所需的控制和治理要求。

3. 多账户管理实现思路

3.1 Management Account

图 1 中，Organization root 是所有组织及账户的父容器。为了实现整个组织的管理工作，在 Organization root 下直接创建 Management Account，在图 1 中表示为 L0A，（这个账号不隶属任何 OU），用于管理整个组织，将执行以下的工作：

• 在组织中创建/删除 OU 或账户
• 邀请其他现有账户到组织中
• 指定委托管理员账户
• 建立策略并应用到组织内的实体（OU 或者账户）
• 实现集中付款

3.2 Corporate OU

图 1 中，Corporate OU 被定义为 Level-1 级别 OU， 在图 1 中表示为 L1A。它是 Orgazization root 的直接子 OU，直接建立这个 OU 的优点是可以在一个集中位置附加该企业的服务控制策略（SCP）基线。应用于这个一级 OU 的所有 SCP 将向下应用到所有嵌套的 OU 和成员账户。注意，没有任何账户直接附加到这个 Corporate OU。

3.3 Core OU

图 1 中，Core OU 是 Corporate OU 的子 OU，被定义为 Level-2 级别 OU，表示为 L2A，提供 AWS Landing Zone 所需的共享基础服务。其下的账号可用于部署安全、日志存储、网络、AD、监控等共享服务。建立这个 OU 的优点是可在一个集中位置附加 SCP 策略，限定经批准的亚马逊云科技托管服务列表（允许列表/阻止列表），这些托管服务事先经过批准可以使用。同时考虑到共享的基础服务在变更投产前需要进行测试，因此在 Core OU 下还划分出 2 个子 OU：Production OU 与  Develop OU。

3.4 Business OU

图 1 中，Business OU 是 Corporate OU 的子 OU，被定义为 Level-2 级别 OU，表示为 L2B。其下的账号用于部署业务相关的各类工作负载应用。建立这个 OU 的优点是可在一个集中位置附加 SCP 策略，限定 Business OU 使用一个经批准的 AWS 服务列表（允许列表/阻止列表），这些服务事先经过批准可以使用。由于 Business OU 与 Core OU 的用途不同，因此他们列表内容会有很大区别。服务的批准可能取决于诸多因素，例如根据客户当前在 AWS 上部署的工作负载类型（如 Web 应用程序、存储、分析等）来批准服务。如果客户没有任何物联网工作负载，则可阻止 Business OU 使用物联网服务。同时企业客户可根据需要遵守的合规程序（如 SOC 或 PCI DSS）来批准服务。由于企业客户通常在投产前需要进行业务测试，在生产与测试环境管控方面会有所不同，因此在 Business OU 下还划分出 2 个子 OU：Production OU 与 Develop OU。

3.5 Production OU

图 1 中，Production OU 是 Business OU 的子 OU，被定义为 Level-3 级别 OU，表示为 L3A。数据保护是 Production OU 的一个关键考虑因素。对于生产环境，一个重要考虑是要求对数据进行分类，因为不同数据类型需要不同的控制措施。建立这个 OU 的优点是可在一个集中位置附加 SCP 策略进行数据保护，例如对任何资源删除操作启用多重身份验证（MFA），以保护生产工作负载。

3.6 Develop OU

图 1 中，Develop OU 是 Business OU 的子 OU，被定义为 Level-3 级别 OU，表示为 L3B。对于开发测试环境通常使用非生产数据，并不需要对数据进行严格管控。因此在一个集中位置附加更加灵活的 SCP 控制策略，以提升开发测试工作效率。

3.7 Public workload OU

图 1 中，Public workload OU 是 Production OU 的子 OU，被定义为 Level-4 级别 OU，表示为 L4A。Public workload OU 将支持面向互联网的工作负载。例如 Web/Email/Online Store 等互联网应用属于这一类别。

3.8 Internal workload OU

图 1 中，Internal workload OU 是 Production OU 的子 OU，被定义为 Level-4 级别 OU，表示为 L4B。Internal workload OU 将支持面向内部的工作负载。可以实施 SCP 来阻止为这些账户创建互联网接口，以减小暴露面。

3.9 Confidential Workload OU

图 1 中，Confidential workload OU 是 Production OU 的子 OU，被定义为 Level-4 级别 OU，表示为 L4C。Confidential workload OU 将支持受限数据的工作负载，这些数据一旦受到威胁或在未经授权的情况下被访问，可能会导致巨额法律罚款或给公司造成损害的应用。这些内部机密应用涉及法律、人力资源、企业战略、专有数据研究等数据。建议根据工作负载的敏感性在这些 OU 上设置额外的控制措施并配合使用相关的安全加密及用户认证服务。

4. 总结

在本文中总结了企业客户具有代表性的 Landing Zone 多账户管理战略设计与实现方式，通过层次化的 Organization Unit（OU）结构，并配合在多帐户 AWS 环境中服务控制策略（SCP）的合理规划，可以帮助实现公司 Landing Zone 治理管控要求。允许在组织内构建自定义策略来保护数据，应用不同的安全控制，并满足内部用户的需求。同时需要说明，在不同业务场景下，建议用户在当前参考架构基础上进行客户化调整，从而为企业上云 Landing Zone 设计打下良好的基础。

本篇作者