ブログに戻る
2026年7月14日13 分で読了

Fibonacci Rule of Backup Security:現代のバックアップセキュリティに向けた3-2-1-1-0の拡張

3-2-1-1-0が今も堅実な運用上のベースラインである理由と、現代のバックアップセキュリティにそれを取り巻くアーキテクチャのレイヤーが必要な理由。

著者: BackupSec Team

Fibonacci Rule of Backup Security:現代のバックアップセキュリティに向けた3-2-1-1-0の拡張

成熟したバックアップ戦略が2026年に破綻しつつある理由

3-2-1バックアップルールは長年にわたり、データ保護の基盤であり続けてきました。写真家のPeter Krogh氏は、『The DAM Book』の初版を執筆していたときにこの用語を自ら考案したと語っており、ASMPのdpBestflowプロジェクト向けに同氏が書いたバックアップガイドにもその内容が示されています。重要なファイルはすべて3つのコピーを持ち、2種類の異なるメディアに保存し、1つのコピーをオフサイトに置く、というものです。この公式は写真の世界をはるかに越えて広まりました。データバックアップの選択肢に関するCISAの論文も、個人データと業務データの両方についてこのルールを紹介しています。

このルールは機能していました。機能しなくなるまでは。

Verizonの2025 Data Breach Investigations Reportは、調査対象となった侵害の44%でランサムウェアを確認しており、前版の32%から増加しています。この版は2023年11月から2024年10月までのインシデントを対象としています。2024年11月から2025年10月までを対象とした2026年版では、この割合は48%です。ランサムウェアグループが公開した被害者を追跡しているGuidePoint Securityの調査チームは、2025年にランサムウェアの被害者数が前年比58%増加したと記録しており、同チームが追跡を始めて以来最も活発な年となりました。企業のリスク管理責任者にとってさらに重大なのは次の点です。Mandiantの2025年のインシデント対応案件全体で、Google Threat Intelligence Groupはランサムウェアによる侵入の約77%でデータ窃取を確認、またはその疑いを把握しており、2024年の約57%から増加しています。データがすでに盗まれている場合、完璧なリストアでシステムは元に戻っても、侵害そのものは解決しません。

3-2-1ルールは、ハードウェア障害、広域障害、誤削除を想定して設計されました。バックアップリポジトリを狙い撃ちする脅威アクターや、有効な管理者認証情報を持つ内部者を想定したものではありません。攻撃者は、バックアップを破壊すれば被害者から身代金の支払い以外の選択肢を奪えることを知っています。同じGoogleのレポートは、ランサムウェアの攻撃者が「often disabled or deleted backups to inhibit and/or limit recovery options」(訳:復旧手段を妨げる、または制限するために、しばしばバックアップを無効化または削除した)と指摘しています。

これが、このルールが拡張されてきた理由です。Veeamは自社による拡張である3-2-1-1-0を、イミュータブルなコピー1つとリカバリエラーゼロを追加したものと説明しています。BackupSecでは、さらに一歩進めることを提案しています。私たちはそれをFibonacci Rule of Backup Securityと呼び、5-3-2-1-1-0と表記します。これは当社独自のフレームワークであり、業界標準ではありません。フィボナッチ数列を逆から読んだような並びで、6つ目の要素を加えています。その下にあるすべてのレイヤーを支えなければならない5つの基本的なセキュリティ原則です。

成熟したバックアップ環境を運用している組織に向けて、本記事では2026年における「包括的なデータ保護」が何を意味すべきかを捉え直します。

3-2-1から3-2-1-1-0へ:簡単なおさらい

Fibonacci Ruleを紹介する前に、ここに至るまでの経緯を確認しておきましょう。

当初の3-2-1ルールは、データのコピーを3つ持ち、2種類の異なるメディアに保存し、そのうち1つをオフサイトに置くことを求めていました。焦点は冗長性にあり、単一の物理的事象で3つのコピーすべてが同時に破壊されることはないという前提に立っていました。

