基于RBAC模型的数据权限控制设计

在项目实际开发中我们不光要控制一个用户能访问哪些资源,还需要控制用户只能访问资源中的某部分数据。

控制一个用户能访问哪些资源我们有很成熟的权限管理模型即RBAC,但是控制用户只能访问某部分资源(即我们常说的数据权限)使用RBAC模型是不够的,本文我们尝试在RBAC模型的基础上融入数据权限的管理控制。

首先让我们先看下RBAC模型。

RBAC模型

RBAC是Role-BasedAccess Control的英文缩写,意思是基于角色的访问控制。

RBAC事先会在系统中定义出不同的角色,不同的角色拥有不同的权限,一个角色实际上就是一组权限的集合。而系统的所有用户都会被分配到不同的角色中,一个用户可能拥有多个角色。使用RBAC可以极大地简化权限的管理。

RBAC模型还可以细分为RBAC0,RBAC1,RBAC2,RBAC3。这里我们不讨论他们之间的差异,感兴趣的同学可以自行研究,我们主要聚焦于常见的RBAC0模型上。

如下图就是一个经典RBAC0模型的数据库设计。

rbac0模型

在RBAC模型下,系统只会验证用户A是否属于角色RoleX,而不会判断用户A是否能访问只属于用户B的数据DataB。这种问题我们称之为“水平权限管理问题”。

数据权限

列表数据权限,主要通过数据权限控制行数据,让不同的人有不同的查看数据规则;要实现数据权限,最重要的是需要抽象出数据规则。

数据规则

比如我们系统的商机数据,需要从下面几个维度来控制数据访问权限。

  1. 销售人员只能看自己的数据;
  2. 各大区的销售经理只能看各区域的数据(安徽大区的销售经理看安徽区域的商机数据),同理也适用于某BG分管领导只能看所在BG的商机数据;
  3. 财务人员只能看金额小于一万的数据。

上面的这些维度就是数据规则。

这样数据规则的几个重点要素我们也明晰了,就是规则字段,规则表达式,规则值,上面三个场景对应的规则分别如下:

  1. 规则字段:创建人,规则表达式:= ,规则值:当前登录人
  2. 规则字段:所属大区,规则表达式:= ,规则值:安徽大区
  3. 规则字段:销售金额,规则表达式:< ,规则值:10000

数据规则规则字段配置说明:
条件表达式:大于/大于等于/小于/小于等于/等于/包含/模糊/不等于
规则值:指定值 ( 固定值/系统上下文变量 )

关联资源、用户

光有数据规则是不够的,我们还需要把数据规则跟资源和用户进行绑定。

数据规则与资源的绑定很简单,我们只需要建立一个中间表即可,如下图所示:

关联资源与用户

这样资源就可以关联上了数据规则。

在应用设计上我们需要一个单独的数据规则管理功能,方便我们录入数据规则,然后在资源管理页面(比如商机列表)上就可以选择内置的数据规则进行资源与规则的绑定。

那么如何让不同的用户拥有不同的数据规则呢?

在RBAC模型中,用户是通过授予不同的角色来进行资源的管理,同理我们可以让角色在授予权限的时候关联上数据规则,这样最终在系统上就体现为不同的用户拥有不同的数据规则。

有点拗口,我们还是按上面的例子来说。

销售人员、大区销售经理、财务人员属于不同的角色,他们都拥有商机列表这个资源权限,但是在给这些角色绑定商机列表资源权限时我们可以勾选对应的数据规则(上面已经实现资源与数据规则的绑定)。体现在数据库设计中我们可以在角色资源对应关系表 Role_Permission中添加一个字段用于存储关联的数据规则,如果有多个数据规则可以使用分隔符分割。

最终RBAC模型演变成如下所示的模型:

按照上面的设计我们需要区分各个大区管理的数据权限则需要建立不同的大区角色,如安徽大区销售经理、上海大区销售经理,然后分别给角色勾选对应的数据规则。这里就类似于RBAC1中的角色继承的概念了。

这样我们就基本实现了RBAC与数据规则的绑定,但是我们还有个问题就是如何在系统中落地。

