后台系统:基于RBAC模型的权限设计

8 评论 12042 浏览 117 收藏 13 分钟

编辑导语:RBAC是一套成熟的权限模型,在传统权限模型中,我们直接把权限赋予用户。而在RBAC中,首先把权限赋予角色,再把角色赋予用户。本文作者以后台系统为例,以RBAC模型为基础,为我们展示了权限设计的过程。

对于业务复杂或数据庞大的系统,为了方便管理,一定要做权限设计。权限设计是后台系统要考虑的一个授权策略问题。直白的说,权限设计就是根据公司的业务规则,对权限管理系统设置的安全策略。

权限一般分为功能权限,数据权限与菜单权限:

  • 功能权限控制当前账号可以操作的功能按妞,比如风控只能审核标的登记,但不能发起进件申请。
  • 数据权限控制当前账号可以看到的数据范围,比如客服A只能看到分配到她名下的出借人的投资数据。
  • 菜单权限控制当前账号可以看到的页面内容,比如催收人员只能看到案件逾期后流转到催收页面的内容。

后台系统:基于RBAC模型的权限设计

对于权限设计,关键是理清用户、权限、角色三者的关系。即给谁创建账户,分配什么角色,赋予何种权限。

后台系统:基于RBAC模型的权限设计

一、需求背景

权限设计的首要问题是明确需求。权限设计牵涉到后台系统底层架构的业务逻辑,在做后台系统之前,一定要对现有的权限控制和业务情况了解清楚,才能避免在权限设计的问题上踩坑。

以某车贷风控系统为例,我们通过相关业务部门的反馈和当前权限系统的调研,发现它存在的问题有以下几点:

  1. 用户的权限归属不明确,导致进件的申请和审核操作为同一个人;
  2. 敏感数据没有做权限控制和脱敏处理,导致用户隐私数据被泄露;
  3. 角色的分类不合理,每个用户只能配置一个角色,导致工作组和流程节点比较复杂;
  4. 对所属团队的客户经理、团队经理和城市经理做了三级维护关系,但人员调动和离职率较大,导致管理成本高。

了解完现有需求背景后,我们借鉴钉钉的那套权限维护方式,改进了管理系统的权限设计。

一方面收集权限需求,根据部门需求列一份权限清单,并做好CheckList。在模块的功能页面要放置哪些权限,完全可以根据《操作权限申请表》的业务需求,进行灵活的权限配置。

后台系统:基于RBAC模型的权限设计

另一方面借助UML建模的用例图,将角色按功能Uc级细分到增删改查导,方便确认相关人员的操作权限。

后台系统:基于RBAC模型的权限设计

二、设计过程

明确需求后,就要选择合适的权限设计模型。做后台系统权限设计,我们可以借鉴一些控制模型。

常见的权限设计控制模型有:自主访问控制(DAC)、强制访问控制(MAC)、访问控制列表(ACL)、基于角色的访问控制(RBAC) 、基于任务和工作流的访问控制(TBAC) 、基于任务和角色的访问控制(T-RBAC)、基于对象的访问控制(OBAC)、使用控制模型( UCON)、基于属性的访问控制(ABAC)等。

最常见的权限设计控制模型是RBAC模型。像业务复杂且功能庞大的某车贷风控系统,权限设计选择的就是RBAC模型,主要是方便后续的扩展。

RBAC即基于角色的权限访问控制(Role-Based Access Control),在RBAC模型中,权限与角色相关联,用户通过成为对应角色的成员,从而得到这些角色的权限。即用户关联角色,角色关联权限,可实现系统权限的灵活配置。

后台系统:基于RBAC模型的权限设计

访问控制的核心是授权策略。在RBAC模型中,Who、What、How构成了权限控制三要素,也就是Who对What(Which)进行How的操作。

后台系统:基于RBAC模型的权限设计

RBAC的权限授权其实就是Who、What、How的问题。Who:权限的拥用者,What:权限针对的资源,How:具体的权限。在RBAC中,根据权限设计的复杂程度,可分为RBAC0、RBAC1、RBAC2、RBAC3。

RBAC模型包含用户(User)、资源(Resource)、操作(Operation)三个关键要素。通过将资源以及资源操作授权给用户,而使用户获得对资源进行操作的权限,保证了权限分配的实施。

此外,RBAC模型遵循三条安全原则:最小权限原则,责任分离原则和数据抽象原则,从而简化了权限管理。

三、实施过程

选择RBAC模型后,就要从账户、角色、权限三方面考虑实施过程,并满足不同的用户在使用过程中的不同权限需求。

后台系统:基于RBAC模型的权限设计

