第2章 RBAC模型标准：从0到3的进化之路
2.1 为什么需要四个模型？
刚接触RBAC时，我也有个困惑：搞这么多个版本干嘛？直接用一个最强的不好吗？
后来踩过坑才明白——不同的业务场景，对权限控制的粒度要求完全不同。一个只有十几个人的创业公司，跟一个上万人的银行系统，权限模型的选择天差地别。 RBAC 标准定义了四个层级：RBAC0、RBAC1、RBAC2、RBAC3，它们不是互相替代，而是逐步增强。
说白了，你选哪个模型，取决于三个问题：
- 要不要角色继承？（上级能不能自动拥有下级权限）
- 要不要约束规则？（一个人能不能同时拥有两个互斥角色）
- 能不能接受管理复杂性？
核心思路：RBAC0是地基，RBAC1/2是可选增强，RBAC3是集大成者。但别盲目用RBAC3——越复杂，出bug的概率越高。
2.2 RBAC0：基本模型，一切从这里开始
RBAC0 就是最基础的 用户-角色-权限 三件套。用户不能直接拥有权限，必须通过角色来获得。我在项目中见过不少团队，一开始直接给用户分配权限，结果后期维护堪称灾难。
RBAC0 的要素就这几个：
- 用户（User）—— 系统操作者
- 角色（Role）—— 权限的集合，例如“财务主管”
- 权限（Permission）—— 对某个资源的操作许可，例如“审核报销单”
- 会话（Session）—— 用户登录后激活的角色集合
它的核心约束只有一条：用户只能通过角色获得权限，不能直接授权。够简单吧？80%的中小系统用RBAC0就够了。
实践经验：我当年给一个电商后台做权限设计，直接用RBAC0，搞了5个角色：客服、运营、财务、管理员、超级管理员。上线一年，没出过权限事故。别总想着炫技，简单模型往往更可靠。
2.3 RBAC1：角色继承，让层级更自然
RBAC1 在RBAC0的基础上加了角色继承。什么意思呢？比如“高级管理员”可以继承“普通管理员”的所有权限，再额外拥有一些高级权限。
这里要注意，继承是单向的、偏序的。角色之间形成树状或半格状结构。举个例子：
公司角色继承示例：
CEO
├── VP Engineering
│ ├── 高级开发工程师
│ └── 中级开发工程师
└── VP Finance
├── 财务经理
└── 财务专员
高级角色自动获得低级角色的所有权限，但反过来不行。这么做的好处很明显：
- 减少角色配置工作量：新增一个高级角色，只需定义它继承谁，而不需要重新配一遍权限
- 权限变更自动传播：修改低级角色的权限，所有继承它的高级角色自动生效
曾经踩过的坑：有一次我设计角色继承时，让“部门经理”继承了“普通员工”，又让“总监”继承了“部门经理”。结果总监对普通员工的某些权限需要限制（比如不能查看自己下属的薪资），但继承机制导致无法撤回。后来我被迫用“私有权限”覆盖来解决。所以——继承要做好“权限覆盖”机制，不能只做加法。
2.4 RBAC2：约束，防止权限滥用
RBAC2 在RBAC0基础上加了约束规则。这些规则限制了用户和角色、角色和权限之间的分配关系。
常见的约束有三类：
| 约束类型 | 含义 | 实例 |
|---|---|---|
| 互斥角色 | 一个用户不能同时拥有两个互斥的角色 | 不能同时是“出纳”和“会计审核员” |
| 基数约束 | 一个角色最多能分配给多少个用户 | “总经理”角色最多只能有1人 |
| 前提角色 | 用户必须先拥有角色A，才能获得角色B | 必须先成为“实习生”，才能升为“正式员工” |
互斥角色是信息安全里的基础防舞弊手段。我在银行项目里亲眼见过，没有互斥约束，一个运维人员同时拥有DBA和审计权限，出了泄露事故都查不到痕迹。
关键认知：RBAC2不限制继承，只约束分配。所以RBAC2可以和RBAC1共存——这就是后面要讲的RBAC3。
2.5 RBAC3：大融合，全都要
RBAC3 就是 RBAC1 + RBAC2。既支持角色继承，又支持约束规则。说白了，把两个增强特性组合到一起。
它解决了两个现实问题：
- 继承带来的“权限膨胀”：比如一个高级角色继承了所有低级角色，但某些权限需要被互斥约束限制
- 约束与继承的冲突处理：假设角色A和B互斥，但角色C继承了A和B——这咋办？RBAC3要求系统在分配时检查，如果C同时继承的两个角色互斥，则分配失败
实现复杂度上，RBAC3几乎是线性叠加。但在实际落地时，我建议优先从RBAC0起步，再根据痛点逐步引入继承和约束。别一上来就上RBAC3。
2.6 模型对比一张表
| 特征 | RBAC0 | RBAC1 | RBAC2 | RBAC3 |
|---|---|---|---|---|
| 角色继承 | 无 | 有 | 无 | 有 |
| 约束规则 | 无 | 无 | 有 | 有 |
| 实现复杂度 | 低 | 中 | 中 | 高 |
| 适用场景 | 中小型应用、简单垂直管理 | 有明显层级结构的组织（如公司、学校） | 有合规/审计要求（如金融、医疗） | 大型企业、多层级+多约束 |
选型建议：我的个人习惯是——先看有没有“职责分离”需求？有，则至少选RBAC2；再看有没有“自动继承”需求？有，则结合成RBAC3。如果都没有，RBAC0永远是最稳的起点。
2.7 知识体系结构图
下面这张图梳理了四个模型的关系与核心差异。建议收藏，以后跟别人讲RBAC时直接甩出来。
2.8 如何选择？我的决策清单
每次做权限架构评审时，我都会拿下面这个清单过一遍：
- 业务有没有明显的管理层级（如经理-主管-员工）？有 → 考虑RBAC1
- 业务有没有合规要求（如Sarbanes-Oxley、等保）？有 → 必须上RBAC2
- 团队规模和预期增长？如果超过500人，建议直接RBAC3
- 现有系统能否快速重构？不能 → 优先RBAC0过渡
- 审计日志的颗粒度要求？要求细 → 约束规则必不可少
曾经踩过的第二个坑：有个项目我上了RBAC3，但忘了配互斥规则中的继承检查，结果一个高级角色继承了多个互斥的低级角色，系统没报错。最后线上出了数据泄露。从此，我要求所有RBAC3实现都必须做 继承环路检测 和 继承互斥冲突检查。
好了，这一章的核心就是四个模型的关系。记住一句话：RBAC0是入门，RBAC1/2是进阶，RBAC3是终极形态，但不是每个系统都需要终极形态。