渗透测试收尾为何先取证再清理?

渗透测试项目收尾时，一种常见做法是先清理、再补记录：临时账号删掉、上传的脚本清掉、为测试放行的策略改回去，然后在报告里补一句环境已恢复。多数时候不出事，但这个顺序把风险放在了最不该放的位置。清理是整个收尾环节里唯一具有破坏性的动作；一旦删错，连“到底删错了什么”的判断依据也会一并消失。

要留下的证据并不复杂，但要求具体。第一是测试期间的操作日志，覆盖堡垒机会话、云审计事件、代理与目标主机日志，导出时连同时间范围与时区一起记下，否则后续比对容易出现时差。第二是落地文件的哈希清单，在删除之前记录路径、大小、修改时间与摘要值，而不是删完凭印象补写。第三是被改动配置项的当前值，它是后面判断“已还原”的对照基线。这三样东西的共同点在于：它们恰好都是清理动作会摧毁的现场。

按时间窗界定范围，同样是为了不误伤。按测试开始时间筛出落地文件，比按目录全量列举更稳妥，前者能把业务正常上传的文件排除在清理对象之外。执行前仍需逐条人工核对清单，遇到疑似业务正在使用的对象，应停下来找资产负责人确认，而不是先删了再说。

账号与凭证的吊销遵循同一套逻辑。直接删除账号实体，会让该账号的历史操作记录失去主体关联，审计时难以回溯发生过什么；更稳妥的顺序是先断开活跃会话，再禁用登录，观察日志确认无异常活动，最后才删除实体。还要检查删除之后的旁路：未主动踢出的长会话、未吊销的刷新令牌、下发到测试机却未回收的私钥，这些都不受改密码影响。

取证最终要落到阴性验证上：用已吊销的令牌、已移除的密钥、原测试源地址重新尝试，期望失败。业务运行正常只能说明没有误伤，不能说明攻击面已经关闭。若阴性验证出现非预期成功，应立即停止后续清理，先定位残留入口；此时继续删除，破坏的正是找出问题的现场。