超越全面的用户权限系统产品设计方案解析

发表时间: 2024-07-03 15:02

在B端和后台系统中,经常会用到权限设计。这篇文章,作者帮我们梳理了权限系统的类型、模型,希望能帮到大家。

这段时间在梳理公司的角色权限关系,为了设计更加合理,我对角色权限系统进行系统化的学习和整理,以下将我的整理结果,和大家分享一下。

一、权限管理概述

权限管理是所有后台系统的都会涉及的一个重要组成部分,主要目的是对不同的人访问资源进行权限的控制,避免因权限控制缺失或操作不当引发的风险问题,如操作错误,隐私数据泄露等问题。

在企业的权限管理中,通常有两类权限,一类是页面/应用的访问权限,一类是数据权限

二、权限控制类型

产品的权限由页面、操作和数据构成,页面与操作相互关联,必须拥有页面权限,才能分配该页面下对应的操作权限。

其中:

  • 页面权限指的是可以看到的页面
  • 操作权限指的是用户可以进行的操作,例如是否可以新增、删除、编辑等
  • 数据权限指的是可以查看数据的范围。

1. 功能权限–对象

对象指赋予权限的人、角色、用户组、组织、岗位

1)人

某个人拥有某个权限,在公司规模比较小的时候,可以简单设置哪些人可以看到哪些权限,维护成本不高;若只绑定人而不绑定角色的弊端:

  • 当人数过多时没有分类,无法快速辨别哪类人拥有权限;
  • 当一群人拥有多个模块的相同权限时,需要把这群人分别为每个模块添加权限,工作量成倍数增长;
  • 当创建新用户时,需要为其增加多个模块的权限。

2)角色

当公司规模较多时,有可能一些人控制某个模块的权限,这时候就需要引入角色的功能,把这些人绑定到一个角色里,再把角色赋予权限,这样就可以清晰的看见模块权限对应哪些角色,解决用户数量大的情况下,用户分配权限繁琐以及用户—权限关系维护成本高的问题,节省了大量的资源。

3)用户组

用户组是将具有相同属性的用户组合在一起,用户组是一群用户的组合,而角色是用户和权限之间的桥梁。

如果一批用户需要相同的角色,我们也需要逐个为用户分配角色。

例如,一个公司的客服部门有500多名员工。某一天,研发部门开发了一套后台数据查询产品,所有客服人员都需要使用。然而,由于之前并未统一为所有客服人员分配一个角色,现在需要新增一个角色,将权限分配给该角色,然后再逐个将角色分配给客服人员。发现为500名用户逐个添加角色非常繁琐。然而,客服人员具有共同属性,因此我们可以创建一个用户组,所有客服人员都属于该客服用户组,将角色分配给客服用户组,这样该用户组下的所有用户便拥有了所需权限。

用户可以进行分组,这有助于简化用户与角色之间的对应关系;用户可以分组,权限也可以分组。

在权限特别繁多的情况下,可以将一个模块的权限组合成一个权限组,这有助于简化权限和角色之间的对应关系。

4)组织

每个公司内部均构建有其独特的组织架构,而在实践中,权限分配常常会依据这一架构进行细化划分。

其原因在于,同一组织单元内的成员通常需要执行相似的工作职能,因而对权限的需求大体一致。

遵循公司的组织架构,同一组织内成员所配备的基础权限往往具有较高的一致性。

按照组织架构来设定角色并分配权限的做法,实际上包括以下两个优势:

① 实现权限分配的自动化

实现组织关系与权限系统的深度融合后,对于新入职员工,只需将其归入相应的组织单元,其角色权限便会自动继承该组织下的所有权限设定,无需逐一进行人工分配。

同样,当员工发生岗位调动时,仅需对其组织关系作出相应调整,权限配置将随之联动更新,全程无须人工介入。

此方案的实施首要前提是实现权限体系与组织结构间的有效对接。

② 控制数据权限

通过将角色与特定组织紧密关联,确保该组织成员仅能访问其所属组织层级内的数据,各部门成员仅能查看与自身组织直接相关的数据,实现了跨部门数据的隔离与保护。

5)岗位

一个组织下面会有很多职位,比如财务管理会有财务总监、财务主管、会计、出纳员等职位,每个职位需要的权限是不一样的,可以像组织那样根据职位来分配不同的角色

2. 功能权限–级别

级别也称账号安全级别,一般通过0-100的数字控制用户账号的功能权限,通常设置的数值越大,权限范围越大。

适用场景:比如创建的正式员工默认安全级别为10,外包员工默认为0,则当某个功能开放给所有人,并且这个功能仅限正式员工可操作时,可通过限制此功能的安全级别(调整为10)控制只能正式员工查看。

