Backup and Recovery (バックアップ・復旧)

article technology medium #バックアップ#復旧#イミュータブル#ランサムウェア対策#RPO-RTO#3-2-1-1-0#cybersecurity#data-security
Created: 2026-05-31 Updated:

ランサムウェア時代の最後の防衛線。3-2-1-1-0 ルールとイミュータブルバックアップ(WORM / AWS S3 Object Lock)が復旧成功率を 62% から 99.7% に引き上げる仕組みと RPO・RTO 設計を解説する。

バックアップ・復旧

バックアップはサイバーセキュリティにおける「最後の防衛線」である。インシデント発生後でもデータを取り戻せる唯一の手段であり、特にランサムウェア攻撃では「バックアップがあるから身代金を払わない」という交渉力に直結する。2025 年の調査ではランサムウェア被害 1,300 件のうち 89% がバックアップリポジトリ自体を標的にしていた。本記事では 3-2-1-1-0 ルール・イミュータブルバックアップ・エアギャップ・RPO・RTO・復旧テストを体系的に解説する。

3-2-1-1-0 ルール:現代のベストプラクティス

従来の「3-2-1 ルール」(3 コピー / 2 媒体 / 1 オフサイト)はランサムウェアが普及する前の時代に策定されたものだ。現代のベストプラクティスは 3-2-1-1-0 に拡張されている。

数字意味目的
3データコピーを 3 つ保持(本番 + バックアップ 2 つ)単一障害点を排除
22 種類の異なる媒体(例:ディスク + テープ)媒体固有の障害に備える
11 つをオフサイト(別拠点・クラウド)に保管物理災害(火災・水害)に備える
11 つをイミュータブル(変更不可)にするランサムウェア・内部犯行による改ざんを防ぐ
0バックアップエラーゼロ(復旧テスト検証済み)「バックアップがあるが復旧できない」を防ぐ

2025 年調査では 3-2-1-1-0 を実践した組織の復旧成功率は 99.7% であり、従来手法の 62% と比較して劇的に改善されている(情報カットオフ ~2025-08 で確認済み)。

イミュータブルバックアップ:WORM と Object Lock

イミュータブルバックアップとは一定期間変更・削除ができないバックアップであり、WORM(Write Once Read Many)技術によって実現される。ランサムウェアがバックアップサーバーを侵害しても、イミュータブルなバックアップは暗号化・削除できない。

クラウド実装

  • AWS S3 Object Lock:オブジェクト単位で保持期間(Governance / Compliance モード)を設定する。Compliance モードは管理者権限でも削除不可。
  • Azure Immutable Blob Storage:時間ベースまたはポリシーベースの不変性ポリシーを設定する。コンテナ全体をロックできる。

オンプレミス実装

  • Veeam Hardened Repository:Linux 不変性機能(immutable flag)を活用した強化済みリポジトリ。
  • Rubrik(クラウド・オンプレ両対応)・Cohesity DataProtect:専用 OS で管理するため通常の OS 攻撃経路が存在しない。
  • 物理 WORM テープ(LTO テープ + WORM カートリッジ):書き込み後は物理的に変更不可。

イミュータブルバックアップの保持期間設計は「組織が想定する最長の攻撃潜伏期間(ドウェル タイム)」以上に設定することが重要だ。ランサムウェアが数週間から数ヶ月間潜伏した後に発動するケースが増えており、30 日以上の保持が推奨される。

エアギャップ:物理的・論理的な分離

エアギャップ(Air Gap)はバックアップを本番ネットワークから物理的または論理的に切り離すことで、攻撃者がバックアップに到達できない状態を作る技術だ。

物理エアギャップ:テープを取り出してオフサイトに運搬する「テープローテーション」が古典的な実装だ。ネットワーク経由では到達不可能だが、テープの搬送に時間がかかり RPO(復旧目標時点)が長くなる。

論理エアギャップ(2025 年主流):クラウドオブジェクトストレージの Object Lock・専用のバックアップクラウドテナント(本番テナントとは別の AWS アカウント / Azure サブスクリプション)・ネットワーク分離されたバックアップストレージなど、論理的に切り離す方式。物理エアギャップより RPO を短くしながら、イミュータブル性を確保できる。

