暗号化ディスク運用手順を整理する

暗号化デバイスの運用は、暗号化領域を一度作成して終わる作業ではない。暗号化領域は、作成した瞬間には正しく見えても、時間が経つにつれて、媒体の劣化、 OS の更新、 cryptsetup の仕様変更、暗号方式の世代交代、鍵管理の変更、担当者や作業記憶の喪失によって、開けるかどうかが不確かになる。暗号化されていないディスクであれば、ファイルシステムが読める限り、部分的な救出ができる場合がある。しかし、暗号化デバイスでは、 LUKS ヘッダー、 key slot、 keyfile、非常用パスフレーズ、 crypttab、 fstab、 LVM 構成、マウント手順のどれかが失われるだけで、データ本体が残っていても復元できない状態になり得る。したがって、暗号化デバイスの運用とは、暗号化領域を作ることではなく、将来の時点でも正しく開き、読み取り、点検し、移行し、退役できる条件を維持することである。

前稿では、暗号化ディスクの長期運用を、 LUKS1 / LUKS2、 CBC-ESSIV / XTS、 PBKDF2 / Argon2id、 TrueCrypt 旧資産、媒体保全、移行、退役を含むレジリエンスの問題として整理した[1]。そこで確認したのは、古い暗号化方式を単純に危険とみなすのでも、すべてを最新方式へ置き換えれば安全と考えるのでも不十分だという点である。古い構成には過去の復元経路が残っている場合があり、現在の標準も将来はレガシーになる。暗号化ディスクの長期運用では、暗号方式の強度だけでなく、解除手段、ヘッダー保全、媒体識別、起動設定、点検周期、移行条件、退役条件を含めて管理する必要がある。本稿では、その設計論を具体的な操作手順へ落とし込み、初期生成、通常運用、情報確認、 key slot 管理、 keyfile、非常用パスフレーズ、ヘッダー保全、 crypttab、 fstab、 LVM、点検、復旧、退役までを一つの作業体系として整理する。

cryptsetup は、 dm-crypt を中心とする Linux の暗号化ブロックデバイスを扱うための主要なユーザー空間ツールである。cryptsetup project は、 LUKS、 plain dm-crypt、 loop-AES、 TrueCrypt / VeraCrypt 系、 BitLocker、 FileVault2 など複数形式を扱うツール群として cryptsetup を説明している[2]。一方、 Linux カーネル側の dm-crypt は、 device-mapper の crypt target として、 block device を透過的に暗号化する機構である[3]。つまり、利用者が実行するのは cryptsetup のコマンドであり、その結果としてカーネル側では dm-crypt による mapper device が作られる。この違いを分けて理解しておかないと、 LUKS ヘッダーを操作しているのか、 mapper を開いているのか、 filesystem をマウントしているのか、 LVM の論理ボリュームを見ているのかが曖昧になる。

本稿では、コマンドだけをまとめて列挙しない。各操作について、何を目的に実行するのか、実行前に何を確認するのか、期待される結果は何か、失敗した場合にどの層を疑うべきか、実行後に何を台帳へ残すべきかを説明する。暗号化デバイスの操作では、対象デバイスの取り違え、最後の key slot の削除、ヘッダー復元の誤用、 keyfile の喪失、 crypttab と fstab の不整合、 LVM と LUKS の上下関係の誤認が、直接的な復旧不能につながる。man page は cryptsetup の各 action を定義しているが、実運用では action の意味を、手順順序、台帳、復旧条件と結び付けて扱う必要がある[4]。したがって、本稿の目的は、 cryptsetup の使い方を断片的に覚えることではなく、暗号化デバイスを長期にわたって安全に扱うための運用手順を明文化することにある。

---

1. 暗号化デバイスは作成コマンドではなくライフサイクルで管理する

暗号化デバイスを扱うとき、最初に固定すべき考え方は、 luksFormat を実行することがゴールではないという点である。luksFormat は暗号化領域の始点であり、その後に open、 filesystem 作成、 mount、 key slot 管理、 header backup、 crypttab / fstab 連携、定期点検、移行、復旧、退役が続く。Arch や Debian の man page でも cryptsetup は暗号化デバイスの作成だけでなく管理全体を扱うコマンドとして整理されている[5][6]。したがって、本稿ではコマンドを単発操作ではなく、暗号化デバイスの寿命を通した管理単位として並べる。

このライフサイクルの考え方が必要になる理由は、暗号化デバイスでは、作成時点の成功と将来の復元可能性が同じではないからである。作成直後に mount できても、 keyfile を失えば開けなくなる。非常用パスフレーズを設定しても、どの key slot に対応するかを記録しなければ、整理時に誤って削除する可能性がある。ヘッダーバックアップを取得しても、対象 UUID や取得日を記録しなければ、復旧時にどの媒体へ戻すべきか判断できない。crypttab と fstab を設定しても、 LUKS UUID、 mapper 名、 filesystem UUID、 mount point の関係を分けて記録しなければ、起動時の失敗を切り分けにくい。つまり、暗号化デバイスの運用では、コマンドの成功だけでなく、後から同じ状態を再現できることが重要になる。

段階	主な操作	運用上の意味
初期生成	対象確認、 luksFormat、 open、 mkfs、 mount を実行する。	暗号化デバイスを安全に作成し、実際に使えるファイルシステムへ接続する段階である。
通常運用	open、 mount、同期、 umount、 close を固定手順として実行する。	日常利用で暗号化領域を開閉し、未同期データや mapper の残存を防ぐ段階である。
情報確認	luksDump、 status、 lsblk、 blkid を使う。	実体、 UUID、 LUKS version、 cipher、 key slot、 mapper 名を台帳と照合する段階である。
鍵管理	luksAddKey、 luksRemoveKey、 luksKillSlot、 test-passphrase を使う。	解除入口を追加、削除、確認し、不要な入口を残さない段階である。
保全と復旧	luksHeaderBackup、 luksHeaderRestore、 e2fsck、 fsck、 SMART 確認を扱う。	破損、設定喪失、媒体劣化に備え、復元条件を維持する段階である。
移行と退役	新媒体作成、データ同期、復元確認、旧媒体の役割変更、消去を行う。	古い方式を無期限に残さず、復元経路を保ちながら管理対象から外す段階である。

この表の各段階は、独立した作業ではなく相互に接続している。初期生成で対象デバイスを取り違えれば、その後のすべての手順が破綻する。通常運用で open と mount の関係を理解していなければ、復旧時に mapper が作られているのか、 filesystem が壊れているのかを切り分けられない。情報確認を台帳と結び付けなければ、 LUKS UUID、 filesystem UUID、 mapper 名、物理媒体の関係が時間とともに分からなくなる。鍵管理を誤れば、データ本体が無傷でも解除できなくなる。移行と退役を設計しなければ、古い構成を放置するか、必要な復元経路を誤って消すかのどちらかになりやすい。暗号化デバイスは、このような連鎖を前提に、作成から退役までを一つのライフサイクルとして管理する必要がある。

---

2. 作業前に対象デバイスを取り違えない

暗号化デバイスの初期生成や退役で最も重大な事故は、暗号方式の選択ミスではなく対象デバイスの取り違えである。特に luksFormat、 mkfs、 erase のような操作は、対象を誤ると既存データを失う。ここで重要なのは、/dev/sdX という名前を信用しないことである。/dev/sda、 /dev/sdb、 /dev/sdc のような名前は接続順や起動順で変わるため、昨日 /dev/sdb だった外付けディスクが今日も /dev/sdb であるとは限らない。Red Hat の LUKS 文書でも、暗号化対象を特定し、 UUID などを使って永続的に参照することが重要になる[7]。したがって、破壊的操作に進む前には、まず対象候補を一覧し、次に物理媒体としての識別子を確認し、最後に「このデバイスで間違いない」と判断できる状態を作る必要がある。

最初に使うべき確認コマンドは lsblk -f である。このコマンドは、ブロックデバイス、パーティション、ファイルシステム種別、 UUID、マウントポイントを階層構造で表示する。ここで確認するのは、対象候補の容量、既存のファイルシステム、すでにマウントされているかどうか、既存の LUKS 領域や LVM 構成が見えているかである。期待される結果は、作業対象にしようとしているディスクまたはパーティションが一覧上で明確に識別でき、かつ既存のマウントポイントやファイルシステムを誤って消そうとしていないと判断できることである。

lsblk -f の結果を見るときは、ディスク全体とパーティションを区別する必要がある。たとえば /dev/sdb はディスク全体を指し、/dev/sdb1 はその中の第 1 パーティションを指す。暗号化対象がディスク全体なのか、パーティションなのかを曖昧にしたまま luksFormat を実行してはならない。また、MOUNTPOINTS に値が出ている場合、その領域は現在利用中である可能性が高い。作業対象に見えるデバイスがすでにマウントされている場合は、暗号化や初期化に進まず、なぜマウントされているのかを先に確認する。

確認項目	見る場所	判断内容
容量	SIZE 列を見る。	想定しているディスク容量と一致するかを確認する。
ファイルシステム	FSTYPE 列を見る。	既存の ext4、vfat、crypto_LUKS、LVM2_member などがないかを確認する。
UUID	UUID 列を見る。	fstab、crypttab、台帳に記録すべき識別子を確認する。
マウント状態	MOUNTPOINTS 列を見る。	現在利用中の領域を誤って初期化しようとしていないかを確認する。

次に、物理媒体としての識別子を確認する。同じ容量の外付け HDD や SSD が複数ある場合、容量だけでは区別できない。/dev/disk/by-id には、ディスクのモデル名、シリアル番号、接続方式に基づく永続的なリンクが並ぶ。ここで期待される結果は、/dev/sdX という一時的な名前と、物理媒体に近い by-id 名を対応づけられることである。以後の台帳では、/dev/sdX だけでなく、by-id 名、LUKS UUID、ファイルシステム UUID、役割名を併記する。

/dev/disk/by-id の出力では、リンク先が ../../sdb や ../../sdb1 のように表示される。この対応を見ることで、現在 /dev/sdb として見えているデバイスが、どの物理媒体に対応しているかを確認できる。ここで by-id 名に想定外のモデル名やシリアルが出ている場合は、作業を止めるべきである。暗号化デバイスの手順では、コマンドを覚えることよりも、対象を確定することのほうが重要である。対象デバイスが確定していない状態では、luksFormat、mkfs、erase、luksHeaderRestore のような操作には進まない。

識別子	意味	使いどころ
/dev/sdX	現在の起動状態で割り当てられた一時的なデバイス名である。	一時的な確認には使えるが、長期記録や設定の根拠にはしない。
/dev/disk/by-id	モデル名やシリアル番号に基づく物理媒体寄りの識別子である。	同容量媒体を区別し、台帳に物理媒体として記録するために使う。
LUKS UUID	LUKS ヘッダーに付与された暗号化デバイスの識別子である。	crypttab や台帳で、暗号化領域を識別するために使う。
ファイルシステム UUID	暗号化デバイスを開いた後のファイルシステムに付与される識別子である。	fstab やマウント管理で、開いた後の領域を識別するために使う。

この章で実施すべき確認は、lsblk -f と /dev/disk/by-id の 2 つに絞ってよい。blkid や fdisk -l も有用だが、最初から多くのコマンドを並べると、どれが何を判断するためのものか分かりにくくなる。通常の作業では、まず lsblk -f で全体像を確認し、次に /dev/disk/by-id で物理媒体を確認する。この 2 つで対象が確定しない場合だけ、blkid で UUID を再確認し、fdisk -l でパーティション構造を詳しく確認する。最初から破壊的操作へ進むのではなく、対象を複数の識別子で確認できる状態を作ることが、暗号化デバイス運用の最初の安全策である。

次の手順へ進んでよい条件は明確である。作業対象の容量、物理媒体、デバイス名、パーティション、既存ファイルシステム、マウント状態が説明できること。台帳に記録する by-id 名、LUKS UUID または作成予定の役割名が決まっていること。現在利用中のシステムディスク、データディスク、バックアップディスクを誤って対象にしていないこと。この条件を満たして初めて、暗号化デバイスの初期生成やメンテナンスに進むことができる。

---

3. 暗号化デバイスを初期生成する

暗号化デバイスの初期生成で最初に決めるべきことは、暗号化対象をどの形式で作るかである。新規に作成する主系の暗号化デバイスでは、現在の標準として LUKS2 を明示するのが自然である。cryptsetup FAQ と LUKS 仕様は、 LUKS がヘッダー、 key slot、マスターキー管理を持つ形式であることを説明している[8][9]。LUKS2 は JSON メタデータや拡張可能な構造を持つため、新規作成では LUKS2 を明示し、古い LUKS1 と混在したときにも「これは意図して新形式で作った」という記録を残すほうがよい[10]。

暗号化デバイスを初期生成する基本コマンドは luksFormat である。この操作は確認コマンドではなく、対象デバイスに LUKS ヘッダーを作成する破壊的操作である。対象が既存データを含むディスクやパーティションであれば、そのデータは通常の手段では利用できなくなる。したがって、このコマンドは、前章で対象デバイス、容量、物理媒体、既存ファイルシステム、マウント状態を確認し、初期化してよい対象だと判断した後にだけ実行する。

このコマンドでは、/dev/sdX の部分を実際の対象デバイスまたは対象パーティションに置き換える。ここで /dev/sdX は説明用の仮名であり、そのまま実行してよい名前ではない。ディスク全体を暗号化するなら /dev/sdb のようなディスク名を対象にする場合があり、既存パーティションを暗号化するなら /dev/sdb1 のようなパーティション名を対象にする場合がある。どちらを選ぶかで後続の台帳、crypttab、fstab、復旧手順が変わるため、作業前に「ディスク全体を暗号化するのか」「パーティションを暗号化するのか」を明確にする。

luksFormat を実行すると、対話式で確認を求められ、初期解除用のパスフレーズ入力を求められる。ここで入力したパスフレーズは、LUKS の最初の key slot に登録される。key slot は、暗号化データ本体を直接表すものではなく、同じ暗号化デバイスを開くための解除入口である。つまり、初期生成直後の暗号化デバイスは、少なくとも 1 つの解除入口を持つ。通常運用で keyfile を使う場合でも、初期段階では非常用パスフレーズを 1 つ登録しておくと、keyfile の喪失や起動設定の破損に備えた手動解除経路を残せる。

初期生成後は、作成された LUKS ヘッダーを確認する。ここで使うコマンドは luksDump である。luksDump はデータを開く操作ではなく、LUKS ヘッダーに記録された形式、UUID、暗号方式、key slot、KDF などを確認するための情報確認コマンドである。期待される結果は、Version が 2 であり、UUID が表示され、少なくとも 1 つの key slot が有効になっていることである。

luksDump の結果では、まず Version を見る。新規主系として LUKS2 を意図した場合、ここが 2 になっていることを確認する。次に UUID を見る。この UUID は、暗号化デバイスを識別するための重要な情報であり、後で crypttab や台帳へ記録する。さらに Keyslots を見て、有効な key slot がいくつあるかを確認する。初期生成直後に 1 つだけ有効であれば、通常は初期パスフレーズ用の解除入口だけが存在している状態である。

確認項目	期待される状態	意味
Version	2 と表示される。	LUKS2 として作成できていることを示す。
UUID	LUKS UUID が表示される。	crypttab や台帳で暗号化デバイスを識別するために使う。
Data segments	crypt segment が表示される。	暗号化データ領域が定義されていることを示す。
Keyslots	少なくとも 1 つの key slot が有効である。	解除入口が存在し、暗号化デバイスを開ける状態であることを示す。
PBKDF	Argon2id などの KDF が表示される。	パスフレーズから解除用の鍵材料を導出する方式を示す。

この時点で台帳へ記録するべき情報は、対象デバイス、LUKS UUID、LUKS version、暗号方式、KDF、有効な key slot、初期生成日である。初期生成は一度実行すれば終わりではない。後続の keyfile 登録、非常用パスフレーズ追加、ヘッダーバックアップ、crypttab 登録、fstab 登録、マウント確認、復旧確認の基準点になるため、作成直後の状態を記録しておく必要がある。

3.1 keyfile を使う初期設計

サーバーや自動マウント構成では、毎回人間がパスフレーズを入力するのではなく、keyfile を解除手段にする場合がある。keyfile は、人間が覚える文字列ではなく、十分な乱数で生成したバイト列である。たとえば 32 byte の keyfile は 256 bit の秘密情報であり、ランダム生成されていれば短い人間のパスフレーズより強い。ただし、keyfile は失われると開けなくなり、漏洩すると開けられるため、保全対象であり同時に機微情報である。したがって、keyfile を使う場合は、作成、権限設定、LUKS への登録、解除確認、台帳記録を 1 つの手順として扱う。

本稿の例では、LVM 専用に見える名称ではなく、暗号化デバイスの用途に対応する中立的な例として /etc/cryptsetup-keys/crypt_name.key を用いる。実運用では、既存環境の keyfile 名をそのまま使ってよいが、ファイル名から対象や用途が分かること、複数の暗号化デバイスで誤用しないこと、台帳上で対象 LUKS UUID と対応付けられることを優先する。

まず keyfile を生成する。次のコマンドは、/dev/urandom から 32 byte の乱数を読み出し、/etc/cryptsetup-keys/crypt_name.key へ保存する。ここで作成されるファイルは通常の設定ファイルではなく、暗号化デバイスを開くための秘密情報である。既に同名の keyfile が存在する環境では上書きしてはならない。既存運用で使われている keyfile を上書きすると、その keyfile に依存している暗号化デバイスを開けなくなる可能性がある。

次に、keyfile の所有者と権限を設定する。所有者は root:root とし、権限は 0400 とする。これは、root だけが読み取れる状態にするためである。keyfile は暗号化デバイスの解除情報そのものなので、一般ユーザーから読める状態にしてはならない。期待される状態は、所有者が root、グループが root、読み取り権限が root のみに限定されていることである。

権限設定後、keyfile のサイズと識別用ハッシュを確認する。ここで確認するのは、keyfile の中身そのものではない。中身を表示する必要はなく、むしろ表示すべきではない。確認すべきことは、サイズが意図どおり 32 byte であること、後で同じ keyfile かどうかを照合できるようにハッシュを記録できることである。

wc -c の結果が 32 であれば、32 byte の keyfile として作成されている。sha256sum の結果は、keyfile 本体を台帳へ貼るためではなく、将来「このファイルは当時記録した keyfile と同じか」を確認するために記録する。keyfile のハッシュは keyfile そのものではないが、運用上の識別情報として扱い、台帳に記録する。

次に、作成した keyfile を LUKS デバイスへ追加する。ここで使うコマンドは luksAddKey である。luksAddKey は、既存の有効な解除手段で認証したうえで、新しい解除入口を key slot として追加する操作である。次のコマンドでは、新しい解除手段として /etc/cryptsetup-keys/crypt_name.key を登録する。実行時には、既存のパスフレーズ入力を求められる場合がある。これは、正当な管理者だけが key slot を追加できるようにするためである。

keyfile を追加した後は、keyfile で実際に解除できることを確認する。ここでは open –test-passphrase を使う。これは暗号化デバイスを実際に /dev/mapper 以下へ開くのではなく、指定した解除手段で開けるかだけを確認する操作である。期待される結果は、エラーなく終了することである。エラーが出る場合は、keyfile が登録されていない、対象デバイスが違う、keyfile のパスが違う、または権限や読み取り条件に問題がある。

最後に、luksDump で key slot が増えていることを確認する。初期パスフレーズだけの状態では有効 key slot が 1 つだったものが、keyfile を追加すると有効 key slot が増える。ここで重要なのは、key slot の数が増えたことだけではなく、どの slot が通常運用用の keyfile で、どの slot が非常用パスフレーズなのかを台帳化することである。LUKS の key slot は自動的に用途名を持つわけではないため、運用側が意味を記録しなければ、数年後にはどの解除入口を残すべきか判断できなくなる。

