バックアップボリュームの LUKS2 鍵更新と読み取り専用復元

バックアップファイルをディスクに保存し、受信用アカウントも分離したとしても、廃棄・退役したディスクやオフラインコピーからデータをそのまま読み取れるかどうかは、別のセキュリティ境界に関わります。ボリューム暗号化は、ロックが解除されていないデータの保護には適していますが、オンラインのアクセス制御の代わりにはなりません。また、鍵更新によって古いパスフレーズを無効化することはできますが、すでに漏えいしたデータを取り戻すことはできません。本記事では、独立したファイルコンテナーを使って LUKS2 の鍵更新と復元を演習します。既存のデータディスクは操作しません。

一、暗号化で保護する対象を明確にする

OnuCloud の物理サーバーには、1TB NVMe が 2 台標準搭載されています。各ドライブは直接接続されており、ハードウェア RAID はありません。ボリューム暗号化、ディスクの冗長化、遠隔地バックアップは、それぞれ異なる問題に対処するものです。暗号化はオフラインでの読み取りを制限し、冗長化はデバイス障害に、遠隔地バックアップは独立したコピーの確保に対応します。2 台とも暗号化しただけでは、復元可能なバックアップが自動的にできるわけではありません。

以下では Ubuntu Server 24.04 LTS を例に説明します。管理者権限、cryptsetup、e2fsprogs、および約 256 MiB の実際に使用可能な空き容量が必要です。まずディストリビューションのパッケージで必要なツールをインストールし、作業専用の管理者シェルを起動してください。以降のコマンドは、変数が引き継がれるよう、同じシェルで実行します。

ロック解除済みのボリュームは、必要な権限を持つプロセスから引き続き読み取れます。ボリューム暗号化では管理者権限の悪用を防げません。また、書き込み中のデータベースのコピーに、アプリケーションレベルの整合性が自動的に備わるわけでもありません。

本番導入前に、パスフレーズの管理者、ヘッダーバックアップの閲覧権限を持つ担当者、人員変更時のアクセス権取り消し手順を明確にしてください。パスフレーズはコマンド引数、スクリプト、作業チケットの本文に記載しないでください。

二、実ディスクに触れない演習用ボリュームを作成する

mktemp で独立した作業ディレクトリを作成し、フォーマット操作の対象を、その中に新規作成するファイルだけに限定します。実行前に、マッピング名 backup-drill が使われていないことを確認してください。すでに存在する場合は作業を止めて調査し、不明なマッピングを閉じないでください。この例ではパスフレーズを対話形式で入力し、初期パスフレーズをスロット 0 に登録します。

umask 077
work=$(mktemp -d /var/tmp/luks-drill.XXXXXX)
image="$work/backup.img"
mountpoint="$work/mnt"
mkdir "$mountpoint"
truncate -s 256M "$image"
cryptsetup luksFormat --type luks2 --key-slot 0 "$image"
cryptsetup open "$image" backup-drill
mkfs.ext4 /dev/mapper/backup-drill
mount /dev/mapper/backup-drill "$mountpoint"
printf 'backup-recovery-check\n' > "$mountpoint/probe.txt"
(
  cd "$mountpoint"
  sha256sum probe.txt
) > "$work/expected.sha256"
sync
umount "$mountpoint"
cryptsetup close backup-drill

各コマンドの成功を確認してから、次のコマンドを実行してください。特に、ロック解除に失敗した状態でフォーマットに進んだり、ファイルパスを未確認の NVMe デバイス名に置き換えたりしてはいけません。スパースファイルの見かけのサイズと実際のディスク使用量は異なります。演習中も、そのファイルを置くファイルシステムに十分な空き容量があることを確認してください。

チェックサム一覧はコンテナーの外に保存し、復元時に独立して照合できるようにします。本番環境の一覧にも、信頼できる出所が必要です。データと一覧の両方を改ざんできる状況では、ハッシュの一致だけで出所の信頼性を証明することはできません。

三、新しいスロットを検証してから古いパスフレーズを無効化する

まず cryptsetup luksDump "$image" を実行し、形式が LUKS2 であること、スロット 0 が有効でスロット 1 が空いていることを確認します。実際のボリュームではスロットの使用状況が異なる場合があるため、番号をそのまま流用しないでください。以下で新しいパスフレーズを追加する際は、最初に古いパスフレーズを入力して認証し、その後、プロンプトに従って新しいパスフレーズを設定します。

cryptsetup luksAddKey --key-slot 1 "$image"
cryptsetup open --test-passphrase --key-slot 1 "$image"
cryptsetup luksDump "$image"

