业务中台--如何设计企业级权限管理系统

叁歲伎倆 2023-03-04 12:27 157阅读 0赞

> 不管是2C产品经理还是2B产品经理，都要将权限管理法则烂熟于心。只有熟悉权限管理法则，才能更好地理解自己产品的架构，做到每次产品迭代都心里有数。

产品经理在思考产品架构的过程中，必须要有业务流程的参与。通过业务流，常常会抽象出对产品有诉求的多个角色，再依据角色的特性去梳理使用场景并设计需求。

当角色之间的使用场景不冲突，不需要隔离时，我们会综合考虑这些角色的使用场景来设计解决方案。比如QQ音乐同时需要为听歌和听电台的用户提供所有的功能需求。

![format_png][]

当这些角色的使用场景完全不重叠、流程对立时，我们会设计完全独立的两套系统，如微店卖家端和买家端；

![format_png 1][]

除了上面两种情况，在toB产品中，基于产品流程和信息安全等多符合因素考虑， 各个角色的使用场景是部分通用，部分隔离的，这时候就需要引入“权限系统”了。

![format_png 2][]

涉及到权限的问题往往是都是复杂的问题，在系统权限控制方面，我们经常会参照现成的案例来设计自己的权限控制，以下就是John所总结最常见的四种权限控制的方法。

**一、控制系统的帐号及登录**

**1. 帐号的定义**

基本上所有的互联网产品，无论是移动端、PC端、C端或B端产品，登录都需要一个账号。只是对于C端的产品，都是用户自己注册即可。

而对于后台产品而言，是需要公司内部人员去创建账号的。而这个账号就是一把钥匙，我们通过控制账号所具备的权限，进而控制这个员工的所操作区域。

**2. 帐号的层级：****企业（管理员）帐号、普通帐号**

公司的实际运营人，他应该掌握最核心、权限最大的企业帐号，所以也可以称为“管理员帐号”俗称admin账号，其他都为普通帐号。

在实际系统中的核心业务步骤如下：

*  企业搭建系统时，默认会用admin作为系统账号的最高权限。下级可以创建企业账号（依托于权限）。
 *  在部署培训阶段，可指导企业账号持有人创建一个或多个普通账号（可是给其帐号授权管理员角色），后续配置即由管理员账号进行。

（魅族的小伙伴可以说下，魅族论坛账号为“J.Wong”是不是admin的权限。哈哈哈哈）

在用户状态上加状态控制，可用的用户就可以登录系统，禁用、停用的就无法登录。

**二、角色管理角色**

往往是基于业务管理需求而预先在系统中设定好的固定标签，每个角色对应明确的系统权限，他是一个集合的概念，是众多最小权限颗粒的组成。我们通过把权限给这个角色，再把角色给账号，从而实现账号的权限，因此它承担了一个桥梁的作用。引入角色这个概念，可以帮助我们灵活的扩展，使一个账号可以具备多种角色。

其所拥有的系统权限一般不会随意更改，并且角色也不会随着用户的被添加和被移除而进行改变，相较于用户管理而言更加稳定。

![format_png 3][]

而引入“角色”概念后，用户与角色之间的关系链是怎么样的？这儿引用一个模型：**RBAC模型**（已经被大家写文章用坏了，可能有些小伙伴还是懵逼），John这边贴上百度百科解释下：

> 基于角色的权限访问控制（Role-Based Access Control）作为传统访问控制（自主访问，强制访问）的有前景的代替受到广泛的关注。在RBAC中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。这就极大地简化了权限的管理。在一个组织中，角色是为了完成各种工作而创造，用户则依据它的责任和资格来被指派相应的角色，用户可以很容易地从一个角色被指派到另一个角色。角色可依新的需求和系统的合并而赋予新的权限，而权限也可根据需要而从某角色中回收。角色与角色的关系可以建立起来以囊括更广泛的客观情况。

