数据泄露是每个站长最怕的事：用户手机号被拖、订单信息外泄、密码明文躺在攻击者手里。处理不好，技术问题会变成法律问题——《个人信息保护法》下，泄露处置不当的罚款能到五千万或上年营收 5%。

这篇讲泄露后的黄金 72 小时怎么处置，以及平时就要做好的合规底线。希望用不上，但必须知道。

需要云服务器可以看看财富云计算：一键开服面板，NAT 型无独立公网 IP，价格比独立 IP 机型省一半以上，主流游戏快速部署。

一、先判断：是不是真泄露了

以下信号出现，按泄露对待：

• 数据库文件出现在暗网/网盘
• 收到用户反馈「接到精准诈骗电话，对方知道我的订单信息」
• 数据库出现陌生查询记录（SHOW PROCESSLIST 看到陌生来源）
• 有陌生管理员账号/API 密钥
• 网站被挂 webshell 且访问过数据库
• 备份文件被公开访问到（/backup/xxx.sql 能被下载）

存疑就当泄露处理——侥幸心理的代价最大。

二、黄金 72 小时处置流程

第 1 小时：止血

# 1. 断网(安全组只放行自己 IP)
# 2. 保全证据(先别删!)
cp -r /var/log /root/evidence-logs/
cp -r 可疑webshell /root/evidence-files/
mysqldump --all-databases > /root/evidence-db.sql

# 3. 改所有密码
# - 服务器 root、数据库 root、Redis、面板
# - 所有第三方服务密钥(短信、支付、OSS)
# - 邮箱(攻击者常用邮箱改绑定)

# 4. 封禁可疑 IP
grep "Failed password" /var/log/secure | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head

证据保全原则：内存里的进程、日志、可疑文件，先备份再清理。事后溯源、报警、定责全靠它们。

第 2–24 小时：定损

回答三个问题：

1. 泄露了什么？

# 数据库里都有什么
mysql -u root -p -e "SHOW DATABASES;"
mysql -u root -p -e "
SELECT table_name, table_rows 
FROM information_schema.tables 
WHERE table_schema='你的库';"

# 重点: 有没有手机号、身份证、密码、订单、住址

2. 泄露了多少？

对比备份和当前数据，看被拖走的范围。查日志里的批量查询记录：

# 慢日志/通用日志里的大批量 SELECT
grep "SELECT" /var/log/mysql/slow.log | awk '{print $1}' | sort | uniq -c | sort -rn | head

# 或者看陌生 IP 的连接记录
grep "Connect" /var/log/mysql/error.log | tail -50

3. 怎么泄露的？

常见路径：webshell 拖库、备份文件暴露、弱口令直连、SQL 注入、内鬼。查日志和文件时间线还原。

24–72 小时：处置与通报

# 1. 堵住入口(按溯源结果)
# - 漏洞: 打补丁/上 WAF
# - 弱口令: 改密码 + 限登录
# - webshell: 全盘扫描清除
# - 备份暴露: 备份移到非 Web 目录

# 2. 重置风险凭证
# - 强制所有用户改密(下次登录必须改)
# - 通知用户: 涉及资金的通知先行
# - 第三方: 支付渠道报备

# 3. 恢复服务
# 确认干净后逐步放开访问

三、合规要点：法律要求你做什么

《个人信息保护法》《数据安全法》《网络安全法》下的关键义务：

1. 通知义务

• 通知监管：发生泄露，立即向所在地网信、公安部门报告（严重情况）
• 通知用户：涉及个人信息的，及时告知受影响用户（内容：泄露信息类型、可能后果、已采取措施、用户能做什么）
• 通知合作方：用了第三方服务（云、支付、短信）的，按合同约定通报

2. 平时义务（泄露前的合规底线）

3. 处罚红线

• 未履行通知义务、未采取补救措施 → 罚款 + 责令改正
• 造成严重后果 → 最高 5000 万或上年营收 5%
• 责任人员 → 个人罚款 + 禁业

现实提醒：小站被罚的案例少，但「被用户集体诉讼」和「被当成典型案例通报」的风险真实存在。合规不难，难的是平时不做，出事抓瞎。

四、技术债清单：现在就该做的

等泄露了再补救就晚了。这些措施把「泄露」的损失降到底：

