📚 课程目录第3章 AWS Organizations与多账户治理

3. AWS Organizations与多账户治理

当平台从单账户走向多账户时，治理问题会从“资源怎么配”升级为“边界怎么划、权限怎么收、基线怎么统一”。AWS Organizations 提供账户的集中组织能力，SCP（Service Control Policy）提供权限上限，Control Tower 则把账户创建、基线配置和持续合规检查打包成可重复的落地机制。三者组合起来，才能形成平台账户的治理骨架。

一、组织单元与账户分层：先定边界，再谈权限

AWS Organizations 的核心对象是根（Root）、组织单元（OU）和成员账户。根是权限上限的起点，OU 是策略继承的中间层，成员账户是实际承载工作负载的单元。一个可落地的平台分层通常按“职责”而不是“团队”来划分，例如：

Security OU：集中日志、审计、安全工具账户，如 Log Archive、Audit。
Infrastructure OU：共享网络、DNS、镜像、CI/CD 等平台账户。
Workloads OU：按环境或业务域再分 Prod、NonProd 子 OU，承载应用账户。
Sandbox OU：实验账户，允许更宽权限但必须限制成本与数据边界。

分层的判断依据是“策略继承路径是否清晰”。SCP 会沿 Root → OU → 账户逐层继承，子层只能进一步收紧，不能放宽。因此，把安全类账户放在独立 OU，可以避免工作负载 OU 的宽松策略意外影响审计账户。

二、SCP：把“不允许”写成可继承的权限上限

SCP 不授予权限，只定义权限上限。它作用于 IAM 主体和角色，对根用户也生效（但管理账户的根用户仍受保护）。平台基线中常见的 SCP 有三类：

区域限制：只允许指定区域创建资源，防止数据驻留越界。
服务限制：禁止高风险服务或操作，如关闭 CloudTrail、删除日志桶、修改组织策略。
保护性拒绝：拒绝删除关键 KMS 密钥、拒绝关闭 GuardDuty、拒绝修改基线配置。

下面是一个区域限制 SCP 的示例，仅允许 ap-northeast-1 和 us-east-1 两个区域，并放行全球服务：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyOutsideApprovedRegions",
      "Effect": "Deny",
      "NotAction": [
        "iam:*",
        "organizations:*",
        "cloudfront:*",
        "route53:*",
        "support:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "ap-northeast-1",
            "us-east-1"
          ]
        }
      }
    }
  ]
}

这里用 NotAction 放行全球服务，是因为 IAM、Organizations、CloudFront、Route 53 等属于全球端点，若直接按区域拒绝会误伤。实际落地时，应先在 Sandbox OU 验证，再逐层向上应用。SCP 的变更会立即影响所有继承账户，因此必须配合版本管理和变更评审。

三、Control Tower：把基线变成可重复的落地机制

Control Tower 在 Organizations 之上提供 Landing Zone。它自动创建 Log Archive 和 Audit 账户，部署 CloudTrail 组织跟踪、AWS Config 记录器、集中日志桶和 IAM 角色，并通过 Guardrails 持续检查。Guardrails 分为强制性和预防性：预防性 Guardrail 本质就是 SCP，检测性 Guardrail 则依赖 Config 规则。

平台账户基线的典型落地顺序是：先启用 Control Tower 并选择区域，再创建 OU 结构，然后为不同 OU 注册账户并应用 Guardrails。Control Tower 会自动为每个账户部署 Account Factory 模板，包括 VPC 基线、IAM 角色和日志配置。若已有账户，可通过“注册现有账户”纳入治理，但需要先满足前置条件，如删除默认 VPC、关闭不兼容的 Config 记录器等。

Control Tower 的 Guardrails 不是一次性配置，而是持续状态。当账户出现漂移（如有人手动关闭 CloudTrail），检测性 Guardrail 会在 Config 中标记为不合规，并可通过 SNS 通知平台团队。

四、集中化治理与安全边界的关系

Organizations 解决“账户归谁管”，SCP 解决“权限上限在哪”，Control Tower 解决“基线怎么持续保持”。三者不是替代关系，而是叠加关系。下图展示了从组织根到成员账户的策略继承与基线注入路径：

图中可以看到，SCP 是横向的继承层，Control Tower 是纵向的基线注入层。两者共同作用后，成员账户既受到权限上限约束，又持续被基线检查覆盖。平台团队不需要登录每个账户手动配置，而是通过组织级策略和 Guardrails 统一管理。

五、落地时的关键判断与常见问题

第一，管理账户不要承载工作负载。管理账户拥有组织级权限，一旦被入侵影响面极大。建议只用于账单、组织和 Control Tower 管理。

第二，SCP 变更前先做影响分析。可以用 IAM Policy Simulator 或先在 Sandbox OU 验证。特别注意 Deny 与 NotAction 的组合，容易误伤全球服务或管理操作。

第三，Control Tower 的注册账户有前置条件。已有账户若存在默认 VPC、未加密的 S3 桶或冲突的 Config 记录器，注册会失败。建议在注册前用脚本检查并清理。

第四，Guardrails 的合规状态需要持续观察。可以在 Audit 账户中查看 Config 聚合结果，或通过 Security Hub 集中查看。发现不合规时，先判断是漂移还是策略本身需要调整，再决定修复方式。

SCP 不会限制管理账户的根用户，也不会限制服务关联角色。若需要限制服务关联角色，应使用 IAM 权限边界或条件键，而不是仅依赖 SCP。

综合来看，多账户治理的基线可以概括为：用 Organizations 定义账户归属，用 SCP 定义权限上限，用 Control Tower 定义持续基线。三者叠加后，平台账户才具备可审计、可继承、可重复的安全边界。