权限模型：RBAC

一、RBAC模型基础概述

1.1 RBAC的定义与核心本质

RBAC的英文全称为“Role-Based Access Control”，中文释义为“基于角色的访问控制”。其核心是通过“角色”这一中间层实现用户与权限的间接关联，而非用户直接绑定权限。简单来说，系统先定义不同角色，为角色分配对应权限，再将角色赋予用户，用户最终通过持有的角色获得相应权限。

1. RBAC的核心授权逻辑

RBAC的授权逻辑可通过**“Who-What-How”三元组**描述：

• Who（谁）：指系统中的“用户”（User），即发起访问请求的主体（如员工、系统账号等）。
• What（什么）：指被访问的“资源”（如页面、按钮、数据、接口等）及对资源的“操作”（如查看、新增、修改、删除等），二者共同构成权限的核心对象。
• How（如何）：指“权限”（Permission），即用户通过角色获得的、对“资源-操作”的许可。

三者的关系为：用户通过绑定角色获得权限，权限决定用户能否对特定资源执行特定操作，最终实现“用户→角色→权限→资源操作”的授权链路。

img

2. RBAC的核心价值（用户与权限逻辑分离）

传统权限管理中，用户与权限直接关联（如“用户A→查看文件权限”“用户B→编辑文件权限”），当用户数量庞大或权限频繁变动时，需逐一维护用户与权限的关系，效率极低。

RBAC通过引入“角色”作为中介，将“用户-权限”的直接关联拆分为“用户-角色”和“角色-权限”两层关联：

• 角色聚合一组权限（如“管理员”角色包含“查看+编辑+删除”权限）；
• 用户通过绑定角色间接获得权限（如“用户A绑定管理员角色→获得管理员的所有权限”）。

这种分离大幅减少了权限管理的复杂度：当权限变动时，只需修改角色的权限集合，所有绑定该角色的用户自动同步权限；当用户变动时，只需调整其绑定的角色，无需重新配置权限。

1.2 RBAC的核心组成要素

• 用户（User）

用户是系统中权限的最终使用者，代表访问系统的主体，可对应真实的人（如员工、客户）或系统账号（如服务间调用的机器人账号）。用户本身不直接拥有权限，需通过绑定角色获得操作许可。一个用户可同时绑定多个角色（如“张三”既是“部门员工”也是“项目负责人”）。

• 角色（Role）

角色是一组权限的集合，代表特定的职责或功能（如“管理员”“普通用户”“审核员”）。角色的定义与业务场景强相关，例如企业中“人力资源专员”角色需包含“员工信息查看”“薪资数据编辑”等权限。角色是用户与权限的中间层，通过聚合权限简化授权流程。

• 权限（Permission）

权限是对资源执行特定操作的许可，由“资源”和“操作”共同构成（如“查看用户列表”“删除订单数据”）。其中：

1. 资源：指被控制的对象（如页面、按钮、接口、数据等）；
2. 操作：指对资源的具体行为（如查看、新增、修改、删除等）。

权限是访问控制的最小单位，不可再拆分，需通过绑定到角色被用户间接获取。

• 会话（Session）

会话是用户登录系统后创建的临时交互周期，用于维护用户在当前登录状态下的权限上下文。用户登录时，系统会加载其绑定的所有角色，用户可在会话中“激活”部分角色（而非全部），会话期间的有效权限仅由激活的角色决定。会话结束（如用户登出、超时）后，权限自动失效。例如，用户“李四”同时绑定“普通用户”和“管理员”角色，登录后可选择仅激活“普通用户”角色，此时仅拥有该角色的权限。

• “用户-角色”映射关系

用户与角色是多对多的映射关系：

1. 一个用户可绑定多个角色（如“产品经理”同时绑定“需求管理”和“项目查看”角色）；
2. 一个角色可分配给多个用户（如“实习生”角色可同时分配给10名新员工）。

这种映射关系可动态调整（如员工升职后新增“部门主管”角色），无需修改角色本身的权限配置。

• “角色-权限”映射关系

角色与权限也是多对多的映射关系：

1. 一个角色可包含多个权限（如“订单管理员”角色包含“查看订单”“修改订单状态”“删除异常订单”权限）；
2. 一个权限可被多个角色共享（如“查看订单”权限可同时分配给“订单管理员”和“客服”角色）。

通过这种映射，权限被聚合到角色中，实现“一次配置，多用户复用”。

1.3 引入RBAC模型的原因

• 解决大规模用户逐一授权的繁琐性

当系统用户数量庞大（如企业级系统有数千甚至数万用户）时，若采用“用户直接绑定权限”的方式，管理员需为每个用户单独配置权限，重复操作多、效率极低。例如，为1000名普通员工配置“查看公告”权限，需执行1000次相同操作。

RBAC通过角色批量授权：先为“普通员工”角色配置“查看公告”权限，再将该角色分配给1000名用户，仅需2步操作即可完成，大幅减少重复劳动。

• 适配岗位权限动态调整的需求

企业中员工岗位变动频繁（如升职、调岗、离职），对应的权限需同步调整。若用户直接绑定权限，岗位变动时需逐一添加/删除权限，易遗漏或误操作（如员工调岗后仍保留原岗位的敏感权限）。

RBAC中，权限与角色绑定，用户权限随角色变化自动调整：员工调岗时，只需移除原岗位角色、添加新岗位角色，权限即可同步更新。例如，“王五”从“开发工程师”调为“测试工程师”，移除“代码提交”角色、添加“用例管理”角色后，自动获得测试相关权限，同时失去开发权限。

• 满足系统权限管理的可扩展性与可维护性

随着系统迭代，新功能（如新增“数据分析”模块）会引入新权限，旧功能可能淘汰旧权限。若用户直接绑定权限，需逐个更新所有相关用户的权限，成本高且易出错。

RBAC中，新权限只需添加到对应角色（如“数据分析师”角色），所有绑定该角色的用户自动获得新权限；旧权限只需从角色中移除，所有用户的权限同步失效。这种“集中管理、批量生效”的模式，显著提升了系统权限管理的可扩展性（支持功能迭代）和可维护性（降低长期管理成本）。

二、RBAC核心模型体系（RBAC96模型族）

RBAC96 是由莱威·桑度（Ravi Sandhu）等人在1996年提出的基础模型族，NIST RBAC96 是美国国家标准与技术研究院（NIST）对该模型的标准化版本，强调了其作为官方标准的地位。‌NIST RBAC96 可视为 RBAC96 的官方标准化版本，两者在本质上高度一致，但应用场景略有差异。

4个基本概念模型:

图片来源: https://transang.me/pattern-oriented-software-architecture-access-control-pattern

• RBACO — 核心RBAC
• RBAC1 — 层次RBAC (RBAC0 + 角色层次结构)
• RBAC2 — 约束RBAC (RBAC0 + 约束)
• RBAC3 — 组合RBAC (RBAC1 + RBAC2)