項目	記録する内容	目的
keyfile path	/etc/cryptsetup-keys/crypt_name.key のような実際の保存場所を記録する。	通常運用でどの解除情報を使うかを明確にする。
keyfile size	32 byte などのファイルサイズを記録する。	意図した長さの keyfile が維持されているか確認する。
owner and mode	root:root、0400 などを記録する。	keyfile が不用意に読まれない状態であることを確認する。
sha256	sha256sum の値を記録する。	将来、同じ keyfile かどうかを照合する。
key slot	keyfile に対応する key slot 番号を記録する。	不要 slot 削除時に通常運用用の解除入口を誤って消さないようにする。

keyfile を使う初期設計では、通常運用と非常時の解除経路を分けることが重要である。通常運用では keyfile を使って自動解除する。非常時には長いパスフレーズで手動解除できるようにする。このように 2 系統の解除入口を意図的に残しておけば、keyfile の喪失、起動設定の破損、crypttab の誤設定、initramfs の問題が起きた場合でも、手動で復旧できる可能性を残せる。一方、用途不明の古いパスフレーズ slot を残し続けると、解除入口が増え、管理不能になる。したがって、初期生成の時点から、通常運用用 keyfile、非常用パスフレーズ、削除対象の旧 slot を区別して管理する必要がある。

---

4. 初期生成後にファイルシステムを作成する

この章で扱うのは、luksFormat が完了した直後に一度だけ実施する初期化手順である。ここでは、暗号化デバイスを開き、復号後に現れる mapper device の上へファイルシステムを作成し、初回マウントまで確認する。これは日常的な通常運用手順ではない。特に mkfs.ext4 は既存ファイルシステムを作り直す破壊的操作であるため、通常運用時に繰り返し実行してはならない。

luksFormat 後の /dev/sdX は、LUKS ヘッダーを持つ暗号化ブロックデバイスであり、そのまま通常のファイルシステムとして使うことはできない。まず cryptsetup open によって、暗号化された block device を復号可能な mapper device として /dev/mapper 以下に作成する必要がある。cryptsetup-open の man page は、暗号化デバイスを開いて device mapping を作る action として open を説明している[11]。ここで指定する mapper 名は、後続の mkfs、mount、fstab、台帳で使う運用上の名前になるため、crypt_name のような一時名ではなく、用途に応じた安定した名前を付けるのがよい。

このコマンドの目的は、暗号化デバイスを復号し、/dev/mapper/crypt_name という操作対象を作ることである。期待される結果は、コマンドがエラーなく終了し、/dev/mapper/crypt_name が作成されることである。ここで /dev/sdX は暗号化済みの LUKS デバイス、crypt_name は mapper 名である。対象デバイスを誤ると別の LUKS デバイスを開こうとするため、実行前には前章の確認手順で対象を確定しておく。

上の例は keyfile 運用の場合である。パスフレーズのみで運用する場合は –key-file /etc/cryptsetup-keys/crypt_name.key を指定せず、sudo cryptsetup open /dev/sdX crypt_name のように実行し、対話式でパスフレーズを入力する。keyfile を使うか、パスフレーズを使うかは解除手段の違いであり、復号後に作成される mapper device の役割は同じである。

mapper device が作成されたら、ファイルシステムを作成する。ここで重要なのは、mkfs.ext4 の対象が暗号化前の /dev/sdX ではなく、復号後の /dev/mapper/crypt_name であることだ。mke2fs は ext 系ファイルシステムを作成するコマンドであり、暗号化そのものではなく、復号後のブロックデバイス上にファイルシステムを作る段階で使う[12]。この操作は初期化であり、既存データがある領域に対して実行するとファイルシステムを作り直してしまう。

このコマンドの期待される結果は、/dev/mapper/crypt_name 上に ext4 ファイルシステムが作成されることである。実行後、この mapper device は通常の ext4 ファイルシステムとしてマウントできる状態になる。逆に、ここで誤って /dev/sdX に対して mkfs.ext4 を実行すると、LUKS ヘッダーや暗号化構造を破壊する危険がある。したがって、mkfs.ext4 の対象は必ず /dev/mapper 以下であることを確認する。

次に、初回マウント用のマウントポイントを作成する。マウントポイントは、復号後のファイルシステムをディレクトリツリー上のどこに接続するかを示す場所である。これは暗号化処理ではなく、Linux のファイルシステム運用上の準備である。

このコマンドの期待される結果は、/mnt/crypt_name というディレクトリが存在する状態になることである。すでに存在している場合でも -p によりエラーにならない。マウントポイント名は mapper 名と対応させると台帳化しやすいが、実運用では /mnt/disk1、/mnt/backup、/srv/data のように用途が分かる名前を使うほうがよい。

最後に、作成した ext4 ファイルシステムをマウントする。ここでも対象は /dev/mapper/crypt_name である。マウントに成功すれば、暗号化デバイスを開き、復号後の領域にファイルシステムを作成し、そのファイルシステムを利用可能にするところまで確認できたことになる。

このコマンドの期待される結果は、/mnt/crypt_name 以下にファイルを書き込める状態になることである。初期生成手順としては、ここで簡単な読み書き確認を行い、その後に sync、umount、cryptsetup close まで実施して、開く、使う、閉じる流れが成立することを確認する。ただし、mkfs.ext4 は初回だけの操作であり、次章の通常運用では実行しない。

段階	コマンドの役割	期待される結果
open	LUKS デバイスを開き、/dev/mapper 以下に復号後の操作対象を作る。	/dev/mapper/crypt_name が作成される。
mkfs.ext4	復号後の mapper device 上に ext4 ファイルシステムを作る。	/dev/mapper/crypt_name を ext4 として利用できる状態になる。
mkdir	マウント先ディレクトリを作成する。	/mnt/crypt_name が存在する状態になる。
mount	復号後の ext4 ファイルシステムをディレクトリへ接続する。	/mnt/crypt_name 以下でファイルを読み書きできる状態になる。

この章の作業が完了したら、以後は暗号化デバイスを「作成済みのファイルシステムを持つ LUKS デバイス」として扱う。通常運用で必要なのは、暗号化デバイスを開き、既存ファイルシステムをマウントし、作業後にアンマウントして閉じることである。初期生成手順と通常運用手順を混同すると、通常運用中に誤って mkfs を実行するような重大事故につながる。

---

5. 通常運用では open、mount、sync、umount、close を固定する

この章で扱うのは、すでに LUKS 形式で初期生成され、ファイルシステムも作成済みの暗号化デバイスを日常的に使う手順である。通常運用では、mkfs.ext4 は実行しない。実施するのは、暗号化デバイスを開く、既存ファイルシステムをマウントする、必要な作業を行う、未書き込みデータを同期する、アンマウントする、最後に mapper device を閉じる、という一連の流れである。cryptsetup-close は mapper device を閉じる action であり、ファイルシステムの umount とは別の段階である[13]。

最初に、暗号化デバイスを開く。この操作は、暗号化された /dev/sdX から、復号後の /dev/mapper/crypt_name を作る段階である。ここでは keyfile を使う例を示しているが、パスフレーズ運用の場合は –key-file を付けずに実行し、対話式でパスフレーズを入力する。

期待される結果は、/dev/mapper/crypt_name が作成されることである。この時点では、まだファイルシステムをディレクトリへ接続していないため、通常のファイル操作はできない。open は暗号化層を開く操作であり、mount はファイルシステム層を接続する操作である。この 2 つを分けて理解することが、暗号化デバイス運用の基本になる。

次に、既存ファイルシステムをマウントする。ここでは、初期生成時に作成済みの ext4 ファイルシステムを /mnt/crypt_name へ接続する。通常運用では、/dev/mapper/crypt_name に対して mkfs.ext4 を実行しない。既にあるファイルシステムを使うだけである。

期待される結果は、/mnt/crypt_name 以下で既存ファイルを読める状態になることである。マウントに失敗する場合は、mapper 名が違う、マウントポイントが存在しない、ファイルシステムが破損している、既にマウントされている、権限やデバイス状態に問題がある、といった原因を切り分ける。ここで暗号化の問題とファイルシステムの問題を混同しないことが重要である。open に成功して mount に失敗する場合、少なくとも keyfile やパスフレーズによる LUKS 解除は成功しており、問題はその後のファイルシステム層にある可能性が高い。

作業が終わったら、未書き込みデータをストレージへ反映する。sync は暗号化デバイスを閉じるコマンドではない。ファイルシステムやカーネルのバッファに残っている書き込みを、実際のストレージへ反映させるための段階である。特に外付け媒体、長時間同期、バックアップ、電源断前の作業では、明示的に sync を入れることで、作業手順上の区切りが明確になる。

sync がエラーなく終わったら、次にファイルシステムをアンマウントする。umount は、/mnt/crypt_name に接続されているファイルシステムを切り離す操作である。ここで対象にするのは mapper device ではなく、マウントポイントである。ファイルを開いたままのプロセスがある場合、umount は失敗することがある。

期待される結果は、/mnt/crypt_name がマウントされていない状態になることである。umount が成功すると、ファイルシステム層としては利用終了状態になる。しかし、この時点でも /dev/mapper/crypt_name はまだ存在している。つまり、暗号化デバイスは開いたままであり、最後に cryptsetup close によって mapper device を閉じる必要がある。

cryptsetup close の期待される結果は、/dev/mapper/crypt_name が消えることである。ファイルシステムを mount したまま close しようとしても失敗するため、順序は必ず sync、umount、close の順にする。これにより、ファイルシステム層、mapper 層、物理デバイス層を順番に閉じることができる。

段階	対象	役割	通常運用での意味
open	LUKS デバイス	暗号化デバイスを開き、mapper device を作る。	暗号化層を利用可能にする。
mount	mapper device	既存ファイルシステムをディレクトリへ接続する。	ファイルを読み書きできる状態にする。
sync	システム全体の未書き込みデータ	バッファ上の書き込みをストレージへ反映する。	作業終了前の同期点を明確にする。
umount	マウントポイント	ファイルシステムを切り離す。	ファイルシステム層の利用を終了する。
close	mapper 名	復号後の mapper device を閉じる。	暗号化層の利用を終了する。

通常運用の要点は、各コマンドが操作している層を混同しないことである。open は暗号化層、mount はファイルシステム層、sync は未書き込みデータの反映、umount はファイルシステムの切断、close は mapper device の削除である。この順序を固定しておけば、暗号化デバイスの利用開始と利用終了を再現可能な手順として扱える。逆に、通常運用の中に mkfs.ext4 のような初期化コマンドを混ぜると、作成手順と利用手順の境界が崩れ、誤操作の危険が高まる。

---

6. 状態確認では目的ごとに見る場所を分ける

暗号化デバイスの状態確認で重要なのは、確認コマンドをまとめて暗記することではなく、「いま何を知りたいのか」に応じて見る層を分けることである。暗号化ディスクには、物理デバイス、LUKS ヘッダー、復号後の mapper device、ファイルシステム、マウントポイントという複数の層がある。LUKS 形式かどうかを確認したい場合、key slot を確認したい場合、すでに開いているかを確認したい場合、どこにマウントされているかを確認したい場合では、使うコマンドが異なる。したがって、この章では、各コマンドを「どういうときに使うのか」「何が分かれば正常なのか」という単位で整理する。

6.1 対象が LUKS デバイスかを確認する

最初に確認したいのは、対象が本当に LUKS デバイスかどうかである。この確認には isLuks を使う。これは、対象デバイスに LUKS ヘッダーがあるかどうかを判定するための確認コマンドである。暗号化デバイスを開く前、key slot を変更する前、ヘッダーバックアップを取る前に、対象が LUKS として認識されるかを確認する用途に向いている。

このコマンドは、正常時に詳細な情報を大量に表示するためのものではない。主に終了ステータスで判定する。エラーなく終了すれば、対象は LUKS デバイスとして認識されている。エラーになる場合は、対象が LUKS ではない、デバイス名を間違えている、パーティションではなくディスク全体を指定すべきところを取り違えている、あるいはヘッダーが破損している可能性がある。ここで失敗する状態のまま luksDump、open、luksKillSlot のような操作へ進んではならない。

6.2 LUKS ヘッダーと key slot を確認する

対象が LUKS デバイスであることを確認したら、次に luksDump で LUKS ヘッダーの内容を見る。luksDump は、LUKS version、UUID、cipher、data segment、key slot、KDF、salt、digest などを表示する。これは単なる詳細情報の表示ではない。暗号化デバイスの形式が LUKS1 なのか LUKS2 なのか、現在どの暗号方式で作られているのか、どの key slot が有効なのか、台帳に記録された内容と実体が一致しているかを確認するための基本操作である。

期待される結果は、LUKS header information が表示され、Version、UUID、暗号方式、有効な key slot が確認できることである。LUKS1 では Key Slot 0、Key Slot 1 のように ENABLED または DISABLED が表示される。LUKS2 では Keyslots、Tokens、Digests などの構造が表示される。ここで確認すべき中心は、すべての細かい値を読むことではなく、台帳上の LUKS UUID と一致するか、想定した LUKS version か、有効な key slot が想定どおりか、不要な解除入口が残っていないかである。

確認項目	見る場所	判断内容
Version	Version 行を見る。	LUKS1 か LUKS2 かを確認する。
LUKS UUID	UUID 行を見る。	台帳や crypttab に記録した暗号化デバイスと一致するかを確認する。
暗号方式	Cipher、Cipher mode、Data segments を見る。	AES-CBC-ESSIV なのか AES-XTS なのかなど、暗号化方式の世代と構成を確認する。
key slot	Key Slot または Keyslots を見る。	有効な解除入口がいくつあり、それが想定どおりかを確認する。
KDF	PBKDF、Iterations、Memory、Threads などを見る。	パスフレーズや keyfile から解除用の鍵材料を作る方式と強度を確認する。

luksDump は、key slot を追加した後、不要な key slot を削除した後、ヘッダーバックアップを取る前後、移行対象を調査するときに必ず使う。特に luksKillSlot の前には、有効な key slot の数と用途を確認する必要がある。最後の有効 key slot を削除すると、その LUKS デバイスは開けなくなる。したがって、luksDump は「状態を見るコマンド」であると同時に、「破壊的操作へ進んでよいかを判断するための安全確認」である。

6.3 すでに開いている mapper device の状態を確認する

暗号化デバイスを open した後は、元の /dev/sdX とは別に /dev/mapper/crypt_name が作られる。この復号後の mapper device が現在どういう状態かを確認するには、cryptsetup status を使う。これは LUKS ヘッダーの詳細を見るためのコマンドではなく、すでに開かれている mapper 名について、元デバイス、暗号方式、offset、sector size などを確認するためのコマンドである。

期待される結果は、/dev/mapper/crypt_name が active として表示され、元デバイスや暗号設定が確認できることである。ここで crypt_name には /dev/mapper/ を付けず、mapper 名だけを指定する。status が「inactive」または見つからないという結果になる場合、その mapper device は開かれていない。mount に失敗したとき、まず open そのものが成功しているかを切り分けるには、この確認が有効である。

status で active と表示されるのに mount できない場合、問題は LUKS の解除ではなく、ファイルシステム、マウントポイント、fstab、権限、破損などの層にある可能性が高い。逆に status で mapper が存在しない場合は、そもそも暗号化デバイスが開けていない。状態確認では、このように暗号化層とファイルシステム層を切り分けることが重要である。

6.4 物理デバイス、mapper、マウントポイントの対応を見る

暗号化デバイスを開いた後、物理デバイス、LUKS、mapper device、ファイルシステム、マウントポイントがどうつながっているかを確認するには lsblk -f を使う。これは、どのデバイスがどの下位層または上位層に接続されているかを階層構造で見るためのコマンドである。暗号化デバイスを open した後、mount した後、close した後に実行すると、状態遷移が確認しやすい。

期待される結果は、物理デバイスの下に crypto_LUKS があり、open 済みであれば /dev/mapper 側の名前が表示され、その上に ext4 などのファイルシステムとマウントポイントが見えることである。ここで確認するのは、単に表示があるかどうかではない。/dev/sdX、mapper 名、ファイルシステム UUID、マウントポイントが、台帳と一致しているかを確認する。暗号化デバイス運用では、どの層を操作しているのかを見失うと、mkfs や umount や close の対象を誤る。

6.5 UUID や TYPE を機械的に確認する

UUID や TYPE を確認するには blkid を使う。lsblk -f でも UUID は見えるが、blkid は設定ファイルや台帳へ転記する識別子を確認する用途に向いている。特に crypttab では LUKS デバイスの UUID、fstab では復号後のファイルシステム UUID を使うことがあるため、どの UUID がどの層に属するものかを区別する必要がある[14][15]。

期待される結果は、各デバイスについて UUID、TYPE、PARTUUID などが表示されることである。TYPE=”crypto_LUKS” と表示される UUID は、LUKS ヘッダーを持つ暗号化デバイス側の識別子である。一方、/dev/mapper/crypt_name に ext4 の UUID が表示される場合、それは復号後のファイルシステム側の識別子である。この 2 つを混同してはならない。crypttab で必要な UUID と fstab で必要な UUID は、同じではない場合がある。

知りたいこと	使うコマンド	期待される結果
LUKS かどうか	cryptsetup isLuks	対象が LUKS デバイスならエラーなく終了する。
LUKS ヘッダーの詳細	cryptsetup luksDump	LUKS version、UUID、暗号方式、key slot、KDF が確認できる。
開いている mapper の状態	cryptsetup status	mapper が active か、元デバイスや暗号設定が何かを確認できる。
デバイス階層とマウント状態	lsblk -f	物理デバイス、mapper、ファイルシステム、マウントポイントの関係を確認できる。
UUID と TYPE	blkid	crypto_LUKS、ext4、vfat などの TYPE と UUID を確認できる。

この章の要点は、状態確認を 1 つのコマンドで済ませようとしないことである。LUKS ヘッダーを見るなら luksDump、開いている mapper を見るなら status、階層関係を見るなら lsblk -f、UUID を確認するなら blkid を使う。これらは重複しているように見えるが、見ている層が違う。暗号化デバイスの運用では、物理デバイス、LUKS ヘッダー、mapper、ファイルシステム、マウントポイントを分けて確認することが、誤操作防止と復旧可能性の基礎になる。

---

7. key slot は暗号化デバイスの解除入口である

LUKS の key slot は、暗号化データ本体の別コピーではない。key slot は、同じ暗号化デバイスを開くための解除入口である。LUKS では、データ本体を暗号化するための volume key があり、利用者はその volume key を直接扱わない。利用者が入力するパスフレーズ、keyfile、token などは、それぞれ key slot を通じて volume key を取り出すための入口として働く。したがって、key slot を管理するとは、暗号化データを複製することではなく、「どの解除手段で開ける状態を残すか」を管理することである。

この構造を理解すると、key slot の使い道が整理できる。通常運用では keyfile を使い、非常時には長いパスフレーズを使う。管理者交代時には新しい解除手段を追加し、古い解除手段を削除する。用途不明の古いパスフレーズが残っている場合は、それが本当に不要かを確認してから削除する。つまり、key slot は、暗号化デバイスの利用者、運用経路、復旧経路、退役条件を表す管理点である。

用途	key slot の使い方	運用上の意味
通常運用	keyfile を登録した key slot を使う。	サーバー起動時や定型作業で、人間の入力なしに暗号化デバイスを開く。
非常時復旧	長い非常用パスフレーズを別 key slot に登録する。	keyfile の喪失、起動設定の破損、crypttab の不整合が起きても手動で開ける経路を残す。
管理者交代	新しい解除手段を追加し、旧解除手段を削除する。	過去の管理者や古い運用に依存した解除入口を残さない。
旧設定整理	用途不明の key slot を調査してから削除する。	使っていない古いパスフレーズを残さず、解除入口を管理可能な数に保つ。
移行作業	移行期間だけ一時的な解除手段を追加する。	新旧環境の両方で作業できる状態を作り、移行完了後に一時 slot を削除する。

key slot 管理で最も重要なのは、増やすことよりも意味を記録することである。LUKS の key slot には「これは通常運用用」「これは非常用」「これは旧管理者用」といった説明が自動的に保存されるわけではない。luksDump で分かるのは、有効な slot が存在すること、slot 番号、KDF、salt などであり、その slot が何のために作られたかは運用側が台帳に残さなければならない。したがって、key slot を追加したら、必ず用途、作成日、解除手段、確認日、削除予定の有無を記録する。

---

8. key slot を追加し、解除できることを確認する

