对于后台系统来说，权限管理是必不可少的一个环节。本文笔者会将理论知识与自己的实践经验相结合，分享权限管理系统设计的相关知识，希望能给读者带来启发。

一、权限管理系统概述

1、权限管理系统的作用

对整个后台系统进行权限控制，目的是为了避免系统的使用者因为权限控制的缺失而出现操作不当、数据泄露、流程卡住等问题。

2、权限管理系统的三要素

这里说的三要素是系统中的三大功能模块，分别是账号、角色和权限。权限管理系统的存在，概括的讲是为了将三要素间的关系安排清楚。

（1）账号

每个后台系统的使用者，都有自己的账号。账号是使用者进入系统这扇大门的钥匙，它的权限对应着使用者在系统中的操作范围。后台产品的账号，通常是由公司内部人员进行创建。

（2）角色

角色是搭建在账号与权限之间的一道桥梁。系统中会有很多权限，如果每建一个账号都要配置一遍权限，将是很繁琐的一项工作。因此，角色作为使用者人群的集合，把需要的权限收归于其中，然后再根据账号的需要来配置角色。通常会根据不同的部门、职位、工作内容等，对角色进行设置。

角色这一概念的引入，极大地增加了权限管理系统配置的灵活性和便捷性。创建账号时，可以将不同的角色配置在同一个账号上，也可以给不同的账号配置相同的角色。创建角色时，可以根据角色的差异赋予其不同的权限。

（3）权限

权限可分为三类：数据权限、操作权限和页面权限。

数据权限：控制账号可看到的数据范围。举例说明，风控系统中，负责不同区域的信审人员，只能看到自己负责区域的标的，不能看到和修改其他区域的。

页面权限：控制账号可以看到的页面，通常系统都会有这一层权限控制。这种控制相对操作权限来说比较粗放，难以对权限进行精细管理。

操作权限：控制账号在页面上可以操作的按钮，通常指的是页面中的新增、删除、编辑、查询功能。没有操作权限，就只能看到页面中的数据，但是不能对数据进行操作。操作权限是比页面权限更精细一层的权限控制。

3、RBAC模型

（1）定义

RBAC（Role-Based Access Control）意思是基于角色的权限控制，有别于传统模型中的直接把权限赋予账号，增加了“角色”的概念，把权限赋予角色，再将角色赋予账号。提高了账号管理效率，降低了出错的概率。

例如：当有多个账号需要配置相同的权限时，有了角色后便不需要给每个账号挨个配置权限，只需要在角色上配置权限，再把角色配置到账号上。如果想批量调整账号的权限，只需要调整账号对应的角色的权限，无需对每个账号进行调整。

（2）类型

RBAC模型根据设计需要，可分为RBAC0、RBAC1、RBAC2、RBAC3四种类型。其中RBAC0是基础，另外三种是RBAC0的升级。产品经理在进行权限系统设计时，可以结合实际情况来选择使用的RBAC模型的类型。

二、权限管理系统设计实例

下文以笔者曾负责过的系统为例，来讲述如何进行权限管理系统设计。此系统类型为RBAC0，即把权限赋予角色，角色赋予账号，账号、角色、权限之间是多对多的关系。为防止暴露公司系统真实情况，已进行删减。

1、账号管理

（1）页面展示

账号管理模块是对系统用户的信息进行管理，在列表中要展示重要性较高的字段，便于识别账号。例如：编号、真实姓名、用户名、部门、角色、创建时间、账号状态等（页面如下图）。

需要能通过“真实姓名”和“用户名”来查询账号，便于管理员定位到想要操作的账号。除此之外，还需要有“新建账号”功能。

（2）新建账号

新建账号功能可跳转页面或弹窗展示（如下图），页面信息除账号基本信息外，还需要对账号赋予角色。

（3）编辑账号

除了需要创建新账号外，还需要对已有的账号进行修改（操作栏中“编辑”功能），账号用户的真实姓名和用户名不可修改，其他信息可修改。

2、角色管理

（1）页面展示

