发现异常时的第一反应往往是"先查清楚怎么回事"。但在安全事件里，这个顺序经常是错的——应该先止损，再查因。资产还在被加密的时候，查清楚原因也没什么意义了。
一、确认：是不是真的出事
- 异常来源：监控告警、用户反馈、外部通知（如云服务商、监管）
- 初步判断：影响范围、是否仍在持续、涉及哪些系统
- 指定处置负责人与联络人，避免多人同时操作
这一步要快，但不要为了求快而漏掉"谁在指挥"这件事。事件处置最怕的不是信息少，而是指令乱。
二、隔离：先止损
- 断开受影响主机的网络，但不要关机——内存中的证据会丢失
- 暂停相关账号，必要时全局强制改密
- 阻断可疑的外联地址与端口
- 确认备份系统未受影响，必要时切断备份服务器的访问路径
拔网线，别按电源
断电会清除内存证据，也会破坏取证条件。正确的做法是网络隔离，保持系统运行状态。
三、取证：边处置边留痕
- 记录时间线：谁、什么时候、做了什么
- 保存日志（系统、应用、网络、账号）并做副本
- 保留可疑文件与样本，不做破坏性分析
- 截图与记录操作过程，包括处置动作本身
四、通报：对上对下两条线
| 对象 | 内容 | 时机 |
|---|---|---|
| 管理层 | 影响范围、当前状态、需要的决策 | 确认后尽快 |
| 业务方 | 哪些系统不可用、预计恢复时间 | 确定影响后 |
| 全体员工 | 简要说明与注意事项（如不点可疑链接） | 必要时 |
| 外部 | 按合规与合同要求执行 | 依照规定 |
五、复盘：把这次的代价换回点什么
事件平息后一周内完成复盘：根因是什么、哪一步慢了、哪些措施有效、要补哪些制度。输出一份改进清单，明确责任人与时间。不复盘的事件，等于白付了一次学费。
#应急响应#事件处置#取证留痕#运维事业部