「論理エアギャップ」は完全な物理的切り離しではないため、ソフトウェアの実装品質がセキュリティ強度に直結することに留意が必要だ([VERIFY] 論理エアギャップが物理エアギャップと同等の保護を提供するかはベンダー実装によって異なる)。

RPO と RTO:バックアップ設計の二つの指標

バックアップ設計は「どこまでのデータ損失を許容するか」「どれだけの時間で復旧するか」という二つの指標によって決まる。

RPO(Recovery Point Objective:復旧目標時点) はデータ損失の許容範囲を時間で表す。RPO が 1 時間であれば「最大 1 時間分のデータ損失まで許容する」ことを意味し、バックアップは少なくとも 1 時間ごとに取得する必要がある。

RTO(Recovery Time Objective:復旧目標時間) はシステムが停止してから復旧するまでの許容時間だ。RTO が 4 時間であれば「4 時間以内に業務を再開しなければならない」を意味し、バックアップの取得だけでなく「リストアの速度」がシステム選定を左右する。

ビジネス要件RPO 目安RTO 目安実装例
ミッションクリティカル(金融)数秒〜数分数分〜15 分レプリケーション + スナップショット
重要業務システム15〜60 分1〜4 時間継続的データ保護(CDP)
一般業務システム1〜24 時間4〜24 時間定期スナップショット + クラウドバックアップ
非重要データ24〜72 時間24〜72 時間日次バックアップ + オフサイトテープ

RPO / RTO の設計はビジネス部門と IT が合意した「SLA(Service Level Agreement)」として文書化し、バックアップシステムの選定・テスト頻度・復旧手順書の更新に反映させる。

ランサムウェア対策としてのバックアップ戦略

ランサムウェア攻撃における被害 1,300 件のうち 89% がバックアップリポジトリを標的にした(情報カットオフ ~2025-08 で確認済み)。攻撃者はまずバックアップを暗号化・削除してから本番データを暗号化することで、被害者の「バックアップから復旧する」という選択肢を奪う戦略をとる。

有効な対策の組み合わせ:

  1. イミュータブルバックアップ(必須):攻撃者がバックアップサーバーを制御してもバックアップは変更不可
  2. バックアップ専用認証:本番環境の管理者権限ではバックアップを削除できない設計
  3. ネットワーク分離:バックアップサーバーを本番セグメントから分離し攻撃経路を断つ
  4. 3-2-1-1-0 ルールの徹底:最低 1 つは攻撃者が到達できない場所に保管
  5. 異常検知:バックアップジョブの失敗・バックアップストレージへの予期しないアクセスをアラート化

復旧テスト:「0 エラー」の意味

3-2-1-1-0 の「0」はバックアップが「テストされていること」を要求する。バックアップが存在してもリストアできなければ意味がない——この「存在するが復旧できない」障害は業界で頻繁に発生する。

復旧テストの実施方式

  • 定期リストアテスト:四半期または年 1 回、実際にバックアップからシステムを復元して動作を確認する。本番環境への影響を避けるため、専用のテスト環境(サンドボックス)で実施する。
  • 自動化リストアテスト(推奨):Veeam SureBackup・Rubrik LiveMount など、バックアップ直後に自動で VM を起動してアプリケーション動作を検証するツールを活用する。
  • 復旧手順書のリハーサル:手順書が最新かつ実際に使えるかを確認する演習。担当者交代時にも引き継げる文書であることが重要だ。

復旧テストの結果は記録し、RPO / RTO の達成可否・課題・改善アクションを文書化する。

アンチパターン:バックアップの落とし穴

アンチパターンリスク
バックアップを一度もテストしないインシデント時にリストアできず「バックアップが壊れていた」と判明
イミュータブルなしで暗号化対策を主張するランサムウェアがバックアップを暗号化して「人質」にされる
RPO・RTO を定義せずにバックアップツール選定業務要件と乖離したシステムを購入し、障害時に SLA を満たせない
バックアップサーバーを本番セグメントに配置本番サーバーが侵害されるとバックアップも同時に失われる
「クラウドに同期しているから大丈夫」という誤解クラウド同期(Google Drive・OneDrive 等)はバックアップではなく、ランサムウェアが即座に上書きされる

Local graph