业务系统设计权限系统 MAC、DAC、RBAC、ABAC 、核心概念（主体 / 客体 / 用户 - 角色 - 对象）、及数据权限

权限系统设计：RBAC、ABAC 及核心概念（主体 / 客体 / 用户 - 角色 - 对象）、及数据权限

权限核心是谁（主体）能对什么（客体）做什么（操作），RBAC/ABAC 是两种主流实现模型，用户 - 角色 - 对象是 RBAC 的核心结构。

权限可以分成三类：功能权限、数据权限、字段权限。

MAC、DAC、RBAC、ABAC 四种访问控制模型对比表

特性	强制访问控制（MAC）	自主访问控制（DAC）	基于角色的访问控制（RBAC）	基于属性的访问控制（ABAC）
核心逻辑	基于主体 / 客体的安全标签 / 等级强制匹配	基于客体所有者自主分配权限	基于角色分配权限，角色关联权限	基于主体、客体、环境多维度属性动态判定
权限控制权	完全由系统管理员 / 安全策略控制，不可被用户修改	由资源所有者控制，可自主授权 / 回收	由管理员定义角色和角色权限	由策略引擎控制，规则可动态配置
灵活性	极低，规则固定刚性	较高，但权限分散易混乱	中等，适合层级化组织	极高，支持复杂动态场景
权限粒度	粗粒度，多针对整个资源（如文件、系统）	中等，可针对单个资源	中等，权限按角色批量分配	极细粒度，支持字段级权限控制
核心优势	安全性最高，防止越权访问，适合高机密场景	配置简单，符合日常使用习惯	权限管理集中，易于审计和维护	适配复杂业务，扩展性强
核心缺点	灵活性差，不适合普通商业系统	权限分散，难以统一管理和审计	角色调整成本高，不支持动态场景	策略配置复杂，对引擎性能有要求
典型应用场景	军工、政府涉密系统、高安全等级行业	个人电脑文件管理、小型团队共享资源	企业 OA 系统、ERP 系统、内部管理平台	云服务、大数据平台、多租户系统、字段级权限控制场景
示例	涉密文件标注 "绝密"，仅 "绝密等级" 用户可访问	Windows 文件夹右键分配 "读取 / 写入" 权限给其他用户	给 "部门经理" 角色分配 "审批单据" 权限，用户加入角色后获得权限	市场部员工工作时间（环境属性）可访问本部门（主体属性）的2025 年销售报表（客体属性）

一、核心基础概念

1. 主体（Subject）

定义：发起操作的实体，如用户、服务、进程、设备。
示例：员工账号、管理员、第三方服务。

2. 客体（Object/Resource）

定义：被操作的资源，如数据、文件、接口、菜单、订单、用户信息。
示例：订单表、用户详情接口、财务报表、部门数据。

3. 操作（Action）

定义：主体对客体执行的动作，如CRUD（增删改查）、查看、编辑、删除、导出、审核。
示例：订单 - 查看、用户 - 编辑、报表 - 导出。

4. 权限（Permission）

定义：主体 + 客体 + 操作的组合，即 "谁能对什么做什么"。
示例：用户A → 订单 → 查看、管理员 → 用户 → 删除。

5. 用户 - 角色 - 对象（User-Role-Object）

用户（User）：实际使用系统的人 / 账号。
角色（Role） ：权限的集合，是权限的 "打包单位"（如管理员、财务、普通员工）。
对象（Object）：被授权的资源（同上述客体）。
核心关系 ：用户 → 角色 → 权限（客体 + 操作），实现 "权限赋给角色，用户继承角色权限"。

二、RBAC（基于角色的访问控制）

1. 核心思想

以角色为中心 ：权限先赋给角色，用户再关联角色，用户通过角色间接获得权限。
核心公式 ：用户 → 角色 → 权限（客体+操作）。

2. 核心模型（RBAC0~RBAC3，常用 RBAC0/RBAC1）

（1）RBAC0（基础版）

核心元素：用户、角色、权限、用户 - 角色关联、角色 - 权限关联。
特点：简单直接，适合中小系统。
示例：
- 角色：普通员工（权限：订单 - 查看、个人信息 - 编辑）
- 角色：财务（权限：订单 - 查看、报表 - 查看、报销 - 审核）
- 角色：管理员（权限：所有操作）
- 用户：张三 → 关联普通员工 → 获得对应权限。

（2）RBAC1（角色继承）

