前言

权限设计及管理是B端中常见的话题，它规定了用户各自的角色和可使用的权限范围，也对数据的安全提供了保障。本篇文章中我主要结合自身以前做权限的项目经验以及现阶段在不断学习、研究和成长过程中，主要从四部分分享关于权限设计的方案和研究心得。

1. 权限的概念

2. 权限设计的核心思想

3. 常用权限设计的模型

4. 权限设计的步骤

所有内容均根据自身经验、研究思考及实践借鉴而来，如有错误欢迎指正。文中有些案例或者截图是我在工作中的真实项目经历。

一、权限的概念

（1）什么是权限？

      a. 权限是指系统执行用户访问、操作或修改的权力（比如查看、编辑、删除等），权限包括「功能权限」和「数据权限」。

      b. 「功能权限」包括页面权限、菜单权限、按钮权限等，「数据权限」包括基础数据、业务数据、资源数据等。

权限分类

（2）为什么要权限管理？

我个人认为，权限管理的目的主要在以下三方面：

      a. 岗位职责的需要

      b. 数据安全的需要

      c. 系统安全的需要

二、权限设计的核心思想

根据权限的定义，可以画出用户与权限的关系，用户与权限之间可以是一对一，也可以是一对多、甚至可以多对多。

关系图1

从关系图1可以看出，用户与权限之间形成了比较复杂的——映射关系，也就是说，权限设计的最简单的策略就是“用户+权限”，直接将权限绑定到用户身上，但是这种策略只适用于简单业务的系统中，在复杂的业务系统显然不适用，在多用户和多权限系统中就非常难管理了。

那么，在复杂的业务系统中，如何去管理用户与权限错综复杂的映射关系呢？从关系图1中，可以看出，要解决这一问题，有三种方式：

  a. 要么减少用户数

  b. 要么减少权限数

  c. 要么减少映射关系

显然“减少用户数”和“减少权限数”的方式不现实，那么只能通过“减少映射关系”的方式。可以联想下现实中的案例，比如，字典中的索引、书籍中的目录或是图书馆中的书架标签，超市的商品分类，都是找到共公属性再进行分类管理。

利用这一思想，我们来看如何减少用户和权限的映射关系。

  a. 判断用户与用户之间是否有公共属性

  b. 找到对权限有影响的公共属性，比如角色、部门、职位等

  c. 不断抽象出中间媒介

关系图2

如上关系图2，如果想要用户1～用户5配置上对应的权限1～权限5的权限，则用户与权限之间的关系只建立了5层，但是再看关系图1，用户与权限之间足足建立了12种关系。所以，从这里我们可以知道，设计权限的核心思想就是：抽象出对象的公共属性，再进行分类管理。

三、常见权限设计的模型

常见的权限设计模型有：ACL、DAC、MAC、RBAC、ABAC

a. 访问控制表ACL（Access Control List）

          定义：目标资源拥有访问权限列表，指明允许哪些用户访问（为资源指定用户），指定哪些用户可以访问对象的资源，以及在对象上的操作也被允许，是基于客体进行控制的模型。

如上图，权限1指定只允许用户1访问，权限2指定允许用户1、用户2访问，权限3和权限4分别指明允许用户3、用户4访问。同样的，如果用户1想要访问没有被授权的权限3、权限4的时候，便访问不了。

常见的应用场景就是：

邮件的抄送功能，OA审批抄送功能，以及白名单设置等；添加抄送人的过程其实就是针对当前的这个权限（邮件或审批单）指明允许哪些用户访问的过程。

例如：当用户A要对一篇文章进行编辑时，ACL会先检查一下文章编辑功能的控制列表中有没有用户A，有就可以编辑，无则不能编辑。再例如：不同等级的会员在产品中可使用的功能范围不同。

缺点：当主体的数量较多时，配置和维护工作就会成本大、易出错。

b. 自主访问控制DAC（Discretionary Access Control）

        定义：为用户指明能够访问的目标资源（为用户指定资源），规定资源可以被哪些主体进行哪些操作。同时，主体可以将资源、操作的权限，授予其他主体。相比于ACL，DAC可以将授权的权力下放，允许拥有权限的用户，可以直接或间接地将访问权限赋予其他主体（除非受到强制访问控制的限制）。

从定义上来看，DAC授权方式跟ACL授权方式本质是一样的，但是授权的逻辑相反。如上图，用户1可以正常访问权限1和权限2，但是如果想访问权限3或权限4，由于自身权限列表中没有这两个权限，所以不允许访问；用户2也是相同道理，可以访问权限3，但无法访问权限1和权限2、权限4。

常见的应用场景就是：

