数据库被勒索病毒加密

数据库通常是企业唯一的权威数据副本。它被加密时，财务、生产、库存、诊疗、教务等所有上层应用同时失效，而且停机时间往往由恢复方案决定，而不是由病毒决定。近年主流家族普遍采用双重勒索，在加密前先窃取数据，因此除了业务中断，还要评估数据外泄与合规通报义务。

真正让数据无法挽回的，多数不是加密本身，而是中招后的这几类操作：

• 反复重启服务器、反复启动数据库服务：会产生新的写入、覆盖磁盘未分配空间，也会让本可修复的文件被数据库引擎进一步改写。
• 格式化、重装系统或把数据库重装到原目录：直接覆盖残留的旧文件和可恢复碎片。
• 在原盘上直接运行恢复软件并把结果写回同一分区：自我覆盖，是最常见的不可逆错误。
• 自行运行攻击者提供的解密器，或从网上下载所谓「万能解密工具」：前者可能只解部分文件并留下后门，后者常带二次加密或挖矿组件。
• 用已被加密的 .bak / .dmp 覆盖生产文件：把仅剩的可用素材也一并破坏。
• 先关杀软再开机联网排查：暴露面未收敛，极易被同一入口二次投放。

我们的立场是明确的：不建议支付赎金，也不提供代谈判服务。付款既无法保证拿到可用密钥，也会把组织标记为可再次攻击的目标。

• 数据库服务器不直连公网。 1433、1521、3306、5432、3389 一律不做端口映射；远程运维统一走 VPN + 堡垒机 + 多因素认证。据公开报告，远程桌面暴力破解与漏洞利用合计占国内勒索事件传播方式的近八成。
• 收敛数据库账号权限。 禁用弱口令与默认口令（尤其 sa、system、root），关闭 xp_cmdshell 等高危扩展，数据库账号与域账号分离，应用连接串使用最小权限账号。
• 备份遵循 3-2-1-1 原则。 三份副本、两种介质、一份异地，至少一份离线或不可变（WORM / 对象锁）。备份服务器不加入生产域，备份账号独立且不复用。
• 只看「备份成功」不算数。 定期做真实还原演练并记录 RTO / RPO，校验备份文件可读性与数据库一致性。
• EDR 覆盖到每台数据库服务器，开启防篡改、卷影保护与勒索行为拦截，不要因为「怕影响性能」把数据库服务器排除在外。
• 补丁与版本治理同步做前端。 数据库自身之外，ERP、OA、中间件、Web 应用同样要打补丁——大量数据库沦陷是先从前端应用漏洞进来的。
• 网络分段与端口白名单。 应用服务器到数据库只放行必要端口，办公网不能直达数据库网段。
• 日志留存不少于六个月，开启数据库审计、失败登录告警与异常导出告警，确保事后能追溯入口。