企业级权限系统怎么设计 —— 数据权限控制
功能权限解决了“用户能做什么操作”的问题，但企业应用中还有另外一种权限：用户能对哪些数据进行这些操作？即数据权限。
一个典型的场景是：销售部的张三和李四都能使用“查看订单”的功能，但张三可能只能看自己负责的订单，而李四作为经理，可以看到本部门所有销售的订单。这就是数据权限在起作用。
注：本文不仅总结了常见的数据权限设计方案，也整理了更复杂但尚未完全落地的模型，供未来扩展和复杂场景参考。
数据权限的构成：行级权限与列级权限
数据权限一般包含两大维度：行级权限和列级权限。
行级权限控制“哪些记录”可见，比如某用户只能查看自己的订单、本部门的订单或指定部门的数据等。
列级权限控制“哪些字段”可见，比如一个用户只能看到客户表中的姓名和联系方式，其他敏感字段（如身份证号、收入）不可见，或需要脱敏处理。
可以理解为：行级权限决定数据的范围，列级权限决定访问的数据内容（字段）。
实现方案的演进
下边我们逐步用更加灵活的模型来支持不同复杂度的业务，当然越灵活的模型带来运维成本，技术复杂度也在逐步提升，在实际场景中请合理选择。
方式一：硬编码 —— 适用简单场景
最直接的做法是在 sql 或代码中写死限制逻辑。
-- 仅查看本部门及下属部门数据的示例
-- 查询仅查看自己数据
SELECT * FROM orders WHERE user_id = #{currentUserId};
-- 查询本部门及下级部门数据，部门ID集合作为参数传入
SELECT * FROM orders WHERE dept_id IN (#{deptIdList});优点： 快速实现，适合固定规则。
缺点： 灵活性差，无法动态配置，维护成本高。
方式二：RBAC + 数据范围 —— 覆盖主流归属场景
在权限点绑定的基础上，加上数据范围的控制。
表结构示例：
| role_id | permission_code | data_scope |
|---|---|---|
| r001 | TRANSFER_QUERY | DEPT_AND_BELOW |
| r002 | LOAN_APPROVE | SELF |
| r003 | CUSTOMER_QUERY | CUSTOM_DEPT(dept1, dept2) |
data_scope 字段常见取值：
SELF：仅本人数据
DEPT：本部门数据
DEPT_AND_BELOW：本部门及下级部门
ALL：所有数据
CUSTOM_DEPT(dept1, dept2)：指定多个部门
方式三：策略表达式模式 —— 表达更复杂的数据规则
角色r001在权限点5001绑定了策略p001
| subject_type | subject_id | permission_point_id | policy_id |
|---|---|---|---|
| role | r001 | 5001 | p001 |
DATA_POLICY
策略p001是一个高金额审批策略，其中前置条件pre_condition_expr可提前判断不需要sql拼装是策略的前置过滤条件，一般用于短路判断，如果不满足就直接拒绝
| policy_id | policy_code | policy_name | pre_condition_expr | enabled |
|---|---|---|---|---|
| p001 | HIGH_AMOUNT_APPROVAL | 高金额审批策略 | true |
DATA_POLICY_GROUP
策略p001有两个条件组g001和g002，条件组g001如果配置多个条件则为AND关系，条件组g002如果有多个条件则为OR关系
| id | policy_id | group_code | name | logical_op |
|---|---|---|---|---|
| g001 | p001 | GRP_AMOUNT_CHECK | 金额检查组 | AND |
| g002 | p001 | GRP_STATUS_REGION | 状态或地区组 | OR |
DATA_POLICY_CONDITION
条件组g001只有一个条件为amount>500000，条件g002有两个条件状态为approved，或者区域为华北
| id | group_id | field | operator | value_type | value_expr |
|---|---|---|---|---|---|
| 1 | g001 | amount | const | 500000 | |
| 2 | g002 | status | = | const | approved |
| 3 | g002 | region | = | const | 华北 |
方式四：ABAC 模型 —— 适用于复杂/平台级系统
ABAC（Attribute-Based Access Control）模型，从“属性”出发控制访问，属性可来自用户、资源或环境，适用于复杂动态的权限决策（既能控制功能权限，也能控制数据权限）。
ABAC 模型强调策略与主体解耦，通常采用如下结构：
ABAC_BINDING
用户u001和角色r001分别都绑定了策略p001
| subject_type | subject_id | policy_id |
|---|---|---|
| user | u001 | p001 |
| role | r001 | p001 |
ABAC_POLICY
策略p001针对资源loan的approve生效，其中前置条件pre_condition_expr可提前判断不需要sql拼装
| policy_id | policy_code | policy_name | resource | action | pre_condition_expr | enabled |
|---|---|---|---|---|---|---|
| p001 | HIGH_AMOUNT_APPROVAL | 高金额审批策略 | loan | approve | true |
ABAC_POLICY_GROUP
策略p001有两个条件组g001和g002，条件组g001如果配置多个条件则为AND关系，条件组g002如果有多个条件则为OR关系
| id | policy_id | group_code | name | logical_op |
|---|---|---|---|---|
| g001 | p001 | GRP_AMOUNT_CHECK | 金额检查组 | AND |
| g002 | p001 | GRP_STATUS_REGION | 状态或地区组 | OR |
ABAC_POLICY_CONDITION
条件组g001只有一个条件为amount>500000，条件g002有两个条件状态为approved，或者区域为华北
| id | group_id | field | operator | value_type | value_expr |
|---|---|---|---|---|---|
| 1 | g001 | amount | const | 500000 | |
| 2 | g002 | status | = | const | approved |
| 3 | g002 | region | = | const | 华北 |
为什么需要 resource 和 action 字段？
resource标识策略适用的资源对象，比如order、loan、customer等；action标识操作行为，比如view（查看）、edit（编辑）、approve（审批）等；
通过资源 + 动作联合定位，可以让一条策略精准适配对应的操作上下文，避免因资源或动作不同导致误匹配。
同时也方便后续支持不同资源下的统一权限管理。
为什么需要 ABAC_BINDING 表？
性能考虑：通过绑定用户或角色，快速缩小策略检索范围，避免海量策略全表扫描。
灵活配置：既可以针对单个用户授权，也可以针对角色、组织授权，适配不同组织模型。
管理方便：权限配置界面可以更清晰地展现策略与用户/角色的对应关系。
