第二章：RBAC模型层次——从RBAC0到RBAC3
好，咱们来聊聊RBAC模型的四个层次。很多人刚开始接触时，总觉得这些概念又长又绕。其实说白了，它们就像盖房子——从地基开始，一层层往上加功能。RBAC0是最简单的，RBAC1加了继承，RBAC2加了约束，RBAC3就是把前两个合并了。
我见过不少团队一上来就想搞RBAC3，结果搞到一半发现连RBAC0都没跑通。嗯，这事急不得。
RBAC0：基础模型，权限控制的起点
RBAC0是核心，是所有高级模型的基础。它的结构很简单：用户→角色→权限。每个用户分配一个或多个角色，每个角色拥有若干权限。
核心知识点：
- 用户与角色是多对多关系
- 角色与权限也是多对多关系
- 一个用户可以拥有多个角色，一个角色可以分配给多个用户
我之前带过一个电商项目，初期就只用了RBAC0。角色有管理员、运营、客服。管理员能看所有数据，运营能操作商品上架，客服只能查订单。够用吗？够用。但一旦组织变大，你就会发现缺东西了。
实际经验：如果你的系统角色少于10个且没有上下级关系，RBAC0完全够用。别盲目追求复杂模型。
RBAC1：角色分层，引入继承
RBAC1在RBAC0的基础上加了角色继承。什么是继承？就是高层角色自动拥有低层角色的所有权限。
举个例子：你的系统里有“普通用户”、“高级用户”和“管理员”三个角色。按照RBAC1的设计，管理员可以继承高级用户的所有权限，高级用户继承普通用户的所有权限。这样设计的好处是省去了重复授权的工作。
| 角色 | 继承自 | 额外权限 |
|---|---|---|
| 管理员 | 高级用户 | 系统配置、用户管理 |
| 高级用户 | 普通用户 | 批量导入、数据导出 |
| 普通用户 | 无 | 浏览、查询、下单 |
需要注意：继承是单向的，向下流动。你不能让普通用户拥有管理员的权限，那是反向继承，不允许。
避坑提醒：我曾经在一个项目中看到有人设计“循环继承”——A继承B，B继承A。这会导致权限判定死循环。记住，角色继承必须是严格的层次结构，不能有环。
RBAC2：加入约束，细化控制
RBAC2在RBAC0的基础上添加了约束条件。我最喜欢的就是这一点——它让权限控制变得更精细了。
约束主要有这么几种：
- 互斥角色：一个用户不能同时拥有两个互相排斥的角色。比如“出纳”和“会计”不能是同一个人。
- 基数约束：限制某个角色的最大成员数。比如“超级管理员”最多只能有3个人。
- 先决条件角色：要成为某个角色，必须先拥有另一个角色。比如想当“导师”，必须先当“助教”满1年。
- 运行时约束：在特定条件下才生效的约束。比如“临时管理员”只能在夜班时段拥有管理权限。
一句话总结：RBAC2的约束，就是帮你在权限分配时加一道安检门。通过了才能放行，没通过就打回。
我做过一个金融系统的权限审计，里面就用了大量互斥约束。你看，一个操作员不能同时拥有“创建订单”和“审批订单”的权限，这叫职责分离。没有这个约束，舞弊风险会大大增加。
RBAC3：合二为一，最完整的模型
RBAC3就是把RBAC1的继承和RBAC2的约束整合在一起。换句话说，它既有角色层次结构，又有各种约束规则。
这是最灵活的模型，也是最复杂的。我建议你在确实需要时再用它。我见过一些小团队硬上RBAC3，结果约束和继承互相打架，权限排查起来非常痛苦。
我的建议：先评估系统复杂度。如果角色层级超过3层，并且有互斥要求，再考虑RBAC3。否则，RBAC1或RBAC2就够用了。
下面这张图可以帮你快速理解四个模型的关系。
四个模型对比总结
| 模型 | 核心特点 | 适用场景 | 复杂度 |
|---|---|---|---|
| RBAC0 | 基础授权，无继承无约束 | 小型团队、简单系统 | 低 |
| RBAC1 | 角色分层，权限自动继承 | 层级分明的组织架构 | 中 |
| RBAC2 | 约束控制，精细化管理 | 金融、医疗等高合规要求场景 | 中高 |
| RBAC3 | 继承+约束，功能最全 | 大型复杂企业系统 | 高 |
我在实际审计中看到的常见问题
- 过度设计：明明用RBAC0就能解决的业务，硬要上RBAC3，结果配置维护成本翻倍。
- 继承滥用：把所有角色都放在一条继承链上，导致一旦有人拥有高级角色，就拥有了所有下层权限。
- 约束冲突：互斥约束和基数约束同时作用时，用户既不能A也不能B，最后没人能干活。
重要提醒：无论使用哪个模型，都建议在数据库层面记录授权变更日志。我在做审计时发现，很多问题的根源就是“谁在什么时候给了谁什么权限”根本查不到。
好了，这一章就到这儿。理解了这四个层次的差异，你就能根据自己的系统规模选择合适的RBAC模型。记住，没有最好的模型，只有最合适的。