バックアップ戦略：3-2-1 ルール

バックアップ戦略

レジリエントなバックアップ戦略は、ランサムウェア、ハードウェア障害、自然災害、ヒューマンエラー、データ破損、または本番システムを破壊する悪意ある攻撃によって引き起こされるデータ損失に対する最後の防衛線です。適切なバックアップがなければ、数時間のリストアで解決できたはずのインシデントが、重要データの永久的な損失、数日から数週間のダウンタイム、ひいては事業の破綻へと発展しかねません。基本となる 3-2-1 ルール（データを 3 つのコピーで、2 種類の異なるメディアに保持し、そのうち 1 つのコピーをオフサイトに置く）は依然として有効ですが、現代の環境向けに次のような概念を取り入れて拡張する必要があります。すなわち、ランサムウェア対策のためのイミュータブルバックアップ（保持期間中は管理者であっても削除も変更もできないバックアップ）、バックアップが必要なときに実際に機能することを検証する定期的なリストアテスト（多くの組織は、緊急時に必要となって初めてバックアップが破損していることに気づきます）、RPO（Recovery Point Objective ― 前回のバックアップからの時間で測る、許容できるデータ損失量）と RTO（Recovery Time Objective ― システムがリストアされるまでにオフラインでいられる時間）の明確な定義、Active Directory を侵害した攻撃者がすべてのバックアップまで破壊することを防ぐためのバックアップ認証情報のメインドメインからの分離、そしてバックアップが想定どおりに実行されることを保証するための監視とアラートを備えたバックアッププロセスの自動化です。よくある誤りは、バックアップを「set and forget」として扱うことです。バックアップには、継続的な注意、検証、インフラの進化に応じた手順の更新、そして何よりも、新機能の開発と同じくらいデータ保護を重視する組織文化が必要です。

3-2-1 ルール：冗長性の基礎

3-2-1 ルールでは、データを 3 つのコピー（本番 + 2 つのバックアップ）で、2 種類の異なるストレージメディアに保持し、そのうち 1 つのコピーを地理的に離れたオフサイトに置くべきと定めています。たとえば、本番データを SAN（Storage Area Network）に、プライマリバックアップを同じ datacenter 内の NAS（Network Attached Storage）に、セカンダリバックアップを別リージョンのクラウドストレージ（S3、Azure Blob）に置きます。メディアの多様性は、特定技術固有の障害から保護します。すべてのバックアップを磁気テープに保持していて、tape drive が動作しなくなったことが判明した場合、テープがあってもリストアできない可能性があります。オフサイトのコピーは、局所的な災害（火災、洪水、盗難、datacenter への物理的攻撃）から保護します。すべてのバックアップが焼失した同じ建物内にあれば、すべてを失います。3-2-1 の現代的な発展形が 3-2-1-1-0 です。3 つのコピー、2 種類のメディア、1 つのオフサイト、1 つのイミュータブル、0 個のエラー（リストアテストで検証済み）。実装方法：バックアップソフトウェア（Veeam、Commvault、Bacula、Acronis、AWS Backup、Azure Backup）を構成して重要システムの日次 snapshots を作成し、それらのバックアップをローカルストレージに複製し（1 つ目のコピー）、コピーをクラウドに送信し（2 つ目のオフサイトコピー）、クラウドのコピーを Object Lock（S3）または Immutable Blobs（Azure）でイミュータブルとしてマークします。必要なストレージは次の式で計算します：データサイズ × 保持期間 × 変更率。10TB のデータがあり、バックアップを 30 日間保持したく、データの 10% が毎日変更される場合、バックアップにはおよそ 10TB + (10TB × 0.1 × 30) = 40TB のストレージが必要になります。コストを削減するために重複排除と圧縮を使用しますが、データをランダムに見せて dedupe の効率を低下させる可能性のある crypto ransomware には注意してください。

ランサムウェア対策のイミュータブルバックアップ

現代のランサムウェアは本番データを暗号化するだけでなく、被害者に身代金支払いを迫る圧力を最大化するために、バックアップを積極的に探し出して破壊します。攻撃者は侵害した管理者認証情報を使用して snapshots を削除し、バックアップサービスを無効化し、backup catalogs を破損させ、さらにはバックアップそのものを暗号化します。イミュータブルバックアップ（WORM ― Write Once Read Many、または air-gapped backup とも呼ばれます）は、定義された retention period 中はバックアップの削除も変更も不可能にすることで、最大権限を持つ管理者であってもこれを行えないようにし、これを防ぎます。実装例：Compliance モードの AWS S3 Object Lock（root account でさえ expiration date より前にオブジェクトを削除できません）、legal hold または time-based retention policies を備えた Azure Blob Immutable Storage、物理的に取り外してオフサイトの vault に保管するテープバックアップ、WORM mode を備えた backup appliances（Dell EMC Data Domain、Cohesity）。適切な retention period を構成します。通常は、RPO と、過去バージョンを保持する必要のある期間に応じて 30～90 日です。重要：イミュータビリティは削除を防ぎますが、新たな破損バックアップの作成は防げません。攻撃者がランサムウェアを起動する前に数週間にわたってシステムを侵害していた場合、イミュータブルバックアップにはすでに感染したデータが含まれている可能性があります。解決策：複数バージョンのバックアップを保持し（最新のものだけでなく）、データの異常を検出する backup validation を使用し（エントロピーの急増は encryption を示している可能性があります）、バックアップを定期的にネットワークから完全に切り離されたストレージにコピーする物理的な「air gap」を検討してください。一部のシステムには、イミュータビリティが legitimate restore operations すら妨げてしまう bugs があるため、イミュータブルバックアップのリカバリを定期的にテストしてください。

