网站数据库被拖库了怎么办：应急响应与加固方案

凌晨三点，运维群里弹出一条告警：数据库连接数激增，某张用户表的查询量是平时的20倍。十分钟后确认——数据库被拖库了。

这种场景并不少见。攻击者通过SQL注入或弱口令拿到数据库权限，把整张表的数据导走，后果比页面被篡改严重得多。那么问题来了：发现拖库后，头24小时该做什么？

一、30分钟内：止血比追查更重要

确认拖库后的第一件事不是查IP、不是看日志，而是切断攻击路径。具体操作三步走：

第一步，立即修改数据库账号密码，同时检查是否存在未授权的账号。很多拖库事件中，攻击者用的是系统里遗留的测试账号，权限还特别大。

第二步，在防火墙或WAF层面临时封堵可疑IP段。如果你用的是云数据库，直接把公网访问关掉，只保留内网连接。

第三步，开启数据库审计日志，后续所有操作都要有记录。这一步容易忽略，但对定责和复盘至关重要。

二、24小时内：评估损失与恢复

止血之后要搞清楚一个关键问题：到底被拿走了多少数据？

检查数据库的慢查询日志和binlog，定位异常导出操作的时间窗口和涉及的表。如果binlog还在，可以通过时间戳反推被拖走的数据范围。

数据恢复方面，如果被拖的是用户表，不要急着回滚。先确认数据是否被篡改——有些攻击者不只是复制，还会修改字段。对比最近一次完整备份和当前数据，找出差异行。

同时启动用户通知机制。如果涉及手机号、身份证号等敏感信息泄露，按照《数据安全法》要求需要告知用户。措辞要准确，说明泄露范围、可能影响和已采取的措施。

三、一周内：堵住漏洞，加固防线

拖库不是结束，下一波攻击可能已经在路上。这一阶段的核心是把之前的短板全部补上。

第一，全面排查SQL注入漏洞。用扫描工具跑一遍所有参数入口，重点检查搜索、筛选、排序这类动态拼接SQL的地方。所有数据库查询必须走参数化或ORM，没有例外。

第二，数据库权限最小化。业务代码用的账号只给SELECT、INSERT、UPDATE权限，不给DROP和FILE权限。管理账号不写进配置文件，用密钥管理服务托管。

第三，数据库定期备份自动化。设置每天全量备份加增量备份，备份文件加密后存到独立的存储桶，和业务环境物理隔离。定期做一次恢复演练，别等出事才发现备份是坏的。

拖库攻击的成本越来越低，但防御手段也在升级。把应急流程跑通，把加固措施做到位，下次告警响起来的时候，你不会那么慌。