ホスト用の保護されたファブリックとシールドされた VM 計画ガイドGuarded Fabric and Shielded VM Planning Guide for Hosters

適用対象: windows server 2019、Windows Server (半期チャネル)、Windows Server 2016Applies to: Windows Server 2019, Windows Server (Semi-Annual Channel), Windows Server 2016

このトピックでは、シールドされた仮想マシンをファブリックで実行できるようにするために必要な計画の決定について説明します。This topic covers planning decisions that will need to be made to enable shielded virtual machines to run on your fabric. 既存の Hyper-v ファブリックをアップグレードするか、新しいファブリックを作成するかにかかわらず、シールドされた Vm は次の2つの主要コンポーネントで構成されます。Whether you upgrade an existing Hyper-V fabric or create a new fabric, running shielded VMs consists of two main components:

  • ホストガーディアンサービス (HGS) では、構成証明とキーの保護が提供されているため、シールドされた Vm は、承認された正常な Hyper-v ホストでのみ実行されるようにすることができます。The Host Guardian Service (HGS) provides attestation and key protection so that you can make sure that shielded VMs will run only on approved and healthy Hyper-V hosts.
  • シールドされた Vm (および通常の Vm) を実行できる承認済みの正常な Hyper-v ホスト。これらは、保護されたホストと呼ばれます。Approved and healthy Hyper-V hosts on which shielded VMs (and regular VMs) can run — these are known as guarded hosts.

HGS と保護されたホスト

Decision #1: ファブリックの信頼レベルDecision #1: Trust level in the fabric

ホストガーディアンサービスと保護された Hyper-v ホストの実装方法は、主にファブリックで実現することを検討している信頼の強さに依存します。How you implement the Host Guardian Service and guarded Hyper-V hosts will depend mainly on the strength of trust that you are looking to achieve in your fabric. 信頼の強度は、構成証明モードによって管理されます。The strength of trust is governed by the attestation mode. 相互に排他的な2つのオプションがあります。There are two mutually-exclusive options:

  1. TPM-信頼された構成証明TPM-trusted attestation

    悪意のある管理者や侵害されたファブリックから仮想マシンを保護することが目的である場合は、TPM で信頼された構成証明を使用します。If your goal is to help protect virtual machines from malicious admins or a compromised fabric, then you will use TPM-trusted attestation. このオプションは、マルチテナントホスティングシナリオや、ドメインコントローラーや SQL や SharePoint などのコンテンツサーバーなどのエンタープライズ環境での価値の高い資産に適しています。This option works well for multi-tenant hosting scenarios as well as for high-value assets in enterprise environments, such as domain controllers or content servers like SQL or SharePoint. ホストでシールドされた Vm の実行が許可される前に、ハイパーバイザーで保護されたコード整合性 (HVCI) ポリシーが、HGS によって適用されます。Hypervisor-protected code integrity (HVCI) policies are measured and their validity enforced by HGS before the host is permitted to run shielded VMs.

  2. ホストキーの構成証明Host key attestation

    要件が主にコンプライアンスによって行われ、仮想マシンが保存された場所と実行中の両方で暗号化される必要がある場合は、ホストキーの構成証明を使用します。If your requirements are primarily driven by compliance that requires virtual machines be encrypted both at rest as well as in-flight, then you will use host key attestation. このオプションは、日常のメンテナンスや操作を行うために仮想マシンのゲストオペレーティングシステムにアクセスする Hyper-v ホストとファブリック管理者に慣れている汎用のデータセンターに適しています。This option works well for general purpose datacenters where you are comfortable with Hyper-V host and fabric administrators having access to the guest operating systems of virtual machines for day-to-day maintenance and operations.

    このモードでは、ファブリック管理者は Hyper-v ホストの正常性を保証するだけです。In this mode, the fabric admin is solely responsible for ensuring the health of the Hyper-V hosts. HGS は、実行が許可されているかどうかを判断するためには何も行わないため、マルウェアとデバッガーは設計どおりに機能します。Since HGS plays no part in deciding what is or is not allowed to run, malware and debuggers will function as designed.

    ただし、VM のワーカープロセス (VMWP.exe) は保護されたプロセスライト (PPL) であるため、プロセス (WinDbg.exe など) に直接アタッチしようとするデバッガーは、シールドされた Vm に対してブロックされます。However, debuggers that attempt to attach directly to a process (such as WinDbg.exe) are blocked for shielded VMs because the VM's worker process (VMWP.exe) is a protected process light (PPL). LiveKd.exe によって使用されるような代替のデバッグ手法はブロックされません。Alternative debugging techniques, such as those used by LiveKd.exe, are not blocked. シールドされた Vm とは異なり、暗号化がサポートされている Vm のワーカープロセスは PPL として実行されないため、WinDbg.exe などの従来のデバッガーは引き続き正常に機能します。Unlike shielded VMs, the worker process for encryption supported VMs does not run as a PPL so traditional debuggers like WinDbg.exe will continue to function normally.

    管理者によって信頼された構成証明 (Active Directory ベース) という同様の構成証明モードは、Windows Server 2019 以降では非推奨とされます。A similar attestation mode named Admin-trusted attestation (Active Directory-based) is deprecated beginning with Windows Server 2019.

