权限|CRM 05：基于RBAC理论的权限设计

编辑导读：权限设计对于大多数产品经理来说都不陌生，本篇文章讨论一个系统的权限设计有哪些机制，并重点介绍RBAC的机制，一起来看看吧。

文章插图
在前文「CRM02-销售域系统设计与实施中，讲解到了权限的划分」，本篇文章讨论一个系统的权限设计有哪些机制，并重点介绍RBAC的机制。

文章插图
一、基本逻辑首先我来拆解下访问的逻辑，一次完整的访问，有如下组成：

用户：发起访问的主体（这个用户还可以是用户组的概念，即一组用户，对应了组织机构）
权限：被访问的客体
对象：记录用户是否可以访问某个对象。其实还能拆出给权限控制表的，为了好理解就简化了

文章插图
【 权限|CRM 05：基于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的机制，优点对于业务环境来讲就是很清晰，可以快速通过角色来识别角色包含的页面，而且多个角色可以叠加取并集，让配置的人操作量减少。