本文へスキップ
株式会社オープンナレッジ
株式会社オープンナレッジ Open Knowledge Inc.
1. 基本と全体像

この記事の要点と4つの章のご案内

この記事の3つの要点(まずここだけ読めば安心です)に関するイメージ写真
この記事の3つの要点(まずここだけ読めば安心です)
なぜ「毎日まじめにバックアップを取っていた会社」の8割が復旧に失敗するのか?に関するイメージ写真
なぜ「毎日まじめにバックアップを取っていた会社」の8割が復旧に失敗するのか?
ランサムウェアに侵入されても数分で業務を取り戻す「OpenZFS 不変バックアップ」の仕組み の各章におけるテーマと要点一覧表
章構成 主なテーマ 要点と確認ポイント
1. 基本と全体像 この記事の3つの要点(まずここだけ読めば安心です) パソコンやサーバーと「同じ権限でつなぎっぱなし」のバックアップは、攻撃者に真っ先に消されます: 警察庁の調査でも、ランサムウェア被害企業の約8割でバックアップデータが同時に暗号化・削除され、元通り復旧できたのは約2割にとどまっています。
2. 現場での進め方と対策 なぜ「毎日まじめにバックアップを取っていた会社」の8割が復旧に失敗するのか? 「上書き保存」ではなく「過去の時点を凍らせて残す(Copy-on-Write)」仕組みが鍵です: OpenZFSのスナップショットは、新しいデータを常に別の場所へ書き込み、過去のブロックを一切書き換えないため、15分前・1時間前の無傷な状態をそのまま保持できます。
3. 関連する制度とルール バックアップ方式別の「ランサムウェア耐性・復旧時間」比較表 まずは本ページの図解と3項目チェックリストでご自身でできる範囲からお試しください。もし設定や判断に迷われたときは、過度な営業のないご相談窓口(お助け隊・お問い合わせ窓口)へいつでもご相談いただけます。
4. 詳しい技術仕様としくみ OpenZFS 128-Byte blkptr_t マークル木と zfs hold カーネルロックによる O(1) 不変復旧の実装仕様 ——「毎日外付けHDDにバックアップしていたのに復旧できなかった」という悲劇をゼロにするために
第1章〜第4章では、実務チェックリスト・公的制度基準・詳しい技術仕様を確認できます。
不変バックアップ・数分復旧設計 監修・執筆:登録情報処理安全確保支援士(第007617号)・上級医療情報技師 加藤 明生

ランサムウェアに侵入されても数分で業務を取り戻す「OpenZFS 不変バックアップ」の仕組み

——「毎日外付けHDDにバックアップしていたのに復旧できなかった」という悲劇をゼロにするために

この記事の3つの要点(まずここだけ読めば安心です)

  • 01. パソコンやサーバーと「同じ権限でつなぎっぱなし」のバックアップは、攻撃者に真っ先に消されます: 警察庁の調査でも、ランサムウェア被害企業の約8割でバックアップデータが同時に暗号化・削除され、元通り復旧できたのは約2割にとどまっています。
  • 02. 「上書き保存」ではなく「過去の時点を凍らせて残す(Copy-on-Write)」仕組みが鍵です: OpenZFSのスナップショットは、新しいデータを常に別の場所へ書き込み、過去のブロックを一切書き換えないため、15分前・1時間前の無傷な状態をそのまま保持できます。
  • 03. 数テラバイトのデータでも、コピー待ち時間なしの「数秒(O(1)ロールバック)」で業務を再開できます: 外付けHDDから何十時間もかけてデータを書き戻すのではなく、正常だった時点の目録(ポインタ)へ切り替えるだけで瞬時に復旧が完了します。
第1章:背景と仕組みの図解

1. なぜ「毎日まじめにバックアップを取っていた会社」の8割が復旧に失敗するのか?

多くの職場で「夜中に自動でNASや外付けHDDへコピーする設定」が使われています。しかし、パソコンからボタン1つで開ける共有フォルダは、パソコンに侵入したランサムウェアからも同じように開いて暗号化できてしまいます。本当に必要なのは、業務パソコン側からは「原則として上書きも削除もできない一方通行の金庫(不変スナップショット)」です。

図1:事象の発生構造と3段階の対策フロー

