バックアップの3-2-1ルールとは？IaaS時代に求められる「3-2-1-1-0」への進化と実践ガイド

バックアップの3-2-1ルールとは、「3つのデータコピーを保持し、2種類の異なるメディアを使用し、少なくとも1つをオフサイト（遠隔地）に保管する」という世界標準のデータ保護フレームワークです。米国のCISA（サイバーセキュリティ・インフラストラクチャセキュリティ庁）も公式文書で3-2-1ルールを推奨しています。

一方、ランサムウェア攻撃がバックアップデータそのものを標的とする現在の脅威環境下では、従来の3-2-1ルールをさらに強化した「3-2-1-1-0」という考え方が広く紹介されています。

本記事では、IaaS環境（AWS／ Microsoft Azure （以下 Azure）／GCP）を活用するエンタープライズ企業向けに、経営層や監査機関に対して復旧の確実性を論理的に説明できるバックアップ戦略を体系的に解説します。

ランサムウェア攻撃の高度化とIaaS環境の普及により、従来のバックアップ戦略は根本的な見直しを迫られています。本章では、最新のインシデント事例、責任共有モデル、そして経営視点から、バックアップ再定義の重要性を明らかにします。

大手企業のランサムウェア被害が示す「バックアップ神話」の崩壊

トレンドマイクロ社の集計によると、2025年に国内で公表されたセキュリティインシデントは559件にのぼり、1日あたり約1.5件のペースでした。Cisco Talosの調査によれば、2025年上半期だけで国内68件のランサムウェア被害が確認されており、最も影響を受けている業種は製造業（18.2%）です。

とりわけ衝撃的だったのは、2025年に発生した大規模インシデントです。ある大手流通企業では受注・出荷システムが全面停止し、サプライチェーン全体への影響が2か月以上にわたって続きました。復旧までの間に生じた売上損失やレピュテーション低下は甚大で、JNSAの「2025セキュリティ十大ニュース」第1位に選出されています。

これらの事例に共通するのは、「バックアップがあれば安心」という前提の崩壊です。攻撃者は侵入後すぐに暗号化するのではなく、数日から数か月にわたって潜伏し、管理者権限の奪取やバックアップデータの削除といった周到な準備を重ねます。さらに、クラウドストレージ上のデータを直接削除して対価を要求する新たな手口も報告されています。

責任共有モデルの正しい理解 ― クラウドが守る範囲と守らない範囲

クラウド活用における最大の誤解は「ベンダーがすべてを守ってくれる」という思い込みです。責任共有モデルにおける役割分担を正しく理解し、利用者側も対策を行う必要があります。

2025年に報告されたインシデントの中には、クラウドストレージのIAMアクセスキーが窃取され、バックアップを含む全データが直接削除された事例もあります。Verizonの「2025 Data Breach Investigations Report」によると、調査対象の侵害事例の44%にランサムウェアが関与し、サードパーティ経由の侵害は前年の15%から30%へと倍増しています。

経営層・監査が求める「説明可能な復旧体制」

現代のITリーダーに求められるのは、CISAをはじめとする公的機関のガイドラインに沿い、「なぜこの構成で復旧できると言えるのか」を論理的に証明できるバックアップ体制の構築です。

国内でも、2022年4月施行の改正個人情報保護法では漏洩時の報告義務が課され、経産省の「サイバーセキュリティ経営ガイドライン」ではサプライチェーンを含めた対策推進が明示されています。IPAの「情報セキュリティ10大脅威」では「ランサムウェアによる被害」が組織部門で10年連続選出（直近5年間は連続1位）です。

BCP（事業継続計画）の観点からも見直しは避けて通れません。前述の大手流通企業のケースが示すように、サイバー攻撃は「事業中断リスク」に直結します。こうした規制強化の流れが、経営レベルでのバックアップ戦略見直しを後押ししています。具体的な説明手法や投資判断の獲得方法は後述します。

バックアップの3-2-1ルールは、2005年に写真家ピーター・クローグ（Peter Krogh）が著書『The DAM Book: Digital Asset Management for Photographers』初版で提唱し、広く知られるようになった概念です。

3-2-1ルールの定義と起源

