2. RBAC 模型演进：从 RBAC0 到 RBAC3 的对比分析
RBAC（基于角色的访问控制）模型并非单一标准，而是经过多年实践逐步演进的体系。美国国家标准与技术研究院（NIST）在 1992 年提出核心模型后，陆续补充了角色继承、角色约束等能力，最终形成了四个层次分明的模型族。理解这四代模型的演进逻辑，是掌握 RBAC 签名证据校验体系的基础。
2.1 RBAC0：核心基础模型
RBAC0 是所有 RBAC 模型的基石，定义了最核心的三要素：用户（User）、角色（Role）、权限（Permission）。其核心思想是“用户通过角色获得权限”，实现了用户与权限的逻辑分离。
- 用户-角色关联：一个用户可以拥有多个角色，一个角色也可以被多个用户持有。
- 角色-权限关联：每个角色被赋予一组权限（操作+资源对象）。
- 会话管理：用户登录时激活一个或多个角色，会话期间仅拥有这些角色的权限。
2.2 RBAC1：引入角色继承
RBAC1 在 RBAC0 的基础上增加了角色继承（Role Hierarchy）机制。角色之间可以形成偏序关系，子角色自动继承父角色的所有权限。这一特性显著减少了权限重复配置的工作量。
角色继承分为两种类型：
- 通用继承：子角色继承父角色的全部权限，且可以额外拥有自己的私有权限。
- 受限继承：子角色只能继承父角色的部分权限（通过私有权限集控制）。
2.3 RBAC2：引入角色约束
RBAC2 在 RBAC0 的基础上增加了约束（Constraints）机制，用于解决权限滥用和职责冲突问题。约束是 RBAC 模型中最重要的安全控制手段之一。
RBAC2 定义了四种核心约束类型：
| 约束类型 | 定义 | 示例 |
|---|---|---|
| 互斥角色（SSD） | 同一用户不能同时拥有两个互斥的角色 | 出纳员与会计员不能由同一人担任 |
| 基数约束 | 限制角色可被分配的最大用户数 | “系统管理员”角色最多只能有 3 人 |
| 先决条件角色 | 用户必须先拥有某个角色，才能获得另一个角色 | 必须先有“普通用户”角色，才能申请“VIP 用户” |
| 会话约束 | 限制单个会话中可激活的角色数量或组合 | 同一会话中不能同时激活“审计员”和“操作员” |
2.4 RBAC3：统一模型
RBAC3 是 RBAC 模型族的最高形态，它同时融合了 RBAC1 的角色继承和 RBAC2 的角色约束，形成了一套完整的访问控制体系。RBAC3 并非简单的叠加，而是对继承与约束之间的交互关系进行了严格定义。
RBAC3 的核心特征包括：
- 支持多层角色继承，且继承关系可以跨越多个层级。
- 约束规则可以作用于继承链上的任意节点。
- 互斥约束可以阻止某些角色之间的继承路径。
- 基数约束可以限制继承链中某个角色的用户数量上限。
2.5 四代模型对比总览
下表从核心能力、复杂度、适用场景三个维度对 RBAC0~RBAC3 进行横向对比：
| 模型 | 核心新增能力 | 复杂度 | 典型适用场景 |
|---|---|---|---|
| RBAC0 | 用户-角色-权限分离 | 低 | 中小型系统、CMS、内部工具 |
| RBAC1 | 角色继承（层级结构） | 中 | 企业组织架构、职级体系 |
| RBAC2 | 角色约束（互斥/基数/先决条件） | 中高 | 金融、医疗、合规敏感系统 |
| RBAC3 | 继承 + 约束统一管理 | 高 | 大型企业、政府、云平台 |
2.6 RBAC 模型演进关系图
下图展示了 RBAC 模型从核心到统一的演进路径，以及各模型之间的包含关系：
2.7 签名证据校验视角下的模型选择
在《RBAC 签名证据校验》课程体系中，不同 RBAC 模型对签名校验的影响差异显著：
- RBAC0：签名校验只需验证用户-角色-权限的静态映射关系，校验逻辑最简单。
- RBAC1：签名校验需要递归解析角色继承链，确保子角色签发的操作在父角色权限范围内。
- RBAC2：签名校验必须检查约束规则是否被违反，例如互斥角色同时激活时的签名无效。
- RBAC3：签名校验需要同时处理继承和约束，校验引擎的复杂度最高，但安全覆盖最全面。
2.8 模型演进总结
RBAC 模型的演进本质上是权限管理粒度和安全约束能力的逐步增强。从 RBAC0 的“能用”到 RBAC3 的“好用且安全”，每一步演进都解决了实际业务中的特定痛点。在实际系统设计中，并非一定要选择最高级的 RBAC3，而是应该根据业务复杂度、合规要求、运维成本综合评估，选择最适合当前阶段的模型。