知识卡片
RBAC用角色解耦多对多权限关系及垂直水平权限的管理难度差异
内容
把权限直接挂在用户身上,在成百上千资源、成千上万用户的系统里会导致 配置量爆炸、出错率极高。RBAC(基于角色的访问控制)的解法是插入”角色” 这个中间层,把权限判断变成”角色是否拥有对资源执行某操作的许可”这个逻辑 求解——用户与角色多对多、角色与许可多对多,两次解耦让配置量从”用户× 资源”降到可管理的规模。这个设计还天然满足”最小特权原则”:角色只被赋予 完成该角色职责所需的最小权限集合,用户职责变化时只需切换角色,而不必 逐条重新分配权限。RBAC还支持角色继承(如开发经理继承开发人员的代码 提交权限,开发人员继承全体员工的食堂就餐权限)和角色互斥(如同一人不能 既是会计又是出纳,防范职责冲突带来的资金风险)来进一步强化建模能力。 但RBAC能优雅解决的只是垂直权限(功能权限,如”谁能审核通过论文”这类 可以从具体业务中抽象出来、用通用框架如Spring Security承载的权限); 水平权限(数据权限,如”A能不能删B的数据”)天然难以抽象和通用化,往往 要精确到某一行某一列,只能由信息系统业务代码自己完成,不存在放之四海 皆准的通用数据权限框架。
参考来源
- 位置:《凤凰架构:构建可靠的大型分布式系统》第5章"架构安全性"
5.2.1节"RBAC"(源文件:_epub-src对应OEBPS/Text/chapter61.xhtml)
- 结论依据:原文说明RBAC通过角色解耦用户与权限的多对多关系、满足最小
特权原则,支持角色继承与互斥约束,并区分垂直权限(可通用框架承载)与
水平权限("仅在角色层面控制并不能满足全部业务需要……只能由信息系统
自主完成"),直接支撑本卡片结论。
- 原始内容:RBAC将权限从用户身上剥离,改为绑定到"角色"上,将权限控制
变为对"角色拥有操作哪些资源的许可"这个逻辑表达式的值是否为真的求解
过程……水平权限……数据权限基本只能由信息系统自主完成,并不存在能放之
四海皆准的通用数据权限框架。