新增：角色继承（子角色继承父角色权限，可叠加 / 覆盖）。
示例：部门主管 继承 普通员工 权限，额外拥有部门数据-查看权限。

（3）RBAC2（职责分离）

新增：静态职责分离（SSD） （如 "出纳" 和 "会计" 不能同一人）、动态职责分离（DSD）（OA会签、或签、依次审批同一操作需多人审批）。
适用：金融、财务等强合规场景。
比如编制职位状态（在校离校）

（4）RBAC3（统一模型）

整合 RBAC1 + RBAC2，功能最全，复杂度最高。
多维矩阵审批比如可以选人角色集团系统部门状态来审批会签循序等。

3. 优点

易管理：批量给角色赋权，用户换岗只需改角色，无需改单个权限。
易理解：符合企业组织架构（岗位 = 角色）。
易实现：成熟方案多，开发成本低。

4. 缺点

灵活性差 ：权限绑定角色，细粒度控制弱（如 "仅查看自己部门的订单" 难以直接实现）。
角色爆炸：复杂场景下角色过多（如 "销售经理 - 华东区 - 2026"），维护困难。

5. 适用场景

企业内部系统 （OA、ERP、CRM、BPM）、中小后台管理系统 、权限规则稳定的场景。

三、ABAC（基于属性的访问控制）

1. 核心思想

以属性为中心 ：通过主体属性、客体属性、环境属性的组合规则，动态判断是否允许操作。
核心公式 ：主体属性 ∧ 客体属性 ∧ 环境属性 → 允许/拒绝操作。

2. 核心属性维度

主体属性 ：用户 ID、部门、职位、职级、组、IP、设备、证书等。
- 示例：部门=销售部、职级=经理、IP=192.168.1.0/24。
客体属性 ：资源 ID、类型、所属部门、创建人、敏感级别、数据范围等。
- 示例：资源类型=订单、所属部门=销售部、敏感级别=普通。
环境属性 ：时间、地点、设备类型、网络环境、操作上下文等。
- 示例：时间=工作日9:00-18:00、设备=公司电脑、网络=内网。
操作属性：操作类型（查看 / 编辑 / 删除）、操作风险等级等。

3. 核心规则示例（伪代码）

复制代码

允许 主体.部门 == 客体.所属部门 且 操作 == 查看 且 环境.时间 in 9:00-18:00
允许 主体.职级 == 经理 且 客体.敏感级别 == 普通 且 操作 == 编辑
拒绝 主体.IP 不在 公司内网 且 操作 == 删除

4. 优点

细粒度高 ：支持动态、灵活、复杂的权限控制（如数据行级、字段级、上下文级）。
扩展性强：新增权限只需改规则，无需新增角色 / 权限项。
动态适配：可根据时间、地点、设备等环境因素实时判断。

5. 缺点

复杂度高：规则设计、调试、维护难度大，需专业人员。
性能开销：每次请求需计算属性规则，高并发场景需优化（缓存、预计算）。
学习成本高：开发和运维人员需理解属性规则逻辑。

6. 适用场景

云原生系统 、微服务架构 、多租户系统 、数据安全要求高 （如金融、医疗、政务）、权限规则动态变化的场景。

四、RBAC vs ABAC 核心对比

维度	RBAC	ABAC
核心	角色为中心，权限静态绑定角色	属性为中心，权限动态计算规则
粒度	粗 / 中粒度（菜单、接口级）	细粒度（行级、字段级、上下文级）
灵活性	低，角色固化	高，规则动态调整
管理复杂度	低，易维护	高，规则复杂
性能	高，权限可缓存	中 / 低，需实时计算规则
开发成本	低，成熟方案多	高，需自定义规则引擎
适用场景	企业内部系统、权限稳定场景	云服务、多租户、高安全场景

五、系统设计实践：权限模块核心架构

1. 权限模块分层（推荐）

接入层 ：API 网关 / 拦截器，统一拦截请求，提取主体、客体、操作、环境信息。
决策层 ：权限引擎（RBAC 角色判断 + ABAC 规则计算），返回允许/拒绝。
数据层：存储用户、角色、权限、属性、规则数据（数据库 + 缓存）。
管理层：后台管理界面（角色管理、权限分配、规则配置）。

2. 数据模型设计（核心表）

（1）RBAC 核心表

