2. 云IAM核心概念
云IAM不是“用户管理”的同义词，它是一套围绕“谁、凭什么、能对什么做什么、在什么条件下”展开的授权体系。要真正读懂一条云上的访问请求，必须先把七个核心概念拆开：身份、凭证、策略、角色、资源、主体、信任边界。它们不是并列的名词，而是构成一次访问决策的因果链：身份是“谁”，凭证是“证明你是谁”，主体是“本次请求以谁的名义发出”，策略是“允许或拒绝什么”，资源是“被访问的对象”，角色是“可被扮演的身份”，信任边界是“谁有资格扮演它”。
身份：长期存在的“账号实体”
身份（Identity）是云账号中一个持久存在的实体，例如IAM用户、用户组、服务账号。它有自己的唯一标识（如阿里云RAM UserId、AWS IAM User ARN、Azure Entra ID Object ID），可以被分配权限、被审计、被禁用。身份的关键特征是“长期性”：它不随某次会话结束而消失。因此身份治理的重点是生命周期——入职创建、转岗调整、离职禁用，以及避免长期不用的“僵尸身份”。
凭证：证明身份的秘密材料
凭证（Credential）是身份用来向云平台证明“我就是我”的材料，常见形式包括：控制台登录密码+MFA、AccessKey ID/Secret、临时安全令牌STS Token、证书、OIDC令牌。凭证的核心风险是“泄露即冒用”，因此治理重点是轮换、最小暴露、优先使用临时凭证。一个关键区分是：身份是名词，凭证是钥匙。禁用身份不等于凭证立即失效，删除AccessKey才是切断路径。
主体：一次请求的“实际发起者”
主体（Principal）是策略语句中描述“谁可以执行操作”的抽象，也是云平台在鉴权时实际评估的对象。它可以是IAM用户、角色会话、联合身份用户、云服务本身（如ECS实例、函数计算）。当用户扮演角色后，后续请求的主体就变成了“角色会话”，而不是原始用户。理解这一点，才能解释为什么“用户有权限但扮演角色后反而被拒绝”——因为主体已经切换。
策略：把意图写成可判定的规则
策略（Policy）是授权逻辑的载体，通常是一段JSON，包含Effect（Allow/Deny）、Action（操作）、Resource（资源）、Condition（条件）、Principal（主体，仅资源策略使用）。云平台默认拒绝，只有显式Allow才放行；显式Deny优先级最高。策略分为身份策略（挂在用户/角色上）和资源策略（挂在资源上，如OSS Bucket Policy、KMS Key Policy）。两者同时存在时，多数云采用“并集放行、显式拒绝覆盖”的判定逻辑。
角色：可被扮演的“临时身份”
角色（Role）本身没有永久凭证，它定义了一组权限和一条信任策略。任何被信任的主体都可以通过STS接口扮演它，获得一组临时凭证。角色的价值在于：跨账号访问、服务间授权、避免长期密钥。例如，账号A的ECS实例需要读取账号B的OSS，不应把账号B的AccessKey写进代码，而应在账号B创建角色并信任账号A，再由实例扮演该角色。
资源与信任边界
资源（Resource）是被访问的对象，用ARN或资源ID唯一标识。信任边界（Trust Boundary）是权限生效的边界，通常由账号、组织单元（OU）、VPC、租户等划分。信任策略（Trust Policy）是角色的“门禁”，它回答“谁可以扮演我”；权限策略回答“扮演后能做什么”。两者缺一不可：信任策略放行但权限策略为空，扮演成功却什么都做不了；权限策略很宽但信任策略严格，外部主体根本进不来。
把七个概念串成一次真实判定
假设账号A中有一个IAM用户 alice，她需要读取账号B的OSS Bucket。完整路径是：alice用密码+MFA登录（凭证），云平台认证后确认主体为 alice（身份→主体）；alice发起 AssumeRole 请求，账号B的角色 oss-reader 的信任策略允许账号A扮演，于是STS返回临时凭证；alice用临时凭证访问OSS，此时主体变为 oss-reader 角色会话，鉴权引擎评估角色的权限策略是否允许 oss:GetObject 作用于目标Bucket ARN；若允许则放行，否则返回 AccessDenied。这条链上任何一环断裂——凭证过期、信任策略不匹配、权限策略缺少Action、资源ARN写错——都会导致失败，而错误信息往往只提示最后一环，排障时必须逐段核对。
常见误区与治理要点
- 把身份当凭证：禁用用户后忘记删除其AccessKey，密钥仍可调用API。应把“禁用身份”和“吊销凭证”作为两个动作。
- 信任策略写成通配：Principal 写成
"*"会让任意账号扮演角色，必须限定具体账号或服务。 - 权限策略只写Action不写Resource：Resource 为
"*"意味着对所有资源生效，违背最小权限。 - 忽略条件键：Condition 可限制源IP、MFA、VPC端点、请求时间，是收紧权限的低成本手段。
- 跨账号只用角色不用资源策略：若资源本身支持资源策略（如OSS、KMS），应同时收紧资源侧，形成双重边界。
理解这七个概念的关系后，后续的权限模型设计、策略编写、跨账号授权和审计排障都会变得有据可依：先确定主体，再确认信任边界，最后用策略把权限精确地约束到资源与条件上。