一文读懂用户权限设计

4 评论 9163 浏览 88 收藏 16 分钟

用户权限管理是指在B端后台中,需要给用户赋予角色和访问权限等,是很多后台系统建设的基础。那我们应如何入手进行搭建呢?作者结合实际工作中的经验,将这部分的理解梳理出来,希望能对你有所帮助。

一、为什么要进行用户权限设计?

用户权限设计的目的是对不同的人访问资源进行权限的控制,避免因权限控制缺失或操作不当引发的风险问题,如操作错误,隐私数据泄露等问题。

在B端系统中,不同角色的用户对于系统功能和数据的需求是不同的,因此需要对用户进行分类,并为每个分类分配相应的角色和权限。

这里我们以OA系统为例,系统提供了100多个菜单页面,但是有多种不同身份的使用者,这时,我们就需要对不同的员工,相同部门级别不同的员工分配权限,这就要求我们必须在后台系统中引入用户权限设计。

例如:

HR和行政人员可以看到【员工信息页面】,但HR的页面有【入职】按钮,而行政却没有;

再比如:

财务部有2名员工,员工A负责研发部的财务预算支出,员工B负责销售部的预算支出,虽然他们俩都能访问【预算支出页面】,但却只能看到自己管辖的部门的,不能看到其他人的。而财务总监,可以看到全公司的预算数据。

二 、系统权限

在讲完了为什么需要进行用户权限设计之后,我们再来讲下常见的权限。

1. 菜单权限

菜单权限是指用户登录系统后可以访问的菜单项,我们可以将菜单授权给用户,拥有该授权的用户则可以使用该菜单下相关功能。菜单权限相较于其他权限而言,是最基础的权限,其他权限基于菜单权限展开拓展。

常见的功能菜单以一级菜单 → 二级菜单 → 三级菜单依次排列,勾选上对应的菜单,即拥有该菜单的访问权限。

2. 按钮权限

按钮权限一般也可理解为操作权限,是指用户登录系统后可以进行的操作,例如查看、编辑、删除等。我们一般将操作权限赋予到按钮上,当需要给某类用户某种特定的按钮权限时,将按钮权限赋予用户,那么用户即拥有操作权限。例如销售部门可以查看、编辑客户信息、订单信息,而运营部门只能查看。

以下是我们公司的一些常见的按钮权限的配置样式,我们一般喜欢将按钮权限配置在某个菜单之下,当勾选中该按钮时,则表示对应的角色有该按钮权限。

3. 数据权限

数据展示权限是指用户登录系统后可以查看的数据范围,即能查看多少数据,什么类型的数据。例如,管理员能查看所有坐席人员的质检记录,而坐席人员只能查看自己的质检记录。

最常见的数据权限一般是基于“组织架构树”展开的,即可以设置该数据可以给组织结构中的哪些人员可见,或者指定给某个组织可见。

数据权限的设置一般会根据公司规模,事业线的多少做区分,当公司规模比较小,没有复杂的多事业线时,一般采用以下方式,决定用户能看到是本人,还是本部门,还是本公司的数据。

当公司规模较大,且公司下有多个子事业部时,这时可以将数据权限按组织架构进行指定,指定xx事业部下xx部门可进行查看该数据权限。

上述说的2种数据权限,一般更多指的是数据的查看权限,那如果想控制某些部门不仅可以查看,还可以拥有编辑的权限。除了可以通过按钮权限实现以外,还可以将数据权限的增删改权限赋予给某个某部门,那拥有该权限的部门则可进行编辑等权限。

参考以下示例(一般不建议这种数据权限控制)。

那除了对某个页面进行整体的数据权限控制以外,我们还可以针对某一列某一行进行权限控制。例如【员工信息页面】,人事可以身份证号列,而行政却看不到。

4. 应用权限

应用权限是功能组的衍生,可以把应用权限理解功能模块的集合,一般更多的用于saas产品上。例如,我们可以把功能合并一下:包含战略管理、财务管理、人事管理、订单管理几个模块整合成几个大的应用,然后根据企业的需求,直接将该应用的权限分配到用户上。

三、角色

讲完了系统的角色,接下来需要解决用户的问题。系统有很多用户,那如何给每一个用户分配合适的权限?一般有2种方式。

1. 直接分配

直接分配就是直接将权限分配给具体的某一个用户。这种方式就是比较灵活,能最大化的满足每个用户的个性化需求。但这种方式的缺点也比较明显,一旦用户量多起来,这种工作量就很大,不适合于大规模的公司。

举个简单的例子:当公司入职了10名销售部的新员工,需要给他们分配销售专员的角色,那这时如果用直接分配的方式,那么就得重复操作10次,这种方式工作量太大,相信到时候分配权限的员工,肯定会吐槽你。

2. 基于角色RBAC模型进行分配

RBAC(Role-BasedAccess Control)基于角色的访问控制方式:该模型首先定义一些组织内的角色,如局长、科长、职员;再根据管理规定给这些角色分配相应的权限,最后对组织内的每个人根据具体业务和职位分配一个或多个角色。

基于角色RBAC模型的分配方式,就是间接分配方式,这是将用户跟权限之间建立一个集合,然后将用户通过角色与权限进行管理,这就是我们传说的用户角色权限模型。