冒頭で述べた通り、3-2-1ルールは「3コピー・2メディア・1オフサイト」というシンプルな原則で単一障害点を排除し、地理的リスクにも対応できるフレームワークです。提唱から20年が経った現在もCISAが「信頼できるガイドライン（a trusted guideline）」として紹介しており、NISTのバックアップ関連ガイドラインの考え方とも整合しています。この国際的な推奨があるからこそ、経営層や監査に対する説明責任の基盤としても機能するのです。

「3」コピー ：複数コピーでデータ消失リスクを最小化

データを3つ維持することで、すべてを失う確率を極限まで低減できます。これは独立事象の確率論に基づいています。たとえば年間故障率1%のデバイス1台では、データを失う確率は1%ですが、独立した3台に保管すれば同時に故障する確率は0.0001%（100万分の1）まで低下します。ただし、同一メーカー・同一ロットのディスクを同じ場所に置いていれば故障の連鎖が起こり得るため、次の「2メディア」の原則と組み合わせることが重要です。

「2」メディア ：技術的単一障害点の排除

異なるストレージ技術（磁気ディスク、フラッシュメモリ、磁気テープ、クラウドオブジェクトストレージ）は、それぞれ異なる故障モードを持ちます。メディアを分散させることで、特定技術に起因する「共倒れ」リスクを排除します。

「1」オフサイト ：地理的レジリエンスの確保

火災、地震、洪水などのサイトレベル災害からデータを守る最後の砦です。日本は自然災害のリスクが高い国であり、オフサイト保管の重要性は欧米以上に高いといえます。クラウドの場合、別リージョン（たとえば東京と大阪）へのレプリケーションがこれに該当します。

3-2-1ルールのメリットと適用範囲

3-2-1ルールを適切に実装することで、複数リスクへの同時対応、復旧ポイントの選択肢確保、コンプライアンス・監査対応の基盤構築が可能となります。特に大企業では、取引先や監査法人から「バックアップ体制の根拠」を求められる場面が増えており、国際的に認知されたフレームワークへの準拠は対外的な信頼性を担保する強力な材料となります。

3-2-1-1-0ルールは、従来の3-2-1原則に「不変性（Immutability）」と「検証（Verification）」を追加した実践的フレームワークです。
Hornetsecurity社の年次調査（2025年版）によると、世界のCISOの61%が「AIがランサムウェアリスクを直接的に高めた」と認識しており、攻撃の高度化は加速しています。「攻撃を受ける前提で、バックアップから確実に復旧させる」という発想への転換が求められる中、その要件を体系化したのが3-2-1-1-0ルールです。

3-2-1-1-0ルールの全体像

3-2-1-1-0ルールの各要素は以下の通りです。

追加の「1」： イミュータブル（不変）コピーの概念

追加の「1」は、WORM（Write Once Read Many）技術を用いた変更不可コピー、または物理的にネットワークから切り離されたオフラインコピーを指します。

追加の「0」：復元エラーゼロの検証

「0」は、定期的なリストアテストにより「復元時にエラーがゼロ」であることを検証済みの状態を指します。バックアップは取得して終わりではなく、「実際に戻せること」を確認してはじめて価値を持ちます。
JNSA（日本ネットワークセキュリティ協会）の「インシデント損害額調査レポート 2025年版」によると、ランサムウェア被害からバックアップで復旧できた組織は73%にとどまり、残り27%はバックアップ未取得やバックアップ自体の暗号化により復旧できませんでした。また、被害組織が事故対応に要した内部工数は平均19.7人月に達しますが、これをコストとして把握していない企業も多いのが実態です。「確実に復元できる」状態を維持し、定期的に検証することが、被害を最小限に抑える鍵となります。

IaaSへの移行により、バックアップ戦略の舞台は物理サーバーからAPIとサービスへ移行しました。本章では、3-2-1-1-0の各要素をクラウドサービスの機能にマッピングし、具体的な実装方法の例を解説します。

「3コピー」の実装： 本番・スナップショット・リージョン間レプリケーション

IaaS環境における3つのコピーは、以下の組み合わせで実現します。GCPにも同等の機能が存在しますが、統合マネージドサービスの体系化に差があるため、ここではAWS・Azure を中心に解説します。

「2メディア」の実装 ：ストレージ階層の使い分け

クラウド環境では、ストレージ階層の使い分けによって「メディアの多様性」を実現します。各階層は異なるアーキテクチャで構成されており、アクセス速度とコストのバランスが異なります。

「オフサイト＋イミュータブル」の実装 ：オブジェクトロックとアカウント分離

