RBAC 模型与角色树概述
核心概念
基于角色的访问控制（RBAC）将权限管理从用户直接绑定权限，提升为“用户 → 角色 → 权限”的三层模型，使授权逻辑可复用、可审计。以下为 RBAC 核心实体及其关系。
| 实体 | 定义 | 示例 |
|---|---|---|
| User | 系统使用者，不直接获得权限 | 张三（员工工号） |
| Role | 权限的集合，关联岗位或职责 | HR 专员、项目经理 |
| Permission | 对资源执行操作的能力 | 查看员工信息、修改合同 |
| Session | 用户激活的角色实例，控制生效范围 | 张三激活“HR 专员”会话 |
关键原则：权限只能授予角色，不能授予用户；用户通过关联角色间接获得权限。这一隔离使权限变更只需调整角色，避免逐用户修改。
角色树结构
在企业级系统中，角色天然具备层级关系，形成「角色树」。父角色继承子角色的所有权限，并可以附加额外权限。合理的角色树能减少权限冗余，简化审计。
权限分配策略
RBAC 标准族定义了四种主要分配策略（RBAC0～RBAC3），实际项目通常组合使用。
- RBAC0（核心 RBAC）：用户-角色-权限三层结构，支持多对多关联。
- RBAC1（角色层级）：引入角色继承树，父角色自动获得子角色权限。
- RBAC2（职责分离）：静态/动态职责分离，防止冲突角色同时激活。
- RBAC3（统一模型）：合并层级与职责分离，最常落地的工业级方案。
落地建议：业务系统推荐选择 RBAC1 + RBAC2，配合角色树与职责分离策略实现灵活且安全的权限体系。
常见误区
| 误区 | 表现 | 影响 | 正确做法 |
|---|---|---|---|
| 角色膨胀 | 为每个最小业务场景创建角色 | 角色数量爆炸，管理成本剧增 | 按「职责聚合」设计，避免细粒度角色 |
| 平铺角色 | 所有角色放在同一层级，不使用继承 | 权限冗余，更新需逐一修改 | 利用角色树继承相似权限 |
| 权限直接挂用户 | 绕过角色体系直接授权 | 破坏 RBAC 模型，审计困难 | 强制通过角色授予权限 |
| 忽略职责分离 | 同一用户同时拥有互斥角色（如出纳与会计） | 内控风险，越权操作 | 定义角色互斥组，运行时检查 |
警示：角色树不等于组织架构树！角色基于「权限域」而非「行政级别」设计。例如，“部门经理”角色可能只拥有“查看本部门员工”的权限，不应自动继承“副总裁”角色的权限。
术语辨析
- 权限 vs 资源：权限 = 资源 + 操作（如“修改/contracts”），资源是数据实体，操作是动词。
- 角色 vs 组：角色是权限的集合，组是用户的集合；一个角色可包含多个组的用户，组可关联多个角色。
- 角色继承 vs 角色聚合：继承是“is-a”关系（子角色是父角色的一种特例），聚合是“has-a”关系（组合角色包含多个基本角色）。
- 会话 vs 上下文：会话是用户激活的角色实例，上下文还包括 IP、时间、设备等动态条件。