IAM Permission Boundary 实战 - 堵住 CreateRole 提权路径

IAM Permission Boundary 是 AWS 中一个常被忽视的安全机制。它解决的问题非常具体：一个拥有 IAM 写权限的用户，可以创建具有管理员权限的角色来绕过自身限制。

提权路径分析

假设开发者通过 SSO 获得了 PowerUserAccess 权限集（允许所有操作，但不包括 IAM 管理）。如果 SCP 中没有显式拒绝 iam:CreateRole，提权链条如下：

SSO PowerUserAccess
  → iam:CreateRole（创建一个新角色）
  → iam:AttachRolePolicy（附加 AdministratorAccess 策略）
  → iam:PassRole（传给 EC2）
  → 登录 EC2 获得管理员权限 ✅

这条路径的关键在于：只要可以创建角色，就能创建拥有任何权限的角色。 Permission Boundary 就是给这条路径加一个”天花板”——开发者仍然可以创建和管理角色，但任何角色的实际权限上限由 Boundary 决定。

Permission Boundary 是什么

Permission Boundary 是一个 IAM 策略，附着在 IAM 角色或用户上，定义该角色/用户的最大权限边界。最终生效权限是 IAM 策略与 Boundary 的交集：

最终权限 = IAM 策略 ∩ Permission Boundary

这意味着即使角色附加了 AdministratorAccess，如果 Boundary 限制了只能访问 EC2，那实际权限也只有 EC2 操作。

策略设计

自定义的 DeveloperPermissionBoundary 策略，按 Allow/Deny 分类：

Allow（允许的常见操作）：

• ec2:Describe*, ec2:List* 等只读操作
• s3:Get*, s3:List*（不包含 s3:PutObject、s3:DeleteObject）
• ssm:StartSession（SSM Session Manager 登录 EC2）
• ec2:StartInstances, ec2:StopInstances, ec2:RebootInstances（日常运维）
• 其他服务（RDS、Lambda、CloudWatch 等）的只读操作

Deny（拒绝的提权和敏感操作）：

• iam:CreateRole / iam:DeleteRole / iam:AttachRolePolicy / iam:PassRole
• guardduty:*、securityhub:*、config:*、cloudtrail:*（安全服务写操作）
• organizations:*（组织级操作）
• budgets:*、ce:*（费用修改）

SCP 强制绑定

仅仅创建 Permission Boundary 不够，还需要在 SCP 层面强制所有新建的角色都必须绑定它。关键条件键是 iam:PermissionsBoundary：

{
  "Effect": "Deny",
  "Action": "iam:CreateRole",
  "Resource": "*",
  "Condition": {
    "ArnNotLikeIfExists": {
      "iam:PermissionsBoundary": "arn:aws:iam::*:policy/DeveloperPermissionBoundary"
    }
  }
}

ArnNotLikeIfExists 覆盖三种场景：

场景	iam:PermissionsBoundary	结果
没带 Boundary	key 不存在，IfExists 返回 true	拒绝
带了但不匹配	key 存在但 ARN 不匹配	拒绝
带了正确的	key 存在且匹配	通过

ARN 中的 * 通配任意账号 ID，所以需要在每个目标账号中创建同名的 DeveloperPermissionBoundary 策略。

除了 iam:CreateRole，还需要补充几条规则堵死其他绕过路径：

SCP 规则 1: CreateRole 必须带 DeveloperPermissionBoundary（如上）
SCP 规则 2: 不可修改或摘除已绑定的 Boundary
SCP 规则 3: 不可 AttachRolePolicy / PassRole 绕过 Boundary
SCP 规则 4: Security-Audit 等安全账号豁免

多账号部署

Permission Boundary 策略需要在每个目标子账号中创建一份。Terraform 中可以通过 provider aliases 在多个账号中创建同名的 aws_iam_policy 资源。

一个实用的做法是先只在 Prod 账号部署，SCP 附加到 Workloads/Prod OU，不影响其他账号，减小风险面。

验证清单

部署后建议逐项确认：

• 创建不带 Boundary 的角色 → 被 SCP 拒绝
• 创建带错误 Boundary 的角色 → 被 SCP 拒绝
• 创建带正确 Boundary 的角色 → 通过，但权限受 Boundary 限制
• 修改/摘除已有角色的 Boundary → 被 SCP 拒绝
• 安全账号的操作不受影响
• SSO 权限集创建的角色不受影响

小结

Permission Boundary 解决的是一个具体且高危的提权场景。核心三步：编写 Boundary 策略定义权限上限 → SCP 强制 CreateRole 必须绑定 → 杜绝绕过路径。与 SCP aws:ResourceOrgID 配合，构成 IAM 权限的完整防御体系。