従来の失敗例:常時接続のNAS・HDD ・業務PCから共有フォルダとして常時書込可能 ・感染と同時にバックアップ側も暗号化・削除 ・復旧に数週間〜数ヶ月、またはデータ消失 ※主な発生要因の整理 OpenZFSの仕組み:Copy-on-Write ・変更時は別領域へ書込み、過去データは不変 ・15分ごとに「凍らせた世代(Snapshot)」作成 ・zfs holdロックにより管理者権限でも消去不能 ※初期設定と運用手順 有事の復旧:身代金0円・数分で再開 ・暗号化検知から0.1秒で異常通信を遮断 ・感染直前のスナップショットへポインタ切替 ・大容量データのコピー待ちなしで即座に再開 ※システム層での保護機構
特徴 01:容量と速度の両立

15分ごとに世代を残しても容量を圧迫しない

変更があった差分ブロックだけを記録するため、1日に96回スナップショットを取ってもディスク容量をほとんど消費せず高速に動作します。

特徴 02:サイレント破損の自己修復

256ビットチェックサムで経年劣化も防ぐ

ハードディスクの磁気劣化(ビット腐敗)が起きても、ツリー構造の検査値(Fletcher-4 / SHA-256)で自動的に検知・修復します。

特徴 03:Pull型レプリケーション

バックアップ機には「外からの入り口」を作らない

業務サーバーからバックアップ機へ押し込む(Push)のではなく、隔離されたバックアップ機がデータを取りに行く(Pull)ため侵入されません。

場面別の実務確認ポイント

ご家庭・シニア・初めて学ぶ方へ 難しい専門用語を覚える必要はありません。上の図解の「真ん中の箱(手順 02)」と、実践チェックリストの3項目を1つずつ確認するだけで十分に安全を高められます。
経営者・総務・医療や現場の責任者の方へ 比較表と実践手順をそのまま社内の点検シートとしてお使いいただけます。高額な機器契約の前に確認すべき判断基準も明記しています。
ろう者・難聴者・発達障害のある方へ 音声や動画のみに頼らず、すべて視覚的な図解と文字で完結しています。画面右上の「文字拡大」「シンプル表示」や、A4印刷にも対応しています。
情報システム担当・エンジニア・研究者の方へ 第3章にて、RFC・CVE・NIST SP 800シリーズ等の一次仕様に基づく数理モデルと、Rust Edition 2024(unsafe禁止)による検証コードを公開しています。
第2章:実践手順とセルフチェック

2. バックアップ方式別の「ランサムウェア耐性・復旧時間」比較表

現在職場で採用しているバックアップ方式がどのタイプに当てはまるか、万が一の際の復旧時間(RTO)とあわせて確認してみてください。

バックアップ方式ランサムウェア感染時の耐性復旧にかかる時間(10TBの場合)運用の手間と注意点
USB外付けHDD・共有NAS(常時接続) 極めて低い(8割の事案で同時に暗号化) 復旧不能(または専門業者で数百万円・数週間) 最も被害が多い構成。今すぐ常時接続の見直しが必要
外付けHDDの手動抜き差し(曜日ローテーション) 中(抜いてあるHDDは無事だが、接続中の世代は被災) 12時間〜48時間(USB経由での全量コピー書き戻し) 担当者が差し忘れるリスクや、持ち出し紛失リスクがある
一般的なクラウドストレージ同期(双方向同期) 低〜中(暗号化されたファイルがそのままクラウドへ同期) 24時間〜数日(回線帯域によるダウンロード律速) バージョン履歴機能がない、または管理者ID奪取で全消去される
FreeBSD + OpenZFS 不変スナップショット(Pull隔離) 極めて高い(CoW不変保護+zfs holdで消去不能) 数秒〜数分(O(1) ポインタロールバックで即時再開) 自動化されているため日常の手作業ゼロ・テスト復元も数秒

今日から無理なく進めるための4ステップ実践手順

手順 01(所要時間:約15分)

現状の棚卸しと「見えにくいリスク」の把握

新しい機器やソフトを購入する前に、現在使っている機器・アカウント・契約先を紙1枚に書き出します。被害の大半は「昔作ったまま誰も管理していない古い機器や共有アカウント」から始まります。

手順 02(所要時間:約30分)

費用をかけずにできる「3つの基本設定」

01 パスキー(FIDO2)または二要素認証の有効化、02 ルーター・VPN・OSの自動更新設定、03 バックアップ用外付けHDDの常時接続解除(切り離し保管)の3点を実施します。

手順 03(所要時間:約15分)

異変に気づいたときの「責めない連絡ルール」

不審なリンクを開いたり偽警告が出たりした際、「怒られるかも」と隠すことが被害を広げます。「迷ったら6秒深呼吸して手を止め、すぐ共有してくれた人を褒める」ルールを共有します。

