LUKS 暗号化の手順と運用

by

LUKS 暗号化を使うと、外付け HDD、SSD、バックアップ媒体、遠隔地保管媒体を、紛失や盗難に強い形で管理できる。しかし、LUKS は単に cryptsetup コマンドを実行すれば終わる仕組みではない。暗号化対象の確認、luksFormat、open、ファイルシステム作成、マウント、バックアップ取得、アンマウント、close、ヘッダーバックアップ、パスフレーズ管理、媒体台帳、復元確認までを一つの運用として扱わなければ、暗号化した媒体は安全なバックアップではなく、読めなくなる可能性を抱えた箱になる。本稿では、LUKS の基本構造と暗号化手順を整理したうえで、バックアップ媒体を安全に運用し、必要な時点で復元できる状態を維持するための実用手順をまとめる。

バックアップ媒体の管理を考えるとき、問題は単に「どの HDD や SSD を使うか」ではない。重要なのは、媒体が壊れる、読めなくなる、紛失する、盗まれる、取り違えられる、誤って上書きされる、接続中に攻撃される、長期保管中に劣化する、という前提で、それでも必要な時点のデータを復元できる状態を維持することである。本稿では、先に整理した物理媒体管理の考え方を出発点にし、LUKS による暗号化、鍵管理、パスフレーズ運用、ヘッダーバックアップ、媒体台帳、世代管理、復元訓練までを一つのバックアップ・リカバリー戦略として統合する[1]。

ここでの中心命題は明確である。バックアップとは、データの複製を作る作業ではなく、復元可能性を設計することである[2]。暗号化は漏えい対策であると同時に、復元不能リスクを増やす操作でもある。LUKS 暗号化媒体を使う場合、媒体が壊れる、読めなくなる、紛失する、盗まれる、取り違えられる、誤って上書きされる、接続中に攻撃される、長期保管中に劣化する、という前提に加えて、パスフレーズを忘れる、LUKS ヘッダーが壊れる、古いヘッダーバックアップが残る、どの媒体がどの鍵体系か分からなくなる、という暗号化固有の失敗も考えなければならない。

1. LUKS は暗号化アルゴリズムではなく、暗号化媒体を運用するための管理層である

LUKS は Linux Unified Key Setup の略であり、Linux において暗号化ブロックデバイスを実用的に扱うための標準的な形式である。ここで最初に区別すべきなのは、LUKS は暗号化アルゴリズムそのものではないという点である。実際にブロックデバイス上の読み書きを暗号化・復号するのは Linux カーネルの device-mapper に含まれる dm-crypt であり、dm-crypt はカーネルの crypto API を用いてブロックデバイスに透過的な暗号化を提供する[3]。

LUKS の役割は、その dm-crypt を人間が長期運用できる形に包むことである。plain dm-crypt では、暗号方式、鍵、IV 生成方式、オフセットなどの情報を利用者側が正確に管理しなければならない。これに対して LUKS は、ディスク上にメタデータヘッダーを持ち、暗号設定、UUID、鍵スロット、PBKDF 情報などを保存する。cryptsetup の FAQ も、LUKS ではパーティション先頭付近にヘッダーと鍵スロット領域が存在し、それらが復号可能性の中核になることを説明している[4]。

層 役割 運用上の意味
物理媒体 HDD、SSD、USB 接続ディスク、内蔵 NVMe などの実体である。 故障、紛失、盗難、経年劣化、接続不良の対象になる。
ブロックデバイス /dev/sdX、/dev/nvme0n1pX などとして OS から見える単位である。 対象を間違えると初期化や上書きで即座にデータを失う。
dm-crypt ブロック単位の暗号化・復号を実行するカーネル機能である。 実際の暗号化処理はこの層で行われる。
LUKS 暗号化設定、鍵スロット、ヘッダー、鍵導出情報を管理する形式である。 複数パスフレーズ、ヘッダーバックアップ、鍵変更を可能にする。
mapper デバイス /dev/mapper/backupdisk のように復号後に見える仮想ブロックデバイスである。 ファイルシステムや LVM はこの上に作成する。
ファイルシステム ext4、XFS、Btrfs など、実際にファイルを保存する層である。 LUKS を閉じるとこの層も読めなくなる。

cryptsetup は、この LUKS と dm-crypt を操作する管理コマンドである。cryptsetup の man page は、cryptsetup がストレージデバイスやコンテナーに対する full-disk encryption を設定・管理するユーティリティであり、LUKS、plain dm-crypt、その他の形式を扱うことを説明している[5]。したがって、実務上は「LUKS で暗号化する」と言っても、その内側では「LUKS 形式のメタデータを持つ dm-crypt デバイスを cryptsetup で管理する」と理解するのが正確である。

2. LUKS が守るものは、保存状態の媒体である

LUKS の効果を過大評価してはならない。LUKS が強いのは、電源断後、アンマウント後、LUKS close 後、媒体単体が流出した状態である。たとえば、外付け HDD を紛失した、遠隔地保管中の媒体が盗まれた、退役媒体を誤って廃棄した、サーバーからディスクだけ抜かれた、という状況では、正しいパスフレーズや鍵がなければ中身を読むことは困難になる。

一方で、LUKS は稼働中の侵害対策ではない。いったん LUKS デバイスを開き、/dev/mapper 配下に復号済みブロックデバイスが現れ、ファイルシステムがマウントされると、OS からは通常のファイルシステムとして読める。したがって、ログイン中のマルウェア、root 権限奪取、復号済みバックアップ媒体への攻撃、マウント済みディレクトリの誤削除は、LUKS だけでは防げない。

状況 LUKS の効果 理由
媒体を紛失した 有効である。 復号鍵がなければ媒体単体から内容を読み出しにくい。
遠隔地保管媒体が盗まれた 有効である。 物理保管場所が自分の管理外でも内容保護を維持できる。
退役ディスクを誤廃棄した 一定の効果がある。 平文データがそのまま残る状況を避けられる。
ログイン中にマルウェアが動作した 無効である。 復号済みファイルシステムには通常権限でアクセスされ得る。
root 権限を奪取された 無効である。 復号済み mapper デバイスやマウント済みファイルを読める。
/boot や initramfs が改ざんされた 単独では不十分である。 パスフレーズ入力前の起動チェーンが攻撃対象になり得る。

したがって、LUKS は「媒体流出時の情報漏えい対策」であり、「稼働中のシステム侵害対策」ではない。バックアップ媒体管理における LUKS の本質は、保存状態、保管状態、移動状態、退役状態の媒体を保護することにある。

3. LUKS ヘッダー、マスターキー、キースロットの関係を理解する

LUKS を安全に運用するには、パスフレーズが直接データを暗号化しているわけではないことを理解する必要がある。実際には、データ暗号化に使われるマスターキー、またはボリュームキーがあり、ユーザーのパスフレーズはそのマスターキーを復号するための鍵を導出する入力として使われる。これにより、同じ暗号化データ領域に対して複数のパスフレーズや鍵ファイルを登録できる。

この構造は、バックアップ媒体管理において非常に重要である。パスフレーズを変更しても、データ全体を再暗号化しているわけではなく、通常はマスターキーを保護するキースロット側を変更している。したがって、古いキースロットや古いヘッダーバックアップの扱いを誤ると、「削除したつもりの旧鍵」が復活し得る。

