RBAC 以及主流权限模型
一、RBAC（基于角色的访问控制，Role-Based Access Control）
核心思想：用户 → 角色 → 权限，用户不直接绑定权限，给角色分配权限，用户挂上角色就拥有对应权限。
RBAC 4 个版本
- RBAC0（基础版） ：用户 (User)、角色 (Role)、权限 (Permission)、会话 (Session)。多对多：一个用户多个角色，一个角色多个权限。最常用。
- RBAC1（角色分层） ：增加角色继承。角色 A 可以继承角色 B 的权限，适合组织层级（总监继承经理权限）。
- RBAC2（约束） ：增加业务约束：互斥角色、角色基数限制、先决角色。比如：一个人不能同时是 "审核人" 和 "申请人"。
- RBAC3 = RBAC1 + RBAC2：完整 RBAC，继承 + 约束。
✅ 优点：
- 业务简单，好理解，绝大多数后台管理系统用它
- 权限复用强，批量给用户授权很方便
❌ 缺点：
- 只能控制功能权限（按钮、菜单、接口） ，天然不擅长数据权限（只能靠额外扩展）
- 复杂细粒度场景会角色爆炸（角色泛滥）
举例：角色【普通运营】拥有查看订单、导出订单权限；用户张三分配这个角色，张三就有这些权限。
二、其他主流权限模型
1. ACL 访问控制列表（Access Control List）
用户直接绑定权限，没有角色中间层。
用户 → 权限列表
✅ 简单，小型系统。 ❌ 用户多的时候维护灾难，授权不能复用。
例子：张三：查看用户、编辑用户；李四：查看用户。
2. ABAC 基于属性的访问控制（Attribute-Based Access Control）
基于属性判断权限，公式化：if (属性满足条件) → 允许访问 属性分四类：
- 用户属性：部门、岗位、职级
- 资源属性：数据所属部门、创建人、数据类型
- 环境属性：IP、时间、设备
- 操作属性：增删改查
示例：
用户.部门 == 订单.所属部门 AND 用户.角色 = 运营才可以查看订单
✅ 优点：强大的数据权限，动态、细粒度，适合多维度复杂权限。云平台、阿里云 / 腾讯云权限、零信任系统大量使用。 ❌ 缺点：配置复杂，理解成本高，性能需要注意。
3. DAC 自主访问控制（Discretionary Access Control）
资源所有者可以自主授权其他人访问自己的资源。
文件主人可以把文件读写权限分给别人，所有者说了算。
✅ 灵活，典型例子：Linux 文件权限、网盘分享。 ❌ 权限容易扩散，安全不可控，很少用于企业后台系统。
4. MAC 强制访问控制（Mandatory Access Control）
系统强制分配安全标签，不能由用户自主修改。资源和用户都有密级标签，系统强制校验，人不能改标签。
比如：绝密、机密、秘密。绝密级用户才能访问绝密资料。
✅ 极高安全等级，军队、涉密系统。 ❌ 非常僵硬，通用业务系统几乎不用。典型：SELinux。
5. PBAC 基于策略的访问控制（Policy-Based Access Control）
和 ABAC 很接近，把权限封装成独立策略，策略单独管理。 很多场景 PBAC 会和 ABAC 混用，策略引擎去评估规则。适合大型组织统一权限策略管理。
6. ReBAC 基于关系的访问控制（Relationship-Based Access Control）
根据主体和资源之间的关系判定权限。现在很火，很多现代应用（开源 FGA、OpenFGA）在用。
例子：
can_view(user, doc) if user is owner of doc OR user is member of doc.team
✅ 擅长资源之间复杂关系：文档共享、团队协作、社交、多租户系统。 ❌ 关系图复杂后查询有性能压力。
快速对比总结
表格
| 模型 | 核心 | 适合场景 | 典型能力 |
|---|---|---|---|
| ACL | 用户直接绑权限 | 极小系统 | 简单功能权限 |
| RBAC | 用户 - 角色 - 权限 | 后台管理、ERP，90% 企业系统 | 菜单 / 按钮功能权限 |
| ABAC | 属性条件判断 | 复杂数据权限、云平台 | 多维度动态权限 |
| DAC | 资源所有者自主授权 | 文件、网盘分享 | 资源自主分享 |
| MAC | 安全标签强制管控 | 涉密、军工系统 | 高安全强制隔离 |
| ReBAC | 主体与资源关系 | 协作系统、文档权限 | 资源关系权限 |
实际项目选型经验
- 简单后台，只有菜单按钮权限：RBAC
- 需要行级数据权限（只能看本部门数据）：RBAC + ABAC 扩展（最常用组合）
- 大量资源共享、对象之间有关系：ReBAC
- 云平台、多租户复杂动态权限：ABAC