2. AWS数据平台安全基线与账户治理

当企业把数据平台从单账户实验环境推进到生产环境时，最先暴露的问题往往不是“某个服务不会用”，而是账户边界、身份边界和权限边界混在一起。一个典型场景是：数据工程团队、数据分析团队、安全审计团队共用同一个 AWS 账户，S3 存储桶、Glue 作业、Redshift 集群、KMS 密钥和 CloudTrail 日志全部堆在一起。此时任何一次误删、误改 IAM 策略或密钥轮换，都可能同时影响多个业务。因此，AWS 数据平台安全基线的第一步不是加密算法，而是账户治理：用多账户隔离爆炸半径，用 Organizations 统一管理，用 SCP 设定权限上限，用 Control Tower 落地基线，用 IAM Identity Center 做集中身份入口。

多账户策略：先分边界，再谈权限

多账户策略的核心不是“账户越多越好”，而是按职责分离和数据敏感级别划分边界。对于数据平台，通常至少拆成以下几类账户：

• 管理账户（Management Account）：只用于 AWS Organizations 管理、账单汇总和 Control Tower 控制台，不部署业务数据负载。
• 日志归档账户（Log Archive）：集中接收 CloudTrail、Config、VPC Flow Logs 等审计日志，配置 S3 Object Lock 和最小权限访问。
• 安全工具账户（Security Tooling）：运行 GuardDuty、Security Hub、Inspector 等安全服务，跨账户聚合发现结果。
• 数据生产账户：运行 Glue、EMR、Kinesis、Lambda 等计算任务，写入原始层和清洗层数据。
• 数据消费账户：运行 Athena、Redshift、QuickSight 等查询与 BI 负载，只读访问已发布数据集。
• 沙箱账户：供实验和开发使用，权限可放宽，但禁止访问生产数据。

这样划分后，数据生产账户被攻破不会直接删除日志归档账户中的审计记录，沙箱账户也无法读取生产 KMS 密钥。账户之间的数据共享通过资源策略 + RAM（Resource Access Manager）或跨账户 IAM 角色显式授权，而不是共享长期访问密钥。

AWS Organizations 与 SCP：把权限上限写进组织

AWS Organizations 提供组织单元（OU）树形结构，SCP（Service Control Policy）则绑定在根、OU 或账户上，定义“这个范围内允许的最大权限”。SCP 不授予权限，只做减法。例如，可以创建一个“数据生产 OU”，绑定如下 SCP 片段，禁止关闭 CloudTrail 和删除 KMS 密钥：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyDisableCloudTrail",
      "Effect": "Deny",
      "Action": [
        "cloudtrail:StopLogging",
        "cloudtrail:DeleteTrail"
      ],
      "Resource": "*"
    },
    {
      "Sid": "DenyKMSKeyDeletion",
      "Effect": "Deny",
      "Action": [
        "kms:ScheduleKeyDeletion",
        "kms:DisableKey"
      ],
      "Resource": "*"
    }
  ]
}

SCP 生效后，即使数据生产账户内的管理员拥有 AdministratorAccess，也无法执行被 Deny 的操作。这就是“权限上限”的意义：IAM 策略决定“能做什么”，SCP 决定“绝对不允许做什么”。在数据平台中，建议至少对生产 OU 禁止以下操作：关闭 CloudTrail、删除 KMS 密钥、修改 S3 存储桶策略为公开、关闭 GuardDuty、删除 Config 记录器。

Control Tower：把基线变成可重复的落地

Control Tower 在 Organizations 之上提供 Landing Zone，自动创建管理账户、日志归档账户和安全工具账户，并部署一组防护性控制（Preventive Controls）和检测性控制（Detective Controls）。防护性控制通常以 SCP 形式实现，例如“禁止在组织外共享 S3 存储桶”；检测性控制则通过 AWS Config 规则实现，例如“检测未加密的 S3 存储桶”或“检测未启用 MFA 的根用户”。

对于数据平台，Control Tower 的价值在于：新账户加入组织时，基线自动继承，不需要每个账户手工配置 CloudTrail、Config、GuardDuty 和 IAM 密码策略。如果企业已有自定义合规要求，可以通过 Control Tower 的自定义控制或Account Factory for Terraform把数据平台专属规则（如“所有 Glue 作业必须使用 KMS 加密”）纳入自动化开户流程。

IAM Identity Center 与集中身份管理

多账户环境下，最忌讳的是在每个账户里创建 IAM 用户和长期 Access Key。IAM Identity Center（原 AWS SSO）提供集中身份源，支持与外部 IdP（如 Okta、Azure AD、企业 LDAP）通过 SAML 2.0 或 SCIM 集成。用户登录后获得临时凭证，按权限集（Permission Set）映射到不同账户中的 IAM 角色。

一个可落地的权限集设计示例：

权限集分配后，用户通过 Identity Center 门户选择账户和角色，获得临时会话。这样既消除了长期密钥，也实现了“一人多账户、按角色切换”的集中管理。对于数据平台中的自动化任务（如 Glue 作业、Lambda 函数），仍应使用 IAM 角色而非用户，并通过信任策略限制只有特定账户或特定服务可以代入。

落地时的关键判断与常见误区

在实际落地中，有几个判断点值得特别注意。第一，管理账户绝不承载业务负载。管理账户拥有组织级权限，一旦被入侵，攻击者可以修改 SCP、关闭日志、甚至删除整个组织。因此管理账户只保留 Organizations、Control Tower 和账单相关权限，根用户启用 MFA 并封存访问密钥。

第二，SCP 不要写成“允许列表”。SCP 是权限上限，不是授权策略。如果 SCP 只写 Allow，很容易误以为它授予了权限，实际上还需要 IAM 策略配合。正确做法是：IAM 策略负责授予具体权限，SCP 负责 Deny 高风险操作。两者叠加后，实际权限是交集。

第三，Identity Center 的权限集要按“最小职责”设计。不要给数据工程师直接挂 AdministratorAccess，而是拆成 Glue 作业管理、S3 数据读写、KMS 加解密等细粒度权限。对于需要跨账户访问的场景，优先使用 Identity Center 的多账户权限集，而不是在目标账户中创建额外 IAM 用户。

总结来看，AWS 数据平台的安全基线不是单一服务，而是一套从身份到账户、从权限上限到检测控制的组合：IAM Identity Center 解决“谁以什么身份进入”，Organizations 解决“账户如何分组”，SCP 解决“绝对不允许做什么”，Control Tower 解决“基线如何自动继承”，多账户策略解决“爆炸半径如何隔离”。把这五者按顺序落地，后续的数据加密、访问审计和合规报告才有稳定的治理底座。