侧边栏壁纸
  • 累计撰写 218 篇文章
  • 累计创建 59 个标签
  • 累计收到 5 条评论

RBAC 权限模型

barwe
2024-02-01 / 0 评论 / 0 点赞 / 916 阅读 / 3,862 字
温馨提示:
本文最后更新于 2024-02-01,若内容或图片失效,请留言反馈。部分素材来自网络,若不小心影响到您的利益,请联系我们删除。

常见的权限模型

权限模型用于管理和控制用户对系统资源的访问权限。

常见的权限模型:

  • RBAC (Role-Based Access Control, 基于角色):将权限关联到角色上,然后将用户关联到角色上来获得权限
  • ABAC (Attribute-Based , 基于属性):使用属性(例如用户属性、资源属性、环境属性等)来决定用户对资源的权限,依赖于属性的匹配规则
  • DAC (Discretionary ~, 自主):资源的所有者可以自行决定其他用户对该资源的访问权限
  • MAC (Mandatory ~, 强制):由系统管理员通过标签或者级别来控制资源的访问,适用于需要高度安全的环境,如军事和政府系统
  • PBAC (Policy-Based ~, 基于策略):相比于 ABAC,PBAC 使用的策略和条件更加复杂

ABAC 直接通过属性来确定权限,更加精细和灵活,但是实现起来更复杂;RABC 更简单,但是因为权限依赖于独立的角色模型,所以灵活性差一点。

综上,对于中小型项目,RABC 是性价比最高的选择。

RBAC 模型

RBAC 中涉及到三个关键概念:

  • 权限:对模型或者资源的操作,可以与页面上的按钮一一对应
  • 角色:一组权限的集合,角色之间还可以分级、组合、继承
  • 用户:用户通过关联角色来获取对资源的控制权限

权限设计的一个例子:

  • 模型层面我们可以设置:
    • 创建实例:不涉及具体的实例权限
    • 查看实例:在模型层面上允许查看实例意味着可以读取该模型的所有实例,此时将忽略实例层面上的权限控制
    • 修改实例:在模型层面上允许修改实例意味着可以修改该模型的所有实例,此时将忽略实例层面上的权限控制
    • 删除实例:在模型层面上允许删除实例意味着可以删除该模型的所有实例,此时将忽略实例层面上的权限控制
    • ……
  • 实例层面上我们单独控制对具体实例的权限:
    • 查看实例:是否允许查看当前实例
    • 修改实例:是否允许查看修改实例
    • 删除实例:是否允许查看删除实例
    • 运行任务:是否允许基于本实例投递任务
    • ……

在涉及到对分层资源的控制时,需要将权限也设计成对应的树形结构,整理出对应的权限树。

带分级的 RBAC 模型

角色区分上下级,上级角色继承下级角色的所有权限,并且还可以添加额外的权限。

image20240131170245371.png

上下级之间一般存在两种对应关系:

  • 一个下级只有一个上级,一个上级可以有多个下级:这种比较常见
  • 一个下级可以有多个上级:这种比较少见

带约束的 RBAC 模型

  • 角色互斥:一个用户不能同时关联两个角色,例如一个员工不可能既是会计又是审核
  • 数量约束:约束角色关联的用户数量,或者约束用户关联的角色数量,例如超级管理员角色只能关联一个用户
  • 先决条件:在分级角色中,用户想要关联一个上级角色之前,必须要先关联其下级角色

用户组

当给某部门下大量用户批量关联新角色时,我们需要手动给每一个用户关联这个角色。

此时可以引入 用户组 的概念:将这些用户添加到某个用户组,然后将角色关联到用户组上,该用户组内的所有用户即可获取该角色的权限。

注意,用户组并没有完全隔断用户和角色的关联,它们的关系如下:

image20240131171740520.png

用户可以通过用户组关联角色,也可以直接关联角色。

组织架构

组织架构一般指的是部门的层级关系,跟人员的上下级有区别。

例如研发部是一个部门,它下面还可以包含产品中心和研发中心两个部门。

在每个部门内部存在很多人员,这些人员之间也存在上下级关系。

上级部门中的人员与下级部门的人员不存在必然的上下级关系。

image20240201105507531.png

可以给部门关联角色,这样新加入部门的用户将自动继承该部门关联的角色。

部门关联的角色只涉及基础权限,即部门内大家共有的权限。

好处:

  1. 新加入的用户可以直接继承部门的基础权限,不需要重新分配权限
  2. 用户组织关系转移时权限会跟着部门自动调整,不再需要重新分配权限

image20240201110305418.png

职位

职位也是组织架构的一部分,其在 RBAC 模型中的位置与部门类似。

理想的 RBAC 模型

