alioth/before/pac-auth/docs/RBAC/对RBAC的理解.md
2025-05-30 09:18:01 +08:00

1.3 KiB
Raw Permalink Blame History

RBAC<92>

1992 , RBAC0

  • 组织架构
  • 岗位:账户上的属性标签
  • 角色:权限的集合
  • 权限:功能权限+数据权限

RBAC<96>

96年对RBAC的优化

RBAC1

角色结构化,角色继承

  • 一般继承:无规则,从最底层开始向上继承,不利于管理(结构化),存在多个多个上级,【最末端的可以用具体权限条目来代替了】
  • 受限继承:向下有限继承,方便建立

将角色结构化,解决扁平化角色的管理复杂度

RBAC2

角色限制

  • SSD静态职责分离
    • 互斥角色:不能同时将两个角色分给同一个人
    • 基数约束:账户能被分配的角色数量,角色能容纳的最大账户数量
    • 先决条件角色:用户想要成为上级角色,必须先成为下一级角色,比如游戏中的转职【此情况应该不存在于受限继承中】
  • DSD动态职责分离
    • 用户可以有两个互斥的角色但是在运行时只能选择一个BOOS直聘老板和员工

RBAC3

RBAC3=RBAC1+RBAC2

完善的RBAC

新用户的权限,可以来源于所在部门的角色或权限

方便新用户进来不用手动配角色

问题:用户和账户的定义,一个用户存在多账户,如腾讯云的子账户