2. RBAC基础理论:RBAC0模型定义、用户-角色-权限三元组、角色继承与角色层级、静态职责分离(SSD)
2.1 RBAC0 核心模型定义
RBAC0 是 NIST RBAC 标准中最基础的层次,定义了权限管理的核心三元组:用户(User)、角色(Role)、权限(Permission)。其核心思想是:用户不直接与权限关联,而是通过角色作为中间层间接获得权限。
核心公式: 用户 ∈ 角色 → 角色 ∈ 权限 → 用户 ∈ 权限
RBAC0 模型包含以下基本元素:
| 元素 | 定义 | 示例 |
|---|---|---|
| 用户(User) | 系统操作的主体,可以是人、服务账号或设备 | 张三(员工工号 1001) |
| 角色(Role) | 组织内职责或职能的抽象集合 | 财务审核员、系统管理员 |
| 权限(Permission) | 对特定资源执行特定操作的许可 | 读取订单表、写入审批记录 |
| 会话(Session) | 用户激活角色集合的运行时上下文 | 用户登录后激活的角色列表 |
2.2 用户-角色-权限三元组关系
三元组通过多对多关系实现灵活授权:一个用户可拥有多个角色,一个角色可包含多个用户;一个角色可关联多个权限,一个权限也可被多个角色持有。
设计要点: 三元组中的“权限”应细化为 操作(Operation) + 资源(Resource) 的二元组。例如:
read:order_table 表示对订单表的读取操作。这种粒度便于后续扩展为 ABAC 属性约束。
2.3 角色继承与角色层级
RBAC0 支持角色层级(Role Hierarchy),即角色之间可以形成偏序关系。上级角色自动继承下级角色的所有权限,但下级角色不反向继承上级权限。
角色层级分为两种类型:
- 通用层级(General Hierarchy): 支持多继承,一个角色可以有多个父角色和多个子角色。
- 受限层级(Limited Hierarchy): 仅支持单继承(树形结构),每个角色最多只有一个父角色。
继承陷阱: 角色层级过深(超过 5 层)会导致权限溯源困难。建议将层级控制在 3 层以内,并在设计阶段明确每个角色的职责边界,避免“万能角色”的出现。
2.4 静态职责分离(SSD)
静态职责分离(Static Separation of Duty, SSD)是 RBAC0 中防止权限滥用的关键约束机制。它通过角色互斥规则,确保一个用户不能同时拥有冲突的角色组合。
SSD 的核心规则:
- 角色互斥(Mutually Exclusive Roles): 定义一组角色集合,用户最多只能被分配其中的一个角色。
- 基数约束(Cardinality Constraints): 限制一个角色最多可被分配的用户数量,或一个用户最多可拥有的角色数量。
- 前提角色(Prerequisite Roles): 用户必须先拥有某个角色,才能被分配另一个角色。
| SSD 类型 | 约束规则 | 应用场景 |
|---|---|---|
| 角色互斥 | 用户不能同时拥有角色 A 和角色 B | 出纳员 vs 会计审核员(防止一人完成付款全流程) |
| 基数约束 | 角色 A 最多分配给 3 个用户 | 超级管理员角色仅限 2 人持有 |
| 前提角色 | 必须先有角色 A 才能分配角色 B | 必须先成为“初级审核员”才能晋升为“高级审核员” |
SSD 实现示例(伪代码):
// 定义互斥角色组
const MUTEX_ROLES = [
['出纳员', '会计审核员'],
['采购员', '采购审批员']
];
// 分配角色时校验
function assignRole(userId, roleName) {
const userRoles = getUserRoles(userId);
for (const mutexGroup of MUTEX_ROLES) {
if (mutexGroup.includes(roleName)) {
const conflict = mutexGroup.find(r => userRoles.includes(r));
if (conflict) {
throw new Error(`角色冲突:用户已有角色 ${conflict},不能分配 ${roleName}`);
}
}
}
// 执行分配逻辑...
}
2.5 RBAC0 模型总结
RBAC0 为权限系统提供了坚实的理论基础,其核心价值在于:
- 简化管理: 通过角色中间层,将用户与权限解耦,降低授权复杂度。
- 职责分离: SSD 机制天然支持合规要求(如 SOX、PCI-DSS 中的职责分离)。
- 可扩展性: 角色层级支持组织架构的自然映射,便于权限的继承与复用。
实践建议: 在构建 RBAC0 模型时,建议先梳理组织内的职责域(Domain of Responsibility),再抽象为角色。每个角色应对应一个明确的业务职能,避免出现“万能角色”或“空角色”。后续章节将在此基础上引入 ABAC 属性约束,实现更细粒度的动态权限控制。