借助 Cloud Foundations 管理 Control Tower：治理区域、管理组织、创建或注册账户、启用控件

本文英文版链接。

Cloud Foundations 解决方案初衷是为弥合亚马逊云科技中国区和全球区的服务差异而设计开发，利用自动化技术以最佳实践快速构建安全规范的云上运行环境并对其有效运维管理。在两年多的发展过程中^[2]，本方案紧跟亚马逊云科技技术进展，始终同步支持国内外区域，做到“一套代码各区可跑”。全球区提供更丰富的服务和功能，针对客户反馈和实践需求，我们也有针对的开发完善，确保方案在全球区也始终保持安全、更新、规范和易用。

AWS Control Tower （以下简称“Control Tower”）是一个创建着陆区，管理组织单元、账户和控件等而广受欢迎的托管服务。目前在全球部分区域可用，尚未于中国区推出。Cloud Foundations 在某些方面和 Control Tower 提供相同或相似的功能，在中国区可作为其替代方案使用。在全球区可单独使用，或二者并行使用，取长补短。有效协同二者管理云上环境颇具挑战，部分用户有时感到困惑和疑虑。为此，我们利用此博客就常见重要问题讲解讨论，协助用户高效运维云上环境。

管理组织

借助 Cloud Foundations 管理组织和多账户有三种模式，如下图所示：

三者主要区别如下：

常用模式为 B 和 C，模式 A 主要有两种适用场景，一是用于不便启用原生组织情形，例如由于法规限制不同账户不能置于相同组织；二是管理单账户情形，即所有工作负载均置于单一账户。本文主要介绍模式 C。

由于 Control Tower 是托管服务，从 Cloud Foundations 视角来看其实和管理其他托管服务一样配置管理。如需正确开启，在部署 Cloud Foundations 时除需开启 Control Tower 开关外，还需设置如下服务开关：

1. 开启 Amazon Organizations：原生组织是 Control Tower 服务的基础；
2. 开启 Amazon CloudTrail：该服务由系统管理，配置 Control Tower 时会关闭；
3. 关闭 Amazon Config：该服务当前只能由 Control Tower 管理；
4. 关闭 Amazon IAM Identity Center：该服务由系统管理；

在部署 Cloud Foundations 过程中，系统会对 Control Tower 做如下配置，部分参数根据最佳实践取值而无法更改。核心账户方面 Cloud Foundations 比 Control Tower 多了一个基础账户，其他包括区域和账户等与 Control Tower 保持一致。在初次部署过程中，Control Tower 在安装流水线的 management/admin 构建部署，一般需耗时约半小时。后期如需调整 Control Tower（例如增加管控区域），也在同一构建变更。

如部署 Cloud Foundations 时未启用 Control Tower，之后需要启用，按照以下步骤操作：

1. 修改参数：/前缀/parameter/baseline/disabled，关闭 config, config_rule；
2. 发布安装流水线，等待执行成功，此时 Amazon Config 服务及配置规则及检测修正产品关闭；
3. 修改参数：/cf/services，开启 controltower；
4. 修改参数：/前缀/parameter/baseline/disabled，开启 config_rule；
5. 发布安装流水线，等待执行成功，此时 Control Tower 服务开启并管理 Amazon Config 服务；
6. 发布额外流水线，等待执行成功，此时配置规则及检测修正产品开启；

新建账户

Control Tower 部署后会在其控制台附带一个账户工厂 Account Factory，用于新账户创建。与此同时，Cloud Foundations 亦会在 Amazon Service Catalog 服务目录创建一个账户工厂产品。而在 Amazon Organizations 控制台亦有创建账户入口。一般而言，如启用了 Control Tower，根据文档直接通过其账户工厂新建账户即可，无需再去 Amazon Organizations 控制台创建账户。同理，当 Cloud Foundations 管理 Control Tower 后，新建账户只需通过系统账户工厂完成，无需再去 Control Tower 或 Amazon Organizations 控制台创建账户。

