Oracle 数据库被勒索病毒加密

Oracle 通常承载组织里最关键、最不允许丢数据的业务：医院的 HIS 与电子病历、集团的核心财务与生产系统、大型 ERP 的后端。这类场景的特点是恢复点目标极严格——丢几小时数据在医疗和财务上都可能是实质性事故，而不只是不便。

Oracle 的恢复逻辑与 SQL Server 有明显差别，处置顺序不能照搬：

• 控制文件是恢复的地图。 它记录数据文件清单、检查点与日志序列。控制文件全丢时，即使数据文件完好，也要靠备份控制文件或重建控制文件才能拉库。
• 归档日志决定恢复点。 ARCHIVELOG 模式下，只要有可用的数据文件备份加上连续的归档日志，就能做时间点恢复；归档日志被加密或被删，恢复点就被强行拉回到最后一个可用备份。
• ASM 与裸设备场景更复杂。 数据不在普通文件系统上，加密器往往只能打到 ASM 磁盘头或整块设备，恢复方式与文件级修复完全不同，必须先确认存储形态。

常见误操作，危害从高到低：

• 在原库上反复 startup / recover，或执行 alter database datafile offline drop、resetlogs 类操作。 这些动作会改写控制文件与文件头，可能直接断掉后续恢复路径。
• 对 ASM 磁盘组做 mount / rebalance 尝试。 在磁盘头被破坏的情况下有覆盖风险。
• 在原盘上恢复数据、或把导出文件写回同一存储。
• 用被加密的 .dmp 或 RMAN 备份集直接 restore 覆盖现有文件。
• 重启主机。 Linux 场景下重启会丢掉内存中仍打开的文件句柄与进程痕迹，也可能触发自动挂载与写入。

我们不建议支付赎金，也不提供代谈判服务。

• 开启并验证 ARCHIVELOG 模式。 没有归档日志就没有时间点恢复能力。同时确认归档目录有独立空间与独立备份，不要只留在数据库主机本地。
• RMAN 备份必须落到独立位置。 备份目标不要挂在生产主机上、不要用生产同一套凭据；至少一份写入不可变存储或离线介质，并定期 restore validate 验证备份集可用。
• 用好物理备库。 Data Guard 备库放在不同网段、使用独立操作系统账号与口令，可作为勒索事件下的快速切换点；但要避免备库与主库共享同一套运维凭据。
• 1521 不暴露公网，收敛 listener。 配置 TCP.VALIDNODE_CHECKING 或防火墙白名单限制可连接来源，关闭不必要的 XDB、HTTP 服务端口。
• Oracle 与操作系统补丁按季跟进。 关注 Oracle 季度安全补丁（CPU / RU）与 Linux 内核提权漏洞，数据库主机不能长期停留在旧版本。
• 收敛 Linux 主机运维面。 禁用密码登录改用密钥、禁止 root 直接远程登录、审计 authorized_keys 与 crontab 变更、oracle 与 grid 账号不复用口令。
• EDR / 主机安全覆盖 Linux 数据库服务器，监控异常 SSH 登录、大量文件改写与加密行为，不要只在 Windows 侧部署。
• 做恢复演练而不是备份检查。 每半年在隔离环境做一次完整 RMAN 恢复演练并计时，得到真实可用的 RTO / RPO 数据。