第2章：RBAC模型原理与构成
2.1 模型边界
RBAC（Role-Based Access Control）将权限与角色挂钩，用户通过角色获得权限。其核心边界如下：
| 维度 | 边界说明 |
|---|---|
| 适用场景 | 组织层级稳定、角色职责清晰、权限变化频率低的企业系统（如ERP、HRM）。 |
| 不适用场景 | 多维度属性驱动（如时间、地点、用户属性）、细粒度到资源实例级别的访问控制。 |
| 信任假设 | 角色分配由管理员人工维护，权限继承由模型自动推导，系统信任角色-权限映射关系的正确性。 |
| 扩展倾向 | 可叠加会话控制、角色层次、职责分离约束，但不可直接支持属性条件。 |
2.2 分层职责与权限继承
RBAC通过角色分层（Role Hierarchy）实现权限继承：上级角色自动获得下级角色的所有权限。角色树中每个节点代表一组权限集合，子节点继承父节点权限并可以添加私有权限。
- 支持方式：多数RBAC实现采用“权限包含”继承（父→子单向继承）。
- 层级限制：建议最大深度不超过5层，避免权限背离或角色爆炸。
- 冲突规则：同一用户分配多个角色时，权限取并集；若出现互斥角色则需按职责分离约束处理。
2.3 职责分离约束（SoD）
职责分离是RBAC的安全核心，分为静态职责分离（SSD）和动态职责分离（DSD）。
| 类型 | 说明 | 示例 |
|---|---|---|
| 静态（SSD） | 用户不能同时分配到两个互斥角色，通常建模为互斥角色集合。 | “财务经理”与“审计员”不能分配给同一用户 |
| 动态（DSD） | 用户可持有多个角色，但在同一会话中不能同时激活互斥角色。 | 用户同时拥有“提权”与“审批”角色，但一个会话中只能启用其一 |
SSD约束在用户-角色分配阶段强制检查，DSD在会话建立时检查。配置示例：
SSD: [{'角色1', '角色2'}, {'角色3', '角色4'}]
DSD: [{'角色A', '角色B'}]2.4 数据流与信任链路
关键链路：用户 → 角色分配（用户-角色关系） → 角色权限映射（角色-权限关系） → 资源操作。信任根基在于 角色权限映射 的完整性和静态约束的严格执行。
- 数据流方向：管理员分配角色 → 用户获取角色集合 → 根据会话激活角色 → 计算有效权限 → 决策引擎拦截请求。
- 信任风险：角色爆炸（角色数量过多导致管理混乱）、权限蔓延（角色被赋予超出职责的权限）、约束绕过（通过多层继承绕过互斥检查）。
2.5 选型权衡
| 对比项 | RBAC | ABAC | ReBAC |
|---|---|---|---|
| 权限粒度 | 粗（按角色） | 细（按属性） | 中（按关系路径） |
| 管理复杂度 | 低（角色少时） | 高（策略膨胀） | 中（关系图维护） |
| 动态适应性 | 差 | 强 | 较强 |
| 审计清晰度 | 高 | 中 | 中 |
当组织层级稳定且角色数量可控制在50以内时，RBAC是性价比最高的选择；否则需考虑引入ABAC或ReBAC。
2.6 风险点
常见陷阱
- 角色爆炸：为每个细微权限创建角色 → 建议使用角色层次合并。
- 继承歧义：角色层次图中出现环形继承 → 必须检测DAG属性。
- SoD绕过：通过父角色继承子角色从而获得互斥权限 → 约束检查应包含角色层次。
- 权限蔓延：非必要权限被添加到角色 → 定期做权限审计。
2.7 落地步骤
- 角色梳理：与业务部门识别所有岗位职责，命名角色并定义职责边界。
- 角色分层设计：构建角色树，确定继承关系，控制深度≤5层。
- 权限映射：为每个角色分配最小必要权限（Least Privilege）。
- 约束建模：识别静态互斥角色对，配置SSD；若需动态控制，增加DSD规则。
- 实现与测试：使用框架（如Spring Security）配置RBAC，编写单元测试验证继承和约束。
- 权限审计：上线后每周运行脚本检查角色权限变化及未使用的角色。
2.8 验收标准
- 功能验收：用户分配角色后，能按角色层次继承正确权限；互斥角色分配被阻止。
- 非功能验收：角色数量≤50时，权限计算耗时<10ms；新增角色对已有用户无影响。
- 安全验收：无用户能通过角色继承获得超越其职责的权限；SoD约束在分配和激活阶段均生效。
实践提示：优先使用“角色工程”方法（如NIST RBAC规范）进行角色定义，避免凭直觉拍脑袋创建角色。