選択する信頼レベルにより、Hyper-v ホストのハードウェア要件と、ファブリックに適用するポリシーが決まります。The trust level you choose will dictate the hardware requirements for your Hyper-V hosts as well as the policies that you apply on the fabric. 必要に応じて、既存のハードウェアと管理者によって信頼された構成証明を使用して保護されたファブリックをデプロイし、ハードウェアがアップグレードされ、ファブリックのセキュリティを強化する必要がある場合に、TPM によって信頼された構成証明書に変換することができます。If necessary, you can deploy your guarded fabric using existing hardware and admin-trusted attestation and then convert it to TPM-trusted attestation when the hardware has been upgraded and you need to strengthen fabric security.

Decision #2: 既存の Hyper-v ファブリックと新しい個別の Hyper-v ファブリックの比較Decision #2: Existing Hyper-V fabric versus a new separate Hyper-V fabric

既存のファブリック (Hyper-v またはそれ以外) がある場合は、通常の Vm と共にシールドされた Vm を実行するために使用できる可能性が非常に高くなります。If you have an existing fabric (Hyper-V or otherwise), it is very likely that you can use it to run shielded VMs along with regular VMs. 一部のお客様は、シールドされた Vm を既存のツールやファブリックに統合し、他のユーザーはビジネス上の理由でファブリックを分離することを選択しています。Some customers choose to integrate shielded VMs into their existing tools and fabrics while others separate the fabric for business reasons.

HGS 管理者によるホストガーディアンサービスの計画HGS admin planning for the Host Guardian Service

ホストガーディアンサービス (HGS) を、専用の物理サーバー、シールドされた VM、分離された Hyper-v ホスト上の VM (保護対象のファブリックから分離)、または別の Azure サブスクリプションを使用して論理的に分離された環境に展開します。Deploy the Host Guardian Service (HGS) in a highly secure environment, whether that be on a dedicated physical server, a shielded VM, a VM on an isolated Hyper-V host (separated from the fabric it's protecting), or one logically separated by using a different Azure subscription.

領域Area 詳細Details
インストール要件Installation requirements
  • 1台のサーバー (高可用性のために推奨される3ノードクラスター)One server (three-node cluster recommended for high availability)
  • フォールバックでは、少なくとも2つの HGS サーバーが必要ですFor fallback, at least two HGS servers are required
  • サーバーは、仮想または物理 (TPM 2.0 を使用する物理サーバーを推奨) のいずれかにすることができます。TPM 1.2 もサポートされています)Servers can be either virtual or physical (physical server with TPM 2.0 recommended; TPM 1.2 also supported)
  • Windows Server 2016 以降の server Core インストールServer Core installation of Windows Server 2016 or later
  • ネットワーク回線がファブリックに認識され、HTTP またはフォールバックの構成が可能Network line of sight to the fabric allowing HTTP or fallback configuration
  • アクセス検証に推奨される HTTPS 証明書HTTPS certificate recommended for access validation
