基于RBAC模型的权限设计:如何设计系统权限体系?

26 评论 64736 浏览 259 收藏 9 分钟

RBAC目前使用最为广泛的权限模型,笔者通过平常工作及工作外的积累,整理了几种比较经典的权限体系,希望对大家有所帮助!

一、什么是RABC

RBAC(基于角色的权限控制)模型的核心是在用户和权限之间引入了角色的概念。取消了用户和权限的直接关联,改为通过用户关联角色、角色关联权限的方法来间接地赋予用户权限(如下图),从而达到用户和权限解耦的目的。

RABC的好处

  1. 职能划分更谨慎。对于角色的权限调整不仅仅只影响单个用户,而是会影响关联此角色的所有用户,管理员下发/回收权限会更为谨慎;
  2. 便于权限管理。对于批量的用户权限调整,只需调整用户关联的角色权限即可,无需对每一个用户都进行权限调整,既大幅提升权限调整的效率,又降低漏调权限的概率;

在不断的发展过程中,RBAC也因不同的需求而演化出了不同的版本,目前主要有以下几个版本:

  1. RBAC0,这是RBAC的初始形态,也是最原始、最简单的RBAC版本;
  2. RBAC1,基于RBAC0的优化,增加了角色的分层(即:子角色),子角色可以继承父角色的所有权限;
  3. RBAC2,基于RBAC0的另一种优化,增加了对角色的一些限制:角色互斥、角色容量等;
  4. RBAC3,最复杂也是最全面的RBAC模型,它在RBAC0的基础上,将RBAC1和RBAC2中的优化部分进行了整合;

二、基于RBAC的几种权限体系设计

1、用户-角色-权限

这种权限体系其实就是RBAC0的模式了。这里面又包含了2种:

  1. 用户和角色是多对一关系,即:一个用户只充当一种角色,一种角色可以有多个用户担当;
  2. 用户和角色是多对多关系,即:一个用户可同时充当好几种角色,一种角色可以有多个用户担当;

如上图:对于左边的用户-角色对应,每个人只能同时拥有一种角色,但是同一个角色里边,可能会含有多个用户(如:李四和王麻子都是业务员);而右边的用户-角色对应,是在左边的基础上,增加了一个用户可拥有多种角色的情况(如:小马哥既是经理,也要负责财务的工作);

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

我的建议是:尽量可能地使用多对多的权限体系。如果这个系统的功能比较单一、使用人员较少、岗位权限相对清晰且不会出现兼岗的情况,这种情况也可以考虑用多对一的权限体系。

2、用户-组织-角色-权限

一般公司的业务管理系统,都有数据私密性的要求:哪些人可以看到哪些数据,哪些人不可以看到哪些数据。这个时候,我们就需要把这些东西也考虑到你的权限体系内了。

假设上图是一家公司业务部门的组织架构图,公司要求你基于这个组织架构设计一个业务管理系统,并要求系统需要满足不同用户的数据私密性,比如:“张三”登录时,只能看到“张三”负责的数据;“张三”的领导登录时,能看到“团队A”的所有业务员负责的数据,但看不到其他团队业务员负责的数据等等。

在这种情况下,上一种权限体系就不适用了,但我们可以对其进行一些小改造后,即可达到数据管控的目的,如下图:

在“用户-角色-权限”的基础上,我们增加了用户与组织的关联关系,组织决定了用户的数据可视权限。但要想真正达到这个效果,我们还需要做2件事:

  1. 组织层级划分。如下图,我们需要对组织进行梳理,并划分层级;
  2. 数据可视权限规则制定。比如:上级组织职能看到下级组织员工负责的数据,而不能看到其他平级组织及其下级组织的员工数据等。

通过以上两点,系统就可以在用户登录时,自动判断要给用户展示哪些数据了!

3、用户-组织-岗位-角色-权限

第三种权限体系又是在第二种权限体系上进行优化的,增加了用户与岗位的关联关系,示意图如下:

增加岗位有以下几点好处:

  1. 识别用户的主要身份。一个人可能身兼多职(多个角色),但是他的主要职能是固定的,那怎么告诉系统用户的主要职能是什么呢?答案就是:通过岗位!拿上面的小马哥举例:小马哥虽然身兼经理和财务两种身份,但他的本职工作是“经理”,因此,他的系统岗位应该“经理”。当他登录时,系统会识别他的身份为“经理”,只不过这个“经理”刚好兼具了其他岗位的职能而已;
  2. 通过“组织-岗位”关联,快速甄别用户岗位。公司在不断地发展的过程中,系统的用户角色也会不断增加,当角色达到一定数量以后,管理员每新增一个用户都要花相当的时间去寻找角色。引入岗位后,可将组织和岗位、岗位和角色提前进行关联,配置账号时,管理员只要选定组织,系统就给出与该组织关联的岗位,而这些岗位,又是提前关联好角色的,选择起来,既方便又高效!

三、总结

以上是基于RBAC模型的三种权限体系,不难看出,三种权限体系的本质都是用户和权限进行解耦,以达到权限的灵活运用。

在最后,也给大家留下两个小问题,大家有兴趣的话可以思考下并在评论区写出你的答案哦:

  1. 在不增加“组织”的情况下(即:第一种权限体系),能否达到数据私密性的控制?如何达到?
  2. 在第二种权限体系中,如何做到将“团队A”的员工和管理者设置在同一个组织下,但又能保证员工只能看到自己的数据,而管理者可以看到该团队所有员工的数据?

 