3-2-1-1-0ルールは、元のルールをVeeamが拡張したもので、現在では広く使われています。2つの改良が加えられました。

  • 攻撃者が管理者認証情報を持っていても変更・削除できない、イミュータブルまたはエアギャップされたコピーを1つ。
  • バックアップ検証におけるエラーゼロ。すべてのバックアップが単に存在するだけでなく、リストア可能であることがわかっている状態にします。

この進化によって、2つの重大なギャップが埋まりました。バックアップを狙うランサムウェアと、災害が起きるまで一度もテストされないバックアップのサイレントな失敗です。しかし、このルールはそれらのコピーを取り巻くセキュリティアーキテクチャ全体、つまりアイデンティティの分離、特権アクセス、セグメンテーション、継続的な監視、影響範囲の封じ込めを定義しようとはしていません。

Fibonacci Rule of Backup Securityは、このギャップを埋めるために設計されています。

なぜフィボナッチなのか:数字の背後にある論理

フィボナッチ数列(0, 1, 1, 2, 3, 5, 8, 13...)は、数学で最も美しいパターンの1つです。各数字は、その前の2つの数字の和になっています。当社のフレームワークを逆から読むと(5, 3, 2, 1, 1, 0)、同じ積み重ねの論理が当てはまります。保護の各レイヤーが、その下にある土台の上に築かれているのです。

  • 5つの基本的なセキュリティ原則。 バックアップをどのように設計するかを規定する5つの原則です。
  • 3つのデータコピー。 すべての重要なデータセットについて、少なくとも3つのコピーを持ちます。
  • 2種類の異なるメディア、またはストレージ/プラットフォーム。 2種類の異なるメディア、ストレージプラットフォーム、または技術スタックに保存します。
  • 1つのオフサイトコピー。 地理的に離れた場所に1つのコピーを置きます。
  • イミュータブル、隔離、またはその他の方法で保護された追加のコピー1つ。 変更や破壊から保護されたコピーをさらに1つ持ちます。
  • 未検証のバックアップ、未解決のリカバリエラーが0。 未検証のまま残るバックアップも、未解決のまま残るリカバリエラーもありません。

元の3-2-1-1-0ルールは、「コピーをいくつ、どこに、どのような状態で持つか」という運用上の問いに答えるものでした。私たちが加えた「5」は、より根本的なアーキテクチャ上の問いに答えます。「バックアップが安全であるとは、実際には何を意味するのか」という問いです。

この5つの原則がなければ、残りの連鎖は中身のないものになります。3つのコピーがあり、2種類のメディアに保存され、イミュータブルな状態にあっても、アクセス制御が不十分だったり、侵害された管理者用ワークステーションから到達できたりするバックアップは、保護されているとはいえません。それは、露出している状態を記録した文書にすぎません。

「5」:バックアップセキュリティの5つの基本原則

この5つの原則は、プラットフォームの選定から保持ポリシー、アクセスガバナンスに至るまで、バックアップ環境におけるすべてのアーキテクチャ上の判断の拠り所となるべきものです。

1. 設計段階からのサイバーレジリエントなアーキテクチャ

バックアップのセキュリティは後付けできません。初日から設計上の制約として組み込まなければなりません。

サイバーレジリエントなバックアップアーキテクチャは、すべてのコンポーネント(カタログ、ストレージ層、管理プレーン、リカバリ環境)を潜在的な標的として扱います。侵害を前提とし、侵害に備えて計画を立て、技術的、人的、敵対的のいずれであっても、単一の障害が連鎖して復旧能力の完全な喪失につながることがないようにします。

