イミュータブルストレージ（WORM）

1. 概要

イミュータブルストレージ（Immutable Storage）とは、データが一度書き込まれると、指定された保存期間（retention period）の間はその内容を変更・削除・上書きできないようストレージ層自体が強制する保存方式であり、一度書いて何度も読むというWORM（Write Once, Read Many）原理をソフトウェア・ハードウェアで実装したものである。核心は「権限を持つ管理者であっても、最上位のルートアカウントであっても、期間内はデータを変えられない」という点にある。

イミュータブルストレージが前面に出てきた背景にはランサムウェアの進化がある。初期のランサムウェアは運用データだけを暗号化したため、バックアップから復旧すれば身代金を払わずに済んだ。そこで攻撃者は戦略を変え、バックアップそのものを先に探して暗号化・削除し始め、バックアップカタログ・スナップショット・クラウドバケットまでが標的となった。すなわち「復旧手段をなくしたうえで身代金を要求する」方式へと進化したのである。このときバックアップが運用データと同じ資格情報・同じ管理プレーン（control plane）に結び付いていると、管理者アカウント一つが奪取された瞬間に運用本体とバックアップ本体がともに消える。イミュータブルストレージはまさにこの点を狙う——データを「消せないように」して、最後の復旧保証（last line of recovery）を打ち立てるのである。

この転換の深刻さは被害統計に表れている。多くの侵害事故調査で、ランサムウェア攻撃者が復旧を挫折させるためにバックアップを優先的に標的とした割合が非常に高く報告されており、バックアップまで暗号化・削除された組織はそうでない組織より身代金を支払う確率が著しく高くなる（具体的な数値は調査主体・年度によって差が大きいため断定しない）。要点は明確である——復旧手段が攻撃者と同じ統制プレーンの中にあれば、バックアップは「保険」ではなく「もう一つの攻撃対象」となる。イミュータブルストレージはこの復旧手段を攻撃者の手が届かない場所へ移す。

二つ目の背景は規制・法的な保存義務である。金融取引記録、医療画像、電子税金計算書、アクセスログ、公共記録物などは、法が定めた期間の間原本のまま保存し、必要時に証拠として提出できなければならない。記録が事後に改ざんされうるなら、証拠能力（evidentiary value）を認められにくい。従来この要求はテープ・光ディスクといった物理的WORM媒体で満たしてきたが、データ量が急増しストレージがクラウドへ移るにつれ、ソフトウェアベースのWORMがその座を代替しつつある。媒体の物性に依存していた不変性がポリシー・ソフトウェアで実装可能になったことで、適用範囲は金融・公共を越えて一般企業のバックアップ・ログ・アーカイブへ急速に拡散した。

したがってイミュータブルストレージは単なるバックアップ技術ではなく、「変更不可能性（immutability）」をストレージ層で保証する信頼の基盤であり、セキュリティ（ランサムウェア復元力）・コンプライアンス（規制保存）・フォレンジック（証拠保全）が交差する地点に位置する。

不変性がなぜストレージ「層」で保証されねばならないかは、信頼境界（trust boundary）の問題として理解できる。バックアップをアプリケーションやオペレーティングシステムの水準で「消すな」と統制すると、その上位ソフトウェアが掌握された瞬間に統制もともに崩れる。一方、不変性をストレージ自体が強制すれば、上位層がすべて汚染されても削除命令はストレージ境界で拒否される。これはセキュリティでいう「信頼をより低く狭い境界へ押し込む」原理と同じであり、イミュータブルストレージがランサムウェアの最後の防衛線として機能する根本理由である。

まとめると、イミュータブルストレージが答えようとする問いは一つである——「すべての運用統制が崩れた最悪の瞬間にも、組織が立ち戻れるクリーンで変更されていない一式のデータが必ず残っているようにするには、どう保存すべきか？」この問いに対するストレージ層の答えがすなわち不変性である。以下では、不変性を支える構成要素と作動原理、実装類型、そして技術士の観点からの適用戦略を順に見ていく。

2. 全体構造と構成要素

イミュータブルストレージは「書き込み経路は開けておきつつ、変更・削除経路を時間ロックで閉じる」という発想の上に立つ。全体構造は、データを生成する運用系、それをイミュータブルストレージへ移すデータ移動層、不変性を強制する保存・保護層、そしてこれを監査・証明するガバナンス層に分かれる。

