事故响应：被盗、被封、被停机、域名劫持的 72 小时

事故里最常见的错误不是「技术不够」，而是「顺序错了」：先解释、先追责、先改代码，最后才止血。等你把顺序理顺，损失已经扩大。

一、域名被劫持的第一个小时

这是为解释机制构造的假设案例，人物、引语、收入和耗时均为教学设定，不是对真实事件的调查记录。

一位开发者的域名注册商账号被盗。攻击者修改了 DNS 记录，把官网和 API 指向另一台服务器，同时提交了域名转出申请。

他是在客户发来截图时才知道的：网站变成了一个钓鱼页面。

第一个小时，他做了三件事（后来证明顺序是对的）：

1. 用另一台干净设备登录注册商，冻结域名、撤销转出、重新开启转移锁。
2. 修改注册邮箱密码，撤销所有会话，开启新的 2FA。
3. 导出 DNS 变更记录与登录日志，保存证据。

他没有做的三件事（后来证明也是对的）：

1. 没有在社交媒体上直播事件。
2. 没有立刻重装电脑（先保留现场）。
3. 没有公开可被利用的细节；同时立即评估客户防护、合同通知与法定通报，不等待恢复完成。

第三天，服务恢复，他发了一封说明邮件，附上时间线和补救措施。流失了一些客户，但没有出现更大范围的信任崩塌。

二、事故分级

不是所有事故都需要 72 小时预案。先分级，再决定投入。

分级的目的不是「大事化小」，而是「别把 P3 当 P0 处理，也别把 P0 当 P3 拖着」。

三、0–1 小时：止血

止血的目标不是恢复，而是阻止损失继续扩大。

3.1 按已确认的影响面选择动作

• 用一台干净设备（不是可能被入侵的那台）登录关键账号。
• 修改主邮箱、密码管理器、域名注册商、云账号的密码。
• 撤销所有活跃会话与记住的设备。
• 重新生成 2FA 恢复码，确认旧码失效。
• 轮换 API key、部署密钥、CI token。
• 检查并移除未知的转发规则、授权应用、团队成员。
• 有资金风险时联系支付商/银行限制恶意出款，检查异常退款或转账；不要无理由冻结正常业务。
• 仅停用已确认的恶意计费或受攻击路径；正常域名、证书和基础设施续费不能一概暂停。

3.2 按事故类型

3.3 止血时的三个禁忌

1. 不要先删日志。 日志是取证的基础，删了就说不清。
2. 不要先重装系统。 现场可能还有线索，重装会破坏证据。
3. 不要先公开细节。 攻击者可能还在观察你的反应。

四、1–6 小时：取证与确认范围

止血之后，回答三个问题：怎么进来的、影响了什么、还有没有后门。

4.1 取证清单

4.2 确认范围

• 攻击者访问了哪些账号？用了哪些 IP、设备、时间窗口？
• 有没有新增的 API key、OAuth 应用、转发规则、团队成员？
• 有没有数据被导出或删除？
• 有没有向客户发送钓鱼邮件？
• 有没有修改付款信息或银行账户？
• 有没有留下计划任务、后门账号、异常证书？

4.3 证据保存原则

• 原始文件不要修改，复制一份再分析。
• 记录每个证据的获取时间与来源。
• 重要证据做哈希，防止被质疑篡改。
• 涉及客户数据时，只保存必要部分，避免二次泄露。

五、6–24 小时：恢复服务

恢复的顺序：先核心、再外围；先只读、再写入；先小流量、再全量。

5.1 恢复清单

• 确认所有后门已清除，凭据已轮换。
• 恢复 DNS 与证书，验证解析与 HTTPS。
• 从备份恢复数据，校验完整性。
• 恢复支付通道或切换备用通道。
• 恢复邮件发送与接收。
• 恢复 CI/CD 与发布流程。
• 小流量验证核心链路，再逐步放量。
• 监控错误率、延迟、支付成功率。

5.2 恢复时的判断

六、沟通与通报并行；24–72 小时持续更新与复盘

6.1 从知悉事件时启动通知评估

1. 受影响客户与控制者：需要采取保护措施的，尽早给出已知事实和动作；未知范围后续补充，不因没恢复而拖延。
2. 主管机关、平台与服务商：分别判断法定通报、合同通知、冻结与申诉入口，记录知悉时间和截止点。
3. 公开发布：如果影响范围大，发一份简短说明。
4. 合作伙伴 / 供应商：告知可能的影响。

6.2 客户通知模板

主题：关于 [产品] 服务中断的说明

你好，

在 [日期/时间] 到 [日期/时间] 期间，[产品] 的 [具体功能] 受到影响，
原因是 [一句话说明，不暴露可利用细节]。

我们已经：
1. [已完成的修复动作]
2. [已采取的保护措施]
3. [对受影响数据的处理方式]

你需要做的：
- [如需要重置密码/检查某项设置]

如果你有任何问题，可以直接回复这封邮件。

[署名]

6.3 平台申诉模板

主题：Account recovery / appeal for [account identifier]

Hello,

My account [identifier] was [compromised / suspended] on [date].
I have secured the account by [actions].

Evidence attached:
- [登录记录 / 账单 / 身份证明 / 所有权证明]

Impact: [brief description]
Request: [restore access / review suspension / transfer ownership]

Thank you,
[Name, contact, account email]

6.4 复盘模板

复盘不是写检讨。 它要产出可验收的改进项，而不是「以后注意」。

七、联系卡

把下面这张卡打印出来，放在钱包或离线恢复包里。出事时你可能没有网络，也可能没有心情找链接。

八、常见错误

九、行动清单

• 写下 P0–P3 的判定标准，贴在工作区。
• 准备一张离线联系卡，填好关键服务商入口。
• 确认主邮箱、域名、云、支付、商店的恢复方式都能走通。
• 准备客户通知与平台申诉模板。
• 每半年做一次桌面演练：假设域名今天失效，第一步做什么。
• 把「止血、取证、恢复、沟通」四个阶段写成一页纸。
• 复盘时至少产出一条可验收的改进项。

使用边界与实操验收

P0–P3 是本系列统一的内部响应规则，不是法律时限。服务仍可访问不能降低正在泄露的事件优先级；通知、隔离、取证和恢复并行。

桌面演练：周五 16:00 发现可用管理员 key 已公开。16:00 起立即撤销并隔离、保存最小证据，评估数据和资金影响；另一个任务记录知悉时间及客户/主管机关通知条件。适用 GDPR 时按角色与风险执行相应通知，不等到周一维护窗口。交付时间线中应有“已知/未知、负责人、下一次更新”，不能假装已确认所有后门清除。

关键参考与核验范围

以下链接支持对应的机制或规则；本文的案例、成本和经营评分是说明方法的假设，不能当作平台统计或收益承诺。核验日期：2026-10-22。

• EDPB 数据泄露指南 ：按处理角色与风险判断通报，不以恢复完成作为起点。
• 个人信息保护法 ：处理依据、委托/对外提供、出境和个人权利分别判断。

系列导航

• 上一篇：商店开发者账号：Apple、Google、Microsoft 与 Chrome 的团队与找回
• 下一篇：交接与数字遗产：应急联系人、资产文档、出售与关停移交
• 回到目录：独立开发者的资产韧性
• 相关阅读：SaaS 事故沟通 、平台风险与迁移