要素 意味 失われた場合の影響
マスターキー データ領域を実際に暗号化・復号する鍵である。 復元不能になる。
パスフレーズ 利用者が記憶し、入力する秘密情報である。 そのパスフレーズでは開けなくなる。
PBKDF パスフレーズから鍵を導出する処理である。 設定互換性を失うと復号できなくなる可能性がある。
キースロット 複数のパスフレーズや鍵ファイルでマスターキーを保護する領域である。 全スロットを失うと開けなくなる。
LUKS ヘッダー 暗号設定と鍵管理情報を保持する領域である。 破損するとデータ本体が無傷でも復号不能になり得る。

cryptsetup の luksFormat は、既存の LUKS コンテナーに対して実行すると新しいボリュームキーを生成し、ヘッダーバックアップがなければ古い暗号化データを永久に読めなくする可能性があると警告している[6]。これは、LUKS ではヘッダーと鍵スロットが復元可能性の中核であり、データ領域だけを見ても安全性や復旧性を判断できないことを示している。

4. LUKS ヘッダーバックアップは復旧性を高めるが、過去の鍵状態も保存する

LUKS 運用で重要となる作業の一つが、ヘッダーバックアップである。LUKS ヘッダーやキースロット領域が壊れると、データ本体が残っていても復号できない可能性がある。したがって、LUKS ヘッダーバックアップは、LUKS 媒体を作成するための必須手順ではないが、バックアップ媒体を長期運用する場合には強く推奨される。cryptsetup の luksHeaderBackup は、LUKS ヘッダーとキースロット領域のバイナリバックアップを保存する機能である[7]。

ただし、ヘッダーバックアップは単純な安全装置ではない。ヘッダーバックアップは、その時点の鍵スロット状態を保存する。つまり、その後にパスフレーズを削除しても、古いヘッダーバックアップと古いパスフレーズが残っていれば、古い鍵状態を復元できる可能性がある。したがって、パスフレーズを変更した場合、媒体本体だけでなく、ヘッダーバックアップの世代と保管場所も管理対象になる。

操作 推奨される対応 怠った場合の問題
LUKS 新規作成 長期運用するバックアップ媒体では、ヘッダーバックアップを取得する。 ヘッダー破損時に復旧できない可能性が高くなる。
パスフレーズ追加 新しい鍵スロットを復旧対象に含める必要がある場合は、ヘッダーバックアップを更新する。 新しい鍵スロットを含む復旧手段が残らない。
パスフレーズ削除 古いヘッダーバックアップを失効扱いにする。 削除した旧パスフレーズが復活し得る。
媒体退役 媒体本体とヘッダーバックアップを対応づけて処分する。 退役済み媒体の復号材料が残る。
遠隔地保管 ヘッダー、媒体、パスフレーズ体系を台帳化する。 復元時に必要な構成が分からなくなる。

この章の要点は、ヘッダーバックアップを「必ず取るか、まったく不要か」という二択で考えないことである。ヘッダーバックアップは、LUKS 媒体の通常利用に必要なものではない。しかし、長期バックアップ媒体では復旧性の保険として強く推奨される。一方で、過去の鍵状態を保存する機密物でもあるため、取得後は保管、更新、失効、処分までを運用に含める必要がある。

5. LUKS2、PBKDF、Argon2 はパスフレーズ運用と結びついている

現在の新規運用では、通常 LUKS2 を基本に考えるのが妥当である。LUKS2 は LUKS1 の後継形式であり、LUKS1 の基本概念を引き継ぎつつ、メタデータ構造や拡張性を改善している。LUKS2 の on-disk format specification では、LUKS2 が LUKS1 の後継であり、既存の制約や問題を改善するために設計された形式であることが説明されている[8]。

パスフレーズ運用で重要なのは PBKDF である。PBKDF は Password-Based Key Derivation Function の略であり、パスフレーズから暗号鍵を導出する処理である。LUKS2 では Argon2 系の PBKDF が利用できる。Argon2 は、パスワードハッシュおよび proof-of-work 用の memory-hard function として RFC 9106 で規定されており、計算時間だけでなくメモリー使用量も攻撃コストに含める設計である[9]。

要素 意味 バックアップ媒体運用での意味
LUKS1 古いが互換性の高い LUKS 形式である。 古い環境やブートローダー互換性を重視する場合に候補になる。
LUKS2 現行の LUKS 形式であり、拡張性が高い。 新規の外付け媒体やバックアップ媒体では基本候補になる。
PBKDF2 古くから使われる鍵導出方式である。 互換性は高いが、現代的には Argon2 系より攻撃コスト設計が単純である。
Argon2 メモリーハードな鍵導出・パスワードハッシュ方式である。 長いパスフレーズと組み合わせることでオフライン攻撃耐性を高めやすい。
GRUB 互換性 起動時にブートローダーが解除する構成で問題になり得る。 バックアップ媒体では問題になりにくいが、root 暗号化では注意する。

パスフレーズについては、NIST SP 800-63B が示すように、長さを重視し、少なくとも 15 文字、最大長は少なくとも 64 文字を許容し、印字可能 ASCII 文字やスペースを受け入れ、文字種混在のような構成規則を強制しない方向が現代的である[10]。NIST のパスワード強度に関する解説でも、パスワード長が強度を特徴づける主要要因であり、短いパスワードは総当たり攻撃や辞書攻撃に屈しやすいとされている[11]。この考え方は、LUKS のようにオフライン攻撃を受け得る媒体暗号化では特に重要である。

6. root 暗号化、データ領域暗号化、バックアップ媒体暗号化は同じ問題ではない

LUKS の使い方は一つではない。ノート PC の root ファイルシステムを暗号化する場合、サーバーのデータ領域だけを暗号化する場合、外付けバックアップ媒体を暗号化する場合では、問題の中心が異なる。Red Hat の LUKS 文書は、LUKS がブロックデバイス暗号化に使われ、起動時にパスフレーズで暗号化パーティションを開く構成を説明している[12]。Debian の cryptsetup initramfs 文書は、暗号化 root ファイルシステムから起動するには、カーネル初期化後かつ通常の OS 起動前に root デバイスを準備する initramfs が必要であることを説明している[13]。

しかし、バックアップ媒体では、起動前解除や initramfs の問題は通常中心ではない。むしろ重要なのは、媒体を接続したときだけ開き、バックアップ取得後に閉じ、保管時には暗号化状態に戻すことである。ArchWiki の dm-crypt 解説も、cryptsetup が dm-crypt を使って暗号化デバイスを作成・管理するコマンドラインツールであることを整理している[14]。

用途 中心問題 設計方針
ノート PC の root 暗号化 紛失時の本体データ保護と起動チェーンの信頼性である。 Secure Boot、initramfs、/boot、TPM なども関係する。
サーバーの root 暗号化 再起動時に遠隔から解除できるかである。 手動解除、dropbear-initramfs、TPM、運用手順を検討する。
サーバーのデータ領域暗号化 機密データを保存状態で保護しつつサービス復旧できるかである。 root は通常起動し、機密領域を必要時に開く設計が現実的である。
バックアップ媒体暗号化 紛失・盗難・遠隔地保管・退役時の漏えい防止である。 接続時間を短くし、暗号化状態で保管する。

