4.2 授权、IAM与最小权限

4.2 授权、IAM 与最小权限

本节摘要：授权（Authorization）决定已认证身份的操作边界，IAM（身份与访问管理）是把账号生命周期、认证与授权统一治理的运营框架，最小权限原则（Least Privilege）要求每个身份只拿到完成其职责所必需的权限。本节鉴定授权模型的演进（从粗放到属性化）、IAM 的闭环、以及最小权限的落地方法。承接 4.1 节的身份验证，本节处理"证明之后"的另一半，通往 4.3 节的密码学底座。

权限是怎么膨胀的

新系统上线时权限设计往往很克制：三个角色、十几条规则。一年之后呢——临时项目开了个宽权限、离职同事的账号留给了接手人"先用着"、某个集成系统拿了管理员令牌"图省事"。权限只发不收，是所有组织的一致方向。等安全团队做权限盘点时，经常发现"能读全量客户数据"的账号数是业务需要的三倍不止，而其中一半的归属人已经离职。

权限膨胀的可怕在于它推翻了所有后续防御的假设：入侵检测假设"特权账号的行为是可信的"，数据防泄漏假设"能碰数据的人是需要的"——当权限本身失真，这些假设全部落空。所以本节的结论先放在前面：授权问题的核心不是模型多先进，而是权限能不能被持续收回。

验明正身：三个术语的分工

授权是技术判定动作：这个身份对这条资源发起这个操作，允许还是拒绝。它在每一次请求时发生（1.2 节讲过"认证一次、授权多次"）。

IAM是运营框架：账号从入职创建（Joiner）、在职变更（Mover）到离职注销（Leaver）的全生命周期，加上认证策略、授权模型、权限审计的统一治理。IAM 的价值在"管理"二字——把散落在各系统里的账号收进一本账。

最小权限是设计原则：默认只给完成当前职责所需的最小集合，需要更多时走临时提权与审批，用完自动回收。它不是 IAM 的可选项，而是 IAM 能否运转的前提——没有最小权限，IAM 只是一本不断变厚的糊涂账。

运作机理：授权模型的演进

授权模型从粗到细经历了三代。用 RBAC（基于角色）的配置样例来看第一代的典型形态：

{
  "角色": "财务专员",
  "允许": ["报表:读取", "凭证:创建"],
  "拒绝": ["薪酬:读取", "系统:配置"],
  "成员": ["zhang.san", "li.si", "wang.wu(离职未清)"]
}
​

RBAC 的优点是简单可审计（角色数有限，盘点得过来），缺点是角色爆炸：业务一复杂，"华东区-线上-退款-审批人"这类组合角色越拆越多，最后没人说得清某个角色为什么存在。第二代 ABAC（基于属性）改用属性判定："允许 当 请求者.部门 = 资源.属主部门 且 时间 在工作时段 且 设备.合规 = 是"。属性化让策略可以表达业务语境，代价是策略本身的复杂度需要治理。

第三代是策略引擎集中化：判定逻辑从各应用里抽出来，集中到统一的策略决策点，应用只负责执行。这就是 5.3 节零信任架构里策略引擎的雏形——授权模型与架构思想在这里接轨。

IAM 闭环的关键动作清单

Joiner  入职: 按岗位模板开通基础权限, 特权权限需单独审批
Mover   转岗: 旧岗位权限自动回收(多数组织缺失的一环!)
Leaver  离职: 全系统账号当日禁用, 令牌与 API 密钥同步吊销
季度    权限复核: 每个角色的属主确认成员名单, 零使用权限进入回收名单
实时    特权会话: 管理员操作走堡垒机, 全程录屏可回放
​

转岗（Mover）是整个闭环里最常断的一环：入职有模板、离职有流程，唯独"换部门"常常只办行政手续不办权限手续，几年下来一个人攒了三个部门的权限。审计这个环节的性价比极高——对照 HR 的岗位表与 IAM 的权限表，偏差清单就是修复清单。