文件的分享链接，网盘资源分享，授权；分享链接，而这个分享链接，其实就是一个“用户对象”，这个“用户对象”指定了可以访问我们所选取的文件，这样当我们把链接分享出去的时候，打开链接的人就可以看到我们所选取的文件，但对于我们没有选取的网盘内的其他文件，是无法看到的。

缺点：对权限控制比较分散，主体的权限太大，无意间就可能泄露信息。

c. 强制访问控制MAC（Mandatory Access Control, 又叫非自主访问控制）

        定义：目标资源划分为等级，访问者拥有包含等级列表的许可，其中定义了可以访问哪个级别的资源（用户-等级），MAC规定资源可以被哪些类别的主体进行哪些操作，同时规定主体可以对哪些等级的资源进行哪些操作。DAC与MAC对比，DAC的数据存取权限由用户控制，系统无法控制；MAC安全等级由系统控制，用户不能直接进行控制。

常见的应用场景就是：系统等保、军事机密文件等。比如，将军分为上将>中将>少将，军事文件保密等级分为绝密>机密>秘密，规定不同军衔仅能访问不同保密等级的文件，如少将只能访问秘密文件；当某一账号访问某一文件时，系统会验证账号的军衔，也验证文件的保密等级，当军衔和保密等级相对应时才可以访问。

缺点：控制太严格，实现工作量大，缺乏灵活性。

d. 基于角色访问控制RBAC（Role-based access control）

        定义：是一种基于角色的权限管理模型，通过角色指定目标资源，用户绑定角色（用户-角色-权限）这种将权限绑定在角色上，再给用户账号赋予角色的方式就叫做基于角色的权限管理，RBAC支持三个著名的安全原则：最小权限原则、责任分离原则、数据抽象原则。

RBAC模型于1992年由美国国家标准与技术研究院组织开发，是目前最通用的权限管理模型，GerorgeMason大学的教授Ravi Sandhu于1996年对RBAC模型进行改进，提出了RBAC96模型族，包括RBAC0、RBAC1、RBAC2和RBAC3四个模型，RBAC0作为最基础的权限模型，其他三个模型是基于RBAC0的基础进行拓展。

RBAC96模型族

RBAC三要素两关系：User用户、Role角色、Permission权限。用户-角色之间的映射关系、角色-权限之间的映射关系。

在RBAC模型中用户与角色，角色与权限之间均可以是一对一、一对多、多对多。角色起到了桥梁的作用，连接了用户和权限的关系，每个角色可以关联多个权限，同时一个用户关联多个角色，那么这个用户就有了多个角色的多个权限。

RBAC0模型：基础的RBAC模型

优点：

    a. 只抽象了角色一层，角色之间各自独立，没有上下级和等级限制，针对不同的用户权限配置灵活性高，且最小颗粒度授权。

缺点：

    a. 只要有权限不一样的用户加入系统或者当用户权限分得很细的时候，就需要新建一个角色，系统中存在的角色会越来越多。

RBAC1模型：在角色中引入继承关系

在角色中引入上下级关系的RBAC模型就叫做角色继承的RBAC模型（RBAC1），通过给角色分级，高级别的角色可继承低级别角色的权限。

角色间的继承关系可分为一般继承关系和受限继承关系。一般继承关系允许角色间的多向继承，即下级角色可以拥有多个上级角色，上级角色也可以拥有多个下级角色。受限继承关系则进一步要求角色继承关系是单向继承，即下级角色只能拥有一个上级角色，但是上级角色可以拥有多个下级角色，单向继承是一个树结构。

如上图所示，一般继承关系图中，角色3拥有角色2、角色1两个上级，同时角色3拥有角色5、角色6两个下级。而在受限继承关系中，角色3只拥有角色1一个上级，拥有角色6一个下级。无论哪种继承方式，上级角色可继承下级角色的权限，只不过继承的范围有所不同。

一般继承：

     角色1：拥有整个系统权限，相当于系统的超级管理员。

     角色3：拥有自身权限+角色5的权限+角色6的权限。

受限继承：

     角色1：拥有整个系统权限，相当于系统的超级管理员。

     角色3：拥有自身权限+角色6的权限。

即，权限范围：运营主管 > 运营组长 > 销售人员/审核人员/运营人员。

RBAC2模型：在用户授予角色之间加入了限制

对用户授予角色之间进行限制的模型就叫做角色限制的RBAC模型（RBAC2），它是基于业务不同的岗位职责分离扩展而来，为了避免用户拥有过多权限而产生利益冲突，可以把限制具体地分为静态职责分离（SSD）和动态职责分离（DSD）。

静态职责分离（SSD）：

     a. 互斥角色：同一用户只能分配到一组互斥角色集合中至多一个角色，比如用户不能同时拥有会计和审计两个角色。

     b. 基数约束：一个用户可拥有的角色数量有限；一个角色可被分配的用户数量受限；一个角色对应的权限数量受限。

     c. 先决条件角色：用户想要获得较高的权限时首先要拥有低一级的权限，角色A为角色B的上级，要想为用户分配角色A，则必须先分配角色B，比如游戏中的转职。

