3、RBAC模型深度解析：RBAC0、RBAC1、RBAC2、RBAC3 模型详解与适用场景

聊到访问控制，RBAC 几乎是绕不开的基石。很多刚入行的朋友觉得 RBAC 就是「用户-角色-权限」三板斧，其实不然。我在好几个大型企业项目里都踩过 RBAC 选型的坑——选轻了后面扩展不动，选重了又过度设计。今天咱们就把 RBAC 的四个标准模型掰开揉碎，看看它们到底有什么区别，各自适合什么场景。

3.1 RBAC0：一切的基础

RBAC0 是核心模型，所有其他模型都建立在它之上。说白了就是三张表：用户、角色、权限，再加上用户-角色关联和角色-权限关联。

我见过不少初创公司，一开始就用 RBAC0，跑得挺顺。为什么？因为简单。用户登录后查角色，角色查权限，一条 SQL 搞定。

-- 典型的 RBAC0 表结构
CREATE TABLE users (
    id INT PRIMARY KEY,
    username VARCHAR(50)
);

CREATE TABLE roles (
    id INT PRIMARY KEY,
    role_name VARCHAR(50)
);

CREATE TABLE permissions (
    id INT PRIMARY KEY,
    perm_code VARCHAR(100)
);

CREATE TABLE user_roles (
    user_id INT,
    role_id INT
);

CREATE TABLE role_permissions (
    role_id INT,
    permission_id INT
);

适用场景：小型系统、内部工具、权限关系简单的应用。比如一个只有管理员和普通用户的后台，RBAC0 完全够用。

3.2 RBAC1：引入角色分级

RBAC1 在 RBAC0 的基础上增加了角色继承（Role Hierarchy）。什么意思？就是角色可以「继承」另一个角色的权限。

举个例子：

• 超级管理员 继承 管理员 的所有权限
• 管理员 继承 普通用户 的所有权限
• 你只需要给「普通用户」分配基础权限，上层角色自动拥有

我在一个电商平台项目中用过 RBAC1。当时有运营、运营主管、运营总监三层，每层权限逐级递增。如果用 RBAC0，得给每个角色重复分配权限，维护成本极高。用了继承之后，改一次底层权限，上层自动同步。

适用场景：组织层级分明的企业，比如 OA 系统、ERP 系统、项目管理平台。

3.3 RBAC2：加上约束规则

RBAC2 在 RBAC0 的基础上增加了约束（Constraints）。这些约束用来解决一个实际问题：不能让一个人同时拥有冲突的权限。

你想想看，如果一个人既是「采购员」又是「审批员」，那他自己下单自己审批，公司不就乱套了？RBAC2 就是干这个的。

常见的约束类型：

约束类型	说明	例子
互斥角色	一个用户不能同时拥有两个互斥的角色	采购员 vs 审批员
基数约束	一个角色最多分配给多少个用户	「超级管理员」最多 3 人
先决条件约束	要获得某个角色，必须先拥有另一个角色	必须先有「初级工程师」才能申请「高级工程师」
会话约束	一个用户一次登录只能激活部分角色	登录时选择「运维」或「开发」身份

我曾经在一个金融项目中吃过亏。当时没做互斥约束，结果一个运营人员同时拥有了「数据导出」和「数据删除」权限，不小心把生产数据删了。嗯，从那以后，RBAC2 的约束就成了我设计权限系统时的标配。

适用场景：金融、医疗、政务等对合规性要求高的行业。说白了，任何需要「分权制衡」的地方，RBAC2 都是好选择。

3.4 RBAC3：集大成者

RBAC3 就是 RBAC1 + RBAC2，既有角色继承，又有约束规则。它是美国国家标准与技术研究院（NIST）定义的完整 RBAC 模型。

听起来很完美对吧？但实际落地时要注意：继承和约束有时候会打架。

举个例子：

• 角色 A 和角色 B 是互斥的
• 角色 C 继承了角色 A
• 那么角色 C 和角色 B 也是互斥的

这个逻辑在代码里实现起来并不复杂，但业务人员理解起来有难度。我建议在设计阶段就把继承树和约束矩阵画清楚，别等到上线了才发现冲突。

3.5 四个模型的对比与选型

为了让你看得更清楚，我把四个模型的核心差异整理成了一张表：

模型	核心能力	复杂度	典型场景
RBAC0	用户-角色-权限	低	小型系统、内部工具
RBAC1	角色继承	中	层级组织、OA/ERP
RBAC2	约束规则	中	金融、医疗、合规场景
RBAC3	继承 + 约束	高	大型企业、SAP、政府系统

选型的时候，我一般会问自己三个问题：

1. 角色之间有没有明显的层级关系？有的话考虑 RBAC1 或 RBAC3。
2. 有没有「不能同时拥有」的权限要求？有的话考虑 RBAC2 或 RBAC3。
3. 团队有没有能力维护复杂的权限模型？没有的话，先从 RBAC0 起步，慢慢演进。

3.6 模型关系全景图

下面这张图展示了四个模型之间的演进关系，以及每个模型新增的核心能力：

从图上可以看得很清楚：RBAC0 是地基，RBAC1 和 RBAC2 是两条不同的扩展路径，RBAC3 则是两者的合流。实际项目中，你完全可以从 RBAC0 起步，等业务复杂了再逐步升级到 RBAC1 或 RBAC2，最后再考虑 RBAC3。