img

2.1 基本模型（RBAC0/Core RBAC）

RBAC0是RBAC模型族的基础，定义了用户、角色、权限、会话的核心关系，是所有扩展模型的基础。

在这里插入图片描述

1. RBAC0的核心构成

• 用户（User）：访问系统的主体，可绑定多个角色。
• 角色（Role）：权限的集合，作为用户与权限的中介。
• 许可（Permission）：或称“权限”，由“资源”和“操作”组成（如“操作：删除；资源：订单数据”）。
• 会话（Session）：用户登录后创建的临时上下文，关联用户与当前激活的角色。
• 操作（Operation）：对资源的具体行为（如查看、新增、修改、删除等），是权限的核心组成部分。

这五者通过“用户-角色”、“角色-权限”的多对多关系关联，形成基础授权框架。

2. RBAC0的权限传递逻辑

权限传递分为两个阶段：

1. 角色授权用户：管理员通过配置“用户-角色”映射，将角色分配给用户，用户由此获得角色包含的所有权限（静态关联）。
2. 会话管理授权关系：用户登录系统后，会话加载其绑定的所有角色，用户可选择激活部分角色（动态选择），会话期间的有效权限仅由激活的角色决定。例如，用户绑定“管理员”和“普通用户”角色，登录后若仅激活“普通用户”，则只能行使普通用户的权限。

会话结束后，激活状态失效，权限传递链路暂时中断。

3. RBAC0的“用户-角色”关系

• 多对一：多个用户绑定同一个角色（如100名员工均绑定“实习生”角色），适用于批量授权场景。
• 多对多：一个用户绑定多个角色，且一个角色分配给多个用户（如“赵六”绑定“部门经理”和“财务审核”角色，同时“部门经理”角色分配给5名员工）。这种关系更灵活，可满足用户同时承担多种职责的场景。

2.2 角色分层模型（RBAC1/Hierarchal RBAC）

RBAC1在RBAC0基础上引入“角色层级”，支持角色间的权限继承，适用于存在层级关系的组织（如企业部门、政府机构）。

在这里插入图片描述

1. 角色层级与继承逻辑（组织树结构）

角色层级以“组织树”形式呈现，即角色间存在上下级关系（如“公司总经理”→“部门经理”→“团队主管”→“普通员工”）。上级角色自动继承下级角色的权限，形成“权限累加”效果（上级权限 = 自身权限 + 所有下级角色权限）。

例如：“部门经理”角色自身有“审批请假”权限，其下级“团队主管”有“查看团队数据”权限，则“部门经理”自动获得“审批请假+查看团队数据”权限。

在这里插入图片描述

2. 角色继承的两种类型（一般继承、受限继承）

• 一般继承：无限制的层级继承，上级角色可继承所有下级角色的权限，层级深度不限（如“总经理”可继承“部门经理”“主管”“员工”的所有权限）。适用于权限需完全向下覆盖的场景。
• 受限继承：对继承范围或条件进行限制，例如：
  • 某些权限不可继承（如“删除公司数据”权限仅“总经理”可拥有，不向下继承）；
  • 继承仅允许在特定分支内（如“技术部门经理”仅继承“技术主管”权限，不继承“市场主管”权限）。

3. 上级角色对下级角色权限的继承规则

• 单向继承：仅上级继承下级权限，下级不继承上级权限（如“主管”继承“员工”权限，但“员工”不能继承“主管”权限）。
• 传递性继承：上级角色继承其直接下级的权限，同时间接继承所有更低层级的权限（如“总经理”继承“部门经理”权限，同时通过“部门经理”继承“主管”和“员工”的权限）。
• 权限去重：若上下级角色存在相同权限，继承后仅保留一份（避免权限冗余）。

2.3 角色限制模型（RBAC2/Constraint RBAC）

RBAC2在RBAC0基础上引入“权限约束”，通过限制角色的分配和使用，防止权限滥用，保障系统安全（如满足内控、合规要求）。

在这里插入图片描述

1. 静态职责分离（SSD）

静态职责分离是在角色定义或分配阶段设置的约束，一旦生效则长期有效，不随会话变化。

• 角色互斥约束

指两个或多个角色不能被同一用户同时拥有，防止权限集中导致的风险。例如：

1. “会计”和“出纳”角色互斥（避免同一人既管账又管钱，符合财务内控要求）；
2. “订单创建”和“订单审批”角色互斥（避免自我创建并审批订单）。

互斥关系通常由系统管理员预先配置，用户绑定角色时会触发校验，若存在互斥则拒绝分配。

• 基数约束

限制角色与用户的关联数量，分为两种：

1. 用户基数约束：一个用户最多可绑定的角色数量（如“普通用户最多绑定3个角色”）；
2. 角色基数约束：一个角色最多可分配的用户数量（如“超级管理员角色最多分配给2人”）。

基数约束可防止用户权限过度集中（如一个用户绑定10个角色导致权限混乱）或敏感角色被滥用（如“root”角色分配给过多用户）。

• 先决条件角色约束

用户需先拥有某个“先决角色”，才能绑定目标角色，确保用户具备基础权限或资质。例如：

1. 需先拥有“工程师”角色，才能绑定“高级工程师”角色（确保具备基础技能）；
2. 需先拥有“部门成员”角色，才能绑定“部门主管”角色（确保属于该部门）。

2. 动态职责分离（DSD/运行时互斥）

动态职责分离是在会话期间（运行时）的约束：用户可同时拥有互斥角色，但同一会话中不能同时激活这些角色，避免单次操作中权限滥用。

例如，用户“钱七”同时绑定“采购”和“审批”角色（静态上不互斥），但会话中若激活“采购”角色，则无法同时激活“审批”角色（防止自我采购并审批）；若需审批，需先退出当前会话，重新登录并激活“审批”角色。

2.4 统一模型（RBAC3/Combines RBAC）

1. RBAC3的模型本质（RBAC1与RBAC2的整合）

RBAC3是RBAC模型族的综合版本，同时整合了RBAC1的“角色分层继承”和RBAC2的“权限约束”功能。即：

• 支持角色间的层级关系和权限继承（如“总监”继承“经理”权限）；
• 同时支持静态/动态职责分离、基数约束等限制（如“总监”与“审计”角色互斥）。

RBAC3是功能最全面的RBAC模型，可覆盖复杂场景的权限管理需求。

2. RBAC3的综合授权能力（角色分层+权限约束）

RBAC3通过“角色分层”实现权限的高效聚合与传递（如层级化组织的权限自动继承），同时通过“权限约束”保障安全（如关键角色的互斥控制），平衡了权限管理的灵活性与安全性。

例如，某企业的RBAC3模型中：

• 角色层级：“CEO”→“部门总监”→“经理”→“员工”（上级继承下级权限）；
• 约束规则：“财务总监”与“内部审计”角色互斥（静态约束），且“经理”角色最多分配给5人（基数约束）。