key slot を追加する典型的な場面は、通常運用用の keyfile を登録する場合、非常用パスフレーズを追加する場合、または移行作業のために一時的な解除手段を追加する場合である。ここで使う基本コマンドは luksAddKey である。luksAddKey は、既存の有効な解除手段で認証したうえで、新しい解除手段を別の key slot に追加する。つまり、誰でも勝手に解除入口を増やせるわけではなく、すでに正当な解除手段を持っていることを確認してから、新しい入口を追加する操作である。

keyfile を追加する場合は、追加したい keyfile を引数として指定する。次の例では、既存のパスフレーズで認証したうえで、/etc/cryptsetup-keys/crypt_name.key を新しい解除手段として登録する。期待される結果は、新しい key slot が 1 つ有効になり、その keyfile で暗号化デバイスを開けるようになることである。

非常用パスフレーズを追加する場合は、既存の keyfile で認証し、新しいパスフレーズを対話式で登録する。通常運用では keyfile を使い、非常時にはパスフレーズで手動解除する設計にしたい場合、この手順が有効である。期待される結果は、keyfile による通常解除を維持したまま、別の key slot に非常用パスフレーズが追加されることである。

追加後は、必ず解除確認を行う。keyfile が正しく登録されたかを確認する場合は、open –test-passphrase と –key-file を使う。この操作は実際に /dev/mapper 以下へ mapper device を作るのではなく、指定した解除手段で開けるかだけを確認する。期待される結果は、エラーなく終了することである。エラーが出る場合は、keyfile が登録されていない、対象デバイスが違う、keyfile のパスが違う、または keyfile の内容が想定と異なる可能性がある。

非常用パスフレーズを追加した場合は、keyfile なしでも解除できることを確認する。この確認では、追加した非常用パスフレーズを入力する。期待される結果は、非常用パスフレーズでもエラーなく test-passphrase が通ることである。これにより、通常運用の keyfile と非常時の passphrase という 2 系統の解除経路が実際に機能することを確認できる。

追加後には luksDump で key slot の状態を確認する。ここで確認するのは、有効な key slot が増えていること、想定外に多数の key slot が残っていないこと、台帳に記録した用途と slot 数が一致することである。ただし、luksDump だけでは「この slot は keyfile 用」「この slot は非常用パスフレーズ用」と自動的に分かるわけではない。どの slot がどの解除手段に対応するかを厳密に確認したい場合は、次章で扱うように –key-slot を指定して照会する。

追加するもの	使う場面	確認方法
keyfile	自動解除や定型運用で使う。	–key-file を指定して test-passphrase が通ることを確認する。
非常用パスフレーズ	keyfile 喪失や起動設定破損に備える。	keyfile なしで test-passphrase を実行し、非常用パスフレーズで通ることを確認する。
一時作業用解除手段	移行、復旧、管理者交代などの期間限定作業で使う。	作業完了後に不要 slot として削除対象へ回す。

key slot を追加すると復旧性は上がるが、解除入口も増える。したがって、追加したまま放置してはならない。通常運用用 keyfile、非常用パスフレーズ、一時作業用 slot は、役割が違う。通常運用用と非常用は長期保持してよいが、一時作業用は作業完了後に削除する。key slot 管理では、追加した直後に確認し、台帳に記録し、不要になった時点で削除するところまでを 1 つの運用として扱う。

---

9. key slot を照会し、不要な解除入口を削除する

不要な key slot を削除する目的は、使っていない古いパスフレーズや用途不明の解除入口を残さないことである。削除対象はデータ本体ではなく解除入口である。ただし、解除入口を誤ってすべて消すと、暗号化データ本体は残っていても復号不能になる。したがって、削除の前には、どの slot が現在の通常運用用で、どの slot が非常用で、どの slot が用途不明なのかを確認する必要がある。

まず、luksDump で有効な key slot を確認する。ここでは slot 番号と有効状態を見る。期待される結果は、有効な key slot の数を把握できることである。たとえば通常運用用 keyfile と非常用パスフレーズの 2 つだけを残す設計なら、有効 slot は 2 つでよい。これより多い場合は、古いパスフレーズ、過去の管理者用 slot、一時作業用 slot が残っている可能性がある。

次に、keyfile がどの slot に対応しているかを確認する。–test-passphrase と –key-slot を組み合わせると、指定した slot に対してその keyfile で解除できるかを確認できる。次の例では、slot 0 が /etc/cryptsetup-keys/crypt_name.key で開けるかを確認している。期待される結果は、keyfile 用として残すべき slot だけが成功することである。

slot 1、slot 2 なども必要に応じて同じ方法で確認する。成功した slot は、その keyfile に対応している。失敗した slot は、その keyfile では開けない別の解除入口である。失敗したからといって即座に不要とは限らない。非常用パスフレーズ用 slot かもしれないし、過去に登録した一時作業用 slot かもしれない。したがって、削除前には、非常用パスフレーズで test-passphrase が通ること、通常運用用 keyfile で通ること、削除後に残すべき解除入口が明確であることを確認する。

削除前には LUKS ヘッダーをバックアップする。これは、key slot 整理が LUKS ヘッダー領域を変更する操作だからである。ヘッダーバックアップは復旧に役立つ一方で、バックアップ時点の key slot 状態も含むため、機微情報として扱う必要がある。期待される結果は、指定したファイルに LUKS ヘッダーのバックアップが作成されることである。

削除には luksKillSlot を使う。luksKillSlot は、指定した slot 番号の解除入口を削除する操作である。これはデータ本体を消す操作ではないが、削除した slot に対応するパスフレーズや keyfile では開けなくなる。最後の有効 key slot を削除すると、暗号化データ本体が残っていても復号不能になる。したがって、削除対象の slot 番号を luksDump と test-passphrase で確認してから、1 つずつ削除する。

この例では、既存の有効な解除手段として /etc/cryptsetup-keys/crypt_name.key を指定し、SLOT_NUMBER の key slot を削除している。SLOT_NUMBER は説明用の仮名であり、実際には luksDump で確認した削除対象 slot 番号に置き換える。削除後は、luksDump で有効 slot が想定どおり減っていることを確認し、さらに keyfile と非常用パスフレーズの両方で test-passphrase を実行する。

操作	目的	注意点
luksDump	有効な key slot と slot 番号を確認する。	slot の用途名は自動では分からないため、台帳と照合する。
test-passphrase	keyfile やパスフレーズで解除できるかを確認する。	mapper を作らずに解除可否だけを確認できる。
test-passphrase + key-slot	特定 slot が特定の解除手段に対応するかを確認する。	keyfile 用 slot を誤って削除しないために使う。
luksHeaderBackup	key slot 変更前の LUKS ヘッダーを保全する。	ヘッダーバックアップは機微情報として保管する。
luksKillSlot	指定した key slot を削除する。	最後の有効 slot を消すと復号不能になる。

luksRemoveKey と luksKillSlot は似ているが、使いどころが違う。luksRemoveKey は、入力したパスフレーズに対応する key slot を削除する操作である。どの slot 番号かを意識せず、「このパスフレーズを無効化したい」ときに向いている。一方、luksKillSlot は、slot 番号を指定して削除する操作である。luksDump と test-passphrase によって「この番号の slot は不要」と判断できている場合は、luksKillSlot のほうが意図を明確にしやすい[16]。

key slot 整理の最終状態は、通常運用用 keyfile と非常用パスフレーズのように、役割が明確な解除入口だけが残っている状態である。用途不明の slot を残すと、過去の弱いパスフレーズが生き続ける可能性がある。一方で、削除しすぎると復旧性を失う。したがって、key slot 管理では、追加、照会、削除のそれぞれを単独操作として扱わず、台帳、ヘッダーバックアップ、解除確認と組み合わせて実施する必要がある。

---

10. LUKS ヘッダーは取得、保管、照合、復元手順まで含めて管理する

LUKS ヘッダーは、暗号化データ本体へ到達するための重要なメタデータである。ここには、LUKS UUID、暗号方式、data segment、key slot、KDF、salt、digest など、暗号化デバイスを開くために必要な情報が含まれる。データ領域が無傷でも、ヘッダーや key slot 領域が破損すれば開けなくなる可能性がある。したがって、LUKS ヘッダーのバックアップは、単にファイルを 1 個保存して終わる作業ではない。取得し、対象デバイスと対応づけ、保管し、必要時に照合し、復旧時だけ復元するための運用手順として扱う必要がある。

ヘッダーバックアップを取得する典型的なタイミングは、初期作成直後、keyfile 追加後、非常用パスフレーズ追加後、不要 key slot 削除前、移行前、退役判断前である。特に key slot を変更する前には、変更前の状態へ戻せるようにヘッダーバックアップを取得する。ただし、これは「いつでも気軽に戻すため」ではない。ヘッダーバックアップは、LUKS ヘッダーや key slot 領域が破損した場合、または key slot 変更に失敗して復旧が必要になった場合に使う復旧資材である。

このコマンドの目的は、/dev/sdX の LUKS ヘッダーを指定したファイルへ退避することである。期待される結果は、luks-crypt_name-header-YYYYMMDD.img のようなヘッダーバックアップファイルが作成されることである。ここで /dev/sdX は LUKS デバイス本体を指し、/dev/mapper/crypt_name ではない。復号後の mapper device ではなく、LUKS ヘッダーを持つ元デバイスを指定する点が重要である。

取得後は、ヘッダーバックアップがどの LUKS デバイスに対応するかを必ず記録する。ファイル名だけでは不十分である。少なくとも、対象の LUKS UUID、取得日、対象デバイスの by-id 名、取得時点の key slot 状態、保存場所、保管方法を台帳に残す。ヘッダーバックアップは、それ単体で直ちにデータを復号する鍵ではないが、バックアップ時点の key slot 情報を含む。したがって、その時点で有効だったパスフレーズや keyfile と組み合わされると、復号に使える可能性がある。

項目	記録する内容	目的
取得日	ヘッダーバックアップを作成した日付を記録する。	どの時点の key slot 状態へ戻るのかを判断する。
LUKS UUID	luksDump で表示される UUID を記録する。	ヘッダーバックアップと対象デバイスを対応づける。
対象媒体	/dev/disk/by-id の識別子、モデル、シリアル、容量を記録する。	/dev/sdX の変化による取り違えを防ぐ。
key slot 状態	取得時点で有効だった key slot と用途を記録する。	復元した場合に、どの解除入口が復活するかを判断する。
保管場所	ヘッダーバックアップファイルの保存先を記録する。	復旧時に必要なファイルを探せるようにする。
保管方法	暗号化保管、オフライン保管、アクセス権限などを記録する。	ヘッダーバックアップ自体の漏洩リスクを管理する。

ヘッダーバックアップを取得したら、対象デバイスの現在の LUKS UUID と、台帳に記録した LUKS UUID を照合できるようにする。通常は luksDump で UUID を確認する。ここで期待される結果は、ヘッダーバックアップの台帳に記録した UUID と、現在見ている対象デバイスの UUID が一致することである。不一致の場合は、バックアップファイルまたは対象デバイスを取り違えている可能性があるため、復元操作へ進んではならない。

ヘッダーバックアップは、保存して終わりではなく、復旧時に使える形で保管されている必要がある。ただし、安易に平文で多数の場所へ複製すると、今度は漏洩リスクが増える。ヘッダーバックアップには key slot 情報が含まれるため、古いヘッダーバックアップを攻撃者が入手し、さらに当時有効だったパスフレーズや keyfile も入手した場合、削除済みの解除入口が実質的に復活する可能性がある。したがって、ヘッダーバックアップは復旧資材であると同時に、機微情報として扱う。

復元に使うコマンドは luksHeaderRestore である。ただし、この操作は軽い修復ではない。対象デバイスの LUKS ヘッダーをバックアップ時点の内容で上書きする操作である。つまり、現在の key slot 状態、現在の token、現在の digest、現在のメタデータが、バックアップ時点へ戻る。非常用パスフレーズを追加した後のヘッダーへ戻すのか、古いパスフレーズ削除前のヘッダーへ戻すのかによって、復元後に有効になる解除入口が変わる。

このコマンドを使う場面は限定される。LUKS ヘッダー破損で luksDump が正常に読めない場合、key slot 整理に失敗して復旧が必要な場合、または復旧手順書に基づいてバックアップ時点のヘッダーへ戻す必要がある場合である。通常の確認、通常のマウント失敗、単なるパスフレーズ入力ミス、crypttab の設定ミスでは、最初に使うべき操作ではない。復元前には、対象デバイス、ヘッダーバックアップの取得日、LUKS UUID、対象媒体、復元によって復活する key slot を確認する。

ヘッダー復元で最も危険なのは、違うデバイスに違うヘッダーを戻すことである。LUKS ヘッダーは暗号化データ本体と対応しているため、別の暗号化デバイスのヘッダーを誤って restore すると、元のデバイスを開けなくする危険がある。また、現在のヘッダーより古いバックアップを restore すると、後から追加した非常用パスフレーズや keyfile が消え、削除済みの古い key slot が復活する場合がある。したがって、restore は「壊れたからとりあえず実行する」操作ではなく、復旧手順書に基づいて最後に選択する操作である。

操作	使う場面	期待される結果	注意点
luksHeaderBackup	初期作成後、key slot 変更前後、移行前、退役前に実施する。	LUKS ヘッダーのバックアップファイルが作成される。	取得したファイルは機微情報として保管する。
luksDump	ヘッダーバックアップと対象デバイスを照合するときに使う。	LUKS UUID、Version、key slot 状態を確認できる。	台帳の UUID と一致しない場合は復元へ進まない。
luksHeaderRestore	ヘッダー破損や key slot 変更失敗から復旧するときに使う。	対象デバイスの LUKS ヘッダーがバックアップ時点へ戻る。	現在の key slot 状態もバックアップ時点へ戻る。

実運用では、ヘッダーバックアップを複数世代保持する場合がある。その場合、最新のヘッダーだけが常に最適とは限らない。key slot 変更前に戻したい場合は変更前のバックアップが必要になり、現在の通常運用状態へ戻したい場合は変更後のバックアップが必要になる。したがって、ヘッダーバックアップのファイル名には日付と対象名を含め、台帳にはその時点の key slot 用途まで記録する。これにより、復元時に「どの時点へ戻すのか」を判断できる。

この章の要点は、LUKS ヘッダーをバックアップファイルとして保存することではなく、復旧可能な資材として管理することである。取得、照合、保管、復元条件、復元後の確認までを含めて初めてヘッダーバックアップは意味を持つ。復元後には、luksDump でヘッダー状態を確認し、通常運用用 keyfile と非常用パスフレーズで test-passphrase を行い、必要であれば crypttab、fstab、台帳を更新する。ヘッダーバックアップは、暗号化デバイスの長期運用における最後の安全網であり、同時に誤用すれば現状を壊す強い操作でもある。

---

11. 自動起動では暗号化解除とマウントを別々に管理する

暗号化デバイスを起動時に自動利用する場合、考えるべき対象は /etc/crypttab と /etc/fstab だけではない。実際には、起動時に暗号化デバイスをどの名前で開くか、どの元デバイスを参照するか、どの keyfile またはパスフレーズで解除するか、解除後の mapper device をどこへマウントするか、失敗時に起動を止めるのか待つのか、initramfs に keyfile が必要なのか、systemd がどの unit を生成するのかまでを含めて設計する必要がある。systemd の crypttab は、暗号化 block device を /dev/mapper 以下へ設定する静的設定として扱われ、systemd-cryptsetup-generator は起動時に crypttab から必要な unit を生成する[17][18]。一方、fstab は filesystem をどこへ mount するかを定義し、systemd.mount は fstab などから mount unit を扱う[19][20]。したがって、自動起動の設計では、暗号化解除とマウントを分けて理解する必要がある。

最初に分けるべきなのは、crypttab が担当する層と fstab が担当する層である。crypttab は、暗号化された元デバイスを開き、/dev/mapper/crypt_name のような復号後の mapper device を作るための設定である。fstab は、その mapper device 上にある ext4 などのファイルシステムを、/mnt/crypt_name や /srv/data のようなマウントポイントへ接続するための設定である。つまり、crypttab は「開く設定」であり、fstab は「マウントする設定」である。この二つを混同すると、mapper は作成されているがマウントされない、または fstab にはマウント設定があるが mapper が存在しない、という状態になる。

11.1 現在の自動起動設定を確認する

自動起動設定を変更する前には、まず現在の crypttab、fstab、mapper、ブロックデバイス階層を確認する。この確認の目的は、設定ファイルに何が書かれているかを見ることではなく、設定と実体が一致しているかを確認することである。crypttab に書かれた mapper 名が実際に /dev/mapper 以下に現れるか、fstab に書かれたマウントポイントが実際に mount されるか、lsblk -f で見える階層が想定どおりかを確認する。

期待される結果は、crypttab に定義された mapper 名が /dev/mapper 以下に存在し、fstab に定義されたマウントポイントが lsblk -f の MOUNTPOINTS に表示されることである。mapper が存在しない場合は、暗号化解除に失敗している可能性がある。mapper は存在するがマウントされていない場合は、fstab、mount option、ファイルシステム、マウントポイント側の問題である可能性が高い。この切り分けにより、起動時の失敗を「LUKS が開けない問題」と「ファイルシステムがマウントできない問題」に分けて調査できる。

確認対象	見る場所	分かること
crypttab	/etc/crypttab を見る。	どの暗号化デバイスを、どの mapper 名で、どの keyfile または方式で開くかを確認する。
fstab	/etc/fstab を見る。	復号後のファイルシステムを、どのマウントポイントへ接続するかを確認する。
mapper	/dev/mapper を見る。	crypttab によって作られるはずの mapper device が存在するかを確認する。
デバイス階層	lsblk -f を見る。	物理デバイス、LUKS、mapper、ファイルシステム、マウントポイントのつながりを確認する。

11.2 crypttab は暗号化デバイスを開く設定である

crypttab には、起動時または systemd 管理下で開く暗号化デバイスを定義する。基本的な考え方は、mapper 名、元デバイス、keyfile、option を 1 行に書くことである。mapper 名は /dev/mapper 以下に作られる名前であり、元デバイスは LUKS ヘッダーを持つ暗号化デバイスである。元デバイスには /dev/sdX のような変動しやすい名前ではなく、UUID などの永続的な識別子を使うのが望ましい。

この例では、UUID=LUKS_DEVICE_UUID で識別される LUKS デバイスを、/etc/cryptsetup-keys/crypt_name.key で解除し、crypt_name という mapper 名で開く。期待される結果は、起動時または systemd の処理時に /dev/mapper/crypt_name が作成されることである。ここで指定する UUID は、復号後の ext4 ファイルシステム UUID ではなく、LUKS デバイス側の UUID である。LUKS UUID とファイルシステム UUID を混同すると、crypttab が正しい対象を開けなくなる。

keyfile を crypttab で指定する場合、その keyfile が起動時に読める場所に存在するかを確認する必要がある。追加データディスクを root filesystem 起動後に開く構成であれば、/etc/cryptsetup-keys/crypt_name.key のような root filesystem 上の keyfile を使える。一方、root filesystem 自体を開くために keyfile が必要な構成では、その keyfile が initramfs に含まれるか、起動時に別の方法で参照できる必要がある。したがって、自動起動設計では、「keyfile が存在する場所」と「その keyfile が必要になる時点」を必ず対応づけて考える。

11.3 fstab は復号後のファイルシステムをマウントする設定である

fstab は、ファイルシステムをどこへマウントするかを定義する設定である。暗号化デバイスの場合、fstab が直接扱うのは暗号化前の /dev/sdX ではなく、crypttab によって開かれた後の /dev/mapper/crypt_name、またはその上にあるファイルシステム UUID である。つまり、fstab は暗号化を解除しない。fstab は、すでに開かれている mapper device 上のファイルシステムを、指定したマウントポイントへ接続する。

この例では、/dev/mapper/crypt_name 上の ext4 ファイルシステムを /mnt/crypt_name へマウントする。期待される結果は、起動後に /mnt/crypt_name が利用可能になることである。mapper が作成されていない場合、この fstab 行は成功しない。したがって、fstab の設定だけを見ても自動起動は完結しない。先に crypttab によって mapper が作成され、その後に fstab によって mount される、という順序を前提にする必要がある。