TPM や FIDO2 などを使った LUKS2 の自動解除は systemd-cryptenroll でも扱えるが、これは利便性と起動チェーンの信頼性をどう設計するかという別問題である[15]。バックアップ媒体においては、むしろ自動解除よりも、手動で開き、作業後に閉じる明示的な運用のほうが安全側に寄る。

7. 実用ワークフローは、初期検査から退役までを一つの手順体系にする

ここまでを実用手順に落とすと、媒体管理は一回限りの作業ではなく、媒体購入、物理ラベル付与、初期検査、LUKS2 暗号化、ファイルシステム作成、必要に応じた LUKS ヘッダーバックアップ、台帳登録、初回バックアップ、復元テスト、通常運用、月次確認、四半期復元訓練、年次棚卸し、退役更新までを含む手順体系になる。前回までの整理で重要だったのは、抽象的な「安全なバックアップ」ではなく、実際に人間が繰り返せる作業順序へ分解することである。媒体は壊れる。接続時に誤操作される。遠隔地に置くと最後に読めた日が曖昧になる。暗号化すると漏えいには強くなるが、鍵やヘッダーを失えば自分も読めなくなる。したがって、実用ワークフローは、暗号化、検査、検証、記録、保管、復元、退役を一連の運用として固定する必要がある。

段階 作業 目的
媒体導入 媒体を購入し、物理ラベルを貼り、型番、シリアル番号、容量、接続方式を確認する。 後から媒体を取り違えないようにする。
初期検査 S.M.A.R.T. 情報、short test、long test、可能なら全域読み書き検査を行う。 初期不良や輸送時ダメージを本番投入前に検出する。
暗号化 LUKS2 で初期化し、mapper デバイスを開き、ファイルシステムを作成する。 媒体流出時の情報漏えいを防ぐ。
復旧準備 長期運用するバックアップ媒体では、LUKS ヘッダーバックアップを取得し、媒体本体とは別に保管する。 ヘッダー破損による復元不能リスクを下げる。
台帳登録 媒体 ID、LUKS UUID、用途、パスフレーズ系統、保管場所、最終確認日を記録する。 復元時に媒体、鍵体系、ヘッダー、世代を対応づける。
バックアップ 接続、開錠、マウント、バックアップ、検証、アンマウント、LUKS close、取り外しを行う。 復号済み状態の時間を短くしつつバックアップを取得する。
保管 作業媒体、世代媒体、遠隔地媒体を分け、同じ場所に集中させない。 誤削除、盗難、火災、水害、ランサムウェアに備える。
定期検査 月次読み出し、S.M.A.R.T. 確認、checksum 検査、代表ファイル復元を行う。 静かな破損、媒体劣化、記憶混同を早期に検出する。
復元訓練 別媒体または別環境へ実際に復元し、ファイル、権限、DB、設定、サービス起動を確認する。 バックアップが存在するだけでなく実際に戻せることを確認する。
退役更新 異常媒体や古い媒体から新媒体へ移行し、旧媒体とヘッダーバックアップを対応づけて処分する。 壊れる前に復元可能性を新しい媒体へ移す。

7.1 初回セットアップ手順

初回セットアップでは、媒体をいきなり本番バックアップ先にしない。最初に物理ラベルを貼り、OS から見えるデバイス名、型番、シリアル番号、容量を確認し、S.M.A.R.T. と自己診断を実施する。そのうえで LUKS2 で初期化し、ファイルシステムを作成し、LUKS ヘッダーを別保管し、媒体台帳へ登録する。ここまで行って初めて、その媒体はバックアップ運用に参加できる。

順番 作業 確認点
1 媒体を購入する。 容量、接続方式、用途、保証、筐体の安定性を確認する。
2 物理ラベルを貼る。 媒体 ID を人間が見て分かる形で付与する。
3 S.M.A.R.T. 情報を取得する。 型番、シリアル番号、使用時間、エラー、温度を確認する。
4 short test と long test を実行する。 初期不良、代替セクター、pending sector、uncorrectable error を確認する。
5 問題がなければ LUKS2 で暗号化する。 対象デバイスを取り違えていないことを確認してから実行する。
6 mapper デバイス上にファイルシステムを作成する。 ext4、XFS、Btrfs など、運用に合う形式を選ぶ。
7 長期運用する場合は LUKS ヘッダーバックアップを取得する。 媒体本体だけに置かず、別の暗号化保管先へ保存する。
8 媒体台帳へ登録する。 媒体 ID、LUKS UUID、用途、鍵系統、保管場所、作成日を記録する。
9 初回バックアップを取得する。 終了コード、ログ、容量、代表ファイル読み出しを確認する。
10 復元テストを行う。 別ディレクトリまたは別媒体へ実際に戻せることを確認する。
11 通常運用へ移行する。 台帳に初回確認日と状態を記録する。

以下の初期化手順は、対象パーティションの既存データを破壊する。実行前に lsblk、blkid、smartctl などで対象デバイスを確認し、/dev/sdX1 を実際のバックアップ用パーティションに置き換える必要がある。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# Confirm the target device before running destructive commands.
# Replace /dev/sdX1 with the actual backup partition.
sudo cryptsetup luksFormat /dev/sdX1

# Open the LUKS container as /dev/mapper/backupdisk.
sudo cryptsetup open /dev/sdX1 backupdisk

# Create an ext4 filesystem inside the decrypted mapper device.
sudo mkfs.ext4 /dev/mapper/backupdisk

# Optionally back up the LUKS header to recover from header damage.
# Strongly recommended for long-term backup media.
# Store this file separately from the encrypted medium.
sudo cryptsetup luksHeaderBackup /dev/sdX1 --header-backup-file backupdisk-luks-header.img

この手順で特に危険なのは、luksFormat の対象デバイスを間違えることである。したがって、実行前には lsblk、blkid、smartctl で対象媒体を確認し、媒体 ID とシリアル番号を台帳と照合する。暗号化は漏えい対策であると同時に、誤操作時の復旧難度を上げるため、初期化作業は最も慎重に行う。

LUKS ヘッダーバックアップは、LUKS 媒体を作成するための必須手順ではない。しかし、バックアップ媒体を長期運用する場合は、ヘッダー破損時の復旧可能性を確保するために強く推奨される。ヘッダーバックアップは、暗号化媒体本体と同じ場所に置かず、別の暗号化媒体や安全な保管場所に分離して保存する。ただし、ヘッダーバックアップは鍵スロット情報を含むため、パスフレーズと組み合わさると復号可能性に関わる機密物として扱う。

7.2 毎回のバックアップ手順

毎回のバックアップでは、媒体を接続し、LUKS を開き、マウントし、バックアップを実行し、検証し、アンマウントし、LUKS を閉じ、取り外し、台帳を更新する。この一連の流れを途中で止めると、復号済み状態の放置、マウントしっぱなし、ログ未確認、台帳未更新が起こる。したがって、毎回の手順は短くても固定化する必要がある。

