RBAC权限模型

RBAC（Role-Based Access Control，基于角色的访问控制）是目前企业系统最主流的权限模型，也是绝大多数后台管理系统（OA、ERP、CRM、MES、IAM、Kubernetes、Linux sudo 等）的基础。

相比直接给用户分配权限，RBAC引入了一个角色（Role）作为中间层：

用户 → 角色 → 权限

这样权限管理会简单很多。

RBAC 的核心元素

经典 RBAC 一共有四个对象。

User（用户）

Role（角色）

Permission（权限）

Session（会话）

最重要的是前三个。

关系如下：

User
  │
  │ 多对多
  ▼
Role
  │
  │ 多对多
  ▼
Permission

权限（Permission）到底是什么？

权限其实就是：

允许执行某个操作。

例如：

GET /users

POST /users

DELETE /users

也可以是：

文章阅读

文章发布

文章删除

也可以：

菜单显示

按钮显示

接口访问

通常一个权限至少包含：

资源(Resource)

操作(Action)

例如：

user:create

user:update

user:delete

order:read

order:refund

很多框架都采用这种字符串。

RBAC 的数据库设计

经典设计：

user
-------
id
name

role
-------
id
name

permission
-----------
id
code
name

user_role
-----------
user_id
role_id

role_permission
----------------
role_id
permission_id

全部都是多对多。

例如：

张三

↓

运营
客服

↓

查看订单
修改订单
回复工单

所以：

一个用户可以多个角色。

一个角色也可以多个权限。

---

RBAC0（基础模型）

这是最基础版本。

只有：

User

Role

Permission

关系：

User

↓

Role

↓

Permission

例如：

管理员

↓

所有权限

运营

↓

商品管理

客服

↓

工单管理

这是95%的后台。

---

RBAC1（角色继承）

角色也可以继承。

例如：

普通员工

↓

主管

↓

经理

↓

总监

图：

经理

↓

拥有主管权限

↓

拥有员工权限

例如：

员工：

查看报销

-----------------

主管：

查看报销
审批报销

-----------------

经理：

查看报销
审批报销
删除报销

不用重复配置。

继承即可。

---

RBAC2（约束）

增加各种规则。

例如：

互斥角色

一个人不能同时：

财务

出纳

否则：

自己审批自己。

所以：

不能同时拥有两个角色

---

最大角色数

例如：

一个用户最多3个角色

---

前置角色

例如：

只有主管

才能成为经理

---

动态约束

例如：

登录以后：

今天只能启用：

管理员

不能同时启用：

审计员

因为：

避免权限冲突。

---

RBAC3

就是：

RBAC1

+

RBAC2

既支持继承。

也支持约束。

也是 ANSI/NIST RBAC 标准。

---

Session（会话）

很多人不知道 Session。

其实很重要。

例如：

张三：

管理员

开发

测试

登录以后：

系统问：

请选择：

□ 管理员

□ 开发

□ 测试

本次：

只启用：

开发

那么：

管理员权限不会生效。

这样更安全。

很多大型 IAM（身份与访问管理）系统都支持这种机制。

---

RBAC 的优点

① 权限复用

例如：

100 个客服。

只需要：

客服

↓

配置一次权限

新增员工：

加入客服角色

结束。

---

② 易维护

离职：

删除用户

↓

权限自然消失

岗位调整：

运营

↓

客服

改角色即可。

---

③ 权限统一

所有客服权限一样。

不会：

张三少一个权限

李四多一个权限

---

④ 审计方便

查看：

为什么有权限？

一路追踪：

张三

↓

运营

↓

商品修改权限

非常清晰。

---

⑤ 扩展方便

新增：

直播运营

创建一个角色即可。

不用改代码。

---

RBAC 的缺点

① 粒度不够细

例如：

运营：

可以修改商品

但是：

只能修改自己负责的商品

RBAC 表达不了。

它只能：

能

不能

不能：

能修改自己的

---

② 数据权限不好处理

例如：

销售：

只能看到自己的客户

经理：

可以看到部门客户

总监：

可以看到全公司

RBAC 做不了。

这属于：

数据权限（Data Authorization）。

通常需要配合组织架构、部门树、区域、标签或策略来实现。

---

③ 角色爆炸（Role Explosion）

这是 RBAC 最大的问题。

假设：

运营

运营（广州）

运营（北京）

运营（上海）

运营（高级）

运营（临时）

运营（海外）

运营（海外高级）

最后：

几百个角色

越来越乱。

---

④ 临时权限麻烦

例如：

领导说：

今天让张三

临时审批一天

RBAC：

只能：

新建角色

↓

赋予角色

↓

第二天删除

不优雅。

实际中通常会支持临时授权（带有效期）或直接授予少量例外权限。

---

⑤ 特殊用户难处理

例如：

CEO：

拥有所有权限

但是：

不能删除日志

RBAC：

可能需要：

CEO角色

再单独减权限。

容易复杂。

---

RBAC 与 ACL、ABAC 的对比

模型	核心思想	优点	缺点	适用场景
ACL（Access Control List）	用户 → 权限	粒度细，灵活	权限关系爆炸，难维护	文件系统、对象权限（如每个文件的读写权限）
RBAC（Role-Based Access Control）	用户 → 角色 → 权限	简单、易维护、符合组织结构	数据权限和复杂场景支持不足，角色易膨胀	企业后台、ERP、OA、IAM、Kubernetes、Linux sudo
ABAC（Attribute-Based Access Control）	根据用户、资源、环境等属性动态决策	最灵活，可表达复杂规则	实现复杂、调试和审计成本高	云平台、金融、政府、零信任架构

例如，ABAC 可以直接表达：

允许访问，当且仅当：
用户.department == 资源.department
AND 用户.level >= 3
AND 当前时间 < 18:00
AND 登录地点属于公司网络

这是传统 RBAC 难以直接表示的。

---

现代企业的实践

纯 RBAC 已经越来越少见，大多数成熟系统采用混合模型：

用户
   │
   ▼
角色（RBAC）
   │
   ▼
功能权限（菜单、按钮、API）

           +
数据权限（部门、区域、项目、租户）

           +
属性策略（ABAC）

例如一个 CRM 系统中：

• RBAC：决定你能否访问“客户管理”“合同审批”等功能。
• 数据权限：决定你只能看自己的客户、部门客户还是全公司的客户。
• ABAC：进一步限制如“只能在工作时间审批”或“必须通过公司 VPN 才能导出数据”。

因此，RBAC 更适合作为权限体系的“骨架”，而数据权限和策略控制则负责解决细粒度访问控制问题。大型企业（尤其是 SaaS、多租户和云平台）通常都会将这几种模型结合使用，而不是只依赖单一的 RBAC。