fstab では /dev/mapper/crypt_name を直接指定する方法と、復号後のファイルシステム UUID を指定する方法がある。mapper 名を使うと crypttab との対応が読みやすい。一方、ファイルシステム UUID を使うと、mapper 名を変更した場合でもファイルシステム自体を識別しやすい。どちらを使う場合でも、台帳には crypttab の mapper 名、LUKS UUID、fstab の指定方法、ファイルシステム UUID、マウントポイントをまとめて記録する。

11.4 自動起動の失敗は層ごとに切り分ける

自動起動で失敗した場合は、暗号化解除、mapper 作成、ファイルシステム認識、マウント、権限、依存関係を順に切り分ける。たとえば、/dev/mapper/crypt_name が存在しないなら、crypttab、keyfile、LUKS UUID、systemd-cryptsetup 側を調べる。/dev/mapper/crypt_name は存在するがマウントされていないなら、fstab、mount point、filesystem UUID、mount option、ファイルシステム状態を調べる。lsblk -f で mapper とマウントポイントの関係を見ると、この切り分けがしやすい。

症状	見る場所	考えられる原因
mapper が存在しない	crypttab、keyfile、LUKS UUID、systemd-cryptsetup を確認する。	暗号化解除に失敗している、対象 UUID が違う、keyfile が読めない、crypttab の mapper 名が違う可能性がある。
mapper はあるが mount されない	fstab、mount point、filesystem UUID、mount option を確認する。	fstab の指定が違う、マウントポイントがない、ファイルシステムに問題がある可能性がある。
起動が待たされる	crypttab option、fstab option、systemd unit の依存関係を確認する。	対象デバイスが存在しない、外付け媒体が未接続、タイムアウト指定が不足している可能性がある。
手動では開けるが自動では開けない	keyfile のパス、権限、起動時に読める場所、initramfs の有無を確認する。	通常環境では読める keyfile が、起動時点ではまだ利用できない可能性がある。

この章の要点は、自動起動を「crypttab に書く」「fstab に書く」という個別作業として扱わないことである。crypttab は暗号化デバイスを開く設定であり、fstab は開いた後のファイルシステムをマウントする設定である。systemd はその設定から起動時の unit を生成し、依存関係に従って処理する。したがって、自動起動の運用では、LUKS UUID、mapper 名、keyfile、ファイルシステム UUID、マウントポイント、起動時に keyfile が読めるか、失敗時にどう切り分けるかまでを含めて台帳化する必要がある。

---

12. LVM と組み合わせる場合は層の順序を手順として管理する

暗号化デバイスと LVM を組み合わせる場合、最も重要なのは、どちらが下位層でどちらが上位層なのかを明確にすることである。device-mapper は dm-crypt や LVM など複数の mapper を積み重ねられる仕組みであり、LVM は物理ボリューム、ボリュームグループ、論理ボリュームを管理する[21][22]。そのため、LUKS の上に LVM を作る構成と、LVM の上に LUKS を作る構成では、初期生成、通常運用、確認、復旧の順番が変わる。ここを曖昧にすると、どのデバイスに luksFormat するのか、どのデバイスに pvcreate するのか、どの mapper を mount するのかが分からなくなる。

LVM と LUKS の組み合わせには、大きく 2 つの構成がある。1 つ目は、物理ディスクまたはパーティションを LUKS で暗号化し、その復号後の mapper device の上に LVM を作る構成である。この構成では、ディスク全体またはパーティション全体を暗号化したうえで、その内部に複数の論理ボリュームを作れる。2 つ目は、先に LVM を作り、その中の特定の論理ボリュームだけを LUKS で暗号化する構成である。この構成では、暗号化したい LV だけを選んで暗号化できる。どちらが正しいという話ではなく、保護したい範囲、起動時の解除順序、復旧時の作業単位によって選ぶ。

構成	層の順序	向いている用途	復旧時の考え方
LUKS の上に LVM	物理デバイス、LUKS、mapper、PV、VG、LV、filesystem の順になる。	ディスクまたはパーティション全体を暗号化し、その内部を LVM で分割したい場合に向く。	まず LUKS を開き、その後に LVM を認識させ、LV をマウントする。
LVM の上に LUKS	物理デバイス、PV、VG、LV、LUKS、mapper、filesystem の順になる。	特定の LV だけを暗号化したい場合に向く。	まず LVM を認識させ、その後に対象 LV の LUKS を開き、mapper をマウントする。

12.1 LUKS の上に LVM を作る構成

LUKS の上に LVM を作る構成では、最初に物理ディスクまたはパーティションを LUKS で暗号化する。その後、復号して現れた /dev/mapper/crypt_name を LVM の物理ボリュームとして登録する。ここで重要なのは、pvcreate の対象が /dev/sdX ではなく、復号後の /dev/mapper/crypt_name になることである。/dev/sdX に直接 pvcreate すると、LUKS ヘッダーを壊す危険がある。

Debian Installer で「暗号化 LVM」を選択した場合、通常は LUKS の上に LVM を作る構成になる。つまり、ディスク上の暗号化パーティションを cryptsetup / dm-crypt で開き、その復号後の mapper device を LVM の PV として扱い、その上に VG / LV を作る。したがって復旧時の順序は、まず LUKS を開き、次に LVM を認識し、最後に各 LV 上のファイルシステムをマウントする、という順序になる。

初期生成では、まず LUKS デバイスを作成し、開く。これは暗号化された外枠を作り、その中に LVM を置くための準備である。次の 2 つのコマンドは、最初に LUKS ヘッダーを作り、その後に暗号化デバイスを開いて /dev/mapper/crypt_name を作る。luksFormat は破壊的操作であるため、対象デバイスを確定してから実行する。

期待される結果は、/dev/mapper/crypt_name が作成されることである。この時点では、まだ LVM もファイルシステムも存在しない。次に、この mapper device を LVM の物理ボリュームとして初期化し、VG と LV を作る。ここで pvcreate の対象は必ず /dev/mapper/crypt_name である。

この 3 つの操作により、復号後の mapper device が PV になり、その上に VG が作られ、その VG の中に LV が作られる。期待される結果は、/dev/vg_name/lv_name または /dev/mapper/vg_name-lv_name として論理ボリュームが見えることである。この LV はまだファイルシステムを持たないため、次に mkfs.ext4 を実行する。

この構成で mkfs.ext4 の対象になるのは、LUKS デバイスでも /dev/mapper/crypt_name でもなく、LVM が作成した LV である。つまり、暗号化の外枠を開き、その中の LVM 論理ボリュームにファイルシステムを作る。この順序を守ることで、ディスク全体を暗号化しつつ、内部を LVM で柔軟に分割できる。

段階	対象	実施内容
暗号化	/dev/sdX	LUKS ヘッダーを作成し、暗号化デバイスとして初期化する。
解除	/dev/sdX	cryptsetup open により /dev/mapper/crypt_name を作成する。
LVM 初期化	/dev/mapper/crypt_name	復号後の mapper device を PV として登録する。
論理ボリューム作成	VG	VG 内に LV を作成する。
ファイルシステム作成	/dev/vg_name/lv_name	LV 上に ext4 ファイルシステムを作成する。
マウント	/dev/vg_name/lv_name	LV 上のファイルシステムをマウントポイントへ接続する。

12.2 LVM の上に LUKS を作る構成

LVM の上に LUKS を作る構成では、先に物理ディスクまたはパーティションを LVM の PV として登録し、VG と LV を作る。その後、特定の LV を LUKS で暗号化する。この構成では、LVM 全体ではなく、選んだ論理ボリュームだけが暗号化対象になる。たとえば、同じ VG の中に通常の LV と暗号化 LV を並べたい場合や、既存の LVM 環境に暗号化領域を追加したい場合に向く。

初期生成では、まず LVM の PV、VG、LV を作る。ここでは /dev/sdX を LVM の物理ボリュームとして使う例を示す。既存の LVM 環境に追加する場合は、pvcreate や vgcreate を実行する対象を誤ると既存構成を破壊するため、事前に pvs、vgs、lvs、lsblk -f で確認する。

期待される結果は、/dev/vg_name/lv_crypt という LV が作成されることである。この時点では、まだ暗号化されていない通常の LV である。次に、この LV 自体を LUKS デバイスとして初期化する。ここで luksFormat の対象は /dev/sdX ではなく、/dev/vg_name/lv_crypt である。

この操作により、LV の中に LUKS ヘッダーが作られ、open 後に /dev/mapper/crypt_name が現れる。期待される結果は、/dev/vg_name/lv_crypt が暗号化コンテナになり、その復号後の mapper device として /dev/mapper/crypt_name が使える状態になることである。ここで mkfs.ext4 を実行する対象は、LVM の LV ではなく、復号後の /dev/mapper/crypt_name である。

この構成では、LVM は暗号化デバイスの外側にあり、LUKS は特定 LV の内側にある。そのため、復旧時には、まず LVM を認識させて /dev/vg_name/lv_crypt を見える状態にし、その後に cryptsetup open で LUKS を開き、最後に /dev/mapper/crypt_name をマウントする。LUKS の上に LVM を作る構成とは順序が逆になる。

段階	対象	実施内容
LVM 初期化	/dev/sdX	物理デバイスまたはパーティションを PV として登録する。
VG 作成	PV	PV を含む VG を作成する。
LV 作成	VG	暗号化対象にする LV を作成する。
暗号化	/dev/vg_name/lv_crypt	LV を LUKS デバイスとして初期化する。
解除	/dev/vg_name/lv_crypt	cryptsetup open により /dev/mapper/crypt_name を作成する。
ファイルシステム作成	/dev/mapper/crypt_name	復号後の mapper device 上に ext4 ファイルシステムを作成する。

12.3 通常運用では構成ごとに開く順序が変わる

LUKS と LVM を組み合わせた構成では、通常運用でも層の順序を意識する必要がある。LUKS の上に LVM がある場合は、まず LUKS を開き、その中にある LVM を有効化し、対象 LV をマウントする。LVM の上に LUKS がある場合は、まず LVM が見えていることを確認し、その中の対象 LV を LUKS として開き、復号後の mapper device をマウントする。

LUKS の上に LVM を作った構成では、通常運用は次の順になる。最初に LUKS デバイスを開く。次に LVM の VG を有効化する。最後に対象 LV をマウントする。期待される結果は、/dev/mapper/crypt_name が作られ、VG が active になり、/mnt/lv_name にファイルシステムがマウントされることである。

終了時は逆順で閉じる。まずファイルシステムをアンマウントし、必要に応じて VG を非 active にし、最後に LUKS の mapper を閉じる。expect される状態は、マウントが解除され、LV が使われておらず、/dev/mapper/crypt_name が消えることである。

LVM の上に LUKS を作った構成では、通常運用は次の順になる。LVM の LV が見えていることを前提に、その LV を LUKS として開き、復号後の mapper device をマウントする。期待される結果は、/dev/vg_name/lv_crypt を元に /dev/mapper/crypt_name が作られ、/mnt/crypt_name へマウントされることである。

終了時は、まずファイルシステムをアンマウントし、最後に cryptsetup close で mapper を閉じる。LVM の上に LUKS がある構成では、VG 自体を停止するかどうかは、その VG に他の LV があるかによって判断する。VG 内の他の LV が利用中であれば、VG 全体を非 active にしてはならない。

構成	開始順序	終了順序
LUKS の上に LVM	LUKS を開き、VG を有効化し、LV をマウントする。	LV をアンマウントし、VG を非 active にし、LUKS を閉じる。
LVM の上に LUKS	LV を確認し、LUKS を開き、mapper をマウントする。	mapper 上のファイルシステムをアンマウントし、LUKS を閉じる。

12.4 状態確認では LUKS と LVM の両方を見る

LVM と LUKS を組み合わせた構成では、状態確認も 1 つのコマンドでは完結しない。LUKS 側を見るには cryptsetup status や luksDump を使い、LVM 側を見るには pvs、vgs、lvs を使う。さらに lsblk -f で物理デバイス、LUKS、mapper、PV、VG、LV、filesystem、mount point の親子関係を見る。ここで確認する目的は、単に表示を眺めることではなく、台帳に書いた層の順序と実体が一致しているかを確認することである。

期待される結果は、LVM の PV、VG、LV が意図どおり認識され、cryptsetup status で mapper が active と表示され、lsblk -f で層の順序を確認できることである。LUKS の上に LVM がある構成なら、/dev/mapper/crypt_name の上に LVM2_member が見え、その上に LV と filesystem が見える。LVM の上に LUKS がある構成なら、/dev/vg_name/lv_crypt が crypto_LUKS として見え、その下に復号後の mapper と filesystem が見える。

確認したいこと	使うコマンド	判断内容
PV の認識	pvs	どのデバイスが LVM の物理ボリュームとして認識されているかを確認する。
VG の状態	vgs	ボリュームグループの存在、容量、空き領域を確認する。
LV の状態	lvs	論理ボリュームの名前、サイズ、属性を確認する。
LUKS mapper	cryptsetup status	暗号化デバイスが open され、mapper が active かを確認する。
層の順序	lsblk -f	物理デバイス、LUKS、LVM、filesystem、mount point の関係を確認する。

12.5 台帳には構成パターンと復旧順序を残す

LVM と LUKS の組み合わせは、動いている間は意識しなくても使える。しかし、復旧時には順番を間違えると、存在するはずのデバイスが見えない、mapper はあるが LV が見えない、LV はあるが LUKS が開けない、といった状態になる。したがって、台帳には、LUKS の上に LVM があるのか、LVM の上に LUKS があるのかを必ず記録する必要がある。

台帳項目	記録する内容	目的
構成パターン	LUKS の上に LVM、または LVM の上に LUKS のどちらかを記録する。	復旧時に最初に開く層を間違えないようにする。
物理デバイス	/dev/disk/by-id、モデル、シリアル、容量を記録する。	/dev/sdX の変化による取り違えを防ぐ。
LUKS UUID	luksDump で表示される UUID を記録する。	暗号化デバイスを永続的に識別する。
mapper 名	cryptsetup open で指定する名前を記録する。	crypttab、mount、復旧手順で同じ名前を使う。
VG / LV 名	vg_name、lv_name、lv_crypt などを記録する。	LVM 側の操作対象を明確にする。
復旧順序	LUKS を先に開くのか、LVM を先に認識するのかを記録する。	非常時に正しい順番でデバイスを再構成する。

この章の要点は、LVM と LUKS を単なる便利な機能として重ねないことである。どちらも device-mapper を使うため、重ねること自体は可能である。しかし、層の順序を台帳化し、初期生成、通常運用、確認、復旧の手順を構成ごとに分けておかなければ、長期運用では復元可能性を失う。暗号化デバイスと LVM を組み合わせる場合、設計の本体はコマンド列ではなく、どの層を先に開き、どの層を後から認識し、どの層を最後にマウントするかを明確にすることにある。

---

13. ファイルシステムと媒体を段階的に点検する

暗号化デバイスの点検では、「開けるか」だけを確認しても不十分である。cryptsetup open が成功して /dev/mapper/crypt_name が作成されても、その上のファイルシステムが壊れていれば mount や読み取りに失敗する。さらに、ファイルシステムが正常に見えても、物理媒体に不良セクター、USB 接続不良、電源断、I/O エラーがあれば、将来の復元可能性は低下する。したがって、点検では、暗号化層、mapper 層、ファイルシステム層、マウント状態、読み取り確認、媒体状態を順番に確認する必要がある。e2fsck は ext2 / ext3 / ext4 ファイルシステムを検査するためのコマンドであり、fsck は filesystem check のフロントエンドとして使われる[23][24]。

13.1 まず暗号化層を開けるか確認する

点検の最初に確認するのは、LUKS デバイスを解除できるかである。この段階では、まだファイルシステムの健全性までは分からない。確認できるのは、対象デバイスが正しく、LUKS ヘッダーが読め、keyfile またはパスフレーズで解除でき、復号後の mapper device を作れるということである。ここで失敗する場合、問題は ext4 ではなく、対象デバイス、LUKS ヘッダー、key slot、keyfile、パスフレーズ、または cryptsetup の指定にある。

期待される結果は、/dev/mapper/crypt_name が作成されることである。ここで /dev/sdX は LUKS ヘッダーを持つ元デバイスであり、crypt_name は復号後に作成される mapper 名である。open が成功したら、次に status と lsblk -f で、暗号化層が期待どおり開いているかを確認する。

cryptsetup status では mapper が active になっていることを確認する。lsblk -f では、物理デバイス、crypto_LUKS、mapper device、ファイルシステム、マウントポイントの関係を確認する。この段階で mapper は存在するが mount されていない状態なら、ファイルシステム検査へ進む前提が整っている。

13.2 ファイルシステム検査は未マウント状態で行う

ext4 の点検では、原則としてファイルシステムをマウントしていない状態で e2fsck を実行する。マウント中のファイルシステムに対して修復を行うと、カーネルが認識している状態と e2fsck が変更する状態が衝突する危険がある。したがって、暗号化デバイスを open した後、まだ mount していない /dev/mapper/crypt_name を対象にして検査する。

このコマンドの目的は、/dev/mapper/crypt_name 上の ext4 ファイルシステムを強制的に検査することである。-f は、通常なら検査不要と判断される場合でも明示的に検査する指定である。期待される結果は、重大なエラーが報告されず、ファイルシステムが整合した状態であることを確認できることである。エラーが報告された場合は、その場で機械的に修復を進めるのではなく、データ救出を優先すべき状況か、修復してよい状況かを判断する。

状態	意味	次の対応
エラーなし	ファイルシステムの整合性に大きな問題が見つかっていない状態である。	読み取り専用マウントまたは通常マウントへ進む。
軽微な修正あり	ファイルシステム上の不整合が検出され、修正された状態である。	修正内容を記録し、読み取り確認とバックアップ確認を行う。
重大なエラーあり	ファイルシステム破損、媒体障害、過去の異常終了などが疑われる状態である。	修復を続ける前に、読み取り専用でのデータ救出、媒体状態確認、バックアップ有無を確認する。
検査不能	対象指定の誤り、暗号化層の問題、I/O エラー、ファイルシステム種別の誤認が疑われる状態である。	lsblk -f、cryptsetup status、dmesg、媒体状態を確認し、層を切り分ける。

13.3 復旧時は読み取り専用マウントを優先する

通常点検では e2fsck の後に通常マウントしてもよいが、異常が疑われる復旧時には、まず読み取り専用マウントを試すほうが安全である。読み取り専用マウントは、ファイルシステムへ新しい書き込みを行わずに内容を確認するための手段である。ファイルシステム破損や媒体劣化が疑われる場合、先にデータを読めるだけ救出し、その後に修復を検討するほうがよい。

期待される結果は、/mnt/crypt_name 以下で既存ファイルを読み取れる状態になることである。読み取り専用でマウントできる場合は、重要データの退避、ディレクトリ一覧の取得、必要ファイルのコピーを優先する。読み取り専用でもマウントできない場合は、ファイルシステム破損がより深い、または媒体側の I/O エラーが発生している可能性がある。

13.4 読み取り確認では代表ディレクトリだけで終わらせない

マウントできたことと、必要なデータが読めることは同じではない。マウント成功後は、代表的なディレクトリを一覧し、重要なファイルを実際に読み取り、必要であればハッシュ確認やバックアップ先との比較を行う。これは、ファイルシステムが mount できても、一部のファイルやディレクトリで I/O エラーが出る場合があるためである。

この確認の目的は、ファイルシステム全体を完全検査することではなく、最低限の読み取り可能性を確認することである。期待される結果は、ディレクトリ一覧が取得でき、代表的なファイルが読めることである。バックアップ媒体や長期保管媒体では、さらに重要ディレクトリを対象にした読み取り確認、容量確認、差分確認、ハッシュ確認を組み合わせると、復元可能性の評価が安定する。

13.5 媒体状態は smartctl で別に確認する

ファイルシステムの検査結果だけでは、物理媒体の状態は分からない。HDD や SSD では、代替処理済みセクター、不良セクター、温度、電源投入時間、自己診断結果などを別に確認する必要がある。smartmontools は S.M.A.R.T. 情報を確認するための代表的なツールである[25]。ただし、USB 接続の外付け媒体では、USB-SATA ブリッジの仕様により S.M.A.R.T. 情報が取得できない場合がある。

