一、权限模型概述：定义、目标与重要性
说实话，做了这么多年权限相关的项目，我每次跟新同事聊起权限模型，大家第一反应都是“不就是角色、资源、动作嘛”。但真正踩过坑的人都知道，权限模型是整个系统的地基——地基没打好，后面的审计、合规、安全全得返工。
今天这一章，咱们先把权限模型这件事掰开揉碎了讲清楚。我不喜欢一上来就念定义，咱们先从一个我亲身经历的真实案例说起。
1.1 一个让我记忆犹新的线上事故
几年前我在一家电商公司做架构升级。当时有个运维同学不小心把"超级管理员"角色赋给了一个新入职的实习生。你也知道，实习生手一抖，把生产库里的用户表 drop 了一半…嗯，还好有快照。事后复盘，问题根源在哪？不是人犯错，是权限模型本身没有做完整性校验——角色定义里没有限制“最小权限原则”，也没有任何审批流。
从那以后，我养成了一个习惯：每做一个系统，先把权限模型画清楚，再用自动化工具跑一遍完整性检查。 权限模型的定义，说白了就一句话：“谁能在什么条件下对什么资源做什么事，以及这些规则之间不能有冲突、不能有缺口、不能有多余。”
1.2 权限模型的核心定义
权限模型由四个基本要素组成，我习惯用 4W1H 来记忆：
| 要素 | 英文 | 说明 |
|---|---|---|
| 主体 (Who) | Subject | 用户、角色、组、服务账号等 |
| 资源 (What) | Resource | 数据、功能、API、菜单、文件等 |
| 动作 (How) | Action | 增、删、改、查、执行、审批等 |
| 条件 (Where/When) | Condition | IP 范围、时间窗口、设备信任等级等 |
举个例子：仓库管理员 这个角色，可以在 工作日 09:00-18:00 对 入库单 执行 新建/修改/提交 操作。你看，四个要素全齐了。
1.3 权限模型的目标：不只是“能访问就行”
我见过很多团队把权限模型做成一张简单的“用户-权限”关联表，权限模型的目标被严重窄化了。其实，一个合格的权限模型应该满足以下五大目标：
- 最小权限 — 每个主体只拥有完成本职工作所需的最少权限。多了就是风险。
- 职责分离 — 敏感操作不能由同一个人完成整个流程。比如一个人既做采购审批又做付款执行，那就容易出问题。
- 可审计性 — 任何权限的授予、变更、撤销都要有完整的日志，能追溯到底。
- 完整性 — 规则之间没有矛盾，没有遗漏，没有死循环（比如角色A继承角色B，角色B又继承角色A）。
- 可扩展性 — 业务变化时，模型能在不改动核心架构的前提下支持新的角色、资源、条件。
关键点：完整性是审计的核心关注点。一个权限模型如果存在“幽灵权限”（没有主体引用的权限规则）或者“冲突权限”（同一主体对同一资源既有允许又有拒绝），那完整性审计就直接判定为失败。
1.4 权限模型的常见分类
我在项目中用过好几种权限模型，每种都有自己的适用范围和坑。下面这张表总结了最常见的三种：
| 模型 | 核心思想 | 适合场景 | 我踩过的坑 |
|---|---|---|---|
| DAC (自主访问控制) | 资源所有者自己决定谁可以访问 | 个人文件共享、小型协作系统 | 权限容易扩散，审计困难，离职员工可能遗留“自己加的”权限 |
| MAC (强制访问控制) | 系统强制按安全标签分级，用户不能改变 | 军事、政府、金融高安全系统 | 灵活性极差，改一次策略要全局审批 |
| RBAC (基于角色的访问控制) | 用户通过角色获得权限，角色与权限解耦 | 企业中后台、SaaS、OA 系统 | 角色膨胀后成为“角色沼泽”，需要定期做角色完整性审计 |
目前业界最主流的是 RBAC，但很多团队对它的理解只停留在“用户-角色-权限”三层结构上。其实 RBAC 还分 RBAC0、RBAC1、RBAC2、RBAC3 四个级别，差别在于是否支持角色继承、角色互斥、会话控制等。咱们后面的课程会详细拆解。
1.5 为什么权限模型完整性审计如此重要？
讲个我自己的教训。以前有个项目上线前走得急，权限模型没做审计，直接复制了另一个系统的角色配置。结果上线第三天就出了安全事故——一个普通客服竟然能查看到全站用户的手机号脱敏前数据。排查下来发现，系统里有个“客服主管”角色继承了一个废弃的“管理员”角色，而那行继承关系当年写死了，没人清理。
你看，权限模型如果没人审计，就像一座大楼没做结构验收就住进去。完整性审计就是要发现这些隐患：
- 冗余权限：某个角色有权限但从未使用过，或者权限覆盖了其他角色已有权限。
- 遗漏权限：某个角色缺少完成本职工作必需的某项权限（比如可以新建订单但不能修改，业务上根本讲不通）。
- 冲突权限：同一条规则既允许又拒绝，执行器不知道听谁的。
- 孤儿权限：权限规则定义了，但没有任何主体或角色引用它，白白占用存储和计算。
- 越权继承：低安全级别角色通过继承链获得了高安全级别的权限。
⚠️ 注意：完整性审计不是一次性的事。我建议每个版本发布前都要做一次自动化完整性扫描。尤其是当你修改了角色继承关系、新增资源或批量导入用户时，一定要跑一遍。
1.6 权限模型完整性审计的知识体系全景
到这儿，咱们把权限模型的定义、目标和重要性都过了一遍。为了让你脑子里有个全局地图，我专门画了一张知识体系结构图。它把整个课程涉及的核心模块串了起来：
💡 学习建议：我建议你把这张图存在本地，每学完一章就回顾一下它在全景中的位置。这样不会迷路。
1.7 一个小测试：你的权限模型健康吗？
在我开始讲后面的审计细节前，你可以在自己负责的系统里跑一个小检查。不复杂，三步：
- 导出当前所有的角色定义和权限规则（最好用 JSON 或 YAML 格式）。
- 写一个简单的脚本，统计一下角色总数、权限规则总数、没有绑定用户的角色数量。
- 看看有没有权限规则里提到了一个已经不存在的资源？或者有没有两个角色拥有完全相同的权限（重复定义）？
如果你发现其中任意一个指标超过 10%，那你的权限模型很可能已经有些“亚健康”了。别担心，这很正常——我见过的生产系统，90% 都有这类问题。后面几章我会教你如何系统性地做一次完整的完整性审计，并且用自动化工具来维护健康状态。
1.8 本章小结
咱们这一章把权限模型的概念框架打好了。现在你应该能回答这几个问题：
- 权限模型的四要素是什么？
- 权限模型要满足哪五大目标？
- 为什么完整性审计不是可有可无的“锦上添花”？
- 常见的模型类型（DAC、MAC、RBAC）各自的特点是什么？
从下章开始，我们会深入到每种模型的具体结构，先拿 RBAC 开刀——把它每个版本的定义、区别、以及审计要点讲清楚。到时候我会带着一段真实的 RBAC 配置代码，咱们一句一句分析完整性坑在哪里。