実際には、次のことを意味します。

  • 多層防御:各レイヤーを複数の独立した統制で守り、1つが破られてもシステムが露出しないようにします。
  • 影響範囲の封じ込め:本番環境の侵害がバックアップ基盤に波及せず、1つのバックアップ層の侵害が他の層に波及しないようにします。
  • リカバリ優先の設計:アーキテクチャを、データをどれだけうまくバックアップできるかだけでなく、敵対的な状況下、つまりDNSが停止している、IDプロバイダーが侵害されている、プライマリサイトに到達できないといった状況で、どれだけ確実にリストアできるかで評価します。
  • 暗号化を機能ではなく、アーキテクチャの基本要素として扱う:すべてのバックアップは、どの状態においても、保存時と転送時の両方で強力な業界標準の暗号化によって保護されなければなりません。暗号鍵は可能な限りバックアップ基盤から独立して管理し、理想的には専用のHSM、または管理権限の所有者が別になっている鍵管理サービスで管理します。鍵がデータと同じ場所にあるなら、それは暗号化ではなく難読化にすぎません。国境を越えたデータの流れがある企業にとって、鍵の主権(誰が、どの法域で、どのような期限で開示を強制できるか)は、インシデント対応の問題ではなく設計上の判断事項になります。

古い脅威環境向けに設計されたバックアップシステムに後からセキュリティを付け足すと、インシデントの最中にその欠陥が露呈しがちで、そのときにはアーキテクチャそのものが弱点だったことが判明します。レジリエンスは設計に組み込まなければなりません。

2. ゼロトラストアクセスと強力な認証

原則はシンプルです。決して信頼せず、常に検証する(never trust, always verify)。バックアップの読み取り、書き込み、変更に関するすべての要求は、ネットワーク上の発信元にかかわらず、要求の時点で認証・認可されなければなりません。

具体的には、次のことが必要です。

  • バックアップ基盤に触れるすべての管理者IDに対する多要素認証(MFA)。理想的には、ハードウェアトークンのようなフィッシング耐性のある方式を使います。
  • 細かな単位で最小権限の原則を徹底するロールベースアクセス制御(RBAC)。
  • 本番システムとバックアップシステムで別々の管理者IDを使うこと。侵害されたドメイン管理者が、最後の防衛線にアクセスできてはなりません。
  • 保持ポリシーの変更などの機密性の高い操作に対して、ジャストインタイムの権限昇格、セッション記録、承認ワークフローを備えた特権アクセス管理(PAM)。

ランサムウェアの被害を受けた3,400組織を対象としたSophosのState of Ransomware 2025調査では、被害者は攻撃の23%で侵害された認証情報を根本原因として挙げており、悪用された脆弱性(32%)に次いで2番目に多い技術的な根本原因でした。バックアップ環境が本番環境を守るのと同じアイデンティティ基盤を信頼しているなら、それは多層防御の体裁をとった単一障害点です。

3. イミュータビリティとWORMストレージ

イミュータビリティ、つまり一度書き込まれたデータが定められた保持期間中は変更も削除もできないという特性は、「ベストプラクティス」から「譲れない要件」へと変わりました。クラウドストレージのObject Lock、WORM(Write Once Read Many)メディア、ハードウェアで強制される保持ロックのいずれで実装するにせよ、イミュータビリティは、バックアップリポジトリを狙い撃ちする脅威アクターに対する最も効果的なアーキテクチャ上の防御策の1つです。

記録保存に関する規則の対象となる企業にとっては、イミュータビリティがコンプライアンスの助けになることもあります。SEC Rule 17a-4は、ブローカー・ディーラーが電子記録を、タイムスタンプ付きの完全な監査証跡とともに保存するか、「in a non-rewriteable, non-erasable format」(訳:書き換え不能かつ消去不能な形式で)保存することを認めています。HIPAA Security Ruleは、電子的な保護対象医療情報の「retrievable exact copies」(訳:取り出し可能な正確なコピー)を作成・維持するデータバックアップ計画を求めています。ランサムウェアからあなたを守る統制の領域は、多くの場合、監査人が確認を求める領域と同じです。