这种方式就只需要将用户跟角色建立关联,在给用户分配权限时,只需要给用户关联角色即可。当角色权限需要变更时,直接调整角色权限即可,拥有该角色的用户权限也会同步进行动态调整。

RBAC模型可以分为:RBAC0、RBAC1、RBAC2、RBAC3 四种。

RBAC0:最基本模型,它包括用户、角色和权限三个基础组成部分,其中用户和角色之间的关系是多对一的关系,而角色和权限之间的关系是多对多的关系(大部分后台系统都采用了RBAC0这种方式),

  • 多对一:即一个角色被多个用户充当;
  • 多对多:即一个角色可以拥有多种权限。

那么,什么时候该使用多对一的权限体系,什么时候又该使用多对多的权限体系呢?

如果系统功能比较单一,使用人员较少,岗位权限相对清晰且确保不会出现兼岗的情况,此时可以考虑用多对一的权限体系。其余情况尽量使用多对多的权限体系,保证系统的可扩展性。如:张三既是行政,也负责财务工作,那张三就同时拥有行政和财务两个角色的权限。

RBAC1:角色分层模型,RBAC1是在RBAC0的基础上增加了角色分层的概念,引入继承概念,即高层级高的角色可以继承低等级的角色的所有权限。

例如针对销售部门,不同的区域销售经拥有不同的角色,显然全国区经理的权限是不能大于华南区经理的,如果这时候采用RBAC0的方式的话,就有可能出现配置出错的问题,会导致华南区经理拥有了全股区经理都没有的权限。

那如果这时引入RBAC1角色分层,配置好广东区经理的角色外,华南区经理的角色就自动继承了广东区经理的角色,这时候再给华南区经理分配该角色特有的权限就可。

RBAC2:角色限制模型,RBAC2是在RBAC0的基础上增加了对角色的限制,包含基数约束、角色互斥、先决条件、运行互斥等。

  • 基数约束:基数约束是指给一个角色被分配给多少个用户是有上限的,不能无限制的添加,即如果创建了总经理的角色,那这个角色被赋予的用户数是有限的,当超过时,该角色将不能再分配给用户。
  • 角色互斥:角色互斥是指一个用户不可能同时拥有多个互斥的角色,就像财务系统种,一个用户不能同时拥有财务和会计的角色。
  • 先决条件:先决条件是指用户要想获得高层级的权限,必须先拥有低层级的权限,好比如必须先拥有财务助理的权限,才能拥有财务经理的权限。
  • 运行互斥:运行互斥是指使用时只能选择一个角色进行使用,好比如老师和家长,一个用户即可能家长也可能是老师,那在使用时,只能选择使用家长的角色或者时老师的角色,不能2个角色同时使用。

RBAC3:统一模型,基于RBAC0进行设计,同时包含了RBAC1和RBAC2模型的特点。但一般后台系统中,使用RBAC3的情况很少,大部分公司都是采用了RBAC0。

四、用户、角色、权限之间的关系

在讲完了RBAC模型之后,再跟大家分享一下用户、角色、权限以及他们对应的组别。

  • 用户:即系统访问的操作者,可以理解为登录系统的用户;
  • 权限:即被允许访问或某种操作的授权资格,一般可以理解为对系统的增删改查权限;
  • 角色:即具有同类相同操作权限的用户。

例如:用户张三,他在OA系统中被赋予了HR的角色,那他则可以操作【员工入职】的权限。

在某些用户数量或者系统功能复杂的后台系统中,为了方便统一管理,还会引入组的概念,即用户组,权限组,角色组。

  • 用户组:用户的集合。当用户数量较多时,可以给用户进行分组。当公司有新员工入职或者需要给员工分配其他角色时,只需要将用户加入用户组,那么该用户就自动拥有了该用户组的权限,无需再一一设置了。
  • 角色组:角色的集合,当多个角色均需拥有相同的权限时,可以采用角色组,例如行政人员,HR均需看到公司的员工信息,那么此时可以将HR、行政建立一个角色组,再将查看员工信息的权限赋予该用户组,那么用户组内的角色就自动拥有了这些权限。
  • 权限组:权限的集合,可以给权限设置一个权限组,例如可以将查看查看员工业绩、查看客户信息关联成一个权限组,当下次需要给用户赋予权限时,直接选择该权限组即可,就不需要一一去设置多个权限了。

五、总结

1. 根据需要设计用户权限体系

我们应根据公司的实际需要,设计最适合的用户权限体系,不应过分的追求功能的大而全,最适合的才是最好的。

2. 需要考虑使用者的感受

在设计前端样式及使用情况时,需考虑用户的使用成本,应尽可能的确保设计的系统简单通俗易用。

本文由 @Camisha 原创发布于人人都是产品经理,未经作者许可,禁止转载。

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

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

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
海报
评论
评论请登录
  1. 作者微信有吗,希望能交流一下

    来自广东 回复
  2. 角色管理菜单,数据权限单独建一个权限组。用户分别挂角色和数据权限组。这样更加清晰。

    来自中国 回复
    1. 不错的建议,但我们公司规模没那么多,可以不用考虑这个。

      来自广东 回复
  3. 不错👍

    来自广东 回复