动态职责分离（DSD）：

     a. 允许一个用户具有多个角色，但在登录运行时只能激活其中某个角色，比如BOSS直聘，一个用户既可以是招聘者也可以是应聘者，但同时只能选择一种身份进行操作，不能以两种角色同时登录。

RBAC3模型：既引入角色间的继承关系，又引入用户授予角色限制关系

RBAC3=RBAC1+RBAC2，既引入了角色间的继承关系，又引入了角色限制关系。RBAC3，最复杂也是最全面的 RBAC 模型，它在 RBAC0 的基础上，将 RBAC1 和RBAC2中的优化部分进行了整合，可以认为是 RBAC0、RBAC1、RBAC2的结合。

特别说明：RBAC进阶设计

从上面的RBAC0、RBAC1、RBAC2、RBAC3当中，可以知道，现有的权限管理模型虽然已经对“权限”层进行了优化，抽象出“角色”，但并没有很好的去抽象“用户”方。

所以，我们在实际的权限设计中，也可以考虑利用抽象的思想将相同属性的用户进行归类。在公司里，最简单的相同属性就是“部门”了，如果给部门赋予了角色和权限，那么这个部门中的所有用户都有了部门权限，而不需要为每一个用户再单独指定角色，在拥有部门权限的同时也还可以单独为用户指定独特的权限。

用户可以分组，权限同样也可以分组。在权限特别多的情况下，可以把同一层级的权限合并为一个权限组，如二级菜单下面有十几个按钮，如果对按钮的操作没有角色之间的限制，可以把这些按钮权限与二级菜单权限合并为一个权限组，然后再把权限组赋予角色就可以了。

“组”概念的引入完善了RBAC模型，在简化操作的同时更贴近了实际业务。

组概念

e. 基于属性访问控制ABAC（Attribute-Based Access Control）

        定义：ABAC是通过动态计算一个或一组属性是否满足某种条件来进行授权判断的，包括用户属性（如性别年龄）、环境属性（如时间地点）、操作属性（如编辑删除）和对象属性（如一篇文章）。

跟RBAC相比，RBAC仅仅描述了用户可以做什么操作，但是操作的条件，以及操作的数据，模型本身是没有这些限制的，这也是由于其模型能力的不足所导致的，但这却恰恰是ABAC的长处，ABAC的思想是基于用户、以及将要访问的数据的属性、以及各种环境因素去动态计算用户是否有权限进行操作。这个模型在如今的云系统中使用的比较多，比如AWS，阿里云，腾讯云，京东云等。这个模型设计过于复杂，目前在市面上并没有广泛应用。

如下例子：

      a. “允许所有班主任在上课时间自由进出校门”这条规则，其中，“班主任”是用户的角色属性，“上课时间”是环境属性，“进出”是操作属性，而“校门”就是对象属性了。

     b. 用户在晚上不能访问这个系统，但是白天可以。

     c. 用户只能在内网对订单具备修改权限，而在外网就只有查看权限。

ABAC模型

四、权限设计的步骤

（1）第一步：罗列所有角色

我们在接业务需求的时候，在进行初步权限方案设计时，先不要急着去定义采用哪种权限设计策略，首先第一步就是从业务中找到所有可能涉及到的角色。如果做的是一个企业内部系统，比如ERP、OA、管理后台，可以根据企业组织架构找到所有角色。以我所在「互联网公司」为例子，则有产品负责人、产品经理、技术负责人、后端开发、前端开发…..等角色。如果是面向B端的其他业务系统，那么，我们就要通过业务流程去找到相关角色，每个流程里面有哪些角色，以我负责过的「数智平台」发起课程备课-学习为例子，则有管理员、创建者、授课教师、协同教师、学生。

（2）第二步：找到各角色之间的关系

列出所有的角色之后，接下来就是找出各角色之间的关系，而角色之间的关系是由业务决定的。常见的有继承、互斥和共享关系，及其他关系：

  a. 等级/继承：拥有上下级关系，比如，产品总监>产品经理>产品助理>产品实习生

  b. 互斥：拥有互斥关系，财务和审计不能是一个人

  c. 共享：拥有共享关系，授课老师和协调老师可以是同一个人

  d. 串行：拥有先后关系，如，先由产品经理进行设计再由开发人员开发

  e. 并行：拥有并行关系，如，前后端同时进行开发

      其他……，比如，还需要考虑，是不是要限制角色的个数，一个用户能不能拥有多个角色等等。同时，还要分析某些角色是否需要内置，哪些角色我们可以事先定好，哪些角色可由用户自定义。通常常把“管理员”角色进行内置，也可根据实际业务去定义，如“教职工”角色，只要进入到系统的用户都默认为一个最初始的身份“教师工”。