其中账户和角色关联、角色和权限关联,且都是多对多的关系,我们可以借助UML建模的类图了解三者之间的关系。

后台系统:基于RBAC模型的权限设计

以某车贷风控系统为案例,我们要为某风控A创建一个管理账户,并分配对应的风控人员角色,且在系统拥有访问标的详情权限和操作标的登记权限。

四、账户管理

账户管理的入口在系统管理模块,包括基本的新增账户,编辑账户,删除账户、查看账户、查询账户,以及给账户分配角色。

账号管理是管理员最常用到的功能,相应字段一般是常用字段和特定字段。常用字段比如用户ID,手机号,姓名,角色,状态和注册时间等,特定字段是公司业务需求,比如分配角色,登录时间,登录次数,访问IP,访问设备等。

后台系统:基于RBAC模型的权限设计

管理员在新增账户时,通过给该账户分配风控人员的角色,从而拥有该角色的相关权限。RBAC模型就是通过给用户分配角色,而取得角色的权限,这样就简化了用户权限分配流程。

后台系统:基于RBAC模型的权限设计

五、角色管理

角色管理的入口在系统管理模块,包括基本的新增角色,编辑角色,删除角色、查看角色、查询角色,以及给角色分配权限。

角色管理是用来管理公司内部用户的角色信息。一个复杂的后台会被分割成很多角色,比如管理员、运营人员、客服人员、财务人员、催收人员等。我们可把具有共同特征的某一类人群的身份进行归纳,从而为不同的用户赋予对应的角色权限。

后台系统:基于RBAC模型的权限设计

管理员会根据公司业务需要,新增对应的角色,并给该角色赋予对应的页面权限和操作权限。角色是关联用户和权限的纽带,可以为用户赋予该角色所集成的相关权限。我们在权限拦截流程设计时,就会限制菜单要根据给用户分配的角色填充,只显示该角色可展示的菜单。

后台系统:基于RBAC模型的权限设计

六、权限管理

权限管理的入口在系统管理模块,包括基本的新增权限,编辑权限,删除权限、查看权限,以及给权限状态进行开关。

后台系统:基于RBAC模型的权限设计

任何一个B/S系统或C/S系统都会做权限管理。权限管理限制用户可以访问而且只能访问自己被授权的内容或数据。

管理员在新增权限时,会限定权限性质为基本权限或操作权限。比如用户没有操作权限时,点击按钮会提示无权限,或者按钮置灰不可点击,或者隐藏该操作按钮。

后台系统:基于RBAC模型的权限设计

权限设计是后台系统必不可少的一个环节。基于RBAC模型的权限设计,能支持业务复杂的权限控制,也能满足平台运营的安全策略,增加了权限管理的灵活性与简便化。

#专栏作家#

朱学敏,微信公众号:朱学敏聊产品,人人都是产品经理专栏作家。畅销书《产品闭环:重新定义产品经理》作者,7年金融产品人,专注于金融行业,从0到1负责产品的全过程开发与设计。

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

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

专栏作家

游善朱哥,微信公众号:朱哥聊产品,人人都是产品经理专栏作家。畅销书《产品闭环:重新定义产品经理》和《金融产品方法论》作者,近10年金融产品人,专注于金融行业(贷款、理财、支付)的产品知识分享,从0到1负责多款金融产品的全过程规划与设计。

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

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

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

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 实施过程的第二张图关系画错了,角色表不会直接和用户表关联,而是通过用户角色表关联。
    并不看好RBAC模型,因为用户:角色:权限都是多对多的关系,当后两者数量破百之后,维护是十分困难的,小型系统可以简单应付一下,大型项目还是不要勉强了

    来自四川 回复
    1. 前不久做的项目就是用的这个模型,相较之前直接对帐号去配置权限,这套好使多了,更清晰

      来自湖北 回复
    2. 权限设计相关文章推荐的大多是RBAC的几种模型,那如果是大型项目,大佬推荐使用什么模型呢?

      来自四川 回复
    3. 没有固定模型,根据业务场景定义,不同的产品结构有适配自己的权限模型,得靠产品自己打磨推敲

      来自四川 回复
    4. 本来权限模型就是适配不同的场景 选对了模型 何来勉强

      来自陕西 回复
    5. 模型不是选出来的,思路可以借鉴参考,模型是实打实的基础,RBAC也有好多个变种,别死抠主流模型不放,实际应用时灵活取舍

      来自四川 回复
  2. 第一次看到这个模型RBAC,虽然有些陌生,但是总觉得很全面,加油

    回复
  3. 再接再厉。希望能看到后续该文档的完善

    来自北京 回复