微服务架构下基于认证用户的行级数据权限实现方案咨询

背景与核心需求 #

公司运营多个Project，拥有大量Employee，员工分为两类角色：SysAdmin（可编辑/查看项目）、SysUsers（仅只读访问）。目前API层通过JWT获取用户Role做粗粒度权限校验，但现在需要实现行级数据过滤：特定员工仅能访问关联的特定Project数据——比如某SysAdmin用户只能查看Project1、5的项目列表，以及这两个项目关联的账单数据，且系统内所有服务的实体都需要这类权限控制。

已构思的四种方案 #

• 方案1：令牌内嵌可访问项目ID
  将用户可访问的所有Project ID放入JWT，各服务通过ExecutionContextAccessor获取后过滤数据。但扩展性差，新增其他实体的权限控制时无法适配。
• 方案2：中心化权限服务实时调用
  所有权限统一维护在UserAccess服务，各服务执行操作前先调用该服务获取权限再过滤数据。缺点是服务间耦合度高，每次请求都依赖权限服务，易引发性能瓶颈和可用性风险。
• 方案3：各服务独立维护权限
  每个服务定义自身的权限实体（比如Projects服务的ProjectPermissions、Billing服务的BillingPermissions），新增用户时通过集成事件同步UserId到各服务。但权限数据分散，难以统一管理，新增权限规则时需要修改多个服务。
• 方案4：中心化维护+本地缓存副本
  权限统一在UserAccess服务维护，权限变更时触发集成事件，其他服务同步权限副本到本地，实现本地过滤无需实时调用权限服务。兼顾了统一管理和低耦合，但需要处理权限同步的一致性问题。

业内其他可行实践方案 #

• 基于策略的权限引擎（OPA）
  引入独立的权限引擎服务，把所有权限规则（包括行级过滤逻辑）统一写成策略文件，各服务执行操作前向OPA发送请求（携带用户信息、操作类型、数据上下文），OPA返回是否允许访问或过滤后的数据集。这种方式解耦业务服务和权限逻辑，规则变更不用改业务代码，还支持复杂的行级过滤规则。
• 数据库层动态过滤
  在各服务的数据库访问层（比如ORM拦截器、数据库视图）实现动态过滤逻辑。比如基于当前用户ID，自动给SQL查询添加WHERE project_id IN (SELECT project_id FROM user_project_permissions WHERE user_id = ?)这类条件。把过滤逻辑下沉到数据层，业务代码不用关注权限过滤，减少重复代码，但要保证各服务的权限数据同步到位。
• GraphQL网关层集中过滤
  如果系统用GraphQL做API网关，可以在网关层实现行级权限过滤。网关解析用户请求后，先获取用户的权限范围，再在查询时动态添加过滤条件，确保返回的数据只有用户有权访问的行。这种方式适合GraphQL架构，避免各服务重复写过滤逻辑，但对REST架构不太适用。
• 属性基访问控制（ABAC）模型
  基于用户属性（角色、部门）、资源属性（项目ID、所属部门）和环境属性（时间、IP）定义权限规则，比如“部门A的SysAdmin可访问部门A下的所有项目”。各服务通过评估这些属性过滤数据，比角色基（RBAC）更灵活，适合复杂的行级权限场景，还能结合权限引擎统一管理规则。

内容的提问来源于stack exchange，提问作者isaranghi