这种设计既满足了层级化管理的效率需求，又符合企业内控的安全要求。

三、权限的相关概念

在这里插入图片描述

3.1 权限的双重属性

权限的本质是“主体对资源进行特定操作的许可”，其核心通过“双重属性”实现对访问行为的精准控制：

• 权限的名词属性（控制对象/资源）
  指权限所作用的“受控资源”，是权限的作用对象，具有明确的实体或抽象载体。例如：系统中的“用户信息表”“订单管理页面”“商品库存数据”“删除按钮”等均属于权限的名词属性。资源可以是物理实体（如文件）、逻辑实体（如数据库表）或交互元素（如页面按钮），其核心是“被操作的对象”。

• 权限的动词属性（操作行为）
  指对“受控资源”可执行的具体操作，是权限的行为描述。例如：对“用户信息表”的“查询”、“新增”、“修改”、“删除”，对“订单管理页面”的“访问”，对“删除按钮”的“点击”等。动词属性决定了主体对资源的操作范围，是权限的“行为边界”。

image-20251210102428083

3.2 控制对象（受控资源）

控制对象是权限的“操作载体”，具有层次化、类别化和继承性特征：

• 资源的层次与包含关系（页面>模块>按钮>字段）

  资源按粒度从大到小呈现层级包含关系：

  • 页面：最高层级资源，如“用户管理页面”“订单列表页面”，是功能模块的载体；
  • 模块：页面内的子功能单元，如“用户管理页面”中的“用户查询模块”“用户编辑模块”；
  • 按钮：模块内的交互元素，如“查询按钮”“保存按钮”“删除按钮”；
  • 字段：数据层面的最小单元，如“用户表”中的“手机号”“身份证号”等敏感字段。

  层级关系体现为“父资源包含子资源”，例如：访问“用户管理页面”是访问其内部“编辑按钮”的前提。

• 资源的类别与实例区分（资源类别、资源实例）

  • 资源类别：对同类资源的抽象定义，是“类型级”资源。例如“用户”（代表所有用户数据的集合）、“订单”（代表所有订单数据的集合）；
  • 资源实例：具体的、单个的资源对象，是“个体级”资源。例如“用户ID=1001的用户”“订单号=20240501的订单”。

  区分二者的核心是：权限可针对“类别”（如“查看所有用户”）或“实例”（如“查看用户ID=1001的信息”）进行控制。

• 资源继承规则（子资源权限依赖父级资源权限）

  子资源的访问权限默认依赖于父级资源的权限，即“拥有父资源权限是拥有子资源权限的前提”。例如：

  • 若用户无“访问订单管理页面”权限，则即使配置了“订单删除按钮”权限，也无法操作该按钮；
  • 若用户无“用户表”访问权限，则无法单独拥有“用户手机号字段”的查看权限。

  该规则避免了“子资源权限孤立存在”导致的逻辑矛盾，确保权限控制的连贯性。

3.3 权限项（操作类型）

权限是对受保护资源操作的访问许可，需绑定在特定资源实例上。权限的底层逻辑是资源（object）与操作（operate）的关联，基础操作可归纳为核心四类，同时也可从数据层面整合为“读、写、删除”三大类，其中“写”操作包含新增和修改。

核心操作类型可归纳为四类：查看、新增、修改、删除，所有复杂权限均由这些基础操作组合而来。

• 查看（读）：获取资源的内容或状态，如查看订单详情、查询用户列表；
• 新增（写）：创建新的资源实例，如新增用户、创建订单；
• 修改（写）：变更资源的属性或状态，如修改用户手机号、更新订单状态；
• 删除：移除资源（逻辑或物理移除），如删除商品记录、注销用户。

3.4 权限的具体分类

权限按控制维度可分为三类，覆盖**“能否访问”、“能否操作”、“能访问哪些数据”**全场景：

• 页面权限（菜单可见性、页面访问权）

  控制用户对系统界面的访问范围：

  • 菜单可见性：决定用户在导航菜单中能否看到某个页面入口（如“管理员菜单”仅对管理员可见）；
  • 页面访问权：决定用户能否通过URL或跳转进入页面（即使菜单不可见，无访问权也无法通过直接输入URL访问）。

  页面权限是最基础的权限控制，确保用户只能看到和进入其权限范围内的界面。

• 操作权限（接口调用权、按钮操作权/细颗粒度权限）

  控制用户在页面内的具体操作能力，粒度更细：

  • 接口调用权：控制用户能否调用后端接口（如“新增用户接口”“删除订单接口”），是操作的“后端校验”；
  • 按钮操作权：控制页面中按钮的可见性和可点击性（如“删除按钮”对普通用户隐藏或置灰），是操作的“前端校验”。

  操作权限需前后端配合校验，避免前端隐藏但后端接口可被恶意调用的安全问题。

• 数据权限

  • 数据权限的定义（数据访问范围控制）：

    限制用户可访问的“数据实例范围”，即“能看到/操作哪些具体数据”。

    例如：普通员工只能查看本部门订单，部门经理可查看全部门订单，CEO可查看所有订单。

  • 数据权限的实现方式（角色分级、组织关联）：

    • 角色分级：通过角色层级定义数据范围（如“经理角色”>“员工角色”，对应更大的数据范围）；
    • 组织关联：基于用户所属组织（部门、公司）限制数据范围（如“仅本部门数据”“仅本公司数据”）；
    • 数据所有权：基于“创建者”关联（如“仅自己创建的数据”）；
    • 自定义规则：通过业务标签（如“订单状态=待审核”）动态限制。

  • 常用数据范围设置（全部数据、本部门数据等）：

    常见范围包括：全部数据（无限制）、本组织数据（用户所属部门及子部门）、本部门数据（仅直接所属部门）、本人数据（自己创建的数据）、自定义数据（指定范围或标签的数据）。

3.5 功能权限与数据权限的区分

功能权限与数据权限是权限管理体系的两大支柱：**功能权限定义“操作边界”，解决“能不能做”；数据权限定义“数据边界”，解决“能看哪些”。**落地时需结合业务复杂度选择合适的粒度与方案——简单业务可简化（如按钮级功能权限+区域数据权限），复杂业务需精细化（如字段级功能权限+多规则数据权限），最终实现“合适的人在合适的范围做合适的事”。

3.5.1 功能权限与数据权限的定义

核心定义：解决“能不能做”与“能看哪些”的本质差异

权限类型	核心定义	核心目标	典型示例
功能权限	控制用户“能否操作特定功能”的权限，涵盖界面访问、按钮操作、接口调用等，是“操作行为的许可”	解决“能不能做”的问题	1. 管理员可点击“删除订单”按钮，运营仅能点击“查看订单” 2. 销售可访问“客户管理”页面，财务无此页面访问权限
数据权限	控制用户“在已授权功能下能访问哪些数据”的权限，是“数据范围的约束”	解决“能看/操作哪些数据”的问题	1. 上海分公司管理员仅能查看上海区域的订单，无法查看北京区域数据 2. 普通销售仅能查看自己创建的客户，销售经理可查看部门所有客户

