权限管理中的RBAC与ABAC

最早的模型

最早最基础的权限管理模型是ACL,也就是Access Control List(访问控制列表)。
它是用来描述用户和权限之间关系的数据列表。它的原理非常简单:每一项资源,都配有一个列表,这个列表记录的就是哪些用户可以对这项资源执行CRUD等操作。当试图访问这项资源时,会首先检查这个列表中是否有关于当前用户的访问权限,从而确定当前用户可否执行相应的操作。
ACL几乎不需要任何基础设施就可以完成访问控制,这是他的简单性,也是他的优点。
但由于需要维护大量的访问权限列表,ACL在性能上有明显的缺陷。另外,对于拥有大量用户与众多资源的应用,管理访问控制列表本身就变成非常繁重的工作。

最开始的ACL定义中,用户直接和权限挂钩,数据存储的是用户与权限的关联关系。如果两个用户的权限是一样的,那么就需要分别存储这两个用户与权限的关联关系,也是上面所提到的ACL的缺陷。为了解决这些问题,便有了对ACL设计的改进,相同权限的用户放到同一个分组里,分组与权限挂钩,不再是用户直接与权限挂钩。以及后来出现的RBAC(基于角色的访问控制),角色与分组也是差不多的概念,角色直接与权限挂钩,用户再与角色进行关联。

RBAC(Role-Based Access Control 基于角色的访问控制)

ACL的访问控制机制中,直接维护的是用户与功能的关系,这一系列的关系就是一个权限列表。当很多的用户具有相同功能权限的时候,就要进行繁琐的关联操作。RBAC就是在用户与权限之间引入了角色的概念。用户与角色之间做关联,权限列表维护的是角色与功能的关系。

一个用户拥有若干个角色,每个角色拥有若干个权限,这样就构成了“用户-角色-权限”的授权模型。这种授权模型的好处在于,不必每次创建用户时都进行权限分配的操作,只要分配用户相应的角色即可,而且角色的权限变更比用户的权限变更要少得多,减少频繁设置。

在RBAC模型中,“用户-角色-权限”之间形成的关系是一个双向的”一对多“的关系。
也就是说,一个用户可以拥有多个角色,一个角色可以赋给不同的用户;一个角色可以拥有多个权限,一个权限也可以被多个角色拥有
在这里插入图片描述

角色的引入,可以让具有相同权限汇集到一起,再将不同角色分配给不同的用户,以此来实现用户对于权限的分配。这样只需要在首次给不同的角色配上相应的权限,后续添加的用户就可直接赋予角色,便可添加上所需要的权限如此一来大大减少了操作的频繁性。

在后续的发展中,我们发现 单单在用户和权限中引入角色,对于大数据量的角色和权限的分配,还是具有相当的复杂度。如果一个部门上万人,那么我们就需要给这个部门上万人分别设置角色,而这上万其实是具有相同的权限的,如果直接采用基础的RBAC权限模型的话,那么面对这样的情况,无疑也是具有一个庞大的重复的工作量,并且也不利于后期用户变更的维护管理。

于是我们可以再在用户与角色之间引入”部门“的概念。
所谓”部门“就是将具有相同角色的用户进行分类,从而形成用户组的概念。
如此一来,我们将具有相同角色的用户归到一起,形成一个用户组,也就是一个”部门“,由此进行批量的调度和权限的管理,可以大大提高分类的清晰程度和我们工作的效率。

给具有相同权限的用户建立用户组,将用户组关联到对应的角色下,此用户组就拥有了此角色下的所有权限,而用户是属于用户组的,所以用户组下的所有用户也就同样的拥有了此角色下的所有权限。一个用户可以属于多个用户组,一个用户组也可以包括多个用户,所以用户与用户组是多对多的关系。

在这里插入图片描述

RBAC级别

RBAC0 用户和角色是多对多,角色和权限是多对多。一个用户拥有的权限,是他所有角色的集合。
RBAC1。基于RBAC0,并引入了角色分层的概念,即一个角色分为多个等级,每个等级对应的权限是不一样的。把权限分给用户时,需要分到对应的角色等级。角色等级低时拥有的权限少,角色等级高的权限是所有角色等级低的权限的集合。

RBAC2 基于RBAC1,对角色访问进行限制。如
互斥角色限制。同一个用户分配到两个角色,且角色互斥时,那么系统应该提醒只能选择其中一个角色。比如员工拥有商务这个角色,可以创建结算单并提交给财务审核,这时,就不能赋予这个员工财务角色,否则他就自己提交结算自己审核结算单了。
角色数量限制。一个用户拥有的角色数量是有限的;一个角色被分配的用户数量也是有限的。
先决条件限制。用户想获得某个上级角色,必须先获得其下一级的角色。比如想获得产品总监的权限,那就需要从产品助理这一角色开始,再到产品经理角色,最后到产品总监角色。

RBAC3 基于RBAC0,对RBAC1和RBAC2进行了整合,是最全面的权限管理。 用户组
当平台用户的基数增大,角色类型越来越多时,而且一部分人具有相同的属性,比如财务部的所有员工。

