この記事の要点と4つの章のご案内
| 章構成 | 主なテーマ | 要点と確認ポイント |
|---|---|---|
| 1. 基本と全体像 | この記事の3つの要点(まずここだけ読めば安心です) | 繋ぎっぱなしの外付けHDDやNASは、感染時に真っ先に暗号化されます: 現代のランサムウェアは、パソコン本体だけでなく、USB接続されている外付けHDDやネットワーク上の共有フォルダ(NAS)、同期型クラウドドライブを自動的に探して同時に暗号化します。 |
| 2. 現場での進め方と対策 | 「バックアップを取っていたのに復旧できない」現場で起きている盲点 | 費用ゼロで今日からできる「抜いて保管(オフライン世代管理)」: 2台の外付けHDDを用意し、「金曜日の夕方にバックアップを取ったら必ずUSBケーブルを抜いて鍵付き棚にしまい、翌週はもう1台を使う」という交互運用だけで、全消失リスクは劇的に下がります。 |
| 3. 関連する制度とルール | 今日からできる交互保管と3-2-1-1-0チェックリスト | まずは本ページの図解と3項目チェックリストでご自身でできる範囲からお試しください。もし設定や判断に迷われたときは、過度な営業のないご相談窓口(お助け隊・お問い合わせ窓口)へいつでもご相談いただけます。 |
| 4. 詳しい技術仕様としくみ | バックアップ・データ保全の実践図解について、専門知識がなくても今日から対策を始められますか? | ——「毎日バックアップしていたのに全部消えた」を防ぐために、今日からできる切り離し保管と不変スナップショットの仕組み |
外付けHDDの「繋ぎっぱなし」が一番危ない?
会社と家庭を守る「3-2-1-1-0バックアップ」実践ガイド
——「毎日バックアップしていたのに全部消えた」を防ぐために、今日からできる切り離し保管と不変スナップショットの仕組み
この記事の3つの要点(まずここだけ読めば安心です)
- 01. 繋ぎっぱなしの外付けHDDやNASは、感染時に真っ先に暗号化されます: 現代のランサムウェアは、パソコン本体だけでなく、USB接続されている外付けHDDやネットワーク上の共有フォルダ(NAS)、同期型クラウドドライブを自動的に探して同時に暗号化します。
- 02. 費用ゼロで今日からできる「抜いて保管(オフライン世代管理)」: 2台の外付けHDDを用意し、「金曜日の夕方にバックアップを取ったら必ずUSBケーブルを抜いて鍵付き棚にしまい、翌週はもう1台を使う」という交互運用だけで、全消失リスクは劇的に下がります。
- 03. 国際基準「3-2-1-1-0ルール」と書き換え不能(イミュータブル)設計: 3つのコピー・2種類の媒体・1つの遠隔地保管に加え、「1つのオフラインまたは書き換え不能(WORM/ZFS hold)コピー」と「0件の復旧テストエラー」を満たす設計を具体的に解説します。
1. 「バックアップを取っていたのに復旧できない」現場で起きている盲点
ランサムウェア被害に遭われた中小企業や医院の多くが、「外付けハードディスクやNASを買って毎日自動バックアップしていたのに、そのバックアップファイルまで全部暗号化されて開けなくなった」と語られます。なぜこのようなことが起きるのか、その仕組みを図解で整理します。
図1:事象の発生構造と3段階の対策フロー
USB接続HDDは「同じパソコンの一部」
Windows等からDドライブやEドライブとして見えている外付けHDDは、ウイルスにとっても通常のフォルダと同じように一瞬で書き換え可能です。
「同期(Sync)」はバックアップではない
パソコン上のファイルが暗号化されると、自動同期機能によってクラウド上のファイルも数秒後に「暗号化された状態」へ上書きされてしまいます。
いざ戻そうとしたらファイルが壊れていた
バックアップ設定をしただけで一度も復元テストをしていないと、有事の際に「実は半年前に容量不足で止まっていた」という事態が頻発します。
場面別の実務確認ポイント
2. 今日からできる交互保管と3-2-1-1-0チェックリスト
専門的な知識がなくても、ご家庭や職場で今日から順番に確認・実践できる具体的な比較表とチェックリストをまとめました。
| 評価軸 | 常時接続の外付けHDD / 共有NAS | 物理切り離し(2台交互ローテーション) | 3-2-1-1-0 不変(Immutable)バックアップ |
|---|---|---|---|
| ランサムウェア感染時の耐性 | 極めて低い(本体と同時に暗号化される) | 高い(抜いてあるHDDは物理的に感染しない) | 極めて高い(OSカーネル層で削除・変更を拒否) |
| 初期費用・追加コスト | 既存のまま(0円) | 外付けHDD 1台追加のみ(約1〜2万円) | 既存サーバー設定または伴走支援内で構築可能 |
| 日々の手作業・忘れやすさ | 手間なし(ただし全滅リスク大) | 週1回の抜き差し習慣が必要 | 自動化(Pull型転送+自動スナップショット) |
| 目標復旧時点(RPO) | 復旧不能になる恐れ | 最大1週間前(週次交互の場合) | 15分〜1時間前の任意の時点へ即座に復元 |
| SCS評価制度(★3)適合性 | 不適合(切り離し・不変性要件を満たさない) | 基本適合(オフライン保管として有効) | 基準適合(3〜4の自動検証証跡まで充足) |
今日から無理なく進めるための4ステップ実践手順
現状の棚卸しと「見えにくいリスク」の把握
新しい機器やソフトを購入する前に、現在使っている機器・アカウント・契約先を紙1枚に書き出します。被害の大半は「昔作ったまま誰も管理していない古い機器や共有アカウント」から始まります。
費用をかけずにできる「3つの基本設定」
01 パスキー(FIDO2)または二要素認証の有効化、02 ルーター・VPN・OSの自動更新設定、03 バックアップ用外付けHDDの常時接続解除(切り離し保管)の3点を実施します。
異変に気づいたときの「責めない連絡ルール」
不審なリンクを開いたり偽警告が出たりした際、「怒られるかも」と隠すことが被害を広げます。「迷ったら6秒深呼吸して手を止め、すぐ共有してくれた人を褒める」ルールを共有します。
定期的な復元テストと第三者の落ち着いた確認
季節の変わり目ごとに「バックアップから実際に1つのファイルを戻せるか」を試すとともに、退職・異動に伴うアカウント整理を行い、迷う点は専門窓口で点検します。
現場で陥りやすい3つの落とし穴と、安全な回避策
落とし穴 01:NASのゴミ箱機能を有効にしているから安心と思い込む
攻撃者はNASの管理者画面(Web管理コンソール)にも侵入し、ゴミ箱の全体消去や初期化コマンドを実行します。ネットワーク越しに書き込みできる領域はすべて保護対象外と考えてください。
落とし穴 02:バックアップ完了通知メールを誰も見ていない
外付けHDDの故障や容量上限で3ヶ月前からバックアップが失敗していたのに気づかないケースが多発しています。月1回は必ず「別パソコンへ1ファイル戻してみるテスト」を行ってください。
落とし穴 03:暗号化パスワードを紛失して自分たちでも開けなくなる
持ち出し盗難対策として外付けHDDをBitLocker等で暗号化する際は、回復キーを印刷して金庫に保管するなど、担当者不在でも復号できる手順を残してください。
今日からできる3項目セルフチェック(クリックして確認)
達成状況:0 / 3 項目ご家庭や職場で現在できている項目にチェックを入れてみてください。すべてお使いのブラウザ内でのみ計算され、外部へ送信されることはありません。
ランサムウェア感染に備えるバックアップ運用として、最も安全で理にかなっているものはどれでしょうか?
よくあるご質問と、迷ったときの判断基準
Q1. 社内に専任のシステム担当者がいないのですが、自分たちだけで始められますか?
はい、始められます。まずは費用や特別な契約を伴わない「基本の3項目(パスキー・自動更新・切り離し保管)」から1つずつ進めてみてください。途中で設定画面の見方が分からなくなったときだけ、相談窓口を頼っていただければ十分です。
Q2. 外部の営業担当者から「今すぐ専用機器(UTM等)をリース契約しないと手遅れになる」と言われました。
その場で即決せず、必ず見積書を持ち帰ってセカンドオピニオンを確認してください。公的ガイドラインや2026年SCS評価制度(★3)が求めているのは、特定メーカーの高額機器ではなく「基本的な管理の仕組み」です。
Q3. このページの内容を印刷して、職場や家族に配ってもよいですか?
もちろんです。本サイトの図解やチェックリストは、地域の企業・医院・学校・ご家庭の安全を守るための公開技術資料として掲載しています。ブラウザの印刷機能(A4縦)でそのまま読みやすく印刷できます。
NIST SP 800-209 3-2-1-1-0 不変バックアップ検証と GFS(Grandfather-Father-Son)世代管理エンジン
本節では、NIST SP 800-209(Storage Security Guideline)および 2026年 SCS評価制度(★3・★4)が要求する「3-2-1-1-0 バックアップ原則」を数理的・プログラム的に保証するための GFS 世代保持ポリシーおよび SHA-256 マニフェスト整合性検証器(Rust Edition 2024)を定義します。
1. プロトコル内部構造・数理モデルと設計根拠
1. Push型バックアップの脆弱性と Pull型(引き取り型)アーキテクチャ: 本番サーバー(Production)がバックアップサーバー(Vault)のSSH鍵やSMB資格情報を保持してデータを書き込む「Push型」では、本番サーバー侵害時にVault側も同時に破壊されます。したがって、本番環境からはVaultへの通信をファイアウォール(FreeBSD pf)で全体遮断し、独立したVault側から読み取り専用(Read-Only)でスナップショットを引き取る「Pull型」トポロジが必須となります。
2. 3-2-1-1-0 不変条件の形式化: データセット D に対し、コピー集合 C = {c_1, c_2, ..., c_n} が |C| ≥ 3、異なるストレージメディア種別数 |Media(C)| ≥ 2、異なる地理的拠点 |Site(C)| ≥ 2、オフラインまたは不変ロック済みコピー |{c ∈ C | Immutable(c) = true}| ≥ 1、かつ直近のリストア検証エラー数 Erestore = 0 を同時に満たすことを日次バッチで自動証明します。
2. 技術パラメータ・検証仕様一覧
| 3-2-1-1-0 指標 | 数理・システム不変条件 | 小規模現場での具体実装 | 自動監査・検証コマンド例 |
|---|---|---|---|
| 3 Copies | |C| >= 3 (本番1 + バックアップ2以上) | 本番PC/サーバ + 外付けHDD A + 外付けHDD B(またはクラウド) | zfs list -t snapshot / manifest count >= 3 |
| 2 Media Types | |Media(C)| >= 2 (異なる物理障害特性) | 内蔵NVMe SSD + 外付け磁気HDD / オブジェクトストレージ | lsblk / camcontrol devlist による媒体種別確認 |
| 1 Offsite | |Site(C)| >= 2 (火災・水害からの分離) | 別フロア耐火金庫または国内別リージョン(db01.ok.st Vault) | replication target ASN / 拠点コード照合 |
| 1 Immutable / Air-Gap | Immutable(c) == true OR Offline(c) == true | USB物理抜去保管 または OpenZFS zfs hold / Object Lock | zfs holds -r tank/vault (userrefs >= 1) |
| 0 Restore Errors | E_restore == 0 (SHA-256 一致) | 月1回のサンドボックス自動展開とハッシュ照合 | sha256sum -c manifest.sha256 (exit code 0) |
#![forbid(unsafe_code)]
use std::collections::HashSet;
#[derive(Debug, Clone, Copy, PartialEq, Eq, Hash)]
pub enum MediaType {
InternalNvme,
ExternalUsbHdd,
ZfsImmutablePool,
OffsiteObjectStorage,
}
#[derive(Debug, Clone)]
pub struct BackupCopyMeta {
pub copy_id: &'static str,
pub media_type: MediaType,
pub site_code: &'static str,
pub is_offline_or_immutable: bool,
pub last_restore_verified_unix: u64,
pub last_restore_error_count: u32,
}
#[derive(Debug, Clone, PartialEq, Eq)]
pub struct Rule32110Report {
pub total_copies: usize,
pub distinct_media: usize,
pub distinct_sites: usize,
pub immutable_copies: usize,
pub restore_errors: u32,
pub is_compliant: bool,
}
pub fn evaluate_32110_compliance(copies: &[BackupCopyMeta], now_unix: u64, max_verify_age_sec: u64) -> Rule32110Report {
let total_copies = copies.len();
let distinct_media: HashSet<MediaType> = copies.iter().map(|c| c.media_type).collect();
let distinct_sites: HashSet<&str> = copies.iter().map(|c| c.site_code).collect();
let immutable_copies = copies
.iter()
.filter(|c| c.is_offline_or_immutable)
.count();
let mut restore_errors = 0u32;
for c in copies {
restore_errors = restore_errors.saturating_add(c.last_restore_error_count);
if now_unix.saturating_sub(c.last_restore_verified_unix) > max_verify_age_sec {
restore_errors = restore_errors.saturating_add(1);
}
}
let is_compliant = total_copies >= 3
&& distinct_media.len() >= 2
&& distinct_sites.len() >= 2
&& immutable_copies >= 1
&& restore_errors == 0;
Rule32110Report {
total_copies,
distinct_media: distinct_media.len(),
distinct_sites: distinct_sites.len(),
immutable_copies,
restore_errors,
is_compliant,
}
}
#[cfg(test)]
mod tests {
use super::*;
#[test]
fn test_32110_rule_passes_only_with_immutable_and_zero_errors() {
let now = 1_710_000_000;
let copies = vec![
BackupCopyMeta {
copy_id: "prod-nvme",
media_type: MediaType::InternalNvme,
site_code: "osaka-hq",
is_offline_or_immutable: false,
last_restore_verified_unix: now - 3600,
last_restore_error_count: 0,
},
BackupCopyMeta {
copy_id: "usb-offline-week-a",
media_type: MediaType::ExternalUsbHdd,
site_code: "osaka-hq",
is_offline_or_immutable: true,
last_restore_verified_unix: now - 86_400,
last_restore_error_count: 0,
},
BackupCopyMeta {
copy_id: "remote-zfs-vault",
media_type: MediaType::ZfsImmutablePool,
site_code: "tokyo-dr",
is_offline_or_immutable: true,
last_restore_verified_unix: now - 7200,
last_restore_error_count: 0,
},
];
let rep = evaluate_32110_compliance(&copies, now, 30 * 86_400);
assert!(rep.is_compliant);
assert_eq!(rep.immutable_copies, 2);
}
}
OpenZFS 128バイト blkptr_t マークル木・Copy-on-Write 不変スナップショット復旧基盤
プロトコル仕様・数理モデル・Rust 2024 実装コードの詳細は、専門技術モノグラフにて公開しています。
あわせて読みたい関連ガイド
まずは本ページの図解とチェックリストでご自身でできる対策からお試しください。関連する手順や、自分たちだけでは判断に迷われたときの相談窓口も以下からご覧いただけます。