flowchart TB
  subgraph PROD["運用層（Production）"]
    APP["業務アプリケーション"]
    DB[("運用DB・ファイル")]
  end
  subgraph MOVE["データ移動層"]
    BK["バックアップ・スナップショットエンジン"]
  end
  subgraph IMM["イミュータブル保存層（Immutable）"]
    OL["オブジェクトロック（Object Lock）"]
    RET["保存ポリシー（Retention）"]
    LH["リーガルホールド（Legal Hold）"]
    STORE[("WORMストレージ")]
  end
  subgraph GOV["ガバナンス・監査層"]
    AUD["監査ログ・完全性検証"]
    IAM["最小権限・職務分離（RBAC）"]
  end
  APP --> DB
  DB -->|"定期バックアップ"| BK
  BK -->|"書き込み（1回）"| STORE
  STORE --- OL
  OL --- RET
  OL --- LH
  IAM -.->|"アクセス統制"| BK
  IAM -.->|"管理プレーン分離"| IMM
  AUD -.->|"変更試行を記録"| IMM

A. 保存ポリシー（Retention Policy）は不変性の時間軸を定義する。各オブジェクト・ファイルに「いつまで変更・削除を禁止するか」を打ち込むもので、通常は期間を明示する保存期間方式と特定時点を指定する保存満了日（retain-until-date）方式がある。重要な設計原則は、保存期間は延長のみ可能で短縮は不可能だという点である。これを許せば攻撃者が期間を0に縮めて即座に削除できるからである。たとえば7年保存をかけた金融記録は、7年が過ぎる前にはいかなる経路でも削除要求が拒否される。

保存ポリシーを設計する際にしばしば見落とされる点がバージョン管理との結合である。オブジェクトストレージで不変性は通常「バージョンごと」に作動する。すなわち同じキーに新しいデータを書いても既存バージョンを上書きするのではなく新バージョンが追加され、既存バージョンは保存ポリシーに従ってそのままロックされ保全される。このおかげで、ランサムウェアがファイルを「暗号化して書き直しても」暗号化以前のバージョンが不変状態で残り復旧が可能になる。バージョン管理なしに単一オブジェクトだけをロックすると、かえって新規書き込みが塞がれ運用に支障をきたすため、不変性はバージョン管理＋保存ポリシーの組み合わせとして理解すべき正確である。

B. オブジェクトロック（Object Lock）は保存ポリシーを実際に強制するメカニズムである。ストレージシステムが削除・上書きAPI呼び出しを受けると、ポリシーを確認し期間内なら拒否（deny）する。核心はこの拒否がアプリケーションではなくストレージ層自体で起きるという点である。上位ソフトウェアがどれほど誤った命令を送っても、または奪取された資格情報で削除を試みても、ストレージが物理的に阻む。

この構造がバックアップソフトウェアの信頼仮定をどう変えるかに注目する必要がある。従来のバックアップは「バックアップサーバが健全である」という仮定の上でデータを保護したが、イミュータブルストレージはバックアップサーバとその資格情報までを不信（untrusted）の対象に置き、ストレージ境界で独立に削除を拒否する。バックアップソフトウェアが保存解除命令を送っても、ストレージがこれを受け入れないため、攻撃者がバックアップインフラを完全に掌握した状況でも過去の複製が保全される。まさにこの「上位を信じない設計」がイミュータブルストレージのセキュリティ的価値の核心である。

C. リーガルホールド（Legal Hold）は、保存期間とは別に、訴訟・捜査・監査などの事由で期間制限なくデータを凍結する装置である。保存期間が満了してもリーガルホールドがかかっていれば削除されず、ホールドを明示的に解除してはじめて再び削除が可能になる。保存が「定められた期間の自動ロック」なら、リーガルホールドは「事由に基づく手動ロック」であり、両者はOR条件で結合され、どちらか一つでもかかっていればデータは保全される。

リーガルホールドと保存期間の結合は実務で繊細な運用を要求する。たとえば保存期間3年をかけた記録に訴訟でリーガルホールドが追加されると、3年が過ぎてもホールドが解けるまで削除が保留される。逆にホールドだけあって保存期間がないデータは、ホールド解除の瞬間に削除可能になる。組織はこの二つの装置の優先順位と解除手続きをポリシーで明文化し、ホールドの設定・解除権限を法務・コンプライアンス組織に置いてIT運用と分離することで、濫用と誤りをともに防がねばならない。

