Web权限模型合规审计核心是验证最小权限、角色分离与操作可追溯性，需将GB/T 22239—2019等标准转化为可检测项，通过Burp Suite、OWASP ZAP等工具组合执行角色隔离、字段级控制、日志完整性等检查，并输出带法规依据和原始证据的闭环报告。
直接用安全评估工具对 Web 环境下的用户权限模型做合规审计，关键不是“扫出漏洞”，而是验证权限设计是否符合最小权限、角色分离、操作可追溯等合规要求。工具只是手段，核心是把标准条款（如 GB/T 22239—2019、《个人信息保护法》）转化为可检测的检查项。
明确审计目标：从“能登录”到“权责匹配”
权限模型合规审计不等于功能测试。重点验证三类事实：
- 系统是否真正实现三权分立——系统管理员、安全管理员、审计员三个角色在后台权限表、API接口、管理界面中是否物理隔离，且无交叉授权能力；
- 普通用户权限是否达到“字段级”控制——例如数据库操作是否限制到具体表的某几列，而非整张表；
- 所有权限变更行为是否被完整记录——包括谁、何时、对哪个用户/角色、做了哪项授权或取消操作，日志是否防篡改、不可删除。
选择并配置适配的评估工具
不同工具侧重点不同，需组合使用：
- Burp Suite + 自定义插件：用于人工验证权限越界。例如以低权限用户身份登录后，手动修改请求中的 user_id 或 role_id，观察是否能访问高权限接口（如 /api/v1/admin/users）；
- OWASP ZAP 或 Netsparker：启用“权限覆盖扫描”插件（非默认），主动探测未授权访问路径，识别缺失权限校验的 REST 接口；
- WATOBO：特别适合会话级权限审计。开启代理后，重放同一用户在不同角色状态下的请求，比对响应差异，快速发现角色切换未生效、缓存导致的权限残留等问题；
- SQLMap 配合手工验证：当怀疑权限数据存储在数据库中时，用 --tables 和 --dump 检查 sys_role_permission、sys_user_role 等表结构是否包含资源粒度（如字段名、操作类型）、是否允许空角色或通配符权限。
执行可落地的检查步骤
避免泛泛而谈“检查权限配置”，聚焦可验证动作：
- 导出系统全部角色定义与关联权限清单，用脚本比对是否满足“最小权限”——例如财务角色不应拥有 /api/v1/system/logs 的 GET 权限；
- 以审计员账号登录，尝试访问 /admin/user/create 或 /api/v1/role/assign，确认返回 403 且无任何后端逻辑执行痕迹；
- 触发一次权限分配操作（如安全管理员给用户 A 分配“报表查看”角色），立即检查审计日志表，确认日志含操作人ID、目标用户ID、角色ID、时间戳、IP地址，且该日志无法通过Web界面或SQL语句删除；
- 检查密码重置、令牌发放等敏感操作是否强制二次认证——Burp 抓包后移除 X-OTP-Token 头，验证是否拒绝执行。
输出符合监管要求的审计证据
合规审计报告不是技术漏洞列表，而是责任闭环证明：
- 每项检查需标注对应法规条目，例如“GB/T 22239—2019 第6.2.2.3条：应授予管理用户所需的最小权限”；
- 截图+原始请求/响应佐证，如审计日志查询SQL语句及返回结果、Burp中越权请求的403响应体；
- 对不满足项，区分“配置缺陷”（如角色绑定了多余权限）和“架构缺陷”（如无审计员独立账号入口），后者需升级方案而非简单调参；
- 附上权限模型ER图（含用户、角色、权限、资源四张表关系）及关键字段说明，证明设计层面已支持字段级控制。
