这是”一文”系列的第二篇。本篇主要介绍基于RBAC模型权限设计的方法。

01 什么是RBAC模型权限？

我们先看下边一个小场景：

小明同学想晚上10点后进入图书馆学习，就在晚上10点准备进入图书馆时被保安王大叔给拦住了，理由是只有图书馆管理员10点以后才能进入图书馆。

1. 怎么样才能让小明同学在10点以后进入图书馆学习？

“让小明同学偷偷溜进去？” “给保安王大叔给好处？”

“还是让小明同学去“某组织”申请成为“图书馆管理员”？”

看来还是申请成为“图书馆管理员”比较靠谱，虽然需要写申请书，找老师签字等走一系列的流程，虽然麻烦，但是这是晚上10点以后进入图书馆的正规途径。

2. 进图书馆小场景和RBAC模型有什么联系？

首先我们先看下百度百科的介绍

“RBAC（Role-Based Access Control）：基于角色的访问控制（RBAC）是实施面向企业安全策略的一种有效的访问控制方式。”

“其基本思想是，对系统操作的各种权限不是直接授予具体的用户，而是在用户集合与权限集合之间建立一个角色集合。每一种角色对应一组相应的权限。一旦用户被分配了适当的角色后，该用户就拥有此角色的所有操作权限。”

看了百度百科介绍是不是感觉一脸懵？我们结合上边的小场景去看：

• 角色1：图书馆管理员
• 角色2：保安      
• 用户：小明同学
• 权限：晚上10点以后进入图书馆的权限
• 系统：图书馆

“图书馆”将晚上10点以后进入图书馆的权限授权给“图书馆管理员”，只有“图书馆管理员”角色的权限才可以晚上10点进入图书馆。小明同学想晚上10点后进入图书馆，就需要成为“图书馆管理员”这个角色，直接将权限赋给小明是不可行的。如下图：

通过小场景，我们简单的理解了RBAC的基本概念，用“角色”将“用户”与“权限”进行分割，实现“用户”与“权限”的解耦。只要是小明同学属于图书馆管理员角色，他就可以进入晚上10点后图书馆，其他同学如果也申请了图书馆管理角色，同理也是可以在晚上10点以后进入图书馆的。

有人问会有疑问，为什么要设置“角色”，直接把权限赋予给“用户”就行啦，不需要这么麻烦呀。咱们接着往下看。

3. RBAC模型的特点

提升管理效率，降低授权复杂性

如果图书馆出了新规定，晚上10点禁止任何人进入图书馆。图书馆只需要将“图书馆管理员”角色下晚10点后进入图书馆权限关闭即可(如下图)。反之，试想如果没有“图书馆管理员”角色，直接将晚上10点以后进入图书馆权限赋给小明和其他同学。要取消权限就要对每个有权限的同学进行取消权限，大大增加了工作量。

适用企业管理变化

图书馆又发出新规定“图书馆出了新规定，晚上10点禁止任何人进入图书馆不合理，应该让“保安”可以在晚上10点进入图书馆进行巡逻。”通过RBAC模型方式，直接将“保安”角色赋予“晚上10点以后进入图书馆”的权限就可以了。

02 RBAC模型权限设计方法

模型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系统的权限设计，我是从下边三个点出发进行分析：

什么人用？

用户从哪来？

作为企业内部使用的营销系统，用户主体部分都是企业员工。其中少部分为供应商团队用户。企业内部员工通过与人力系统进行组织对接，打通人力系统与A系统用户数据。员工可以直接使用统一企业账号（portal)进行登录。供应商团队用户是没有portal的，这部分账号需要进行创建分配。

什么身份（角色）

在找到“人”之后就要进行开始“身份”调研了。“身份”调研阶段是跟进在整个业务调研阶段中，例如在调研中会梳理到实际业务组织架构。虽然已经确认有了人力系统组织架构，但是根据实际经验往往人力架构与实际业务中架构会有一些差异。