D. ガバナンス・職務分離層は不変性の最も多い失敗地点を埋める。ストレージ自体がどれほど堅固でも、周辺の身元・権限統制が弱ければ設定を変えたりアカウントを奪取したりして回避できるからである。したがって、バックアップを生成するアカウントと保存ポリシーを設定するアカウントを分離し（職務分離、separation of duties）、イミュータブルストレージの管理プレーンを運用系と異なる資格情報体系で隔離し、すべての変更試行を監査ログに残すことが不変性設計の必須要素である。

3. 不変性強制の作動原理

イミュータブルストレージが「消せない」を保証する過程は、保存モード（mode）とリクエスト処理フローで理解できる。最も広く使われるオブジェクトストレージ（例：Amazon S3 Object Lock）モデルを基準に見ると、同じWORMでもガバナンスモード（Governance）とコンプライアンスモード（Compliance）はまったく異なる保証水準を提供する。

flowchart TB
  REQ["削除・上書きリクエスト"] --> Q1{"リーガルホールドあり?"}
  Q1 -->|"はい"| DENY["拒否（保全維持）"]
  Q1 -->|"いいえ"| Q2{"保存期間内?"}
  Q2 -->|"いいえ"| ALLOW["許可（削除可能）"]
  Q2 -->|"はい"| Q3{"保存モード?"}
  Q3 -->|"コンプライアンス"| DENY
  Q3 -->|"ガバナンス"| Q4{"特権（迂回権限）保有?"}
  Q4 -->|"はい"| ALLOW
  Q4 -->|"いいえ"| DENY

ガバナンスモードは一般ユーザーの削除・変更は阻むが、特別な迂回権限（例：s3:BypassGovernanceRetention）を持つ特権ユーザーは保存期間内でもデータを削除できるようにする。運用の柔軟性は高いが、まさにその特権アカウントが奪取されると不変性が無力化する。したがってガバナンスモードは「誤りによる削除防止」には十分でも、悪意ある攻撃者や内部者脅威に対する保証としては不完全である。

コンプライアンスモードは一歩進んで、誰も——ストレージを作ったルートアカウントであっても——保存期間内にはデータを削除・変更できない。設定を変える経路自体が封鎖されるため、管理者アカウント全体が奪取される最悪のシナリオでもデータが生き残る。代わりに一度期間を誤って設定すると元に戻せないため、期間算定とテストが非常に慎重でなければならない。規制対応とランサムウェア最後の防衛線にはコンプライアンスモードが定石である。

二つのモードの違いは単純なオプション選択ではなく、脅威モデル（threat model）の選択である。ガバナンスモードは「誤り・誤動作」を脅威と想定し、コンプライアンスモードは「管理者資格情報の完全な奪取と悪意ある内部者」までを脅威と想定する。ランサムウェアグループが侵入後に権限を昇格させてバックアップ設定を先に無力化するという実際の攻撃パターンを考慮すれば、最後の防衛線用の複製は必ずコンプライアンスモードでなければならないという結論が自然に導かれる。逆に開発・テスト用の一時保存のように元に戻す余地を残すべきデータはガバナンスモードが合理的である。すなわち一つの組織の中でも、データの役割に応じてモードを差等適用することが正しい設計である。

また不変性は「ルートアカウントであっても消せない」という強力さと「誤ってかければ元に戻せない」という危険を同時に内包する。コンプライアンスモードで10年保存を誤って設定すると、そのデータは10年間いかなる費用を払っても削除できない。したがって保存期間は法的要求＋安全余裕を越えないよう慎重に算定し、運用投入前に短い期間で十分に検証したうえで適用範囲を広げる段階的導入が推奨される。このように不変性は「強いほどよい」単純なスイッチではなく、保証強度と運用リスクの間で均衡点を見つけねばならない設計変数である。