順番 作業 確認点
1 媒体を接続する。 対象媒体 ID、デバイス名、LUKS UUID を確認する。
2 LUKS を開く。 正しいパスフレーズ系統で開けるか確認する。
3 ファイルシステムをマウントする。 想定したマウントポイントに接続されているか確認する。
4 バックアップを実行する。 rsync、borg、restic などのコマンドと対象範囲を確認する。
5 終了コードを確認する。 正常終了か、許容可能な警告か、失敗かを判定する。
6 ログを確認する。 I/O error、permission denied、途中失敗、容量不足を確認する。
7 代表ファイルを読み出す。 実際にバックアップ先のファイルを開けるか確認する。
8 アンマウントする。 書き込み完了後に安全に切り離す。
9 LUKS を閉じる。 mapper デバイスが消えていることを確認する。
10 媒体を取り外す。 復号済み状態やマウント状態で外さない。
11 台帳に実施日を記録する。 最終バックアップ日、最終読み出し確認日、異常有無を更新する。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
# Open the encrypted backup medium.
sudo cryptsetup open /dev/sdX1 backupdisk

# Mount the decrypted filesystem.
sudo mount /dev/mapper/backupdisk /mnt/backup

# Run the backup and verify the result before unmounting.
# Example: rsync, borg, restic, checksum verification, or restore test.

# Unmount the filesystem after backup and verification.
sudo umount /mnt/backup

# Close the LUKS container so the medium returns to an encrypted-at-rest state.
sudo cryptsetup close backupdisk

この手順の中核は、バックアップ媒体を常時接続しないことである。常時接続されたバックアップ媒体は、誤削除、マルウェア、ランサムウェア、電源障害、ファイルシステム破損、経年劣化の影響を受ける。全メディア暗号化をしていても、復号済みでマウントされたままなら、暗号化による防御はほとんど効かない。

7.3 月次作業手順

月次作業では、日常バックアップとは別に、媒体の健康状態、重要ファイルの整合性、世代保存、遠隔地保管、台帳更新を確認する。日常バックアップは直近復旧には有効だが、破損や誤削除に遅れて気づいた場合には弱い。月次世代は、直近同期では救えない障害に対する復元点になる。

順番 作業 確認点
1 S.M.A.R.T. を確認する。 代替セクター、pending sector、uncorrectable error、温度、使用時間を見る。
2 重要ディレクトリの checksum 検査を行う。 静かな破損や転送ミスを検出する。
3 月次世代を作成する。 直近同期とは別に、固定された復元点を残す。
4 遠隔地保管媒体を更新する。 自宅や同一拠点の災害に備える。
5 台帳を更新する。 最終バックアップ日、最終確認日、保管場所、状態を記録する。

月次作業では、すべてのファイルに対する完全検証を毎回行う必要はないが、重要ファイル、設定ファイル、データベースダンプ、WordPress 関連ファイル、鍵管理に関わる文書などは重点的に確認する。負荷の重い検証は月次や四半期へ寄せ、日常バックアップでは軽量検証に留めると、継続しやすい。

7.4 四半期作業手順

四半期作業では、バックアップ媒体が読めるかではなく、実際に復元できるかを確認する。復元訓練では、本番バックアップを壊さないように復元確認用媒体や別ディレクトリを使い、主要ファイル、権限、所有者、データベース、設定ファイル、サービス起動まで確認する。

順番 作業 確認点
1 復元用の別媒体または別領域を用意する。 本番バックアップ媒体を破壊しない検証環境を確保する。
2 バックアップから実際に復元する。 ファイルが戻るか、必要な世代を選べるかを確認する。
3 主要ファイル、DB、設定を確認する。 WordPress、MySQL、設定ファイル、権限、所有者を確認する。
4 復元手順の不足を修正する。 手順書、台帳、パスフレーズ系統、保管場所の曖昧さを潰す。
5 古い媒体の退役候補を確認する。 異常兆候、使用年数、読み出し失敗、容量不足を基準に判断する。

復元訓練をしていないバックアップは、バックアップが存在すると思い込んでいる状態に近い。四半期ごとに少なくとも代表的な復元を実施すれば、パスフレーズの記憶混同、ヘッダーバックアップの所在不明、媒体台帳の記載漏れ、復元コマンドの忘却を早期に発見できる。

7.5 年次棚卸しと退役更新手順

年次作業では、すべての媒体を棚卸しし、保管場所、LUKS UUID、最終確認日、状態、退役候補を確認する。バックアップ媒体は壊れてから交換するのではなく、壊れる前に復元可能性を新媒体へ移す。異常が出た媒体は修理して使い続けるのではなく、救えるうちに退役させる。

対象 入れ替え・退役目安 判断理由
常用外付け HDD 3〜5 年を目安にする。 接続頻度と通電時間が長く、故障や誤操作の影響を受けやすい。
遠隔地保管 HDD 5 年前後を目安にし、定期読み出しを前提にする。 保管中も機械部品や磁気保持の問題が残る。
SSD 書き込み量、通電時間、予備領域、media error を見て判断する。 HDD と劣化指標が異なるためである。
USB メモリー 長期保存には原則使わない。 品質差が大きく、バックアップの最終防衛線にしにくい。
SD カード 長期保存には原則使わない。 小型で紛失しやすく、長期保管媒体として不安定である。

退役時には、媒体本体だけでなく、その媒体に対応する LUKS ヘッダーバックアップも確認する。媒体を処分しても、古いヘッダーバックアップと古いパスフレーズが残っていれば、過去の鍵状態が残存する可能性がある。したがって、退役は「媒体の処分」ではなく、「媒体、ヘッダー、台帳、保管記録の整合を閉じる作業」である。

7.6 最小構成としての現実解

個人運用や小規模サーバーで過剰に複雑にしないなら、日常バックアップ、月次 LUKS 暗号化外付け HDD、遠隔地保管、重要ファイルの追加クラウド保管、月次読み出し確認、四半期復元訓練、台帳管理、3〜5 年程度の媒体更新を組み合わせる構成が現実的である。ここでは、高価な専用装置よりも、継続できる手順、暗号化された媒体、確実な復元訓練を優先する。

要素 推奨 理由
日常バックアップ rsync、borg、restic などでローカルまたは NAS へ取得する。 直近の誤削除や作業ミスから素早く戻すためである。
月次バックアップ LUKS 暗号化外付け HDD へ固定世代を作る。 遅れて気づく破損や同期ミスへ備えるためである。
遠隔地保管 LUKS 暗号化 HDD を月次または四半期で入れ替える。 火災、盗難、災害、拠点障害に備えるためである。
クラウド 重要ファイルのみ暗号化して追加保管する。 物理媒体喪失時の補助線にするためである。
検証 月次で読み出し確認し、四半期で復元訓練する。 バックアップが復元可能であることを確認するためである。
台帳 Markdown、CSV、plain text で媒体 ID、LUKS UUID、保管場所、確認日を管理する。 復元時に媒体と鍵体系を対応づけるためである。
退役 異常検出時、または 3〜5 年を目安に交換する。 壊れてからではなく壊れる前に復元可能性を移すためである。

この構成は、完璧な理想形ではなく、運用負荷と安全性のバランスを取った現実解である。重要なのは、全メディア暗号化を採用しながら、鍵喪失、ヘッダー破損、媒体劣化、世代不足、復元手順忘却という別種の失敗を同時に潰すことである。

このサイクルによって、LUKS は単なる暗号化ツールではなく、媒体管理全体の中に組み込まれた安全装置になる。実用手順としては、媒体購入、初期検査、LUKS2 暗号化、必要に応じたヘッダーバックアップ、台帳登録、バックアップ取得、検証、LUKS close、分散保管、定期読み出し、復元訓練、退役更新を、ひとまとまりの運用として繰り返すことが必要である。

