vSphere 信頼機関 プロセス フローを理解することは、信頼済みインフラストラクチャを構成および管理する方法を学習するために不可欠です。
vSphere 信頼機関 の構成方法
デフォルトでは、vSphere 信頼機関 は有効になっていません。環境内の vSphere 信頼機関 を手動で設定する必要があります。vSphere 信頼機関 の設定を参照してください。
vSphere 信頼機関 を構成するときには、証明サービスが受け入れる ESXi ソフトウェアのバージョン、および信頼できる Trusted Platform Module (TPM) を指定する必要があります。
TPM と証明
このガイドでは、TPM と証明についての説明に次の定義を使用します。
| 用語 | 定義 |
|---|---|
| 承認キー (EK) | TPM は、承認キー (EK) と呼ばれる RSA パブリック/プライベート キー ペアがハードウェアに組み込まれた状態で製造されています。EK は個々の TPM ごとに固有です。 |
| EK パブリック キー | EK キー ペアのパブリック部分。 |
| EK プライベート キー | EK キー ペアのプライベート部分。 |
| EK 証明書 | EK パブリック キーが署名付きでラップされています。EK 証明書は、認証局のプライベート キーを使用して EK パブリック キーに署名する TPM メーカーによって作成されます。すべての TPM に EK 証明書が含まれているわけではありません。その場合、EK パブリック キーは署名されていません。 |
| TPM 証明 | リモート ホストで実行されているソフトウェアを検証する証明サービスの機能。TPM 証明は、リモート ホストの起動時に TPM によって行われる暗号化測定を通じて行われ、要求に応じて証明サービスに渡されます。証明サービスは、EK パブリック キーまたは EK 証明書のいずれかを介して TPM 内の信頼を確立します。 |
信頼済みホストでの TPM 信頼の設定
ESXi 信頼済みホストには、TPM が含まれている必要があります。TPM は、承認キー (EK) と呼ばれるパブリック/プライベート キー ペアがハードウェアに組み込まれた状態で製造されています。TPM 2.0 では多くのキー/証明書ペアが許可されますが、最も一般的なものは RSA-2048 キー ペアです。TPM EK パブリック キーが CA によって署名されている場合、EK 証明書が得られます。通常、TPM の製造元は少なくとも 1 つの EK を事前に生成し、認証局を使用してパブリック キーに署名して、署名付きの証明書を TPM の不揮発性メモリに埋め込みます。
証明サービスは、次のように TPM を信頼するように設定できます。
- 製造元が TPM への署名に使用したすべての認証局証明書を信頼します（EK パブリック キー）。証明サービスのデフォルト設定では、認証局証明書を信頼します。この方法では、1 つの認証局証明書で多くの ESXi ホストに対応できるため、管理オーバーヘッドが軽減されます。
- ESXi ホストの TPM 認証局証明書と EK パブリック キーを信頼します。後者は、EK 証明書または EK パブリック キーのいずれかです。この方法ではセキュリティが強化されますが、各信頼済みホストに関する情報を設定する必要があります。
- 一部の TPM には EK 証明書が含まれていません。その場合は、EK パブリック キーを信頼します。
すべての TPM 認証局証明書を信頼するよう決定すると、運用面で利便性が向上します。新しい証明書は、新しいクラスのハードウェアをデータセンターに追加する場合にのみ設定します。個々の EK 証明書を信頼するようにすると、特定の ESXi ホストへのアクセスを制限できます。
TPM 認証局証明書を信頼しないよう決定することもできます。あまり発生しない状況ではありますが、この設定は EK が認証局によって署名されていない場合に使用できます。現在、この機能は全面的には実装されていません。
TPM の証明
証明プロセスを開始するために、信頼済みクラスタ内の ESXi 信頼済みホストが事前設定済みの EK パブリック キーと EK 証明書を Trust Authority クラスタの証明サービスに送信します。証明サービスは、要求を受信すると設定内で EK を検索します。EK は、設定に応じて EK パブリック キーか EK 証明書、またはその両方です。有効なものが見つからない場合、証明サービスは証明の要求を拒否します。
EK は署名には直接使用されないため、認証キー（AK または AIK）がネゴシエートされます。ネゴシエーション プロトコルにより、新しく作成された AK が検証済みの EK にバインドされ、中間者攻撃やなりすましが確実に回避されます。ネゴシエートされた AK は将来の認証要求で再利用され、毎回 AK が生成されることはありません。
ESXi 信頼済みホストは、TPM から Quote と PCR の値を読み取ります。Quote は AK によって署名されています。ESXi 信頼済みホストは TCG イベント ログも読み取ります。これには、現在の PCR 状態をもたらしたすべてのイベントが含まれます。この TPM 情報は、検証のために証明サービスに送信されます。証明サービスはイベント ログを使用して PCR の値を確認します。
キー プロバイダとキー サーバの連携方法
キー プロバイダ サービスは、信頼済みキー プロバイダの考え方を使用して、データセンターの他のソフトウェアからキー サーバの詳細を隠蔽します。信頼済みキー プロバイダはそれぞれが 1 つの設定済みプライマリ暗号化キーを持ち、1 台以上のキー サーバを参照します。プライマリ暗号化キーは、キー サーバに置かれます。vSphere 信頼機関 の構成の一部として、プライマリ キーを別個のアクティビティとしてプロビジョニングし、有効にする必要があります。キー プロバイダ サービスでは、いくつかの信頼済みキー プロバイダを設定できます。信頼済みキー プロバイダはそれぞれ異なるプライマリ キーを使用しますが、同じバッキング キー サーバを参照できます。
新しい信頼済みキー プロバイダが追加された場合、信頼機関管理者は、キー サーバと、そのキー サーバ上の既存のキー識別子を指定する必要があります。
次の図に、キー プロバイダ サービスとキー サーバの関係を示します。
信頼済みクラスタに対して信頼済みキー プロバイダを設定すると、キー プロバイダ サービスは、その信頼済みキー プロバイダに対して暗号化操作を実行する要求を受け入れることができます。たとえば、この図では、3 つの信頼済みキー プロバイダ（KMS-1 用として 2 つ、KMS-2 用として 1 つ）が設定されています。信頼済みホストは、キー プロバイダ 2 に対して暗号化操作を要求します。信頼済みホストは、暗号化キーが生成されて返されることを要求し、この暗号化キーを使用して暗号化操作を実行します。
キー プロバイダ サービスは、キー プロバイダ 2 が参照するプライマリ キーを使用して、指定されたプレーンテキスト データを暗号化し、対応する暗号テキストを返します。その後、信頼済みホストは、復号化操作に対して同じ暗号テキストを提供して、元のプレーンテキストを取得できます。
vSphere 信頼機関 の認証と認可
vSphere 信頼機関 管理操作には、TrustedAdmins グループのメンバーであるユーザーが必要です。信頼機関管理者の権限だけでは、ESXi ホストが関係するすべての管理操作を実行することはできません。詳細については、『vSphere 信頼機関の前提条件と必要な権限』を参照してください。
信頼済みクラスタへの信頼済みホストの追加
信頼済みクラスタに ESXi ホストを初めて追加するときの手順については、vSphere 信頼機関 の設定を参照してください。
その後、信頼済みクラスタに ESXi ホストを追加するときは、ワークフローが異なります。vSphere 信頼機関 ホストの追加と削除を参照してください。
信頼済みクラスタに ESXi ホストを初めて追加するときは、次の情報を収集する必要があります。
- クラスタ内の各ハードウェア タイプの TPM 証明書
- クラスタ内にある ESXi の各バージョンの ESXi イメージ
- vCenter Server のプリンシパル情報
信頼済みクラスタに後から ESXi ホストを追加するとき、いくつかの追加的な情報の収集が必要になることがあります。具体的には、新しい ESXi ホストのハードウェアまたは ESXi のバージョンが元のホストと異なる場合、新しい ESXi ホストの情報を収集して、それを信頼機関クラスタにインポートする必要があります。vCenter Server のプリンシパル情報は、vCenter Server システムごとに 1 回のみ収集する必要があります。