このコマンドの目的は、物理媒体側の状態を確認することである。期待される結果は、デバイスの型番、シリアル、通電時間、エラー履歴、自己診断結果などを確認できることである。ここで見る対象は /dev/mapper/crypt_name ではなく、物理デバイス側の /dev/sdX である。smartctl は暗号化層や ext4 を見るコマンドではないため、mapper device に対して実行しても、媒体診断としては意味がずれる。

確認対象	見る内容	判断内容
通電時間	Power_On_Hours などを見る。	長期運用媒体として使用時間が大きくなっていないかを確認する。
不良セクター	Reallocated、Pending、Offline_Uncorrectable などを見る。	読み取り不能や再配置が発生していないかを確認する。
温度	Temperature 関連の値を見る。	高温状態が継続していないかを確認する。
自己診断	SMART overall-health self-assessment や self-test log を見る。	媒体側が異常を報告していないかを確認する。

13.6 点検後は必ず閉じる手順まで実施する

点検は、開いて確認したところで終わりではない。暗号化デバイスを開き、必要に応じてマウントした場合は、最後に sync、umount、close まで実施する。特に読み取り専用マウントであっても、運用手順としては明示的にアンマウントし、mapper device を閉じるところまでを点検手順に含める。

期待される結果は、/mnt/crypt_name がアンマウントされ、/dev/mapper/crypt_name が消えることである。点検後に mapper device が残ったままだと、次回作業時に現在開いている状態なのか、新しく開いた状態なのかが分かりにくくなる。lsblk -f や cryptsetup status で、点検後の状態が閉じていることを確認しておくとよい。

13.7 点検結果は台帳へ残す

点検の目的は、その場で安心することではなく、長期運用上の判断材料を残すことである。暗号化デバイスは、数年後に同じ手順で開けるか、同じ媒体がまだ使えるか、同じ keyfile と非常用パスフレーズが機能するかを継続的に確認する必要がある。そのため、点検結果は台帳へ記録する。

台帳項目	記録する内容	目的
点検日	点検を実施した日付を記録する。	最終確認日を明確にする。
対象媒体	by-id、LUKS UUID、mapper 名、マウントポイントを記録する。	どの暗号化デバイスを点検したかを明確にする。
解除確認	keyfile、非常用パスフレーズ、必要な key slot の確認結果を記録する。	将来も開ける状態が維持されているかを確認する。
ファイルシステム検査	e2fsck の結果、修正有無、異常内容を記録する。	ファイルシステムの整合性を追跡する。
読み取り確認	読み取り専用マウント、代表ディレクトリ確認、重要ファイル確認の結果を記録する。	データが実際に読めることを確認する。
媒体状態	smartctl の主要結果、不良セクター、温度、自己診断結果を記録する。	媒体交換や退役判断の材料にする。
次回対応	継続利用、再点検、移行、退役候補などを記録する。	点検結果を運用判断へ接続する。

この章の要点は、点検対象を 1 つに絞らないことである。暗号化層が開けること、mapper が存在すること、ext4 が整合していること、読み取りできること、物理媒体が健全であること、点検後に安全に閉じられることは、それぞれ別の確認である。暗号化デバイスの長期運用では、これらを一連の点検手順として実施し、結果を台帳に残すことで、復元可能性を継続的に確認できる。

---

14. 暗号構成を棚卸しし、移行要否を判断する

この章で点検する対象は、ファイルシステムの整合性や物理媒体の故障ではない。ここで確認するのは、暗号化デバイスがどの世代の暗号構成で作られているかである。具体的には、LUKS1 か LUKS2 か、AES-CBC-ESSIV か AES-XTS か、PBKDF2 か Argon2id か、有効な key slot がいくつあるか、現在の運用標準から見て主系として維持すべきか、互換用として残すべきか、移行対象にすべきかを判断する。つまり、この章は「壊れていないか」を見る手順ではなく、「長期運用上、現在の暗号構成をどう位置付けるか」を決める棚卸し手順である。

暗号構成の棚卸しは、毎回のマウント時に行うものではない。実施する契機は、年次点検、OS のメジャーアップグレード前後、cryptsetup の大きな更新後、新しい暗号化デバイスを作成するとき、古い LUKS1 媒体や TrueCrypt 由来の資産を発見したとき、key slot を整理するとき、ヘッダーバックアップを取り直すとき、媒体を退役させるか判断するときである。普段の通常運用では open、mount、sync、umount、close の流れを固定すればよいが、長期運用では定期的に暗号構成そのものを読み直し、当時の標準が現在どの位置にあるかを確認する必要がある。

暗号構成の確認では、まず luksDump を使う。luksDump は LUKS ヘッダーに記録された情報を表示するコマンドであり、LUKS version、UUID、cipher、data segment、key slot、KDF、salt、digest などを確認できる。ここで見るべき中心は、細部の値をすべて暗記することではなく、暗号化デバイスの世代と運用上の扱いを判断できる情報である。たとえば、Version が 1 で cipher mode が cbc-essiv:sha256 なら、旧来の LUKS1 構成として扱う。Version が 2 で aes-xts-plain64、PBKDF が Argon2id なら、現在の主系に近い構成として扱いやすい。

期待される結果は、対象デバイスの LUKS version、UUID、暗号方式、key slot、KDF が確認できることである。ここで /dev/sdX は説明用の仮名であり、実際には対象の LUKS デバイスに置き換える。重要なのは、この出力を単なる確認ログとして流さないことである。出力結果を台帳と照合し、作成時期、現在の用途、解除手段、ヘッダーバックアップの有無、退役条件と結び付けて読む必要がある。

確認項目	見る場所	判断すること
LUKS version	Version 行を見る。	LUKS1 旧構成か、LUKS2 現行構成かを判断する。
暗号方式	Cipher、Cipher mode、Data segments を見る。	AES-CBC-ESSIV 系か、AES-XTS 系かを確認し、ディスク暗号化方式としての世代を判断する。
KDF	PBKDF、Iterations、Memory、Threads を見る。	PBKDF2 中心の旧構成か、Argon2id を使う現行構成かを判断する。
key slot	Key Slot または Keyslots を見る。	通常運用用、非常用、用途不明の解除入口が残っていないかを確認する。
LUKS UUID	UUID 行を見る。	台帳、crypttab、ヘッダーバックアップと同じ対象かを照合する。

AES、CBC、XTS、PBKDF2、Argon2id は、それぞれ見る場所が違う。AES はデータを暗号化するための block cipher であり、CBC や XTS は AES をディスクのような大きなデータへ適用するための mode である[26][27]。ストレージ暗号化では、ディスク上の位置を暗号化に組み込む XTS-AES が重要であり、NIST SP 800-38E は XTS-AES を storage device 上の confidentiality のための mode として扱っている[28]。一方、PBKDF2 や Argon2id はデータ本体を暗号化する方式ではなく、パスフレーズや keyfile から key slot を開くための鍵材料を導出する仕組みである[29][30]。

この違いを混同すると、運用判断を誤る。たとえば、Argon2id が使われているから大量ファイルコピーが遅い、と考えるのは基本的に誤りである。KDF は主に unlock 時、key slot 追加時、パスフレーズ確認時に効く。いったん暗号化デバイスを開いた後のコピー速度には、データ暗号化方式、CPU の AES 支援、ファイルシステム、媒体性能、USB ブリッジ、I/O パターンが影響する。したがって、luksDump の KDF 表示は「解除試行への耐性」を読むための情報であり、「通常の読み書き性能」を直接説明する情報ではない。

暗号構成の棚卸しでは、現在の標準に合っているかだけでなく、将来の移行可能性も見る必要がある。NIST は SP 800-38E の更新提案を出しており、現在の標準も将来にわたって固定されるものではない[31]。また、暗号化デバイスの長期運用では、鍵管理とアルゴリズム移行をライフサイクルとして扱う必要があり、NIST の鍵管理ガイドラインや暗号アルゴリズム移行指針はその背景資料になる[32][33]。現在の LUKS2、AES-XTS、Argon2id も、将来は「当時の標準」として見直し対象になる。

棚卸し結果	意味	運用判断
LUKS2 + AES-XTS + Argon2id	現在の主系として扱いやすい構成である。	新規作成標準として維持し、ヘッダーバックアップと key slot 台帳を整備する。
LUKS1 + AES-CBC-ESSIV + PBKDF2	旧来の実用構成であり、直ちに破綻しているとは限らないが現行主系ではない。	互換用、読み取り中心、移行対象として分類し、新規主系として増やさない。
用途不明の key slot が多い	過去のパスフレーズや一時解除手段が残っている可能性がある。	key slot の照会、非常用経路の確認、ヘッダーバックアップ取得後に整理する。
台帳と UUID が一致しない	対象デバイス、ヘッダーバックアップ、設定ファイルの対応が崩れている可能性がある。	破壊的操作へ進まず、by-id、luksDump、crypttab、fstab、台帳を照合する。
古いが復旧経路として意味がある	主系ではないが、過去データや移行失敗時の逃げ道として価値がある。	役割を限定し、読み取り確認、保管条件、退役条件を明文化する。

この章の要点は、暗号方式と KDF を抽象的な知識として説明することではない。luksDump の結果を読み、暗号化デバイスを現在の主系、互換用、移行対象、退役候補のどれとして扱うかを判断することである。暗号構成の棚卸しは、日常の open / mount 作業ではなく、長期運用の節目で実施する設計点検である。ここで得た結果は、key slot 整理、ヘッダーバックアップ更新、crypttab / fstab 見直し、新媒体への移行、旧媒体の退役判断へ接続する。

---

15. TrueCrypt / TCRYPT 既存資産は互換バックアップとして位置付けて管理する

cryptsetup は LUKS だけでなく、TrueCrypt / VeraCrypt 系の TCRYPT コンテナも扱える。したがって、TrueCrypt 7.1a で作成した既存資産は、単に「古いから即移行して消す対象」として扱うべきではない。TrueCrypt は保守終了しているため、新規主系として増やす対象ではないが、既に存在する暗号化コンテナや暗号化ディスクは、過去データへ到達するための互換バックアップとして意味を持つ場合がある。ここで重要なのは、TrueCrypt / TCRYPT 既存資産を、現行主系、互換バックアップ、読み取り中心アーカイブ、移行対象、退役候補のどれとして扱うかを明確に分類することである。

TrueCrypt のユーザーガイドは TrueCrypt の方式を説明しているが、TrueCrypt は現在では保守終了している[34]。BSI の TrueCrypt 分析や NCC Group の Phase Two Audit は、過去資産を冷静に評価するための資料であり、永続利用の保証ではない[35][36][37]。したがって、判断は二分法ではなく、役割に応じて行う必要がある。通常更新を続ける主系としては LUKS2 へ寄せる。一方で、過去環境との互換性、FAT で作成された旧媒体の読みやすさ、過去バックアップ状態の保全、LUKS + ext4 移行時の性能問題に対する逃げ道としては、TrueCrypt / TCRYPT 既存資産を一定期間残す合理性がある。

まず行うべきことは、TCRYPT 既存資産が現在も開けるか、どの方式で作られているか、どのデータを保持しているかを確認することである。tcryptDump は TCRYPT ヘッダー情報の確認に使う[38]。この確認は、データを変更する操作ではなく、対象が TCRYPT として認識されるかを確認するための調査である。期待される結果は、TCRYPT コンテナとして認識され、暗号方式やヘッダー情報を確認できることである。

次に、TCRYPT コンテナを mapper device として開く。open –type tcrypt は、TrueCrypt / VeraCrypt 系のコンテナやデバイスを cryptsetup で開くための操作である。ここで /path/to/container.tc はファイルコンテナの例であり、実際にはデバイス全体やパーティションを指定する場合もある。期待される結果は、/dev/mapper/tcrypt_name が作成されることである。

既存資産の初回確認では、まず読み取り専用マウントを基本にする。これは、TrueCrypt / TCRYPT 資産を今後一切更新してはならないという意味ではない。初回確認、棚卸し、移行前調査、媒体状態が不明な場合には、書き込みを避けて内容を確認するほうが安全だからである。期待される結果は、/mnt/tcrypt_name 以下で既存ファイルを読み取れる状態になることである。

ただし、TrueCrypt / TCRYPT 既存資産を互換バックアップとして有効に残す場合、常に読み取り専用でなければならないわけではない。たとえば、既存の TrueCrypt + FAT 媒体が現在も開け、媒体状態に問題がなく、主系 LUKS2 とは別系統の互換バックアップとして役割を持ち、更新手順と退役条件が台帳化されているなら、限定的な更新対象として扱う余地がある。この場合でも、更新前には別系統のバックアップが存在することを確認し、更新後に読み取り確認を行い、最終更新日と同期元を台帳へ記録する必要がある。

位置付け	扱い方	判断基準
現行主系	新規採用しない。	保守終了しているため、現在の主系暗号化ディスクとして増やす対象ではない。
互換バックアップ	役割を限定して保持する。	過去データ、旧環境、移行失敗時の逃げ道として有効なら、台帳化して残す。
読み取り中心アーカイブ	原則として読み取り確認とデータ救出を目的に扱う。	更新の必要がなく、過去状態の保全が主目的なら読み取り中心にする。
限定更新対象	条件付きで更新する。	別系統バックアップがあり、更新手順、確認手順、退役条件が明確な場合に限る。
移行対象	LUKS2 などの現行主系へ同期する。	互換バックアップとしての役割より、保守終了や媒体劣化のリスクが上回る場合に移行する。
退役候補	復元確認後に保管停止または安全消去する。	同等データが現行主系と別系統に存在し、互換バックアップとしての役割が終わった場合に退役させる。

更新を許可する場合の通常運用では、TCRYPT コンテナを開き、通常マウントし、作業後に sync、umount、close で閉じる。ここで重要なのは、TrueCrypt / TCRYPT を「古いがまだ使えるから漫然と使う」のではなく、「互換バックアップとして、どの範囲で更新を許すか」を明確にすることである。更新対象にするなら、主系ではないこと、更新頻度、同期元、確認方法、退役条件を台帳へ記録する。

TrueCrypt / TCRYPT 既存資産の管理で避けるべきなのは、読み取り専用移行対象としてしか見ないことと、逆に現行主系と同じ扱いで使い続けることの両方である。前者では、互換バックアップとしての価値を過小評価する。後者では、保守終了した方式を無期限に主系へ残すことになる。適切なのは、現行主系ではなく、互換バックアップまたは移行対象として役割を明示し、確認、更新、同期、退役の条件を運用設計に落とし込むことである。

この章の要点は、TrueCrypt / TCRYPT 既存資産を単純に「古いので廃止」と判断しないことである。保守終了は重要なリスクであるが、長期運用では過去資産に到達できること自体も復元可能性の一部である。したがって、TrueCrypt / TCRYPT は新規主系としては採用せず、既存資産については、互換バックアップ、読み取り中心アーカイブ、限定更新対象、移行対象、退役候補として分類し、役割がある間は管理し、役割が終わったら復元経路を損なわずに退役させる。

---

16. 定期点検では解除可能性、鍵、媒体状態を確認する

暗号化デバイスの定期点検は、毎日の通常運用で機械的に実行するものではない。目的は、平時に暗号化デバイスを開けること、必要な解除手段が生きていること、LUKS ヘッダーと key slot が台帳どおりであること、keyfile が想定どおり保全されていること、物理媒体に劣化兆候がないことを確認することである。通常運用では open、mount、sync、umount、close を実施すればよいが、それだけでは「非常時にも開けるか」「古い key slot が残っていないか」「keyfile が別物に置き換わっていないか」「媒体が劣化していないか」は分からない。したがって、定期点検は日常の利用手順ではなく、復元可能性を維持するための保守手順として位置付ける。

点検頻度は、すべての暗号化デバイスで同じにする必要はない。更新頻度が高く、現在の主系として使っている暗号化ディスクは、月次または四半期で確認する価値がある。互換バックアップや読み取り中心アーカイブは、頻繁に触るよりも、半年または年 1 回の棚卸しで、開けること、読めること、媒体状態に異常がないことを確認するほうが現実的である。さらに、key slot の追加や削除、ヘッダーバックアップ取得、OS のメジャーアップグレード、cryptsetup 更新、媒体交換、移行作業、退役判断の前後では、定期周期とは別に都度点検する必要がある。

契機	実施頻度	目的
主系暗号化ディスク	月次または四半期で確認する。	通常運用で使う解除手段、ファイルシステム、媒体状態が継続して正常であることを確認する。
互換バックアップ	半年または年 1 回で確認する。	普段使わない旧構成が、復旧経路としてまだ開けることを確認する。
読み取り中心アーカイブ	年 1 回または重要な棚卸し時に確認する。	過去データを読める状態が維持されていることを確認する。
key slot 変更前後	変更の都度実施する。	通常用 keyfile と非常用パスフレーズが意図どおり残っていることを確認する。
OS / cryptsetup 更新前後	更新の都度実施する。	更新後も既存の LUKS デバイスや TCRYPT 既存資産を開けることを確認する。
移行・退役判断前	判断の都度実施する。	移行元が読めること、移行先が復元可能であること、退役後も復旧経路が残ることを確認する。

定期点検では、暗号化層、鍵管理層、ファイルシステム層、媒体層を分けて確認する。暗号化層では luksDump により LUKS version、UUID、暗号方式、key slot、KDF を確認する。鍵管理層では、通常運用用 keyfile と非常用パスフレーズの両方で test-passphrase を行い、どちらの解除経路も機能していることを確認する。媒体層では smartctl により S.M.A.R.T. 情報を確認する。smartmontools は SMART 情報を取得する代表的なツールであり、媒体劣化の兆候を把握するために使える。

luksDump では、対象デバイスが台帳に記録された LUKS UUID と一致していること、有効な key slot が想定どおりであること、用途不明の解除入口が残っていないことを確認する。test-passphrase は、実際に mapper device を作らず、解除できるかだけを確認するために使う。keyfile 指定の test-passphrase が成功すれば、通常運用用 keyfile による解除経路が生きていることが分かる。keyfile を指定しない test-passphrase が成功すれば、非常用パスフレーズによる手動解除経路が生きていることが分かる。

smartctl では、暗号化とは別に物理媒体の状態を確認する。ここで見る対象は /dev/mapper/crypt_name ではなく、物理デバイスである /dev/sdX である。代替処理済みセクター、保留中セクター、訂正不能エラー、通電時間、温度、自己診断結果などを確認し、劣化傾向がある場合は移行または退役を検討する。USB 接続の外付け媒体では、USB-SATA ブリッジの仕様により SMART 情報が取得できない場合があるため、その場合は読み取り確認や同期時の I/O エラー有無も含めて判断する。

sha256sum による keyfile の確認は、keyfile の内容が台帳に記録されたものと一致するかを確認するために使う。ただし、keyfile の hash も機微情報に準じて扱うべきであり、公開ログや不用意な共有場所に残してはならない。keyfile そのものを表示するのではなく、台帳に記録した hash と照合することで、誤って別ファイルに置き換わっていないか、バックアップから復元した keyfile が正しいかを確認できる。

確認対象	確認方法	正常と判断できる状態
LUKS ヘッダー	luksDump で Version、UUID、key slot、KDF を確認する。	台帳と UUID が一致し、有効 key slot が想定どおりである。
通常用 keyfile	–key-file を指定して test-passphrase を実行する。	mapper を作らずに解除確認が成功する。
非常用パスフレーズ	keyfile なしで test-passphrase を実行する。	非常用パスフレーズで解除確認が成功する。
物理媒体	smartctl で SMART 情報を確認する。	重大なエラー、増加傾向のある不良セクター、高温継続などがない。
keyfile の同一性	sha256sum を台帳の値と照合する。	台帳に記録した hash と一致する。

定期点検の結果は、実施して終わりではなく、台帳へ記録する。記録すべき内容は、点検日、対象デバイス、LUKS UUID、確認した key slot、通常用 keyfile の確認結果、非常用パスフレーズの確認結果、SMART の主要結果、読み取り確認の有無、次回対応である。異常がなかった場合でも、最終確認日が更新されることに意味がある。長期運用では、「存在する媒体」ではなく、「最後にいつ、どの手段で、どこまで確認した媒体なのか」が復元可能性を左右する。

