数据安全事件最怕的不是出事，而是出事后全员各干各的：有人急着删日志，有人先去改密码，等要查的时候证据已经没了。这篇给安全团队一份按时间推进的处置清单，从谁先动、动什么，到每步留什么凭证、什么指标算控制住了。适合已经有基本安全制度、但缺少事件响应流程的团队，照着改成自己的一页纸预案。
数据安全事件最怕的不是出事，而是出事后全员各干各的：有人急着删日志，有人先去改密码，等要查的时候证据已经没了。真到那一刻，团队缺的不是意识，是顺序——谁先动、动什么、每步留下什么。下面这份清单按时间推进，从第一小时一直写到收尾复盘。
它适合已经有基本安全制度、但还没写成事件响应流程的团队。你可以照着改成自己的一页纸预案：把角色填上、把路径换成自己系统的、把验证方式写清楚。不用追求一次写全，先能跑起来比写满十页更有用。
黄金第一小时：先控损还是先取证
第一小时最容易乱。建议先做三件不花钱、但决定后面能不能查清的事：确认事件边界（哪些系统、哪些数据、还在不在持续）、指定唯一指挥人（只留一个决策出口）、开一个只用于本次事件的沟通频道（不让讨论散在几个群里）。这三件事做完，队伍才算有主心骨。
- 取证优先于清理：截图、导出访问日志、保留进程与内存快照，再去断权限、改密钥、下线接口；顺序反了，后面就无法判断影响面
- 先别急着对外发声，但也别把内部结论写进公开工单或聊天群，结论一旦外流，后面口径很难收回来
- 所有临时操作（停服务、踢账号、改配置）都记下时间和执行人，不然复盘时对不上号
定级与影响面：先把范围圈出来
控住之后要回答一个问题：到底影响了多少。定级别凭感觉，用三个维度打分——数据类型（是否含个人信息、账号凭据、业务机密）、影响人数或条数、是否仍在持续。三个维度里只要有一个打满，就按高一级处理。
| 维度 | 看什么 | 记录方式 |
|---|---|---|
| 数据类型 | 是否含个人信息、凭据、业务机密 | 逐类标注，不确定的写「待确认」 |
| 影响范围 | 人数、条数、涉及的系统和账号数 | 给区间，别只写一个约数 |
| 持续性 | 是否仍在泄露、是否已被外部看到 | 按时间点记录每次变化 |
圈范围要用两头对齐的办法：从入口往回查（谁有权限、权限怎么来的），从数据往前查（这段数据流经哪些服务与日志），两头对上了才不漏人。把「疑似」和「确认」分开记，不要混在一张表里，否则复盘时说不清当时的判断依据。
术语口径也要统一：什么算「泄露」、什么算「越权」，团队各说各话最耽误事。判定标准可以到 /safety 与 /ai-dict/category/safety 核对当前定义，用同一套词再开会。
止血动作清单：按顺序做，别跳步
止血最容易犯的错是东一榔头西一棒子。建议按凭据、访问、数据、留痕四类顺下来，做一类勾一类，别凭记忆。下面这组动作可以直接当 checklist 用。
- 凭据类吊销并轮换受影响的 Key 与令牌，顺带检查有没有派生凭据、长期有效的机器账号、写进配置文件里的旧密钥。验证方式：确认旧凭据调用返回失败。
- 访问类临时收回越权账号、关掉对外暴露的端口与调试接口、收紧共享链接的可见范围，并确认这些改动有没有被缓存绕开。
- 数据类暂停相关导出与同步任务，确认备份是否也被污染；被污染的备份要标记出来，别等恢复时才发现。验证方式：抽查一份备份的内容是否包含本次受影响的数据。
- 留痕类所有止血操作记录时间、执行人、命令或后台操作路径，这些就是事后举证材料。Key 相关动作可对照 key-leak-response-runbook 的顺序走。
处置期间看哪几个指标判断有没有控制住
盯指标的意义是回答一句：现在控制住了吗。看趋势不看单点——异常调用量、失败率、错误码分布，在止血后有没有回落，具体数字以你们自己的历史基线为准，别拿别人家的数据套。
- 异常调用量
- 止血后应回落；只降一半说明还有入口没堵住，继续找
- 失败率与错误码
- 突然换了一种错误码，往往意味着攻击方在换路径而不是放弃
- 数据外发量
- 导出、邮件、外链等出口的总量，比单看接口更接近真实泄露
- 账号与权限变更
- 是否出现新的越权或提权动作，说明横向移动可能还在进行
基线不用一开始就很精细，可以先量出来再迭代。服务本身是否正常、是不是上游抖动，可以对照 /ai-status 的状态页先排除一遍，避免把故障当入侵、或把入侵当故障。要量响应速度这类基础数据，/tools/speed-test 也能给个参照。区分「指标回落」和「事件结束」很关键：回落只说明当前入口被堵，横向移动可能还在。
通报与分工：谁通知谁、谁签字
角色不清是通报环节最常出问题的地方。建议明确四个岗位：指挥（拍板）、取证（留证据）、止血（动手）、对外沟通（管口径）。小团队可以一人多岗，但每个动作必须只有一个负责人，不能出现「大家一起看着办」。
| 角色 | 主要职责 | 不该做的事 |
|---|---|---|
| 指挥 | 定级、拍板断服务、控制节奏 | 不亲自下场改配置 |
| 取证 | 保存日志、截图、时间线 | 不清理现场 |
| 止血 | 按清单轮换凭据、收紧权限 | 不擅自对外说明 |
| 对外沟通 | 统一口径、按流程通报 | 不即兴回答客户细节 |
对内通报控制在必要范围，知道的人越少越不容易走漏；对外通报口径由法务或合规确认后再发，别让一线同学自己回复客户。涉及个人信息或跨境数据的，先判断是否触发报告义务与时限，路径与口径到 /safety 核对当前要求。内部试验环境、无真实数据的事件可以走简化流程，但仍要留一条记录。
收尾：复盘、修复与回归验证
复盘只问三件事：怎么进来的、为什么没更早发现、哪一步动作慢了。不做个人追责式复盘，否则下次没人敢早报告，损失更大。这三问能落成三样产出：入口修复、监测补强、响应提速。
- 修复项要落到具体负责人和验证方式，例如加监控规则、改权限模型、补日志字段，并约定回归测试时间
- 把事件写成一页纸案例，进团队知识库，作为下次演练的脚本
- 修复完成后做一次对照验证：用同样的攻击路径再打一遍，看是否被拦住；拦住了才算闭环
这里有个容易偷懒的点：修复项写成了「加强监控」这种没法验证的话。改成「某类异常在多少分钟内触发告警，谁收到」才算完整，验收时才有据可依。
留证与记录：出事后能拿得出手的东西
留证不是事后补救，是提前设计。固定证据三件套：时间线（谁在何时做了什么）、原始日志与截图（不改动原件）、沟通记录（工单、邮件、群聊）。三样要对得上，单独一张截图说明不了问题。
日志保留期限、脱敏方式与访问权限要提前定好，临时找日志往往已经轮转掉了，做法可参考 log-redaction-retention。对外举证材料的整理思路可参考 dispute-evidence-keep，重点是形成可核对的链条而不是一堆散图。纯内部小范围误操作、无数据外泄的，留一份简要记录即可，不必按大事件规格做。
把清单变成能力：演练与预案维护
清单写在文件里不会自动生效，得靠演练变成肌肉记忆。至少每季度做一次桌面演练：给一个假想场景，让每个角色说清自己的第一步做什么，说不出来的地方就是预案的漏洞。
- 预案里写清联系人与升级路径（谁有权拍板断服务），并定期核对是否还在职
- 演练后把暴露出来的空白补进预案，别只写一份演练记录就归档
- 监测能力要定期体检，可对照 prelaunch-security-checklist 与 security-audit-capabilities 补齐盲区
- 把每次真实事件和演练的差异记下来，下一次修订预案时优先补这些点
还有一个现实问题：很多团队第一次做演练时会发现联系人早换了、权限早变了。这不丢人，趁演练发现比出事时发现强得多。把这些基础信息当成活的文档维护，比写一份漂亮的预案更有用。
下一步把上面的清单对着自己团队改一版，再去站内选型与可信度页面核对该走的路径和当前要求，避免照着过期口径做响应。→常见问题
发现数据可能泄露，第一件事到底做什么？
先确认是不是还在持续泄露，同时指定唯一指挥人并开始记录时间线。取证和控损可以并行，但不要先删日志、先重启服务，那些动作会把判断影响面的依据一起清掉。如果泄露还在高速扩散，控损优先，但必须同步在另一处留日志。
日志被覆盖了还能查吗？
能查的范围会大幅缩小。可以转向其他来源：云平台操作审计、网关与负载均衡日志、数据库审计、代码仓库提交记录、工单与聊天记录。以后要在事件前就定好日志保留期限与集中存储，别等出事才想起日志已经轮转。
要不要第一时间通知用户或客户？
先内部定级和确认影响面，再由法务或合规判断是否有报告义务和时限要求。过早对外容易口径反复，过晚又可能违规。原则是先有事实再发声，所有对外文本过一次合规审查，一线同学不要自行回复。
小团队没有专职安全岗，怎么做应急？
用角色不用岗位：临时指定指挥、取证、止血、沟通四个人，可以兼任但不能空缺。清单可以压缩到一页纸，只保留断权限、轮换凭据、留日志、通知合规这几步。关键是提前写好谁有权断服务，出事时不用现讨论。
怎么判断事件已经结束了？
满足三个条件再收尾：异常指标回到基线并稳定观察一段时间、根因已定位且修复项已验证、对外该通报的已按口径完成。只看指标回落就收工很容易漏掉横向移动，建议用同样的攻击路径再打一遍做回归验证。