サイズ変更Sizing 各中間サイズ (8 コア/4 GB) の HGS サーバーノードは、1000の Hyper-v ホストを処理できます。Each mid-size (8 core/4 GB) HGS server node can handle 1,000 Hyper-V hosts.
管理Management HGS を管理する特定のユーザーを指定します。Designate specific people who will manage HGS. ファブリック管理者とは別のものにする必要があります。They should be separate from fabric administrators. 比較のために、HGS クラスターは、管理の分離、物理的な展開、および全体的なセキュリティのレベルに関して、証明機関 (CA) と同じ方法で考えることができます。For comparison, HGS clusters can be thought of in the same manner as a Certificate Authority (CA) in terms of administrative isolation, physical deployment and overall level of security sensitivity.
ホストガーディアンサービス Active DirectoryHost Guardian Service Active Directory 既定では、HGS は管理のために独自の内部 Active Directory をインストールします。By default, HGS installs its own internal Active Directory for management. これは自己完結型の自己管理型フォレストであり、ファブリックから HGS を分離するために推奨される構成です。This is a self-contained, self-managed forest and is the recommended configuration to help isolate HGS from your fabric.

分離に使用する高い特権を持つ Active Directory フォレストが既にある場合は、HGS の既定のフォレストではなく、そのフォレストを使用することができます。If you already have a highly privileged Active Directory forest that you use for isolation, you can use that forest instead of the HGS default forest. HGS は、Hyper-v ホストまたはファブリック管理ツールと同じフォレスト内のドメインに参加していないことが重要です。It is important that HGS is not joined to a domain in the same forest as the Hyper-V hosts or your fabric management tools. これにより、ファブリック管理者は HGS を制御できるようになります。Doing so could allow a fabric admin to gain control over HGS.
障害復旧Disaster recovery 次の 3 つのオプションがあります。There are three options:
  1. 各データセンターに個別の HGS クラスターをインストールし、シールドされた Vm をプライマリデータセンターとバックアップデータセンターの両方で実行することを承認します。Install a separate HGS cluster in each datacenter and authorize shielded VMs to run in both the primary and the backup datacenters. これにより、WAN を介してクラスターを拡張する必要がなくなり、指定されたサイトでのみ実行されるようにバーチャルマシンを分離することができます。This avoids the need to stretch the cluster across a WAN and allows you to isolate virtual machines such that they run only in their designated site.
  2. 2つ (以上) のデータセンター間の拡張クラスターに HGS をインストールします。Install HGS on a stretch cluster between two (or more) datacenters. これは、WAN がダウンした場合に回復性を提供しますが、フェールオーバークラスタリングの制限をプッシュします。This provides resiliency if the WAN goes down, but pushes the limits of failover clustering. ワークロードを1つのサイトに分離することはできません。1つのサイトで実行することが承認されている VM は、他のサイトでも実行できます。You cannot isolate workloads to one site; a VM authorized to run in one site can run on any other.
  3. Hyper-v ホストを別の HGS にフェールオーバーとして登録します。Register your Hyper-V host with another HGS as failover.
また、常にローカルで回復できるように、すべての HGS の構成をエクスポートしてバックアップする必要があります。You should also backup every HGS by exporting its configuration so that you can always recover locally. 詳細については、「 HgsServerStateHgsServerState」を参照してください。For more information, see Export-HgsServerState and Import-HgsServerState.
ホストガーディアンサービスキーHost Guardian Service keys ホストガーディアンサービスでは、暗号化キーと署名キーの2つの非対称キーペアが使用されます。これらはそれぞれ SSL 証明書によって表されます。A Host Guardian Service uses two asymmetric key pairs — an encryption key and a signing key — each represented by an SSL certificate. これらのキーを生成するには、次の2つのオプションがあります。There are two options to generate these keys:
  1. 内部証明機関–内部 PKI インフラストラクチャを使用してこれらのキーを生成できます。Internal certificate authority – you can generate these keys using your internal PKI infrastructure. これは、データセンター環境に適しています。This is suitable for a datacenter environment.
  2. 公的に信頼された証明機関–公的に信頼された証明機関から取得した一連のキーを使用します。Publicly trusted certificate authorities – use a set of keys obtained from a publicly trusted certificate authority. これは、ホスト側で使用するオプションです。This is the option that hosters should use.
