RBAC模型详解：核心、层次与约束
模型这东西，说起来抽象，用起来其实很实在。咱们搞RBAC，得先搞清楚三个基本形态：核心RBAC、层次RBAC、约束RBAC。我这些年做过的审计项目，十有八九都是在跟这三兄弟打交道。下面我一个一个拆开讲。
1. 核心RBAC — 地基中的地基
核心RBAC是NIST标准里最基础的那层模型。说白了，就是「用户-角色-权限」这个三角关系。我见过不少公司一开始就硬上复杂的权限模型，结果把自己绕晕了。其实核心RBAC已经能解决大部分问题。
它定义了五个基本要素：
- 用户 — 操作系统的人或服务账号
- 角色 — 语义上的岗位或职责
- 权限 — 对资源的具体操作许可
- 会话 — 用户激活角色的临时上下文
- 分配关系 — 用户↔角色、角色↔权限
核心模型最关键的三个规则，我直接列成表：
| 规则 | 含义 | 我看到的常见坑 |
|---|---|---|
| 用户-角色分配 | 用户只能被授予角色，不能直接给权限 | 好多系统图省事，直接给用户绑权限 |
| 角色-权限分配 | 权限只能挂在角色上 | 角色膨胀时没人清理僵尸权限 |
| 会话控制 | 用户一次会话可以激活多个角色，但必须在授权范围内 | 忘了控制并发会话的权限叠加 |
核心RBAC适用哪些场景？嗯，中小企业的内部管理系统、单一应用的角色控制、权限粒度要求不高的场景。我建议初创团队先从这个开始，别一上来就想搞个大而全的魔改方案。
2. 层次RBAC — 带着继承关系的权限树
层次RBAC在核心模型上加了一个东西：角色继承。你想想看，公司里部门经理肯定比普通员工权限多，但又比总监少。这些层级关系如果用核心RBAC来表示，你就得重复创建一堆相似的角色。
层次RBAC把这种重复劳动省掉了。关键点：
- 上级继承下级所有权限 — 不用重复配置
- 支持单继承和多继承 — Java那种父类子类的关系，你也可以理解成角色可以有多位「父亲」
- 继承是传递的 — 如果A继承B，B继承C，那A自动拥有C的权限
常见的问题：
适用场景：企业内部的多层级组织架构、需要细分权限等级的应用、存在通用角色和特岗角色的系统。
3. 约束RBAC — 给权限装上的安全阀门
约束RBAC是三种模型里最「硬核」的。我在做金融系统审计时，几乎都会用到这个模型。它主要解决一个问题：如何防止权限的滥用和冲突。
约束分三类：
3.1 互斥角色
这是最常用的一种。意思是某些角色不能同时分配给同一个人。举个真实例子：谁负责申请采购，谁负责审批采购，这两个角色必须分开。如果同一个人既申请又审批，那内部审计形同虚设。
我见过最离谱的案例：一个公司的出纳兼任会计，结果两年里挪走了80万。这就是典型的没加互斥约束。
3.2 基数约束
限制某个角色能分配给多少人。比如「CEO」这个角色，你总不能给全公司都配上吧？核心系统管理员通常也只控制在一两个人。基数约束就是干这个的。
具体常用的基数场景：
- 系统管理员角色最多2人
- 一个用户最多持有3个敏感角色
- 审批类角色至少需要2人
3.3 先决条件角色
这个约束要求用户在获得某个角色前，必须先拥有另一个角色。说白了就是「先当兵，才能当班长」。我建议在培训认证和晋升流程中使用。
三种模型的适用场景对比
这里我直接放个对比清单，方便你对照自己手头的项目：
- 核心RBAC：SaaS多租户应用、小型内部OA、开放API的权限控制
- 层次RBAC：大型企业ERP、医院角色分级、学校教务处与院系的权限模型
- 约束RBAC：金融系统、政务审批平台、高风险操作集中的系统
实际项目中，这三种模型通常是组合使用的。没有一个项目只用纯核心RBAC，也没有一个项目能把约束做到滴水不漏。
下面这张图是我画的一个三种模型的结构关系，可以帮你快速建立整体认知：
看到图应该就清楚了：核心RBAC是骨架，层次RBAC解决了继承问题，约束RBAC加了边界控制。我常说的一句话是：没有的「最好模型」，只有「适合当前阶段」的模型。根据业务复杂度来选择，才是务实之道。