3.5.2 功能权限的实现：从“层级结构”到“验权落地”

1. 核心层级与粒度

功能权限的粒度从粗到细可分为4级，且低粒度权限依赖高粒度权限（优先级原则），具体如下：

粒度级别	对应层级（参考链接）	控制对象	依赖关系（搜索补充）
模块级	表示层+业务层	整个业务模块（如“客户管理”“财务管理”）	基础粒度，无依赖
页面级	表示层	具体页面（如“客户列表页”“订单详情页”）	依赖模块级权限（无模块权限则页面不可见）
按钮级	表示层+业务层	页面内操作按钮（如“新增客户”“删除订单”）	依赖页面级权限（无页面权限则按钮不渲染）
字段级	数据层	页面内具体字段（如客户的“联系方式”是否可编辑）	依赖按钮级权限（如“编辑客户”按钮权限决定字段是否可改）

2. 验权场景与逻辑

系统触发功能权限校验的核心场景，覆盖用户操作全流程：

1. 应用范围验权：用户打开系统时，校验其可访问的应用（如“应付系统”“报销系统”），仅展示有权应用；
2. 菜单范围验权：进入应用后，校验其可访问的菜单（如左侧导航栏的“发票处理”“结算管理”），无权菜单不显示；
3. 操作权限验权：点击按钮/触发接口时，校验是否有对应操作权限（如“提交财务应付单”需验“应付-财务应付单-提交”权限）；
4. 隔离维度验权：查询数据时，校验其可操作的组织/部门维度（如仅能操作“上海分公司”的组织范围）；
5. 权限项验权：获取当前功能下所有有权/无权的权限项（如“财务应付单”功能下，用户有权“查询”“修改”，无权“删除”“审核”）。

3. 技术实现路径

• 前端：通过权限字典对比用户当前权限（如存储permissionList: ['order:view', 'order:edit']），控制菜单、按钮、字段的可见/可用状态；
• 后端：对每个API接口增加权限拦截（如Spring Boot通过注解@PreAuthorize("hasPermission('order:delete')")），防止前端绕过UI直接调用接口；
• RBAC绑定：通过“用户-角色-功能权限”关联，例如“销售经理”角色绑定“客户管理-查看/编辑”权限，用户分配该角色后自动获得对应功能权限。

3.5.3 数据权限的实现：从“范围维度”到“规则落地”

1. 数据权限的核心维度

数据范围的划分需结合业务场景，常见维度如下：

维度类型	核心逻辑	典型示例
组织架构维度	基于用户所在的组织节点层级，控制数据范围（常用维度）	1. 总部管理员：查看全公司数据 2. 分公司管理员：查看本分公司及下属门店数据 3. 门店员工：仅查看本门店数据
数据归属维度	基于数据的创建者/负责人，控制数据范围（常用维度）	1. 本人创建：仅查看自己创建的客户/订单 2. 本人负责：仅查看自己负责的项目数据 3. 部门归属：查看本部门所有成员创建的数据
业务属性维度	基于数据的业务特征（如金额、状态、区域），控制数据范围	1. 金额过滤：财务仅查看金额＜1万元的订单 2. 区域过滤：华南区销售仅查看华南区域客户 3. 状态过滤：客服仅查看“待处理”的工单

2. 数据规则的核心模型

复杂场景下需通过“数据规则”精准控制，避免“角色爆炸”，核心模型包含要素：

• 规则字段：数据的筛选维度（如“所属区域”“创建人”“订单金额”）；
• 规则表达式：筛选条件（如“=”“＜”“包含”“不等于”）；
• 规则值：具体筛选值（如“上海区域”“当前登录人”“10000”）。

示例：“销售经理查看安徽大区数据”的规则为——字段=“所属大区”，表达式=“=”，值=“安徽大区”；若需“查看安徽大区且金额＜1万的订单”，则需组合两个规则。

3. 实现方案对比

不同方案的灵活性、复杂度差异显著，需根据业务场景选择：

实现方案	核心逻辑	优点	缺点	适用场景
组织机构树	基于组织节点层级（父/子节点）计算数据范围	灵活性极强，支持复杂层级	实现复杂，需维护组织树	多层级企业（如M公司分销平台、集团型CRM）
地理区域划分	按固定区域（如省/市）筛选数据	实现简单，易理解	扩展性差，无法支持跨区域	地域性业务（如本地生活服务、区域零售）
客户属性过滤	按客户标签/属性（如客户等级）筛选	精准控制，适配业务属性	维护成本高，需频繁更新属性	多维度细分业务（如高端客户专属运营、行业定制化权限）

3.5.4 功能权限与数据权限的区别与联系

两者相辅相成，共同构成权限管理的完整闭环：

1. 核心区别

对比维度	功能权限	数据权限
控制目标	操作行为的许可（能不能做）	数据范围的约束（能看哪些）
粒度单位	模块/页面/按钮/字段	组织/归属/业务属性
验权触发点	页面渲染、接口调用时	数据查询、数据操作时
技术实现核心	前端UI控制+后端接口拦截	SQL条件过滤（动态拼接where）

2. 核心联系

1. 功能权限是基础：无功能权限时，数据权限无意义（如无“订单管理”功能权限，即使有“查看上海订单”的数据权限也无法操作）；
2. 数据权限是延伸：同一功能下，数据权限决定“能操作哪些数据”（如均有“订单查看”功能权限，总部看全部、分公司看区域）；
3. 共同依赖RBAC：两者均通过“角色”绑定——角色同时关联功能权限（如“查看订单”）和数据权限（如“上海区域订单”），用户分配角色后自动获得两类权限。

3.5.5 典型行业应用场景

1. 电商分销（参考链接案例）：
   • 功能权限：采购员有“下单”“修改订单”权限，财务有“对账”“发票管理”权限；
   • 数据权限：上海采购员仅能操作上海仓库订单，广东高级采购员可操作广东所有仓库订单。
2. CRM系统（搜索补充）：
   • 功能权限：CEO有“客户管理+报表导出”权限，普通销售仅有“客户查看+新增”权限；
   • 数据权限：CEO看全公司客户，华东区经理看华东客户，销售看自己创建的客户。
3. 餐饮行业（搜索补充）：
   • 功能权限：门店店长有“门店管理+库存查看”权限，收银员仅有“收银操作”权限；
   • 数据权限：店长仅能查看本店库存数据，区域经理可查看管辖内所有门店库存。

四、RBAC的设计与实现

4.1 用户划分

1. 用户组

创建角色是为了解决用户数量大的情况下，用户分配权限繁琐以及用户-权限关系维护成本高的问题。抽象出一个角色，把需要一起操作的权限分配给这个角色，把角色赋予用户，用户就拥有了角色上的权限，这样避免了一个个的给用户分配权限，节省了大量的资源。