リストアテストと検証

テストされていないバックアップは信頼できないバックアップです。何年も忠実にバックアップを行っていたにもかかわらず、disaster recovery の際にバックアップが破損していた、構成が誤っていた、メディアが劣化していた、あるいはリストアプロセスがまったく機能しなかったことが判明した企業の事例は、数え切れないほど記録されています。正式な backup testing プログラムを実装してください：月次でテスト環境への本番の完全リストア（full system restore）、週次で重要な VMs/データベースのリストア（partial restore）、日次で backup job logs の検証（バックアップがエラーなく完了したことの確認）。次を行うスクリプトを使用してテストを自動化します：隔離環境でリストアを開始し、リストアされたデータの整合性を検証し（checksums、database consistency checks）、リストア時間を測定し（RTO を満たせるかを検証）、メトリクスを含む reports を生成します。データベースには、DBMS 自体の backup restore validation を使用します：SQL Server RESTORE VERIFYONLY、MySQL mysqlcheck、PostgreSQL pg_restore --list。アプリケーションのバックアップには、リストアして、重要な機能を検証する自動化された smoke tests を実行します。各テストを記録します：日付、テストしたシステム、結果（成功/失敗）、経過時間、発見された問題、是正措置。restore tests の失敗は P0 incidents として扱ってください。バックアップテストが失敗した場合、修正するまでは機能するバックアップがないものと想定します。事前通知なしにチームに対し、Y 時間以内にシステム X をリストアする必要があると伝え、実際の緊急事態をシミュレートする「surprise restore drills」の実施を検討してください。これらの drills は、バックアップの検証に加えて、チームに recovery 手順を訓練させ、ドキュメントや自動化における gaps を特定します。

RPO と RTO：Recovery 目標の定義

RPO（Recovery Point Objective）は、時間で測った、許容できる最大のデータ損失量です。RPO が 4 時間であれば、少なくとも 4 時間ごとにバックアップを行う必要があり、災害時には最大 4 時間分のトランザクションを失う可能性があります。RTO（Recovery Time Objective）は、システムがリストアされるまでオフラインでいられる最大時間です。RTO が 2 時間であれば、インシデントの検出からシステムが再び稼働するまでに 2 時間あります。RPO と RTO は business requirements（事業が許容できるデータ損失量と downtime）によって定義されなければならず、バックアップアーキテクチャを規定します：重要な tier-1 アプリケーションは RPO=0（同期レプリケーションによるデータ損失ゼロ）と数分の RTO（high availability cluster）を要求する場合があり、tier-2 アプリケーションは RPO=1h（毎時の増分バックアップ）と RTO=4h を許容でき、tier-3 アプリケーションは RPO=24h（夜間バックアップ）と RTO=8h でよい場合があります。コスト対リスクを計算してください：RPO が小さいほどバックアップの頻度が増し（ストレージの増加、パフォーマンスの overhead の増加）、RTO が小さいほどより高度な recovery システム（hot standby、automated failover）が必要になります。異なる tiers 向けのアーキテクチャ例：Tier-1（ERP、Payment Processing）― DR site への同期レプリケーション + 15 分 snapshots + 日次イミュータブルバックアップ、RPO は 15 分未満、RTO は 1h 未満；Tier-2（CRM、Email）― 1h の増分バックアップ + 日次 full バックアップ、RPO=1h、RTO=4h；Tier-3（File Shares、Logs）― 日次バックアップ、RPO=24h、RTO=8h。各システムの RPO/RTO を Disaster Recovery Plan に記録し、business stakeholders の sign-off を取得し（期待値の整合を確保するため）、定義した目標を満たせているかを監視します（インシデントにおける actual recovery times を追跡）。

バックアップ認証情報の分離

backup system が同じ AD の認証情報を使用している場合、Domain Admin 権限で Active Directory を侵害した攻撃者は、すべてのバックアップにアクセスして破壊できる可能性があります。これはランサムウェア攻撃でよく見られるベクターであり、攻撃者はまず AD に persistence を確立し、次にバックアップインフラ全体をマッピングし、最終的に encryption を起動する前にバックアップを破壊します。認証情報の分離によってこれを緩和します：backup infrastructure 用に別個のドメインまたは standalone workgroup を作成し、可能な場合は domain accounts ではなくローカルの service accounts を使用し、backup appliances を AD から独立した独自の認証で構成し、backup console とストレージへのアクセスに MFA を実装し、クラウドバックアップには広範なアクセス権を持つ認証情報ではなく、制限された権限を持つ API keys を使用します。Veeam 環境では「hardened Linux repository」を実装します。backup server を Linux とし（Windows AD の外側）、key-based auth による SSH 経由でのみアクセス可能とし、Veeam console を通じたバックアップの削除を不可能にします（immutability を Linux filesystem レベルで強制）。AWS バックアップでは cross-account backup vault を使用します。バックアップは、共有されていない認証情報を持つ別チームが管理する別個の AWS account に送信され、削除を防ぐために Vault Lock を構成します。least privilege の原則を適用します：バックアップを実行するアカウントは、本番での read access と backup destination での write access のみを必要とし、delete permissions は必要ありません。backup infrastructure へのアクセスを high-value targets として監視します。バックアップウィンドウ外、または予期しない IPs からのアクセス試行は、いずれもセキュリティアラートを生成すべきです。極端なケースでは「offline backup admin」を検討します。バックアップ管理の認証情報はデジタル形式では存在せず、物理的な vault に保管され、緊急時にのみアクセスされます。