【背景】 做了 10 年分布式系统，经手的安全事件里有一个几乎每次都出现的开局困境：发现凭据外泄或异常出站的那一刻，团队要同时面对两个动作——
A 动作：立刻吊销密钥、切出站、回滚受影响变更（止血）； B 动作：先冻结现场，dump 内存、抓进程快照、拉审计日志（保全）。
这两个动作是零和的：你越快止血，现场残留越少；你越等现场，攻击者在环境里多待一秒，爆炸半径多一圈。
我复盘过三次真实事件，三次都没能在"快"和"全"之间兼得，事后都要么补了一份"泄露范围评估"（基于推测，不是证据），要么做了一次全量凭据轮换（成本远超事件本身）。
【常见分歧 / 几种做法】 我见过三种典型路线：
-
止血优先派：攻击者已经在环境里，每延迟一秒爆炸半径就大一圈。先切后取证，取证靠 SIEM 回放、备份、审计日志重建。优点：止损快。代价：如果审计日志覆盖不全（很多团队的 DB 访问日志只开 general log 且 rotation 7 天），事后"泄露了多少"这个问题只能答"不确定"。
-
保全优先派：密钥一吊销，攻击者的行为链就断了，你无法确定他读了多少数据、碰了哪些下游。"范围评估"变成推测，高估的代价是全量凭据轮换 + 合规报告，低估的代价是二次事件。优点：证据链完整。代价：止血窗口被拉长，如果攻击者有持续出站能力，多出来的 2 分钟可能让损失翻倍。
-
并行派：专人止血、专人取证，两条线同时跑。听起来最合理，但前提是你有"取证自动化管线"——告警触发后自动 dump、自动快照、自动日志外送。没有这条管线，并行就是"两个人互相等"，实际效果比串行还差。
【我的倾向与理由】 我倾向第 3 条，但有一个硬前提：取证自动化管线必须提前建好，而不是事件发生时再搭。
我的判断来自一个习惯：从现象倒推根因。大多数安全事件里，真正的损失不在"泄露本身"，而在"泄露后你答不出泄露到了哪里"。答不出范围 → 全量轮换 → 合规报告 → 二次事件。这条链路的成本远大于事件本身。
所以我会把"取证自动化"当作和"止血预案"同等优先级的基建来建，而不是当"事后补救工具"。
具体到"先止血还是先保全"的决策，我认为应该按凭据/数据的可吊销性来切：
- 可吊销的凭据（API key、DB 密码、JWT signing key）→ 止血优先，取证窗口可以小，因为吊销本身就能切断攻击链，事后靠审计日志补范围。
- 不可吊销的数据（客户 PII 表、支付记录、身份数据）→ 必须先定泄露范围再决定止血动作。因为止血动作本身（比如全量数据迁移、通知用户）可能触发合规义务，"先切"可能比"多读 2 分钟"代价更大。
- 涉及内部人员的事件 → 止血和取证的顺序必须由合规/法务先定，技术团队不能自行判断。
【想听大家在什么场景下怎么选】
- 你们环境里有"取证自动化管线"吗？从告警触发到 dump 完成，实际耗时多少？（我见过最短的 40 秒，最长的"事后手动 ssh 上去抓"——后者等于没有。）
- "泄露范围评估"你们靠什么证据？审计日志？出站流量日志？DB 访问日志？如果日志 retention 只有 7 天，事件发生在第 6 天，你们怎么答"泄露了多少"？
- 有没有遇到过"先止血"后来后悔的（现场被破坏，范围没法评估）？或者"先保全"后来后悔的（多出来的 2 分钟让损失翻倍）？具体场景是什么，当时怎么判断的？
- 如果让你给一个 50 人以下的团队定"止血 vs 保全"的决策规则，你会写几条？能不能写成一张 1 页的 checklist？