B端后台“权限设计”的99种解法与反思

“权限设计”是中后台的底层设计，它是系统设计中最为重要的一环。

优秀的权限设计能够有效提高系统的安全性、降低用户误操作，数据泄露的风险；差劲的权限设计，往往会导致系统流程不通，系统的稳定性和安全性受到威胁。

而产品经理在设计权限时，往往会一头雾水，不知从何下手。

其问题在于：一方面开源的权限产品较少，产品经理无从体验，借鉴。另一方面关于权限的文章良莠不齐，缺乏系统性的文章帮助了解权限构成，产品们只能摸着石头过河，犯一些认知之外的错误。

对此，笔者根据此前的产品实操经验，整合互联网优秀权限文章，输出自身关于权限的浅薄认知，望能起到些抛砖引玉的作用。

一、权限的定义是什么？

权限，百度百科将其定义为：“保证职责的有效履行，任职者必须具备的，对某事项能进行决策的范围和程度。”

但笔者理解为：“不同的对象在不同使用场景下，所需要的产品相应的权力和责任的统一，其核心为权责明晰，权责分离，目的是建立分配资源的规则，以便用户能够通过这套规则，获取他们应获得的资源。”

二、权限的维度有多少？

通常情况下，我们会将权限分成两个维度，分别为功能权限和数据权限。功能权限是指用户能够做什么样的操作，或者访问哪些资源，使用哪些功能；数据权限是指哪些数据属于你，或者属于你可以操作的范围。

从颗粒度维度来分，功能权限的颗粒度从粗到细一般分为“模块级”>>“页面级”>>“接口级”，由此引申出了常说的页面权限、模块权限、接口权限。

数据权限的颗粒度从粗到细一般分为“对象级”>>”字段级”，由此引申出对象级数据权限（具体到实际用户）、字段级数据权限（具体到表单字段）。

从权限操作维度来说，权限操作可以分为授权和鉴权。

1. 鉴权是指验证用户是否拥有访问系统的权利，一般是指针对具体人的行为，根据权限规则进行合法性鉴别。在逻辑上，鉴权一般先于授权。
2. 授权一般可理解为是分配给具体的权限给具体的人。它可分为功能授权和数据授权。

功能授权往往是单一维度的，一般会功能列表或者功能树上进行勾选，来确定用户所对应的可操作资源。

数据授权和功能授权不同，数据是多维的，是抽象的。因此，在做数据授权之前，往往需要考虑对数据维度进行拆分，而数据是抽象的，我们不能具象地看待单个用户的某一条数据，那没有任何意义，而是要内置抽象的规则，通过抽象的规则，去寻找数据背后的联系。

三、权限设计的模型有哪些？

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

自主访问控制是指由用户有权对自身所创建的访问对象（文件、数据表等）进行访问，拥有对象权限的用户。

可将对这些对象的访问权授予其他用户和从授予权限的用户收回其访问权限，此类权限模型往往应用于文档系统的权限设计，例如微软的NTFS文件系统。

DAC不仅能够分配权限，还能够对权限进行累加，继承，但是其最大的缺点在于，权限过于分散，不方便管理，例如，无法简单地将一组文件设置一个统一的权限开发给制定的一群用户。

2. 强制访问控制（MAC：Mandatory Access Control）

MAC模型往往用于信息敏感行业，该模型将系统中的信息分密级和类进行管理，以保证每个用户只能访问到那些被标明可以由他访问的信息的一种访问约束机制。

通俗地来说，在强制访问控制下，用户（或其他主体）与文件（或其他客体）都被标记了固定的安全属性（如安全级、访问权限等），在每次访问发生时，系统检测安全属性以便确定一个用户是否有权访问该文件。例如多级安全（MultiLevel Secure, MLS）就是一种强制访问控制策略。

3. 访问控制列表（ACL：Access Control List）

ACL（Access Control List）主要包含三个关键要素用户（User）、资源（Resource）和操作（Operate）。

ACL将每一项资源都分配一个列表，当用户需要访问资源时，都会先去请求列表是否有当前用户的访问权限，从而确定当前用户可否执行相应操作。

其优点是，ACL及其简单，不需要任何基础设备就可完成访问控制，但是由于其表单数量过多，导致若系统内部有大量资源，管理访问控制列表就成为了繁琐的工作。