我们可以设计一个包含上面各种情况的模型,这个模型能解决大多数权限控制的问题,但是实现起来也较为复杂,注意具体情况具体分析。

image20240201111654067.png

  • 角色和权限一般是多对多的关系:一个角色可以拥有多个权限,一个权限可以属于多个角色
  • 用户组和权限一般是多对多的关系:一个用户组可以拥有多个权限,一个权限可以属于多个用户组
  • 用户和用户组是多对多的关系:一个用户组可以包含多个用户,一个用户可以属于多个用户组
  • 部门组织一般只关联基础权限,一般设计为一对一即可,可以为部门创建一个专属角色
  • 职位和角色一般设计成多对多的关系,职位在继承部门的基本权限的基础上还可以附加额外的角色
  • 用户和职位一般是一对一,也可能出现一个用户兼任多值的情况(一对多),具体分析
  • 部门和职位一般也是一对多:一个部门拥有多个职位,一个职位必定只属于某个部门
  • 用户在继承用户组、组织、职位的权限基础上,还可以附加额外的角色

权限数据表设计

以理想的 RBAC 模型为例,涉及到的实体有权限、角色、用户组、用户、部门组织、职位。

在 ORM 设计中,我们只需要关注实体表以及实体间的关联关系,框架会自己处理关联数据表。

erDiagram Permission { int id string name "权限名称" string type "权限类型" int parent "父权限ID (FK:self)" } Role { int id string name "角色名称" int parent "父级角色ID (FK:self)" } RoleMut { int role1 "角色1 (FK:Role)" int role2 "角色2 (FK:Role)" string description "互斥描述" } User { int id string name "用户名称" } UserGroup { int id string name "用户组名称" } Department { int id string name "部门名称" } Position { int id string name "职位名称" } UserGroup }o--|{ User : "" %% 用户组拥有的用户≥1,用户所属的用户组≥0 Department }|--|{ User : "" %% 部门拥有的用户≥1,用户所属的部门≥1 User ||--|{ Position : "" %% 用户拥有的职位≥1,职位所属的用户==1 Department ||--|{ Position : "" %% 部门拥有的职位≥1,职位所属的部门==1 UserGroup }o--o{ Role : "" %% 用户组拥有的角色≥0,角色所属的用户组≥0 User }o--o{ Role : "" %% 用户拥有的角色≥0,角色所属的用户≥0 Department }o--o{ Role : "" %% 部门拥有的角色≥0,角色所属的部门≥0 Position }o--o{ Role : "" %% 职位拥有的角色≥0,角色所属的职位≥0 Role }o--o{ Permission : "" %% 角色拥有的权限≥0,权限所属的角色≥0 Role ||--o{ RoleMut : "" %% 角色拥有的互斥关系≥0,一个互斥关系所属的角色==1

image.png

UserGroup }o--|{ User : "" %% 用户组拥有的用户≥1,用户所属的用户组≥0
Department }|--|{ User : "" %% 部门拥有的用户≥1,用户所属的部门≥1
User ||--|{ Position : "" %% 用户拥有的职位≥1,职位所属的用户==1
Department ||--|{ Position : "" %% 部门拥有的职位≥1,职位所属的部门==1
    
UserGroup }o--o{ Role : "" %% 用户组拥有的角色≥0,角色所属的用户组≥0
User }o--o{ Role : "" %% 用户拥有的角色≥0,角色所属的用户≥0
Department }o--o{ Role : "" %% 部门拥有的角色≥0,角色所属的部门≥0
Position }o--o{ Role : "" %% 职位拥有的角色≥0,角色所属的职位≥0
    
Role }o--o{ Permission : "" %% 角色拥有的权限≥0,权限所属的角色≥0
Role ||--o{ RoleMut : "" %% 角色拥有的互斥关系≥0,一个互斥关系所属的角色==1

权限

权限名称通常指的是“在什么资源上施加什么操作”。

权限表的权限类型可以划分为:

  • 系统管理:偏底层结构数据的管理,例如用户管理、角色管理、权限管理等
  • 内容管理:与内容相关的权限,例如创建、编辑和删除内容的权限
  • 数据管理:与数据相关的权限,例如数据库访问、数据的导入和导出等
  • 订单管理:与订单相关的权限,例如创建、编辑和删除订单的权限
  • 财务管理:与财务相关的权限,例如支付管理、生成报表等

通过指定父权限的 ID,实现对权限的层次化管理,即权限树。

mermaid 语法参考:https://mermaid.js.org/syntax/entityRelationshipDiagram.html

资料参考:https://mp.weixin.qq.com/s/far1K5lhHbWR9S0bpnfi6A

0

评论区