この章の要点は、定期点検を気まぐれな確認作業にしないことである。日次で毎回行うには重すぎるが、年単位で放置するには重要すぎる。主系は月次または四半期、互換バックアップやアーカイブは半年から年 1 回、構成変更や移行や退役判断の前後では都度実施する。定期点検の目的は、暗号化デバイスが今日使えることではなく、将来の障害時にも開ける状態を維持し続けることである。

---

17. 移行では新規 LUKS2 を作り、検証後に旧構成の役割を変更する

暗号化デバイスの移行では、古い構成をその場で無理に変換するより、新しい LUKS2 デバイスを作成し、旧構成からデータを同期し、復元確認が完了してから旧構成の役割を変更するほうが安全である。古い LUKS1、AES-CBC-ESSIV、PBKDF2、用途不明 key slot、TrueCrypt / TCRYPT 既存資産を発見した場合でも、最初に行うべきことは即時削除ではない。まず移行元を読める状態で保持し、新しい移行先を現在の標準に近い構成で作り、両方が存在する期間を確保する。これにより、方式を新しくしながら、移行失敗時の復元経路を失わずに済む。

移行の目的は、単に新しい暗号化デバイスを作ることではない。目的は、データ、所有者、権限、ACL、拡張属性、hard link、マウント手順、解除手段、ヘッダーバックアップ、台帳を、新しい運用単位へ安全に移すことである。したがって、移行手順は、新規 LUKS2 作成、ファイルシステム作成、旧領域の読み取り確認、rsync による同期、差分再同期、移行先の読み取り確認、解除確認、起動設定確認、旧構成の役割変更、退役判断までを含める必要がある。

17.1 移行前に移行元を確認する

移行作業の最初に行うのは、移行元の状態確認である。移行元が LUKS1 なのか LUKS2 なのか、TrueCrypt / TCRYPT なのか、どの key slot で開けるのか、ファイルシステムが読めるのか、媒体状態に異常がないのかを確認する。移行元が不安定な状態であれば、書き込みを避け、読み取り専用で開いてデータ救出を優先する。移行元の確認を省略すると、移行先に不完全なデータを同期しても気づけない。

この手順では、まず luksDump で移行元の LUKS ヘッダーと key slot を確認し、次に cryptsetup open で移行元を開き、lsblk -f で物理デバイス、LUKS、mapper、ファイルシステム、マウントポイントの対応を確認する。その後、初回確認では読み取り専用でマウントする。期待される結果は、移行元が正しい対象であり、/mnt/old_crypt から既存データを読めることである。移行元が通常運用中の現役領域で、更新停止時間を設けて移行する場合は、後続の差分同期のために、どの時点で更新を止めるかを決めておく。

17.2 移行先の LUKS2 デバイスを新規作成する

移行先は、現在の主系として使う前提で LUKS2 を明示して作成する。対象デバイスを取り違えると移行元や別媒体を破壊するため、luksFormat の前に必ず対象を確認する。ここで行う luksFormat は破壊的操作であり、/dev/newDevice 上の既存データは失われる。移行先は、作成直後に keyfile、非常用パスフレーズ、ヘッダーバックアップまで整備しておくと、その後の検証と台帳化が安定する。

期待される結果は、/dev/newDevice に LUKS2 ヘッダーが作成され、/dev/mapper/new_crypt が現れることである。この時点では、移行先は暗号化デバイスとして開かれているだけであり、まだファイルシステムは存在しない。通常運用で keyfile を使う場合は、この段階で keyfile を追加し、非常用パスフレーズを残すかどうかを設計に従って決める。

この確認により、移行先が通常運用用 keyfile で開けること、有効な key slot が想定どおりであることを確認する。非常用パスフレーズを別 key slot に残す場合は、keyfile なしの test-passphrase でも確認する。移行先の key slot が整理される前に大量データを同期すると、後から解除経路を見失いやすいため、解除手段は移行初期に確定しておくほうがよい。

17.3 移行先にファイルシステムを作成してマウントする

移行先を開いた後は、復号後の mapper device にファイルシステムを作成する。mkfs.ext4 の対象は /dev/newDevice ではなく、/dev/mapper/new_crypt である。暗号化前の元デバイスに mkfs を実行すると LUKS ヘッダーを壊す危険があるため、ここでは必ず復号後の mapper device を対象にする。

期待される結果は、/mnt/new_crypt が空の移行先ファイルシステムとして利用可能になることである。ここで lsblk -f を実行し、/dev/newDevice、/dev/mapper/new_crypt、ext4、/mnt/new_crypt の対応を確認する。LVM と組み合わせる場合は、前章で整理した構成に従い、LUKS の上に LVM を作るのか、LVM の上に LUKS を作るのかを先に確定する必要がある。

17.4 rsync でデータを同期する

データ同期では、単純にファイル内容だけをコピーするのではなく、所有者、グループ、権限、時刻、hard link、ACL、拡張属性を維持する必要がある。特にシステム領域やホームディレクトリ、アプリケーションデータ、バックアップ領域では、所有者や権限が変わるだけで復元後に動作が変わる。したがって、移行では cp よりも rsync を使い、何を保存するかを option として明示するほうがよい。

この rsync は、移行元 /mnt/old_crypt/ の内容を移行先 /mnt/new_crypt/ へ同期する。-a は archive mode であり、基本的な属性を維持する。-H は hard link、-A は ACL、-X は拡張属性を維持する。–numeric-ids はユーザー名やグループ名ではなく数値 ID として所有者を保持するため、別環境でユーザー名の解決結果が変わる場合にも意味がずれにくい。期待される結果は、移行先に移行元と同じファイル構造が再現されることである。

末尾の slash も重要である。/mnt/old_crypt/ のように末尾に slash を付けると、old_crypt ディレクトリそのものではなく、その中身が /mnt/new_crypt/ へ同期される。末尾 slash の有無を誤ると、移行先に /mnt/new_crypt/old_crypt のような余分な階層ができる場合がある。移行手順では、rsync の option だけでなく、同期元と同期先のパス構造も台帳または作業手順書に明記する。

option	意味	移行で必要な理由
-a	再帰、権限、所有者、グループ、時刻、シンボリックリンクなどを維持する。	通常のファイルコピーより、復元後の状態を元環境に近づけられる。
-H	hard link の関係を維持する。	同じ実体を複数パスから参照している構造を壊しにくくする。
-A	ACL を維持する。	通常の Unix permission だけでは表せないアクセス制御を保持する。
-X	拡張属性を維持する。	セキュリティ属性やアプリケーション固有属性を保持する。
–numeric-ids	ユーザー名ではなく数値 UID / GID として所有者を扱う。	移行先環境で名前解決が変わっても所有者の意味を保ちやすい。

17.5 更新がある領域では差分再同期を行う

移行中に移行元が更新される可能性がある場合、一度の rsync だけで完了とみなしてはならない。最初の同期は大量データを移すための初回同期であり、その後に更新を停止して差分再同期を行う。Web サービス、データベース、メールスプール、ログ、ホームディレクトリなどは、移行中に変化しやすい。更新が続く領域では、停止時間を設けるか、アプリケーションごとのバックアップ手順を使う必要がある。

この差分再同期では、–delete を付けることで、移行元で削除済みのファイルを移行先からも削除する。期待される結果は、移行先が移行元の最終状態に近づくことである。ただし、–delete は強い option であり、同期元と同期先を取り違えると移行先の必要データを削除する危険がある。したがって、–delete を使うのは、初回同期後、同期方向が確定し、移行先を移行元に揃える段階に限定する。

17.6 移行先を検証する

移行完了後は、移行先が開けること、マウントできること、主要ファイルが読めること、所有者と権限が維持されていること、容量とファイル数が大きくずれていないことを確認する。ここで確認するのは、rsync が終了したかどうかではなく、移行先を復元先として実際に使えるかである。暗号化デバイスの移行では、データ同期、解除手段、ファイルシステム、マウント手順をすべて確認する必要がある。

この手順では、いったん移行先を閉じてから、通常運用で使う keyfile で再度開き直している。期待される結果は、移行先が通常運用と同じ手順で開き、マウントでき、主要ディレクトリを読めることである。単に作成直後の開いた状態で読めるだけでは、復旧手順としての確認にはならない。閉じて、開き直し、マウントし直すことで、将来の通常利用や復旧時にも使えることを確認する。

ファイル数確認は完全な同一性検査ではないが、大きな欠落を発見するための簡易確認として有効である。期待される結果は、移行元と移行先のファイル数が大きくずれていないことである。ただし、ファイルシステム固有の lost+found、同期除外、実行中に変化したログなどにより、完全一致しない場合もある。重要なのは、差異が説明できるかどうかである。

17.7 起動時自動解除やマウント設定を切り替える

移行先を通常利用に切り替える場合は、crypttab と fstab の更新が必要になる。crypttab では新しい LUKS UUID、mapper 名、keyfile を指定し、fstab では新しい mapper device またはファイルシステム UUID とマウントポイントを対応させる。ここで旧媒体の UUID を残したままにすると、起動時に旧構成を開こうとしたり、意図しない媒体をマウントしようとしたりする。

この段階では、すぐに設定を書き換える前に、必要な識別子を確認する。luksDump で新しい LUKS UUID を確認し、blkid で復号後のファイルシステム UUID を確認する。crypttab は暗号化デバイスを開く設定であり、fstab は開いた後のファイルシステムをマウントする設定である。切替後は、再起動または systemd の設定反映により、新しい移行先が想定どおり自動解除・自動マウントされることを確認する。

17.8 旧構成はすぐ消さずに役割を変更する

移行後の旧構成は、すぐに削除するのではなく、いったん役割を変更する。たとえば、旧 LUKS1 媒体は主系から外し、互換バックアップ、読み取り中心アーカイブ、退役候補のいずれかへ分類する。TrueCrypt / TCRYPT 既存資産も同様に、現行主系ではなく、互換バックアップ、限定更新対象、移行済み退役候補として扱う。移行直後は、新構成に見落としがある可能性があるため、一定期間は旧構成を復元経路として保持するほうが安全である。

旧構成の扱い	条件	運用
互換バックアップ	旧構成がまだ開け、過去環境や移行失敗時の逃げ道として価値がある。	読み取り確認と点検周期を決め、主系とは別系統として保持する。
読み取り中心アーカイブ	更新は不要だが、過去状態を保持する意味がある。	原則として読み取り専用で扱い、年 1 回程度の棚卸しで開けることを確認する。
退役候補	移行先と別系統バックアップで復元可能性が確保されている。	一定期間保持した後、保管停止または安全消去を検討する。
安全消去対象	役割が終わり、保持する必要がなく、漏洩リスクを減らしたい。	データの存在確認、退役承認、台帳更新後に消去する。

17.9 移行完了条件を明文化する

移行完了は、rsync が終了した時点ではない。移行先が通常手順で開けること、マウントできること、主要データを読めること、keyfile と非常用パスフレーズが機能すること、ヘッダーバックアップを取得したこと、crypttab と fstab の切替が確認されたこと、旧構成の役割を台帳に記録したことまで確認して、初めて移行完了と判断する。暗号化デバイスの移行では、データ移動よりも、移行後に復元可能性を維持できるかが本質である。

完了条件	確認内容	未実施時のリスク
移行先の解除確認	通常用 keyfile と非常用パスフレーズで test-passphrase が通る。	障害時に移行先を開けない可能性がある。
移行先の mount 確認	通常運用と同じ手順で mount できる。	解除はできてもファイルシステムを利用できない可能性がある。
データ確認	主要ディレクトリ、ファイル数、容量、必要に応じてハッシュを確認する。	欠落や同期方向の誤りに気づけない。
ヘッダーバックアップ	移行先 LUKS ヘッダーを取得し、UUID と取得日を記録する。	ヘッダー破損時に復旧経路を失う。
自動起動設定	crypttab、fstab、mapper 名、UUID、mount point を確認する。	再起動後に自動解除または mount に失敗する。
旧構成の役割変更	互換バックアップ、読み取り中心アーカイブ、退役候補のいずれかへ分類する。	旧媒体を主系のまま使い続けたり、必要な復元経路を誤って消したりする。

移行完了後には、移行先の LUKS ヘッダーをバックアップし、台帳を更新する。ここで記録するべき内容は、新旧デバイスの by-id、LUKS UUID、mapper 名、ファイルシステム UUID、mount point、key slot 構成、ヘッダーバックアップの場所、同期実施日、最終確認日、旧構成の役割である。これにより、移行作業がその場限りのコピーではなく、次回以降の通常運用と復旧手順に接続される。

この章の要点は、移行を「古い暗号方式から新しい暗号方式へ移す作業」とだけ見ないことである。移行は、暗号形式、key slot、ヘッダー、ファイルシステム、所有者、権限、起動設定、台帳、旧構成の役割をまとめて更新する作業である。安全な移行とは、旧構成をすぐ消すことではなく、新構成が十分に検証されるまで旧構成を復元経路として保持し、検証後に互換バックアップ、読み取り中心アーカイブ、退役候補へ役割を変更することである。

---

18. 復旧時は観測、解除、読み取り、救出、修復の順に進める

暗号化デバイスの復旧では、いきなり fsck、e2fsck、luksHeaderRestore、再フォーマット、再同期を実行してはならない。復旧時に最初に行うべきことは、壊れている箇所を直すことではなく、どの層で失敗しているのかを観測することである。暗号化デバイスは、物理媒体、パーティション、LUKS ヘッダー、key slot、mapper device、LVM、filesystem、mount point という複数の層で構成される。どの層まで正常に到達でき、どの層で失敗しているかを切り分けないまま修復操作を行うと、まだ救出できるデータへ書き込みを加え、復旧可能性を下げる危険がある。

復旧手順の基本順序は、観測、解除確認、読み取り専用マウント、データ救出、修復判断、通常復帰確認である。観測では、対象デバイス、LUKS ヘッダー、UUID、mapper、LVM、filesystem の見え方を確認する。解除確認では、keyfile と非常用パスフレーズが使えるかを確認する。読み取り専用マウントでは、書き込みを行わずにデータへ到達できるかを確認する。データ救出では、修復より先に重要データを別媒体へ退避する。修復判断では、ヘッダー復元や e2fsck を実行すべきかを判断する。通常復帰確認では、復旧後に通常手順で開けるかを確認する。

段階	目的	実施すること
観測	どの層まで見えているかを確認する。	lsblk、blkid、luksDump、LVM コマンドで対象と層の状態を確認する。
解除確認	keyfile または非常用パスフレーズで LUKS を開けるか確認する。	test-passphrase を使い、mapper を作らずに解除可否を確認する。
読み取り専用マウント	書き込みを避けてデータへ到達できるか確認する。	復号後の mapper または LV を読み取り専用でマウントする。
データ救出	修復前に重要データを別媒体へ退避する。	rsync などで救出先へコピーし、読み取り不能箇所を記録する。
修復判断	ヘッダー復元や filesystem 修復を実行すべきか判断する。	バックアップ、台帳、対象 UUID、救出状況を確認してから修復する。
通常復帰確認	復旧後に通常運用へ戻せるか確認する。	通常用 keyfile、非常用パスフレーズ、mount、読み取りを再確認する。

18.1 まず対象デバイスを取り違えていないか確認する

復旧時に最も避けるべき事故は、壊れたデバイスではなく正常なデバイスへ修復操作を行うことである。/dev/sdX は接続順で変わるため、復旧時には特に信用してはならない。まず lsblk -f と blkid で、物理デバイス、LUKS、filesystem、UUID、mount point の関係を確認する。ここでの目的は、復旧対象が本当に意図した媒体であることを、容量、UUID、filesystem type、mount point、必要に応じて /dev/disk/by-id によって確認することである。

期待される結果は、復旧対象の物理デバイス、LUKS UUID、filesystem UUID、mapper 名、mount point の対応を説明できることである。この段階で対象が曖昧な場合、復旧操作へ進んではならない。特に luksHeaderRestore、e2fsck、rsync –delete、mkfs などは、対象を誤ると正常なデータを破壊する。復旧時は、対象を特定できないこと自体を重大な異常として扱う。

18.2 LUKS ヘッダーが読めるか確認する

対象デバイスが確定したら、次に LUKS ヘッダーが読めるかを確認する。luksDump が正常に読める場合、少なくとも LUKS ヘッダーの基本構造は認識できている。ここでは、Version、UUID、cipher、key slot、KDF を確認し、台帳やヘッダーバックアップの記録と照合する。luksDump が失敗する場合は、対象デバイスの取り違え、LUKS ではない領域を見ている、ヘッダー破損、物理媒体の I/O エラーなどを疑う。

期待される結果は、/dev/sdX が LUKS デバイスとして認識され、台帳に記録された UUID と一致することである。isLuks は対象が LUKS デバイスとして認識されるかを確認する簡易判定であり、luksDump はより詳細なヘッダー情報を表示する。ここで UUID が台帳と一致しない場合は、別のデバイスを見ているか、ヘッダーが想定外の状態になっている可能性があるため、復元操作へ進まず、対象確認へ戻る。

18.3 keyfile と非常用パスフレーズで解除できるか確認する

LUKS ヘッダーが読める場合、次に解除手段が生きているかを確認する。通常運用用 keyfile と非常用パスフレーズの両方を確認することで、障害が keyfile 側にあるのか、パスフレーズ側にあるのか、key slot 側にあるのかを切り分けられる。ここでは open –test-passphrase を使う。これは実際に /dev/mapper 以下へ mapper device を作らず、指定した解除手段で開けるかだけを確認するため、復旧初期の安全な確認に向いている。

期待される結果は、通常運用用 keyfile と非常用パスフレーズの少なくともどちらかで解除確認が成功することである。keyfile では失敗し、非常用パスフレーズでは成功する場合、keyfile のパス、内容、権限、台帳との hash 一致を確認する。非常用パスフレーズでは失敗し、keyfile では成功する場合、非常用パスフレーズの記録ミス、削除済み key slot、入力ミスを疑う。どちらも失敗する場合は、key slot、ヘッダー、対象デバイス、入力情報のいずれかに問題がある。

18.4 mapper を作成し、状態を確認する

解除確認が通る場合は、復旧用の mapper 名で LUKS デバイスを開く。復旧時には通常運用で使う mapper 名をそのまま使ってもよいが、状況確認や一時救出では recovery_crypt のような復旧用の名前を使うと、通常運用の設定と区別しやすい。open が成功したら、cryptsetup status と lsblk -f で、mapper が active になっていること、物理デバイスから mapper までの階層が想定どおりであることを確認する。

期待される結果は、/dev/mapper/recovery_crypt が作成され、cryptsetup status で active と表示されることである。この段階で mapper が作成できるなら、暗号化層の解除までは成功している。以後の問題は、LVM、filesystem、mount、媒体読み取りのいずれかにある可能性が高くなる。逆に mapper が作成できない場合は、まだ filesystem 修復へ進む段階ではない。

18.5 LVM 構成では先に層の順序を確認する

LUKS と LVM を組み合わせている場合、復旧時の順序は構成によって変わる。LUKS の上に LVM がある場合は、まず LUKS を開き、その後で VG を有効化し、LV を確認する。LVM の上に LUKS がある場合は、まず LVM を認識し、対象 LV を確認してから、その LV を LUKS として開く。順序を間違えると、存在するはずの LV が見えない、または開くべき LUKS デバイスが見つからないように見える。

期待される結果は、PV、VG、LV が台帳どおりに認識され、どの層に LUKS があるのかを説明できることである。LUKS の上に LVM がある構成では、recovery_crypt の上に LVM2_member が見え、その内部に LV が現れる。LVM の上に LUKS がある構成では、LV 自体が crypto_LUKS として見える。この違いを確認してから mount へ進む。

18.6 まず読み取り専用でマウントする

mapper または LV が見えたら、最初の mount は読み取り専用を基本にする。読み取り専用マウントの目的は、ファイルシステムへ新たな書き込みを行わずに、データへ到達できるかを確認することである。復旧時には、ファイルシステムの journal replay や修復書き込みが望ましくない場合もあるため、まず読み取り専用で状態を確認し、重要データを救出できるかを見る。

