TPM2 + Clevis/Tang によるディスク自動アンロック本番導入｜鍵紛失リスク評価と切り戻し設計

TPM2とClevis/Tangが解くサーバー起動時の課題

LUKSでディスクを暗号化したサーバーを無人再起動させるには、起動時にパスフレーズを自動で入力する仕組みが必要です。従来はinitramfsに鍵を埋め込む方法やネットワーク経由でパスフレーズを渡す独自スクリプトが使われてきましたが、どちらも「鍵がどこかに平文で置かれる」という根本的なリスクを抱えています。

この問題に対するOSSの現行標準が Clevis（クライアント側フレームワーク）と Tang（鍵配送サーバー）の組み合わせです。さらに TPM2.0（Trusted Platform Module）を加えることで、「Tangサーバーへの到達性」と「ハードウェア的な起動状態の正常性」を両方検証してからアンロックする多重バインディングが実現します。クラウドVMではvTPMとして利用できる環境が増えており、オンプレミス・クラウドを問わず適用範囲が広がっています。

アーキテクチャ：Clevis・Tang・TPM2の役割分担

Clevisは起動時にLUKSボリュームを解錠するクライアントライブラリです。解錠に使う情報源を「ピン」と呼び、主要なものは以下の3種類です。

• tang：ネットワーク上のTangサーバーと楕円曲線Diffie-Hellman鍵交換を行い、Tangサーバーが応答している場合のみ鍵を再構成する
• tpm2：TPM2チップのPCR（Platform Configuration Register）値と照合し、起動チェーンが改ざんされていない場合のみ鍵を解放する
• sss：Shamir’s Secret Sharingにより複数ピンのAND/OR条件を定義する

本番環境では sss ピンを使って「tang AND tpm2」あるいは「tang OR tpm2」という条件を設定することが多いです。AND条件はセキュリティが最も高くなりますが、Tangサーバー障害時やTPMのPCR値変化時に解錠できなくなります。可用性とのバランスを踏まえた設計が必要です。

TangサーバーはHTTPS不要のシンプルなHTTPデーモンで、鍵の実体を持たず楕円曲線演算のみを担います。Tangをシャットダウンすれば過去にバインディングした端末はすべて解錠不能になる「リモートロック」が可能という設計上の特徴があります。

本番導入の手順（RHEL 9 / Ubuntu 22.04 系共通）

前提として、LUKS2でフォーマット済みのディスクが存在し、既存のパスフレーズスロットが有効であることを確認してから作業を開始してください。既存のパスフレーズは切り戻し用に必ず手元に保管します。

パッケージのインストール

RHEL/AlmaLinux 9系では clevis・clevis-luks・clevis-dracut をインストールします。Tangサーバー側には tang パッケージを追加します。Ubuntu 22.04系では clevis-tpm2・clevis-luks・clevis-initramfs が対応パッケージです。TPM2向けにはいずれのディストリでも tpm2-tools と tpm2-abrmd（アクセスブローカーデーモン）が必要になります。

TangサーバーのURLとTPM2のPCRポリシーを決定する

Tangサーバーは内部ネットワーク上の専用ホストに配置し、外部インターネットには公開しません。tangd.socket をsystemdで有効化し、ポート80またはカスタムポートでリッスンさせます。初回起動で鍵ペアが /var/db/tang/ 以下に自動生成されます。

TPM2のPCRポリシーは、どのPCRレジスタをバインド対象にするかを決める重要な設計事項です。PCR0～7はファームウェア・ブートローダー・カーネルの測定値を保持しており、カーネルアップデート後にPCR値が変わるためバインディングの再設定が必要になります。運用負荷を下げるには変動の少ないPCR範囲に絞るか、後述する再バインドフローを手順化します。

ClevisをLUKSスロットにバインドする

clevis luks bind コマンドで、LUKSデバイスに新しいキースロットとしてClevisの設定を書き込みます。tangピン単体の場合は -d /dev/sda3 tang '{"url":"http://tang.example.internal"}' のように指定します。sssピンでAND条件を設定する際はJSON内に t（閾値）と pins オブジェクトをネストして記述します。バインド後は clevis luks list -d /dev/sda3 でスロットと設定内容を必ず確認してください。

initramfsへの組み込みと再生成

RHEL系は dracut -fv、Ubuntu系は update-initramfs -u を実行してinitramfsを再生成します。このステップを忘れると起動時にClevisが呼び出されずパスフレーズ入力プロンプトが表示されたままになるため、必ず実施してください。

動作検証と鍵バインディング確認