（3）第三步：梳理权限

根据前面权限的定义，我们可以知道权限分为：功能权限和数据权限。

1）. 首先，要列出功能清单：

以下以我在实际工作中的项目做例子，该平台是一个以项目式教学为核心的系统，「数智平台」部分功能清单如下；

部分功能清单

2）. 其次，根据业务并结合功能清单，找出角色与权限的关系，即功能权限：

以下为「数智平台」部分角色权限关系，因为当时做的是第一个版本，所以角色、权限并不多，但是梳理角色与权限关系可按照这种思路去做；

角色权限关系表：部分权限示意图

3）. 根据业务，列出数据权限范围：

有些业务数据权限维度些比较简单，有些比较复杂，比如有些不分区域，有些需要分区域，有些需要分组织架构，有些不需要分组织架构。其实数据权限的核心就是：角色+范围。

比如：

  a. 授课教师（角色）能查看所任教科目+所带班级（范围）数据，即，数据范围“授课教师+科目+班级”。

  b. 年级主任（角色）能查看所任年级（范围）的数据，即，数据范围“年级主任+年级”。

数据权限表

做完第一步、第二步、第三步之后，我们就可以结合业务需求考虑该怎么去设计权限策略，通常一个业务系统内，会存在有多种中权限策略，也就是常说的权限管理，比如会有ACL+RBAC两种策略一起使用，应对不同的场景。多个权限管理策略就形成了权限体系。

权限管理是指为解决某一具体的权限分配问题而采用的方法或者策略，比如解决文件的权限分配问题可以采用ACL模型，解决不同年龄段的用户可访问不同类型的电影问题可以采用RBAC+ABAC。而权限体系是指整个系统内采用的权限管理方法的集合。

权限体系

RBAC设计思路

这里我主要侧重讲一下RBAC权限策略，因为后面「数智平台」会向SaaS领域发展，在SaaS领域最常用的权限方案就是RBAC。

设计功能权限离不开最基本的三要素：用户管理、角色管理、权限管理。根据业务的不同，可能还会涉及更复杂的要素：部门管理、职位管理；在这些之上还会配置不同的版本满足不同的客户需求，这就需要版本管理，版本管理是在系统级别就做了隔离，不同版本之间的功能、权限设计会有差异，这是为了满足个性化需求的场景。

用户管理页面

“用户管理”是用于管理用户信息的，如更改用户角色、创建或删除用户、和用户信息。对于业务系统来说，用户管理页面其实就是给业务方使用，以学校为例子，学校用户自己可以管理自己的教师、学生数据，并且通过给不同教师分配角色权限去管理学校教育、教学活动的运营及管理。一般的后台系统也会有相应的用户管理模块。

设计“用户管理”一般有三个页面：

  a. 用户列表页：展示系统中所有的用户。一般有添加、编辑、删除、导出、导入及批量操作等。

  b. 添加用户页：根据业务选择创建时需要的字段。（添加用户与绑定角色动作可以分开或者不分开）

  c. 绑定角色页：可在创建用户的时候选择角色，当然也可以在创建用户后再有单独的入口去绑定角色（如上图）。两种方式没有本质区别。

角色管理页面

用户可以对角色进行管理，可以给不同角色分配不同的权限，自行管理，这就是用户自定义角色管理，且可任意修改。当然这里的角色管理，一般会有一个内置的角色，比如“管理员”，这是由系统内置提供的，用户只能查看和使用。

设计“角色管理”一般有三个页面：

  a. 角色列表页：展示系统中的所有角色，一般有查看、添加、编辑、设置权限、禁用、删除等操作。

  b. 添加角色页：必须输入不可重复的角色名称，可选填状态、描述等信息。

  c. 配置权限页：可在创建角色的同时配置权限，当然也可在创建角色后再有单独入口去配置权限（如上图），两种方式没有本质区别。

权限管理页面

一般来说，这个权限管理在用户方不会出现，主要是软件提供方的内部人员使用，比如开发人员，系统在更新或者迭代某些功能模块的时候，可以通过该页面进行管理，因为用户实际上不用去管理系统功能的增、删、改等操作，他们无权操作，业务方只作为使用者使用而已。当前这个权限管理页面也不一定要有，通常很多时候，在业务开发的时候，直接通过代码层面直接写进入了，就不要有一个页面单独去查看和管理了。这个页面一般只会出现在后台管理系统里面。

关于部门、职位管理、版本的权限设计，我就不过多阐述，底层逻辑跟角色是一样，就是抽象出更高一层拥有公共属性的分类，在进行管理即可。

全文完，内容如有错误欢迎指正！