RBAC 模型梳理

cliffordl

已于 2024-06-07 11:24:47 修改

阅读量1.2k

点赞数 22

分类专栏： python 文章标签： python

于 2024-06-07 11:19:48 首次发布

本文链接：https://blog.csdn.net/cliffordl/article/details/139518663

版权

python 专栏收录该内容

19 篇文章 0 订阅

订阅专栏

1. RBAC 模型是什么

RBAC（Role-Based Access Control）即：基于角色的权限控制。通过角色关联用户，角色关联权限的方式间接赋予用户权限。
RBAC 模型由 4 个基础模型组成：

基本模型 RBAC0（Core RBAC）
角色分层模型 RBAC1（Hierarchal RBAC）
角色限制模型 RBAC2（Constraint RBAC）
统一模型 RBAC3（Combines RBAC）
RBAC 授权的过程可以抽象概括为：判断 Who 是否可以对 What 进行 How 的访问操作，以及这个逻辑表达式的值是否为 True 的计算过程。
Who、What、How 构成了访问权限三元组，Who 是权限的拥有者或主体（User、Role），What 是资源（Resource），How 是具体的权限。

1.1. 基本模型 RBAC0

RBAC0 是最基础也是最核心的模型，由五部分组成：用户（User）、角色（Role）、许可（Permission）、会话（Session）、操作（operations OPS）。
在这里插入图片描述
角色通过权限（许可）被授权资源，角色又授权到用户身上，通过会话管理用户和角色的授权关系，用户就继承了角色的访问资源权限。
我们举一个很简单的例子，例如：张三是一家企业的财务总监，同时他也是该企业对外的形象大使，财务总监有访问公司财务数据的权限，形象大使有访问公司市场部推广计划和编辑发言稿的权限。那么张三既有访问公司财务数据的权限，又有访问公司市场部推广计划和编辑发言稿的权限。突然有一天公司决定做职位调整，张三被任命为财务总监和人力资源总监，撤掉了形象大使。那么张三当前就只能访问财务总监和人力资源总监所对应的授权资源。

1.2. 角色分层模型 RBAC1

该模型主要是在 RBAC0 的基础上，增加了角色层级关系的继承逻辑，也就是说角色有了组织树的逻辑。
在这里插入图片描述
角色有了上下级关系，上一级的角色可以继承其下所有角色的授权资源。
再比如张三是一家企业的财务总监，同时他也是该企业对外的形象大使，财务总监有访问公司财务数据的权限，形象大使有访问公司市场部推广计划和编辑发言稿的权限。那么他的上级领导，比如是该公司的 CFO，既有访问公司财务数据的权限，又有访问公司市场部推广计划和编辑发言稿的权限。这是继承关系。
在这里插入图片描述

1.3. 角色限制模型 RBAC2

该模型主要添加了授权约束。约束规定了权限被赋予角色时，或角色被赋予用户时，以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。
责任分离包括：静态责任分离（SSD）和动态责任分离（DSD）。
在这里插入图片描述
SSD 是用户和角色的指派阶段加入的，主要是对用户和角色有如下约束:

角色互斥：同一个用户在两个互斥角色中只能选择一个。比如财务部有会计和审核员两个角色，他们是互斥角色，那么用户不能同时拥有这两个角色，体现了职责分离原则。
基数约束：一个角色被分配的用户数量受限，一个用户可拥有的角色数目受限，同样一个角色对应的访问资源权限数目也受限，以控制高级权限在系统中的分配。比如李四是 COO，王五不能也是 COO。同样的李四不能既是 COO 又是 CTO 又是 CFO。COO 、CTO、 CFO 三个角色所能访问的资源权限也不能是一模一样的。
先决条件约束：用户想要获得高级角色，首先必须拥有低级角色。
DSD 是会话和角色之间的约束，可以动态的约束用户拥有的角色，也叫运行时互斥。如一个用户可以拥有两个角色，但是运行时只能激活一个角色。如一个人如果既是运动员又是教练，当比赛开始的时候，只能选择一个角色身份入场。

