第1章 权限验收整体排查框架
权限验收是B2B产品上线前最易被低估的环节。一次遗漏可能导致客户全租户数据泄漏或功能瘫痪。本章从现象识别到预防，建立可复用的六阶段排查框架，包含故障树、数据采集清单和判断规则，作为后续29章的问题排查总纲。
1.1 现象识别 — 权限验收失败的典型表现
以下现象是权限验收最常见的“报警”信号，一旦出现应立即启动排查流程：
- 403/401返回：用户登陆后访问特定资源或API返回HTTP 403或401。
- 数据越权：普通用户能看到或操作本应属于管理员的数据（如订单列表、组织架构）。
- 权限未生效：新增角色或修改权限策略后，用户行为与策略预期不符。
- 角色继承异常：子部门用户未继承父部门的角色权限，或意外继承了上级权限。
1.2 数据采集清单 — 排查前必须获取的输入
在定位原因前，需系统化收集以下数据。缺失任意一项都可能误判根因：
| 数据类别 | 具体内容 | 采集来源 |
|---|---|---|
| 用户角色分配 | 用户ID、用户名、所属部门、关联角色列表 | 用户中心 / IDP（身份提供者） |
| 权限策略配置 | 策略名称、资源路径、Action列表、条件表达式 | 权限管理服务（如IAM） |
| 访问日志 | 时间戳、请求者、目标资源、授权结果（allow/deny） | API网关 / 应用日志 |
| 角色-权限映射 | 角色与策略的绑定关系、继承链 | 角色管理数据库 |
| 环境差异 | 测试环境与生产环境的配置差异（用户、策略、缓存） | 配置中心 / CI管道 |
1.3 故障树结构 — 定性辅助排查
故障树将顶层问题“权限验收失败”向下分解，帮助快速锁定排查方向。以下SVG图展示核心分支：
1.4 排查流程总览 — 六阶段执行顺序
以下步骤是每次权限验收的标准操作流程，建议将环节固化到验收Checklist中：
- 现象识别：记录重现条件、错误信息、影响范围。
- 数据采集：按1.2清单收集齐备开始分析。
- 原因定位：利用故障树缩小范围，检查配置、数据和代码。
- 修复动作：修正策略、刷新缓存或回滚代码，并记录变更。
- 复测：使用原始用例重新验证，确认修复无副作用。
- 预防：将本次根因录入预防清单，补充自动化检测点。
1.5 常见判断规则 — 快速决策卡
下表总结在定位阶段常用的判断规则，可减少试错次数：
| 现象 | 排查入口 | 判断规则 |
|---|---|---|
| 403且日志无deny记录 | 检查API网关鉴权中间件是否在权限服务之前拒绝 | 如果API网关无对应策略，则属于网关配置缺失；否则检查权限服务返回 |
| 角色已分配但权限未生效 | 查看角色-策略绑定时间戳 vs 用户会话创建时间 | 若绑定发生在用户会话之后，需重新登录或清除会话缓存 |
| 数据越权（A用户看到B用户数据） | 检查数据层Filter或视图级别权限条件 | 若SQL语句未携带租户ID过滤，则属于代码漏传租户上下文 |
| 测试环境通过，预发布/生产失败 | 对比环境的权限配置与角色映射差异 | 优先检查环境变量、外部IDP连接、数据库种子数据 |
1.6 常见误区
- 误区一：只验通过用例，忽略负面用例 —— 必须验证“非授权用户访问失败”和“授权用户访问成功”双向。
- 误区二：以为缓存立即刷新 —— 多数权限引擎使用分布式缓存（Redis TTL 5～15分钟），修改策略后需等待或手动清除。
- 误区三：仅靠日志输出定位 —— 日志可能被框架层吞掉（如Spring Security的AccessDeniedHandler），应结合链路追踪或API调试工具。
1.7 预防清单（面向验收团队）
每次权限验收交付后，需将以下检查项更新到团队知识库：
- 新增权限策略是否经过自动化规则校验（格式、资源路径、Action枚举）
- 是否在CI管道中集成“权限回归测试”（基于Postman/Newman或Gatling）
- 权限配置变更是否记录变更审计日志，并通知验收团队
- 是否在灰度环境执行一轮完整的角色-资源矩阵测试
- 是否建立缓存刷新SOP并与发布流程绑定
实践建议： 将故障树的每个叶子节点映射到《权限验收自查清单》的具体行项。当出现新故障时，先在故障树上打标签，补充条目到预防清单，形成正反馈循环。