user（用户表）：user_id, username, password, status...
role（角色表）：role_id, role_name, description...
permission（权限表）：permission_id, permission_name, resource (客体), action (操作), description...
user_role（用户 - 角色关联）：user_id, role_id
role_permission（角色 - 权限关联）：role_id, permission_id

（2）ABAC 扩展表（可选）

subject_attribute（主体属性）：user_id, attr_key, attr_value（如部门、职级）
object_attribute（客体属性）：resource_id, attr_key, attr_value（如所属部门、敏感级别）
environment_attribute（环境属性）：规则中动态获取，无需存储（如时间、IP）
abac_rule（规则表）：rule_id, rule_name, rule_expression（规则表达式）, status...

3. 权限校验流程（通用）

请求拦截 ：用户请求接口，网关 / 拦截器获取用户ID、资源ID、操作类型、环境信息。
身份认证：验证用户身份（Token / 会话）。
权限决策 ：
- RBAC：查询用户关联的角色，再查询角色关联的权限，判断是否包含资源+操作。
- ABAC：加载相关属性，执行规则引擎，判断是否满足规则。
- 混合模式：先 RBAC 粗筛，再 ABAC 细控（推荐）。
结果返回：允许则放行，拒绝则返回 403 Forbidden。

4. 混合模式（RBAC + ABAC，推荐）

RBAC 负责粗粒度：菜单、接口级权限（如 "财务能访问报表模块"）。
ABAC 负责细粒度：数据行级、字段级、上下文级权限（如 "财务仅能查看自己部门的报表，且仅工作日可编辑"）。
优势：兼顾易管理 和灵活性，是企业级系统的主流方案。

六、关键设计要点

权限最小化：仅授予用户完成工作所需的最小权限。
职责分离：关键操作（如支付、删除）需多人审批，避免单人权限过大。
缓存优化：RBAC 权限缓存用户 - 角色 - 权限关系，ABAC 缓存属性数据，减少重复计算。
日志审计：记录所有权限校验结果、操作日志，便于追溯和安全审计。
动态扩展：支持权限规则热更新（无需重启服务），适配业务变化。
多租户适配 ：ABAC 通过租户ID属性实现多租户数据隔离，RBAC 通过租户-角色关联实现。

七、RBAC与ABAC总结

RBAC ：简单、易管理，适合企业内部、权限稳定的系统，是权限设计的基础。
ABAC ：灵活、细粒度，适合云服务、多租户、高安全的系统，是复杂权限的解决方案。
混合模式 ：RBAC + ABAC，兼顾管理成本和灵活性，是企业级系统权限设计的最优实践。
核心本质：无论哪种模型，最终都是解决 **"谁能对什么做什么"** 的问题，需根据业务复杂度、安全要求、开发成本选择合适的方案。

数据权限

数据权限，实现指定用户可以操作指定范围的数据。例如说，针对员工信息的数据权限：

用户	数据范围
普通员工	自己
部门领导	所属部门的所有员工
HR 小姐姐	整个公司的所有员工

上述的这个示例，使用硬编码是可以实现的，并且也非常简单。但是，在业务快速迭代的过程中，类似这种数据需求会越来越多，如果全部采用硬编码的方式，无疑会给我们带来非常大的开发与维护成本。

权限可以分成三类：功能权限、数据权限、字段权限。

字段权限的控制，不属于数据权限，而是属于字段权限。

1. 实现原理

data-permission 技术组件的实现原理非常简单，每次对数据库操作时，他会自动拼接 WHERE data_column = ? 条件来进行数据的过滤。

例如说，查看员工信息的功能，对应 SQL 是 SELECT * FROM system_users，那么拼接后的 SQL 结果会是：

用户	数据范围	SQL
普通员工	自己	`SELECT * FROM system_users WHERE id = 自己`
部门领导	所属部门的所有员工	`SELECT * FROM system_users WHERE dept_id = 自己的部门`
HR 小姐姐	整个公司的所有员工	`SELECT * FROM system_users` 无需拼接

明白了实现原理之后，想要进一步加入理解，后续可以找时间 Debug 调试下

2. 基于部门的数据权限

一般的成熟开发很久的项目都会有基于部门的数据权限，支持 5 种数据范围：

全部数据权限：无数据权限的限制。
指定部门数据权限：根据实际需要，设置可操作的部门。
本部门数据权限：只能操作用户所在的部门。
本部门及以下数据权限：在【本部门数据权限】的基础上，额外可操作子部门。
仅本人数据权限：相对特殊，只能操作自己的数据。

