记ABAC的落地实践

为什么使用ABAC

一般提到授权，我们就会想到角色（role）。什么样的用户拥有什么样的角色可以怎么操作什么样的资源，这是我们普遍使用的权限系统的模型。这里的角色实质上是包含了一组用户操作资源的规则集合。一旦角色被创建，也就意味着有一组资源操作集合被固化起来，除非去修改角色，否则这个规则集合是不会变的。 比如在一个图书馆的图书管理系统中，所有读者都可以查看书籍及其不同的分类，图书管理员编辑图书信息，管理层可能要看一些图书借阅报表等。这些都可以给读者和图书管理员分配不同的角色就可以实现。在一个较大的图书馆，图书管理员可能分布在不同楼层或者管理不同类别的图书，所以我们需要创建多个图书管理员的角色，比如： 二楼图书管理员，或经济类图书管理员等。更大的图书馆可能会有出版社区分的管理员或者代理人员，因此会有更多基于出版社和图书分类的角色。随着该图书馆的不断扩大，业务职责越来越精细，会继续不断的创建新的角色，比如对于一个出版社在一个楼层的一个特定分类的按照出版时间进行不同角色管理，就会有 “出版社数 x 楼层数 x 楼层图书分类数 x 出版时间分类数” 的角色创建，如此下去，整个系统就会面临“角色爆炸”的窘态。

上述描述的就是基于角色的访问控制，简称RBAC（Role-Based Access Control）它他是一种静态的访问控制模型，主要用于一些基本的简单授权系统中。那如果我们需要更细粒度的访问控制，而又不想面临“角色爆炸”，基于属性的访问控制，简称ABAC（Attribute-Based Access Control）可以是一种选择。在ABAC的模型中没有角色的概念，也就没有“角色爆炸”，它是通过定义一系列的访问规则，利用当前用户操作相关资源的属性，动态的决定用户有没有权限操作该资源。当前著名的AWS IAM就是使用ABAC管理访问控制的，也称PBAC（Policy-Based Access Control）。

ABAC模型和框架

在ABAC的概念模型中，主要包含：

• 访问者（Subject）：指操作的发起者，可能是一个用户，或一个系统。
• 受访者（Object）：指操作的接受者，也就是访问目标资源，例如用户数据等。
• 操作（Operation）：即对受访者的操作，常见的增删改查等。
• 属性（Attribute）：指一组来自访问者，受访者，和操作相关的数据，也包含一些环境上下文数据。
• 策略（Policy）：指可以基于属性动态生成访问控制结果的预定义的一组规则。

但ABAC毕竟只是个模型，要真正实现它，最好依赖于一种成熟的框架。XACML&#