ESXi の構成情報の暗号化、TPM による追加の保護、TPM 障害からの復旧

Table of contents

ESXi 7.0 Update 2 以降での構成情報の暗号化

ESXi 7.0 Update 2 以降では、ブートディスクの盗難などから ESXi を保護するために構成情報が暗号化されるようになっています。

• ESXi 構成をセキュアにする

ESXi は、構成ファイルにシークレットを格納します。これらの構成は、アーカイブ ファイルとして ESXi ホストのブートバンクに保持されます。vSphere 7.0 Update 2 以降、このアーカイブ ファイルは暗号化されています。その結果、たとえ ESXi ホストのストレージに物理的にアクセスできたとしても、攻撃者はこのファイルを直接読み取ったり、変更したりすることはできません。

以前のリリースでは構成情報のアーカイブ(state.tgz)を tar コマンドで順に展開していけば構成情報が確認できてしまいました。それに対して、現在のリリースでは state.tgz に含まれる local.tgz が暗号化されており、tar コマンドでの単純な展開は出来なくなっています。

1# tar xzf /bootbank/state.tgz
2# ls
3encryption.info  local.tgz.ve
4# tar xzf local.tgz.ve
5tar: invalid magic
6tar: short read

state.tgz に一緒に含まれる encryption.info には暗号化に使用する鍵を導出するための入力が保存されています。ESXi の再起動時には encryption.info の情報を鍵導出関数(KDF)への入力として鍵を導出し、導出された鍵を使用して復号化を行います。

上述のように tar コマンドでの単純な展開はできないものの、この暗号化を突破できない状態はあくまでも「使われている鍵導出関数の詳細がわからない」ことに依存しています¹。万が一、ESXi のコードが解析されるなどで鍵導出関数の詳細が分かってしまえば「ブートディスクを盗んで state.tgz に含まれる encryption.info から鍵を導出して復号化」といった状況も想定できます。

暗号化されたデータと鍵(の材料)が同じデバイスに存在することになるため、可能性が低いとはいえど実質的に暗号化としては機能しなくなります。この辺りを考慮しているのか VMworld 2021 Japan のセッション等ではこのモードは構成情報の「難読化」として紹介されています。

また、その他に想定されるケースとして「流出した ESXi のブートディスクを別のハードウェアに接続して ESXi を起動した後、パスワードの総当たりなどで root ユーザーにアクセス」といった状況であればやはり構成情報を取得できてしまいます。

これらのケースから ESXi の構成情報を保護するために、ハードウェア搭載の TPM を使用する追加の保護機能が用意されています。

構成情報の暗号化に対する TPM を使用した追加の保護

ESXi がインストールされるハードウェアに TPM を搭載しておくことで、構成情報の暗号化に用いられる鍵が TPM に保存されるようになります。encryption.info には TPM の測定値などメタデータのみが含まれ、鍵や導出するための入力は含まれません。

これにより暗号化されたデータとその鍵が異なるデバイスに保存されるため、仮にブートディスクを盗み出し state.tgz の復号化を試みても、鍵は TPM に保存されていて使用できないため復号化が不可能となります。

また、ブートディスクを別のハードディスクで起動しようとしても、鍵が保存されている TPM にアクセスできないため、ESXi のブート処理内での構成情報の復号化も行えません。この場合は ESXi のブート中にセキュリティ違反とみなされて PSOD が発生します。

ここまで来ると、データセンターからハードウェアを筐体丸ごと盗むような真似でもしない限り復号化が不可能となり、ESXi の構成情報の堅牢化を実現できます。

TPM の障害発生時の対応

ESXi の構成情報の暗号化に用いられる暗号化キーは TPM で保持されるため、ハードウェア障害で TPM の交換を含む保守対応を行った、TPM の内容をクリアした場合など、元の TPM に保存されていた情報が使用できない場合は上述したように ESXi の構成情報が復号化できずブートに失敗し PSOD となります。

ここからリカバリを行うためには、事前に ESXi から構成情報のリカバリキーを取得しておく必要があります。今回の記事では vTPM を構成した Nested ESXi VM で TPM の障害のシミュレーションとリカバリを試してみます。

検証用の Nested ESXi の準備

まず vTPM が構成された Nested ESXi を準備しますが、vTPM は Windows と Linux でしかサポートされません。このため、Native Key Provider や外部 KMS が構成されていても、vSphere Client の仮想マシンの設定で仮想 TPM デバイスの追加の UI 自体が表示されません²。

PowerCLI の New-VTpm コマンドレットならゲストOSのサポートに関係なく仮想 TPM デバイスを追加できるため、まず仮想マシンを作成した後に New-VTpm で仮想 TPM デバイスを追加します。

1PS > Connect-VIServer vcsa.jangari.lab
2PS > Get-VM "vTPM-NestedESXi" | New-VTpm

仮想 TPM デバイスが構成された仮想マシンを作成したら、通常の手順で ESXi をインストールします。

リカバリキーの取得

Nested ESXi に ESXi Shell または SSH でアクセスし、esxcli system settings encryption recovery list コマンドでリカバリキーの一覧を取得します。