CISAは多くのベンダーよりも慎重です。同庁の#StopRansomware Guideは、組織に「maintain offline, encrypted backups of critical data」(訳:重要データのオフラインかつ暗号化されたバックアップを維持する)よう求め、その可用性と完全性を定期的にテストするよう求めています。クラウドベンダーのイミュータブルストレージについては、警告を添えたうえでしか言及していません。それは「does not meet compliance criteria for certain regulations」(訳:特定の規制のコンプライアンス基準を満たさない)ものであり、設定ミスによって多大なコストが生じる可能性があるというものです。イミュータビリティは、すでに管理者認証情報を持っている攻撃者からバックアップを無傷に保ちます。しかし、オフラインコピーやテスト済みのリストアの代わりにはなりません。

4. 継続的な検証とリカバリテスト

テストしていないバックアップはバックアップではありません。仮説です。

3-2-1-1-0の「0」はエラーゼロを求めますが、その主張を裏付ける唯一の方法は継続的にテストすることです。成熟したプログラムでは、自動化された完全性チェック、定期的なフルリストア訓練、検証用の隔離されたリカバリ環境、そして技術面と同じくらい厳密に人とプロセスのレイヤーを検証する構造化された机上演習を実施しています。

リカバリは速くなっています。同じSophosの調査では、ランサムウェアの被害者の53%が1週間以内に完全に復旧しており、2024年の35%から増加しました。また、97%が3か月以内に完全に復旧していました。Sophosは、この改善はインシデントへの備えとリカバリ態勢への投資を反映している可能性があると示唆しています。調査はテスト済みの計画の効果だけを切り出してはいませんが、Sophos自身の助言は、質の高いバックアップを取り、そこからのリストアを定期的に練習することです。

リスク管理責任者への教訓はこうです。テストこそが、バックアップを持っている組織と、復旧できる組織とを分けるものです。

5. 隔離とネットワークセグメンテーション

バックアップ基盤は本番環境から強固にセグメント化されるべきであり、可能な限り、本番システムを守っているのと同じ管理上の信頼境界に依存すべきではありません。

現代のベストプラクティスは、論理的なセグメンテーション(個別のVLAN、専用サブネット、厳格なファイアウォールルール、マイクロセグメンテーション)と、すべてのバックアップの少なくとも1つのコピーに対するエアギャップまたは準エアギャップのアーキテクチャを組み合わせます。別のIDプロバイダーを使うクラウドのイミュータビリティ、オフラインのテープローテーション、専用のリカバリ環境、共有インフラにおけるテナント分離は、いずれも同じアーキテクチャ上の目標に役立ちます。単一の侵害の影響範囲が、リカバリのレイヤーにまで及ばないようにすることです。

ドメインコントローラー上にいる脅威アクターが同じ認証情報でバックアップリポジトリに到達できるなら、そのバックアップは攻撃対象領域から切り離されたものではなく、その一部です。

「3-2-1」:今も重要な冗長性

5つの原則を土台としたうえで、従来の3-2-1のレイヤーは引き続き不可欠です。

  • すべての重要なデータセットについて3つのコピー:本番データに加えて、少なくとも2つのバックアップ。
  • 2種類の異なるメディアまたはストレージプラットフォーム:ローカルディスクとクラウド、あるいはオンプレミスのオブジェクトストレージと別のクラウドプロバイダーなどです。目的は、単一の技術的障害、ベンダー側の障害、あるいは1つの種類の攻撃によって、すべてのコピーが同時に失われないようにすることです。
  • 1つのオフサイトコピー:プライマリサイトから地理的に離し、理想的には異なる脅威ドメインに、そして必要に応じて異なる法域に置きます。

このルールが最初に定式化されてから変わったのは、その解釈です。同じプロバイダーの2つのクラウドリージョンは「2種類の異なるメディア」にはなりません。本番アレイの隣にあるSAN上のバックアップボリュームは、実質的に「オフサイト」とはいえません。現代の企業の脅威モデリングでは、各要件をより厳密に解釈することが求められます。

「1-1」:オフサイト、そしてイミュータブルまたはエアギャップ