ここにエアギャップ（air-gap）が結合されると保証がさらに一段高まる。エアギャップはバックアップ複製を運用ネットワークと物理・論理的に分離（テープを取り出して保管したり、ネットワークを平時は切っておく方式）し、攻撃者がそもそも到達できないようにする。不変性とエアギャップは相反する選択肢ではなく相互補完である。エアギャップは隔離を極大化するがバックアップ周期が長くなり復旧が遅く、イミュータブルオブジェクトストレージはオンラインで常時アクセス可能で復旧速度が速い。スナップショットベースの不変複製は攻撃直前の状態へファイルシステム・ボリューム全体を数分内にロールバックできる一方、テープ復旧は数時間〜数日かかる。したがって「速い復旧は不変ストレージで、最終隔離はエアギャップで」階層化するのが現代的な設計である。

4. 実装類型と比較

イミュータブルストレージは媒体・層によっていくつかの形態で実装され、それぞれ保証強度・費用・復旧速度のトレードオフが異なる。類型を「何で不変を強制するか」の観点で比較すると選択基準が明確になる。

類型	不変強制手段	復旧速度	費用	適合用途
ハードウェアWORM（光ディスク・テープ）	物理媒体特性	遅い（時間〜日）	媒体当たり安価、運用負担	長期規制保存、エアギャップ
ソフトウェアWORM（ファイルシステムロック）	OS・NAS保存属性	普通	中間	企業ファイルアーカイブ
オブジェクトストレージ Object Lock	ストレージAPI拒否	速い	容量課金	ランサムウェア復元、クラウドバックアップ
不変スナップショット	変更不可スナップショット＋保存	非常に速い（分）	ストレージ依存	運用系の迅速ロールバック

ハードウェアWORMは、そもそも媒体が物理的に再記録を許さないか（真のWORM光ディスク）一度だけ記録されるよう設計された方式で、証拠能力と長期保存の面で信頼が高いが容量拡張・検索・復旧が不便である。ソフトウェアWORMは一般ディスクの上に保存属性をソフトウェアで付与する方式で、NAS・エンタープライズファイルシステムが対応する。柔軟だが不変性の信頼はソフトウェア実装の堅固さに懸かっている。

二つの方式の信頼モデルの違いは実務で重要な含意を持つ。物理WORMは「媒体の性質」が不変を保証するため、ソフトウェアがどう動こうと過去の記録は保全される。一方、ソフトウェアWORMとオブジェクトロックは「コードと設定」が不変を保証するため、そのコードに欠陥があったり権限境界が緩かったりすれば不変性が壊れうる。とはいえ物理WORMが常に優れているわけではない。媒体の老朽・読取装置の製造中止・大容量非効率という弱点があり、数十PB規模の現代データには適さない。結局「何で不変を保証するか」の信頼モデルと運用の現実をともに秤にかけ、用途別に媒体を選ぶのが核心であり、長期規制保存は物理WORM・テープに、ランサムウェア迅速復旧はソフトウェアベースの不変スナップショット・オブジェクトロックに委ねる分担が典型である。

オブジェクトストレージ Object Lockは今日のクラウドバックアップの標準で、先に見たガバナンス・コンプライアンスモードで細かく制御される。不変スナップショットは運用ストレージが特定時点の状態を変更不可能なスナップショットとして固定しておき、攻撃発生時にその時点へ全ボリュームを即座に戻す方式で復旧速度が最も速い。実務ではこれらを混ぜて「運用系の不変スナップショット（分単位復旧）＋クラウドObject Lockバックアップ（遠隔復元）＋テープエアギャップ（最終隔離）」の多段構造で設計する場合が多い。

この多段構造がなぜ必要かは復旧目標指標で説明される。運用系の不変スナップショットはRPO（復旧時点目標）を数分〜数十分まで狭めRTO（復旧時間目標）を分単位に短縮するが、そのスナップショットが同じストレージアレイの中にあるため、アレイ全体が破壊されたり管理プレーンが掌握されたりすればともに危うくなる。そこで遠隔地のObject Lockバックアップが地理的・管理的隔離を加え、最終的にオフラインテープがネットワークで到達不可能な最後の複製を保証する。各層は復旧速度は遅くなるが隔離強度は高まる式で、「速いが近い複製」と「遅いが遠く安全な複製」をともに保有し、どんな攻撃シナリオでも最低一式は生き残らせる多層防御（defense in depth）構造である。