上图为 Cloud Foundations 账户工厂架构图，注意其中账户工厂服务目录产品、账户状态机、部署状态机等关键资源。启动系统账户工厂服务目录产品时，根据是否提供亚马逊云科技账户 12 位数字标识（ID），系统据此新建或注册/邀请账户。根据是否开启 Control Tower，系统或调用 Control Tower 账户工厂，或直接调用 API 新建或注册账户。除此之外，新建账户时账户工厂还会创建系统管理员角色，启用默认关闭的区域，执行初始化流水线等。当所有管控流水线执行完毕后新账户才就绪。根据账户和区域多寡，整个过程通常耗时半小时至一小时。终止产品时会关闭或注销账户。根据是否开启 Control Tower，系统或调用 Control Tower 账户工厂，或直接调用 API。具体技术上是通过基础账户的 Amazon Step Functions 账户状态机来调度执行，详细流程参考下图。

启用 Control Tower 后，一次只能创建或注册一个账户，而不是最多五个。新建账户步骤如下：

1. 在基础账户启动系统账户工厂服务目录产品；
2. 预置产品名称：填入名称，例如该批次账户创建描述；
3. Account Ids：账户标识留空；
4. Account Emails：填入 1 个账户电子邮箱，亦用做身份中心用户邮箱；
5. Account Names：填入 1 个账户名称，亦用做身份中心用户名，用户姓设置为 Admin；
6. Organizational Unit：填入已注册的组织单元名称或标识，留空则使用沙盒组织单元；
7. 启动产品：在预置产品列表查找启动的产品并等待其状态为可⽤；
8. 账户状态机：在 Step Functions 观察账户状态机并确认执行成功；
9. 部署状态机：在 Step Functions 观察部署状态机并确认执行成功；

部署状态机完成后，创建新账户并在 Control Tower 中注册和被系统有效管控，可以安全使用。终止上述产品时，系统会调用 Control Tower 账户工厂删除账户。另可参考新建账户演示视频四^[4]。

注册账户

Control Tower 提供注册既有账户功能，使得组织内账户接受 Control Tower 管控。和新建账户一样，注册账户通过系统账户工厂完成，无需通过 Control Tower 控制台完成。因为账户除需要接受 Control Tower 管控外，也要接受 Cloud Foundations 管控。注册先决条件是既有账户在原生组织内且已对管理账户信任授权，即存在 OrganizationAccountAccessRole 组织账户访问角色。注册过程中系统会创建 Control Tower 需要的 AWSControlTowerExecution 执行角色，无需手动创建。同样的，一次只能注册一个账户。注册账户步骤如下：

1. 在基础账户启动系统账户工厂服务目录产品；
2. 预置产品名称：填入名称，例如该批次账户创建描述；
3. Account Ids：填入 1 个账户标识；
4. Account Emails：账户电子邮箱留空，通过组织动态读取；
5. Account Names：账户名称留空，通过组织动态读取；
6. Organizational Unit：填入已注册的组织单元名称或标识，留空则使用沙盒组织单元；
7. 启动产品：在预置产品列表查找启动的产品并等待其状态为可⽤；
8. 账户状态机：在 Step Functions 观察账户状态机并确认执行成功；
9. 部署状态机：在 Step Functions 观察部署状态机并确认执行成功；

部署状态机完成后，新账户在 Control Tower 中注册并被系统有效管控，可以安全使用。终止上述产品时，系统会调用 Control Tower 账户工厂注销账户，但不会删除。账户还在组织中但处于未注册状态。

定制账户

Control Tower 提供了丰富工具来定制账户，主要有以下几种：

