保護されたファブリックとシールドされた VM の計画ガイド (ホスト向け)
このトピックでは、シールドされた仮想マシンをファブリックで実行するために必要な計画に関する決定について説明します。 既存の Hyper-V ファブリックをアップグレードするか、新しいファブリックを作成するかに関係なく、シールドされた VM の実行は 2 つの主要なコンポーネントで構成されます。
- ホスト ガーディアン サービス (HGS) は、シールドされた VM を承認された正常な Hyper-V ホストでのみ確実に実行できるよう、構成証明とキー保護を提供します。
- シールドされた VM (および通常の VM) を実行できる承認された正常な Hyper-V ホスト。これらは保護されたホストと呼ばれます。
決定事項 #1: ファブリックでの信頼レベル
ホスト ガーディアン サービスと保護された Hyper-V ホストを実装する方法は、主にファブリックで実現する信頼の強さによって異なります。 信頼の強さは、構成証明モードによって制御されます。 2 つの互いに排他的なオプションがあります。
TPM によって信頼された構成証明
目的が、悪意のある管理者や侵害されたファブリックから仮想マシンを保護することである場合は、TPM によって信頼された構成証明を使用します。 このオプションは、マルチテナント ホスティング シナリオ、およびドメイン コントローラーやコンテンツ サーバー (SQL や SharePoint など) といったエンタープライズ環境の価値の高い資産に対して有効です。 ハイパーバイザーで保護されたコード整合性 (HVCI) ポリシーが測定され、ホストでシールドされた VM の実行が許可される前に HGS によってその有効性が適用されます。
ホスト キー構成証明
要件が主に、保存時と転送中の両方で仮想マシンが暗号化されることを要求するコンプライアンスによるものである場合は、ホスト キーの構成証明を使用します。 このオプションは、Hyper-V ホストとファブリック管理者が、毎日のメンテナンスと運用のために仮想マシンのゲスト オペレーティング システムにアクセスできればよい、汎用のデータセンターに対して有効です。
このモードでは、ファブリック管理者だけが Hyper-V ホストの正常性を確保する責任を負います。 HGS は実行を許可するものと許可しないものの決定に何の役割も果たさないため、マルウェアとデバッガーは設計どおりに機能します。
ただし、WinDbg.exe などのプロセスに直接接続しようとするデバッガーは、シールドされた VM ではブロックされます。その理由は、この VM のワーカー プロセス (VMWP.exe) が保護されたプロセス ライト (PPL) であるためです。 LiveKd.exe で使用されるような代替のデバッグの手法はブロックされません。 シールドされた VM とは異なり、暗号化がサポートされている VM のワーカー プロセスは PPL として実行されないため、WinDbg.exe などの従来のデバッガーは引き続き正常に機能します。
管理者によって信頼された構成証明 (Active Directory ベース) という名前の同様の構成証明モードは、Windows Server 2019 以降では非推奨になっています。
選択した信頼レベルによって、Hyper-V ホストのハードウェア要件と、ファブリックで適用するポリシーが決まります。 必要な場合は、既存のハードウェアと管理者によって信頼された構成証明を使用して保護されたファブリックを展開した後、ハードウェアがアップグレードされ、ファブリックのセキュリティを強化する必要がある場合は、TPM によって信頼された構成証明に変換することができます。
決定事項 #2: 既存の Hyper-V ファブリックか、新しい独立した Hyper-V ファブリックか
既存のファブリック (Hyper-V など) がある場合は、おそらく、通常の VM と共にシールドされた VM を実行するためにそれを使用できます。 シールドされた VM を既存のツールとファブリックに統合するお客様もいれば、ビジネス上の理由でファブリックを分離するお客様もいます。
ホスト ガーディアン サービスに関する HGS の管理計画
専用の物理サーバー、シールドされた VM、分離された (保護対象のファブリックとは別の) Hyper-V ホスト上の VM、異なる Azure サブスクリプションを使用して論理的に分離されている場合のいずれであっても、非常に安全な環境にホスト ガーディアン サービス (HGS) を展開します。
| 領域 | 詳細 |
|---|---|
| インストール要件 |
|
| サイズ変更 | 各中規模 (8 コア/4 GB) の HGS サーバー ノードは、1,000 の Hyper-V ホストを処理できます。 |
| 管理 | HGS を管理する特定のユーザーを指定します。 ファブリック管理者とは別にする必要があります。 ちなみに、HGS クラスターは、管理の分離、物理的な展開、セキュリティ感度の全体的なレベルに関して、証明機関 (CA) と同じように考えることができます。 |
| ホスト ガーディアン サービス Active Directory | 既定では、HGS により管理のために独自の内部 Active Directory がインストールされます。 これは自己完結型で自己管理型のフォレストであり、ファブリックから HGS を分離するために推奨される構成です。 分離に使用する高い特権を持つ Active Directory フォレストが既にある場合は、HGS の既定のフォレストの代わりにそのフォレストを使用できます。 HGS が、Hyper-V ホストまたはファブリック管理ツールと同じフォレスト内のドメインに参加していないことが重要です。 そのようにすると、ファブリック管理者が HGS を制御できるようになります。 |
| 障害復旧 | 次の 3 つのオプションがあります。
|
| ホスト ガーディアン サービス キー | ホスト ガーディアン サービスは、それぞれが SSL 証明書によって表される 2 つの非対称キー ペア (暗号化キーと署名キー) を使用します。 これらのキーを生成するには、2 つのオプションがあります。
ホストは、HGS キーに加えて、"Bring Your Own Key" を使用できます。この場合、テナントで独自のキーを提供し、一部 (またはすべて) のテナントが独自の HGS キーを使用できるようにすることができます。 このオプションは、テナントがキーをアップロードするための帯域外プロセスを提供できるホストに適しています。 |
| ホスト ガーディアン サービス キーの記憶域 | 可能な限り強力なセキュリティのため、作成した HGS キーはハードウェア セキュリティ モジュール (HSM) だけに格納することをお勧めします。 HSM を使用していない場合は、HGS サーバーに BitLocker を適用することを強くお勧めします。 |
保護されたホストに関するファブリックの管理計画
| 領域 | 詳細 |
|---|---|
| ハードウェア |
|
| OS | Hyper-V ホスト OS には Server Core オプションを使用することをお勧めします。 |
| パフォーマンスへの影響 | パフォーマンス テストに基づいて、シールドされた VM とシールドされていない VM の実行では約 5% の密度差が予想されます。 つまり、特定の Hyper-V ホストで 20 個のシールドされていない VM を実行できる場合、シールドされた VM は 19 個実行できるものと予想されます。 ご自分の一般的なワークロードでサイズ設定を確認してください。 たとえば、書き込み集中型の IO ワークロードでは外れ値が発生し、密度の差にさらに影響を与える可能性があります。 |
| ブランチ オフィスに関する考慮事項 | Windows Server バージョン 1709 以降では、ブランチ オフィスでシールドされた VM としてローカルに実行されている仮想化された HGS サーバーに、フォールバック URL を指定できます。 フォールバック URL は、ブランチ オフィスがデータセンター内の HGS サーバーへの接続を失った場合に使用できます。 以前のバージョンの Windows Server では、ブランチ オフィスで実行されている Hyper-V ホストは、シールドされた VM の電源オンまたはライブ マイグレーションのために、ホスト ガーディアン サービスに接続されている必要があります。 詳しくは、「ブランチ オフィスに関する考慮事項」をご覧ください。 |