旧系统权限重构，菜单之外还要控制动作与数据

哪些权限模型适合当前规则

用业务矩阵重新描述现有权限

矩阵包括谁对什么资源做什么动作，以及能看到哪一部分数据。菜单权限只是其中一个展示条件，不能代表完整授权。

从合同、客户、订单和报表等资源开始，列出读取、修改、审批、导出和删除。再由业务负责人确认本人、部门、下级组织及跨组织范围。多个角色合并时要明确冲突如何处理；不要仅复制旧权限表，否则长期累积的例外会被原样带到新策略中。

• 为资源与动作定义稳定标识，避免只使用菜单名称。
• 明确每个角色的数据范围、批准人及业务依据。
• 登记历史权限的保留、收回和待确认结论。

服务端执行授权，所有入口遵守同一规则

网页按钮、小程序页面和客户端路由可改善使用体验，授权决定应由服务端在实际处理资源时执行。知道对象编号不应意味着拥有访问权。

查找控制器、下载地址、后台任务和内部接口里的权限判断，识别遗漏和重复实现。资源查询也要限制范围，避免查询全部数据后再在页面隐藏。统一判断组件可以减少分散逻辑，但每种资源仍需要正确的归属条件；一个通用“已登录”中间件不足以承担业务授权。

授权使用的部门、对象归属和业务状态应来自可信数据，不能直接相信客户端提交的组织编号。更新和删除前还要核对当前状态，避免查询时允许、处理时条件已经变化。并发修改涉及的约束按实际事务边界验证。

• 对每次敏感请求验证动作和目标资源权限。
• 文件下载、导出与接口调用同样执行数据范围检查。
• 授权判定失败时安全拒绝，保留可定位的原因。

临时授权和管理员操作保留具体边界

客服代操作、跨部门协作和应急管理有真实需求，但应有范围、时限和审计。无法解释的管理员万能权限会削弱整个模型。

把例外写成对象范围、允许动作、理由、批准记录和失效条件。批量导出、金额调整等高影响操作可以设置额外审批或复核，是否采用由业务风险决定。管理员不应默认能够读取全部敏感业务内容；需要应急访问时，记录启用与结束过程，定期复查是否还必要。

• 对临时权限定义到期与主动撤销的处理。
• 限制代操作范围，日志记录真实操作者与被代理主体。
• 将系统维护权限与业务数据权限分别分配。

迁移旧权限时逐项解释差异

新规则应先在隔离环境与旧权限比较，找出额外授予与权限收回。影子判定只能观察差异，正式放行必须由一个明确策略决定。

用真实角色与脱敏对象运行正常流程，再将新旧判定差异交给业务确认。上线分阶段推进时，不能为保持旧体验简单采用“任一规则允许即放行”，这可能把旧漏洞继续保留。对关键人员的权限收回安排业务说明和申请通道，避免用户绕过新流程寻找共享账号。

• 第一步：导出现有角色、例外和对象归属样例。
• 第二步：比较新旧结果，审核授予与收回差异。
• 第三步：切换明确策略，观察拒绝原因与申请反馈。

权限变化应及时影响已有请求与缓存

转岗、权限撤销和组织变更后，缓存中的授权信息可能仍允许访问。要明确策略更新、缓存失效和审计记录的责任。

为授权缓存设定版本或失效机制，按业务需要约定撤销生效时限，测试实际访问是否按期被拒绝。日志记录操作者、动作、对象和判定依据，避免写入不必要的敏感正文。审计不只是记录成功，还应能解释批量拒绝、策略改变和管理员授权来源，以支持问题定位和权限复核。

权限变更与长时间任务相遇时，定义执行前和执行中的检查要求。例如导出启动后权限被撤销，是否停止生成、禁止下载或允许已批准任务完成，应由业务明确，测试按同一口径检查，不留给不同开发者猜测。

• 核对网页、接口、导出任务和下载令牌的权限变化。
• 测试组织调整与撤销后缓存不会长期保留旧决定。
• 提供权限审计与定期复核方式，责任人可执行。

验收同时覆盖允许与拒绝的组合

用两名同角色用户、不同部门和不同租户的账号测试横向访问；用普通员工与管理员测试动作差异，还要覆盖对象状态变化。

直接修改对象编号、绕过前端按钮、批量提交混合归属记录，都可以发现授权边界问题。本文适合已有账号体系的业务授权升级；统一身份认证、账号同步和登录会话由相应集成方案处理。复杂多组织系统可以采用属性与关系规则，但需先确认数据主责和可解释性，避免为技术模型而制造业务概念。

测试报告同时保留账号条件、对象归属、期望决定与实际响应。仅截图一个访问被拒绝的页面不能说明服务端全部正确；需要把样例关联到具体接口和操作，便于同一权限规则变化后再次验证。

• 验证合法流程可完成，禁止动作和跨范围资源被拒绝。
• 检查批量接口是否对每个对象执行授权。
• 将已发现越权加入持续回归样例。

需求讨论中的问题