功能组合:安全级别还可与对象(组织、角色、岗位、人、用户组)组合,达到更精细化控制权限的目的,比如安全级别与部门相搭配,可控制此部门下特定的安全范围的人可以操作功能。

3. 数据权限–时间

权限中的时间是指数据到达某个时间节点后,是否要继续给用户查看,应用场景:比如外部人员需要查看某一年度的数据时,只需开放对应时间的数据给他们,这么做就可以保证数据的安全,不会遭到泄露。

4. 数据权限–区域

权限中的区域也可以理解为范围,是指某一区间的值,可以对区域范围内的数据进行查看,应用场景:比如共享单车的运维人员只需查看他所负责的区域的车辆数据即可

三、权限的扩展功能

1. 菜单权限

菜单权限一般分为前端菜单权限和后端菜单权限。前端菜单权限是指用户层面操作的菜单页面,后端菜单权限是指系统管理员、系统运维人员层面操作的菜单页面。

2. 权限转移

对于员工从原部门调走,离职等情况的发生,当有新员工接手他的工作时,则需要权限转移的功能。

转移的内容一般为角色、菜单,更精细化的内容还可以分为下属、待办、已办、文档等,如果是CRM系统,还可以转移他的客户等。

四、常见的权限管理模型

1. 基础权限管理系统

–简单清晰但无法承载复杂的需求

基础权限系统的设计,一般都是从「用户-权限」这两个纬度开始的,管理员需要为每一个用户单独定义权限。

如果系统中用户数在几十个上下,权限变动也不太多时,这种「用户-权限」的权限管理逻辑简单清晰,很好用。

但当系统中用户开始增多,到达上千、上万时,此种管理方法的局限性就暴露出来了:

2. 基于角色概念的权限设计–RBAC模型

1)RBAC0

RBAC0是基于角色的访问控制的完美体现,也就是把权限赋予角色,然后再把角色赋予用户,在这个模型中,角色起到了连接用户和权限关系的桥梁作用。

每个角色可以拥有多个权限,每个用户可以被分配多个角色,从而使用户具备多个角色的多个权限。

在对角色权限系统进行设计时,只需给对应的角色配置系统中的权限(菜单/操作/字段),完成角色创建后,再将角色赋予系统用户即可。

这样在用户登录后,就能获取该用户的所属角色,然后通过角色来找到拥有的权限,再加载对应的权限资源。

一般来说包含菜单管理、用户管理、角色管理等功能页面

菜单管理:对页面进行配置,与访问路径映射,填写菜单路径,设置页面顺序,方便访问

用户管理:对用户进行管理,给用户赋予角色

角色管理:对角色进行管理,给角色分配权限

2)RBAC1–引入继承的概念

如果一个部门人员很多,如一级部门向下还有二级部门,二级部门向下才是员工,这样就导致如果采用RBAC0模型进行权限管理的话,则很有可能错配权限的问题。

角色继承的RBAC模型又称RBAC1模型,在角色继承的RBAC模型中,上层角色会继承下层角色的所有权限,并且可以额外拥有其他权限。下级角色的权限上级角色都具备,并且上级角色可以拥有其他权限

RBAC1模型相较于RBAC0模型增加了角色继承的概念,有了角色继承就有父子的关系,即子角色可拥有父角色的权限。

在配置角色的时候可以增加父角色的选择,可在父角色的基础上进行删减权限,以避免错配权限的问题。

3)RBAC2–添加责任分离关系

RBAC2模型是RBAC0的另一变种,对用户、角色和权限三者之间增加了一些限制。这些限制可以分成两类,即静态职责分离SSD(Static Separation of Duty)和动态职责分离DSD(Dynamic Separation of Duty)。

① 静态职责分离

  • 互斥角色限制:一个用户不能同时分配互斥角色中的多个角色,即只能选择一个。比如如果想拥有审核员的角色就必须先去掉会计的角色。假设提交角色和审核角色是互质的,我们可以用图形表示:
  • 基数限制:一个用户拥有的角色是有限的。例如规定拥有超级管理员角色的用户只能有1个,用户被分配的角色数量,以及角色分配的权限数量也可以被限制。
  • 先决条件限制:一个用户想获得更高级的角色,首先需先拥有低级角色。比如技术负责人角色和普通技术员工角色存在上下级关系,因此用户想要拥有技术负责人角色就必须先拥有普通技术员工角色。

② 动态职责分离

  • 动态限制:一个用户可以拥有两个角色,但是运行时只能激活一个角色。

4)RBAC3–基于RBAC0、RBAC1和RBAC2进行整合

3. 数据权限

为了数据权限控制的灵活度,在角色管理中还可以设置角色的数据权限范围

作者:诺儿笔记本,公众号:诺儿笔记本

本文由 @诺儿笔记本 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议。

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。