手順 04(3ヶ月に1回・約15分)

定期的な復元テストと第三者の落ち着いた確認

季節の変わり目ごとに「バックアップから実際に1つのファイルを戻せるか」を試すとともに、退職・異動に伴うアカウント整理を行い、迷う点は専門窓口で点検します。

現場で陥りやすい3つの落とし穴と、安全な回避策

落とし穴 01:「クラウドに同期しているから安心」と思っていたら、暗号化された状態まで同期された

パソコンのフォルダとクラウドを自動同期する設定では、パソコン上のファイルがランサムウェアで暗号化された瞬間に、クラウド側のファイルも「最新の変更」として暗号化データで上書きされてしまいます。「同期」と「世代バックアップ」は別物です。

落とし穴 02:一度も「バックアップから戻す練習(復元テスト)」をしたことがない

「毎日バックアップ完了メールが届いているから大丈夫」と思っていても、いざ事故が起きたときに「特定フォルダが対象外だった」「復元手順書がなくて誰も戻せない」というケースが多発しています。3ヶ月に1回、1つのファイルを別フォルダへ復元する確認を行いましょう。

落とし穴 03:バックアップ機の管理パスワードを業務用のパソコンと同じにしている

NAS自体の管理画面(Web UI)のパスワードが業務PCと同じだったり初期パスワードのままだと、攻撃者はまずNASの管理画面にログインして「スナップショット全削除・初期化」を実行してから暗号化を始めます。

今日からできる3項目セルフチェック(クリックして確認)

達成状況:0 / 3 項目

ご家庭や職場で現在できている項目にチェックを入れてみてください。すべてお使いのブラウザ内でのみ計算され、外部へ送信されることはありません。

上の3項目をクリックすると、現在の達成状況に応じたアドバイスが表示されます。まずは1項目ずつ順番に整えていきましょう。
理解を深める確認クイズ

OpenZFSの「不変スナップショット(Copy-on-Write)」が、ランサムウェア被害からの復旧において大きくに速く安全である理由はどれでしょうか?

よくあるご質問と、迷ったときの判断基準

Q1. 社内に専任のシステム担当者がいないのですが、自分たちだけで始められますか?

はい、始められます。まずは費用や特別な契約を伴わない「基本の3項目(パスキー・自動更新・切り離し保管)」から1つずつ進めてみてください。途中で設定画面の見方が分からなくなったときだけ、相談窓口を頼っていただければ十分です。

Q2. 外部の営業担当者から「今すぐ専用機器(UTM等)をリース契約しないと手遅れになる」と言われました。

その場で即決せず、必ず見積書を持ち帰ってセカンドオピニオンを確認してください。公的ガイドラインや2026年SCS評価制度(★3)が求めているのは、特定メーカーの高額機器ではなく「基本的な管理の仕組み」です。

Q3. このページの内容を印刷して、職場や家族に配ってもよいですか?

もちろんです。本サイトの図解やチェックリストは、地域の企業・医院・学校・ご家庭の安全を守るための公開技術資料として掲載しています。ブラウザの印刷機能(A4縦)でそのまま読みやすく印刷できます。

4. 詳しい技術仕様としくみ:技術アーキテクチャ仕様

OpenZFS 128-Byte blkptr_t マークル木と zfs hold カーネルロックによる O(1) 不変復旧の実装仕様

設計背景・判断基準リファレンス

本節では、OpenZFS のトランザクショングループ(TXG)コミットモデル、128バイトブロックポインタ(blkptr_t)内の256ビットチェックサム検証、および zfs send --raw による暗号化ストリームのPull型隔離レプリケーションを定式化する。

ブロックポインタ構造
128-Byte blkptr_t + 256-Bit Fletcher-4/SHA-256
不変ロック機構
zfs snapshot + zfs hold (EROFS / EBUSY 強制)
レプリケーション方式
Pull-Only SSH/mTLS zfs send --raw Stream
ロールバック計算量
O(1) Uberblock TXG Pointer Switch (< 1 sec)

1. プロトコル内部構造・数理モデルと設計根拠

1. 【Copy-on-Write トランザクショングループ(TXG)と Uberblock の原子性】 OpenZFS ではディスク上の既存ブロックをその場で上書き(In-place Overwrite)することは一切ない。すべての変更は新しい空きブロックへ書き込まれ、親ノードの blkptr_t(128 bytes)が子のチェックサムを再計算しながらルート(Uberblock)までボトムアップに更新される。スナップショット \mathcal{S}t は特定 TXG 番号におけるルート blkptr_t を参照カウント付きで固定する操作であるため、後にランサムウェアが全ファイルを暗号化しても、\mathcal{S}t が指すマークル木配下の全データブロックはディスク上で1ビットも変更されない。