#2.1 后台配置

可设置用户角色的数据权限。

2.2 字段配置

配置哪些表的哪些字段，进行数据权限的过滤

复制代码

 // dept 基于部门的数据权限
            rule.addDeptColumn(AdminUserDO.class); // WHERE dept_id = ?
            rule.addDeptColumn(DeptDO.class, "id"); // WHERE id = ?
            
            // user 基于用户的数据权限
            rule.addUserColumn(AdminUserDO.class, "id"); // WHERE id = ?
//            rule.addUserColumn(OrderDO.class); // WHERE user_id = ?

注意，数据库的表字段必须添加：

基于【部门】过滤数据权限的表，需要添加部门编号字段，例如说 dept_id 字段。
基于【用户】过滤数据权限的表，需要添加部门用户字段，例如说 user_id 字段。

3. C# 特性标注权限 JAVA@DataPermission 注解

数据权限注解，可声明在类或者方法上，配置使用的数据权限规则。

4. 自定义的数据权限规则

如果想要自定义数据权限规则，只需要实现数据权限规则接口

#getTableNames() 方法：哪些数据库表，需要使用该数据权限规则。
#getExpression(...) 方法：当操作这些数据库表，需要额外拼接怎么样的 WHERE 条件。

下面，艿艿带你写个自定义数据权限规则的示例，它的数据权限规则是：

针对 system_dict_type 表，它的创建人 creator 要是当前用户。
针对 system_post 表，它的更新人 updater 要是当前用户。

业务系统衍生

常见设计模式

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

系统会识别用户，然后根据被操作对象（Subject）的权限控制列表（ACL: Access Control List）或者权限控制矩阵（ACL: Access Control Matrix）的信息来决定用户的是否能对其进行哪些操作，例如读取或修改。

而拥有对象权限的用户，又可以将该对象的权限分配给其他用户，所以称之为"自主（Discretionary）"控制。

这种设计最常见的应用就是文件系统的权限设计，如微软的NTFS。

DAC最大缺陷就是对权限控制比较分散，不便于管理，比如无法简单地将一组文件设置统一的权限开放给指定的一群用户。

Windows的文件权限

强制访问控制（MAC: Mandatory Access Control）

MAC是为了弥补DAC权限控制过于分散的问题而诞生的。在MAC的设计中，每一个对象都都有一些权限标识，每个用户同样也会有一些权限标识，而用户能否对该对象进行操作取决于双方的权限标识的关系，这个限制判断通常是由系统硬性限制的。比如在影视作品中我们经常能看到特工在查询机密文件时，屏幕提示需要"无法访问，需要一级安全许可"，这个例子中，文件上就有"一级安全许可"的权限标识，而用户并不具有。

MAC非常适合机密机构或者其他等级观念强烈的行业，但对于类似商业服务系统，则因为不够灵活而不能适用。

MAC 不是 ABAC，二者是两种不同的访问控制模型，核心设计理念和判定逻辑有本质区别。

1. 核心定义与判定逻辑差异

特性	强制访问控制（MAC）	基于属性的访问控制（ABAC）
核心逻辑	基于主体和客体的安全标签 / 等级进行强制匹配，规则由系统全局定义且不可被用户修改。	基于主体、客体、环境的多维度属性，通过动态策略规则判定访问权限。
权限标识	主体（用户）有安全等级（如绝密、机密、秘密），客体（文件）有对应安全等级，访问需满足等级匹配规则（如主体等级 ≥ 客体等级）。	主体属性（部门、角色、职级）、客体属性（文件类型、创建时间）、环境属性（访问时间、IP 地址），通过策略引擎动态计算是否允许访问。
灵活性	规则固定、刚性，无灵活性，适合高安全等级场景。	规则可动态配置、灵活扩展，支持复杂业务场景。
控制权	完全由系统管理员 / 安全策略控制，用户无法自主分配权限。	由策略规则控制，可根据业务需求随时调整属性和规则。

2. 举例区分

MAC 场景 ：涉密系统中，一份标注为 "绝密" 的文件，只有安全等级为 "绝密" 的用户才能访问，即使是文件创建者，若自身等级为 "机密"，也无法访问该文件，规则由系统强制设定，无法修改。
ABAC 场景 ：企业 OA 系统中，策略规则为 "市场部员工在工作时间（9:00-18:00）可以访问本部门的 2025 年销售报表" 。这里的判定条件包含：
- 主体属性：部门 = 市场部
- 客体属性：文件类型 = 销售报表、年份 = 2025、归属部门 = 市场部
- 环境属性：访问时间 ∈ 9:00-18:00只要满足这些属性组合，即可访问，规则可随时调整（如新增 "仅限公司内网 IP" 的环境属性）。