LVM の上にファイルシステムがある構成では、mount 対象は /dev/mapper/recovery_crypt ではなく、/dev/vg_name/lv_name になる。期待される結果は、/mnt/recovery 以下で既存データを読み取れることである。読み取り専用で mount できる場合は、修復より先にデータ救出を行う。読み取り専用でも mount できない場合は、filesystem 破損、未対応 filesystem、LVM の認識不整合、媒体 I/O エラーなどを疑う。

18.7 読めるうちに重要データを救出する

復旧時にデータへ到達できた場合、最初に行うべきことは修復ではなく救出である。修復操作は状況を改善する可能性がある一方で、状態を変化させる。媒体障害や filesystem 破損がある場合、修復の前に重要データを別媒体へ退避するほうが安全である。救出先は、十分な空き容量があり、別の物理媒体であり、可能であれば既に健全性を確認した領域にする。

期待される結果は、読み取れるデータが /mnt/rescue/ へ退避されることである。I/O エラーが出る場合は、どのパスで失敗したかを記録する。rsync は途中で失敗しても、再実行によって読める範囲を継続的に救出しやすい。救出目的では、完全な同期よりも、読めるデータを確保することを優先する。–delete は救出初期には原則として使わない。同期方向や救出先を誤った場合に、退避済みデータを消す危険があるためである。

18.8 filesystem 修復は救出後に判断する

filesystem 修復は、読み取り専用での確認と可能な範囲のデータ救出が終わってから判断する。ext4 の場合、e2fsck は有効な修復手段だが、未マウント状態で実行する必要がある。マウント中の filesystem に対して修復を行うと、カーネルが保持する状態と e2fsck の修正が衝突する危険がある。したがって、修復する場合は、まず umount し、対象が復号後の mapper または LV であることを確認してから実行する。

LVM 構成では、e2fsck の対象は filesystem が存在する LV になる場合がある。期待される結果は、filesystem の整合性が確認または修復されることである。ただし、重大なエラーが多数出る場合や、媒体 I/O エラーが継続している場合は、修復よりも媒体複製や追加救出を優先する判断もあり得る。e2fsck は「とりあえず実行する安全な確認」ではなく、filesystem を変更し得る修復操作として扱う。

18.9 LUKS ヘッダー復元は最後の復旧手段として扱う

luksHeaderRestore は、LUKS ヘッダーが破損している場合や key slot 変更に失敗した場合に使う復旧手段である。ただし、これは軽い修復ではない。対象デバイスの LUKS ヘッダーをバックアップ時点へ戻す操作であり、現在の key slot 状態もバックアップ時点へ戻る。したがって、luksDump が正常に読め、keyfile または非常用パスフレーズで解除できる状態では、通常は最初に使う操作ではない。

この操作を行う前には、対象デバイス、ヘッダーバックアップの取得日、LUKS UUID、対象媒体、復元後に有効になる key slot を台帳で確認する。期待される結果は、破損または不整合になった LUKS ヘッダーが、バックアップ時点の状態へ戻ることである。一方で、誤ったヘッダーを誤ったデバイスへ restore すると、復旧対象をさらに開けなくする危険がある。したがって、luksHeaderRestore は、観測、対象確認、バックアップ確認、救出方針の確認を終えた後に実行する最終的な復旧操作として扱う。

18.10 復旧後は通常手順で開けることを確認する

救出または修復が終わったら、復旧用 mapper を閉じ、通常運用と同じ手順で開けるかを確認する。復旧時だけ特殊な手順で開けても、通常運用に戻せなければ復旧完了とは言えない。通常用 keyfile、非常用パスフレーズ、crypttab、fstab、LVM、mount point の確認まで行い、台帳を更新する必要がある。

期待される結果は、復旧用の一時状態が閉じられ、通常運用用 keyfile と非常用パスフレーズの両方で解除確認が成功することである。その後、必要に応じて通常 mapper 名で open し、通常 mount point へマウントする。自動起動対象であれば、crypttab と fstab の UUID、mapper 名、mount point が復旧後の状態と一致していることを確認する。

18.11 復旧結果を台帳へ記録する

復旧作業は、データが読めた時点で終わりではない。何が原因で、どの層で失敗し、どの解除手段が有効で、どのデータを救出し、どの修復を実行し、どのヘッダーバックアップを使ったのかを記録する必要がある。この記録がないと、次回障害時に同じ切り分けを繰り返すことになり、復旧手順の再現性が失われる。

記録項目	記録する内容	目的
発生日	障害を確認した日時と復旧作業日時を記録する。	媒体劣化や障害再発の履歴を追跡する。
対象媒体	by-id、LUKS UUID、mapper 名、VG / LV 名、mount point を記録する。	どの暗号化デバイスを復旧したかを明確にする。
失敗した層	物理媒体、LUKS、key slot、LVM、filesystem、mount のどこで失敗したかを記録する。	次回以降の切り分けを速くする。
有効だった解除手段	keyfile、非常用パスフレーズ、どの key slot が使えたかを記録する。	鍵管理の見直しに接続する。
救出結果	救出先、救出範囲、読み取り不能だったパスを記録する。	失われた可能性のあるデータを把握する。
修復操作	e2fsck、luksHeaderRestore、設定修正など、実行した操作を記録する。	状態を変化させた操作を追跡する。
復旧後確認	通常手順で open、mount、読み取り、test-passphrase が成功したかを記録する。	復旧完了条件を満たしたことを確認する。

この章の要点は、復旧を一発の修復コマンドとして扱わないことである。暗号化デバイスの復旧では、物理媒体、LUKS ヘッダー、key slot、mapper、LVM、filesystem、mount point を順に確認し、読める段階でデータを救出し、修復は必要性と対象を確認してから行う。luksHeaderRestore や e2fsck は有効な手段だが、観測と救出より先に実行するものではない。復旧とは、壊れた箇所を慌てて直すことではなく、復元可能性をこれ以上失わない順序で状態を切り分け、必要なデータと運用経路を回収する作業である。

---

19. 退役では復元経路を失わずに暗号化デバイスを閉じる

暗号化デバイスの退役は、古いディスクを消す作業ではなく、その暗号化デバイスが担っていた復元経路を安全に終了させる作業である。退役してよいのは、新しい移行先へデータが移っていること、別系統の復元経路が残っていること、移行先を通常手順で開けること、主要データを読めること、旧媒体を互換バックアップとして残す必要がないこと、ヘッダーバックアップ、keyfile、非常用パスフレーズ、台帳の扱いが決まっていることを確認した後である。暗号化デバイスでは、データ本体を消すだけでなく、key slot を消す、LUKS ヘッダーを破棄する、ヘッダーバックアップを退役させる、媒体を保管停止する、物理廃棄する、という複数の退役方法がある。したがって、退役では「何を消すか」より先に、「何を残せば復元可能性が維持されるか」を確認する必要がある。

退役判断の最初に行うべきことは、旧暗号化デバイスが現在どの役割を持っているかを分類することである。主系から外れたからといって、即座に消去対象になるとは限らない。旧 LUKS1 媒体、TrueCrypt / TCRYPT 既存資産、古い 2.5-inch HDD、過去環境で作成した暗号化ディスクは、現行主系ではなくても、互換バックアップ、読み取り中心アーカイブ、移行失敗時の逃げ道として意味を持つ場合がある。一方で、役割が不明なまま残すと、古い key slot、古いパスフレーズ、所在不明のヘッダーバックアップ、媒体劣化が積み上がり、管理不能なリスクになる。

位置付け	意味	退役判断
主系	現在の通常運用で使っている暗号化デバイスである。	退役対象にする前に、新しい主系への移行、検証、切替を完了する。
互換バックアップ	旧形式だが、過去環境や移行失敗時の復元経路として意味がある。	開けること、読めること、保管理由が明確なら保持する。
読み取り中心アーカイブ	更新しないが、過去状態を保持するために残す暗号化デバイスである。	年次点検で読めることを確認し、役割が終わるまで保持する。
退役候補	移行済みであり、主系でも互換バックアップでもなくなった暗号化デバイスである。	復元経路が別に残ることを確認してから退役へ進む。
消去対象	保持する意味がなく、漏洩リスクや管理負荷を下げるために無効化する対象である。	台帳更新、復元経路確認、ヘッダーバックアップ方針決定後に消去する。

19.1 退役前に移行先と別系統の復元経路を確認する

退役前には、旧媒体ではなく移行先を確認する。退役とは旧媒体を使わない状態へ移すことなので、移行先が通常手順で開け、マウントでき、主要データを読めることが前提になる。さらに、移行先だけに依存すると単一障害点になるため、別系統のバックアップや互換バックアップが残っているかも確認する。ここを省略して旧媒体を消すと、暗号方式としては整理されても、復元可能性としては弱くなる。

この手順では、移行先が通常用 keyfile で開けること、非常用パスフレーズでも開けること、実際に mapper を作成してマウントできること、主要ディレクトリを読めることを確認している。期待される結果は、旧媒体がなくても移行先だけで通常利用または復旧が可能だと説明できることである。退役判断では、旧媒体の状態よりも先に、旧媒体を失った後の復元経路が成立しているかを確認する。

19.2 退役対象の現在状態を確認する

移行先の確認が終わったら、退役対象の現在状態を確認する。ここで確認するのは、退役対象が本当に意図した媒体であること、LUKS UUID が台帳と一致すること、有効な key slot がいくつ残っていること、通常用 keyfile や非常用パスフレーズでまだ開けること、暗号構成が何であること、ヘッダーバックアップが存在すること、媒体がどの役割から退くのかである。対象確認をせずに消去系コマンドを実行すると、正常な媒体を退役させる事故につながる。

期待される結果は、/dev/sdX が退役対象の LUKS デバイスであり、台帳上の LUKS UUID と一致し、どの解除手段がまだ有効かを説明できることである。keyfile と非常用パスフレーズの両方で開ける場合、その媒体はまだ復元可能な状態にある。どちらか一方だけで開ける場合は、退役前にその理由を記録する。どちらでも開けない場合は、退役というより、すでに復元不能または対象誤認の可能性があるため、消去ではなく切り分けへ戻る。

19.3 ヘッダーバックアップと keyfile の扱いを決める

LUKS の退役では、物理媒体だけを見てはいけない。LUKS ヘッダーのバックアップが残っている場合、現在のデバイス上で key slot を消しても、過去のヘッダーバックアップを restore すれば、当時の key slot が復活する可能性がある。つまり、退役対象は、物理媒体、LUKS ヘッダー、ヘッダーバックアップ、keyfile、非常用パスフレーズ、台帳記録の集合である。媒体だけを消しても、ヘッダーバックアップと keyfile の扱いが曖昧なら、退役は完了していない。

対象	退役時に決めること	理由
物理媒体	保管継続、読み取り専用保管、安全消去、物理廃棄のどれにするかを決める。	媒体自体が復元経路または漏洩リスクになるためである。
LUKS ヘッダー	保持するのか、key slot を消すのか、ヘッダーを破棄するのかを決める。	ヘッダーがある限り、正しい解除手段と組み合わせれば復号可能性が残るためである。
ヘッダーバックアップ	保存継続、別保管、削除、退役済みラベル付けの方針を決める。	古い key slot を復活させる可能性があるためである。
keyfile	他媒体でも使う keyfile か、退役対象専用 keyfile かを確認する。	共用 keyfile を誤って削除すると、別の暗号化デバイスを開けなくなるためである。
非常用パスフレーズ	退役対象専用か、他の媒体でも使っていないかを確認する。	パスフレーズ管理を誤ると、不要な解除入口や誤削除が残るためである。
台帳	退役日、退役理由、退役方法、残した復元経路を記録する。	後から媒体の状態や消去済みかどうかを判断できるようにするためである。

19.4 互換バックアップとして残す場合は退役ではなく役割変更にする

旧媒体をすぐに消さず、互換バックアップや読み取り中心アーカイブとして残す場合、その作業は退役ではなく役割変更である。この場合、key slot を消したり cryptsetup erase を実行したりしてはならない。必要なのは、主系から外したこと、通常更新対象ではないこと、次回点検日、保管場所、解除手段、ヘッダーバックアップ、退役再判断の条件を台帳へ記録することである。古い方式を残すこと自体が悪いのではなく、役割不明のまま放置することが問題である。

この確認により、互換バックアップとして残す媒体が現在も開けることを確認する。期待される結果は、通常用 keyfile または非常用パスフレーズで解除確認が成功し、台帳に記録された LUKS UUID と一致することである。互換バックアップとして残す場合の目的は、現行主系として使い続けることではなく、移行後も一定期間、別系統の復元経路を保持することである。

19.5 復元不能化する場合は cryptsetup erase の意味を理解する

cryptsetup erase は、LUKS デバイス上の全 key slot を消去する操作である。これはデータ本体を上書きする操作ではなく、データ本体へ到達するための解除入口を消す操作である。LUKS ではデータ本体は volume key によって暗号化され、その volume key を各 key slot から取り出せるように管理している。全 key slot を消すと、通常は volume key へ到達できなくなり、暗号化データ本体が残っていても復号できなくなる。したがって、cryptsetup erase は通常メンテナンスではなく、復元不能化を目的にする退役操作である。

この操作の期待される結果は、/dev/sdX 上の LUKS key slot が消去され、そのデバイス単体では解除できなくなることである。ただし、ヘッダーバックアップが残っている場合は、バックアップ時点のヘッダーを restore することで過去の key slot が戻る可能性がある。したがって、cryptsetup erase を実行しても、ヘッダーバックアップと keyfile が残っていれば、運用上の復元不能化は完了していない場合がある。退役では、媒体上の key slot だけでなく、ヘッダーバックアップと解除手段の扱いまで同時に決める必要がある。

19.6 物理媒体を再利用する場合と廃棄する場合を分ける

退役後の媒体には、再利用する場合と廃棄する場合がある。再利用する場合は、旧 LUKS ヘッダーや古いパーティション情報を残したままにせず、新しい用途に合わせて初期化する。ただし、再利用前に、本当に退役条件を満たしているか、必要なデータが移行済みか、別系統バックアップがあるかを確認する。廃棄する場合は、暗号化デバイスであっても、key slot 消去、ヘッダーバックアップ処理、物理破壊、廃棄記録のどれを採用するかを決める。

退役後の扱い	実施内容	注意点
互換バックアップとして保管	消去せず、読み取り確認と点検周期を設定する。	主系ではないこと、更新可否、退役再判断日を台帳化する。
再利用	退役確認後、新しい用途に合わせて初期化する。	再利用前に移行先と別系統バックアップの存在を確認する。
復元不能化	key slot 消去、ヘッダーバックアップ処理、keyfile 管理見直しを行う。	cryptsetup erase だけで完了したと誤解しない。
物理廃棄	媒体を物理的に廃棄し、台帳へ廃棄日と方法を記録する。	廃棄前に復元経路が失われないことを確認する。

19.7 退役完了条件を明文化する

退役完了は、cryptsetup erase を実行した時点でも、ディスクを取り外した時点でもない。退役対象が主系から外れていること、移行先が検証済みであること、別系統の復元経路が残っていること、旧媒体を残す必要がないこと、ヘッダーバックアップと keyfile の扱いが決まっていること、台帳が更新されていることを確認して、初めて退役完了と判断できる。暗号化デバイスの退役では、データを消すことよりも、復元可能性を失わずに役割を閉じることが重要である。

完了条件	確認内容	未確認時のリスク
移行先確認	移行先を通常手順で open、mount、読み取りできる。	旧媒体を消した後に主系が使えない可能性がある。
別系統確認	移行先とは別に復元経路が残っている。	単一媒体障害で復元不能になる可能性がある。
旧媒体の役割確認	互換バックアップとして残すか、退役するかが決まっている。	必要な旧資産を消したり、不要な媒体を放置したりする。
ヘッダーバックアップ方針	保存継続、削除、退役済み保管の方針が決まっている。	古い key slot が意図せず復活可能な状態で残る。
keyfile 方針	退役対象専用か、他媒体と共用かを確認している。	共用 keyfile を誤削除し、別媒体を開けなくなる。
台帳更新	退役日、退役理由、退役方法、残した復元経路を記録している。	後から状態を判断できず、再調査が必要になる。

この章の要点は、退役を削除作業として扱わないことである。暗号化デバイスの退役では、旧媒体、LUKS ヘッダー、key slot、ヘッダーバックアップ、keyfile、非常用パスフレーズ、移行先、別系統バックアップ、台帳が相互に関係する。cryptsetup erase は強力な復元不能化手段だが、それだけで退役が完了するわけではない。退役とは、古い暗号化デバイスの役割を閉じ、必要な復元経路を残し、不要な解除入口と媒体を管理対象から外すための運用手順である。

---

20. やってはいけない操作を場面ごとに明文化する

暗号化デバイスの運用では、正しいコマンドを知っているだけでは不十分である。事故は、コマンドの文法を知らないことよりも、実行してはいけない場面で強い操作を実行することによって起きる。特に危険なのは、対象確認が不十分なまま luksFormat、mkfs、luksKillSlot、cryptsetup erase、luksHeaderRestore、rsync –delete を実行することである。これらは、正しい場面では有効な管理手段だが、誤った場面では復元可能性を失わせる操作になる。したがって、手順書では「何をしてよいか」だけでなく、「どの場面で、何をしてはいけないか」を明文化する必要がある。

禁止事項は、単なる注意書きではなく、事故を未然に防ぐための運用境界である。暗号化デバイスでは、LUKS ヘッダー、key slot、keyfile、非常用パスフレーズ、ファイルシステム、物理媒体、ヘッダーバックアップが相互に関係している。ある操作が 1 つの層だけに見えても、実際には全体の復元可能性へ影響する。たとえば、最後の key slot を消せばデータ本体が残っていても復号不能になり、誤ったヘッダーを restore すれば現在の key slot 状態が過去へ戻り、rsync –delete の同期方向を間違えれば正しいデータを削除する。禁止事項は、このような不可逆または復旧困難な失敗を防ぐために定義する。

場面	してはいけない操作	理由	代わりに行うこと
対象確認前	/dev/sdX の見た目だけで luksFormat、mkfs、pvcreate、rsync –delete を実行する。	/dev/sdX は接続順で変わるため、正常な別媒体を初期化または削除する危険がある。	lsblk -f、blkid、/dev/disk/by-id、容量、モデル、UUID、台帳を照合してから実行する。
初期生成時	移行元や既存データが残る媒体に対して luksFormat を実行する。	luksFormat は LUKS ヘッダーを作成する破壊的操作であり、既存データへの到達経路を壊す。	新規作成対象であること、退避済みであること、対象デバイスが正しいことを確認する。
ファイルシステム作成時	復号後の mapper ではなく、元デバイスに mkfs.ext4 を実行する。	元デバイスに mkfs を実行すると、LUKS ヘッダーや暗号化コンテナを破壊する可能性がある。	mkfs.ext4 の対象が /dev/mapper/crypt_name または意図した LV であることを確認する。
key slot 変更前	ヘッダーバックアップなしで luksAddKey、luksRemoveKey、luksKillSlot を実行する。	key slot 操作に失敗した場合、解除入口を失い、復旧できなくなる可能性がある。	luksHeaderBackup を取得し、対象 UUID とバックアップ取得日を台帳へ記録する。
key slot 削除時	keyfile 用 slot や非常用パスフレーズ用 slot を確認せずに luksKillSlot する。	通常運用または非常時の解除入口を消してしまう可能性がある。	–test-passphrase と –key-slot で、どの解除手段がどの slot に対応するかを確認する。
key slot 整理時	最後の有効 key slot を削除する。	全 key slot が失われると、データ本体が残っていても volume key へ到達できず復号不能になる。	削除前後に luksDump と test-passphrase を実行し、少なくとも 1 つ以上の有効な解除入口を残す。
通常メンテナンス時	cryptsetup erase を通常の key slot 整理や軽い退役確認として実行する。	cryptsetup erase は全 key slot を消す復元不能化操作であり、通常メンテナンス用ではない。	復元不能化が目的であり、移行先と別系統バックアップが確認済みの場合に限って検討する。
ヘッダー復旧時	luksHeaderRestore を軽い修復操作として実行する。	ヘッダーと key slot 状態がバックアップ時点へ戻り、現在の台帳や解除手段と不一致になる可能性がある。	対象 UUID、バックアップ取得日、復元後に有効になる key slot、救出状況を確認してから実行する。
復旧初期	読み取り確認やデータ救出の前に e2fsck の修復やヘッダー復元を実行する。	修復操作は状態を変化させるため、読めるデータを救出する前に状況を悪化させる可能性がある。	まず観測、解除確認、読み取り専用マウント、重要データ救出を行い、その後に修復判断をする。
同期・移行時	同期方向を確認せずに rsync –delete を実行する。	移行元と移行先を取り違えると、正しいデータを削除する可能性がある。	初回同期では –delete を避け、差分再同期時のみ同期方向を明示してから使う。
keyfile 管理時	keyfile を平文で無造作に複製、共有、ログ出力、削除する。	keyfile は解除手段そのものであり、漏洩すれば開けられ、喪失すれば開けなくなる。	所有者、権限、保管場所、hash、対象デバイス、バックアップ方針を台帳化する。
ヘッダーバックアップ管理時	ヘッダーバックアップを通常ファイルのように無造作に保存する。	ヘッダーバックアップには key slot 情報が含まれ、古い解除入口を復活させる可能性がある。	取得日、対象 UUID、保存場所、暗号化保管方法、退役方針を記録する。
自動起動設定時	crypttab と fstab の役割を混同して設定する。	crypttab は暗号化デバイスを開く設定であり、fstab はファイルシステムをマウントする設定であるため、混同すると起動時に失敗する。	LUKS UUID、mapper 名、filesystem UUID、mount point を分けて確認し、起動確認まで行う。
LVM 併用時	LUKS の上に LVM があるのか、LVM の上に LUKS があるのかを確認せずに操作する。	層の順序を誤ると、pvcreate、mkfs、mount、fsck の対象を間違える危険がある。	lsblk -f、pvs、vgs、lvs で層の順序を確認し、構成ごとの手順に従う。
TrueCrypt / TCRYPT 既存資産	保守終了を理由に、確認せず即削除する。	旧資産が互換バックアップや過去データへの復元経路として意味を持つ可能性がある。	開けること、読めること、保持理由、移行先、退役条件を確認してから扱いを決める。