2. 【zfs hold と Securelevel による root 権限奪取耐性】 攻撃者が万が一ストレージホストの特権を奪取した場合でも、zfs hold が付与されたスナップショットに対する zfs destroy はカーネル内で EBUSY により拒絶される。さらにレプリケーション先の Vault サーバーを Pull 専用(外部からの SSH/API 受信なし)で構成することで、厳密な非対称分離が成立する。

2. 技術パラメータ・検証仕様一覧

ZFS 内部構造体 / 機能バイトサイズ / パラメータ暗号学的・構造的役割ランサムウェア防御における効果
Uberblock Ring Array 1024 bytes × 128 slots / vdev アトミックなTXGルートポインタの世代管理 クラッシュや強制電源断でも整合性を100%維持
blkptr_t (Block Pointer) 128 bytes (3 DVAs + 256-bit Checksum) 親ブロックが子ブロックのハッシュを保持するMerkle木 1ビットの改ざん・Bit-Rotも読込時に即時検知・修復
Snapshot & zfs hold O(1) Metadata Reference Lock 指定TXG配下の全ブロックの解放(Free)を禁止 unlink/destroy によるバックアップ消去をカーネル拒否
recordsize=8K + LZ4 8192 bytes (PostgreSQL 19 Page Aligned) DBページとストレージレコードの1:1境界一致 Partial Block Write ゼロ化による高速I/Oと高圧縮
3. リファレンス実装コード(crates/ok-zfs-vault/src/snapshot_retention_guard.rs) Rust Edition 2024 (#![forbid(unsafe_code)])
#![forbid(unsafe_code)]

#[derive(Debug, Clone, PartialEq, Eq)]
pub struct ZfsSnapshotMeta {
    pub dataset: &'static str,
    pub snapshot_name: &'static str,
    pub txg_id: u64,
    pub creation_unix_sec: u64,
    pub hold_tag_active: bool,
    pub fletcher4_verified: bool,
}

#[derive(Debug, Clone, Copy, PartialEq, Eq)]
pub enum RollbackPlan {
    ReadyForInstantRollback { target_txg: u64, rpo_seconds: u64 },
    RejectedMissingHoldLock,
    RejectedChecksumMismatch,
    NoValidSnapshotFound,
}

pub fn select_clean_rollback_target(
    snapshots: &[ZfsSnapshotMeta],
    attack_detected_unix_sec: u64,
) -> RollbackPlan {
    let mut best_candidate: Option<&ZfsSnapshotMeta> = None;

    for snap in snapshots {
        if snap.creation_unix_sec >= attack_detected_unix_sec {
            continue;
        }
        if !snap.fletcher4_verified {
            return RollbackPlan::RejectedChecksumMismatch;
        }
        if !snap.hold_tag_active {
            return RollbackPlan::RejectedMissingHoldLock;
        }
        match best_candidate {
            None => best_candidate = Some(snap),
            Some(prev) if snap.creation_unix_sec > prev.creation_unix_sec => {
                best_candidate = Some(snap);
            }
            _ => {}
        }
    }

    match best_candidate {
        Some(target) => RollbackPlan::ReadyForInstantRollback {
            target_txg: target.txg_id,
            rpo_seconds: attack_detected_unix_sec.saturating_sub(target.creation_unix_sec),
        },
        None => RollbackPlan::NoValidSnapshotFound,
    }
}
4. 詳しい技術仕様としくみ(システム設計・数理モデル・実装例)

OpenZFS 128バイト blkptr_t マークル木・Copy-on-Write 不変スナップショット復旧基盤

プロトコル仕様・数理モデル・Rust 2024 実装コードの詳細は、専門技術モノグラフにて公開しています。

技術モノグラフを読む →
ご質問・公的制度の活用に関するお問い合わせ窓口

掲載資料に関するご質問・公的制度活用のご案内

本ページの図解や解説内容に関するご質問、経済産業省「SCS評価制度」やIPA「SECURITY ACTION・サイバーセキュリティお助け隊サービス」等の公的制度の確認方法について、落ち着いた参考窓口としてご案内しております。売り込みや営業連絡は一切行いませんので、社内勉強会やご家庭での確認資料としてご自由にご活用ください。

図解・ビジュアルの拡大表示

図表内のテキストもそのまま選択・検索可能です(ベクターSVG描画) 枠外クリックまたは ESC キーで閉じます