継続性と復旧：誰も試さなかった復元

すべてのバックアップダッシュボードは緑のチェックマークを表示しています。ジョブが完了し、リテンション ポリシーが満たされ、ストレージが期待通りに使用されています。これらのどれも、実際のインシデント中に4時間以内にドメイン コントローラーをベア メタルから復旧できるかどうかは示していません。「バックアップ成功」と「復元成功」の間のギャップは、ほとんどの継続性計画が静かに失敗する場所です。

チェックマークが嘘をつく理由

バックアップ ソフトウェアは、バイトの書き込みが完了したときに成功を報告します。それらのバイトが使用可能かどうかは知りません。SQL Server バックアップは正常に完了する可能性がありますが、3日前にトランザクション ログ チェーンが破断し、誰も気付かなかったため、復元不可能です。VM スナップショットはコンソールでは問題ないように見えますが、基盤となる VSS ライターはゲスト OS 内で静かに失敗し、クラッシュ一貫性（アプリケーション一貫性ではない）イメージを生成しています。

ランサムウェア オペレーターはこれを知っています。過去のインシデントで Conti スタイルのプレイブックを実行するグループは、バックアップ インフラストラクチャを意図的にターゲットにしました。vssadmin delete shadows /all /quietでシャドウ コピーを削除し、Veeam リポジトリを無効化し、SMB 経由でアクセス可能な NAS ベースのバックアップ ターゲットを暗号化しました。バックアップが本番環境と同じネットワーク セグメントに存在し、それらに触れられるドメイン認証情報がある場合、それはセーフティネットではなくターゲットです。

バックアップ ポリシーではなく復元ランブックを構築する

継続性計画には、通常それを実行しない人のために書かれたステップバイステップの復元指示が必要です。以下を書き留めます：

• 正確な復旧順序（ドメイン コントローラーと DNS を最初に、次にコア アプリ、その後すべて）
• パスワード ボルトも ダウンしている場合にバックアップ コンソール用の認証情報がある場所
• 「Veeam を使用して VM を復元する」ではなく、特定の復元コマンドまたはコンソール パス
• ベンダーのマーケティング番号ではなく、実際に測定されたテストに基づくシステムごとの予想期間

Veeam Backup & Replication の場合、実際のステップを文書化することを意味します：コンソールを開き、Backups > Disk にナビゲートし、復元ポイントを右クリックし、シナリオに応じて Instant VM Recovery または Full VM Restore を選択し、十分な空き容量を持つターゲット ホストを選択します。プライマリ ホストも侵害されている場合は、すでに特定されてライセンスされている、分離された2番目のホストが必要です。

スケジュールに従って復元をテストする、気まぐれではなく

ローテーションを選択します。毎月、1つの重要なシステムを分離された 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つのオフサイト）は、ランサムウェア時代用に更新が必要です：3-2-1-1、ここで追加の「1」はイミュータブルまたはエア ギャップされたコピーです。S3 互換ストレージ（Wasabi、Backblaze B2、または Object Lock が有効な AWS S3）の Object Lock は、定義されたリテンション ウィンドウの間、管理者認証情報を持つアカウントであっても、削除または変更を防ぎます。以下で構成します：

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

COMPLIANCE モードは、ルート アカウントを含む誰もが、リテンション を短縮したり、オブジェクトを早期に削除したりできないことを意味します。これは攻撃者がドメイン管理者権限を持っている場合に重要です。

推測ではなく実数で RTO と RPO を測定する

復旧時間目標と復旧ポイント目標は、経営幹部が「どのくらいのデータを失い、どのくらい ダウンタイムがあるのか」と尋ねるまで、事務作業のように見えます。最後の3つのテスト復元の時間を計ります。RPO 目標が1時間だが、バックアップ ジョブが6時間ごとにしか実行されない場合、文書化されたギャップがあり、土曜日の午前2時の実際の暗号化イベント中ではなく、テーブルトップ エクササイズでそのギャップを見つける方が良いです。

テストを実行し、実際のクロック時刻を書き留め、ディザスタ リカバリー ドキュメントで約束したものと比較します。これら2つの数値の差は、継続性計画の実際の状態です。

保護しているシステムの強化と インシデント対応ワークフローの構築の詳細については、Korra Studio の関連する Blue Team および Digital Forensics セクションを確認してください。