2 番目のコマンドでは新しいパスフレーズを入力し、終了コードが 0 になった場合に限り、検証成功とします。--test-passphrase はロック解除をテストするだけで、マッピングは作成しないため、ファイルシステムのマウント状態に影響しません。スロットを追加してもボリューム鍵が更新されるわけではなく、全データが再暗号化されるわけでもありません。

権限を持つ担当者が新しいパスフレーズを適切に保管したことを確認してから、スロット 0 を削除します。この演習では、引き続き使用する新しいパスフレーズで削除を認証します。

cryptsetup luksKillSlot "$image" 0
cryptsetup open --test-passphrase "$image"

最後のコマンドでは、まず古いパスフレーズを入力し、失敗することを確認します。その後、同じコマンドを再実行して新しいパスフレーズを入力し、成功することを確認してください。自動リトライで失敗を覆い隠したり、スロット一覧だけを見て更新完了と判断したりしてはいけません。検証の証跡には、スロットの変更内容と 2 回のテスト結果を含め、パスフレーズ自体は含めないでください。

四、ヘッダーバックアップも機密性の高いアクセス情報として扱う

LUKS ヘッダーには、ロック解除に必要な重要なメタデータが保存されています。データ領域が残っていてもヘッダーが破損した場合、ヘッダーバックアップが復元の条件になることがあります。ただし、ヘッダーバックアップはデータのコピーではありません。唯一のデータボリュームと一緒に失うことも避けなければなりません。鍵更新に成功したら、現在のヘッダーをエクスポートします。

cryptsetup luksHeaderBackup "$image" \
  --header-backup-file "$work/header-current.bin"
chmod 600 "$work/header-current.bin"
cryptsetup luksDump "$image" > "$work/luks-layout.txt"

ディレクトリやファイルのパーミッションで制限できるのは、ローカル環境でのアクセスだけです。本番用のヘッダーコピーは、アクセスを管理した独立の保管先に移し、対応するボリューム、鍵更新の実施単位、権限を持つ担当者を記録してください。データコピーとの対応関係も明確にしておきます。ヘッダーファイルを一般的な診断用添付ファイルとして送付しないでください。

特に注意が必要なのが過去のバージョンです。古いヘッダーには無効化したスロットが残っている場合があり、それを復元すると古いパスフレーズが再び有効になる可能性があります。そのため、現在のボリュームから古いスロットを削除しても、過去に保存したすべての資料からアクセス能力を取り消したことにはなりません。ボリューム鍵の漏えいが脅威に含まれる場合、パスフレーズの変更だけでは不十分です。別途、再暗号化や移行を計画する必要があります。

五、読み取り専用の復元ではファイル内容まで検証する

演習用ボリュームは正常にアンマウント済みなので、読み取り専用のマッピングを作成し直し、ext4 を読み取り専用かつジャーナルをリプレイしない設定でマウントできます。この 2 段階の制限で、ブロックデバイスとファイルシステムそれぞれの動作を制約します。

cryptsetup open --readonly --key-slot 1 "$image" backup-drill
mount -t ext4 -o ro,noload /dev/mapper/backup-drill "$mountpoint"
findmnt -no SOURCE,FSTYPE,OPTIONS "$mountpoint"
(
  cd "$mountpoint"
  sha256sum -c "$work/expected.sha256"
)
touch "$mountpoint/should-not-exist"

新しいパスフレーズを入力した後、マウントオプションに ro が含まれていること、チェックサムの照合が成功すること、最後の書き込みが失敗することを確認します。書き込みが成功した場合は、直ちに検証を中止し、実際のマウント先を確認してください。無関係な異常として扱ってはいけません。noload は、ファイルシステムのダーティな状態を隠すために使うものではありません。正常にアンマウントされていないコピーを扱う場合は、まず原本を保全し、作業用コピー上で修復の可否や方法を検討してください。

完了したら、ディレクトリをアンマウントし、続いてマッピングを閉じます。マウントやマッピングが残っていないことを確認してから、演習用ディレクトリを処理してください。本番用の資料は定められた保管ルールに従って管理し、一時ファイルの削除対象に混ぜないでください。

最終的な記録では、次の 4 点に答えられる必要があります。新しいパスフレーズだけでロック解除できるか、古いパスフレーズが無効になっているか、ヘッダーコピーが適切に管理されているか、復元したファイルが信頼できるチェックサム一覧と一致するか。この 4 点をすべて確認できて初めて、後から検証可能な鍵更新・復元演習が成立します。

よくある質問