不変性とオフサイトを同時に実現する推奨構成は以下の通りです。なお、GCPについてはCloud Storageのバケットロック機能やRetention Policyにより不変性を実現できますが、AWSのObject Lockや Azure の Immutable Blob Storage と比較すると、バックアップ特化の統合管理機能としての成熟度に差があるため、本表ではAWS・Azure を中心に記載しています。GCP環境で同等の構成を実現する場合は、バケットロック＋組織レベルのプロジェクト分離を組み合わせた設計をお勧めします。

「検証エラーゼロ」の実装 ：自動リストアテストと監視

自動検証の実装アプローチは以下の通りです。フルリストア訓練は形骸化しやすいため、四半期に1回以上の実施を組織ルールとして明文化し、結果を経営層に報告する仕組みを設けるとよいでしょう。

マルチクラウド環境では、Veeamなどのサードパーティ製バックアップツールが3クラウド横断で利用可能なため、統合管理の観点から有力な選択肢となります。

RTO/RPOに基づくバックアップ設計指針

システムの重要度に応じて、RTO（復旧目標時間）とRPO（復旧目標時点）を定義し、適切な構成を選択します。RTOは「障害発生からシステム復旧までに許容される最大時間」、RPOは「データ損失として許容できる最大期間」を意味します。

技術的な要件を満たしていても、組織・プロセス面の課題によってバックアップ戦略が機能しないケースは多くあります。本章では、運用面に限定した失敗パターンと成功要因を解説します。

失敗パターン①：バックアップ設計の属人化

部門ごとにクラウドインスタンスが乱立し、標準化されたバックアップ設定が存在しない状態は危険です。担当者の異動や退職で設定の意図が不明になり、重要システムのバックアップ未取得がインシデント後に判明するケースが後を絶ちません。バックアップポリシーを全社標準として策定し、IaC（Infrastructure as Code）で管理することが有効です。

失敗パターン②：復旧テスト・訓練の省略

「バックアップ完了」通知を受け取るだけで満足し、実際の復旧テストを一度も実施していない企業は少なくありません。前述の大規模インシデントが示すように、バックアップがあっても「安全性を確認しながら慎重に復旧する」プロセスには相応の時間を要します。定期的な復旧訓練を通じて、復旧手順の習熟と所要時間の把握を行うことが重要です。

失敗パターン③：コスト最適化による階層設計の欠如

「コスト削減」の名の下にすべてのバックアップをArchiveストレージに保管した結果、復旧に数時間から数日を要するケースがあります。コスト削減と復旧速度はトレードオフの関係にあるため、システムの重要度に応じてHot・Cool・Archiveを適切に使い分けることが不可欠です。

運用を成功に導く3つの要因

バックアップ強化の投資判断を得るためには、技術論ではなく「経営リスク」と「復旧の確実性を裏付ける根拠」で説明する必要があります。

経営会議で伝えるべき3つのポイント

監査対応で求められる証跡と文書化

IT部門が提示すべき「復旧の確実性を裏付ける根拠」は以下の項目に集約されます。

事業部との調整を円滑にする進め方

全社ルール変更への抵抗を軽減するには、「CISAが推奨」「競合他社も採用」という外部権威の活用、Critical Asset（重要資産）からの段階的導入、各部門への影響範囲と対応スケジュールの可視化が有効です。

バックアップ投資の考え方とコスト構造

バックアップ 3-2-1 ルールについて、よくある質問と回答をまとめました。

ランサムウェアがバックアップ自体を標的とする現在、従来の3-2-1ルールにイミュータブルコピーと検証を加えた3-2-1-1-0ルールへの進化が不可欠です。
本記事ではIaaS環境に焦点を絞って解説しましたが、実際にはオンプレミスやSaaSを含めた自社環境全体を俯瞰し、最適なバックアップ構成を検討する必要があります。ＪＢＣＣでは、セキュリティ対策にとどまらず、クラウドを含む様々なお客様環境の設計・構築からインフラの継続的な運用支援までをワンストップで提供しています。バックアップ戦略の見直しやクラウド移行をご検討の際は、お気軽にご相談ください。

バックアップ戦略の見直しやクラウド移行をご検討中の方へ

「コスト最適化とセキュリティ強化を両立したい」「自社だけで対応できるか不安」——そんなお悩みは、ＪＢＣＣのクラウド専門家が無料で解消します。

クラウド相談会に申し込む