RBAC(基于角色的访问控制)
一家快速扩张的创业公司,一年之内从 50 人增长到 500 人。HR 系统里的部门在变、岗位在变、入职离职在变。运维工程师发现,每次组织架构调整,都要花三天时间在各个系统中逐个修改权限配置。错误、遗漏、延迟——传统的用户-权限直接映射模式,已经成为组织扩张的瓶颈。
RBAC 的诞生,正是为了解决这个问题。
一、RBAC 的核心概念
RBAC(Role-Based Access Control)引入了「角色」作为用户与权限之间的中间层:
三个核心关系:
- 用户-角色分配(UA):用户被分配到角色
- 角色-权限分配(PA):角色被授予权限
- 角色-角色关系:角色之间存在继承或其他关系
二、RBAC 的四个层级
NIST 定义的 RBAC 标准包含四个递增的复杂性层级:
2.1 Core RBAC(核心 RBAC)
这是最基本的 RBAC,包含用户、角色、权限、会话五个基本元素:
2.2 Hierarchical RBAC(层级 RBAC)
引入角色继承:子角色自动继承父角色的所有权限:
层级 RBAC 的优势在于:新晋升的员工只需要改变角色,权限自动跟随层级调整。
2.3 Constrained RBAC(约束 RBAC)
引入职责分离(SOD)和基数约束:
互斥角色:同一个人不能同时持有两个互斥角色,防止利益冲突。
基数约束:限制角色分配的数量。
先决条件角色:获得某个角色之前必须先拥有另一个角色。
2.4 Symmetric RBAC(对称 RBAC)
引入角色-权限分配与角色-角色分配的对称性,并支持权限的外部管理。本层级主要面向大型企业的复杂权限管理场景。
三、RBAC 的 Java 实现
3.1 基于 Spring Security 的 RBAC 实现
3.2 权限服务实现
3.3 数据库模型
四、RBAC 的优点与局限性
4.1 优点
4.2 局限性
RBAC 的「角色」是静态的。当需要根据用户当前状态(如「是否在会议室」)决定权限时,RBAC 就力不从心了。这是 ABAC 的用武之地。
五、最小权限原则在 RBAC 中的实践
最小权限原则(Principle of Least Privilege)要求每个用户只拥有完成工作所需的最小权限集。
实践方法:
- 默认拒绝:新建用户默认没有任何角色
- 基于岗位设计角色:每个岗位对应一个角色,不跨岗位复用
- 定期审查:每季度审查角色权限配置,移除不必要的权限
- 临时权限例外:需要额外权限时通过审批流程临时授予,到期自动回收
思考题
问题 1:在 RBAC 中实现「临时权限」机制,需要考虑哪些设计要素?如何在不过度复杂化系统的前提下支持紧急权限授予?
参考答案
临时权限需要考虑的核心要素:
- 时效性:明确权限的开始时间和结束时间
- 审批流程:紧急场景下需要快速审批(可以设置自动审批阈值)
- 通知机制:权限变更需要通知用户和管理员
- 自动回收:到期后系统自动撤销权限
- 审计记录:记录所有临时权限的授予和回收
- 次数限制:同一临时权限不能无限续期
简化方案:
- 使用「审批工作流 + 自动过期」机制
- 临时角色命名规范:
TEMP_{业务}_{过期时间戳} - 到期前 24 小时提醒用户续期
问题 2:角色层级设计不当会导致权限失控。请分析以下场景中潜在的安全风险:CTO 拥有所有权限,而实习生可以继承 CTO 的所有权限。
参考答案
风险分析:
场景一:CTO 拥有所有权限
- 问题:单一角色权限过于集中,一旦泄露影响巨大
- 建议:即使是 CTO,也应该将权限拆分到多个角色,通过角色组合实现完整权限
场景二:实习生继承 CTO 权限
- 问题:这违反了 RBAC 层级设计的初衷,高层级角色的权限不应被低层级角色完全继承
- 原因:层级继承应该基于「向上继承」,而非「向下继承」
- 正确设计:
INTERN继承JUNIOR,而不是CTO继承INTERN
安全原则:角色层级应该是「自下而上」的权限叠加,而非「自上而下」的权限下沉。