关于 RBAC 和 ABAC 两种权限设计的优缺点

date

Jun 10, 2021

slug

advantage-and-disadvantage-of-two-access-control-modes

status

Published

summary

基于角色的访问控制（RBAC）和基于属性的访问控制（ABAC）是目前被广泛采用的两种权限设计方法。

RBAC

基于角色定义，简单来说就是权限→角色→用户，角色是用户和权限之间的关联主键，用户通过角色关联权限。

下面一个例子：

该自然人的权限为

优点

稳定：从管理角度出发，角色是为了解决特定问题而被创造的，也就是解决分工问题，而用户的变动几率比系统里的角色大多了，角色这一定义相对会更加稳定一些。

简单：用户与权限的逻辑分离，使得权限只和角色相关。而根据上文，角色是被相关干系人或行业直接创造出来的，以角色为核心的权限管理体系的理解成本和学习成本相对于新造概念会少上很多，非常利于在内部推广。

缺点

从管理角度出发，角色是为了解决特定问题而被创造的，也就是解决分工问题，而自然人的变动几率比系统里的角色大多了，角色这一定义相对会更加稳定一些。

这一优点实际上也带来了缺点，现实生活中人是不稳定的，在 RBAC 中通常表现为一个人关联了多个角色，这样就给角色管理带来了很大的难题，尽管有权限继承、角色互斥等等办法提高角色管理的效率，但是在面对以下难题时依然束手无策：

产品经理Ａ拥有产品相关权限，但是由于最近在负责业务Ｂ，需要获取Ｂ的临时权限；这个时候需要新增一个角色；

产品经理 C 需要业务 D 中一个单独后台页面的查看和修改权限；这个时候也需要新增一个角色

新增资源时，需要维护所有与之相关的角色，维护起来费时费力，而且角色是一个相对静态的权限定义，如果需要把一个流程权限化：

运营 A 创建了兑换码后，产品 B 才能去看兑换订单的详情数据

像这样一类权限获取，是 RBAC 所不支持的。

与最小权限原则冲突——用户应该仅能访问其工作所需的资源和服务，拥有既不超过也不低于完成工作所需的管理权限。过度预配访问权限可能会增加内部人员威胁、资源配置错误以及难以进行审核跟踪的风险。如果权限预配不足，则用户可能无法访问完成任务所需的资源——如果严格按照最小权限原则，将会让角色爆炸这个问题更加严重

ABAC

基于操作属性确定一个操作是否被允许；操作可以是删除、访问等等，属性需要预先定义：

对象：用户 ID、用户职位、部门、入职时间、是否通过试用期等等

资源：资源创建日期、资源最新更新时间、资源类型（文件、订单详情数据）、资源分类（订单管理、文章管理等）等

操作：新增、查看、删除等

环境：IP 地址、时间等

上图是一个产品经理查看订单数据的场景，换成大白话来说就是一个工作 3 年的中级产品经理可以在工作时间内通过内网查看订单的数据。

当然，看起来还是有点复杂，再举一个简单的例子：

初级前端工程师（对象）可以下载（操作）内网中的（环境）GitLab 前端源代码（资源）

这样应该就清晰多了。

优点

颗粒度小：由于其基于属性组合确定权限的逻辑设计，ABAC 理论上能够实现非常小颗粒度的权限控制，同时也几乎能够满足所有需求；

灵活：非常适用于公司成员（角色）快速变化的时候，此时并不需要修改角色信息，只有修改一下对应账户的属性就能非常便捷地适配新的权限。

示例：K8s 的 ABAC 权限控制

缺点

策略定制比较麻烦，这点有些类似于 RBAC 的角色维护，但是两者在不同规模的公司里会有一些差异。在中小规模公司，角色的维护会比策略的定制更加方便，毕竟人数也不多。而对于大型公司，大型跨地区公司，大型跨国公司，由于人员、空间、时间等等各种问题，维护角色反而是比策略定制更加麻烦。

另外就是安全和统计问题，ABAC 是灵活的，但同时也是复杂的。我们很难说一个账户永远不能访问某项资源，除非我们了解资源相关的所有策略，因此在完整搭建起了复杂的 ABAC 权限系统后要确定一个账户是否完全没有某项资源的权限是比较困难的。

最后是性能，ABAC 的一系列优点都是建立在占用更多性能的前提下，而有些时候系统的响应速度和稳定性是相当重要的，如何在复杂的 ABAC 策略下，保持相对不错的性能和稳定性也是很重要的。