权限管理中的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