3、RBAC模型变体：从平坦到对称，四种常用演进
RBAC 这个模型，说起来简单——「用户→角色→权限」。但实际落地时，你会发现一个角色体系根本不够用。我在几个中大型项目里都踩过坑：一开始只建了十几角色，结果半年后膨胀到上百个，权限分配乱成粥。后来才明白，RBAC 其实有一整套变体家族。今天我就把这四种最常见的变体掰开讲清楚。
3.1 平坦 RBAC（Flat RBAC）——最朴素的原型
平坦 RBAC 是 NIST RBAC 标准里的最基础层。说白了就是：用户直接挂角色，角色直接挂权限，没有任何继承、约束或层级。我最早做的一个内部 CMS 系统就是用的这种。当时团队小，角色只有「管理员」「编辑」「访客」三个，平坦模型完全够用。
适用场景：角色数量少（< 20）、权限变更不频繁的小团队系统。如果角色膨胀到上百个，平坦模型会让你痛不欲生——每个用户都要手工维护角色，权限审计基本靠人眼扫 Excel。
3.2 层级 RBAC（Hierarchical RBAC）——让角色继承
层级 RBAC 在平坦基础上加了「角色继承」。比如「高级管理员」继承「普通管理员」的所有权限，再额外加几个特殊权限。我个人最常用的是单继承（每个子角色只有一个父角色），因为实现简单，权限路径清晰。多继承虽然灵活，但容易搞出菱形冲突。我之前在某个 ERP 项目里试过多继承，结果角色关系图变成了蜘蛛网，最后不得不回退成单继承。
| 对比项 | 平坦 RBAC | 层级 RBAC |
|---|---|---|
| 角色数量上限 | 约 20-50 | 可达数百 |
| 权限管理成本 | 随角色数线性增长 | 继承后呈对数下降 |
| 典型实现 | 简单 JOIN 表 | 使用 parent_id 或闭包表 |
3.3 约束 RBAC（Constrained RBAC）——加一道安全锁
约束 RBAC 在层级基础上加入了两类约束：静态职责分离（SSD）和动态职责分离（DSD）。我印象最深的是在金融支付系统里，SSD 规定「出纳员」和「对账员」不能由同一人担任，这直接避免了单点舞弊。DSD 则是运行时检查——比如用户在同一会话中不能同时扮演「审批人」和「申请人」。
常见的约束类型：
- 互斥角色：同用户不能拥有角色 A 和角色 B（如采购、验收）
- 前提角色：要获得角色 A，必须先拥有角色 B（如「高级经理」需先有「经理」）
- 基数约束：角色 A 最多分配给 N 个用户（如「系统管理员」仅限 2 人）
3.4 对称 RBAC（Symmetric RBAC）——双向闭环
对称 RBAC 是 NIST 标准里比较特殊的一种。它不只是在用户-角色-权限之间做正向分配，还支持反向撤销。什么意思呢？你给用户 Alice 分配了「编辑」角色，当角色定义中删除了「编辑文章的权限」时，Alice 的实际权限会自动回收。很多人做权限系统只做「分配」不做「回滚」，导致权限残留。我记得有一次安全审计，发现一个离职一年的员工居然还能访问旧系统——就是因为对称机制没做好。
| 变体 | 核心新增 | 典型痛点 |
|---|---|---|
| 平坦 RBAC | 基础模型 | 角色膨胀后管理难 |
| 层级 RBAC | 角色继承 | 多继承的菱形冲突 |
| 约束 RBAC | SSD / DSD | 约束规则的设计与维护 |
| 对称 RBAC | 双向联动 | 反向传播的性能开销 |
3.5 四种变体如何落地到双人审批场景
我们这门课的主题是「双人审批 + RBAC」，所以最后聊点实际的。在双人审批流程中，角色分配经常要满足「审批人不能是自己」这类约束——这就属于约束 RBAC 的 DSD（动态职责分离）。而审批链的「逐级上报」天然需要层级 RBAC：比如「主管审批→经理审批→总监审批」，每一级继承上一级的「审批权限」并增加额度上限。
我在设计某企业的费用报销审批系统时，就用了这样一套模式：
- 角色层级：员工→主管→部门经理→总监→CFO，单继承，每层额度上限不同
- 静态约束：互斥角色——「填单人」和「审批人」不能为同一角色
- 动态约束：同一单据的「发起人」不能是「当前审批人」
- 对称联动：当某位员工晋升，旧角色的审批权限自动剥离