这里我们就要借助大名鼎鼎的AOP来实现了,这篇文章只讲原理不讲实现,所以我们只顺带提一下实现方案。

  1. 自定义一个数据权限的注解,比如叫PermissionData
  2. 在对应的资源请求方法,比如商机列表上添加自定义注解@PermissionData
  3. 利用AOP抓取到用户对应角色的所有数据规则并进行SQL拼接,最终在SQL层面实现数据过滤。

继续优化

在上面的设计中我们通过给不同角色绑定不同数据规则实现了数据权限,但是考虑下面一种场景:某角色需要看到的数据范围为 “所属大区为安徽大区且事业部为消费者事业部的商机数据”,在这种场景里按照我们之前的设计需要建立两个数据规则:

  1. 所属大区 = 安徽大区
  2. 所属事业部 = 消费者事业部

然后再建立2个不同的角色,分别授予不同的数据规则,如果这样的场景比较多的话很容易出现角色爆炸的情况,所有我们这里再抽取出 数据规则组的概念。

一个数据规则组有多个数据规则,数据规则之间通过 AND 进行连接,放一张应用设计图:

数据规则

体现在数据库设计中就变成了如下所示:

小结

通过上面8张表的设计我们实现了RBAC模型与数据权限的结合,当然这里还有继续优化的空间。比如这里的规则字段和规则值我们可以抽取出对应的字典表,让数据规则表去关联这些字典字段,这样在应用层配置数据规则的时候就不需要管理员手动填写而是从字典项中去选择了,减少了数据规则配置出错的概率。

  • 24
    点赞
  • 28
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
提供的源码资源涵盖了安卓应用、小程序、Python应用和Java应用等多个领域,每个领域都包含了丰富的实例和项目。这些源码都是基于各自平台的最新技术和标准编写,确保了在对应环境下能够无缝运行。同时,源码中配备了详细的注释和文档,帮助用户快速理解代码结构和实现逻辑。 适用人群: 这些源码资源特别适合大学生群体。无论你是计算机相关专业的学生,还是对其他领域编程感兴趣的学生,这些资源都能为你提供宝贵的学习和实践机会。通过学习和运行这些源码,你可以掌握各平台开发的基础知识,提升编程能力和项目实战经验。 使用场景及目标: 在学习阶段,你可以利用这些源码资源进行课程实践、课外项目或毕业设计。通过分析和运行源码,你将深入了解各平台开发的技术细节和最佳实践,逐步培养起自己的项目开发和问题解决能力。此外,在求职或创业过程中,具备跨平台开发能力的大学生将更具竞争力。 其他说明: 为了确保源码资源的可运行性和易用性,特别注意了以下几点:首先,每份源码都提供了详细的运行环境和依赖说明,确保用户能够轻松搭建起开发环境;其次,源码中的注释和文档都非常完善,方便用户快速上手和理解代码;最后,我会定期更新这些源码资源,以适应各平台技术的最新发展和市场需求。
RBAC(Role-Based Access Control)是一种权限管理模型,它是建立在角色的基础上,将用户分配给角色,再根据角色的权限授予对应的资源访问权限。这种模型可以有效地管理大规模应用系统中的权限问题。下面是基于RBAC权限管理系统的设计分析: 1.确定系统需求:首先要确定系统的具体需求和功能,包括用户界面、权限设置和管理、角色管理、资源管理等方面。同时需要明确系统的主要目标是什么,以便在设计时保持一致性。 2.确定角色:根据系统需求,确定所需要的角色类型和数量,包括系统管理员、普通用户等。在设计时应该合理分配权限,避免角色间权限重叠或漏洞。 3.确定资源:确定系统中的资源,包括数据、程序、文档等,依据资源的重要性和保密性进行分类,在角色分配时考虑资源所属角色的权限。 4.权限授予:根据角色的不同,授予对应的资源访问权限,包括读取、修改、删除等。在授予权限时要严格按照角色的权限定义进行操作,避免数据泄漏和滥用。 5.权限审核:对所有权限的修改和删除操作进行记录和审查,定期对权限进行审核,保证系统的安全性和稳定性。 6.权限维护:系统上线后,需要对权限进行维护和更新,包括新增角色、修改权限、删除角色等操作,同时定期对系统进行安全检查和修复漏洞。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值