ネットワークファイアウォールや仮想マシン（VM）上のウイルス対策ソフトは、攻撃者によって物理サーバーのBIOSやブートローダーへ不正コードが埋め込まれてしまうと全く役に立ちません。昨年のPCI-DSS監査は、私たちのチームにとって大きな教訓となりました。本番稼働中の全8ノードのESXiが、ハードウェアレベルの完全性検証メカニズムの欠如により不合格となってしまったのです。その根本的な解決策となるのが、各サーバーに物理TPM 2.0チップを搭載し、vCenter上でHost Attestation機能を有効化することです。
ESXiサーバーの完全性監視手法の比較
ファームウェアやハイパーバイザーカーネルへの不正な改ざんを早期検知するために、管理者は主に3つのアプローチを選択できます。
- 手法1：手動監視とログ収集 — スクリプトを用いてVIBパッケージのハッシュ値を検証し、SIEM（Wazuh、Splunkなど）にログを転送します。ただし、この方法はインシデント発生後の事後検知にとどまります。
- 手法2：UEFI Secure Bootのみの有効化 — ESXiがVMwareの有効なデジタル署名のないドライバーのロードをブロックします。しかし、照合用に起動プロセスの測定ログ（痕跡）を保持する仕組みはありません。
- 手法3：UEFI Secure Boot + TPM 2.0 + Host Attestationの組み合わせ — 電源投入時から各ブートステージを測定（measured boot）します。ハッシュ値はTPMチップ内のPCR（Platform Configuration Register）レジスタに記録され、vCenterがその信頼性を自動検証します。
各アプローチのメリット・デメリット分析
| ソリューション | メリット | デメリット |
|---|---|---|
| ログ監視 / ファイルハッシュ検証 | 既存ハードウェアを活用でき、追加コストがかからない。 | root権限を奪取された場合ログを容易に消去される；即時対応が困難。 |
| UEFI Secure Bootのみの有効化 | サーバーの標準マザーボード（Dell R740/R750、HPE DL380など）に標準搭載されており、BIOSで有効化するだけで利用可能。 | measured bootの仕組みがなく、vCenterからシステム全体の完全性を検証できない。 |
| TPM 2.0 + Host Attestation | ハードウェアのRoot of Trust（信頼の基点）から保護され、vCenter上でPassed/Failedの状態を即座に把握可能。ISO 27001やPCI-DSS基準に適合。 | 専用TPMモジュールの購入コストが発生する（1ノードあたり約100万〜200万VND／約1万〜2万円）；設定時に物理ホストの再起動が必要。 |
システムに最適なソリューションの選択
ラボ環境や社内検証用サーバーであれば、単独のUEFI Secure Bootでも十分な安全性を確保できます。しかし本番クラスターにおいては、物理TPM 2.0の導入は必須の投資と言えます。特にvTPMを必要とするWindows 11やWindows Server 2022/2025仮想マシンを展開する場合、ESXiはストレージ上にソフトキーを保持するのではなく、物理TPMを利用して安全にVMセキュリティキーを生成・管理する必要があります。
TPM 2.0の設定とHost Attestationの有効化手順
ステップ1：ハードウェアの取り付けとBIOS/UEFIでのTPM 2.0有効化
サーバーモデルに対応した正規のTPM 2.0モジュール（例：Dell PowerEdge R740/R750向けの型番0F7T4Vなど）を装着します。その後、BIOS（System Setup）を起動します。
- Boot Modeを
UEFI Modeに変更します（Legacy BIOSは完全に無効化）。 - System Security（Dellの場合）またはServer Security（HPEの場合）項目を開きます。
- TPM Securityを
Enabled / Onに設定します。 - TPM Advanced Settingsで、OS側からの読み取り権限を付与するために
TPM PPI (Physical Presence Interface)が有効になっていることを確認します。 - Secure Bootを
Enabledに設定します。 - 設定を保存し、ESXiを再起動します。
ステップ2：SSH経由でESXiによるTPM 2.0の認識状態を確認
ESXiホスト（バージョン7.0 Update 2または8.0以降）へSSH接続し、以下のコマンドを実行して暗号化ステータスを確認します。
# 1. 暗号化状態とSecure Bootのステータスを確認
esxcli system settings encryption get
# 正常時の出力結果:
# Mode: TPM
# Require Secure Boot: true続いて、ESXiのTPMドライバーが正常にロードされていることを確認します。
# 2. VMkernelによるTPMモジュールの認識ログを確認
zcat /var/log/boot.gz | grep -i tpm
# 期待される出力: TPM 2.0バージョンのtpm-crbまたはtpm-tisドライバーが表示されることログにタイムアウトエラーが出力されていたり、デバイスが見つからない場合は、サーバーのカバーを開けてマザーボード上のTPMモジュールのピン接続を再度確認してください。
ステップ3：vCenter ServerでのHost Attestationの確認
ESXiの起動が完了すると、vCenterは自動的に完全性認証プロセスを実行します。
- vSphere Client (HTML5)にログインします。
- クラスター一覧から先ほど設定したESXiホストを選択します。
- Summaryタブを開き、画面右側にあるSecurityウィジェットを確認します。
- TPM 2.0: PassedおよびSecure Boot: Enabledと表示され、緑色のチェックマークが付いていれば完了です。
もし画面上に赤色でAttestation Failedと表示された場合は、以下の実戦トラブルシューティング手順に沿って対処してください。
実践ノウハウとよくあるトラブルシューティング
1. 「Host Attestation Failed: Failed to verify identity / integrity」エラーの解決
このエラーは、ハードウェア構成の変更時や、ESXiの証明書とvCenter側に保存されているレコードの不整合によってよく発生します。ESXiを再インストールする必要はありません。vSphere Clientから実施できる最も的確な対処法は以下の3ステップです。
- ホストをMaintenance Modeに切り替えます。
- ホストを右クリックし、Certificates > Refresh CA Certificatesを選択後、続いてRenew Certificateを選択します。
- ホストを右クリックしてConnection > Disconnectを選択し、30秒ほど待ってからReconnectを選択します。
これにより、vCenterはEndorsement Key（EK）を再同期し、TPMチップからPCRレジスタの値を再取得します。ステータスは即座に緑色の正常状態へと切り替わります。
2. 署名のないVIBに起因する紫色の画面（PSOD）エラー
Secure Bootは、追加インストールされたVIBパッケージを極めて厳格に検証します。以前にCommunitySupported形式のカスタムネットワークドライバーやRAIDドライバーをインストールしていた場合、ESXiは起動を即座にブロックします。BIOSでSecure Bootを有効化する前に、以下のコマンドを実行してこれらのパッケージを事前にクリーンアップしてください。
# VMware認定外のVIBパッケージをリストアップ
esxcli software vib list | grep -E "CommunitySupported|Unknown"
# 再起動前に非認定パッケージを削除（例: net-e1000eパッケージ）
esxcli software vib remove -n net-e1000e上記コマンドのリストが完全に空であることを確認した上でSecure Bootを有効化してください。このわずかな事前確認によって、予期せぬサービス停止を未然に防ぐことができます。