📚 课程目录第3章 AWS账户与组织设计

3. AWS账户与组织设计

当基础设施从“一个账号跑所有东西”走向多账号时，治理的核心问题不再是“怎么创建资源”，而是“资源应该放在哪个账号、由谁创建、受什么边界约束、如何证明它没有越界”。AWS Organizations 正是回答这些问题的组织级骨架：它把多个 AWS 账户纳入同一棵树，用组织单元（OU）表达职责分组，用服务控制策略（SCP）表达权限上限，再用账户工厂把“新账号上线”变成可重复、可审计的流水线。

Organizations 与 OU：先定结构，再谈权限

Organizations 提供两种主要组织形态：整合账单（Consolidated Billing）和组织内账户管理。前者解决成本聚合与折扣共享，后者才是治理重点——它允许在根（Root）之下建立 OU 层级，并对 OU 或账户挂载 SCP。一个常见的生产级结构是：根之下分设 Security（日志归档、安全工具）、Infrastructure（网络、共享服务）、Workloads（业务负载）、Sandbox（实验）四个一级 OU，Workloads 再按环境拆成 Prod、Staging、Dev 三个子 OU。这样做的价值在于：SCP 可以按“职责”而非“单个账号”下发，新账号只要放进正确 OU，就自动继承对应边界。

需要特别区分 OU 与账号的语义：OU 是策略挂载点，不是资源容器；账号才是资源、身份和账单的真实边界。因此设计 OU 时应遵循“同一 OU 内的账号应共享同一套权限上限”的原则，避免把 Prod 和 Dev 放进同一 OU 后再用复杂条件去区分。

SCP：权限的上限，而非授权

SCP 是组织级权限边界，它只做“减法”：任何身份策略（IAM Policy）授予的权限，都必须同时被 SCP 允许，才真正生效。SCP 不授予权限，只限制权限。这一点决定了它的典型用法是“默认拒绝高风险动作”，而不是“逐条允许业务操作”。

例如，为防止成员账号关闭审计与安全监控，可在 Security OU 上挂载一条拒绝策略，禁止对 CloudTrail、Config、GuardDuty 执行停止或删除操作；在 Workloads OU 上，可限制只能使用指定区域，避免数据意外落到未治理区域。下面是一段示例 SCP（示例参数，非实测结果）：

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

判断 SCP 是否生效，不能只看策略文本，而要在成员账号内用目标角色实际调用一次被限制的 API，观察是否返回 AccessDenied，并核对 CloudTrail 中该请求的 errorCode。若返回成功，说明 SCP 未覆盖该路径或该操作属于 SCP 不支持的例外（如部分服务关联角色行为）。

账户工厂：把“开账号”变成可复现流程

账户工厂（Account Factory）的本质是把账户创建标准化：由管理账号或专用自动化账号触发，调用 Organizations 的 CreateAccount，随后自动完成基线配置。一个可落地的流程是：

在管理账号中通过 Control Tower 或自研流水线提交申请，参数包括账户名、邮箱、目标 OU、负责人、成本中心。
调用 organizations:CreateAccount 创建账户，等待 SUCCEEDED 状态。
将新账户移动到目标 OU，使其继承该 OU 的 SCP。
通过跨账号角色 AssumeRole 进入新账号，部署基线：启用 CloudTrail 到集中日志账号、配置 Config、绑定 SSO 权限集、打上 Owner、Env、CostCenter 标签。
记录账户 ID、OU 路径、基线版本到 CMDB 或参数存储，作为后续审计依据。

关键判断点是第 3 步之后：新账户是否真的继承了预期 SCP。可在新账号内尝试一个应被拒绝的操作（如创建未授权区域的 S3 桶），若被拒绝，说明 OU 挂载正确；若成功，需检查账户是否仍在根或错误 OU 下。

多账号环境隔离的治理闭环

隔离不是“建完账号就结束”，而是持续验证。建议把治理闭环落在三个可观测点上：SCP 是否覆盖全部生产 OU、账户是否偏离基线、跨账号访问是否只走受控角色。下图展示了从组织根到账户基线的治理链路与关键检查点。

落地时建议把上述检查固化为两条规则：其一，任何新账号在进入 Prod OU 前，必须通过一次“SCP 拒绝验证”和一次“基线合规扫描”；其二，每季度对全部 OU 做一次 SCP 覆盖审计，确认没有账号停留在根或未挂载策略的 OU 下。这样，多账号环境才从“建了很多账号”变成“每个账号都在受控边界内运行”。