4. 基于角色的访问控制制（RBAC：Role-Based Access Control）

RBAC模型是在实际业务中使用最多的模型，RBAC模型主要由3个基础模块组成，分别为用户、角色、权限。系统通过编辑用户与角色、角色与权限的映射关系，解耦用户与权限的关系，大幅度降低数据冗余，进而降低了系统的复杂度，提高了系统的灵活性。

RBAC模型它只是一个大类，它可以细致地划分为：RBAC0、RBAC1、RBAC2、RBAC3。

1）基本模型：RBAC0

RBAC0是RBAC的核心，它定义了能构成RBAC控制系统的最小元素的集合（角色）。在此模型中，它指明了角色、用户、访问权限和会话之间的关系。其流程为，通过用户关联角色，定义权限集（角色）的方法间接的赋予用户权限，进而达到用户和权限解耦的目的。

在RABC中，用户与角色的关系可以分为为“N：1（多对一）的用户角色关系”和”N:N（多对多）的用户角色关系“。

举个N：1的用户角色关系的例子，李三、李四（用户）都是A部门（用户组）的人，岗位都为产品运营（角色），他们都需要文章审核、文章发布功能（权限）。因此，只需要对产品运营（角色）进行分配文章审核、文章发布（权限），将产品运营（角色）分配给李三、李四即可。

N：N（多对多）的用户角色关系中，若一个用户被分配了多个角色，那么该用户的权限为所分配角色的并集。

再举个例子，李五为B部门的产品经理，权限为文章模板设置。但是因为某次调研，他需要A部门的文章审核、发布权限。当分配给他A部门产品运营角色后，此时，他的权限变成了文章审核、发布权限、文章模板设置。

但在实际业务中，对于用户的理解并非如上文中所写的那么浅薄。实际上，对于用户的定义多种多样，就笔者自身对用户的理解而言：“用户本质上为一个个需求的集合体“。

从这个角度来讲，在使用场景和需求相对一致的情况下，可以将这部分用户看作一个需求集合体一致的群组，进而形成一个用户组（即为用户的集合体）。

拿之前的例子来说，若A部门为产品运营部，那么我们无需对A部门内部的人去分配角色。而是以A部门为对象去分配角色。

同时，现实中同样也存在以下使用场景，需要对用户分配居多的权限，若一个个分配将特别繁琐，因而可以选择将相对固定的权限打包成组来赋予给用户。

2）角色分层模型：RBAC1

RBAC1在RBAC0的基础上，引入角色间的继承关系，即角色上有了上下级的区别。角色间的继承关系可分为一般继承关系和受限继承关系。

一般继承关系仅要求角色继承关系是一个绝对偏序关系（有向无环图），可进行多继承。而受限继承关系则进一步要求角色继承关系是一个树结构（二叉树）间的单继承。

一般继承的RBAC和受限继承的RBAC两者的区别在于：前者是图，可多继承；而后者可以有多个父节点但只能有一个子节点，是一个反向树结构，只能单继承。

RBAC1模型往往使用于角色之间层级明晰的产品中，一般会和组织架构关联起来。例如，李三为产品运营，其上级李四为产品经理。则李四会将其部分权限授权给李三，也可认定为李三继承了李四的部分权限，即子集继承了父级部分权限。

3）角色限制模型：RBAC2

RBAC2模型中添加了责任分离关系。RBAC2的约束规定了权限被赋予角色时，或角色被赋予用户时，以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。

责任分离包括静态责任分离和动态责任分离。约束与用户——角色——权限关系一起决定了RBAC2模型中用户的访问许可，此约束有多种，主要包括：

静态限制（静态责任分离）同一用户只能分配到一组互斥角色集合中至多一个角色，支持责任分离的原则。例如：同一个人不能既是“运动员”又是“裁判员”，即当用户分配给受众运动员的角色后，权限页面无法给于其分配裁判员的权限。

动态限制：运行时互斥：例如，允许一个用户具有两个角色的成员资格，但在运行中不可同时激活这两个角色。当一个人被授予了运动员和裁判员角色，在一次比赛中，他只能选择以一个身份进行，不能以两种身份同时进行。