8. 物理媒体管理とは媒体の健康管理ではなく、復元可能性の管理である

物理媒体管理の基本思想は、媒体を信じないことである。HDD も SSD も、買った直後に初期不良を持つ可能性があり、運用中に劣化し、保管中に読めなくなり、USB ブリッジやケーブルや電源の問題で不安定になり得る。したがって、媒体管理の目的は「正常そうな媒体を保有すること」ではなく、「必要な時点で必要なデータを復元できる状態を維持すること」である。

このため、媒体は役割ごとに分ける必要がある。日常的に接続する媒体は、誤削除、ランサムウェア、ファイルシステム破損、電源断の影響を受けやすい。一方、遠隔地保管媒体は、更新頻度が低く、最後に読めた日が不明になりやすい。媒体の役割が違えば、検査周期、保管場所、暗号化方式、パスフレーズ体系、台帳項目も違う。

媒体種別 役割 管理上の焦点
作業用バックアップ媒体 日常的なバックアップ取得に使う。 接続時間、ログ確認、誤削除防止を重視する。
世代保存用媒体 月次、四半期、年次の復元点を残す。 世代の固定、書き換え抑制、保管状態を重視する。
遠隔地保管媒体 火災、盗難、災害に備える。 暗号化、保管場所、最終読み出し日を重視する。
復元確認用媒体 実際の復元テストに使う。 本番バックアップを壊さず検証できることを重視する。
退役前確認媒体 古い媒体から新媒体へ移行する際に使う。 読めるうちに移行し、退役後の漏えいを防ぐことを重視する。

この役割分離によって、バックアップ媒体を一つの曖昧な箱として扱うのではなく、復元目的別の構成要素として管理できるようになる。

9. 媒体は使用前に検査し、使用中も読み出し可能性を確認する

新しい媒体を買ったら、すぐに本番バックアップを置くのではなく、初期検査を行う必要がある。最低限、認識状態、型番、シリアル番号、容量、S.M.A.R.T. 情報を確認し、short test と long test を実行する。smartmontools の FAQ は、smartctl -t short による short self-test の実行例を示しており、smartctl はディスク状態確認の基本工具になる[16]。smartctl の man page でも、long test は short test より長く詳細な extended self-test として説明されている[17]。

ただし、S.M.A.R.T. が正常であれば安全という意味ではない。S.M.A.R.T. は有力な兆候を与えるが、復元可能性の保証ではない。したがって、媒体管理では、S.M.A.R.T. を「異常を発見するための信号」として扱い、「正常なら信じてよい証明」として扱わない。

段階 確認内容 判断
購入直後 lsblk、smartctl -a、型番、シリアル、容量を確認する。 媒体台帳に登録できる状態かを見る。
初期検査 short test、long test、可能なら全域読み書き検査を行う。 初期不良や輸送ダメージを早期に発見する。
バックアップごと マウント、書き込み、代表ファイル読み出しを確認する。 今回のバックアップが最低限読めるかを見る。
月次 S.M.A.R.T.、重要ファイルの checksum、ログを確認する。 静かな破損や劣化兆候を検出する。
四半期または年次 別環境への復元テストを実施する。 本当に復元できることを確認する。

HDD では reallocated sector、current pending sector、offline uncorrectable、I/O error、long test 失敗が重要な退役信号になる。SSD では総書き込み量、予備領域、media error、温度、使用時間を見る。媒体の種類によって指標の意味は違うが、共通する原則は、怪しい媒体をバックアップの最終防衛線にしないことである。

10. バックアップは取得後の検証まで含めて完了する

バックアップは、コピー処理が終わった時点では完了していない。バックアップが完了したと言えるのは、少なくとも、処理が成功し、ログに致命的なエラーがなく、代表ファイルが読め、必要な時点に戻れる見込みが確認できた時点である。rsync を使う場合、終了コード、ログ、差分、ファイル数、容量、必要に応じた checksum 確認を組み合わせる必要がある。rsync の manpage は checksum negotiation や差分判定の仕組みを説明しており、コピーが単純なファイル複製以上の処理であることを示している[18]。

重要ファイルの確認では、sha256sum のような SHA-2 digest の利用も有効である。GNU Coreutils の sha2 utilities は、sha224sum、sha256sum、sha384sum、sha512sum が SHA-2 ハッシュを計算するコマンド群であることを説明している[19]。ただし、毎回全ファイルの checksum verification を行うと重くなるため、日常バックアップでは軽量検証、月次や四半期では強めの検証という階層化が現実的である。

検証項目 目的 頻度
終了コード確認 バックアップコマンドが正常終了したかを見る。 毎回行う。
ログ確認 I/O error、permission denied、途中失敗を検出する。 毎回行う。
代表ファイル読み出し 実際に読めるファイルがあることを確認する。 毎回行う。
checksum 確認 重要ファイルやアーカイブの整合性を確認する。 月次または重要世代で行う。
別環境復元 実際に戻せることを検証する。 四半期または年次で行う。

BorgBackup は重複排除、圧縮、認証付き暗号化を備えたバックアッププログラムであり、信頼しきれない保存先へのバックアップにも適する設計になっている[20]。Borg の rcreate 文書は、バックアップを暗号化・署名して第三者が読んだり改ざんしたりできないようにする一方、鍵をリポジトリー外へバックアップし、鍵を車内に置き忘れるような状態を避けるべきだと警告している[21]。これは LUKS ヘッダーと同じく、暗号化されたバックアップでは鍵管理が復元可能性の一部になることを示している。

restic もまた暗号化されたバックアップリポジトリーとスナップショット管理を提供する。restic の文書は暗号化、repository key、check、repair などを扱い[22]、snapshot が特定時点のディレクトリ構造を表す JSON 文書として保存されることを説明している[23]。このようなツールを使う場合でも、ツールが存在するだけでは不十分であり、復元訓練、鍵管理、リポジトリー検査が必要になる。

11. 世代管理はコピー数ではなく、戻れる時点の設計である

バックアップでは「何個コピーがあるか」よりも「どの時点へ戻れるか」が重要である。直近コピーだけでは、誤削除、壊れた状態の同期、ランサムウェアによる暗号化、設定ミスの伝播に弱い。直近の同期バックアップだけを持っている場合、壊れた状態を正しく複製してしまうため、復元可能性は低い。

NIST NCCoE のランサムウェア対策文書は、重要ファイルについて 3 つのコピーを持ち、2 種類の媒体に置き、1 つをオフサイトに置く 3-2-1 ルールを、データ損失からの復旧可能性を高める方法として説明している[24]。ただし、現代のランサムウェア環境では、3-2-1 は出発点であり、オフライン性、暗号化、改ざん困難性、復元テストが加わらなければ不十分である。CISA の StopRansomware Guide も、ランサムウェア攻撃者はアクセス可能なバックアップを探して削除または暗号化しようとするため、重要データのバックアップをオフラインで維持し、可用性と完全性を定期的にテストすることを推奨している[25]。

世代 目的 媒体管理上の意味
日次 直近の誤削除や作業ミスから戻す。 復元速度を重視し、接続頻度が高くなる。
週次 数日前から数週間前の破損に備える。 同期ミスや遅れて気づく障害に対応する。
月次 気づくのが遅れた破損や設定ミスに備える。 オフライン媒体として残す価値が高い。
四半期または半期 長期保管と災害対策に使う。 遠隔地保管の候補になる。
年次 最終防衛線として残す。 書き換えず、読み出し確認を重視する。