工程实践要点

特权账号单列管理。 管理员账号与日常账号物理分离（两套账号、两套密码策略、特权走堡垒机），让"高危操作"天然带有独立的审计通道。1.2 节判例里那个能导出客户表的 deploy 账号，本节给出它的病根：部署身份与数据权限没有隔离。

API 密钥与机器身份要纳入 IAM。 现代系统里"身份"的大头不是人，是服务账号、CI 流水线、第三方集成——它们的凭据（API key、token）生命周期往往无人管理。泄露事件里机器凭据的占比逐年上升，第 6 章的软件供应链一节会回到这个话题。

⚠️ 常见坑：用"审批流程"替代"权限模型"。有的组织把所有权限申请都做成人工审批单，以为流程能兜住一切——审批人根本无从判断"这个权限该不该给"，一律点同意。审批只能兜住例外，兜不住常态；常态靠的是角色与属性的合理建模。

💡 关键直觉：评估一家组织的权限治理水平，别看它的权限矩阵多精细，问一句"一个员工转岗后，旧权限多少天会自动消失"。答案超过一周，说明 Mover 环节是断的，权限矩阵再漂亮也只是装饰。

鉴定结论

• 授权是每次请求的判定动作，IAM 是账号全生命周期的治理框架，最小权限是让两者不失真的设计原则；
• RBAC 够用就别上 ABAC，模型先进度要匹配治理能力，角色爆炸比模型落后更危险；
• 转岗权限回收是 IAM 闭环的常见断点，季度复核要把 HR 岗位表对进 IAM 权限表；
• 权限体系运转起来了，接下来看它的技术底座：加密、哈希这些原语到底各自管什么——4.3 节拆开鉴定。

附卷：权限盘点七日冲刺

权限治理最怕"大而全"的一揽子工程。鉴定所推荐一种短平快的打法：七天冲刺，只回答三个问题（谁有什么、谁不该有、怎么收回来）。

第 1 天 拉底账: 从 IAM 导出全量账号-权限矩阵, 冻结新申请两天
第 2 天 对人头: 账号对 HR 在职表, 离职未销的当天禁用
第 3 天 对岗位: 每个角色的属主确认成员名单, 偏差记录在案
第 4 天 查僵尸: 半年零使用的权限批量列入回收候选
第 5 天 查特权: 特权账号逐一对人核对, 无主特权一律冻结
第 6 天 补机器: 服务账号与 API 密钥登记属主与用途, 无主即停
第 7 天 定机制: 把第 3、4 天的确认动作固化为季度例会
​

冲刺的价值不在七天本身，而在第 7 天的固化——没有季度化机制，下一轮冲刺会查出一模一样的问题。两处细节容易翻车：第 4 天的"零使用"要先排除低频但关键的权限（灾备切换一年用一次），否则会把救命权限也收了；第 6 天的机器身份最容易被跳过，但攻击者最爱它——服务账号没有人的直觉，异常行为没人代它喊冤。

再补一个授权设计的评判口径：看一个角色设计得好不好，就问"新人入职能否只凭岗位名就配齐权限"。能，说明角色是按职责建的；不能、要靠主管逐项点名，说明角色是按历史巧合攒的——后者就是下一次权限膨胀的种子。4.2 节正文说的"角色爆炸"，早期症状就是这句点名。

附卷二：生命周期三段钩子的自动化锚点

Joiner-Mover-Leaver 想不靠人肉跑起来，每段找一个自动化锚点：

三行锚点的共同前提是 HR 数据准：岗位表错一条，权限就错一片。所以 IAM 项目的真实第一站往往不是 IAM 平台，而是与 HR 系统的数据对齐。锚点接通之后，4.2 节正文那句"转岗权限多少天自动消失"的答案就从"看人自觉"变成"看系统计时"——治理从口头承诺变成了数据事实。