本番適用前に同構成の検証環境でリブートテストを行うことを強く推奨します。検証環境が用意できない場合は、本番機のリブートは業務影響を最小化できるメンテナンスウィンドウ内で実施することが原則です。

リブート後に自動アンロックが成功したことを確認するには、RHEL系では journalctl -b -u clevis-luks-askpass.path、Ubuntu系では journalctl -b | grep clevis でClevisの起動ログを確認します。cryptsetup status /dev/mapper/xxx でボリュームがアクティブになっていれば成功です。

Tangサーバーとの通信確認には curl http://tang.example.internal/adv でAdvertisement（公開鍵情報）が返ることをチェックします。応答がない場合はネットワーク疎通とsystemdソケットの状態を見直してください。

鍵紛失リスクの評価と切り戻し設計

Clevis/Tangを本番に導入する際に最も丁寧に設計すべきなのが「鍵が使えなくなるシナリオ」の洗い出しです。主要なリスクシナリオを整理します。

• Tangサーバーの停止・消失：tangピン単体バインドの場合、Tangサーバーが応答しないと解錠できません。Tangサーバーを冗長化するか、既存のLUKSパスフレーズスロット（スロット0）を温存しておくことで緊急時の手動アンロックを担保します
• Tangの鍵ローテーション後の旧バインディング失効：/var/db/tang/ の鍵を削除・更新すると旧鍵でバインドしたすべてのクライアントが解錠不能になります。ローテーション前に全クライアントを再バインドするか、旧鍵を一定期間残す移行期間を設けます
• TPM PCR値の変化によるtpm2ピン失効：カーネルアップデート・BIOS更新・セキュアブート設定変更でPCR値が変わり、tpm2ピンが失効します。カーネルアップデートを適用する前に clevis luks regen または unbind → 再バインドを実施するフローを運用手順に組み込みます
• LUKS2ヘッダー破損：LUKSヘッダーが破損するとClevisの設定ごと失われます。cryptsetup luksHeaderBackup によるヘッダーバックアップを導入直後と設定変更のたびに取得し、オフラインの安全な場所に保管します

切り戻し設計の要点は「Clevisとは独立した解錠手段を必ず1つ残す」ことです。LUKSパスフレーズスロットを温存し、パスフレーズ自体を組織のパスワード管理基盤に登録しておきます。Clevisスロットの削除は clevis luks unbind -d /dev/sda3 -s <スロット番号> で安全に行えます。

以下は、カーネルアップデート時の手順フロー（想定例）です。

1. アップデート前に cryptsetup luksHeaderBackup でヘッダーを退避する
2. clevis luks unbind でtpm2スロットを解除する
3. カーネルアップデートと dracut -fv を実施してリブートする
4. 起動後に新しいPCR値で clevis luks bind を再実行する
5. 動作確認後、ヘッダーバックアップを更新する

2026年現行環境での注意点と差分

RHEL 9 / AlmaLinux 9 / Rocky Linux 9：Clevis・Tang ともにデフォルトリポジトリに含まれており、dnf install で導入できます。clevis luks regen サブコマンドが利用可能になっており、カーネルアップデート後のPCR再バインドを自動化するsystemdユニット（clevis-luks-regen.service）の活用でPCR変化による失効リスクを大幅に低減できます。

Ubuntu 22.04 LTS / 24.04 LTS：clevis-initramfs パッケージが整備されており、Ubuntu 24.04 ではTPM2とセキュアブートの統合が進んでいます。ただし tpm2-abrmd の設定とユーザー権限の付与が必要なケースがあるため、事前に tpm2_getcap handles-pcr コマンドで動作確認を行うことを推奨します。

クラウド環境（AWS・GCP・Azure）：vTPM（仮想TPM）を提供するインスタンスタイプが標準化されており、AWS Nitro SystemはTPM2.0をサポートしています。ただしクラウドのvTPMはファームウェアアップデートやインスタンスタイプ変更でPCR値が変わる可能性があり、物理TPMと比べてPCRバインディングの運用設計に注意が必要です。可用性を優先する場合はtangピン単体またはOR条件のsssバインドが安定しやすい傾向があります。

大規模環境でのエスクロー統合：Tangの標準管理UIは最小限です。RHEL環境では Clevis + NBDE（Network Bound Disk Encryption）をIPA（FreeIPA / Red Hat Identity Management）と統合するオプションがあり、鍵のエスクローと失効管理をIPA経由で行えます。この方式は構成が複雑になる分、鍵紛失リスクを組織的にコントロールしやすくなります。多数のサーバーを管理する環境では検討に値する選択肢です。