連續性與復原：沒有人測試過的還原

每個備份儀表板上都是綠色勾號。工作完成、保留政策滿足、儲存空間使用如預期。但這些都無法告訴你，在實際事件發生時，能否在四小時內從裸機還原網域控制器。「備份成功」與「還原成功」之間的落差，正是大多數連續性計畫悄悄失敗的地方。

為什麼勾號會說謊

備份軟體在完成將位元組寫入目的地時回報成功。它不知道那些位元組是否可用。SQL Server 備份可以乾淨地完成，但仍然無法還原，因為交易日誌鏈在三天前就斷裂了，沒人注意到。VM 快照在主控台看起來沒問題，但客體 OS 內的底層 VSS 寫入器悄悄失敗，產生了損毀一致（而非應用程式一致）的映像。

勒索軟體操作者知道這一點。執行過去事件中 Conti 樣式腳本的組織刻意針對備份基礎設施——用 vssadmin delete shadows /all /quiet 刪除陰影副本、禁用 Veeam 儲存庫、加密可透過 SMB 存取的 NAS 型備份目標。如果你的備份與生產環境在同一網路區段上，而且擁有可以存取它們的網域認證，它們就是一個目標，而不是安全網。

建立還原手冊，而不是備份政策

連續性計畫需要為非通常執行者編寫的逐步還原指示。記下：

• 確切的復原順序（網域控制器和 DNS 優先，然後核心應用程式，最後是其他所有內容）
• 密碼保管庫也當機時，備份主控台認證的位置
• 具體的還原命令或主控台路徑，而非「用 Veeam 還原 VM」
• 每個系統的預期持續時間，基於實際測試的測量值，而非廠商行銷數字

對於 Veeam Backup & Replication，這表示記錄實際步驟：開啟主控台、瀏覽至 Backups > Disk、右鍵點擊還原點、根據情境選擇 Instant VM Recovery 或 Full VM Restore，然後選擇有足夠可用容量的目標主機。如果主要主機也遭到破壞，你需要一個已識別且已授權的第二個隔離主機。

按照時程表測試還原，而不是臨時起意

選擇一個輪轉。每個月，將一個關鍵系統還原到隔離的 VLAN，驗證它能開機、認證且正確提供資料。每季執行一次全面範圍測試：將網域控制器、檔案伺服器和主要資料庫還原到隔離的基礎設施，然後讓備份小組之外的人嘗試登入並提取報告。

對於資料庫，不只是還原 .bak 檔案——驗證它：

RESTORE VERIFYONLY FROM DISK = 'D:\Backups\prod_2024.bak'

然後實際將它還原到測試執行個體，並執行 DBCC CHECKDB。通過 VERIFYONLY 的備份仍然可能包含邏輯損毀，只有在查詢時才會顯示。

對於使用 Bacula 或 restic 之類的 Linux 系統，測試實際的還原路徑：

restic restore latest --target /tmp/restore-test --repo /mnt/backup-repo

然後比對還原的設定檔與生產環境，確認沒有任何內容悄悄遺漏。

不可變副本與 3-2-1-1 規則

經典的 3-2-1 規則（三份副本、兩種媒體類型、一份異地備份）在勒索軟體時代需要更新：3-2-1-1，額外的「1」是不可變或隔離的副本。S3 相容儲存上的 Object Lock（Wasabi、Backblaze B2 或啟用 Object Lock 的 AWS S3）可防止在定義的保留期內進行刪除或修改，即使是具有管理員認證的帳戶也不行。用以下方式設定：

aws s3api put-object-lock-configuration \
  --bucket backup-vault \
  --object-lock-configuration '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":30}}}'

COMPLIANCE 模式表示沒有人，包括 root 帳戶，可以縮短保留期或提前刪除物件。當攻擊者擁有網域管理員時，這很重要。

用實際數字測量 RTO 和 RPO，而不是猜測

恢復時間目標和恢復點目標聽起來像文件練習，直到主管問「我們會損失多少資料，停機多久」。記錄最後三次測試還原的時間。如果你的 RPO 目標是一小時，但備份工作只是每六小時執行一次，你就有一個記錄在案的落差，最好在桌面演習中找到它，而不是在星期六早上 2 點的實際加密事件中。

執行測試、記下實際時鐘時間，並將其與災難復原文件中的承諾進行比較。這兩個數字之間的差異是連續性計畫的真實狀態。

欲瞭解有關強化你正在保護的系統和建立事件回應工作流程的更多資訊，請查看 Korra Studio 上相關的 Blue Team 和 Digital Forensics 部分。