特に危険な操作は、通常運用の確認コマンドと同列に扱ってはならない。luksDump、isLuks、cryptsetup status、lsblk -f、blkid は主に観測のためのコマンドであり、対象の状態を大きく変えない。一方、luksFormat、mkfs.ext4、pvcreate、luksKillSlot、cryptsetup erase、luksHeaderRestore、e2fsck の修復、rsync –delete は、状態を変化させる操作である。手順書では、この二種類を分けて扱う必要がある。観測コマンドで対象を確認し、台帳と照合し、復元経路を確認した後でなければ、状態変更コマンドへ進んではならない。

分類	代表例	扱い方
観測系	lsblk -f、blkid、luksDump、isLuks、cryptsetup status、pvs、vgs、lvs	対象確認、台帳照合、層の切り分けに使う。
解除確認系	open –test-passphrase	mapper を作らず、keyfile や非常用パスフレーズが有効か確認する。
通常操作系	open、mount、sync、umount、close	日常運用の固定手順として使う。
状態変更系	luksAddKey、luksRemoveKey、luksKillSlot、mkfs.ext4、pvcreate、e2fsck	バックアップ、対象確認、復元経路確認後に実行する。
破壊的操作系	luksFormat、cryptsetup erase、luksHeaderRestore、rsync –delete	実行目的、対象、復旧経路、台帳更新を確認した場合に限る。

この章の要点は、禁止事項を精神論にしないことである。「気を付ける」では不十分であり、どの場面で、どの操作を止めるべきかを手順として定義する必要がある。暗号化デバイスの長期運用では、失敗の多くが暗号方式そのものではなく、対象取り違え、解除入口の誤削除、ヘッダー復元の誤用、同期方向の誤り、keyfile やヘッダーバックアップの管理不備から発生する。したがって、やってはいけない操作を明文化することは、補足ではなく、復元可能性を守るための中核的な運用設計である。

---

21. 台帳には復元判断に必要な項目だけを残す

暗号化デバイスの長期運用では、すべての情報を台帳へ書けばよいわけではない。現実の運用では、記録項目が多すぎると更新されなくなり、台帳そのものが古くなる。したがって、台帳に残すべきなのは、数年後に復元、移行、点検、退役を判断するときに必要になる情報である。単なるコマンド履歴、毎回変わる一時的な /dev/sdX 名、調べればすぐ分かるが判断に使わない細部まで書く必要はない。台帳は百科事典ではなく、復元条件を失わないための運用設計書である。

台帳に残す項目は、明確な理由を持つ必要がある。たとえば、LUKS UUID はヘッダーバックアップや crypttab と照合するために必要である。mapper 名と mount point は、起動時設定と通常運用手順を結び付けるために必要である。key slot の用途は、不要な解除入口を消すときに最後の有効 slot を誤って削除しないために必要である。一方、luksDump の全出力を毎回貼り付ける必要はない。必要なのは、将来の作業者が「この暗号化デバイスは何で、何で開き、どこへマウントされ、いつ確認され、いつ退役できるのか」を判断できることだからである。

台帳項目	記録する内容	残す理由
役割	system disk、data disk、backup disk、archive、互換バックアップ、退役候補などの役割を記録する。	その暗号化デバイスを主系として扱うのか、復旧経路として残すのか、退役候補にするのかを判断するためである。
物理媒体	vendor、model、serial、capacity、接続形態など、媒体を取り違えないための識別情報を記録する。	/dev/sdX は接続順で変わるため、破壊的操作の対象確認には物理媒体の識別情報が必要だからである。
永続識別子	/dev/disk/by-id、LUKS UUID、filesystem UUID、必要に応じて PARTUUID を区別して記録する。	crypttab、fstab、ヘッダーバックアップ、実デバイスを照合し、別物を同一視しないためである。
暗号構成	LUKS1 / LUKS2、cipher、mode、KDF、sector size など、運用判断に必要な範囲で記録する。	現行主系、互換バックアップ、移行対象、退役候補のどれとして扱うかを判断するためである。
解除手段	通常用 keyfile、非常用パスフレーズ、token の有無、対応する key slot の用途を記録する。	key slot 整理時に必要な解除入口を誤って消さず、非常時にどの手段で開けるかを判断するためである。
keyfile 管理	keyfile の path、size、owner、mode、hash、保管方針を記録する。	keyfile が正しいものか、権限が適切か、紛失や置き換えが起きていないかを確認するためである。
ヘッダーバックアップ	filename、取得日、対象 LUKS UUID、保存場所、保護方法、退役方針を記録する。	ヘッダー破損時の復旧経路である一方、古い key slot を復活させる機微情報でもあるためである。
自動起動設定	crypttab entry、fstab entry、mapper name、mount point、initramfs に関係する keyfile の扱いを記録する。	起動時に何が開かれ、何がマウントされるかを復旧時に再現するためである。
LVM 関係	PV、VG、LV、および LUKS と LVM の上下関係を記録する。	復旧時に LUKS を先に開くのか、LVM を先に認識するのかを誤らないためである。
最終確認日	last open test、last mount test、last read check、last SMART check、last restore-related check を記録する。	存在しているだけの媒体ではなく、最後にいつ復元可能性を確認した媒体なのかを判断するためである。
退役条件	移行完了、移行先検証、別系統バックアップ確認、ヘッダーバックアップ方針、消去方針を記録する。	古い暗号化デバイスを必要以上に残さず、かつ復元経路を失わずに役割を閉じるためである。

一方で、台帳へ残さないほうがよい情報もある。たとえば、平文のパスフレーズ、keyfile の中身、毎回のコマンド出力全文、一時的な /dev/sdX 名だけに依存した記録、判断に使わない詳細ログは、台帳の可読性と安全性を下げる。パスフレーズや keyfile 本体は、台帳ではなく別の保管設計で扱う。台帳には、それらがどの方針で保管され、どの暗号化デバイスに対応し、最後にいつ確認されたかを記録する。

残さない項目	理由	代わりに残すもの
平文パスフレーズ	台帳漏洩時に暗号化デバイスを開けられる危険がある。	非常用パスフレーズが存在すること、対応 slot、保管方針、最終確認日を記録する。
keyfile の中身	keyfile は解除手段そのものであり、台帳に貼るべきではない。	path、size、owner、mode、sha256、保管方針を記録する。
luksDump の全文	毎回全文を貼ると台帳が肥大化し、重要項目が埋もれる。	LUKS version、UUID、cipher、KDF、key slot 用途など判断に使う要点だけを記録する。
一時的な /dev/sdX のみ	接続順で変わるため、将来の対象確認に使えない。	/dev/disk/by-id、model、serial、LUKS UUID、filesystem UUID を記録する。
判断に使わない詳細ログ	記録量が増えすぎると更新されなくなり、台帳の信頼性が下がる。	点検結果、異常有無、次回対応、退役判断に必要な要約を記録する。

この章の要点は、台帳を大きくすることではなく、復元判断に必要な情報だけを残すことである。台帳が現実に運用されるためには、項目数を増やしすぎず、各項目に理由を持たせる必要がある。暗号化デバイスの台帳に必要なのは、将来の作業者が、対象を取り違えず、正しい解除手段を使い、必要なヘッダーバックアップを見つけ、起動時設定を再現し、移行や退役を判断できるだけの情報である。理由のない情報は残さず、復元条件に関係する情報だけを継続的に更新する。

---

22. 暗号化デバイスの運用手順はレジリエンスの実装である

cryptsetup の手順を体系化する意味は、コマンドを暗記することではない。暗号化デバイスの初期生成、通常運用、情報確認、key slot 管理、keyfile 管理、ヘッダーバックアップ、crypttab / fstab 連携、LVM 確認、点検、移行、復旧、退役を一つのライフサイクルとして扱い、時間が経っても開ける状態、読める状態、移せる状態、閉じられる状態を維持することにある。暗号化は第三者からデータを守るが、同時に、正当な利用者であっても解除条件を失えばデータへ到達できなくなる構造を作る。したがって、暗号化デバイスの運用では、データ本体だけでなく、LUKS ヘッダー、key slot、keyfile、非常用パスフレーズ、ヘッダーバックアップ、起動設定、LVM 構成、媒体識別情報、点検履歴、退役条件までを復元条件として扱う必要がある。

本稿で整理した手順は、個別には単純なコマンド操作に見える。luksFormat は暗号化デバイスを作る操作であり、open は mapper を作る操作であり、mount はファイルシステムを利用可能にする操作であり、luksDump は状態を確認する操作であり、luksAddKey や luksKillSlot は解除入口を管理する操作である。しかし、長期運用の観点では、これらは独立した小技ではない。どの対象に対して実行するのか、実行前に何を確認するのか、実行後に何を検証するのか、失敗した場合にどこへ戻れるのか、数年後に同じ判断を再現できるのかが重要になる。つまり、cryptsetup の手順は、暗号化ディスクを操作するための技術手順であると同時に、復元可能性を維持するための運用設計である。

暗号化デバイスの長期運用で失敗しやすい点は、暗号アルゴリズムそのものよりも、周辺条件の喪失にある。対象デバイスを取り違える。keyfile を失う。非常用パスフレーズを確認していない。用途不明の key slot が残る。最後の有効 key slot を消す。ヘッダーバックアップを取得していない。ヘッダーバックアップを取得しても、どの UUID に対応するのか分からない。crypttab と fstab の関係を忘れる。LVM と LUKS の上下関係を誤る。移行後に旧媒体を消した結果、別系統の復元経路が消える。これらは暗号理論の問題ではなく、運用設計の問題である。したがって、暗号化デバイスのレジリエンスは、強い暗号方式を選ぶだけでは成立しない。

現在の標準を採用することは重要である。新規作成では LUKS2、AES-XTS、Argon2id のような現行構成へ寄せるのが自然であり、古い LUKS1、CBC-ESSIV、PBKDF2、TrueCrypt / TCRYPT 既存資産を新規主系として増やすべきではない。しかし、それは古い構成を即座に消すという意味ではない。古い構成には、過去データ、過去環境、過去の復旧経路が残っている場合がある。レジリエンスとは、古い構成を無条件に残すことでも、すべてを最新方式へ置き換えることでもない。主系、互換バックアップ、読み取り中心アーカイブ、移行対象、退役候補を分類し、それぞれに確認周期、解除手段、保管方針、退役条件を与えることである。

この考え方を一般化すると、暗号化デバイスの運用で守るべき原則は四つに整理できる。第一に、観測してから変更する。lsblk、blkid、luksDump、status、pvs、vgs、lvs によって、対象と層の関係を確認してから状態変更操作へ進む。第二に、解除入口を意図的に管理する。keyfile、非常用パスフレーズ、token、key slot を用途ごとに分類し、不要な入口を残さず、必要な入口を誤って消さない。第三に、復元条件をデータ本体と同じ重さで扱う。ヘッダー、keyfile、台帳、自動起動設定、LVM 構成、点検履歴が失われれば、データ本体が残っていても復元できない。第四に、移行と退役をライフサイクルとして扱う。新しい構成へ移すだけでなく、移行先を検証し、旧構成の役割を変更し、復元経路を失わずに退役させる。

原則	意味	具体的な運用
観測してから変更する	対象と層の状態を確認してから、破壊的操作や状態変更操作を行う。	luksFormat、mkfs、luksKillSlot、erase、HeaderRestore、rsync –delete の前に、lsblk、blkid、luksDump、台帳照合を行う。
解除入口を管理する	key slot は同じ暗号化データへ到達する入口であり、増やしすぎても消しすぎても危険である。	通常用 keyfile、非常用パスフレーズ、用途不明 slot を分け、追加、確認、削除の手順を固定する。
復元条件を保存する	暗号化デバイスでは、データ本体だけでなく、ヘッダー、鍵、設定、手順、台帳が復元条件になる。	ヘッダーバックアップ、keyfile 管理、crypttab / fstab、LVM 構成、最終確認日、退役条件を台帳化する。
移行と退役を設計する	現在の標準も将来は古くなるため、作成時点から移行可能性と退役条件を持たせる。	新規主系は LUKS2 へ寄せ、旧構成は互換バックアップ、移行対象、退役候補として分類する。

この意味で、暗号化デバイスの運用手順はレジリエンスの実装である。レジリエンスとは、障害が起きない状態を作ることではない。媒体が劣化し、OS が更新され、暗号標準が変わり、手順が忘れられ、担当者が変わり、古い構成と新しい構成が併存する現実の中で、それでもデータへ到達できる経路を維持することである。暗号化デバイスでは、この経路は自然には残らない。鍵、ヘッダー、設定、台帳、点検、移行、退役を意図的に管理して初めて残る。

したがって、本稿の結論は、暗号化デバイスを安全に作るためには cryptsetup の使い方を覚えればよい、というものではない。暗号化デバイスを長期運用するには、暗号化、解除、確認、点検、移行、復旧、退役を一つの運用ライフサイクルとして設計する必要がある。最新方式を採用することは出発点であり、最終目的ではない。最終目的は、将来のある時点で、対象を取り違えず、正しい解除手段を使い、必要なデータを読み取り、必要なら新しい構成へ移し、役割を終えた古い構成を安全に閉じられる状態を維持することである。これが、暗号化デバイスを長期運用するための設計であり、cryptsetup 手順を手順書として残す本質的な理由である。

---

参考文献

1. id774, 暗号化ディスクを長期運用するための設計（2026-05-30）. https://blog.id774.net/entry/2026/05/30/4818/
2. cryptsetup project, cryptsetup. https://gitlab.com/cryptsetup/cryptsetup
3. Linux Kernel Documentation, dm-crypt. https://docs.kernel.org/admin-guide/device-mapper/dm-crypt.html
4. man7.org, cryptsetup(8). https://man7.org/linux/man-pages/man8/cryptsetup.8.html
5. Arch manual pages, cryptsetup(8). https://man.archlinux.org/man/cryptsetup.8
6. Debian manpages, cryptsetup(8). https://manpages.debian.org/stretch/cryptsetup-bin/cryptsetup.8.en.html
7. Red Hat Documentation, Encrypting block devices using LUKS. https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/security_hardening/encrypting-block-devices-using-luks_security-hardening
8. cryptsetup Wiki, Frequently Asked Questions. https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions
9. cryptsetup Wiki, LUKS standard on-disk format specification version 1.2.1. https://gitlab.com/cryptsetup/cryptsetup/-/wikis/LUKS-standard/on-disk-format.pdf
10. cryptsetup Wiki, LUKS2 On-Disk Format Specification. https://gitlab.com/cryptsetup/LUKS2-docs/-/blob/main/luks2_doc_wip.pdf
11. man7.org, cryptsetup-open(8). https://man7.org/linux/man-pages/man8/cryptsetup-open.8.html
12. man7.org, mke2fs(8). https://man7.org/linux/man-pages/man8/mke2fs.8.html
13. man7.org, cryptsetup-close(8). https://man7.org/linux/man-pages/man8/cryptsetup-close.8.html
14. man7.org, lsblk(8). https://man7.org/linux/man-pages/man8/lsblk.8.html
15. man7.org, blkid(8). https://man7.org/linux/man-pages/man8/blkid.8.html
16. man7.org, cryptsetup-luksRemoveKey(8). https://man7.org/linux/man-pages/man8/cryptsetup-luksRemoveKey.8.html
17. systemd, crypttab. https://www.freedesktop.org/software/systemd/man/latest/crypttab.html
18. systemd, systemd-cryptsetup-generator. https://www.freedesktop.org/software/systemd/man/latest/systemd-cryptsetup-generator.html
19. man7.org, fstab(5). https://man7.org/linux/man-pages/man5/fstab.5.html
20. man7.org, systemd.mount(5). https://man7.org/linux/man-pages/man5/systemd.mount.5.html
21. Red Hat Documentation, The Device Mapper. https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/logical_volume_manager_administration/device_mapper
22. Red Hat Documentation, Configuring and managing logical volumes. https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html-single/configuring_and_managing_logical_volumes/index
23. man7.org, e2fsck(8). https://man7.org/linux/man-pages/man8/e2fsck.8.html
24. man7.org, fsck(8). https://man7.org/linux/man-pages/man8/fsck.8.html
25. smartmontools, smartmontools. https://www.smartmontools.org/
26. NIST, FIPS 197, Advanced Encryption Standard (AES). https://csrc.nist.gov/pubs/fips/197/final
27. NIST, SP 800-38A, Recommendation for Block Cipher Modes of Operation. https://csrc.nist.gov/pubs/sp/800/38/a/final
28. NIST, SP 800-38E, Recommendation for Block Cipher Modes of Operation: The XTS-AES Mode for Confidentiality on Storage Devices. https://csrc.nist.gov/pubs/sp/800/38/e/final
29. IETF, RFC 8018, PKCS #5: Password-Based Cryptography Specification Version 2.1. https://datatracker.ietf.org/doc/html/rfc8018
30. IETF, RFC 9106, Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications. https://datatracker.ietf.org/doc/rfc9106/
31. NIST, Proposal to Update SP 800-38E. https://csrc.nist.gov/News/2023/proposal-to-update-sp-800-38e
32. NIST, SP 800-57 Part 1 Rev. 5, Recommendation for Key Management. https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final
33. NIST, SP 800-131A, Transitioning the Use of Cryptographic Algorithms and Key Lengths. https://csrc.nist.gov/pubs/sp/800/131/a/r2/final
34. TrueCrypt Foundation, TrueCrypt User Guide. https://garykessler.net/library/crypto/TrueCrypt%20User%20Guide.pdf
35. BSI, Security Analysis of TrueCrypt. https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Studies/Truecrypt/Truecrypt.html
36. BSI, Security Analysis of TrueCrypt PDF. https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Studies/Truecrypt/Truecrypt.pdf?__blob=publicationFile=2
37. NCC Group, Truecrypt Phase Two Audit Announced. https://cryptoservices.github.io/blog/2015-02-18-truecrypt-phase-two/
38. man7.org, cryptsetup-tcryptDump(8). https://man7.org/linux/man-pages/man8/cryptsetup-tcryptDump.8.html