具体例として、1日1TBが変更される中堅金融会社が運用系に15分周期の不変スナップショットを72時間維持し、毎日1回クラウドObject Lockバケットにコンプライアンスモードで30日保存バックアップを上げ、週1回テープを外して社外金庫に7年保管するとしよう。ランサムウェアが運用系とバックアップカタログをすべて暗号化しても、攻撃者はコンプライアンスモードバケットとオフラインテープには手を出せない。対応チームは15分前の不変スナップショットでほとんどを即座に復旧し、スナップショットまで汚染された範囲はクラウドバックアップで埋め、規制対応用の長期記録はテープで証憑する。複製の「個数」ではなく複製の「不変性と隔離の多様性」が生存を決めるという点がこの設計の要諦である。

この選択を規律する実務原則がバックアップの3-2-1-1-0ルールである。伝統的な3-2-1（複製3個、媒体2種、社外1個）にランサムウェア時代の要求を加えたもので、加わった1は不変（またはエアギャップ）複製1個、0は復旧テスト誤り0件を意味する。複製をいくら増やしてもすべて変更可能なら一度に暗号化されうるため、「最低一式は不変」が復元力の核心条件となる。実際、多くのランサムウェア被害調査で攻撃者がバックアップを標的とした割合が非常に高く報告されるが、これは不変複製の有無が身代金支払いの可否を分ける決定的変数であることを示唆する。

一つのよくある誤解は「暗号化されたバックアップなら安全だ」という考えである。暗号化は機密性（confidentiality）を守るが不変性（integrity・availability）を与えはしない。暗号化されたバックアップも削除・上書きはいくらでも可能なため、ランサムウェアが暗号化されたバックアップファイル自体を消してしまえば復旧が不可能になる。逆に不変ストレージは内容を変えたり消したりできなくするだけで内容を隠しはしない。二つの性質は互いを代替できず、機微なバックアップは暗号化（機密性）＋不変性（変更防止）をともに適用してはじめて完全である。この区別を明確にしてこそ「バックアップを暗号化したから大丈夫」という誤った安心に陥らない。

5. 深化：規制動向と復元力アーキテクチャ

イミュータブルストレージは規制変化とともに急速に進化している。代表的に、米国証券取引委員会（SEC）のブローカー・ディーラー電子記録保存規定であるRule 17a-4が2022年10月に改正され2023年初めに発効した（遵守期限2023年5月）が、従来WORM保存のみを認めていた要件に、「完全な時点記録（time-stamped）監査証跡を通じて変更・削除された原本を再現できる電子記録システム」という二つ目の選択肢を追加した。すなわち不変性を「媒体水準の物理的WORM」だけで達成していた過去から、監査証跡ベースの論理的不変性も認める方向へ規制が柔軟になったのである。これは不変性の本質が「媒体が物理的に消せないこと」ではなく、「原本の完全性と再現可能性を保証すること」であることを規制が再確認した事例として読める。

国内（韓国）でも、電子金融監督規定・電子文書および電子取引基本法・個人情報保護法上のアクセス記録保存、公共記録物管理に関する法令などが事実上WORMに準じる保存・改ざん防止要件を要求する。たとえば個人情報アクセス記録は一定期間（機微・大量処理システムはより長く）保管し改ざんされないよう管理せねばならず、公共記録物は保存フォーマットと完全性検証（ハッシュ・電子署名）を通じて長期保存の信頼を確保する。このようにイミュータブルストレージは特定ベンダー機能ではなく、法的保存義務を技術で履行する共通手段である。

ただし不変性と個人情報削除権（忘れられる権利）が衝突しうる点は注意が必要である。保存期間を長くかけた不変ストレージに個人情報が含まれると、情報主体の削除要求や保有期間経過時の破棄義務と相反する。これを解消するため、個人情報は不変保存の対象から分離するか、復号鍵を廃棄して事実上アクセスを不能化する暗号消去（crypto-shredding）技法を併用する。すなわち不変性は無制限の美徳ではなく、プライバシー規制との均衡の中で適用範囲を精緻に設計すべき対象である。

規制のもう一つの流れは、クラウド責任共有モデルの中で不変性を誰が保証するかの問題である。クラウド事業者がObject Lockのような機能を提供しても、それを「コンプライアンスモードで、十分な期間で、管理プレーンを分離して」正しく構成するのは顧客の責任である。実際の事故の相当数は機能の不在ではなく誤構成（misconfiguration）——バケットをガバナンスモードで開けておいたり、保存ポリシーをかけなかったり、削除権限を過度に付与したことから生じる。したがってイミュータブルストレージ導入は機能の有効化にとどまらず、ポリシー・アズ・コード・構成点検・アクセス権限最小化まで包摂する運用ガバナンスで完成させねばならない。