同样，如果有一批用户需要相同的角色，也需要一个个的给用户分配角色，可以创建一个用户组，所有的用户都属于该用户组，把角色分配给该用户组，这个用户组下面的所有用户就拥有了需要的权限。RBAC模型添加用户组之后的模型图如下所示：

​

用户组是一群用户的组合，而角色是用户和权限之间的桥梁。用户组把相同属性的用户组合起来，比如同一个项目的开发、产品、测试可以是一个用户组，同一个部门的相同职位的员工可以是一个用户组， 一个用户组可以是一个职级，可以是一个部门，可以是一起做事情的来自不同岗位的人。

用户可以分组，权限也可以分组，权限特别多的情况下，可以把一个模块的权限组合起来成为一个权限组，权限组也是解决权限和角色对应关系复杂的问题。加入权限组之后的RBAC模型如下所示：

​

实际工作中很少给权限分组，给用户分组的场景会多一些，有的时候用户组也可以直接和权限关联，这个看实际的业务场景是否需要，权限模型没有统一的，业务越复杂业务模型会约多样化。

2. 组织

每个公司都有自己的组织架构，很多时候权限的分配可以根据组织架构来划分。因为同一个组织内的人员使用的大部分权限是一样的。如下所示一个公司的组织架构图：

​

按照这个组织架构，每一个组织里的成员使用的基础权限很可能是一样的，比如人力资源都需要看到人才招聘的相关信息，市场推广都需要看到行业分析的相关信息，按照组织来分配角色会有很多优势：

实现权限分配的自动化：和组织关系打通之后，按照组织来分配角色，如果有新入职的用户，被划分在某个组织下面之后，会自动获取该组织下所有的权限，无需人工分配。又比如有用户调岗，只需要把组织关系调整就可以了，权限会跟着组织关系自动调整，也无需人工干预。 这么做首先需要把权限和组织关系打通。

控制数据权限：把角色关联到组织，组织里的成员只能看到本组织下的数据，比如市场推广和大客定制，市场推广针对的是零散的客户，大可定制针对的是有一定体量的客户，相互的数据虽然在一个平台，但是只能看自己组织下的数据。

加入组织之后的RBAC模型如下所示：

​

用户可以在多个组织中，因为组织也有层级结构，一个组织里只可以有多个用户，所以用户和组织的关系是多对多的关系，组织和角色的关系是一对一的关系。这个在工作中可以根据实际情况来确定对应关系。

3. 职位

一个组织下面会有很多职位，比如财务管理会有财务总监、财务主管、会计、出纳员等职位，每个职位需要的权限是不一样的，可以像组织那样根据职位来分配不同的角色，由于一个人的职位是固定的，所以用户跟职位的对应关系时一对一的关系，职位跟角色的对应关系可以是多对多的关系。加入职位的RBAC模型如下所示：

​

4.2 理想的RBAC模型

RBAC模型根据不同业务场景的需要会有很多种演变，实际工作中业务是非常复杂的，权限分配也是非常复杂的，想要做出通用且高效的模型很困难。把RBAC模型的演变汇总起来会是一个支撑大数据量以及复杂业务的理想的模型。把RBAC、RBAC1、RBAC2、用户组、组织、职位汇总起来的模型如下所示：

​

按照这个模型基本上能够解决所有的权限问题，其中的对应关系可以根据实际的业务情况来确定，一般情况下，组织和职位是一对多的关系，特殊情况下可以有多对多的情况，需要根据实际情况来定。

理想的RBAC模型并不是说一开始建权限模型就可以这么做，而是数据体量、业务复杂度达到一定程度之后可以使用这个模型来解决权限的问题，如果数据量特别少，比如刚成立的公司只有十几个人，那完全可以用用户-权限模型，都没有必要使用RBAC模型。

4.3 权限系统表设计

3.1 标准RBAC模型表设计

标准RBAC模型的表是比较简单了，要表示用户-角色-权限三者之前的关系，首先要创建用户表、角色表、权限表，用户和角色是多对多的关系，角色和权限是多对多的关系，需要再创建两章关系表，分别是用户-角色关系表和角色-权限关系表。这六张表的ER图如下所示：

​

3.2 理想RBAC模型表设计

理想的RBAC模型是标准RBAC模型经过多次扩展得到的，表结构也会比较复杂，因为要维护很多关系，如下图所示是理想的RBAC模型的ER图：

​

这里面需要强调的是角色互斥表，互斥的关系可以放在角色上，也可以放在权限上，看实际工作的需求。

五、RBAC的适用场景与流程

5.1 RBAC的适用场景

5.1.1 企业组织架构权限管理

企业组织架构中，员工因岗位、部门不同需具备不同权限（如HR部门需员工信息管理权限，财务部门需账务审批权限）。RBAC通过“岗位-角色-权限”映射，实现权限与组织架构的联动：

• 当员工岗位变动时，只需调整其关联的角色，无需逐个修改权限，适配人员流动频繁的场景；
• 支持角色层级（如部门经理继承员工角色权限+额外管理权限），符合企业“管理层级-权限范围”的对应关系；
• 可通过静态职责分离（如“出纳”与“会计”角色互斥），满足企业内控要求（如财务不相容岗位分离）。

5.1.2 应用程序和系统访问控制

各类应用系统（如OA、CRM、后台管理系统）需对用户操作范围严格管控，RBAC是主流解决方案：

• 针对系统功能模块（如“用户管理”“数据报表”），通过角色分配“查看”“新增”“删除”等操作权限（如“系统管理员”角色拥有全部权限，“普通用户”仅能查看）；
• 支持细粒度权限控制，例如对按钮（如“导出报表”）、接口（如/api/user/delete）的权限管理，通过角色与权限项的绑定实现精准控制；
• 适配多系统集成场景，同一用户在不同系统中可关联不同角色（如用户在OA中是“审批人”，在CRM中是“业务员”），权限隔离清晰。

5.1.3 多租户系统权限隔离

多租户系统（如SaaS平台）需确保不同租户数据与功能的隔离，RBAC通过“租户-角色-权限”三层模型实现：

• 为每个租户分配独立角色池（如“租户管理员”“租户用户”），避免租户间权限混淆；
• 租户内部可自定义角色（如租户A的“高级会员”与租户B的“高级会员”权限不同），满足个性化需求；
• 支持租户级权限约束（如限制租户可创建的角色数量、权限范围），防止资源滥用。

5.1.4 医疗保健领域权限管控

医疗领域对数据保密性（如患者病历）和操作合规性（如处方开具）要求极高，RBAC的核心价值在于：

• 按职业角色划分权限（如医生可查看/修改本人患者病历，护士仅可查看基础信息，管理员无直接访问权限）；
• 通过动态职责分离（如“开处方”与“审核处方”角色不可同时激活），符合医疗规范（如双人复核制度）；
• 适配权限临时调整（如医生休假时，通过临时角色授权同事代查病历，到期自动回收）。

