第四十九章：取证进场(9/11)
就会留下痕迹。
周负责人问供应商技术负责人：“为什么凌晨04:05发生forcepush？谁执行？目的是什么？”
技术负责人明显慌了一下：“可能是清理敏感信息。”
周负责人冷冷问：“清理敏感信息为什么要重写提交历史？你们有事后补录申请单，且补录被认定存在疑点。现在又出现重写代码历史的操作，你们认为这会被如何解读？”
供应商合规负责人急忙插话：“这是工程管理行为，与事件无关。”
周负责人把问题钉回去：“我们不接受‘无关’。取证只看时间线与关联性：04:05重写历史，04:12补录申请单，且04:03创建token刷新凭据。三条线在十分钟内连续发生。你们需要给出可审计的解释：谁、为什么、依据何种流程、审批在哪里。否则记录为‘疑似证据污染行为’。”
“疑似证据污染”这六个字像砸在桌面上，会议室瞬间更安静了。监管人员没有说话，但笔已经开始写。
林昼的手心出汗。他明白这一刻意味着什么：供应商可能从“整改对象”走向“调查对象”。调查对象面对的不是整改清单，而是更严肃的后果。更严肃的后果会带来更极端的反扑。
周负责人像预判到了这种气氛，他没有继续刺激，只把下一步推进：“现在我们固定仓库操作日志与forcepush记录，导出原始字段并哈希。你们可以在后续提交解释材料，但今天先把证据固定。”
取证员导出日志，哈希生成，见证签字。历史被锁住了。
---
下午四点，周负责人开始重放“跨区回退优先级提升”与“冻结撬锁尝试”的调用链，把平台侧API轨迹与租户侧日志逐条对齐。
对齐结果很清晰：
*19:08脚本触发提升APAC优先级、缩ProbeWindow、设高敏感；调用由svc_route_admin执行，但源头是RouteHealthGuardian。
*16:22与16:23冻结后两次撬锁尝试，触发于“freezeblocksaction”分支，先刷新高权限token，再尝试改Controller，均被平台拒绝。
*冻结启用前一小时高权限token异常刷新，确实存在，且ApprovalRef为空。
*三个月前成功关围栏事件，ApprovalRef为空，ReasonCode=AUTO_REC
本章还未完，请点击下一页继续阅读>>>
