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

产品经理就业特训营,专门为大学生和准备转型做产品的人量身定制,60天线下培训,包就业!了解详情

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协议

赞赏是对原创者的最大认可
5人打赏
评论
欢迎评论,与我交流
  1. 感谢作者的分享~

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

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

    回复
  3. 写得很通俗易懂,受用

    回复
    1. 谢谢!

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

    回复
    1. 感谢回答!
      关于问题一,我有个问题:你这边的A区域内容和B区域内容是静态的还是动态的?且他们的规则是怎样的?
      关于问题二,可能我没有表达清楚:假设“王小二”是团队A的leader,那么在他与“张三”在同一组织的前提下,你如何为他们设置规则,使“王小二”可以看到团队A成员的数据,但“张三”只能看到自己的数据;

      回复
    2. 为王小二分配团队A组织下的管理员角色,为张三分配团队A组织下的普通角色?

      回复