在构建任何需要用户登录和资源访问控制的系统时，权限模型的选择直接决定了系统的安全性、可维护性和扩展性。本文将带你深入理解两种主流权限模型——ACL 和 RBAC，并重点解析 RBAC 的四个层级（RBAC0～RBAC3），帮助你建立全局认知。
一、ACL 模型：最原始的权限控制
✅ 是什么？
ACL（Access Control List，访问控制列表） 是一种“资源 → 用户/角色”的直接授权方式。
- 每个资源（如菜单、接口、文件）维护一个列表，记录“谁可以访问它”以及“拥有哪些操作权限”。
- 关系本质：资源 与 用户/角色 之间是多对多。
📊 典型表结构
用户表（user） 权限表（permission） —— 描述“删除数据”、“导入Excel”等原子权限 资源表（resource） —— 可选，用于绑定权限到具体对象 用户-权限关联表（user_permission） → 直接授权 角色-权限关联表（role_permission） → 间接授权（可选） 用户-角色关联表（user_role）
⚙️ 特点
- 简单直接：适合小型系统或权限粒度极细的场景（如操作系统文件权限）；
- 维护成本高：用户一多，授权关系爆炸式增长；
- Spring Security 提供了
spring-security-acl模块支持，但使用较少。
💡 举例：
- 用户“油炸小波” → 有“查看报表”权限；
- 用户“油炸大波” → 有“删除数据 + 导入Excel”权限。
二、RBAC 模型：现代系统的主流选择
✅ 是什么？
RBAC（Role-Based Access Control，基于角色的访问控制） 引入“角色”作为中间层，实现 用户 ↔ 角色 ↔ 权限 的解耦。
核心思想：不直接给用户赋权，而是通过角色分配权限。
🌟 三大设计原则
- 最小权限原则：角色只拥有完成任务所需的最小权限集合；
- 职责分离（SoD）：关键操作需多人协作，避免一人独揽（如报账人 ≠ 审批人）；
- 数据抽象：权限应抽象为可复用的操作单元（如“编辑用户”而非“修改 user 表字段”）。
三、RBAC 的四个层级
🔹 RBAC0：基础模型（所有 RBAC 的起点）
- 用户 ↔ 角色：多对多
- 角色 ↔ 权限：多对多
- 用户的最终权限 = 所有角色权限的并集
✅ 这是绝大多数后台管理系统采用的模型。
[用户] —(1:N)— [用户角色关联] —(N:1)— [角色] [角色] —(1:N)— [角色权限关联] —(N:1)— [权限]
🔹 RBAC1：支持角色继承
- 在 RBAC0 基础上，角色之间可以形成父子关系（如“部门经理”继承“普通员工”的权限）；
- 子角色自动拥有父角色的所有权限；
- 形成角色层级树（Role Hierarchy）。
例如：
- “超级管理员” → 继承 “管理员” → 继承 “普通用户”
🔹 RBAC2：引入职责分离（Separation of Duty）
解决“冲突角色不能共存”的问题：
✅ 静态职责分离（SSD）
- 在分配角色时就做限制；
- 同一用户不能同时被授予互斥角色；
- 例如：
财务专员与报销申请人互斥。
✅ 动态职责分离（DSD）
- 用户可以拥有多个互斥角色，但在某次会话中只能激活其中一个；
- 由应用逻辑在运行时控制。
适用于高安全要求场景（如金融、审计系统）。
🔹 RBAC3：RBAC1 + RBAC2 的合体
- 同时支持 角色继承 和 职责分离；
- 是 RBAC 模型中最完整、最强大的版本；
- 实现复杂，通常只在大型企业或合规性要求高的系统中使用。
四、如何选择？
| 场景 | 推荐模型 |
| 小型内部工具、原型系统 | ACL（简单快速） |
| 通用后台管理系统（OA/CRM/ERP） | RBAC0（够用且易维护） |
| 多层级组织架构（集团→子公司→部门） | RBAC1（角色继承） |
| 金融、政府、审计等高安全场景 | RBAC2 / RBAC3（职责分离） |
📌 在微服务架构中，通常以 RBAC0 为基础，结合 JWT Token 携带用户角色，在网关或各服务中做权限校验。
五、小结
- ACL：直连式授权，简单但难维护；
- RBAC：通过“角色”解耦用户与权限，是现代系统的标准；
- RBAC0 是起点，RBAC1/2/3 是进阶扩展；
- 实际项目中，80% 的需求 RBAC0 已足够，无需过度设计。
理解这些模型，不仅能帮你设计出更合理的权限系统，也能在面试或技术方案评审中展现你的系统思维能力。