2つの「1」は、異なる障害ドメインに対応しています。

1つ目は、1つのコピーをプライマリ環境から地理的に離れたオフサイトに保管することを求めます。これにより、サイト単位のインシデント、インフラ障害、物理的な災害によって、すべての復旧手段が一度に失われることを防ぎます。

2つ目は、少なくとももう1つのコピーを、イミュータビリティ、エアギャップ、またはそれと同等の隔離の仕組みによって変更や破壊から保護することを求めます。その目的は異なります。オフサイトの分離は拠点の障害から守り、イミュータビリティや隔離は管理者アクセス権を手に入れた攻撃者から守ります。

実装上、これらの要件は重なることがあります。オフサイトのコピーがイミュータブルであってもかまいませんし、成熟した環境ではイミュータブルなリカバリ層と、さらに奥にあるオフラインまたはエアギャップされたコピーの両方を維持している場合もあります。重要なのは、地理的な分離だけをセキュリティ上の隔離とみなさないことです。

この区別は、イミュータビリティがFibonacci Ruleの5つのセキュリティ原則の1つに含まれている理由でもあります。数字の「1」はバックアップコピーの最低限の保護要件を定めるものです。一方、セキュリティ原則としてのイミュータビリティは、保持の制御、管理者アクセス、アイデンティティの分離、管理プレーンを含め、アーキテクチャ全体を通じてイミュータビリティを考慮することを求めます。

「0」:未検証のバックアップを一切許さない

すべてのバックアップを検証する。すべてのリストアをテストする。すべてのギャップを記録し、解消する。

「0」はこのフレームワークにおける運用規律のレイヤーです。求められるのは厳密さです。自動化されたチェックサム、計画的なリストア検証、バックアップジョブのメタデータに対する異常検知(ジョブのサイズが急に増えた場合、脅威アクターが暗号化の前段階の準備をしている兆候である可能性があります)、バックアップの管理操作に対する振る舞い監視、そして検証が失敗したときの明確なエスカレーション経路です。

理由はシンプルです。バックアップを破壊しようとする攻撃者は、まずバックアップシステムに手を触れなければなりません。そしてその変更は、リストアが失敗するよりも前に、ジョブ設定、保持の値、監査ログに表れます。エラーゼロは見栄えのための指標ではありません。その違いが最も重要になる瞬間に、確かな自信と誤った自信を分けるものです。

企業のリスク管理責任者にとっての意味

組織が異なる脅威環境向けに設計されたバックアップ戦略で運用しているのであれば、今あるものと必要なものとのギャップは、もはや机上の話ではありません。財務上の現実を考えてみてください。

  • Sophosの2025年の調査では、身代金の支払額の中央値は100万ドル、リカバリにかかる平均コスト(身代金を除く)は153万ドルでした。
  • Verizonの2025 DBIRによると、ランサムウェアの被害組織の64%が身代金を支払わず、2年前の50%から増加しています。別のサンプルを調査したSophosでは、被害者の49%がデータを取り戻すために身代金を支払っていました。いずれにせよ、支払いはもはやデフォルトではなく、支払いを拒否する組織には機能するリストア経路が必要です。

規制業種の企業や、複雑なハイブリッド環境を管理する企業にとって、この計算はさらに切実です。米国の上場企業は、重大なサイバーセキュリティインシデントをForm 8-Kで開示しなければならず、原則として重大であると判断してから4営業日以内に行う必要があります。他の多くの法域や業種でも、それぞれ独自の報告義務が課されています。復旧できないインシデントのコストは、もはや業務上のものだけではありません。評判と規制の面にも及びます。

Fibonacci Ruleの実装に、インフラをゼロから作り直す必要はありません。必要なのは、誠実なアーキテクチャ評価、明確な原則に基づいて優先順位を付けた改善、そしてバックアップのセキュリティを調達上の一項目ではなく統合された分野として扱うというガバナンス上のコミットメントです。

BackupSecの役割