1.4. 统一模型 RBAC3

RBAC3 是 RBAC1 与 RBAC2 的合集，所以 RBAC3 是既有角色分层又有约束的一种综合授权模型了。

2. 什么是权限

权限是资源的集合，这里的资源指的是软件中所有的内容，包括模块、菜单、页面、字段、操作功能（增删改查）等等。具体的权限配置上，目前形式多种多样，按照我个人的理解，可以将权限分为：页面权限、操作权限和数据权限。

2.1. 页面权限

所有系统都是由一个个的页面组成，页面再组成模块，用户是否能看到这个页面的菜单、是否能进入这个页面就称为页面权限。
在这里插入图片描述
客户列表、客户黑名单、客户审批页面组成了客户管理这个模块。对于普通用户，不能进行审批操作，即无客户审批页面权限，在他的账号登录后侧边导航栏只显示客户列表、客户黑名单两个菜单。

2.2. 操作权限

用户凡是在操作系统中的任何动作、交互都是操作权限，如增删改查等。

2.3. 数据权限

数据权限是指在一个系统，对于不同的用户或用户组，授予不同的数据访问权限的过程。
这里的数据权限包含菜单、页面以及字段等。这些权限可以限制用户可以访问哪些数据、以及他们可以对这些数据进行哪些操作。数据权限的目的是确保数据的安全性和保密性，同时也可以提高数据的可用性和可靠性。
简单举个例子：某系统中有销售部门，销售专员负责推销商品，销售主管负责管理销售专员日常工作，经理负责组织管理销售主管作业。
在这里插入图片描述
按照实际理解，“销售专员张三”登录时，只能看到自己负责的数据；销售主管2登录时，能看到他所领导的所有业务员负责的数据，但看不到其他团队业务员负责的数据。
换另外一句话就是：我的客户只有我和我的直属上级以及直属上级的领导能看到，这就是我理解的数据权限。
要实现数据权限有多种方式：

可以利用RBAC1模型，通过角色分级来实现。
在‘用户-角色-权限’的基础上，增加用户与组织的关联关系，用组织决定用户的数据权限。
具体如何做呢？
组织层级划分
数据可视权限规则制定
上级组织只能看到下级组织员工负责的数据，而不能看到其他平级组织及其下级组织的员工数据等。
通过以上两点，系统就可以在用户登录时，自动判断要给用户展示哪些数据了。

3. RBAC 设计实现

3.1. 用户-角色-权限

最简单的用户、角色、权限（许可）模型。这里面又包含了2种：

用户和角色是多对一关系，即：一个用户只充当一种角色，一种角色可以有多个用户担当。
用户和角色是多对多关系，即：一个用户可同时充当多种角色，一种角色可以有多个用户担当。
那么，什么时候该使用多对一的权限体系，什么时候又该使用多对多的权限体系呢？
如果系统功能比较单一，使用人员较少，岗位权限相对清晰且确保不会出现兼岗的情况，此时可以考虑用多对一的权限体系。
其余情况尽量使用多对多的权限体系，保证系统的可扩展性。如：张三既是行政，也负责财务工作，那张三就同时拥有行政和财务两个角色的权限。

3.2. 用户-组织-角色-权限

在“用户-角色-权限”的基础上，增加了用户与组织的关联关系，组织决定了用户的数据范围的权限。
在这里插入图片描述
系统都有数据私密性的要求：哪些用户可以看到哪些数据，哪些用户不可以看到哪些数据。这个时候，我们需要从组织结构出发思考，数据范围权限其实是角色权限的重要属性，但是由于数据范围太灵活，如果加入“数据权限”，如果账号下的数据量较大，用户编辑数据权限的操作会很繁琐。因此现在主流的后台设计都会使用“组织结构”来对应数据权限。
在这里插入图片描述
常用数据范围设置：全部数据权限、自定数据权限、本部门数据权限、本部门及以下数据权限、仅本人数据权限。