简单点一句话说下：Who（权限的拥有者或主体）对What/Which（权限针对的对象或资源）进行How（权限针对的对象或资源）操作。

![format_png 4][]

上图示意为：用户与角色可为多对一或多对多的关系，当一个用户的角色为多对多时，当前用户的权限是多个角色的并集。

此时只需要为角色赋予权限，能够大大减轻管理负担，同时将用户与权限解耦，提供更大的灵活性。

由于随着公司扩大角色的增多，试想如果用户量上万，新增一个角色时，可能需要为大量用户都分配一遍新的角色，工程量仍然巨大，此时即可以引入用户组的概念：如果部分用户的使用场景是相对一致和基础的，我们可以把这些用户打包成一个组，基于这个组的对象进行角色和权限的赋予。

同理如果权限较多时也会存在一样的问题，处理方式是引入权限组的概念，将使用场景相对固定的一组功能或权限打包成组赋予角色。但是一般来讲一个系统中权限功能的体量是相对有限和可控的，所以实际应用中对权限组的使用较少。

![format_png 5][]

![format_png 6][]

![format_png 7][]

用一个页面例子来解释下：

![format_png 8][]

（用户组）

![format_png 9][]

（用户管理）

![format_png 10][]

（用户权限&权限组）

**三、控制功能权限（案例）**

功能权限定义：为可见、可以操作的功能范围。例如：某一部分目录，或者某个页面里的各种操作。

**1. 目录管理模块**

类型分为2种：目录、操作。

在目录上加权限控制，有权限的就可以访问对应模块。

在业务模块的功能按钮上加权限控制，最小粒度的控制用户行为。例如：上级有录入商品的权限，就能看到商品录入的操作，点击录入就可以进行商品的录入操作；反之没有该权限的下级就无法进行商品录入的操作。

![format_png 11][]

（红色的代表目录，蓝色的代表操作）

**2. 控制功能权限管理**

底层目录管理配置一般为开发人员一早就配置好，现在由用户进行分配使用这些功能权限。

**功能权限：**以角色为基础，通过划分不同角色的不同功能权限，并将员工添加到对应的角色中，实现员工功能权限的区分和隔离，包括：

*  对象级功能：比如功能的入口是否可见，如角色为“人事HR”，对“人员管理”的“查看列表”权限点取消，则此角色下员工不可见人员管理的功能入口。
 *  操作点权限：比如新建、编辑等业务操作；

**字段权限：**在展示信息时加权限控制，保证敏感信息的安全性。可为角色配置对象字段的读写、只读或不可见。比如：为角色“服务人员”配置销售订单的【销售订单金额】字段不可见。

![format_png 12][]

（字段权限细节）

*  【读写】权限：员工将具备该字段的最大权限，【新建】【编辑】时可编辑，列表和详情页可见该字段。
 *  【只读】权限：员工在【新建】【编辑】时不可编辑，列表和详情页可见该字段。
 *  【不可见】权限：员工在【新建】【编辑】【列表】【详情】界面对该字段（或该字段值）不可见。

功能权限对于前端界面的影响点：

*  如果员工没有某对象“查看列表”的权限，则该对象的功能入口会被隐藏。
 *  如果员工没有某对象的操作点权限，则在对象页面上隐藏相应操作按钮。
 *  如果员工没有某对象的指定字段的可见权限，则在对象页面上隐藏相应字段。

**总结下：****在权限管理中，需要遵循的一个重要的点：****用户移动要匹配对应的操作。**

**四、配置权限注意点**

产品设计支持后，配置权限需要注意以下几个要点：

**1. 确定是否支持前端配置**

如果角色和权限相对固定，则一般将角色与权限的关系可以写在后台，改动时需要后端变更且重新上线；这种情况适用于公司内部系统等只有一个使用主体的系统。

如果需要自定义角色、或者每个角色在不同使用者的场景下有不同的权限，则需要将角色的定义、角色与权限之间的配置体现在“前端用户配置页面”；这种情况适用于有频繁变动的自定义角色权限，和有租户体系的系统。