BackupSecは、Veeamのバックアップ環境を上記の原則に沿って運用できるよう、チームを支援しています。バックアッププラットフォームを置き換えるのではなく、そのセキュリティを可視化し、助言し、テストします。

  • ZeroMON はVeeam Backup & Replicationを監視します。ジョブの健全性、誰が/何を/いつ変更したかの記録を伴う構成変更、Security Analyzerのチェックリスト、レポート、そしてハニーポットを提供します。イミュータビリティのステータスはVeeamのリポジトリ設定が報告するとおりに表示し、ストレージ上のオブジェクトレベルのロックを検証することはありません。アラートはメールとアプリ内通知で送られます。OVAとしてオンプレミスに展開し、読み取り専用アカウントで接続し、BackupSecにも第三者にも何も送信しません。
  • ZeroTAM は、アーキテクチャ、キャパシティ、ランサムウェアからのリカバリ計画、そして優先的な危機対応サポートのために、専任のバックアップセキュリティアドバイザーを提供します。
  • ZeroPEN は、Veeam Backup & Replication、Veeam ONE、Enterprise Managerを対象とした脅威主導型のペネトレーションテストで、MITRE ATT&CKにマッピングされた8つのキルチェーンステージで構成されます。エンゲージメントにはリストアの完全性とイミュータビリティの検証も含まれます。実際のバックアップを削除することも、実際の暗号化を行うことも、本番サービスやバックアップサービスを停止することもありません。監査対応可能なエビデンスと、重大な指摘事項の再テストが提供されます。
  • ZeroVault は、オフサイトのイミュータブルなコピーのための、Object Lockを備えたS3互換のイミュータブルなクラウドオブジェクトストレージです。

バックアップのセキュリティ態勢についてBackupSecに相談する →

出典 · 17

Verizon · CISA · GovInfo · GuidePoint Security · Google Cloud · +6

よくある質問

Fibonacci Rule of Backup Securityは業界標準ですか?

いいえ。写真家Peter Krogh氏に由来するとされる3-2-1ルールと、Veeamによる拡張である3-2-1-1-0は、広く使われている慣行です。Fibonacci Rule of Backup Security(5-3-2-1-1-0)はBackupSec独自の提案であり、それらのルールをアーキテクチャの面から拡張し、バックアップ環境がレジリエントであるとみなされるために満たすべき5つのセキュリティ原則を示すものです。標準化団体に採用されたものではありません。

企業のバックアップはどのくらいの頻度でテストすべきですか?

義務付けられた単一の間隔はありません。当社の推奨は次のとおりです。自動化されたチェックによってバックアップの完全性を継続的に検証し、ティア1のシステムについては少なくとも四半期に1回フルリストア訓練を行い、人とプロセスのレイヤーを含む完全な災害復旧演習を少なくとも年に1回実施します。規制の厳しい業種の組織では、規制当局や監査人の要求に応じて、より頻繁な検証が必要になる場合があります。

イミュータビリティとエアギャップの違いは何ですか?

イミュータビリティは、ソフトウェアまたはハードウェアによって強制される特性で、定められた保持期間中はデータを変更も削除もできません。エアギャップは物理的または論理的な分離で、バックアップが本番ネットワークからまったく到達できない状態です。どちらもランサムウェアから守るものであり、最も強固な企業アーキテクチャでは、多くの場合、両者を階層的に組み合わせて使用しています。

このフレームワークは規制要件とどのように関係しますか?

Fibonacci Ruleのいくつかの原則、特にイミュータビリティ、暗号化、アクセスガバナンス、検証は、各種規則の統制目標に関係しています。たとえば、ブローカー・ディーラーの記録を書き換え不能かつ消去不能な形式で、または完全な監査証跡とともに保存することを認めるSEC Rule 17a-4や、データバックアップ計画を求めるHIPAA Security Ruleです。このフレームワークを実装することで組織のコンプライアンス態勢を強化できますが、それだけでいずれかの規制制度への準拠が確立されるわけではありません。