Oracle Data Guard 本身不防勒索病毒，但通过延迟应用（如 DELAY 1440）、网络/账号/进程三隔离及配合不可变备份（WORM），可大幅降低业务中断和数据丢失风险。
Oracle Data Guard 本身不防勒索病毒，但能大幅降低业务中断和数据丢失风险
很多人误以为开启 Data Guard 就等于“防勒索”，其实不是。Data Guard 的核心能力是 同步/异步复制物理块级数据，它不拦截文件系统层的加密行为，也不阻止恶意进程调用 TerminateProcess 杀掉 oracle.exe。一旦主库被感染，备库若处于实时应用（APPLY）状态，也会在几秒到几分钟内同步被加密的坏块——尤其是当病毒先清空 v$archived_log 并强制归档损坏日志时。
它的真正价值在于：提供一个时间点隔离、网络隔离、权限隔离的副本，让恢复有据可依。关键不在“开不开”，而在“怎么配”。
必须关闭实时应用（MANAGED RECOVERY）并启用延迟应用（DELAY）
默认配置下，备库收到归档日志后立即 RECOVER MANAGED STANDBY DATABASE，这是最危险的模式。勒索病毒加密主库数据后，只要归档日志没被删，备库会在应用过程中把加密结果原样写入数据文件。
正确做法是主动引入“时间缓冲”：
- 在备库执行：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DELAY 1440;（延迟 24 小时） - 配合脚本每日检查
V$ARCHIVED_LOG的APPLIED状态，确认延迟是否生效 - 禁用自动删除归档：确保主库和备库的
LOG_ARCHIVE_DEST_n中不带DELETE ALL或DELETE INPUT - 延迟值不能拍脑袋定——要覆盖你最长备份窗口 + 最长人工响应时间（比如你每天凌晨 2 点全量备份，那延迟至少设为 150 分钟）
备库必须与主库网络/账号/进程三隔离
很多企业把备库装在同一台物理机或同一 VLAN 下，甚至用同一个域账号启动 Oracle 服务，这等于给勒索病毒铺了条高速路。
真实攻击中，.AIR 和 Weaxor 变种都会扫描本地进程列表，一旦发现 oracle.exe，会尝试用相同账号权限远程执行 sqlplus / as sysdba @kill_db.sql。所以：
- 备库操作系统账号必须与主库完全独立，禁止使用域账号或共享本地管理员组
- 主备之间只开放
1521（监听）和22（仅限 rsync/rsyncd 同步归档，非 SSH shell）端口，其他全部封死 - 备库禁用
SQL*Plus、expdp、rman等交互式工具，仅保留RECOVER所需最小权限 - 如果用云环境，备库应部署在独立 VPC，且安全组规则不允许从主库所在子网发起任何出站连接
延迟备库不是万能的，必须搭配不可变存储（immutable backup）
延迟应用只能帮你抢回“昨天的数据”，但无法解决两个致命问题：一是事务日志被病毒截断导致备库无法前滚（ORA-00308），二是病毒清空卷影副本（vssadmin delete shadows）后，连归档日志都可能被删光。
这时候，唯一能救命的是带时间锁的备份副本：
- 用 RMAN 配置
BACKUP ... KEEP UNTIL TIME 'SYSDATE+7' NOLOGS，并确保目标存储支持 WORM（Write Once Read Many）模式 - 不要把备份存在 NAS 共享目录里——Weaxor 已知会遍历
\NASackup并加密.bkp文件；改用对象存储（如 S3 兼容的 MinIO 启用object-lock） - 每晚备份完成后，运行脚本校验
LIST BACKUP OF DATABASE输出，并比对CONTROLFILE中记录的LAST_BACKUP_TIME是否一致
延迟备库 + 不可变备份，才是当前对抗 .AIR、Weaxor 这类“精准锁库”病毒的最低可行防线。别省那几分钟配置时间，等看到桌面弹出 YOUR_DATA_IS_GONE.AIR，再补就只剩赎金支付页面了。