1# esxcli system settings encryption recovery list
2Recovery ID                             Key
3--------------------------------------  ---
4{A860B8FF-F25C-4332-BD87-713890210EC6}  404745-562992-542643-017570-449948-013337-426256-580884-202287-630254-411949-357346-279412-492912-626244-478163

• セキュアな ESXi 構成リカバリ キーの内容の一覧表示

2列目の Key 列の内容がリカバリキーになるため、こちらをテキストファイルにコピー＆ペーストしておくなどで保管します。リカバリキーを紛失すると TPM 関連の障害発生後に ESXi を復旧できなくなるため適切な手段で保管するようにしましょう。

なお、TPM が搭載された ESXi では事前定義済みアラーム「TPM 暗号化リカバリ キー バックアップ アラーム」がトリガーされます。リカバリキーをバックアップしたら vSphere Client 上で手動でアラームをクリア(緑にリセット)します。

• “TPM Encryption Recovery Key Backup” warning alarm in vCenter Server (81661)

TPM の障害のシミュレーション

Nested ESXi をパワーオフしてから仮想 TPM デバイスを削除・新規追加することで、TPM が交換された状況をシミュレーションします。

1PS > Get-VM "vTPM-NestedESXi" | Get-VTpm | Remove-VTpm
2PS > Get-VM "vTPM-NestedESXi" | New-VTpm

この状態で Nested ESXi を起動しようとすると、元の TPM が使用できないため上述したセキュリティ違反の PSOD が発生します。

リカバリキーを使用した復旧

事前に取得しておいたリカバリキーを使用することで TPM の交換後やクリア後に ESXi のリカバリを行うことが出来ます。

• セキュアな ESXi 構成のリカバリ

ESXi のブートローダーで Shift + O キーを押下し、起動オプションとして encryptionRecoveryKey=<recovery_key> を追記します。<recovery_key>は事前に esxcli コマンドで取得しておいたリカバリキーです。

起動オプションを追記した後 Enter キーを押下します。正しく追記できていれば ESXi が起動してきます。

ESXi が起動したら、ESXi Shell から手動で構成情報の保存スクリプトを実行して ESXi の構成情報を保存します。

1# /sbin/auto-backup.sh

なお、リカバリを行うには使用可能な TPM がハードウェアに搭載されている必要があります。故障などで TPM が使用できない場合、TPM を交換する、別の TPM 搭載ハードウェアにブートディスクを移しておく、といった事前の対応が必要です。

補足１: UEFI セキュアブート / execInstalledOnly の強制

構成情報を TPM で暗号化されている ESXi では、UEFI セキュアブートや execInstalledOnly 起動オプションを強制することも可能になります。

• セキュアな ESXi 構成のセキュア ブートの適用の有効化/無効化
• セキュアな ESXi 構成の execInstalledOnly の適用の有効化/無効化

UEFI セキュアブートは、UEFI ファームウェアを信頼の起点として ESXi のブートローダー、カーネル(vmkernel)、モジュール(VIB) の署名が正当であるかどうかを検証します。UEFI セキュアブートを利用することで、改ざんされていない正当なソフトウェアのみでブートされたことを保証できます。

execInstalledOnly 起動オプションは、インストール済みの VIB の一部としてパッケージング／署名されたバイナリのみを ESXi に実行させます。例えば悪意のあるコードを含むバイナリを ESXi に転送したり、ブート後に ESXi 内のバイナリを改ざんしても、VIB に含まれていた元のバイナリと一致しないため実行が拒否されます。本起動オプションを強制する場合は前提条件としてセキュアブートが必要です。

TPM 未搭載のハードウェアの場合、UEFI やブートローダーでこれらの機能を有効にしても、後から無効にして ESXi が起動できてしまいます。

TPM で構成情報を暗号化している ESXi ではこれらの機能を強制させることができ、機能が無効である状態を検出するとセキュリティ違反の PSOD を発生させることでブートを停止します。

• Boot time failures due to ESXi configuration encryption (81446)

なお、サードパーティの VIB などはこれらの機能と互換性がない場合もあるため、有効化／強制するにあたり事前に検証をおこなって動作確認することが重要です。

補足２: TPM と構成情報のリストア

TPM で暗号化された構成情報をバックアップした場合、バックアップ時点と異なるハードウェアへのリストアは行えません。

How to back up ESXi host configuration (2042141)

However, starting from vSphere 7.0 U2, the configuration could be encrypted using TPMs and in which case, the -force option will not work if the host got changed. We need the same TPM that was used on the host during backup, to restore. In other words, from vSphere 7.0U2, the override will not work if the host has TPM enabled.

BIOS UUID が一致しなくても強制的にリストアさせる -Force オプションがありますが、このオプションでリストアしてもバックアップ時点と同じ TPM が使用できない場合はリストアが行えません³。

おわりに

今回の記事では ESXi 7.0 Update 2 以降での構成情報の暗号化、TPM による追加の保護や障害時のリカバリについて見ていきました。

今のところ TPM は多くのベンダーでオプション扱いですが、サーバ1台あたり数千円程度でセキュリティを高められるモジュールなので使えるなら使いたいところです。

なお、VMware Compatibility Guide で認証が取れているハードウェアでもベンダー側で個別に制限などが存在するケースもあるようなので、TPM の搭載を検討する場合はハードウェアベンダーにサポート状況など確認を取るのが確実だと思います。