基数约束：一个角色被分配的用户数量受限；一个用户可拥有的角色数目受限；同样一个角色对应的访问权限数目也应受限，以控制高级权限。

先决条件角色：可以分配角色给用户仅当该用户已经是另一角色的成员；对应的可以分配访问权限给角色，仅当该角色已经拥有另一种访问权限。要想获得较高的权限，要首先拥有低一级的权限。就像我们生活中，国家主席是从副主席中选举的一样。

4）整合统一模型：RBAC3

RBAC3包含了RBAC1和RBAC2，既提供了角色间的继承关系，又提供了责任分离关系。

5. 基于属性的权限验证（ABAC：Attribute-Based Access Control）

ABAC被认为是权限控制的未来，由于其逻辑比较复杂，笔者并未吃透，所以只简单地介绍一下。

ABAC可分为访问控制策略、环境条件、主体、客体、主体属性、客体属性。它通过将主体属性、客体属性和环境条件结合起来，按照它们与访问控制策略的匹配情况来确定访问（即对系统客体的操作）。

简单而言就是将主体和客体的属性用策略相关联，通过读取策略来确定主体可对客体进行哪些操作。

四、基于RBAC模型设计权限时应注意什么？

1. 熟悉业务流程，盘点角色

设计初期，应该重新梳理系统中不同模块的业务流程，通过业务流程图，来盘点各个节点的角色，在这一环节中，需要对角色进行穷举，保证系统在运行过程中达到闭环。一般情况下：

• 角色通过岗位去划分，例如在禅道中，通过不同的岗位来划分不同的角色。
• 角色通过任务流划分，根据业务流程中的不同节点功能，可将定义角色，例如，在某审批系统，可将角色划分为录入人员、审核人员。

2. 盘点权限，使用正确的描述方式

将系统中的所有功能模块进行归纳整理，并根据自身系统所需要的颗粒度，来选择权限的颗粒度。

同时，在PRD中传达一个系统的权限设计规则时，不应该采用“当…时，就….“的语句去表达规则，而是要将角色和单元绘制成网格，每一个交叉节点为描述该角色与权限的数据关系和限制。

特别要注意的是，在设计数据权限时，其查看权限往往应设计在“增、删、改、查”之前。

3. 做好无页面权限的提示

在正常情况下，当用户无对应权限时，该页面会直接隐藏，但也不排除用户可以获取到权限外的URL地址，因为当用户访问到没有权限的页面时，需提示该用户无对应权限。

4. 创建默认角色

默认角色一般为系统中自带的角色，其往往包括超级管理员，管理员、业务员等等。

一般情况下，超级管理员为隐形角色，为领导高层掌握，拥有整个系统的所有权限，管理员继承超级管理员所分配的权限，若管理员唯一的情况下，自身不可编辑，不可删除，防止用户删除管理员角色，导致系统无法正常运行。其余角色为管理员创建，可编辑，可删除。

5. 对系统的长期规划需明确

在搭建权限系统时，应该详细地了解系统的业务范围和长期规划，梳理角色，并尽可能多地获取用户信息。

例如，在数据权限配置过程种，我们通过数据打标来划分数据权限，但是随着数据的标识增加，权限判断条件增多，就会出现大量用户信息需要判断的问题。

6. 用户的长期维护需及时处理

当系统长时间运转时，在权限上，可能会因为用户离职，权限系统未及时更新，而导致内部数据泄露的问题发生。针对这种情况，产品可采用权限系统与OA系统互通或者系统设置数据自动清洗的规则来解决。

7. 公司内部的权限规则需统一

当一个系统非常庞大时，由多名产品经理负责时，可能会出现由于没有制定统一的权限规范，导致在提需求时，忘记说明而导致新功能没有去实现权限控制。因此，在一个相对较大的项目中，产品经理们可以针对权限、UI做一个统一的标准。

互联网上优秀的权限文章合集

• 【网易UEDC】角色权限设计的100种解法
• 【腾讯CDC】系统解读：权限设计指南
• 【王赛】中后台学习笔记-数据权限
• 【学习文档】RBAC总结
• 【Enlink_Young】基于熟悉的访问控制（ABAC）定义与思考

本文作者 @lee的自我复盘 。

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！