大规模 AWS IAM：治理、多账户安全与组织控制（第3部分）

Source: Dev.to

为什么单账户 IAM 无法扩展

单个 AWS 账户可能足以用于实验或小型项目。然而，随着团队和工作负载的增长，这种做法会带来若干问题：

• 难以隔离环境（开发、预发布、生产）
• 误操作导致关键资源被意外访问的风险高
• 安全事件发生时难以控制影响范围（blast‑radius）
• 审计和合规跟踪能力差

现代 AWS 架构通过采用 多账户策略 并进行集中治理来解决这些问题。

多账户 AWS 模型

AWS 建议使用多个账户来组织环境，而不是在单个账户中使用复杂的 IAM 规则。常见的基线结构包括：

• 管理账户 – 拥有组织和计费权限
• 安全账户 – 集中日志、GuardDuty、IAM 分析
• 共享服务账户 – CI/CD、IAM 联合、工具链
• 工作负载账户 – 为开发、预发布和生产分别创建的独立账户

每个账户默认是相互隔离的，这大幅降低了配置错误或凭证泄露的影响。

AWS Organizations：集中式账户管理

AWS Organizations 让你可以从单一管理账户管理多个 AWS 账户。它提供合并计费、层级组织单元（OU）以及集中式策略执行。

Organizations 使团队能够：

• 以编程方式创建和管理账户
• 在账户组上应用治理策略
• 控制可使用的 AWS 服务
• 一致地强制执行安全要求

IAM 仍然存在于每个账户内部，但 Organizations 在其之上增加了一层控制。

服务控制策略（SCP）：护栏，而非权限

SCP 常被误解。它们 不授予权限；相反，它们定义账户或 OU 能拥有的 最大权限。可以把 SCP 看作过滤器：即使 IAM 策略允许某个操作，SCP 也可以阻止它。

常见的 SCP 用例

• 防止关闭 CloudTrail 或 GuardDuty
• 限制使用组织未批准的区域
• 除紧急操作外阻止根用户访问
• 拒绝创建公共 S3 桶
• 防止删除安全相关资源

SCP 在不需要修改各个 IAM 策略的情况下，强制组织范围的安全姿态。

示例 SCP：区域限制

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "NotAction": "iam:*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": ["ap-south-1"]
        }
      }
    }
  ]
}

该策略确保除 IAM 之外的所有服务都被限制在特定区域，有助于合规和成本控制。

集中式身份与访问管理

在大规模环境下，在每个账户中创建 IAM 用户既低效又不安全。组织通常采用 身份联合 的方式。

推荐做法

• 使用外部身份提供者（IAM Identity Center、Active Directory、Okta、Azure AD）
• 用户一次登录
• 在目标账户中通过角色切换获取有范围限制的权限

收益

• 单点登录（SSO）
• 集中式用户生命周期管理
• 无长期 AWS 凭证
• 强审计能力

访问变为基于角色、临时且可审计。

多账户环境中的角色设计

清晰的角色策略对于可维护性至关重要。

最佳实践

• 在各账户之间使用标准化的角色名称
• 区分只读、开发者和管理员角色
• 避免授予通配符权限
• 谨慎编写信任策略，限制谁可以假设角色
• 对敏感访问使用短会话时长

这种一致性简化了入职、自动化和事件响应。

集中式日志与监控

安全可视化必须跨账户集中。通常组织会将日志统一发送到专用的安全账户：

• 所有账户的 CloudTrail 日志
• VPC Flow Logs
• AWS Config 数据
• GuardDuty 发现

此配置确保任何工作负载账户都无法抑制或篡改安全证据。

组织层级的 IAM Access Analyzer

Access Analyzer 可以在整个组织范围内运行，识别：

• 公开共享的资源
• 意外的跨账户访问
• 过于宽松的策略
• 外部主体访问敏感服务

定期运行 Access Analyzer 有助于提前发现配置错误，支持持续合规。

基于属性的访问控制（ABAC）

ABAC 通过基于属性（标签）而非单个身份授予访问权限，降低了策略的复杂度。

示例

• 为用户打标签 department=finance
• 为资源打标签 department=finance

当标签匹配时，策略允许访问。随着团队规模和组织结构的变化，这种模型易于扩展。

根账户保护

在成熟的 AWS 环境中，根账户会被严格锁定：

• 启用 MFA
• 没有访问密钥
• 最小化使用频率
• 凭证安全存储
• 仅在破窗（break‑glass）场景下访问

根账户不应成为日常操作的一部分。

结论

大规模的 IAM 并不是编写更多策略，而是设计能够在账户、团队和工作负载之间强制一致安全边界的系统。AWS Organizations、SCP、联合访问以及集中监控共同构成了一个治理框架，在保证安全的同时提供运营灵活性。

如果正确实施，IAM 将成为推动业务快速发展的助力，而不是障碍，帮助团队在保持强大安全保证的前提下快速前进。