5.1.5 金融和银行领域权限分配

金融领域受严格监管（如 Basel 协议、国内《商业银行内部控制指引》），RBAC需满足“权限最小化”“职责分离”等核心要求：

• 交易相关角色（如“柜员”“理财经理”）仅分配必要操作权限（如“转账录入”），审批角色（如“主管”）拥有“转账审核”权限，实现“操作-审核”分离；
• 高风险操作（如大额转账、账户冻结）需多角色协同（如“经办+复核+审批”三级角色），通过角色层级和约束确保合规；
• 支持权限审计追溯，通过角色关联的操作日志，可追踪“哪个用户（通过哪个角色）执行了哪项操作”。

5.1.6 云计算和网络服务提供商权限管理

云服务（如AWS、阿里云）需管理用户对云资源（服务器、存储、数据库）的访问，RBAC是核心控制手段：

• 按资源操作场景定义角色（如“EC2管理员”“S3只读用户”），绑定资源操作权限（如“创建实例”“删除桶”）；
• 支持资源级权限约束（如仅允许某角色操作特定地域的云服务器），通过“角色-资源-操作”三维控制实现精细化管理；
• 适配多账号场景（如企业子账号），父账号可通过角色授权子账号有限权限，避免主账号密钥泄露风险。

5.2 RBAC的核心流程

5.2.1 RBAC权限分配流程

权限分配是RBAC落地的基础，流程可分为“权限定义-角色设计-用户关联”三步：

1. 权限定义：梳理系统资源（如页面、接口、数据）和操作类型（如查看、新增），形成权限项（如“用户管理-查看”“订单管理-删除”）；

2. 角色设计：根据业务场景创建角色（如“管理员”“编辑”），并为角色绑定权限项（可批量关联同类权限，如“编辑”角色绑定所有“内容修改”相关权限）；

3. 用户关联：将用户与角色绑定（支持多对多，如一个用户可同时是“编辑”和“审核员”），用户通过角色获取权限集合；

4. 权限生效：用户登录后，系统通过会话（Session）加载其关联角色的权限，后续操作基于该权限集合校验。

   

   img

5.2.2 RBAC访问控制流程（权限校验逻辑）

用户发起操作时，系统需通过RBAC逻辑校验权限，流程如下：

1. 用户请求：用户触发操作（如点击“删除按钮”、调用接口），系统获取用户标识（如用户ID）和操作对应的权限项（如“订单删除权限”）；
2. 角色查询：通过用户-角色关联表，查询该用户当前激活的角色（考虑会话级角色切换，如用户临时切换“只读角色”）；
3. 权限匹配：检查角色-权限关联表，判断是否有角色包含该操作所需权限项；
4. 结果反馈：若匹配成功，允许操作执行；若失败，拒绝操作并返回权限不足提示（部分场景需记录审计日志）。

img

5.2.3 RBAC模块功能流程

RBAC系统通常包含三大核心模块，功能流程如下：

• 用户管理模块：负责用户的增删改查，核心流程为“创建用户→关联组织/部门→分配角色→设置状态（启用/禁用）”，支持批量导入用户并批量绑定角色；
• 角色管理模块：负责角色的生命周期管理，流程为“创建角色→定义角色描述（如适用场景）→分配权限项→设置角色层级/约束（如互斥角色）→启用角色”，支持角色复制、权限继承（如“高级角色”继承“基础角色”权限）；
• 权限管理模块：负责权限项的维护，流程为“梳理资源（如新增菜单）→定义操作类型→生成权限项→关联资源实例（如特定菜单的按钮）→同步至角色权限池”，支持权限项的批量启用/禁用、分类管理（如按模块分组）。

img

六、RBAC的优缺点分析

6.1 RBAC模型的优点

6.1.1 简化用户与权限的关联关系

传统权限模型（如ACL）中，用户直接关联权限，当用户数量庞大（如10万用户）且权限项众多（如1000个）时，需维护10万×1000的关联关系，极为繁琐。RBAC通过“用户-角色-权限”三层结构，将关联关系简化为“用户-角色”和“角色-权限”两类，大幅减少关联数量（如10万用户关联100个角色，100个角色关联1000个权限，仅需维护10万+100×1000=11万关系，远低于ACL的1亿关系）。

6.1.2 提升权限管理的可扩展性与可维护性

• 可扩展性：新增用户时，无需重新配置权限，仅需分配现有角色；新增功能时，只需为角色批量绑定新权限项，无需逐个通知用户；
• 可维护性：权限变更（如回收“删除”权限）时，仅需修改角色与权限的关联，所有关联该角色的用户自动生效，避免遗漏；支持角色批量操作（如复制、禁用），降低管理成本。

6.1.3 支持三大安全原则

• 最小特权原则：可为角色分配“完成工作所必需的最小权限”（如“客服”角色仅分配“查询订单”权限，无“删除订单”权限），减少权限滥用风险；
• 责任分离原则：通过RBAC2的静态职责分离（如“采购”与“付款”角色互斥），避免单一用户掌握完整流程权限（如既采购又付款可能导致舞弊）；
• 数据抽象原则：用户通过角色获取权限，无需了解权限的具体实现细节（如用户无需知道“查看报表”权限对应哪些接口），降低权限管理的认知成本。

6.1.4 降低授权管理的复杂性与管理成本

• 管理员无需为每个用户单独授权，只需管理角色与权限的映射，减少重复劳动；
• 角色可按业务场景标准化（如“管理员”“操作员”“访客”），新系统可复用现有角色体系，缩短权限设计周期；
• 支持权限继承（如RBAC1），上级角色自动获取下级角色权限，无需重复配置（如“部门经理”自动拥有“员工”角色的所有权限）。

6.1.5 减少权限分配的出错概率

传统直接授权模式中，人工为每个用户分配权限易出现“多授权”（如误给普通用户管理员权限）或“漏授权”（如忘记给新员工分配基础操作权限）。RBAC通过角色标准化授权，权限分配基于预设角色模板，减少人工干预，且可通过“角色权限校验工具”检查角色权限的合理性（如是否包含冗余权限），降低出错风险。

6.2 RBAC模型的缺点

6.2.1 无操作顺序控制机制（难以适配操作次序严格的系统）

RBAC仅控制“是否有权限执行操作”，但无法约束“操作的先后顺序”。例如，在采购系统中，需先“创建采购单”才能“审批采购单”，但RBAC无法阻止用户先执行“审批”操作（只要用户同时有两个权限）。此类场景需额外引入“工作流引擎”或“状态机”配合，增加系统复杂度。

6.2.2 模型本身存在一定复杂性（需精细化角色与权限规划）

RBAC的灵活性依赖于前期设计：

• 若角色颗粒度太粗（如仅设计“管理员”和“用户”两个角色），会导致权限过度集中或不足；
• 若角色层级设计混乱（如多级继承关系复杂），会导致权限传递不清晰（如难以追溯某用户的权限来源）；
• 职责分离规则（如互斥角色数量过多）可能导致角色管理复杂化，甚至出现“角色冲突”（如某用户需同时关联两个互斥角色）。