世代管理は「コピーの多さ」ではなく、「破損がいつ発生し、いつ気づくか」という時間差への対策である。つまり、時間方向に分散した復元点を作ることが、バックアップ戦略の中核になる。

12. 全メディア暗号化は、媒体流出を通常事故に変えるための戦略である

全メディア暗号化とは、日常バックアップ媒体、月次媒体、遠隔地媒体、復元検証用媒体、退役前媒体まで、原則としてすべて暗号化する方針である。この方針は過剰ではない。むしろ、外付け媒体や遠隔地媒体が本体 PC より物理的に流出しやすいことを考えると、暗号化は自然な基本方針である。

特に遠隔地保管媒体は、自分の直接管理から離れる。家族宅、貸金庫、オフィス、別拠点、クラウドと同期する中継媒体など、保管場所が自宅やサーバー室の外に出るほど、紛失や盗難の確率は増える。LUKS により媒体単体で読めない状態を作っておけば、媒体流出は「情報漏えい事故」ではなく「暗号化媒体の紛失事故」に近づく。

対象媒体 暗号化する理由 運用上の注意
作業用外付け HDD 持ち運びや取り外し時に紛失し得るためである。 接続時だけ開き、作業後は必ず閉じる。
月次・年次媒体 長期保管中に管理状態が曖昧になりやすいためである。 台帳で保管場所と最終確認日を管理する。
遠隔地保管媒体 自分の直接管理外に置くためである。 パスフレーズとヘッダーは媒体本体と同居させない。
復元確認用媒体 一時的に本番データの複製が置かれるためである。 検証後の消去または再初期化も管理する。
退役媒体 廃棄、譲渡、保管忘れによる漏えいを避けるためである。 媒体本体とヘッダーバックアップを対応づけて処分する。

NIST SP 800-88 Rev. 1 は、媒体の sanitization を、対象データへのアクセスを一定の努力水準で実行不能にするプロセスとして扱い、媒体の処分、再利用、移転時に情報機密性を保つ判断を支援する文書である[26]。暗号化媒体管理は sanitization そのものではないが、暗号化しておくことで、媒体退役時の漏えいリスクを大きく下げられる。

13. しかし全メディア暗号化は復元不能リスクを増やす

暗号化は、正しい鍵がなければ誰にも読めない状態を作る。これは攻撃者だけでなく、自分にも適用される。したがって、全メディア暗号化は、紛失時の漏えいリスクを下げる一方で、鍵喪失時、ヘッダー破損時、台帳不備時の復元不能リスクを上げる。

暗号化していない媒体なら、ファイルシステムが壊れていても一部サルベージできる可能性がある。しかし LUKS では、LUKS ヘッダー、キースロット、パスフレーズ、マスターキーの関係が壊れると、データ本体が物理的に残っていても復号できない。これは暗号化の欠点ではなく、暗号化の本質である。

リスク 発生条件 対策
パスフレーズ喪失 長期未使用、記憶混同、事故、病気で入力不能になる。 系統別設計、定期開錠確認、緊急用キースロットを用意する。
ヘッダー破損 媒体先頭破損、誤書き込み、luksFormat 誤実行で起こる。 長期バックアップ媒体では、LUKS ヘッダーバックアップを別媒体へ保存する。
旧ヘッダー残存 パスフレーズ削除後に古いヘッダーバックアップが残る。 鍵変更時にヘッダーバックアップも更新・失効管理する。
台帳不備 媒体 ID、LUKS UUID、保管場所、鍵系統が不明になる。 媒体台帳を作り、変更時に更新する。
復元手順忘却 年単位で復元していないため手順が再現できない。 復元訓練を定期作業に含める。

したがって、全メディア暗号化は「暗号化して終わり」ではない。暗号化媒体は、鍵、ヘッダー、台帳、世代、検証、復元訓練と一体で管理しなければならない。

14. 記憶パスフレーズを主系にする戦略は合理的だが、記憶だけに賭けてはならない

鍵喪失を避けるために、自身の高い記憶力を活かして長いパスフレーズを記憶し、それを主系として使う戦略は合理的である[27]。物理的な鍵ファイル、紙のメモ、USB キー、パスワードマネージャーだけに依存しないため、災害時や環境変更時にも、自分が入力できれば復旧できる。

しかし、記憶力が高いことは、記憶が絶対に失われないことを意味しない。事故、病気、加齢、睡眠不足、ストレス、長期未使用、似たパスフレーズの混同は起こり得る。また、自分以外が復元する必要がある場合、記憶だけの鍵管理は継承不能である。したがって、記憶パスフレーズは主系として使い、非常時の安全弁を別に設けるべきである。

管理方式 利点 欠点
記憶パスフレーズ主系 物理鍵を失っても本人が覚えていれば復旧できる。 本人の記憶と入力能力に依存する。
紙の緊急鍵 本人が入力不能でも復元できる可能性がある。 盗難、紛失、保管場所漏えいのリスクがある。
鍵ファイル 長く強い鍵を使いやすい。 鍵ファイルそのものを失うと復元不能になる。
パスワードマネージャー 媒体ごとに異なる鍵を管理しやすい。 マネージャー自体が単一障害点になる。
完全同一パスフレーズ 忘れにくく運用が単純である。 漏えい時に全媒体が危険になる。

ここで重要なのは、「記憶に頼るか、頼らないか」という二択ではない。実用解は、記憶を主系にしつつ、LUKS の複数キースロット、ヘッダーバックアップ、封緘した緊急復旧手段、媒体台帳を組み合わせることである。

15. 全媒体同一パスフレーズではなく、系統別パスフレーズが現実解である

全メディアを暗号化するとき、すべての媒体を完全に同じパスフレーズで開けるようにするのは単純である。しかし、漏えい時の被害範囲が最大化する。逆に媒体ごとに完全に異なるパスフレーズを使うと、被害範囲は限定できるが、記憶、台帳、復元作業が重くなる。したがって、現実的には「媒体ごと」ではなく「役割ごと」にパスフレーズ系統を分けるのが妥当である。

系統 対象 狙い
Daily 系 日常バックアップ媒体である。 頻繁に入力するため、確実に記憶できる主パスフレーズにする。
Monthly 系 月次・世代保存媒体である。 日常系とは分離し、直近媒体漏えい時の波及を抑える。
Offsite 系 遠隔地保管媒体である。 自分の管理外に出る媒体を別系統にする。
Archive 系 年次・長期保存媒体である。 長期保管に合わせて、開錠確認と緊急復旧手段を重視する。
Test 系 復元確認用媒体である。 一時媒体が本番系の鍵体系を汚染しないようにする。

この方式なら、完全個別管理より覚えやすく、完全共通より被害範囲を限定できる。パスフレーズには、公開済みの文章、ブログタイトル、生年月日、住所、単純な媒体名、年月の付加などを使わない。自分には自然に再現でき、他人には推測しにくく、レスキュー環境でも入力できる ASCII ベースの長いフレーズが望ましい。

16. 媒体台帳は、暗号化媒体の復元可能性を維持するための索引である