本文由 @没有昵称 原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自unsplash,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 我个人认为两个问题是否可以如下解决:
    1. 采用角色继承的方式,如 经理-》业务员,财务,老板-》 经理,这样建立层级关系,达到数据范围的控制。
    2. 在建立组织架构树时,增加一个【是否管理人员】的标识。在权限验证部分,读取到管理人员标识时,则开放部门权限,否则,只开放个人权限。
    以上仅是针对上述两个问题的粗略思考。

    实际过程中,行数据权限 我认为至少应包括4种模型,(1)所有数据权限 (2)纵向组织架构权限 (3)横向分管范围权限 (4)个人权限

    在提一个小建议,上述文章中,重点描述了 用户,组织,岗位,角色内容,是否忽略了 权限 -》 资源部分内容;即如何定义权限,定义资源;资源包括哪些,如何抽象,如何落地等。

    来自上海 回复
  2. 试着回答两个问题,当作是个人的读后小结吧
    1,可以。方法: 每一条数据对应到具体用户,可以把原来的组织想象成一个用户一个单独的组织。
    2,可以。方法: 按组织取出数据的同时,根据角色筛选。

    RBAC模型中,个人理解其实还有一层,也就是权限的分类:操作权限,资源权限。权限的概念,指的是对某资源(比如页面,按钮,数据库中的某条(某些)数据)是否允许某操作,所以有两个层面的主体:资源与操作。回到最初的用户-权限模型,就是“某一个用户,对某一个资源,允许某一些操作”的集合。然后在这个基础上做分类和解耦

    来自上海 回复
  3. 通过 角色 做权限管理 和 通过 组织的边界在哪?

    来自浙江 回复
  4. 楼主留的2个问题,我觉得是同一个问题。在不引入xx的情况下,实现数据的控制。有一个思路,在用户级,直接设定其上级用户。

    来自江苏 回复
  5. 感谢分享,超级受用。第一点里小标题 “RABC的好处” RBAC RABC我也要看花眼啦 😎

    来自北京 回复
  6. 非常感谢作者的分享!有时间也很想把自己在权限方面的一些心得拿出来跟大家交流,因为在权限管理很重要很重要很重要,开始没设计好,后面迭代起来非常的麻烦。
    1、第一个问题的本质应该是数据权限到底应该如何控制的问题?要给划分数据的范围,就必须给每一条数据打上一个可以用来划分的标识。那到底用什么来做标识,要根据数据划分的需求来分析。文中提到的数据私密性的要求,就很容易让人想到用组织架构。因为每一条数据都是由用户创建的,用户又一定属于某一个组织节点,那数据肯定就一定会有组织节点。有没有应用场景是不需要根据组织架构来划分数据权限的呢?当然有,例如商业地产。数据的管理需求是根据项目来划分的,那就需要我们在做产品设计的时候就考虑到,每一条数据的产生一定是属于某一个项目的。那这时候,就可以根据项目这个标识来划分数据权限的范围。
    2、第二个问题就简单一些,我们首先确认每个用户可以查看哪些组织节点的数据,再加一层控制,可以查看这个节点下面自建的数据还是全部的数据就好了。

    来自广东 回复
    1. 您好,我是做公寓租赁管理系统的,和您比较像,想请教您一个问题。数据权限的确是根据项目(或者楼栋)来划分的,但系统不同模块的数据是有公私之分的,例如:
      1.客户管理模块,同项目的两个招商人员各自只能看到自己的客户,而招商主管可以看到项目的所有客户,如何在后台配置呢?
      2.房源&合同管理模块,同项目的两个运营人员都可以看到该项目的所有房源和合同,但是只能编辑和修改自己录入的合同,这个要怎么配置呢?

      来自广东 回复
    2. 😐

      来自北京 回复
    3. 像这种情况应该不需要设置。角色这块已经固定了。
      1.后台只需要根据角色加上条件去查就行了。
      2.合同都有一个录入人,前台做判断看运营人员和录入人员是否同一人就行啊。

      来自北京 回复
    4. 你说的非常好!厉害

      来自广东 回复
  7. 1:我对于作者问的第一个问题其实不是很清晰。
    2:RABC模型的解释是 基于角色的权限控制,所以我们可以在角色这里思考。建立角色组和父子角色概念,对于一个团队而言,每个成员有一个或多个角色,把每个成员的角色归属到一个角色组里面,在把角色组给团队leader,leader就拥有整个团队的权限。应为作者说 了这里是团队的 leader和团队成员是属于同级组织里面。当我们的组织结构树往上走的时候,当为这个管理几个团队的领导奉陪权限的时候,我们就可以引入父子角色概念。

    来自北京 回复
  8. “比如:上级组织职能看到下级组织员工负责的数据,而不能看到其他平级组织及其下级组织的员工数据等。”这一句的后半句是不是应该为“及其上级组织员工” ?

    来自北京 回复
    1. 【其他平级组织及其下级组织的员工数据】这个是一句话

      来自陕西 回复
  9. “比如:上级组织职能看到下级组织员工负责的数据,而不能看到其他平级组织及其下级组织的员工数据等。”这一句的后半句是不是应该为“及其上级组织员工” ?

    来自北京 回复
  10. 感谢作者的分享~

    回答一下上面的问题:我的理解,问题一和问题二都是把团队的员工和该团队的管理者放在了一个目录下,普通员工只能看到自己的数据,而管理者可以看到该团队的数据,我想应该建一个“管理者”的角色,配置到团队,即有该角色的用户就可以查看对应团队所有数据的权限,否则只能查看自己的数据。

    来自北京 回复
    1. 数据权限与角色是无关的。角色是控制操作权限的,组织是控制数据权限的

      来自广东 回复
  11. 我做的也是RBAC的改进,不过我设计的是将权限分为操作权限和资源权限,操作权限的集合即为角色,资源权限的集合为职位,角色表示了该角色的用户所能进行的操作,职位表示该用户所能操作的资源,职位相当于每一个权限所对应的资源列表。
    问题一:权限在定向图中从上向下流动,上级角色为父角色,下级角色为子角色,权限由父角色为子角色分配。相同角色的用户拥有不同职位,实现数据私密性。
    问题二:我觉得组织机构和权限系统是分开的,因为父子角色已经可以实现子角色的权限是父角色的子集,同时还能实现当有多个上级时,每个上级的权限都只能看到自己能管理的数据,无法看到子角色所有数据。

    来自浙江 回复
    1. 有这样一个场景,若几个相同职位的人,写了同一份资源列表,如何管理他们使得他们只能看到列表中自己创建的那部分资源数据。这才是数据权限问题,因此其实你对数据权限和操作权限的理解有误

      来自广东 回复
    2. 是的,17年的时候对这块了解不够深入。问题二现在想想也只有在组织上再加一层控制,管理员数据权限等于组织,其他用户的数据权限除了自己建的以外需要管理员授权

      来自上海 回复
  12. 写得很通俗易懂,受用

    回复
  13. 感谢作者的分享~
    小答一下两个问题:
    问题一:可以达到。如果没有“组织”,可以根据需求在权限部分建立子分类,比如编辑权限下可以分为编辑A区域内容、编辑B区域内容。
    问题二:这个问题没太明白作者的意图,因为在文章中已经提到了答案——设定数据可视权限规则

    来自北京 回复