1. AFC：通过专用账户存储 Service Catalog 账户蓝图产品，在创建账户时选择蓝图来定制新账户。蓝图产品事实上为 Amazon CloudFormation 模版，其内容为定制账户所部署的资源定义；
2. AFT：通过专用组织单元和账户，部署 AFT 环境包括代码库、流水线、状态机等，基于 GitOps 模式通过账户请求 Terraform 文件来创建和配置一个或多个账户；
3. CfCT：通过 CloudFormation 模版和服务控制策略 (SCP) 定制 Control Tower 着陆区，与 Control Tower 生命周期事件集成，所以也可用于账户工厂创建新账户时自动在账户中部署资源。与 AFT 类似，该功能需要部署一系列 CICD 资源来支持运行，但 CfCT 架构只能部署在管理账户而非专用账户，对此我们不认为是最佳实践。

Cloud Foundations 通过产品工厂提供了类似定制账户功能^[1]。在基础账户集中定义类似“账户创建蓝图”的模版和产品，通过系统内置流水线引擎^[3]自动化部署资源到指定账户和指定区域。在此基础账户可视为蓝图管理专用账户。

启用控件

Control Tower 主要功能之一是通过控件（“Controls”，之前称为“护栏”）对云上环境持续治理。控件是一个自然语言描述的高层次规则，用以治理云上资源、监控账户合规性。控件分阻止、检测和主动阻止 (proactive) 三类。控件适用在组织单元上，对组织单元内包含的账户生效，但对管理账户和安全组织单元无效。所有控件标识列表在 Control Tower 文档中罗列。

系统通过产品工厂支持 Control Tower 控件的部署和配置。例如下列代码定义在指定组织单元中适用 EBS 优化实例和加密卷的两个控件，组织单元通过变量 OU 动态传入。Control Tower 控件资源是特定资源，指定部署于主区域管理账户。更多利用产品工厂自动化部署管理云资源的信息可参考博客 [1]。

{
  "service": "controltower",
  "controls": {
    "safeguard-${OU}": {
      "ou": "${OU}",
      "controls": ["AWS-GR_EBS_OPTIMIZED_INSTANCE", "AWS-GR_ENCRYPTED_VOLUMES"]
    }
  }
}

治理区域

新增治理区域时，和新增账户类似，用户无需登录至 Control Tower 控制台操作，而是通过系统完成所有新区域配置部署操作。在部署流水线执行时，系统会将新区域传入 Control Tower 完成相应新增区域治理设置。在系统新增区域步骤如下：

1. 以 parameter-editor 角色登录主区域基础账户，修改参数 /前缀/parameter/regions，在最后添加新区域代码并以逗号分隔，例如 cn-north-1；
2. 以 pipeline-approver 角色登录主区域基础账户，发布初始化流水线；
3. 在 Step Functions 控制台观察部署状态机，等待所有流水线执行完毕。

总结

Control Tower 作为管理着陆区的托管服务，在云上环境安全治理和账户定制化管理方面提供了丰富和强大的功能。很多客户默认会选择开启该服务。Cloud Foundations 向来重视对重点基础服务的良好支持。根据实际项目经验总结，我们优化并加强了对 Control Tower 从部署到运维的支持，特别是基于账户工厂新建和注册账户，新增区域，基于产品工厂管理控件等方面。特别的，通过产品工厂账户创建蓝图产品在相当程度上实现了账户定制化配置，可灵活定义并标准化部署云资源。至此，绝大部分 Control Tower 的核心管控工作基本上都可由 Cloud Foundations 完成。此举进一步简化云上环境运维，使得各自管控边界清晰明了，助力您高效、规范、安全治理系统。

参考资料

1. 博客：借助 Cloud Foundations 产品工厂规划设计并一键部署云上多账户访问控制及权限策略等基础设施资源，2024年3月
2. 博客：快速构建安全规范和架构完善的云上多账户运行环境，2022年10月
3. 博客：借助 Cloud Foundations 实现 Terraform 基础设施即代码的自动化管理及其持续集成和持续部署，2022年12月
4. 博客：Cloud Foundations 演示视频集之一：从安装部署到日常运维，2024年8月

本篇作者