3. 身份与访问管理架构设计
在多账号云环境中，IAM 不是“给每个账号配几个用户和策略”这么简单。它要解决四个彼此耦合的问题：身份从哪里来（统一身份源）、身份如何跨账号被信任（联邦认证）、权限如何被约束到刚好够用（最小权限）、高权限如何被隔离与审计（特权账号管理）。这四者共同决定了一个请求最终能否被允许，以及被允许到什么程度。
一、统一身份源：把“人”和“机器”收敛到可治理的目录
统一身份源的目标是让所有云账号不再各自维护一套用户口令，而是由企业目录（如 Microsoft Entra ID、Okta、LDAP/AD）作为唯一权威身份库。典型做法是：目录中按组织与职能建立用户组，云侧只保留角色与策略，人员入离调转通过组成员关系自动生效。机器身份则单独治理，使用工作负载身份（如 OIDC 联合、实例角色、服务账号）而非长期 AK/SK。
一个可落地的映射示例：目录组 cloud-prod-readonly 映射到生产账号的 ReadOnlyAccess 角色；cloud-prod-ops 映射到 OpsRole；cloud-security-audit 映射到跨账号的 AuditRole。这样，权限变更不再发生在云账号内部，而是发生在目录组成员关系上，天然具备审批与留痕。
二、联邦认证：用信任关系替代密钥分发
联邦认证的核心是“云账号信任企业 IdP 签发的断言”。以 SAML 2.0 或 OIDC 为例，IdP 在用户完成 MFA 后签发断言，云侧通过预配置的信任策略校验签名、受众（Audience）、有效期与属性声明，再映射到本地角色。关键参数包括：Audience 必须精确匹配云侧配置的实体 ID，NameID 建议使用不可变唯一标识（如 objectId），SessionDuration 通常设为 1～8 小时，Attribute 中的组声明用于角色映射。
跨账号访问则通过“角色链”实现：用户在门户账号完成联邦登录，获得 PortalRole，再通过 sts:AssumeRole 跳转到目标账号的 TargetRole。此时必须校验目标角色的信任策略是否只允许来自门户账号的特定角色，并附加 ExternalId 或条件键（如 aws:PrincipalArn）防止混淆代理。联邦的价值在于：没有长期密钥跨账号流转，所有访问都绑定到一次可审计的登录会话。
三、最小权限：从“能做什么”到“在什么条件下能做”
最小权限不是把策略写短，而是把权限收敛到“特定主体、特定资源、特定条件”。实践中分三层：权限边界（Permissions Boundary）限定身份角色可拥有的最大权限集合；身份策略定义实际授予；资源策略定义资源侧允许谁访问。三者取交集才是有效权限。
例如，给运维角色设置边界策略，只允许 ec2:*、rds:Describe*、s3:GetObject，则即使身份策略误授 iam:CreateUser，也会被边界拦截。条件键进一步收紧：aws:RequestedRegion 限制在 cn-north-1，aws:SourceVpce 限制只能从指定 VPC 终端节点发起，aws:MultiFactorAuthAge 要求 MFA 在 3600 秒内。这样，权限从静态清单变成了带上下文的动态判定。
四、特权账号管理：把高权限关进“临时、审批、可录”的笼子
特权账号包括云根账号、管理员角色、CI/CD 发布角色和数据库超级用户。治理原则是：根账号不日常使用，启用 MFA 并封存访问密钥；管理员权限不常驻，通过 PAM 或云原生临时提权（如 IAM Roles Anywhere、Just-In-Time 访问）按需申请；所有提权会话必须审批、限时、录屏或记录命令。典型参数：提权时长 30～120 分钟，审批人至少一名非申请人，会话结束后自动回收角色。
下面这张图展示了多账号环境下从身份源到最终资源访问的完整信任链与权限收敛关系，重点体现联邦断言、角色链、权限边界与临时提权四个关键控制点。
五、多账号角色映射方案：把上述控制点落到账号矩阵
多账号环境通常按“组织单元（OU）”划分：安全 OU、基础设施 OU、生产 OU、非生产 OU。角色映射应遵循“一个职能一个角色、一个角色一个边界”的原则。下面给出一份可直接参考的角色映射表（示例参数，需按实际组织调整）：
| 目录组 | 目标账号 / OU | 云侧角色 | 权限边界 | 会话时长 | 附加条件 |
|---|---|---|---|---|---|
| cloud-prod-readonly | 生产 OU 全部账号 | ReadOnlyRole | 只读边界 | 8h | MFA ≤ 3600s |
| cloud-prod-ops | 生产 OU 指定账号 | OpsRole | 运维边界（禁 IAM 写） | 4h | Region=cn-north-1 |
| cloud-security-audit | 安全 OU + 全账号 | AuditRole | 审计只读边界 | 8h | SourceVpce 限定 |
| cloud-cicd-deploy | 非生产 / 生产发布账号 | DeployRole | 发布边界（禁删除） | 1h | OIDC 工作负载身份 |
| cloud-breakglass | 全账号（仅故障时） | BreakGlassRole | 管理员边界 | 30min | 双人审批 + 录屏 |
落地时建议按以下顺序推进：先完成目录组与云侧角色的映射，再为每个角色绑定权限边界，随后接入联邦登录并强制 MFA，最后把特权路径纳入 PAM 审批。验证阶段可用云侧访问分析器识别“已授予但 90 天未使用”的权限，逐步收敛；同时用 CloudTrail 检查是否存在绕过联邦的直接密钥调用。判断标准很直接：任一人员访问生产资源时，其身份应来自目录、会话应可追溯到一次联邦登录、权限应被边界约束、高权限操作应留下审批与录屏记录。四项同时成立，IAM 架构才算真正闭环。