6.2.3 难以处理临时权限调整等特殊场景

RBAC适合长期稳定的权限分配，但对临时权限（如员工代班、紧急操作）支持不足：

• 为临时需求创建新角色会导致角色冗余；
• 临时修改用户-角色关联后，若忘记回收，可能导致权限泄露；
• 动态职责分离（DSD）虽可限制会话中角色的同时激活，但实现复杂，需额外开发会话级权限控制逻辑。

6.2.4 有效性高度依赖角色设计的合理性

RBAC的核心是“角色”，若角色设计不符合业务场景，整个模型会失效：

• 例如，在电商系统中，若未区分“商品编辑”和“商品审核”角色，而用单一“商品管理”角色，会违反“编辑-审核分离”的内控要求；
• 角色命名模糊（如“高级用户”）会导致权限分配混乱（不同管理员对“高级”的理解不同）；
• 角色数量过多（如超过1000个）会增加管理难度，甚至出现“角色膨胀”（每个用户关联数十个角色，权限集合难以维护）。

七、RBAC与其他访问控制模型的对比

7.1 常见访问控制模型类型

7.1.1 访问控制列表（ACL，Access Control List）

ACL是一种以“客体”为核心的访问控制模型，其核心逻辑是为每个受保护的资源（如文件、接口、数据库表等）维护一个权限列表，列表中明确记录哪些主体（用户、进程等）可以对该资源执行哪些操作（如读、写、删除等）。

• 核心构成：由“客体+主体+权限”三元组组成，例如“文件A允许用户甲读取、禁止用户乙修改”。
• 特点：直接建立主体与客体的权限关联，实现简单，适合小规模、资源和用户数量较少的场景（如单机文件系统）。
• 局限性：当资源或用户规模扩大时，权限列表会急剧膨胀，导致管理复杂度呈指数级上升（例如1000个用户和1000个资源，可能需要维护百万级别的权限关联），且难以批量调整权限（如批量修改某类用户的权限需逐个更新资源的ACL列表）。

7.1.2 自主访问控制（DAC，Discretionary Access Control）

DAC是一种允许主体自主管理其拥有资源权限的模型，核心是“主体对自身资源的权限具有分配权”。

• 核心逻辑：资源的所有者可以自主决定其他主体对该资源的访问权限，且权限可传递（如用户甲可将文件A的“读取权”授予用户乙，用户乙也可进一步授予用户丙）。
• 典型案例：Unix/Linux系统的文件权限管理（rwx权限机制），文件所有者可通过chmod命令分配其他用户的访问权限。
• 优点：灵活性高，符合用户自主管理资源的场景需求。
• 缺点：安全性较低，权限传递可能导致“权限扩散”（如无意授予过多用户权限），且难以满足严格的权限管控需求（如企业级数据保密场景）。

7.1.3 强制访问控制（MAC，Mandatory Access Control）

MAC是一种由系统管理员或安全策略强制定义权限的模型，核心是“权限由系统统一分配，主体无法自主修改”。

• 核心逻辑：主体和客体均被分配固定的安全级别（如“绝密”“机密”“秘密”“公开”），访问权限由两者的级别关系决定（如“低级别主体无法访问高级别客体”）。
• 典型案例：军事、政府等对安全性要求极高的领域，如美国国防部的多级安全模型（MLS）。
• 优点：安全性极强，严格遵循预设安全策略，避免权限被随意篡改。
• 缺点：灵活性极差，权限调整需通过系统管理员手动操作，难以适配动态变化的业务场景（如企业内部的权限临时调整需求）。

7.1.4 基于属性的访问控制（ABAC，Attribute-Based Access Control）

ABAC是一种基于“属性”动态决策权限的模型，核心是“通过主体、客体、环境的属性组合判断是否允许访问”。

• 核心构成：包含主体属性（如用户角色、部门、级别）、客体属性（如资源类型、敏感级别）、环境属性（如时间、IP地址、设备类型），以及基于这些属性的访问控制规则（如“仅允许本部门经理在工作时间（9:00-18:00）从公司内网访问敏感客户数据”）。
• 特点：权限判断不依赖固定关联，而是通过动态规则计算，支持复杂场景的细粒度控制。
• 优点：灵活性极高，可适配动态变化的业务需求（如临时权限、跨场景权限），减少权限维护成本。
• 缺点：规则设计复杂（需梳理大量属性和逻辑），权限判断过程涉及规则引擎计算，可能影响系统性能；且规则过多时易出现冲突（如“允许”和“禁止”规则矛盾）。

7.1.5 其他模型

• HBAC（Hierarchical-Based Access Control，基于层次的访问控制）：权限与组织层次结构强绑定，主体的权限随其在层次中的位置自动继承（如“部门经理自动继承下属员工的所有权限”）。适用于严格层级化的组织（如政府机构、大型企业），但灵活性不足，难以处理跨层级权限场景。
• IBAC（Identity-Based Access Control，基于身份的访问控制）：直接以主体身份（如用户名、唯一标识）作为权限判断依据，本质是简化版的ACL（仅以身份为主体属性）。适用于用户数量极少且固定的场景（如小型系统管理员权限），扩展性差。
• OrBAC（Organization-Based Access Control，基于组织的访问控制）：引入“组织”作为核心维度，权限定义与组织上下文绑定（如“在A部门中，角色‘主管’可审批B类型单据”）。适用于多组织、多租户场景（如 SaaS 平台），但模型复杂度高，实现难度大。

7.2 RBAC与ACL的核心区别

7.2.1 权限关联逻辑

• RBAC：采用“用户-角色-权限”的间接关联逻辑。用户通过关联角色获得权限，角色通过关联权限聚合操作许可，形成“用户→角色（多对多）→权限（多对多）”的三层结构。例如：“用户张三→角色‘销售员’→权限‘查看客户信息’‘新增订单’”。
• ACL：采用“用户（主体）→权限→资源（客体）”的直接关联逻辑。权限直接绑定用户与资源，例如：“用户张三→权限‘查看客户信息’→资源‘客户表’”“用户张三→权限‘新增订单’→资源‘订单接口’”。

7.2.2 管理复杂度与效率对比

• 管理复杂度：

  • ACL：当用户或资源数量增加时，权限关联数量呈“用户数×资源数”的线性增长（如100个用户和100个资源，最多需维护10000条权限记录），且权限调整需逐个更新资源的访问列表（如批量新增“销售员”权限需修改所有客户资源的ACL），管理成本极高。
  • RBAC：通过“角色”中间层减少关联数量（关联数为“用户数×角色数 + 角色数×权限数”），且权限调整可通过修改角色实现批量生效（如新增“导出订单”权限，只需为“销售员”角色关联该权限，所有关联该角色的用户自动获得权限），管理复杂度显著降低。

