ABAC访问控制模型

一、什么是ABAC访问控制模型

基于属性的访问控制（Attribute-Based Access Control，下文简称ABAC）是一种灵活的授权模型。是通过实体的属性、操作类型、相关的环境来控制是否有对操作对象的权限。

例如：P5（职级）的同学有OA系统的权限。

上述是一个简单的ABAC的例子，就是通过实体的职级这一属性来控制是否有OA系统的权限

再比如：P5（职级）的研发（职位）同学有公司Gitlab的权限

上述例子是通过一组实体的属性（职级和职位）来控制对操作对象的权限

再比如：P5（职级）的研发（职位）同学在公司内网（环境）可以查看和下载（操作）代码。

上述例子显然比之前两个更加复杂，除了判断实体的属性（职级和职位），还判断了当前的环境属性和操作属性

所以我们可以ABAC的访问控制模型用下面这张图表现出来

 

ABAC的使用场景

ABAC授权模型理论上能够实现非常灵活的权限控制，几乎能满足所有类型的需求。从使用场景来说比较适用于用户数量多并且授权比较复杂的场景。简单的场景也是可以使用ABAC的，但是使用基础的ACL或者RBAC也能满足需求。

场景一：

还是拿上面的例子来说：P5（职级）的研发（职位）同学在公司内网（环境）可以查看和下载（操作）代码。

在需要根据环境属性和操作属性来动态计算权限的时候，使用其他的授权模型可能不太能满足需求。这个时候就需要使用ABAC授权模型。

场景二：

ABAC也适用于公司成员（角色）快速变化的场景，由于ABAC 是通过用户的属性来授权的。在新建用户/修改用户属性时会自动更改用户的权限，无需管理员手动更改账户角色。

在属性的组合比较多，需要更细粒度地划分角色的情况下。RBAC需要建立大量的角色。ABAC授权模型会更加灵活。

二、与RBAC访问控制模型的对比

ABAC对于RBAC有以下优点

• 对于大型组织，基于RBCA的控制模型需要维护大量的角色和授权关系，相比而言，ABAC更加灵活；对于中小型组织，维护角色和授权关系的工作量不大，反而定制各种策略相对麻烦，更容易接受RBAC授权模型。
• 新增资源时，ABAC仅需要维护较少的资源。而RBAC需要维护所有相关的角色。ABAC可扩展性更强、更方便。
• RBAC支持带有动态参数的授权规则，RBAC只能基于静态的参数进行判断。
• ABAC权限控制的粒度比RBAC更细。
• 补上RBAC的另外几种延伸形式
  1、RBAC-1
  RBAC1引入角色间的继承关系，角色间的继承关系可分为一般继承关系和受限继承关系。一般继承关系仅要求角色继承关系是一个绝对偏序关系，允许角色间的多继承。而受限继承关系则进一步要求角色继承关系是一个树结构。
  2、RBAC-2
  RBAC2模型中添加了责任分离关系。RBAC2的约束规定了权限被赋予角色时,或角色被赋予用户时,以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。
  责任分离包括静态责任分离和动态责任分离。

  静态责任分离
  1、互斥角色限制：同一个用户在两个互斥的角色中只能选择一个
  2、角色数量限制：一个用户拥有的角色数是有限的，同样的权限也会是有限的
  3、角色先后限制：用户要拥有更高级的角色，首先要有相应的低级角色
  动态责任分离
  4、角色激活限制：如一个用户允许拥有两个角色，但运行时只能激活一个角色

  约束与用户-角色-权限关系一起决定了RBAC2模型中用户的访问许可。

  3、RBAC-3
  RBAC3包含了RBAC1和RBAC2，既提供了角色间的继承关系，又提供了责任分离关系。