**2. 以基本单元拆分，以业务逻辑配置**

一般可将每个对象的“增、删、改、查”各自作为一个基本的权限单元。打个比方，在“人员管理”中，查看人员列表、添加人员、删除人员、编辑人员信息最好拆分为4个权限单元。在技术和设计上，我们希望能尽量做到解耦和模块化。

但是在业务层面有些操作却是一体的。这些不能拆开的权限在“前端用户配置页面”中建议打包成一个整体提供配置。例如，如果我们确定在系统的现有和未来业务中，仅分为普通成员有“人员管理”的查看权限，管理员有操作权限，则可将“增、删、改”三个基本权限单位合并为“操作”权限进行配置。

**3. 页面权限优先于操作和数据权限**

必须配置了页面模块权限后，才能配置当前页面模块下具体的操作权限，以及页面模块的数据展示权限；

**4. 查看权限优先于增删改权限**

正常情况下，一定要先能查看某个模块或操作，其它的增删改操作才有意义。因此在设计时，应在获取查看权限前限制其它权限的配置；或者配置其它权限时默认赋予查看权限。

**5. 角色与权限的多种关系**

角色与权限的关系不仅是单纯“是/否关系”，还包括以某种限制进行操作，和以某种程度访问数据。例如在“人员管理”中：

*  数据范围：用户拥有查看人员列表的权限，但仅能查看自己所在的团队；
 *  数据边界限制（上限等）：添加人员时不能超过20个等。
 *  数据字段：HR能查看人员列表中包括职级、薪资等字段；其它角色仅能查看姓名邮箱等字段；

**6. 角色与权限的设计表达**

在传达一个系统的权限设计规则时，设计师常常习惯用主观最直接的方式表达想法，如用“当……时，就……”的句式来表达。但一个平台中涉及的权限规则是非常多的，当通篇以这样的形式描述时，表达对象将很难理解。

正确的描述方式：更清晰的是基于开发的语言，和技术模型的结果进行表达：将各角色与权限单元绘制成网格，每个交叉点网格中描述该角色与权限的数据关系和限制。

**五、后台产品逻辑自查表**

后台产品逻辑遵循的就是八个字：“增（增加）”、“删（删除）”、“改（修改）”、“查（查询）”、“显（显示）”“算（算法）”、“传（传递）”和“异（异常）”。用一张表来整体看下自查表：

![format_png 13][]

后台权限不复杂，用户角色和权限一一对应匹配就好了。同样前端后台都不复杂，只要真实清楚的去了解业务就好了。

[format_png]: /images/20230208/58ac2594928e46fd9c48ce57f01c33a6.png
[format_png 1]: /images/20230208/430832d439a84c01ad53b64a87b79592.png
[format_png 2]: /images/20230208/b6b460525645407aa502b8adf4bff049.png
[format_png 3]: /images/20230208/e95a4ace280e44329ffa5f66ad3f46ce.png
[format_png 4]: /images/20230208/149a5206c39547fa99ba122fcb687a20.png
[format_png 5]: /images/20230208/d5467247e3e3476d90aa8aa343eb2f19.png
[format_png 6]: /images/20230208/4d35859a8fd74dc383cf32952e79f48e.png
[format_png 7]: /images/20230208/c079449bf0da4a7ba6098c928ef0b35f.png
[format_png 8]: /images/20230208/b631929545ed406eb9e3851bbad91503.png
[format_png 9]: /images/20230208/c1f401f6fbef4b05b8834abcfd4ec20c.png
[format_png 10]: /images/20230208/13685911d9344b83b4fee09d9ad3a607.png
[format_png 11]: /images/20230208/e10320afd4f649ee96a3aa2c8996f354.png
[format_png 12]: /images/20230208/1ab19cb36e3c4d92b6ee93868ea41136.png
[format_png 13]: /images/20230208/d5a4bdcc179d43e0841066fa213c6626.png