復元力の観点で近年注目される概念は隔離復旧環境（isolated recovery environment）またはサイバー復旧金庫（cyber recovery vault）である。不変バックアップを平時は運用網と切っておいた別途の金庫に保管し、復旧時にはクリーンルーム（clean room）でバックアップ本体にマルウェアがないことを検証したうえで運用系へ戻す。単にデータを保存するにとどまらず、「汚染されていない状態で安全に蘇らせる」全過程を設計するのである。ここにバックアップデータに対する異常行為検知（大量変更・エントロピー急増の検知）を結合すれば、ランサムウェア感染時点を識別してその直前のクリーンな不変スナップショットへ精密復旧することが可能になる。

6. 考慮事項および示唆点

保証水準と運用柔軟性のトレードオフ：コンプライアンスモード・長い保存期間は最強の保証を与えるが元に戻せないため、誤って設定すれば不要なデータを長期間削除できず費用が雪だるま式に膨らむ。ガバナンスモードは柔軟だが特権奪取に脆弱である。データ重要度・規制要件・脅威モデルに応じて層別に異なるモードと期間を適用する差等戦略が必要である。
不変性の失敗はストレージではなく身元から来る：ストレージがどれほど堅固でも、保存ポリシーを設定・解除できる管理プレーンが運用系と同じ資格情報に結び付いていれば無力化する。管理プレーン隔離、職務分離、MFA、別途の信頼境界を必ず併行せねばならず、イミュータブルストレージはゼロトラスト・最小権限原則とともに設計されるべきである。
費用と保存ガバナンス：不変データは期間内の削除が不可能なため容量が単調増加する。保存期間算定、階層型ストレージ（hot→cold→archive）移動、満了自動削除ポリシー、重複排除・圧縮との組み合わせを通じて保存と費用の均衡を設計し、全社のデータ保存ガバナンスで管理せねばならない。
復旧可能性の定期検証（0の原則）：不変バックアップを保有することと実際に復旧できることは別である。バックアップ完全性検証、クリーンルーム復旧リハーサル、RTO・RPO目標に対する実際の復旧時間測定を定期的に遂行せねばならず、「復旧テスト誤り0」を運用指標として管理してこそ真の復元力が確保される。
証拠能力と完全性証明の設計：規制・フォレンジック目的の不変データは「消えない」だけでは不足し、保存の時点・内容が改ざんされていないことを立証できねばならない。ハッシュチェーン・電子署名・信頼できるタイムスタンプ（TSA）を結合して各記録の完全性と生成時点を証明し、保存全過程の監査証跡を残して法廷で証拠能力を認められるよう設計せねばならない。これは先に見たSEC Rule 17a-4改正が「監査証跡ベースの再現可能性」を認めた流れと接している。
連携技術との統合：イミュータブルストレージは単独技術ではなく[[rpo-rto-disaster-recovery]]・[[ransomware-raas]]・[[zero-trust]]・[[erasure-coding]]・[[digital-forensics]]と結合されるとき価値が大きくなる。特に災害復旧（DR）設計、ランサムウェア対応プレイブック、証拠保全体系と一貫して統合し、データ復元力（data resilience）という大きな絵の中で運用することが技術士の観点の核心である。

参考資料

SEC, "Electronic Recordkeeping Requirements for Broker-Dealers (Rule 17a-4 Amendments)" — https://www.sec.gov/
Dechert LLP, "SEC Adopts Amendments to Rule 17a-4 Electronic Recordkeeping Requirement" — https://www.dechert.com/knowledge/onpoint/2022/11/-sec-adopts-amendments-to-rule-17a-4-electronic-recordkeeping-re.html
AWS, "Amazon S3 Object Lock" documentation — https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html

一言まとめ: イミュータブルストレージ（WORM）は保存ポリシー・オブジェクトロック・リーガルホールドでデータを期間内に変更・削除不可能にストレージ層で強制し、バックアップまで狙うランサムウェアの最後の復旧手段かつ規制保存・証拠保全の基盤となるものであり、コンプライアンスモード・エアギャップ・管理プレーン隔離・定期復旧検証と結合されてはじめて完成する。