3. 多账户策略与组织治理

当团队从单一 AWS 账户走向多账户时，真正的挑战不是“开更多账户”，而是让这些账户在统一规则下运行，同时把风险、权限和成本边界切清楚。AWS Organizations 提供了账户编组、策略下发和集中账单的基础能力，但能否落地，取决于 OU 结构、SCP 策略、日志归档和安全账户四件事是否被一起设计。

一、先定治理边界，再定 OU 结构

OU（Organizational Unit）不是文件夹，而是策略继承和权限隔离的边界。一个常见的误区是按“部门名称”直接建 OU，结果业务调整时策略无法复用。更稳妥的做法是按“治理要求”分层：顶层按环境隔离，第二层按业务线或职能划分，第三层按合规等级或数据敏感度细分。

例如，一个中等规模平台可以设计为：根下先分 Security、Infrastructure、Workloads、Sandbox 四个一级 OU。Security 承载日志归档、安全工具账户；Infrastructure 承载网络、共享服务、CI/CD 账户；Workloads 下再按 Prod、NonProd 划分；Sandbox 用于实验和临时账户。这样，生产环境的 SCP 可以更严格，沙箱环境可以更宽松，而安全账户始终独立于业务账户之外。

OU 层级不宜过深，通常 3～4 层足够。每增加一层，策略继承和排障复杂度都会上升。设计时可以用一句话检验：如果某个账户需要单独例外，它是否应该被移到另一个 OU，而不是在 SCP 里加一条例外？ 如果答案是“是”，说明 OU 结构本身需要调整。

二、SCP 策略：用“拒绝”划底线，而不是用“允许”做授权

SCP（Service Control Policy）只做一件事：限制账户内 IAM 主体能做什么。它不授予权限，只做权限的上限。因此，SCP 的正确用法是写“拒绝”，而不是写“允许”。如果一条 SCP 写成了允许列表，说明设计方向已经偏了。

一个可落地的 SCP 分层策略如下：

• 根级 SCP：拒绝所有账户退出组织、拒绝关闭 CloudTrail、拒绝修改 Organizations 本身。这是全局底线。
• Security OU SCP：拒绝删除日志桶、拒绝关闭 Config、拒绝修改日志归档账户的 S3 桶策略。
• Workloads/Prod SCP：拒绝使用未批准区域（如只允许 ap-northeast-1 和 ap-southeast-1）、拒绝创建无加密的 RDS、拒绝关闭 GuardDuty。
• Sandbox SCP：只保留根级底线，允许更多服务实验，但限制高成本实例类型。

下面是一段生产环境常用的区域限制 SCP 示例，作用是拒绝在非批准区域创建资源：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyNonApprovedRegions",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "ap-northeast-1",
            "ap-southeast-1"
          ]
        },
        "ArnNotLike": {
          "aws:PrincipalArn": "arn:aws:iam::*:role/OrganizationAccountAccessRole"
        }
      }
    }
  ]
}

注意 ArnNotLike 这一条：它允许管理账户通过 OrganizationAccountAccessRole 跨账户操作，避免把自己锁死。SCP 生效后，可以用一个简单方法验证：在目标账户中用普通 IAM 角色尝试在 us-east-1 创建 S3 桶，应返回 AccessDenied；而在 ap-northeast-1 创建则成功。这个“拒绝—放行”的对比，就是 SCP 是否生效的判断依据。

三、集中式日志与安全账户：把审计证据固定下来

多账户环境下，日志不能散落在各账户里。推荐做法是：每个账户开启 CloudTrail 组织跟踪，将日志投递到日志归档账户的 S3 桶；同时开启 AWS Config 和 VPC Flow Logs，统一汇聚。日志归档账户应启用 S3 对象锁（Object Lock）和跨区域复制，防止日志被篡改或删除。

安全工具账户则承担“分析”职责：通过跨账户 IAM 角色读取日志归档账户的数据，运行 GuardDuty 聚合、Security Hub 汇总和自定义告警。这样，日志的“写”和“读”分离，安全账户即使被攻破，也无法删除原始日志。

四、落地检查清单

在完成 OU、SCP、日志和安全账户设计后，可以用以下清单做一次快速复核：

多账户治理的本质，是把“谁能做什么、日志放在哪、谁来看日志”这三件事用组织结构和策略固定下来。OU 决定边界，SCP 决定底线，集中式日志决定证据，安全账户决定分析能力。四者配合，才能在多账户环境下既保持隔离，又不失去统一治理。