通过前期业务调研后我们整理出组织架构，在组织架构梳理中明确了组织中父子级对应关系，在前期调研中也许明确出岗位角色中是否有“限制条件”，例如岗位角色是否有唯一性限制，如下图所示中每个分公司里只有一个运营总监，销售总监等等。（RBAC2中基数限制）

用什么功能（权限）

功能权限分为功能权限与数据权限。

功能权限指的角色在系统内操作范围，例如角色A可以点击报表导出按钮或者管理员角色在系统中可以看到后台管理菜单并可以对其进行操作。

数据权限指的角色在系统中可操作的数据范围，例如报表中只显示该角色的数据范围内数据，比如上海公司的运营总监查看数据权限只是上海分公司内的，同时筛选数据条件范围也只限于其权限内。

通过前期业务调研针对不同的业务场景流程，在设计相关功能时需整理出功能权限表，权限表体现需要标注具体功能可以对哪些角色可见，功能内某个按钮具体操作权限。有了这份表格，我们可以在系统上线初始化时，将角色的权限配置好，方便用户上线后即用。

2. 设计阶段

在梳理了用户，角色，权限（功能&数据）关系后，就要着手进行功能设计了。

根据用户流向策略，绘制出了如下后台业务流程图（初版）。

用户来源主要是来自人力组织对接与自行创建分配用户。人力岗位与角色在对接中形成组织对接关系，在具体功能权限赋予时，需要系统运营人员根据实际业务需求进行配置。

基于初版流程图，先整体设计出后台功能架构。

用户中心：账号管理   数据管理

角色中心：角色管理   角色功能管理  角色组织岗位管理  角色数据管理

组织管理：组织对接

用户心中：账号管理主要功能为账号创建，查看，删除，导出，修改，账号状态修改(停用/冻结).针对供应商账号可以该功能模块进行创建，其他操作可以对所有账号进行。数据管理主要展示用户的数据权限查看，导出，删除。

角色中心：角色管理主要功能为角色创建，查看，删除，导出，修改。角色功能管理是角色与功能权限进行配置。角色组织岗位管理为角色与组织岗位关系的查看、导出。角色数据管理可为角色进行数据模板配置，用户在提报角色数据权限时，只能根据数据模板设置进行相应权限提报。

组织管理：组织对接功能与人力系统进行组织对接。

3. 场景演练

张三是新入职新员工，其岗位是上海分公司一级销售代表。在入职后张三需要使用A系统进行日常办公。因为A系统与人力系统有组织对接，所以张三直接使用portal账号密码登录即可，登录后需要进行角色与数据权限申请。

申请时角色默认为组织对接后角色，数据权限申请范围是该角色可选择数据权限。例如张三岗位为上海分公司一级销售代表，其角色为一级销售代表，那么张三进入申请功能时角色默认为一级销售代表。但申请数据数据权限时只能选择上海,品牌选择现在为全部或多选（数据权限是通过角色数据管理进行配置）。张三选择完数据权限，提交申请后，审批由张三的上一级领导进行操作，审批通过后张三可以以一级销售代表的角色身份登录系统开展业务。

下图为新员工角色数据权限流程图。

后记

由于该项目暂时还未正式上线，所以复盘的时隐藏了大部分信息，例如原型图。可能会导致大家阅读起来比较困难，后续我会根据实际情况不断更新项目实例。

给大家一点建议：整体权限设计应该在项目开始时就要贯穿其中，优秀的后台权限设计方案，必定是依靠着前台清晰的功能设计而生成的。所以尽量多参与项目调研阶段与需求分析阶段，最好整体都参与其中。

在整个项目权限设计中思想都是基于RBAC模型去设计的，RBAC模型的特点之一也是可以灵活多变的支持企业组织架构的伸缩，同时也提高了运维管理的效率。遗憾点是在设计初期并未考虑到分公司自行运营A系统的长远需求（近几年并不会实际落地），没有在设计时提出“租户”或者“用户组”概念。

本文由 @Sean 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议