• 效率对比：

  • ACL：权限校验时需直接查询资源对应的用户权限列表，当列表过长时查询效率低。
  • RBAC：权限校验通过“用户→角色→权限”的层级查询实现，可通过缓存角色权限集合提升效率（如用户登录时加载所属角色的所有权限，后续校验直接匹配缓存），适合大规模系统。

八、RBAC相关实现框架与技术实践

8.1 主流RBAC权限验证框架

8.1.1 Apache Shiro

Apache Shiro是一个轻量级的Java安全框架，全面支持RBAC模型，同时提供身份认证、会话管理、加密等功能。

• RBAC支持特性：
  • 内置RolePermissionResolver接口，可通过角色自动关联权限，支持角色继承（符合RBAC1模型）。
  • 提供@RequiresRoles @RequiresPermissions注解，可在代码层面直接声明角色或权限要求（如@RequiresPermissions("order:create")表示需“新增订单”权限）。
  • 支持自定义权限校验逻辑，可扩展实现动态职责分离（RBAC2模型）。
• 优势：API简洁易用，学习成本低，不依赖Spring等框架，可独立使用；适合中小规模项目或需要快速集成权限功能的场景。
• 局限性：在分布式系统中会话管理需额外配置（如集成Redis），且细粒度数据权限控制需自行扩展。

8.1.2 Spring Security

Spring Security是Spring生态中的安全框架，与Spring无缝集成，对RBAC支持更深入，适合复杂权限场景。

• RBAC支持特性：
  • 通过RoleHierarchy接口实现角色继承（如“管理员”继承“操作员”的所有权限），符合RBAC1模型。
  • 基于SecurityContextHolder维护用户权限信息，支持通过@PreAuthorize注解实现复杂权限表达式（如@PreAuthorize("hasRole('ADMIN') and hasPermission(#orderId, 'Order', 'edit')")）。
  • 内置AccessDecisionManager接口，可自定义权限决策逻辑（如实现静态/动态职责分离）。
• 优势：与Spring Boot、Spring Cloud等生态深度融合，支持OAuth2.0、JWT等认证机制，适合大型分布式系统；细粒度控制能力强，可灵活扩展数据权限（如结合MyBatis拦截器实现数据范围过滤）。
• 局限性：配置复杂，学习曲线较陡，对非Spring项目支持较弱。

8.1.3 SELinux

SELinux（Security-Enhanced Linux）是Linux内核级的安全模块，基于MAC和RBAC模型，用于增强系统级访问控制。

• RBAC支持特性：
  • 引入“用户（User）→角色（Role）→类型（Type）”的RBAC扩展模型，其中“类型”对应资源访问权限（如“httpd_t”类型表示HTTP服务可访问的资源）。
  • 角色由系统管理员预定义，用户需切换角色才能获得对应权限（如su - role_name），符合职责分离原则。
• 优势：内核级强制控制，安全性极高，可防止恶意进程越权访问系统资源（如限制Web服务器仅能访问特定目录）。
• 局限性：配置极其复杂（需学习TE规则语言），适合对系统安全要求极高的场景（如服务器、嵌入式设备），不适合业务系统的应用层权限管理。

8.2 RBAC技术实践注意事项

8.2.1 角色设计的合理性原则

• 基于业务岗位抽象：角色应与实际业务岗位对应（如“销售员”“财务审核员”），而非按个人或零散功能定义（避免出现“张三专属角色”“临时查询角色”），确保角色的复用性。
• 遵循最小特权原则：每个角色仅包含完成其职责必需的权限（如“订单查看员”仅授予“查看订单”权限，不包含“修改订单”），减少权限滥用风险。
• 支持角色分层与继承：通过角色继承简化权限管理（如“部门经理”继承“部门员工”的所有权限，再额外添加“审批”权限），避免重复配置。
• 控制角色数量：角色数量过多会增加管理复杂度（如超过100个角色时难以维护），需通过合并相似角色、拆分过粗角色平衡粒度。

8.2.2 权限粒度的把控策略

• 按资源层次划分粒度：结合资源的层级关系（页面>模块>按钮>字段）设计权限粒度，例如：
  • 页面级：“访问订单管理页”；
  • 模块级：“订单管理模块操作权”；
  • 按钮级：“订单导出按钮点击权”；
  • 字段级：“查看订单中的客户手机号字段”。
• 平衡粒度与管理成本：粒度过粗（如仅“订单管理权限”）会导致权限不精准（无法限制“查看”与“修改”）；粒度过细（如每个字段单独设权限）会增加角色-权限关联数量（如100个字段对应100个权限）。需根据业务敏感度调整：核心数据（如用户密码）采用细粒度，非敏感功能（如基础查询）采用粗粒度。
• 区分功能权限与数据权限：功能权限控制“能否操作”（如“能否删除订单”），数据权限控制“能操作哪些数据”（如“只能删除本部门订单”），两者需独立设计但联动校验（如先校验功能权限，再过滤数据范围）。

8.2.3 静态与动态职责分离的落地要点

• 静态职责分离（SSD）落地：

  • 角色互斥：在角色定义时标记互斥关系（如“出纳”与“会计”角色互斥），通过数据库约束（如用户-角色关联表中添加互斥校验）或代码拦截（如新增用户角色时检查是否存在互斥角色）防止冲突。
  • 基数约束：限制用户关联角色的数量（如“普通用户最多关联3个角色”）或角色关联用户的数量（如“管理员角色最多关联5人”），通过数据库触发器或业务层校验实现。
  • 先决条件约束：要求用户必须先关联“基础角色”才能关联“高级角色”（如“高级审核员”需先关联“初级审核员”），在角色关联流程中添加前置检查。

• 动态职责分离（DSD）落地：

  • 会话级互斥：用户登录时检查当前会话关联的角色是否存在互斥（如同时关联“审批者”和“申请者”角色时拒绝登录），或限制同一会话中只能激活一个互斥角色（如通过“角色切换”功能临时激活某一角色）。
  • 操作级校验：执行关键操作时（如“审批订单”），动态检查用户当前激活的角色是否符合权限要求（如排除临时授予的冲突角色），通过AOP拦截器在操作前触发校验。

• 技术实现工具：结合框架特性落地，例如Spring Security可通过AccessDecisionVoter自定义投票逻辑实现职责分离校验；Shiro可通过AuthorizingRealm的doGetAuthorizationInfo方法动态过滤互斥权限。

---

参考资料

致谢

• RBAC 模型梳理
• 【设计模式】RBAC 模型详解_rbac模式(2)，真香系列
• RBAC——基于角色权限的模型
• 深入理解RBAC
• 全网最全：权限系统设计方案！
• 最全的权限系统设计
• 权限系统与RBAC模型概述[绝对经典]
• 基于RBAC的通用权限管理系统的详细分析与实现（理念篇——权限对象、权限项、功能权限、数据权限、权限组、权限设计）