1. 密码绝不能明文存

// PHP 正确做法
$hash = password_hash($password, PASSWORD_BCRYPT);   // 存储
password_verify($input, $hash);                       // 验证

# 检查数据库里有没有明文密码
mysql -u root -p -e "SELECT * FROM users LIMIT 5;" | grep -v "^\$2y\$"
# 有非哈希开头的 = 明文,立刻改

2. 数据库和备份加密 + 分权

# 备份加密
mysqldump ... | gzip | gpg -c --cipher-algo AES256 > backup.sql.gz.gpg

# 备份放非 Web 目录,别放 /var/www/html/backups/
# 按账号分权,应用账号不给 FILE/SUPER 权限(见数据库加固)

3. 敏感操作审计

# 开启 MySQL 通用日志(泄露后溯源的关键)
# 记录谁、什么时候、查了什么
general_log = 1
general_log_file = /var/log/mysql/general.log

# 日志外传(本机日志会被删)
rsync -az /var/log/mysql/general.log 日志服务器:/audit/

4. 蜜罐与监控

# 假备份文件(被下载 = 有人扫到了)
echo "<?php mail('admin@example.com', 'ALERT', 'backup accessed');" > /var/www/html/backup.php.bak

# 数据库连接异常监控(陌生 IP 连库 = 告警)

五、事后：复盘与重建信任

技术处置完，还有三件事：

1. 复盘报告：时间线、根因、损失、改进项。写下来，团队才真正记住
2. 用户沟通：透明 > 遮掩。说清楚发生了什么、你在做什么、用户该做什么（改密码）。藏着掖着被爆出来，信任直接归零
3. 加固落地：复盘列出的改进项，逐条排期做完，别停在 PPT 里

六、常见问题

Q：多快必须通报监管？
法律表述是「立即」，实务中 72 小时内通报是安全线。拿不准就打 12377（网信办举报）或咨询律师。

Q：小网站也算「个人信息处理者」吗？
算。只要有注册用户、收集手机号/邮箱，就适用《个人信息保护法》。规模小不等于豁免。

Q：泄露的是哈希密码，用户就安全吗？
弱密码的哈希能被彩虹表/GPU 爆破。必须强制改密 + 提示别用相同密码。

Q：内部人员泄露怎么防？
最小权限 + 操作审计 + 敏感数据脱敏。技术上防不住内鬼，但审计能让事后可追溯。

Q：被拖库后网站还能继续用吗？
堵洞、加固、换密码后可以。但用户信任受损，需要主动沟通。数据回滚到泄露前的备份，逐条核对被篡改的内容。

Q：日志也被删了怎么办？
本机日志不设防。这就是为什么要外传日志——本地一份、远程一份，攻击者删不完。

小结

数据泄露的应对核心是黄金 72 小时：1 小时止血（断网+改密码+保证据）→ 24 小时定损（泄露什么/多少/怎么泄的）→ 72 小时处置与通报（堵洞+通知+合规）。而真正的胜负手在平时：密码哈希、备份加密、操作审计、日志外传——这四件事做了，泄露的损失可控；不做，一次事故就能毁掉整个业务。

更多安全内容见财富云计算知识库：应急排查、数据库加固、挂马清除、安全基线全系列。需要云服务器可以看看财富云计算：一键开服面板，NAT 型无独立公网 IP，价格比独立 IP 机型省一半以上。

延伸阅读

1. 网站环境怎么选：LNMP 手动 / 宝塔面板 / Docker / 云开发
2. 问卷表单系统搭建：SurveyKing / Formbricks，数据自己收
3. 图床搭建：Lsky Pro / Lychee，自托管图片托管方案
4. 邮件列表搭建：listmonk 自托管 Newsletter，把读者握在自己手里
5. 文档站点搭建：MkDocs / VuePress / Docsify，产品文档与技术手册方案
6. RSS 阅读器搭建：FreshRSS 自托管，把信息流拿回自己手里
7. 短链接服务搭建：Shlink 自托管，链接数据自己掌握
8. 网站状态监控页搭建：Uptime Kuma，服务器挂了第一时间知道

更多阅读

1. 上一篇：网站被挂马：排查、清除与防护完整流程
2. 下一篇：进程调试实战：strace、lsof、perf 排障三件套