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

编辑导读：权限设计对于大多数产品经理来说都不陌生，本篇文章讨论一个系统的权限设计有哪些机制，并重点介绍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的求解过程。