ランサムウェア対策の多層防御：3-2-1バックアップだけでは足りない理由
本記事はアフィリエイト広告を含みます。価格・仕様は2026年7月時点の目安です。最新は各公式サイトでご確認ください。
TL;DR
- 警察庁の統計（令和7年上半期）では、ランサムウェア被害を受けた企業の85.4%がバックアップからの復元に失敗しています。3-2-1を設定済みの企業も多数含まれています。
- 3-2-1が機能しない根本原因は3つに集約されます。①本番環境と同じAD認証情報でバックアップを管理している、②オフサイトバックアップがネットワークに常時接続している、③復元テストを一度も実施していない。
- Veeamが提唱する3-2-1-1-0ルールは、この3つに対して「イミュータブルまたはエアギャップのコピーを1つ」と「復元エラーゼロの定期テスト」を追加した設計です。
- 実装オプションはクラウド環境ならS3 Object Lock、既存Veeam環境ならHardened Linux Repository、規制対応・大規模環境ならテープ（物理エアギャップ）の3系統が現実的です。
「バックアップは3-2-1で設定済みです。」——この報告が、ランサムウェア被害後に意味を失う場面は珍しくありません。
富士ソフトのTech Tipsによれば、警察庁「令和7年上半期サイバー空間をめぐる脅威の情勢等」の統計では、ランサムウェア攻撃を受けた企業の85.4%がバックアップから復旧できていません。3-2-1を組んでいた企業がなぜ復元に失敗するのか。その原因は3つの構造的な盲点に集約されます。
この3つの原因はいずれも、Veeam提唱の3-2-1-1-0ルールとイミュータブルバックアップで塞げます。
3-2-1ルールの基本設計については、3-2-1バックアップとは？データを失わないための最小設計を先に参照してください。
バックアップがあっても復元に失敗した企業が85%：データが示す現実
富士ソフトのTech Tips（警察庁「令和7年上半期」二次引用）によると、ランサムウェア被害を受けた企業のうち：
- バックアップから復元できなかった：85.4%
- 復元失敗の最大理由（バックアップも暗号化された）：65%
- 復旧費用が1,000万円以上かかった：59%
NTT Security Japanの解説記事（同統計引用）では、復元失敗の最大原因がネットワーク経由でのバックアップデータごとの暗号化であることが示されています。常時接続・バックアップサーバーの脆弱性・SaaSの誤解が3大原因として挙げられています。
Arcserve Japanが2025年12月に実施した「ランサムウェア攻撃に関する意識と実態調査」（情報システム担当者・経営層500人対象）では、さらに詳細な実態が報告されています（出典：ZDNET Japan、IT Leaders）。
- 被害企業でバックアップデータまで暗号化された：89%
- 数時間以内に復旧できた：22%のみ
- 復旧に1週間以上かかった：32%
- 復旧費用が1,000万円以上かかった：47%
- イミュータブルバックアップを現在利用している：10%のみ
- イミュータブルバックアップを「重要」と評価：60%
知っているが実装できていない——60%と10%のギャップが、設計変更の出発点です。
なお、DataClasysの解説記事（警察庁2025年統計引用）では、令和7年のランサムウェア被害報告件数が226件（ノーウェアランサム17件を含めると243件）に達し、中小企業が全体の60%以上を占めることも示されています。VPN機器経由の侵入が全体の6割以上という数値は、後述する構造的理由と直結しています。
3-2-1が機能しない3つの構造的理由
3-2-1ルールはもともと、ハードウェア障害・人的ミス・拠点災害を想定した設計枠組みです。ランサムウェアの脅威モデルは異なります。侵害されたネットワーク内を横展開し、バックアップを先に無効化してから暗号化ペイロードを展開するというシーケンスが一般的です。この脅威モデルのズレが、3-2-1を機能不全にする3つの原因を生みます。
①本番環境と同じAD認証情報でバックアップを管理している
CIT Solutionsの解説によると、「同一のActive Directoryクレデンシャルでバックアップシステムにアクセスできる環境では、攻撃者は本番環境とバックアップを同時に侵害できる」と指摘されています。
攻撃のシーケンスは概ね次のようになります。
- VPN機器や境界デバイスの既知の脆弱性から侵入する
- Active Directoryで管理者権限を横展開で取得する
- バックアップ管理コンソールに同一のAD認証情報でアクセスする
- 暗号化ペイロードを展開する前に、バックアップを削除または暗号化する
本番と同じ認証基盤でバックアップ管理コンソールを保護している場合、ステップ2の時点でバックアップへのアクセス権も失われます。バックアップ専用の認証情報を本番ADから切り離して管理することが、最初の対処方向です。
②オフサイトバックアップがVPN経由でネットワークに常時接続している
「物理的に離れた場所にある」だけでは、ランサムウェアに対するエアギャップにはなりません。
NTT Security Japanは、VPNなどで社内ネットワークと繋がっている状態は感染経路となり得ることを明示しています。本番データから遠隔地のバックアップまで、ネットワーク経由で一網打尽に暗号化されるリスクがあります。
Object Firstの2026 World Backup Day調査でも、79%のITリーダーが「攻撃者によるバックアップへのアクセス」を最大の懸念として挙げています。攻撃者は数週間かけて環境をマッピングし、すべてのバックアップ場所を特定してから暗号化を実行するパターンが報告されています。
3-2-1ルールは「保存場所の分散」を担保しますが、「ネットワーク接続を切る」ことは設計前提に含まれていません。常時接続されたオフサイトコピーは、攻撃者から見れば「離れた場所にあるが到達可能なターゲット」です。
③復元テストを一度も実施していない
バックアップジョブが「成功」を返しても、それは「データが書き込まれた」ことを示すだけです。「業務再開まで含めて復元できる」ことを保証するものではありません。
Veeam Communityの実装ガイドでは、「一度もテストしていないバックアップは、ディスクに保存された希望に過ぎない」と表現されています。
NTT Security Japanも同様の観点を示しており、従来型のバックアップ管理は「バックアップジョブが成功したか」までしか確認しておらず、「実際にシステムとして起動し業務再開できるか」まで定期的に検証している組織は少ないと指摘しています。
ランサムウェアは侵入後、数週間潜伏してから発動するケースがあります。感染した状態のスナップショットしか残っていない場合、感染前の正常な時点への復元が実質不可能になります。どの時点のスナップショットが感染前かを確認できる体制と、その時点から業務再開まで実際に通せるかの定期確認が必要です。
3-2-1から3-2-1-1-0へ：追加された2つのルールの意味
Veeamの公式ブログは、上記3つの弱点に対応するために3-2-1ルールを拡張した3-2-1-1-0ルールを提唱しています。
| 数字 | 意味 |
|---|---|
| 3 | データコピーを3つ（本番1＋バックアップ2） |
| 2 | 2種類の異なるメディアに保存 |
| 1 | 1つはオフサイト |
| +1 | 1つはイミュータブルまたはエアギャップ |
| +0 | 復元エラーゼロ（定期テストで確認） |
+1（イミュータブル/エアギャップ）が追加された背景は、ネットワーク接続されたコピーだけでは侵害される現実に対応するためです。Veeamは「現代の環境では、イミュータブルまたはエアギャップのコピーが不可欠」と明示しており、ランサムウェアがバックアップをますます標的にしているという状況への直接的な回答です。
+0（復元エラーゼロ）が追加された背景は、バックアップの完成形は「取得完了」ではなく「復元成功」であるという原則を設計に組み込むためです。定期的な復元テストによってゼロエラーを担保することが、このルールの要件です。
Arcserve調査でイミュータブルバックアップを利用している組織が10%にとどまる一方で、重要と評価する組織が60%に達していたことを踏まえると、3-2-1-1-0への移行は「知っているが実装できていない」ギャップを埋める作業といえます。
イミュータブルバックアップの実装オプション比較
「イミュータブル（変更不可）バックアップ」とは、書き込み後の一定期間、管理者権限を持つユーザーも含め上書きも削除もできない状態でデータを保持する方式です。攻撃者がAD認証情報を奪っても、保持期間中はバックアップを消去できません。
実装の選択肢は主に3つあります。
選択肢A：AWS S3 Object Lock（クラウド環境向け）
AWS公式ドキュメントが定義するS3 Object Lockは、WORM（Write Once, Read Many）モデルでオブジェクトを保護します。S3バージョニングを有効化したうえで利用します。
モードは2種類あります。
- Complianceモード：AWSのrootユーザーを含め、保持期間中はいかなるユーザーもオブジェクトを上書き・削除できません。保持期間前に削除するには、当該AWSアカウントそのものを削除する必要があります。運用ミスの修正が不可能なため、本番適用前に設計と運用ルールの確定が必須です。
- Governanceモード：特別な権限を持つユーザーであれば削除が可能です。段階的な導入やテスト環境への適用に向いています。
保持期間については、Veeam Communityの実装ガイドが「7日間では短すぎる」と明示しています。ランサムウェアは数週間潜伏してから発動することがあるため、7日間に設定した場合、保持期間内のスナップショットすべてが感染済みになるリスクがあります。最低14〜30日以上が推奨されています。
料金は容量・操作数・リージョンによって変動するため、Amazon S3料金ページを参照してください。
選択肢B：Hardened Linux Repository（オンプレ環境・Veeam利用者向け）
Veeamの公式ブログが紹介するHardened Linux Repositoryは、LinuxのXFSファイルシステムの不変フラグを活用してバックアップデータをイミュータブルに保持する方式です。
管理者アカウントが侵害された場合でも、保持期間中はバックアップの削除・上書きができません。既存のVeeam環境がある組織では、追加のクラウドコストを発生させずにイミュータブルバックアップを構成できる最小コストの選択肢です。
Veeamにはバックアップの復元テストを自動化するSureBackup機能があり、サンドボックスネットワーク上で仮想マシンを実際に起動して業務継続性を確認できます。3-2-1-1-0の「+0」要件を組織的に担保しやすいアプローチです。
選択肢C：テープ（物理エアギャップ）
テープはカートリッジを排出して物理的に保管することで、ネットワーク接触がゼロになります。ソフトウェア的なイミュータビリティではなく、物理的なエアギャップを実現できる唯一の選択肢です。
CISA（米国サイバーセキュリティ・インフラセキュリティ庁）は「オフラインで暗号化されたバックアップの管理が重要なリスク軽減策になる」としています（Veeam公式ブログが言及しているCISAの推奨。一次ソースとの直接照合は未実施のため、二次引用として扱います）。
制約もあります。テープドライブ設備への初期投資が必要で、復元時間（RTO）もクラウド・オンプレ方式と比べて長くなります。大規模データの長期保存、規制対応が求められる環境に適しています。
3選択肢の比較
| S3 Object Lock | Hardened Linux | テープ | |
|---|---|---|---|
| エアギャップ | ソフト（ネットワーク経由） | ソフト（ネットワーク経由） | 物理（完全） |
| 実装コスト目安 | 低〜中 | 中 | 高 |
| RTO | 短 | 短〜中 | 長 |
| 向いている環境 | クラウド中心・S3利用中 | 既存Veeam環境あり | 大規模・規制対応 |
各選択肢の料金は変動します。費用の詳細は各公式サイトをご確認ください。
イミュータブルバックアップ導入前に確認すべき制約
イミュータブルバックアップは万能ではありません。設計・運用上の注意点を整理します。
Complianceモードの削除不可制約
AWS S3 Object LockのComplianceモードを適用すると、誤設定や不要になったテストデータも保持期間中は削除できません。Complianceモードで本番環境に適用する前に、Governanceモードで設計と運用ルールを十分に検証してから移行するアプローチが安全です。
イミュータビリティ期間の設定ミスリスク
Veeam Communityが推奨する「最低14〜30日以上」は、ランサムウェアの潜伏期間に対応するための設定です。7日間に設定した場合、発動前に2週間潜伏するランサムウェアに感染していると、保持期間内のスナップショットすべてが感染済みになる可能性があります。一方で保持期間を延ばすほどストレージコストは増加します。自社の許容RPO（目標復旧時点）とコストのバランスで期間を設計してください。
復元テスト体制の構築コスト
3-2-1-1-0の「+0」を実現するには、定期的な復元テストを運用に組み込む体制が必要です。実施日・担当者・確認観点をSOP（標準操作手順書）として文書化しておかないと、監査や経営報告の証跡になりません。テストの自動化（Veeam SureBackup等）を活用する場合でも、テスト結果を記録・保管する仕組みは別途用意する必要があります。
SaaS・クラウドデータの誤解
Microsoft 365やGoogle WorkspaceなどのSaaSに保管されているデータは「クラウドにあるから安全」ではありません。ランサムウェアに感染した端末からSaaSへのアクセス権が奪われた場合、クラウド上のデータが連動して暗号化・削除されるケースがあります（NTT Security Japan参照）。SaaSのデータについても、3-2-1-1-0の設計対象に含める必要があります。
IPA中小企業の情報セキュリティ対策ガイドライン第4.0版との接点
IPAは2026年3月27日、「中小企業の情報セキュリティ対策ガイドライン」を第4.0版に改訂し、従来の「情報セキュリティ5か条」に「バックアップを取ろう！」を追加して情報セキュリティ6か条としました。
IPAが公式の改訂背景として示しているのは、「ランサムウェアによる被害が情報漏えいにとどまらず企業の事業活動の停止にまで影響が拡大した」という状況です。バックアップの実装は任意の努力目標ではなく、中小企業が満たすべきセキュリティ基準の構成要素として位置づけられました。
第4.0版の詳細ページ（最終更新：2026年6月1日）では、「中小企業のためのセキュリティインシデント対応の手引き」「クラウドサービス安全利用の手引き」など8点の付録も提供されています。
バックアップ設計の再構築を経営層・監査委員会に説明する際、IPA第4.0版の改訂内容を外部根拠の一つとして活用できます。「国の機関が要件に追加した」という事実は、社内決裁の説得材料として機能します。
今日から着手できるバックアップ再設計チェックリスト
現在の設計を確認するための4点です。
- □ バックアップ管理コンソールへのアクセスが、本番AD認証情報とは別の認証情報で管理されているか
- □ オフサイトバックアップがネットワーク常時接続になっていないか（同期時のみ接続、またはエアギャップ）
- □ 直近6か月以内に、業務再開まで含めた復元テストを実施済みか
- □ イミュータビリティ期間が14日以上に設定されているか
1つでもNoがある場合、そのポイントが攻撃者にとっての侵入・破壊経路となる可能性があります。