📚 课程目录第3章统一身份与访问管理

3. 统一身份与访问管理

当业务同时运行在阿里云、AWS、腾讯云或私有 OpenShift 上时，最容易被低估的风险不是网络打通，而是“人”和“机器”的身份在各云之间各自为政。一个员工离职后，如果只在 HR 系统停用账号，而他在三个云平台上的 RAM 用户、IAM User、CAM 子账号仍然有效，这就是典型的权限残留。统一身份与访问管理（IAM）要解决的核心问题，是把分散在各云的身份收敛到一个可信源，再通过联邦和最小权限把访问边界收窄。

跨云 IAM 联邦：让身份从“各云自建”变为“集中签发”

跨云 IAM 联邦的本质，是让云平台信任一个外部身份提供者（IdP），而不是在每个云里单独维护一套用户名密码。常见做法是以企业已有的 Azure AD、Okta、Keycloak 或自建 LDAP 作为唯一身份源，通过 SAML 2.0 或 OIDC 协议完成联邦。以阿里云为例，配置 RAM 角色并设置 SAML 元数据后，用户从企业门户登录，IdP 签发断言，阿里云 STS 返回临时凭证；AWS 侧则通过 IAM Identity Center 或直接配置 SAML 身份提供者，把同一用户映射到 Permission Set。这样，用户不再持有长期 AccessKey，权限变更只需在 IdP 或角色映射层调整。

联邦配置中最容易出错的是属性映射。例如企业 IdP 中的 department 属性需要映射为云上角色的会话标签，才能让后续策略按部门做条件判断。如果映射缺失，用户虽然能登录，但会被拒绝访问，表现为“SSO 成功但控制台报无权限”。排查时应先看 IdP 断言中的 AttributeStatement，再核对云侧角色信任策略里的 Condition 是否要求了未传递的标签。

单点登录：体验统一之后，权限边界不能统一放大

SSO 解决的是“一次登录、多系统通行”，但它不自动等于最小权限。很多团队在接入 SSO 时，为了省事把 IdP 中所有用户都映射到一个高权限角色，结果 SSO 反而成了权限扩散的加速器。正确做法是按“身份属性 → 角色 → 策略”三层收敛：IdP 只负责证明“你是谁”，云侧角色决定“你能做什么”，策略再决定“对哪些资源做”。例如运维人员登录后获得 OpsReadOnly 角色，只有发起变更时才通过审批流切换到 OpsAdmin 角色，且该角色要求 MFA 和来源 IP 在白名单内。

SSO 会话时长也需要与安全要求匹配。控制台会话建议 1～4 小时，CLI 临时凭证建议 15～60 分钟。会话过长会放大凭证泄露窗口，过短则导致频繁重认证影响效率。生产环境通常对高权限角色设置更短会话，对只读角色适当放宽。

最小权限策略：从“能跑通”到“刚好够用”

最小权限不是一次性配置，而是一个持续收敛的过程。起步阶段可以先用云厂商提供的只读策略或基于历史访问生成初始策略，再通过访问分析器观察实际调用的 Action，逐步删除未使用的权限。以 AWS IAM Access Analyzer 为例，它可以基于 CloudTrail 过去 90 天的活动生成策略草稿；阿里云也有类似的访问控制分析能力。收敛时重点关注三类权限：*:* 通配、iam:PassRole、sts:AssumeRole，这三类一旦过宽，攻击者就能横向提权。

策略编写建议遵循“显式 Deny 兜底”原则。例如在允许业务读写对象存储的同时，显式拒绝关闭日志、删除备份和修改 KMS 密钥。这样即使 Allow 策略被误改，关键防护仍然生效。下面是一个示例策略片段，用于限制只能访问指定前缀且禁止删除：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowAppBucketReadWrite",
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::prod-app-data/app01/*"
    },
    {
      "Sid": "DenyDeleteAndPolicyChange",
      "Effect": "Deny",
      "Action": ["s3:DeleteObject", "s3:PutBucketPolicy", "s3:DeleteBucket"],
      "Resource": "*"
    }
  ]
}

服务账号治理：机器身份比人更容易失控

服务账号（Service Account、RAM 用户、IAM User）往往被用于 CI/CD、定时任务和跨系统调用。它们的问题集中在三点：长期 AccessKey 硬编码在代码或配置中、权限过大且无人复核、离职或项目结束后未清理。治理手段是优先用工作负载身份替代静态密钥。例如 Kubernetes 中的 ServiceAccount 通过 IRSA（IAM Roles for Service Accounts）或 OIDC 联邦直接换取云上临时角色，Pod 内不再挂载 AK；GitLab CI 则通过 OIDC 向云平台换取短期凭证。对于确实无法改造的遗留系统，至少做到密钥托管在 KMS 或 Secrets Manager、90 天强制轮换、绑定责任人和到期时间。

生产环境权限审计实战

审计的目标不是“看日志”，而是回答三个问题：谁在什么时候对什么资源做了什么、这个操作是否超出预期、异常发生后能否追溯和阻断。建议按以下顺序执行一次完整审计。

盘点身份清单。导出各云所有 RAM 用户、IAM User、角色和服务账号，标注类型（人/机器）、责任人、创建时间和最后活跃时间。最后活跃超过 90 天且无责任人的，列入待禁用。
检查高危权限。搜索策略中是否存在 Action: "*"、Resource: "*"、iam:CreateAccessKey、iam:AttachUserPolicy、sts:AssumeRole 无条件的组合。命中即列为高风险。
核对联邦映射。确认 IdP 中已离职或转岗人员的断言不再能映射到有效角色，检查角色信任策略中的条件是否仍然生效。
审计密钥生命周期。统计所有 AccessKey 的创建时间和轮换记录，超过 90 天未轮换的生成工单；确认没有密钥出现在代码仓库、镜像层或 CI 变量明文里。
验证日志完整性。确认 CloudTrail、ActionTrail、CAM 日志已投递到集中存储，且存储桶策略不允许删除日志。检查是否有 StopLogging、DeleteTrail 事件。
输出整改清单。按“立即禁用、限期收敛、持续监控”三档处理，并设定复查时间。

审计中最常见的盲区是“角色信任策略”。很多团队只检查附加的策略文档，却忽略了谁可以 AssumeRole。一个允许 Principal: "*" 且没有 Condition 的信任策略，等于把角色开放给任何已认证身份，风险远高于普通权限过大。

建议把权限审计做成月度例行任务，而不是一年一次的大检查。身份和权限是持续变化的，只有高频、小步的收敛，才能让最小权限真正落地，而不是停留在文档里。

统一身份与访问管理的最终形态，是让“人”和“机器”都通过联邦获得短期身份，让权限由策略精确约束，让每一次访问都留下可审计的痕迹。跨云 IAM 联邦解决身份统一，SSO 解决体验统一，最小权限解决边界收敛，服务账号治理解决机器身份失控，而权限审计则是验证这一切是否真正生效的手段。五者缺一不可，任何一环松动，都会让其他环节的努力被绕过。