自己署名証明書を使用することはできますが、概念実証ラボ以外の展開シナリオでは推奨されません。Note that while it is possible to use self-signed certificates, it is not recommended for deployment scenarios other than proof-of-concept labs.

HGS キーを使用するだけでなく、ホストは "独自のキーを持ち込む" こともできます。テナントは独自のキーを提供できるため、一部のテナント (またはすべてのテナント) は独自の HGS キーを持つことができます。In addition to having HGS keys, a hoster can use "bring your own key," where tenants can provide their own keys so that some (or all) tenants can have their own specific HGS key. このオプションは、テナントがキーをアップロードするためのアウトオブバンドプロセスを提供できるホストに適しています。This option is suitable for hosters that can provide an out-of-band process for tenants to upload their keys.
ホストガーディアンサービスのキーの保存Host Guardian Service key storage 可能な限り強力なセキュリティを実現するために、HGS キーを作成してハードウェアセキュリティモジュール (HSM) に排他的に保存することをお勧めします。For the strongest possible security, we recommend that HGS keys are created and stored exclusively in a Hardware Security Module (HSM). Hsm を使用していない場合は、HGS サーバーに BitLocker を適用することを強くお勧めします。If you are not using HSMs, applying BitLocker on the HGS servers is strongly recommended.

ファブリック管理者による保護されたホストの計画Fabric admin planning for guarded hosts

領域Area 詳細Details
ハードウェアHardware
OSOS Hyper-v ホスト OS には、Server Core オプションを使用することをお勧めします。We recommend using Server Core option for the Hyper-V host OS.
パフォーマンスへの影響Performance implications パフォーマンステストに基づいて、シールドされた Vm とシールドされていない Vm の間で、ほぼ5% の密度に差があることを想定しています。Based on performance testing, we anticipate a roughly 5% density-difference between running shielded VMs and non-shielded VMs. これは、特定の Hyper-v ホストで20個のシールドされていない Vm を実行できる場合、19個のシールドされた Vm を実行できることを想定しています。This means that if a given Hyper-V host can run 20 non-shielded VMs, we expect that it can run 19 shielded VMs.

一般的なワークロードでサイズ設定を確認してください。Make sure to verify sizing with your typical workloads. たとえば、密度の差にさらに影響を与える書き込み指向 IO ワークロードを使用した外れ値がある可能性があります。For example, there might be some outliers with intensive write-oriented IO workloads that will further affect the density difference.
ブランチ オフィスに関する考慮事項Branch office considerations Windows Server バージョン1709以降では、ブランチオフィスでシールドされた VM としてローカルで実行されている仮想化 HGS サーバーのフォールバック URL を指定できます。Beginning with Windows Server version 1709, you can specify a fallback URL for a virtualized HGS server running locally as a shielded VM in the branch office. フォールバック URL は、ブランチオフィスがデータセンター内の HGS サーバーへの接続を失ったときに使用できます。The fallback URL can be used when the branch office loses connectivity to HGS servers in the datacenter. 以前のバージョンの Windows Server では、ブランチオフィスで実行されている Hyper-v ホストは、ホストガーディアンサービスに接続して、電源オンまたはシールドされた Vm のライブマイグレーションを行う必要があります。On previous versions of Windows Server, a Hyper-V host running in a branch office needs connectivity to the Host Guardian Service to power-on or to live migrate shielded VMs. 詳細については、「 ブランチオフィスの考慮事項」を参照してください。For more information, see Branch office considerations.