3. 与 "用户字段权限" 的关系

"用户字段权限" 一般指针对数据字段级别的细粒度权限控制 （比如只允许查看客户姓名，不允许查看手机号），它是权限控制的粒度维度，而非独立模型。

MAC 通常是粗粒度的，多针对整个文件 / 资源的访问权限，而非字段。
ABAC 天然支持细粒度控制，可以通过定义 "客体属性 = 字段名称" 来实现字段级权限（如 "仅允许财务人员查看薪资字段"）。

MAC与ABAC 区别总结

MAC 是 "等级驱动、强制匹配" 的刚性模型，适用于军工、政府涉密等强安全需求场景。
ABAC 是 "属性驱动、动态判定" 的灵活模型，适用于企业级复杂业务系统。
二者没有包含关系，也不是同一概念。

其他：

业务系统设计 权限系统 MAC、DAC、RBAC、ABAC 、核心概念（主体 / 客体 / 用户 - 角色 - 对象）、及数据权限

权限系统设计：RBAC、ABAC 及核心概念（主体 / 客体 / 用户 - 角色 - 对象）、及数据权限

MAC、DAC、RBAC、ABAC 四种访问控制模型对比表

一、核心基础概念

1. 主体（Subject）

2. 客体（Object/Resource）

3. 操作（Action）

4. 权限（Permission）

5. 用户 - 角色 - 对象（User-Role-Object）

二、RBAC（基于角色的访问控制）

1. 核心思想

2. 核心模型（RBAC0~RBAC3，常用 RBAC0/RBAC1）

（1）RBAC0（基础版）

（2）RBAC1（角色继承）

（3）RBAC2（职责分离）

（4）RBAC3（统一模型）

3. 优点

4. 缺点

5. 适用场景

三、ABAC（基于属性的访问控制）

1. 核心思想

2. 核心属性维度

3. 核心规则示例（伪代码）

4. 优点

5. 缺点

6. 适用场景

四、RBAC vs ABAC 核心对比

五、系统设计实践：权限模块核心架构

1. 权限模块分层（推荐）

2. 数据模型设计（核心表）

（1）RBAC 核心表

（2）ABAC 扩展表（可选）

3. 权限校验流程（通用）

4. 混合模式（RBAC + ABAC，推荐）

六、关键设计要点

七、RBAC与ABAC总结

数据权限

1. 实现原理

2. 基于部门的数据权限

#2.1 后台配置

2.2 字段配置

3. C# 特性标注权限 JAVA@DataPermission 注解

4. 自定义的数据权限规则

业务系统衍生

常见设计模式

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

强制访问控制（MAC: Mandatory Access Control）

MAC 不是 ABAC，二者是两种不同的访问控制模型，核心设计理念和判定逻辑有本质区别。

1. 核心定义与判定逻辑差异

2. 举例区分

3. 与 "用户字段权限" 的关系

MAC与ABAC 区别 总结

其他：

C#.net 分布式ID之雪花ID，时钟回拨是什么？怎么解决？

【电商 】订单减少库存业务流程，分布式ID策略选型，C# .net雪花ID代码，下单功能实现 ，异步延时队列

Net 模拟退火，遗传算法，禁忌搜索，神经网络 ，并将 APS 排程算法集成到 ABP vNext 中

SAAS多租户套餐权限模块功能按钮 设置 关键代码实现 JAVA C#

在C# .net中RabbitMQ的核心类型和属性，除了交换机，队列关键的类型 / 属性，影响其行为

业务系统设计权限系统 MAC、DAC、RBAC、ABAC 、核心概念（主体 / 客体 / 用户 - 角色 - 对象）、及数据权限

MAC与ABAC 区别总结

【电商】订单减少库存业务流程，分布式ID策略选型，C# .net雪花ID代码，下单功能实现，异步延时队列

Net 模拟退火，遗传算法，禁忌搜索，神经网络，并将 APS 排程算法集成到 ABP vNext 中

SAAS多租户套餐权限模块功能按钮设置关键代码实现 JAVA C#