暗号化媒体では、台帳の重要性がさらに増す。平文媒体なら、接続して中身を見ればある程度内容を推測できる。しかし LUKS 媒体では、開けなければ中身は見えない。どの媒体がどの世代で、どの LUKS UUID を持ち、どのパスフレーズ系統で、どのヘッダーバックアップに対応し、どこに保管されているかを記録しておかなければ、復元時に詰まる。

台帳項目 記録する理由 例
媒体 ID 人間が物理媒体を識別するためである。 BK-HDD-001
型番・シリアル番号 物理媒体と OS 上の認識を対応づけるためである。 smartctl の出力を記録する。
LUKS UUID 暗号化コンテナーを識別するためである。 cryptsetup luksUUID の値を記録する。
パスフレーズ系統 どの記憶体系で開けるかを示すためである。 Daily、Monthly、Offsite など。
ヘッダーバックアップ保管先 ヘッダー破損時に復旧できるようにするためである。 別暗号化媒体、封緘保管、金庫など。
最終バックアップ日 どの時点まで戻れるかを示すためである。 2026-05-09
最終読み出し確認日 媒体が実際に読めた最新日を示すためである。 2026-05-09
保管場所 分散保管と棚卸しのためである。 自宅、別室、遠隔地、貸金庫など。
状態 稼働中、要注意、退役予定、退役済みを区別するためである。 Active、Warning、Retired など。

媒体台帳は、秘密情報そのものを平文で書く場所ではない。パスフレーズそのものではなく、パスフレーズ系統、媒体 ID、UUID、保管場所、最終確認日を管理する。これにより、情報漏えいを増やさずに復元可能性を高められる。

17. 接続時間を短くし、復号済み状態を長く放置しない

全メディア暗号化を行っても、媒体を接続し、LUKS を開き、ファイルシステムをマウントしたまま放置すれば、暗号化の効果は大きく下がる。復号済み状態の媒体は、OS から通常のファイルシステムとして見えるため、誤削除、マルウェア、ランサムウェア、同期ミス、手動操作ミスの対象になる。

したがって、バックアップ媒体は「接続、開錠、マウント、バックアップ、検証、アンマウント、LUKS close、取り外し」までを一つの作業単位にする。これは単なる手順美学ではなく、攻撃可能時間と操作ミス可能時間を減らすための実務的な対策である。

状態 リスク 方針
未接続 物理紛失や盗難はあり得るが、オンライン攻撃は受けにくい。 暗号化状態で保管する。
接続済み・未解除 デバイス破壊や誤初期化はあり得る。 対象デバイス確認を徹底する。
LUKS 解除済み・未マウント mapper デバイスを誤操作する可能性がある。 必要な作業だけ行う。
マウント済み 誤削除、マルウェア、ランサムウェア、同期ミスの対象になる。 作業後すぐにアンマウントする。
保管中 長期劣化、紛失、所在不明化が起こる。 台帳と定期読み出しで管理する。

暗号化媒体の安全性は、暗号化方式だけで決まらない。復号済み時間をどれだけ短く保つかも、媒体管理の一部である。

18. 復元訓練はバックアップ運用の最後ではなく中心である

バックアップを取得しても、復元できなければ意味がない。暗号化媒体では、復元訓練の重要性はさらに高い。なぜなら、通常のファイルシステム確認に加えて、LUKS を開けるか、パスフレーズが正しいか、ヘッダーバックアップが有効か、別環境で cryptsetup が使えるか、ファイル所有者や権限が復元されるかを確認しなければならないからである。

確認項目 確認内容 意味
媒体認識 別マシンやレスキュー環境で媒体が見えるかを確認する。 復旧環境差を検出する。
LUKS 解除 記憶パスフレーズで開けるかを確認する。 鍵喪失や記憶混同を発見する。
マウント 復号後のファイルシステムがマウントできるかを確認する。 ファイルシステム破損を検出する。
ファイル復元 実際に別ディレクトリへ復元する。 バックアップが実用的に戻せるかを見る。
権限・所有者 uid、gid、パーミッション、ACL を確認する。 サービス復旧時の権限問題を避ける。
サービス復旧 DB、WordPress、設定ファイルなどを動作確認する。 ファイル単位ではなくサービス単位で復元できるかを見る。
所要時間 復元にかかる時間を測る。 RTO の現実性を確認する。
復元時点 どの時点に戻れたかを確認する。 RPO の現実性を確認する。

復元訓練をしていないバックアップは、バックアップが存在すると思い込んでいる状態に近い。特に LUKS 媒体では、正しいパスフレーズを覚えているか、ヘッダーがあるか、レスキュー環境で入力できるかを確認しなければ、暗号化による復元不能リスクを管理したことにならない。

19. 異常媒体は修理して使い続けるのではなく、救えるうちに退役させる

バックアップ媒体は、データを救う側である。したがって、怪しい媒体を粘って使うべきではない。S.M.A.R.T. long test の失敗、I/O error、pending sector、uncorrectable error、USB 切断の頻発、異音、異常発熱、fsck の頻発は、退役または即時移行の判断材料になる。

異常 判断 理由
Current Pending Sector 原則として退役候補にする。 読み出し不能になりかけているセクターがある可能性を示す。
Offline Uncorrectable 退役する。 訂正不能エラーはバックアップ媒体として致命的である。
long test 失敗 退役する。 媒体全体の信頼性が損なわれている。
I/O error 退役または即時移行する。 復元時に読めない可能性が高い。
USB 切断頻発 筐体、ケーブル、電源を切り分け、再発なら退役する。 媒体本体ではなく周辺要因でもバックアップ破損は起こる。
異音・異常発熱 退役する。 物理故障の兆候として扱うべきである。

暗号化媒体では、媒体劣化に加えてヘッダー領域の破損が致命的になる。したがって、退役時は、読めるうちに新媒体へ移行し、移行後に復元確認を行い、旧媒体と対応するヘッダーバックアップを台帳上で退役扱いにする。

20. 最終戦略は、全メディア暗号化、系統別パスフレーズ、ヘッダー管理、復元訓練の結合である

最終的な戦略は、次のように整理できる。第一に、外付けバックアップ媒体、遠隔地保管媒体、検証用媒体、退役前媒体を含め、全メディア暗号化を基本方針とする。第二に、LUKS2 を基本とし、必要に応じて互換性や起動要件を考慮する。第三に、長い記憶パスフレーズを主系にする。ただし、全媒体完全同一パスフレーズにはせず、Daily、Monthly、Offsite、Archive、Test のように系統別に分ける。第四に、長期運用するバックアップ媒体では LUKS ヘッダーをバックアップし、パスフレーズ変更時には古いヘッダーの失効も管理する。第五に、媒体台帳と復元訓練によって、実際に戻せることを確認する。

戦略要素 採用方針 理由
全メディア暗号化 採用する。 紛失、盗難、遠隔地保管、退役時の漏えいを抑えるためである。
LUKS2 新規媒体では基本とする。 現行形式であり、鍵管理と拡張性に優れるためである。
記憶パスフレーズ 主系として使う。 鍵ファイル喪失や保管物依存を下げられるためである。
完全同一パスフレーズ 避ける。 漏えい時の被害範囲が全媒体に広がるためである。
系統別パスフレーズ 採用する。 記憶可能性と被害範囲限定のバランスがよいためである。
複数キースロット 予備系として使う。 主パスフレーズ喪失や変更に備えられるためである。
ヘッダーバックアップ 長期運用するバックアップ媒体では強く推奨する。 LUKS ヘッダー破損が復元不能に直結し得るためである。
媒体台帳 必須とする。 媒体、鍵系統、保管場所、最終確認日を対応づけるためである。
復元訓練 定期作業にする。 バックアップが実際に復元可能であることを確認するためである。

