Visual LabINTERACTIVE LEARNING
02 · ACCESS CONTROLP014 MIN

RBAC:角色与权限

把用户与动作权限通过角色解耦,避免为每个人维护一套规则。

MENTAL MODELROLE-BASED ACCESS CONTROL
01User
02Organization Membership
03Role
04Permission
05Resource Action
User 获得 Role,Role 聚合 Permission;权限命名应表达对资源的动作,而不是页面长什么样。
01 · CONCEPTS & BOUNDARIES

先把概念与边界说清楚

定义告诉你它是什么,边界告诉你它不负责什么;企业系统最常见的误解通常发生在两者混用时。

01

Role

围绕岗位职责形成的权限集合,例如 Dealer Sales、Warehouse Operator。

02

Permission

可判断的原子能力,如 quote:approve、inventory:adjust。

03

RBAC

通过 User—Role—Permission 关系管理授权,适合职责相对稳定的企业系统。

02 · BLIND BOTS CASE

经销商销售能否审批自己的折扣

问题现场

Sales 角色有 quote:update,系统因此允许把 40% 折扣直接改为 accepted。

  1. 01

    拆分 quote:update 与 quote:approve。

  2. 02

    高折扣审批授予 Sales Manager。

  3. 03

    加入“不能审批自己提交”的对象条件。

得到什么

角色表达职责,权限与业务规则共同限制敏感动作。

03 · PRACTICE

马上动手

  1. 为销售、仓库、组织管理员各列 5 个原子权限。
  2. 识别哪些规则无法只靠 RBAC。
04 · PITFALLS

常见坑

  • 权限直接等于菜单名
  • 一个超级 role 承担所有场景
  • 修改角色后不记录审计
05 · KNOWLEDGE CHECKRBAC 为什么通常要以组织成员 Membership 为中心?查看答案⌄
答案

同一用户在不同组织可能拥有不同角色;角色应绑定“用户在某组织的成员关系”,而不是全局写在 User 上。