角色，即为拥有共同特征的同一类人群身份的归纳，所以在角色管理页面中，需要设置能够识别角色特征的字段。例如：角色名称、角色描述、创建时间、更新时间、状态等（如下图页面）。

角色数量通常不会太多，数量较少时可取消查询功能，但“新建角色”功能是必不可少的。

（2）新建角色

新建角色即是对角色进行描述并赋予权限的过程，若权限数量不多，可采用下拉列表的方式选择。若权限数量多且分类繁杂，则可采用分组列表的方式展示，让用户通过复选框勾选。为了操作简便，建议增加全选/反选功能。

（3）编辑角色

操作栏中的“编辑”功能，对已有角色进行修改，角色的名称、描述、状态、权限均可修改，每次修改后在列表中记录更新时间。

（4）对应账号

指的是配置过该角色的账号，点击后在新页面中打开，展示账号信息，包括账号的真实姓名、用户名、部门、创建时间、账号状态，并可在列表中对账号进行编辑。

3、权限管理

（1）页面设计

若系统中权限数量较多且权限类型复杂（页面权限、操作权限、数据权限），为了保证管理员使用便捷及减低出错概率，可以将权限管理页面以列表的形式展示，展示页面包含权限编号、名称、类型、描述、创建时间等。

若系统权限较为简单，则可用树状图来展示权限，不需要对权限做过多描述。

（2）新增权限

新增权限的输入页面，不同的系统要求不同，有的需要开发录入代码，有的需要产品经理录入新权限的URL，还有的系统中不展示新增权限入口。产品经理在设计时需要和开发沟通，选择适合目前技术能力的方案。

三、RBAC0模型的三种扩展

1、RBAC1模型（角色分级模型）

该模型在RBAC0模型的基础上，引入了角色间的继承关系。将角色划分层级，每个层级拥有的权限不同，每个层级的下级角色只能按照系统的设置，继承上级角色的部分权限。以此来对角色的关系进行精细化管理。

例如：在风控体系中，风控经理、风控主管、风控专员可分为三个不同层级。风控主管拥有风控经理的部分权限，而风控专员拥有风控主管的部分权限。

2、RBAC2模型（角色限制模型）

该模型也是以RBAC0模型为基础，引入了角色间的限制条件，共有4种限制条件。

（1）角色互斥

在系统的互斥角色集合中存在相互制约的角色，这些角色不能分配给同一个账号。例如：风控系统中的尽调角色和审核角色即为互斥角色，不能配置在同一个账号上。

（2）基数限制

某个角色被分配给账号的数量有限制，不允许超过数量限制的账号拥有该角色。例如：专门为公司某个职位的高管建立的角色（CEO）。

（3）先决条件限制

即账号想要获得高层级的角色，则需要先拥有低层级的角色。例如：先拥有风控主管的权限，才能拥有风控经理的权限。

（4）运行限制

允许一个账号拥有两个角色的权限，但是运行时只能激活其中一个。

3、RBAC3（统一模型）

同时包含RBAC1和RBAC2的特性，既有角色层级划分，也有各种限制，在此不再赘述。

四、补充说明

1、用户组设置

一般来说权限管理系统不需要设置用户组，只要当用户基数较大，角色类型过多时，为了便于管理员进行操作，才会引入“用户组”的概念。

用户组可以理解为，将某个部门的所有人看成一个用户组，再给用户组赋予角色，这个部门的所有人就都有了用户组中角色的权限。对于给群体账号赋予权限，用户组可以提供很大的便利。

同时，用户组中的账号，除拥有用户组的权限外，还可以拥有指定的角色。

2、角色的数据权限控制

在实际业务中，相同的角色在同一页面中，所拥有的数据权限可能不同。例如：负责不同区域的审核人员能看到各自负责区域的数据。所以在设置角色的权限时，需要结合实际业务情况对角色的数据权限进行设置。也可能会出现同样的角色，在同一个页面上，能够查看到的字段权限不一样。

3、未设置权限的展示

对于角色中未设置的权限，在页面上有两种展示方式。第一种比较常见，根据权限的设置来展示，没有权限的不予展示。第二种是显示所有的功能和权限，点击时告知用户是否有此权限。