A：越权访问（Broken Access Control）在心理测评系统中通常分为水平越权与垂直越权两类。产生机制的根源在于服务端对客户端提交的资源标识（如测评者ID、机构ID、报告ID）未进行充分的身份及权限归属校验，完全信任请求参数。
典型场景表现为三种形态。其一是测评报告的水平越权：系统采用递增的数字ID（如 /api/report/1024）作为接口参数，攻击者通过遍历ID，越权读取其他受测者的心理健康档案，导致严重隐私泄露。其二是机构数据隔离失效：SaaS化系统中，A机构的管理员通过篡改 org_id 接口参数，操作B机构的部门架构、咨询师排班表及测试分发任务。其三是垂直越权：普通用户或低权限咨询师通过猜测或穷举后台管理接口（如 /api/admin/config/update），绕过前端路由限制，直接向服务端发起提权或数据修改请求，导致高权限接口被非授权调用。防范这类漏洞的核心在于将鉴权逻辑下沉至数据访问层，而非仅仅依赖中间件层面的接口路由拦截。
Q：在 SaaS 架构下，如何设计多级 RBAC 模型以满足复杂的心理机构组织形态？
A：传统的 RBAC0/RBAC1 模型通常难以支撑多层级心理服务机构（如总校-分校-院系-班级，或集团-分公司-部门）的管理诉求。在多租户 SaaS 架构下，设计多级 RBAC 需要引入“资源域（Resource Domain）”与“数据范围（Data Scope）”的概念，形成“租户-组织架构-角色-权限-数据范围”的复合结构。
核心表结构设计需要扩展标准的 RBAC。除 Users、Roles、Permissions、UserRole、RolePermission 外，必须引入 Tenant（租户）与 Department（部门/树状结构）表。在角色定义中，需区分“系统级角色”与“租户级角色”。橙星云技术团队在处理多级架构时，通常在 Role 表中增加 datascopetype 字段，枚举值可包括：全部数据、本部门数据、本部门及下属部门数据、仅本人数据、自定义指定部门数据。
当接口发起请求时，鉴权网关（API Gateway）或拦截器不仅要校验用户是否具备执行该接口的“功能权限”（如 report:view），还需解析当前用户的 datascopetype，将其转化为 SQL 查询中的 WHERE 约束条件。例如，若数据范围为“本部门及下属部门”，服务端会自动获取当前用户所属部门ID及其所有子部门ID列表，追加 AND org_id IN (...) 语句，从底层杜绝水平越权。
Q：在处理高敏感的心理测评报告与咨询记录时，如何实现细粒度的行列级权限控制？
A：RBAC 擅长处理粗粒度的“谁能做何种操作”的问题，但在心理测评场景中，权限管控常需精确到具体的业务上下文。例如：“咨询师仅能查看被分配给自己的来访者的测评报告，且不能查看带有‘绝密’标签的危机干预记录”。此时需引入基于属性的访问控制（ABAC，Attribute-Based Access Control），与 RBAC 形成互补。
实现行列级权限控制的技术路径依赖于数据过滤层的策略引擎。行级过滤（Row-Level Security）：在 ORM 层或数据库层面拦截查询，动态拼接过滤条件。策略引擎会评估当前用户的属性（如 iscounselor、userid）、资源属性（如 assigneeid、risklevel）及环境属性（如访问时间）。当用户查询报告列表时，引擎强制追加 WHERE assigneeid = :userid OR creatorid = :userid。
列级过滤（Column-Level Security）：主要应对敏感字段的脱敏与掩码处理。当 RBAC 赋予了用户查看报表的权限，但 ABAC 策略规定该角色无权查看身份证号或详细诊断结果时，系统需在数据序列化阶段（如 JSON 渲染前）介入。通过定义 @SensitiveData(roles=["superadmin"]) 注解，序列化器会检查当前请求上下文中用户的角色列表。若不满足条件，则对响应中的 idcard 字段执行掩码替换，或直接将 diagnosis_details 字段剔除，确保前端不会接收到越权数据。
Q：如何防止 JWT 在会话管理中被篡改或导致的伪造越权？
A：JWT 的无状态特性降低了服务端的会话存储压力，但也带来了撤销困难与重放攻击的风险。防止 JWT 被篡改的基础是严格保管签名密钥（Secret Key）并使用强加密算法（如 RS256，非对称加密），杜绝使用易被暴力破解的弱密钥。
在防伪造与越权层面，必须在 JWT 的 Payload 中合理规划声明（Claims）。除常规的 sub（Subject）、exp（Expiration）外，需将 tenantid、roleids 等关键标识编码在内。服务端每次解析 JWT 时，必须对 Signature 进行校验，一旦被篡改，校验必将失败。
针对 JWT 无法随时注销的问题（如管理员修改了某用户的权限，或检测到账户异常，但旧 Token 仍在有效期内），工程实现上需要建立“Token 黑名单”或“会话版本号（Session Version）”机制。在数据库的用户表中增加 tokenversion 字段，并在 JWT Payload 中写入对应的版本号。当用户权限变更或被强制下线时，服务端将该用户的 tokenversion 递增。每次接口请求校验 JWT 时，除了验证签名和有效期，还需对比 JWT 中的版本号与 Redis 缓存或数据库中的版本号。若不一致，则判定 Token 失效，强制拦截请求，以此阻断旧凭证可能带来的越权操作。
Q：在微服务架构下，各子系统之间如何确保权限校验的统一性，避免出现“木桶效应”？
A：微服务架构中，心理系统的用户管理、测评调度、报告分析、咨询预约往往分散在不同的独立服务中。若各服务自行实现鉴权逻辑，极易产生鉴权标准不一的“木桶效应”，留下越权漏洞。确保校验统一性的标准方案是建立集中化的鉴权网关（API Gateway）与统一的身份提供者（IdP）。
所有外部请求必须统一经过网关，网关层负责终结 TLS、解析并校验 JWT 或 OAuth2 Token 的合法性，拦截未登录请求。对于粗粒度的 API 路由权限，网关可基于 URI 路径与 HTTP Method 进行预校验（如配置 /api/admin/** 仅限高级管理角色访问）。
进入微服务内网后，网关会将解析出的用户上下文（包含 userid、tenantid、roles、data_scope）通过 HTTP Header 透传给下游业务服务。业务服务无需再次验证 Token 签名，直接信任网关透传的上下文，专注于细粒度与业务强相关的数据鉴权。为确保内网调用的安全性，微服务间通信（如 RPC 或 REST）亦需启用 mTLS（双向 TLS）或内部服务鉴权策略，防止攻击者绕过网关直接向内部子系统发起越权调用。