巨大システムの事故がしばしば単一原因ではなく、複数の小さな見落とし、前提の固定化、連絡不全、検証不足、判断の遅れから発生するように、バックアップ障害もまた「コピーは取っていた」「媒体は保管していた」「暗号化はしていた」という個別要素の存在だけでは防げない[28]。意味は差異の読み取りから生まれるという観点に立てば、バックアップ運用においても、正常時と異常時、平文媒体と暗号化媒体、保管と復元、記憶と記録、媒体の健康と復元可能性の差異を読み分ける必要がある[29]。

この戦略の本質は、機密性と可用性を同時に設計することにある。暗号化だけなら漏えいには強くなるが、復元不能に弱くなる。鍵を単純化するだけなら復元は楽になるが、漏えい時の被害範囲が広がる。媒体を増やすだけならコピー数は増えるが、世代、保管場所、検証、退役がなければ復元可能性は保証されない。したがって、暗号化、記憶、台帳、ヘッダー、世代、検証を分離せず、一つの運用構造として結合する必要がある。

21. 結論

LUKS は、Linux における暗号化ブロックデバイス運用の実用標準である[30]。しかし、LUKS を理解するとは、cryptsetup のコマンドを覚えることではない。dm-crypt が暗号化処理を担い、LUKS がメタデータ、鍵スロット、ヘッダー、PBKDF 情報を管理し、そのヘッダーが復元可能性の中核になることを理解することである。

バックアップ・リカバリー戦略において、全メディア暗号化は妥当な基本方針である。外付け媒体や遠隔地媒体は本体より流出しやすく、退役時にも漏えいリスクを持つ。したがって、LUKS により保存状態の媒体を暗号化することは合理的である。しかし、暗号化は復元不能リスクも増やす。パスフレーズ、LUKS ヘッダー、キースロット、ヘッダーバックアップ、媒体台帳、復元訓練が揃っていなければ、守られた媒体は同時に自分にも読めない媒体になる。

自身の高い記憶力を活かし、長い記憶パスフレーズを主系にする戦略は有効である。ただし、全媒体完全同一パスフレーズにするのではなく、媒体の役割ごとに系統別パスフレーズを設計し、LUKS の複数キースロット、ヘッダーバックアップ、封緘した緊急復旧手段、媒体台帳を組み合わせるべきである。記憶力を鍵管理の中心に置くことは合理的だが、記憶だけに全復元可能性を賭けてはならない。

最終的に、暗号化媒体管理の実用解は、次の運用サイクルに集約される。媒体を購入し、初期検査し、LUKS2 で暗号化し、長期運用するバックアップ媒体ではヘッダーをバックアップし、台帳に登録し、バックアップを取得し、検証し、LUKS を閉じ、分散保管し、定期的に読み出し、復元訓練を行い、異常が出た媒体は退役させる。このサイクルを維持して初めて、バックアップは単なる複製ではなく、復元可能性として設計されたものになる。

参考文献

  1. id774, バックアップ・リカバリー戦略における物理媒体管理（2026-05-10）. https://blog.id774.net/entry/2026/05/10/4743/
  2. id774, バックアップとは復元可能性を設計することである（2026-05-07）. https://blog.id774.net/entry/2026/05/07/4728/
  3. Linux Kernel Documentation, dm-crypt. https://docs.kernel.org/admin-guide/device-mapper/dm-crypt.html
  4. cryptsetup, Frequently Asked Questions. https://gitlab.com/cryptsetup/cryptsetup/-/blob/main/FAQ.md
  5. cryptsetup(8), Linux manual page. https://man7.org/linux/man-pages/man8/cryptsetup.8.html
  6. cryptsetup-luksFormat(8), Linux manual page. https://man7.org/linux/man-pages/man8/cryptsetup-luksFormat.8.html
  7. cryptsetup-luksHeaderBackup(8), Linux manual page. https://man7.org/linux/man-pages/man8/cryptsetup-luksHeaderBackup.8.html
  8. LUKS2 On-Disk Format Specification. https://fossies.org/linux/cryptsetup/docs/on-disk-format-luks2.pdf
  9. RFC 9106, Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications. https://www.rfc-editor.org/rfc/rfc9106.html
  10. NIST SP 800-63B, Digital Identity Guidelines: Authentication and Lifecycle Management. https://pages.nist.gov/800-63-4/sp800-63b.html
  11. NIST, Strength of Passwords. https://pages.nist.gov/800-63-4/sp800-63b/passwords/
  12. Red Hat Documentation, Encrypting block devices using LUKS. https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/security_hardening/encrypting-block-devices-using-luks_security-hardening
  13. Debian Cryptsetup Initramfs integration. https://cryptsetup-team.pages.debian.net/cryptsetup/README.initramfs.html
  14. ArchWiki, dm-crypt/Device encryption. https://wiki.archlinux.org/title/Dm-crypt/Device_encryption
  15. systemd-cryptenroll(1), Arch manual pages. https://man.archlinux.org/man/systemd-cryptenroll.1
  16. smartmontools, FAQ. https://www.smartmontools.org/wiki/FAQ
  17. smartctl(8), Oracle manual page. https://docs.oracle.com/cd/E75431_01/html/E72377/smartctl-8.html
  18. rsync(1), rsync manpage. https://download.samba.org/pub/rsync/rsync.1
  19. GNU Coreutils, sha2 utilities. https://www.gnu.org/software/coreutils/manual/html_node/sha2-utilities.html
  20. BorgBackup Documentation. https://borgbackup.readthedocs.io/
  21. BorgBackup, borg rcreate. https://borgbackup.readthedocs.io/en/stable/usage/rcreate.html
  22. restic Documentation. https://restic.readthedocs.io/
  23. restic Documentation, References. https://restic.readthedocs.io/en/stable/100_references.html
  24. NIST NCCoE, Protecting Data from Ransomware and Other Data Loss Events. https://csrc.nist.gov/pubs/other/2020/04/24/protecting-data-from-ransomware-and-other-data-los/final
  25. CISA, #StopRansomware Guide. https://www.cisa.gov/sites/default/files/2025-03/StopRansomware-Guide%20508.pdf
  26. NIST SP 800-88 Rev. 1, Guidelines for Media Sanitization. https://csrc.nist.gov/pubs/sp/800/88/r1/final
  27. id774, あらためて WAIS-IV の結果を分析する（2026-03-16）. https://blog.id774.net/entry/2026/03/16/4016/
  28. id774, タイタニック号事故から読み解く巨大システム運用の本質（2026-05-02）. https://blog.id774.net/entry/2026/05/02/4656/
  29. id774, 意味は差異の読み取りから生まれる（2026-05-09）. https://blog.id774.net/entry/2026/05/09/4740/
  30. id774, デバイス管理とマウントの基本方針を整理する（2025-09-01）. https://blog.id774.net/entry/2025/09/01/2977/