3. RBAC模型族谱：RBAC0、RBAC1、RBAC2、RBAC3的演进与适用场景
RBAC 不是单一模型，而是一组可组合的标准化模型家族，其核心演进路径由 NIST（美国国家标准与技术研究院）在 1992 年提出，并于 2001 年纳入 INCITS 359 标准。本章从架构角度定义各模型的边界、分层、组件交互与信任链路，帮助你在实际项目中做出准确的选型权衡。
核心认知：RBAC0 是所有模型的基础基座；RBAC1 引入角色继承；RBAC2 引入约束规则；RBAC3 是前两者的全功能合体。模型越高级，管控粒度越细，但架构复杂度与运维成本也越高。
3.1 模型族谱总览：四个层级的关系
下图展示了 RBAC 模型从基础到完整的演进结构，每个虚线框代表一个可独立部署或组合的模型层级。箭头表示“继承/包含”关系，即上层模型必须依赖下层核心能力。
3.2 边界与分层：每个模型的核心范围
| 模型 | 核心边界 | 引入机制 | 信任边界 | 典型场景 |
|---|---|---|---|---|
| RBAC0 | 用户 ↔ 角色 ↔ 权限 | 基础三元组、会话控制 | 角色管理在管理员侧，权限判定在运行时 | CMS后台、内部OA系统 |
| RBAC1 | 角色继承（RH） | 角色偏序（父子角色自动传递权限） | 继承链路必须保持无环，父级变更影响所有子级 | 企业组织架构（经理→主管→普通员工） |
| RBAC2 | 约束规则（SSD/DSD） | 静态职责分离、动态职责分离 | 约束在角色分配或激活时强制校验 | 金融系统（出纳与审核审计不能同一角色） |
| RBAC3 | 角色继承 + 约束规则 | 全功能组合 | 约束检查需遍历继承树，性能开销最大 | 大型企业统一身份平台、公有云IAM |
3.3 组件职责与数据流
3.3.1 核心组件（所有模型共享）
- 用户管理：维护用户身份与属性，作为角色分配的目标对象。
- 角色管理：定义角色名称、层级关系（RBAC1/3）、约束规则（RBAC2/3）。
- 权限管理：将操作许可绑定到角色，权限粒度可以是功能、数据行、API端点。
- 会话管理：控制用户一次登录中激活的角色集合，超时或切换会话时回收授权。
3.3.2 数据流（权限验证流程）
- 用户发起请求（带用户ID + 目标资源 + 操作）。
- 会话管理器查询该用户当前激活的角色列表（RBAC1 场景下需递归展开继承角色）。
- 约束校验器（RBAC2/3）检查当前操作是否违反 SSD/DSD 规则。
- 权限判定器遍历角色关联的权限集，匹配资源与操作，返回允许/拒绝。
- 审计日志记录判定结果，用于风险回溯。
3.3.3 控制流与信任链路
- 控制流方向：管理人员通过管理控制台 → 角色分配服务 → 约束引擎 → 权限存储；运行时请求通过 API 网关 → 会话上下文 → 权限判定引擎 → 业务服务。
- 信任关键点：角色分配必须由受信管理员执行；继承链路必须由系统自动验证无环；约束规则不能绕过权限判定直接赋予用户角色。
- 信任链路风险：在 RBAC3 中，若继承树深度超过 5 层，权限膨胀可能导致“非预期授权”，建议在角色定义时强制显式声明继承边界。
3.4 选型权衡：四个模型的适用决策矩阵
| 评估维度 | RBAC0 | RBAC1 | RBAC2 | RBAC3 |
|---|---|---|---|---|
| 实现复杂度 | 低 | 中（需维护继承图） | 中（需约束校验引擎） | 高（两者叠加） |
| 运维负担 | 低 | 中（继承变更需影响分析） | 中（规则变更需重校） | 高（综合管理成本） |
| 权限粒度 | 角色级 | 角色级 + 继承级 | 角色级 + 约束级 | 全维度精细管控 |
| 典型用户数 | <500 | 500~5000 | <2000（强制分离） | >5000 |
| 安全审计要求 | 基础 | 中等（需继承审计） | 严格（约束合规性审计） | 极高 |
常见误区：不要为了“功能完备”直接选用 RBAC3。四个模型是渐进增强的，过度设计会导致角色维护失控、权限判定瓶颈。正确的做法是：从 RBAC0 起步，当出现“角色爆炸”（RBAC1）或“权限滥用”（RBAC2）时再升级。
3.5 各模型风险点与落地步骤
3.5.1 风险点清单
- RBAC0 风险：角色数量随用户增长线性膨胀，无继承复用，导致角色管理失控。
- RBAC1 风险：继承链产生循环依赖或权限泄露（例如子级角色意外获取高层敏感权限）。
- RBAC2 风险：约束规则定义冲突（如两个互斥角色被同时分配到同一用户组的默认设置）。
- RBAC3 风险：继承与约束叠加后，权限判定路径变长，易出现核心路径性能瓶颈；规则修改影响面难以评估。
3.5.2 落地步骤（渐进式引入）
- 第一阶段（RBAC0）：梳理现有权限点，建立用户-角色-权限三表结构，实现基础分配与鉴权。
- 第二阶段（RBAC1 候选）：当角色数量超过 50 且存在明显上下级关系，设计角色继承树，定义父级自动继承子级的权限。
- 第三阶段（RBAC2 候选）：在金融、合规场景中定义 SSD 互斥规则，限制同一用户不能同时拥有“订单审批”与“财务对账”角色。
- 第四阶段（RBAC3）：将继承与约束合并，建立规则优先级（约束 > 继承），在运维平台中提供角色影响分析工具。
3.6 验收标准
| 验收项 | RBAC0 | RBAC1 | RBAC2 | RBAC3 |
|---|---|---|---|---|
| 权限判定准确率 | 100%（对应角色表） | 100%（含继承展开） | 100%（含约束校验） | 100%（继承+约束综合） |
| 角色分配完成率 | 所有用户至少一个角色 | 继承关系无循环 | 互斥规则无冲突 | 规则与继承共存时无覆盖冲突 |
| 响应延迟 | <10ms | <30ms（继承层数≤3） | <20ms | <50ms（继承+约束） |
| 管理操作成功率 | 角色增删改查 100% | 继承关系修改后权限重算成功 | 规则变更后合规性校验通过 | 全功能操作日志可追溯 |
架构决策提示：验收时重点关注“边界冒烟测试”——为每个模型设计一个极端输入（如继承深度 10 层、100 条互斥规则），观察系统是否仍能满足响应时间与准确率的要求。无法通过冒烟测试意味着需要拆分模型层级或引入更高效的数据结构（如增量计算继承权限）。