RBAC96 模型家族 — Sandhu 角色访问控制奠基论文
笔记类型：论文消化 | 领域：访问控制 / 安全工程
元信息
- 论文：Role-Based Access Control Models (RBAC96)
- 作者：Ravi S. Sandhu (Penn State), Edward J. Coyne, Hal L. Feinstein, Charles E. Youman (C2 Inc.)
- 发表：IEEE Computer, Volume 29, Number 2, February 1996, pp. 38-47
- 地位：RBAC 领域的奠基性论文，后来成为 NIST RBAC 标准（INCITS 359）和 Common Criteria 的理论基础
核心思想
RBAC 的本质是在用户和权限之间插入”角色”作为中介层，实现策略中立（policy-neutral）的访问控制。论文提出一个从简到繁的模型家族 RBAC₀–RBAC₃，每一层只增加一个概念：
| 模型 | 新增概念 | 说明 |
|---|---|---|
| RBAC₀ | 核心模型 | 用户-角色-权限三段式 + 会话 |
| RBAC₁ | 角色层次 (RH) | 继承：高级角色自动获得低级角色权限 |
| RBAC₂ | 约束 (Constraints) | 职责分离、基数限制等组织策略 |
| RBAC₃ | 二者结合 | RH + Constraints（注意：RBAC₁ 和 RBAC₂ 互不包含，可任选先序） |
RBAC₀ 核心模型要素
- U, R, P, S：用户、角色、权限、会话
- PA ⊆ P×R：权限-角色分配（多对多）
- UA ⊆ U×R：用户-角色分配（多对多）
- user: S→U：每个会话绑定单一用户（会话期内不变）
- roles: S→2^R：会话激活的角色子集（可随时间变化）
- 会话权限 = 激活角色的权限并集
- 权限是不可解释的符号（uninterpreted symbols）——权限的具体含义由实现决定，这是模型保持策略中立的关键
- 管理权限（修改 U/R/P/PA/UA 的权限）不属于 RBAC₀，假设由单一安全官控制
- 职责（duties）被明确排除：作者认为属于更高级概念，需进一步研究（可走 task-based authorization 路线）
RBAC₁ 角色层次
- RH 是 R 上的偏序（自反、传递、反对称），惯例：高级角色在上
- 继承传递：主治医师 → 医师 → 医疗提供者
- 支持多继承（项目主管同时继承测试工程师和程序员）
- 私有角色（private roles）技巧：若测试工程师想让某些权限不被上级角色继承，引入测试工程师′ 承载私有权限，员工直接分配到 ′ 角色。层级图因此保持”权限分布”的准确语义，优于”阻断继承”的黑箱做法
- 私有子层级 = 整个子树复制一份（共享权限放原树，私有权限放 ′ 树），便于安全审查
RBAC₂ 约束
约束是 RBAC 落地的关键机制（作者称其常被当作采用 RBAC 的首要动机）：
- 互斥角色（职责分离 SoD）：采购经理与应付账款经理不得为同一人
- 对偶约束（论文独有的重要洞察）：互斥不仅约束 UA（用户↔角色），也应约束 PA（权限↔角色）——同一权限不得同时分配给互斥角色集中的两个角色，防止”开支票”权限被误配/恶意配给采购经理
- 基数约束：用户最多属于 n 个角色；权限最多分配给 n 个角色（对偶）
- 先决角色：想获得角色 B 必须先已属于角色 A（对偶：分配权限 p 前角色必须已有权限 q，如”读文件需先有读目录权限”）
- 会话约束：可同属两角色但不能同时激活；限制并发会话数
- 前提纪律：用户 ID 必须与自然人一对一，一人多号则职责分离全线失效
RBAC₃ 层次与约束的交互陷阱
- 高级角色可能”violate”互斥约束（项目主管继承自互斥的测试工程师和程序员）——模型不预设哪种可接受，留给策略
- 基数约束是否覆盖继承成员？论文不裁决，指出这是设计决策点
- 私有角色天然无公共上级，互斥声明永不冲突——这是私有角色的实用红利
管理模型：RBAC 管 RBAC 自身
- 下半图是上半图的镜像：AR（管理角色）、AP（管理权限）、APA、ARH
- 内建约束：普通权限只能分配给普通角色，管理权限只能分配给管理角色
- ARBAC₀ 管 RBAC₃ 合理，反之无意义——管理模式应比业务模式简单
- 作用域（scope）限定：SO1 只管 T1 子树，不自动继承对 P 的管理权；管理权还需限定”能管哪些用户/权限/操作”（如只能加用户不能删）
- 二级管理金字塔作者明确不推荐（过于复杂不实用）
可行动点 / 工程启示
- 设计权限系统时，把”互斥”同时施加在用户-角色和权限-角色两个维度（对偶约束），比只做人-角色分离更可靠
- 权限语义保持中立（不透明符号），策略靠层次+约束外挂——这正是后来 Spring Security / AWS IAM 等系统的演化方向
- “一人一号”是任何 RBAC 系统有效的前提条件，账号治理先于权限治理
- 管理面板本身也需要 RBAC，且管理模型刻意保持简单
关联
- 形式化方法-裘宗燕-课程讲义（同目录课程资料）
- 与 NIST RBAC 模型 (2001) 一脉相承：本文是其直接前身