CRM 05：基于RBAC理论的权限设计
在前文「CRM02-销售域系统设计与实施中，讲解到了权限的划分」，本篇文章讨论一个系统的权限设计有哪些机制，并重点介绍RBAC的机制。
一、基本逻辑
首先我来拆解下访问的逻辑，一次完整的访问，有如下组成：
- 用户：发起访问的主体（这个用户还可以是用户组的概念，即一组用户，对应了组织机构）
- 权限：被访问的客体
- 对象：记录用户是否可以访问某个对象。其实还能拆出给权限控制表的，为了好理解就简化了
基于这个逻辑，访问过程可以有不同的机制来控制。
二、访问机制
当前市面上流传比较广的权限控制机制，如下3种：
- ABAC：基于属性的访问控制(Attribute Based Access Control)
- RBAC：基于角色的访问控制(Role Based Access Control)
- PBAC：基于策略的访问控制(Policy Based Access Control)
一瞬间甩出3个访问控制机制，会让人找不到抓手，我先从我的角度来介绍下，如果有说错的欢迎老司机来斧正。
首先，这3个机制没有好与坏，只有是否合适，每个机制下的拥护者都会说自己的机制代表了未来。
1. ABAC
是基于用户上的某个属性来控制访问的，比如基于年龄属性限制，某用户18岁以下，就不能访问某些页面，这种就是ABAC。
优点：集中化管理，一刀切
缺点：如果权限需求灵活多变，配置会死人，也无法看到某个用户能否访问具体某个对象
2. RBAC
基于角色的权限控制，增加了一层角色的抽象，这也是在设计CRM结构中介绍的方法《引用第二篇文章》。通过不同的页面授权，把不同对象的权限集合成角色，达到灵活的配置。
优点：用户和对象的关系可直观追溯，调整与配置很灵活。
缺点：如果公司业务规模较大，角色分工出现模糊，比如一个人有记账的角色又有了监管的角色，这种分工是极不合理的。按照这个层级模型，理论上对象越多，能排列出的权限组合越多，角色就越多。这种现象叫做
角色爆炸。基于角色爆炸，又引出了后面的PBAC。
3. PBAC
如果一个大的系统会有很多关联子系统，子系统中又有不同的权限配置，等级也不同，菜单也不同。
这个场景就更适合PBAC，基于策略的角色控制，这个机制下的配置逻辑，就是“按照原则去设计一条权限限制”，这个原则就组成了策略，如只要是某个部门的人都不需要打卡。举例：当“部门属性”=“运维组”，访问页面包含“系统配置”这类。
优点：PBAC 支持环境和上下文控制，因此可以设置策略以在特定时间和特定位置授予对资源的访问权限，甚至评估身份和资源之间的关系。策略可以快速调整，并在给定的时间段内设置（例如响应违规或其他紧急情况）。可以轻松添加、删除或修改用户组，单击即可撤销过时的权限。
缺点：配置的操作难度，不适用于一般的商业公司，对配置人员操作要求较高。
三、RBAC核心设计
介绍完不同的机制，我重点说下RBAC。
RBAC认为权限的过程可以抽象概括为：判断【Who是否可以对What进行How的访问操作（Operator）】这个逻辑表达式的值是否为True的求解过程。
即将权限问题转换为Who、What、How的问题。who、what、how构成了访问权限三元组。
RBAC支持公认的安全原则：最小特权原则、责任分离原则和数据抽象原则。
- 最小特权原则：某用户对应的角色的权限只要不超过该用户完成其任务的需要就可以了。
- 责任分离原则：是指完成敏感任务过程中需要分配两个责任上互相约束的两个角色来实现，例如在清查账目时，只需要设置财务管理员和会计两个角色参加就可以了。
- 数据抽象：如在账目管理活动中，可以使用信用、借方等抽象许可权，而不是使用操作系统提供的读、写、执行等具体的许可权。
使用RBAC的机制，优点对于业务环境来讲就是很清晰，可以快速通过角色来识别角色包含的页面，而且多个角色可以叠加取并集，让配置的人操作量减少。
至于角色爆炸的问题，在CRM实施之初就提前规划好，并约定好原则，这个问题就可以大概率避免。当然不排除后人破掉了这个限制，导致套娃
RBAC的核心设计如下绿图：
【图片来自于Apache Directory】
用户和角色还有会话相互关联（会话的作用可理解为每次访问都要检查用户和角色的关系，如果角色冲突，就中断会话）
角色单独和权限管理，是权限的集合。权限内部又包含了对象和操作。（如果不理解对象和操作，可查看之前的UML文章）
RBAC体系的逻辑可以大体这么理解：
RBAC0：RBAC96家族的核心部分，后面的123都是基于此发展
RBAC1：在0的基础上，增加角色分层和角色继承的关系。如区域经理下方有门店店长这种关系
RBAC2：在0基础上增加了角色约束，包含：
- 角色互斥约束，系统的运行中互斥角色只能生效一个，如Boss直聘里的牛人和BOSS，切换以后需要重新登录
- 角色基数约束，限制某个用户最多的角色数量/权限数量，防止滥用
- 先决条件角色约束，指某用户只有在已经拥有某个角色的前提下，才能分配到特定的其他角色，如想拥有线索放弃的权限，就必须拥有销售角色的权限
RBAC3：
融合了RBAC1和RBAC2的所有特点，把角色关系和角色约束都整合到了一块，在我们的业务环境中没必要这么复杂，所以就用了RBAC0。
基于RBAC0的这种机制，落地到业务中，整体的权限配置效果如下：
- 一个用户，可以批量关联多个角色。一个角色可以批量授权给多个用户
- 一个角色可以配置不同的页面权限与操作权限（操作在我们设计的时候也抽象成了页面，更简单）
- 数据权限与组织树权限的颗粒度精细到具体的用户，只可单独授权。同时数据的行权限和列权限不必单独授权，保留了能力
基于RBAC的权限设计就讲到这里，希望在大家设计系统的时候有所帮助，如果在设计过程中卡在了页面设计上，把上述的每个圆圈的内容分别设计个列表和详情页，就有思路了，如图。
角色管理：
角色详情：
用户管理：
用户详情：
本文核心理论部分来自于互联网，页面截图来自于过往脱敏经历。
参考资料
RBAC https://csrc.nist.gov/projects/role-based-access-control
PBAC VS RBAC https://blog.plainid.com/why-role-based-access-control-is-not-enough
PBAC VS ABAC https://blog.plainid.com/the-advantage-of-pbac-over-the-traditional-abac
RBAC核心设计 http://directory.apache.org/fortress/user-guide/1.3-what-rbac-is.html
感谢大家的阅读！CRM系统设计的相关内容到这里基本讲完了，后面我会继续出CRM外围系统的相关内容，欢迎大家追更~~
我这几篇文章经常提到UML，也是给大家实操了一遍，建议大家练习和使用。祝大家在产品的道路上找到自己喜欢的事情。
作者：罗文正雄；公众号：罗文正雄
本文作者 @罗文正雄
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
