架构思考|基于 RBAC 权限设计四点总结

Posted 2021-05-01 企业架构设计

今天刚好在做一个平台权限相关模块的设计，对RBAC权限设计来一个思考总结。

①RBAC的理解

1.是什么？基于角色的权限访问控制即Role-Based Access Control。

2.基本原则:支持三个重要的安全原则：最小权限原则，责任分离原则和数据抽象原则。

3.RBAC实际上是Who、What、How的问题。在RBAC模型中，Who、What、How构成了权限控制三要素,也就是Who对What(Which)进行How的操作。

Who：权限的拥用者或主体如Principal、User、Group、Role、Actor等等。

What：权限针对的对象或资源Resource、Element。

How：具体的权限如Privilege,还包括正向授权与反向授权。

②功能权限

用一个permission表示What、How。

优点：当系统比较简单，对对象（What）只有一个操作(How)时比较适用。

缺点：复杂系统以及需要对系统进行精度较高权限控制比如数据权限时不太好维护，构造元数据以及授权将成为负担。

1个How+1个What场景：生成一个权限，如PC创建应用。

多个How+1个What场景：生成多个权限,如多端创建应用。

多个How+多个What场景：生成多个权限，笛卡尔积。

n个How+n个What场景：数据爆炸。

问题来了，每个权限都涉及运维即创建、更新删除以及授权即授予、回收用户权限过程，数据爆炸给这些过程带来更复杂的系统交互和管理工作量。

③数据权限

明确使用操作表示How、数据模型表示What。数据模型由属性组成，支持复杂数据管理组合。属性定义数据来源和形式，支持各种类型的数据源。

优点：能够支持精度较高权限管理。

缺点：需要一些学习成本。

④数据权限设计

方案：将数据权限抽象为操作和数据两部分，即数据权限＝操作＋数据(模型)。

操作

How元素的定义，可以具体的成为CRUD等行为。

数据模型

What元素的定义，由属性组成，是对数据或者数据结构的封装和抽象。

数据权限需要处理几类数据（What）管理场景：

1、具体数据管理：授权指定具体的数据值。

2、数据分类管理：通常为管理海量数据产生，需要提前给数据做好分类，授权时授予用户分类。由于分类可以有多种，每个属性代表&封装一个分类的值选项，所以可能有多个属性，数据模型聚合多个属性成为一个可管理的对象，以便进行高级设置。

3、打标：为用户（Who）定义授权相关的属性，授权时设置用户(Who)各个属性值，验权时调接口获取用户属性值进行权限控制，属性标记值对应权限由应用自己解释。

场景1通常只包含一个属性，可以忽略数据模型的理解和建立。数据模型的存在主要是为了支持2、3等更复杂场景。

属性

数据池一般存在定义了对象（What）包含哪些数据、分类、标记等可以进行授权。属性带有“类型”属性，为平台后续扩展提供无限空间，常用的需要平台支持的类型：

1、枚举：保存在权限管理平台的申请、授权时通过列表形式展现的数据。

2、字符串：申请、授权时文本类型展现的数据。

3、外部数据源：可配置的申请、授权时列表、树形展示的数据。数据来自应用，用户申请、授权时候会调应用接口实时查询数据，数据不在权限平台落地，所以没有数据同步过程。外部数据源支持http,rpc两种类型，满足大多数应用的需求。

总结： 数据权限为RBAC模型中的What和How提供了明确的支持，能够支持更复杂、精度要求更高的权限控制。