ABAC(Attribute-Based Access Control 基于属性的权限验证)

ABAC被称为是权限系统设计的未来。

在结构化语言中使用属性作为构建基石来定义并实施访问控制,提供上下文相关的细粒度动态访问控制服务。ABAC是一种为解决行业分布式应用可信关系访问控制模型,也表示词语的一种构成形式。

ABAC是一种为解决行业分布式应用可信关系访问控制模型,它利用相关实体(如主体、客体、环境)的属性作为授权的基础来研究如何进行访问控制。基于角色的访问控制(RBAC)通过引入角色中间元素,使得权限先经过角色进行聚合,然后再将权限分配给主体,通过这种方式可以简化授权,可将角色信息看成是一种属性,这样 RBAC 就成为了ABAC 的一种单属性特例。

在ABAC中,主体是对客体(资源)实施访问行为的实体,如用户、服务、通信实体等;

主体有定义其身份和特性的属性,包括主体的身份、角色、职位、能力、位置、行政关系以及CA
证书等,如用户这一主体,它可以以所处行业中用户属性特征为基础,将这些用户的某些属性进行标准化定义,包括某用户所属的部门、职务、主管业务等;

客体是被主体操作的实体,如文件、数据、服务、系统设备等,客体属性包括身份、位置(URL)
、大小、值,这些属性可从客体的“元数据”中获取,同样也可以由对其操的主体来继承。这就是说,客体属性与主体属性具有一定的相关性;
环境属性是与事务(或业务)处理关联的属性,它通常与身份无关,但适用于授权决策,如时间、日期、系统状态、安全级别等。

ABAC授权模型理论上能够实现非常灵活的权限控制,几乎能满足所有类型的需求。从使用场景来说比较适用于用户数量多并且授权比较复杂的场景。

举个例子:

P5(职级)的研发(职位)同学在公司内网(环境)可以查看和下载(操作)代码

这个例子中的”职级“”职位“”环境“”操作“,就是实体的属性、操作类型、相关的环境,根据这四点来判断,此时该用户是否有某些权限。
比如同样是在内网,这个开发同学有权限操作代码,而运营同学没有这个权限;或者同样是这个开发同学,他在内网有操作代码的权限,而在公司外没有这个权限。

通俗的讲,就是对用户实体的实体属性(比如工号,职级,职位等)、环境属性(IP、时间、地点等)、操作树形(增加、删除、修改、查看等),来计算出当前用户是否有权限。

如何选择

在这里,组织的规模是至关重要的因素。由于ABAC最初的设计和实施的困难,对于小型企业而言,可能太过复杂了。

对于中小型企业,RBAC是ABAC的简单替代方案。每个用户都有自己的角色,并具有相应的权限和限制。当用户转移到新角色时,其权限将更改为新职位的权限。这意味着,在明确定义角色的层次结构中,可以轻松管理少量的内部和外部用户。

但是,当必须手动建立新角色时,对于大型组织而言,效率并不高。一旦定义了属性和规则,当用户和利益相关者众多时,ABAC的策略就更容易应用,同时还降低了安全风险。

简而言之,如果满足以下条件,就选择ABAC:

  • 你在一个拥有众多用户的大型组织中;
  • 你需要深入的特定访问控制功能;
  • 你有时间投资远距离的模型;
  • 你需要确保隐私和安全;

但是,如果满足以下条件,请考虑RBAC:

  • 你所在的是中小型企业;
  • 你的访问控制策略广泛;
  • 你的外部用户很少,并且你的组织角色得到了明确定义;

参考文章:

https://baike.baidu.com/item/abac/3555041?fr=aladdin
https://blog.csdn.net/qq_31960623/article/details/120528589
https://blog.csdn.net/zl1zl2zl3/article/details/82968140?spm=1001.2101.3001.6650.1&utm_medium=distribute.pc_relevant.none-task-blog-2%7Edefault%7ECTRLIST%7Edefault-1-82968140-blog-120528589.pc_relevant_default&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2%7Edefault%7ECTRLIST%7Edefault-1-82968140-blog-120528589.pc_relevant_default&utm_relevant_index=2
https://blog.csdn.net/hi_bigbai/article/details/120868485?spm=1001.2101.3001.6650.2&utm_medium=distribute.pc_relevant.none-task-blog-2defaultCTRLISTdefault-2-120868485-blog-82968140.pc_relevant_aa&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2defaultCTRLISTdefault-2-120868485-blog-82968140.pc_relevant_aa
https://www.jianshu.com/p/32e548fbba35
https://blog.csdn.net/qzw752890913/article/details/124461952
https://blog.csdn.net/qq_46311811/article/details/122444864?spm=1001.2101.3001.6650.6&utm_medium=distribute.pc_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromBaidu%7Edefault-6-122444864-blog-124461952.pc_relevant_default&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromBaidu%7Edefault-6-122444864-blog-124461952.pc_relevant_default&utm_relevant_index=9
https://juejin.cn/post/6844904056876433416#heading-12

  • 5
    点赞
  • 23
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值