这是”一文”系列的第二篇。本篇主要介绍基于RBAC模型权限设计的方法。
01什么是RBAC模型权限？
我们先看下边一个小场景：
小明同学想晚上10点后进入图书馆学习，就在晚上10点准备进入图书馆时被保安王大叔给拦住了，理由是只有图书馆管理员10点以后才能进入图书馆。1.怎么样才能让小明同学在10点以后进入图书馆学习？
“让小明同学偷偷溜进去？”“给保安王大叔给好处？”
“还是让小明同学去“某组织”申请成为“图书馆管理员”？”
看来还是申请成为“图书馆管理员”比较靠谱，虽然需要写申请书，找老师签字等走一系列的流程，虽然麻烦，但是这是晚上10点以后进入图书馆的正规途径。
2.进图书馆小场景和RBAC模型有什么联系？
首先我们先看下百度百科的介绍
“RBAC（Role-BasedAccessControl）：基于角色的访问控制（RBAC）是实施面向企业安全策略的一种有效的访问控制方式。”“其基本思想是，对系统操作的各种权限不是直接授予具体的用户，而是在用户集合与权限集合之间建立一个角色集合。每一种角色对应一组相应的权限。一旦用户被分配了适当的角色后，该用户就拥有此角色的所有操作权限。”
看了百度百科介绍是不是感觉一脸懵？我们结合上边的小场景去看：
通过小场景，我们简单的理解了RBAC的基本概念，用“角色”将“用户”与“权限”进行分割，实现“用户”与“权限”的解耦。只要是小明同学属于图书馆管理员角色，他就可以进入晚上10点后图书馆，其他同学如果也申请了图书馆管理角色，同理也是可以在晚上10点以后进入图书馆的。
有人问会有疑问，为什么要设置“角色”，直接把权限赋予给“用户”就行啦，不需要这么麻烦呀。咱们接着往下看。
3.RBAC模型的特点
如果图书馆出了新规定，晚上10点禁止任何人进入图书馆。图书馆只需要将“图书馆管理员”角色下晚10点后进入图书馆权限关闭即可(如下图)。反之，试想如果没有“图书馆管理员”角色，直接将晚上10点以后进入图书馆权限赋给小明和其他同学。要取消权限就要对每个有权限的同学进行取消权限，大大增加了工作量。
适用企业管理变化
图书馆又发出新规定“图书馆出了新规定，晚上10点禁止任何人进入图书馆不合理，应该让“保安”可以在晚上10点进入图书馆进行巡逻。”通过RBAC模型方式，直接将“保安”角色赋予“晚上10点以后进入图书馆”的权限就可以了。
02RBAC模型权限设计方法模型1：RBAC0
RBAC0是RBAC的基础，RBAC1，RBAC2，RBAC3模型都是从RBAC0模型拓展而成。
RBAC0模型中用户，角色，权限都是多对多关系。例如：实际中企业可能由于各种原因会出现一人承担多个角色。比如担任人力岗位同时，也会承担行政的工作。
模型2：RBAC1
RBAC1在RBAC0的基础上，加入角色继承的概念。将角色下分成各个等级的小角色(如图),子级权限继承父级。如下图，根据子级等级不同来分配更细粒度的权限。
例如：公司的财务总监可以看到整个公司所有部门的财务报表数据，而销售部财务经理只能看到销售部财务报表数据，在销售部财务经理下可能还会设立其他岗位，比如财务专员，财务专员可能只有查看销售部具体某个报表的权限。
模型3：RBAC2
RBAC2是对RBAC0在角色，权限上增加了限制条件，例如：公司规定有人被赋予了财务角色，就不能再赋予他审计角色。这样可以在一定程度上防止在年总审计时候，审计人与被审计人是同一个人。这就是角色互斥。
用户拥有的角色数，角色可以被赋予给多少用户数，角色拥有的权限数都是可以被限制的，这就是基数限制。
还有先决条件限制，比如想拥有高级产品经理，就必须先拥有产品经理角色。
模型4：RBAC3
RBAC3=RBAC1+RBAC2
RBAC3集成了RBAC1的角色分级继承，同时也包括RBAC2中的各种限制。如下图
03实例复盘1.前期分析
A系统(企业内部营销域平台)是我最近在参与项目之一，主要职责一部分是设计后台功能，这其中就包含了权限设计。
对于A系统的权限设计，我是从下边三个点出发进行分析：
什么人用？
用户从哪来？
什么身份（角色）
在找到“人”之后就要进行开始“身份”调研了。“身份”调研阶段是跟进在整个业务调研阶段中，例如在调研中会梳理到实际业务组织架构。虽然已经确认有了人力系统组织架构，但是根据实际经验往往人力架构与实际业务中架构会有一些差异。
通过前期业务调研后我们整理出组织架构，在组织架构梳理中明确了组织中父子级对应关系，在前期调研中也许明确出岗位角色中是否有“限制条件”，例如岗位角色是否有唯一性限制，如下图所示中每个分公司里只有一个运营总监，销售总监等等。（RBAC2中基数限制）
用什么功能（权限）
功能权限分为功能权限与数据权限。
功能权限指的角色在系统内操作范围，例如角色A可以点击报表导出按钮或者管理员角色在系统中可以看到后台管理菜单并可以对其进行操作。
数据权限指的角色在系统中可操作的数据范围，例如报表中只显示该角色的数据范围内数据，比如上海公司的运营总监查看数据权限只是上海分公司内的，同时筛选数据条件范围也只限于其权限内。
2.设计阶段
在梳理了用户，角色，权限（功能&数据）关系后，就要着手进行功能设计了。
根据用户流向策略，绘制出了如下后台业务流程图（初版）。
基于初版流程图，先整体设计出后台功能架构。
用户中心：账号管理数据管理角色中心：角色管理角色功能管理角色组织岗位管理角色数据管理组织管理：组织对接
用户心中：账号管理主要功能为账号创建，查看，删除，导出，修改，账号状态修改(停用/冻结).针对供应商账号可以该功能模块进行创建，其他操作可以对所有账号进行。数据管理主要展示用户的数据权限查看，导出，删除。
角色中心：角色管理主要功能为角色创建，查看，删除，导出，修改。角色功能管理是角色与功能权限进行配置。角色组织岗位管理为角色与组织岗位关系的查看、导出。角色数据管理可为角色进行数据模板配置，用户在提报角色数据权限时，只能根据数据模板设置进行相应权限提报。
组织管理：组织对接功能与人力系统进行组织对接。
3.场景演练
下图为新员工角色数据权限流程图。
后记
由于该项目暂时还未正式上线，所以复盘的时隐藏了大部分信息，例如原型图。可能会导致大家阅读起来比较困难，后续我会根据实际情况不断更新项目实例。
给大家一点建议：整体权限设计应该在项目开始时就要贯穿其中，优秀的后台权限设计方案，必定是依靠着前台清晰的功能设计而生成的。所以尽量多参与项目调研阶段与需求分析阶段，最好整体都参与其中。
在整个项目权限设计中思想都是基于RBAC模型去设计的，RBAC模型的特点之一也是可以灵活多变的支持企业组织架构的伸缩，同时也提高了运维管理的效率。遗憾点是在设计初期并未考虑到分公司自行运营A系统的长远需求（近几年并不会实际落地），没有在设计时提出“租户”或者“用户组”概念。
本文由@Sean原创发布于人人都是产品经理。未经许可，禁止转载