ホスト ガーディアン サービスの管理

ホスト ガーディアン サービス (HGS) は、保護されたファブリック ソリューションの中心的な働きをします。 これは、ファブリック内の Hyper-V ホストがホスト側またはエンタープライズおよび実行中の信頼されたソフトウェアから認識されるようにし、シールドされた VM を起動するために使用するキーを管理する役割を担っています。 テナントは、シールドされた VM をホストすることを任せることに決めた場合、ホスト ガーディアン サービスの構成と管理に信頼を置きます。 そのため、保護されたファブリックのセキュリティ、可用性、および信頼性を確保するために、ホスト ガーディアン サービスを管理するときは ベストプラクティスに従うことが非常に重要です。 以下のセクションのガイダンスでは、HGS の管理者が直面する最も一般的な操作上の問題について説明します。

HGS への管理者アクセスを制限する

HGS がセキュリティ上重要な性質を持っているため、その管理者は組織の十分に信頼されたメンバーであり、理想的には、ファブリック リソースの管理者とは別の人であるようにすることが重要です。 また、HGS の管理は、HTTPS 経由の WinRM などのセキュリティで保護された通信プロトコルを使用して、セキュリティで保護されたワークステーションからのみ行うことをお勧めします。

職務の分離

HGS を設定するときに、HGS 専用の分離された Active Directory フォレストを作成するか、既存の信頼されたドメインに HGS を参加させるかを選択できます。 この決定と、組織内で管理者を割り当てる役割によって、HGS の信頼境界が決定されます。 HGS にアクセスできるすべてのユーザーは、管理者として直接であろうが、あるいは HGS に影響を与えることのできる別の機能 (Active Directory など) の管理者であろうが、保護されたファブリックを制御できます。 HGS 管理者は、シールドされた VM を実行する権限がある Hyper-V ホストを選択し、シールドされた VM を起動するために必要な証明書を管理します。 HGS にアクセスできる攻撃者や悪意のある管理者は、この権限を使用して、侵害されたホストがシールドされた VM を実行することを承認し、キー マテリアルを削除してサービス拒否攻撃を開始することができます。

このリスクを回避するには、HGS (HGS が参加するドメインを含む) の管理者と Hyper-V 環境の重複を制限することを "強く" お勧めします。 1 人の管理者が両方のシステムにアクセスできないようにすることで、攻撃者が HGS ポリシーを変更する任務を完了するには、2 人の個人から 2 つの異なるアカウントを侵害することが必要になります。 これは、2 つの Active Directory 環境のドメイン管理者とエンタープライズ管理者が同じ人物であってはならず、HGS で同一の Active Directory フォレストを複数の Hyper-V ホストとして使用してはならないことを意味します。 より多くのリソースへのアクセス権を自分に付与できるユーザーは、セキュリティ上のリスクになります。

Just Enough Administration の使用

HGS には、より安全に管理するのに役立つ Just Enough Administration (JEA) ロールが組み込まれています。 JEA は、管理者のタスクを管理者以外のユーザーに委任できるようにするために役立ちます。つまり、HGS ポリシーを管理するユーザーは、実際にコンピューターまたはドメイン全体の管理者である必要はありません。 JEA は、ユーザーが PowerShell セッションで実行できるコマンドを制限し、裏側で一時的なローカルアカウント (各ユーザーセッションで一意) を使用して、通常は昇格が必要なコマンドを実行することによって機能します。

HGS には、2 つの JEA ロールがあらかじめ構成されています。

  • HGS 管理者は、シールドされた VM を実行する新しいホストの承認など、すべての HGS ポリシーを管理することをユーザーに許可します。
  • HGS レビュー担当者は、既存のポリシーを監査する権利のみユーザーに許可します。 HGS の構成に変更を加えることはできません。

JEA を使用するには、最初に新しい標準ユーザーを作成し、そのユーザーを HGS 管理者グループまたは HGS レビュー担当者グループのメンバーにする必要があります。 Install-HgsServer を使用して HGS の新しいフォレストを設定する場合、これらのグループにはそれぞれ "servicenameAdministrators" と "servicenameReviewers" という名前が付けられます。ここで、servicename は HGS クラスターのネットワーク名です。 HGS を既存のドメインに参加させた場合、Initialize-HgsServer で指定したグループ名を参照する必要があります。

HGS 管理者ロールとレビュー担当者ロールのための標準ユーザーを作成する

$hgsServiceName = (Get-ClusterResource HgsClusterResource | Get-ClusterParameter DnsName).Value
$adminGroup = $hgsServiceName + "Administrators"
$reviewerGroup = $hgsServiceName + "Reviewers"

New-ADUser -Name 'hgsadmin01' -AccountPassword (Read-Host -AsSecureString -Prompt 'HGS Admin Password') -ChangePasswordAtLogon $false -Enabled $true
Add-ADGroupMember -Identity $adminGroup -Members 'hgsadmin01'

New-ADUser -Name 'hgsreviewer01' -AccountPassword (Read-Host -AsSecureString -Prompt 'HGS Reviewer Password') -ChangePasswordAtLogon $false -Enabled $true
Add-ADGroupMember -Identity $reviewerGroup -Members 'hgsreviewer01'

レビュー担当者ロールを使用してポリシーを監査する

HGS にネットワーク接続されているリモート コンピューターから、PowerShell で次のコマンドを実行して、レビュー担当者の資格情報で JEA セッションを開始します。 レビュー担当者アカウントは単なる標準ユーザーであるため、通常の Windows PowerShell のリモート処理や、HGS へのリモート デスクトップアクセスなどには使用できないことに注意してください。

Enter-PSSession -ComputerName <hgsnode> -Credential '<hgsdomain>\hgsreviewer01' -ConfigurationName 'microsoft.windows.hgs'

次に、Get-Command を使用して、セッションで許可されているコマンドを確認し、許可されたコマンドを実行して構成を監査できます。 次の例では、HGS で有効になっているポリシーを確認しています。

Get-Command

Get-HgsAttestationPolicy

JEA セッションの操作が完了したら、コマンド Exit-PSSession またはそのエイリアスである exit を入力します。

管理者ロールを使用して HGS に新しいポリシーを追加する

ポリシーを実際に変更するには、'hgsAdministrators' グループに属している ID を使用して JEA エンドポイントに接続する必要があります。 次の例では、新しいコードの整合性ポリシーを HGS にコピーし、JEA を使用して登録する方法を示します。 構文は、使い慣れたものとは異なる場合があります。 これは、ファイル システム全体にアクセスできないなど、JEA のいくつかの制限に対応するためです。

$cipolicy = Get-Item "C:\temp\cipolicy.p7b"
$session = New-PSSession -ComputerName <hgsnode> -Credential '<hgsdomain>\hgsadmin01' -ConfigurationName 'microsoft.windows.hgs'
Copy-Item -Path $cipolicy -Destination 'User:' -ToSession $session

# Now that the file is copied, we enter the interactive session to register it with HGS
Enter-PSSession -Session $session
Add-HgsAttestationCiPolicy -Name 'New CI Policy via JEA' -Path 'User:\cipolicy.p7b'

# Confirm it was added successfully
Get-HgsAttestationPolicy -PolicyType CiPolicy

# Finally, remove the PSSession since it is no longer needed
Exit-PSSession
Remove-PSSession -Session $session

HGS の監視

イベント ソースと転送

HGS からのイベントは、Windows イベント ログで、次の 2 つのソースに表示されます。

  • HostGuardianService-Attestation
  • HostGuardianService-KeyProtection

これらのイベントを表示するには、イベント ビューアーを開き、Microsoft-Windows-HostGuardianService-Attestation と Microsoft-Windows-HostGuardianService-KeyProtection に移動します。

大規模な環境では、イベントの分析を容易にするために、中央の Windows イベント コレクターにイベントを転送することをお勧めします。 詳細については、Windows イベント転送に関するドキュメントを参照してください。

System Center Operations Manager の使用

System Center 2016 - Operations Manager を使用して、HGS と保護されたホストを監視することもできます。 保護されたファブリック管理パックには、構成証明を通過しないホストや、エラーを報告する HGS サーバーなど、データセンターのダウンタイムにつながる可能性がある一般的な構成の誤りをチェックするイベント モニターがあります。

まず、SCOM 2016 をインストールして構成 し、保護されたファブリック管理パックをダウンロードします。 付属の管理パックガイドでは、管理パックを構成し、そのモニターの範囲を理解する方法が説明されています。

HGS のバックアップおよび復元

ディザスター リカバリー計画

ディザスター リカバリー計画を作成するときは、保護されたファブリックでのホスト ガーディアン サービスの固有の要件を考慮することが重要です。 HGS ノードの一部またはすべてを失った場合、シールドされた VM をユーザーが起動できなくなる緊急性の高い可用性の問題に直面する可能性があります。 HGS クラスター全体が失われるシナリオでは、HGS クラスターを復元して通常の操作を再開するために、HGS 構成の完全なバックアップを手元に保持することが必要になります。 このセクションでは、このようなシナリオに対して準備するために必要な手順について説明します。

まず、HGS のバックアップが重要であることを理解しておくことが重要です。 HGS には、シールドされた VM の実行を承認されているホストを特定するのに役立ついくつかの情報が保持されます。 これには次のものが含まれます

  1. 信頼されたホストを含むグループの Active Directory セキュリティ識別子 (Active Directory 構成証明を使用する場合)。
  2. 環境内の各ホストの一意の TPM 識別子。
  3. ホストの一意の構成ごとの TPM ポリシー。
  4. ホストで実行が許可されているソフトウェアを決定するコードの整合性ポリシー。

これらの構成証明の成果物は、取得するのにホスト側のファブリックの管理者との調整が必要であることから、障害発生後にこの情報を再度取得することが困難になる可能性があります。

さらに、HGS では、シールドされた VM を起動するために必要な情報の暗号化と署名に使用する、2 つ以上の証明書へのアクセスを必要とします (キーの保護機能)。 これらの証明書は既知のもので (シールドされた VM の所有者が VM を実行するファブリックを承認するために使用されます)、シームレスな回復エクスペリエンスのために、障害の発生後に復元する必要があります。 障害発生後に同じ証明書を使用して HGS を復元しない場合、各 VM を更新して、情報の暗号化を解除するために新しいキーを承認する必要があります。 セキュリティ上の理由により、VM の所有者のみが VM 構成を更新してこれらの新しいキーを承認できます。つまり、障害発生後にキーの復元に失敗すると、各 VM 所有者が、VM を再び実行するための措置を講じる必要があります。

最悪の事態のための準備

HGS の完全な損失に対して準備するには、次の 2 つの手順を実行する必要があります。

  1. HGS 構成証明ポリシーをバックアップする
  2. HGS キーをバックアップする

これらの手順を実行する方法のガイダンスについては、「HGS のバックアップ」のセクションを参照してください。

また、HGS を管理する権限を持つユーザーの一覧を、その Active Directory ドメイン内で (または Active Directory 自体を) バックアップすることも推奨されますが、必須ではありません。

情報が最新となるようにバックアップを定期的に作成し、改ざんや盗難を防ぐために安全に保管する必要があります。

HGS ノードのシステム イメージ全体をバックアップしたり復元したりすることはお勧めしません。 クラスター全体が失われた場合、ベスト プラクティスは、サーバー OS 全体ではなく、新しい HGS ノードを設定して HGS の状態のみを復元することです。

1 つのノードの損失からの回復

HGS クラスター内の 1 つまたは複数のノード (すべてのノードではない) が失われた場合、展開ガイドのガイダンスに従って、単純にクラスターにノードを追加することができます。 構成証明ポリシーは自動的に同期され、付随するパスワードとともに PFX ファイルとして HGS に提供されたすべての証明書も同様です。 拇印を使用して HGS に追加された証明書 (一般的には、エクスポートできないハードウェアベースの証明書など) については、それぞれの新しいノードから各証明書の秘密キーにアクセスできるようにする必要があります。

クラスター全体の損失からの回復

HGS クラスター全体が停止し、オンラインに戻すことができない場合は、バックアップから HGS を復元する必要があります。 バックアップから HGS を復元するには、まず展開ガイドのガイダンスに従って新しい HGS クラスターを設定します。 ホストからの名前解決を支援するために、回復 HGS 環境を設定するときに同じクラスター名を使用することを強くお勧めしますが、必須ではありません。 同じ名前を使用すると、新しい構成証明およびキー保護 URL を使用してホストを再構成する必要がなくなります。 Active Directory ドメインがサポートする HGS にオブジェクトを復元した場合、HGS サーバーを初期化する前に、HGS クラスター、コンピューター、サービス アカウント、および JEA グループを表すオブジェクトを削除することをお勧めします。

最初の HGS ノードを設定したら (つまり、インストールして初期化されたら)、「バックアップからの HGS の復元」の手順に従って、構成証明ポリシーと、キー保護証明書の公開された両方の部分を復元します。 証明書プロバイダーのガイダンスに従って、証明書の秘密キーを手動で復元する必要があります (たとえば、Windows に証明書をインポートするか、HSM ベースの証明書へのアクセスを構成します)。 最初のノードが設定されたら、必要な容量と回復性に達するまで、クラスターに追加のノードをインストールし続けることができます。

HGS のバックアップ

HGS 管理者は、HGS のバックアップを定期的に行う必要があります。 完全バックアップには、適切に保護する必要がある重要なキー マテリアルが含まれています。 信頼されていないエンティティがこれらのキーにアクセスできるようになると、シールドされた VM を侵害するために、そのマテリアルを使用して、悪意のある HGS 環境を設定することができます。

構成証明ポリシーのバックアップ HGS 構成証明ポリシーをバックアップするには、任意の有効な HGS サーバー ノードで次のコマンドを実行します。 パスワードの入力を求めるメッセージが表示されます。 このパスワードは、(証明書の拇印ではなく) PFX ファイルを使用して HGS に追加されたすべての証明書を暗号化するために使用されます。

Export-HgsServerState -Path C:\temp\HGSBackup.xml

注意

管理者によって信頼された構成証明を使用している場合は、保護されたホストを承認するために HGS によって使用されるセキュリティ グループのメンバーシップを個別にバックアップする必要があります。 HGS では、セキュリティ グループの SID のみがバックアップされ、その中のメンバーシップはバックアップされません。 これらのグループが障害発生時に失われた場合は、グループを再作成し、保護された各ホストを再度追加する必要があります。

証明書のバックアップ

Export-HgsServerState コマンドでは、コマンドの実行時に HGS に追加された PFX ベースの証明書をバックアップします。 拇印を使用して証明書を HGS に追加した場合 (エクスポートできないハードウェアベースの証明書の場合は通常)、証明書の秘密キーを手動でバックアップする必要があります。 HGS に登録されていて手動でバックアップする必要がある証明書を特定するには、任意の有効な HGS サーバー ノードで次の PowerShell コマンドを実行します。

Get-HgsKeyProtectionCertificate | Where-Object { $_.CertificateData.GetType().Name -eq 'CertificateReference' } | Format-Table Thumbprint, @{ Label = 'Subject'; Expression = { $_.CertificateData.Certificate.Subject } }

一覧表示された各証明書について、秘密キーを手動でバックアップする必要があります。 エクスポートできないソフトウェアベースの証明書を使用している場合は、証明機関に連絡して証明書のバックアップがあること、および必要に応じて再発行できることを確認する必要があります。 ハードウェア セキュリティ モジュールで作成および保存された証明書については、デバイスのドキュメントでディザスター リカバリー計画のガイダンスを参照してください。

証明書のバックアップと構成証明ポリシーのバックアップを、セキュリティで保護された場所に一緒に保存し、両方を一緒に復元できるようにする必要があります。

バックアップする追加の構成

バックアップされた HGS サーバーの状態には、HGS クラスターの名前、Active Directory の情報、または HGS API との通信をセキュリティで保護するために使用される SSL 証明書は含まれていません。 これらの設定は整合性のために重要ですが、障害発生後に HGS クラスターをオンラインに戻すために不可欠というわけではありません。

HGS サービスの名前を取得するには、Get-HgsServer を実行し、Attestation URL と Key Protection URL のフラット名をメモします。 たとえば、構成証明 URL が "https://hgs.contoso.com/Attestation" の場合、"hgs" が HGS サービス名です。

HGS で使用される Active Directory ドメインは、他の Active Directory ドメインと同様に管理する必要があります。 障害発生後に HGS を復元する場合、現在のドメインに存在する同一のオブジェクトを必ずしも再作成する必要はありません。 ただし、Active Directory をバックアップして、システムを管理することが許可されている JEA ユーザーの一覧と、保護されたホストを承認するために管理者によって信頼された構成証明によって使用されるセキュリティ グループのメンバーシップを保持しておくと、回復が容易になります。

HGS 用に構成された SSL 証明書の拇印を特定するには、PowerShell で次のコマンドを実行します。 その後、証明書プロバイダーの指示に従って、これらの SSL 証明書をバックアップできます。

Get-WebBinding -Protocol https | Select-Object certificateHash

バックアップからの HGS の復元

次の手順では、HGS 設定をバックアップから復元する方法について説明します。 この手順は、既に実行されている HGS インスタンスに対して行われた変更を元に戻す場合と、以前の HGS クラスターが完全に失われた後に新しい HGS クラスターを起動しようとする場合の両方に関するものです。

置換 HGS クラスターを設定する

HGS を復元する前に、構成を復元できる初期化済みの HGS クラスターが必要です。 誤って削除された設定を既存の (実行中の) クラスターにインポートするだけの場合は、この手順を省略できます。 HGS の完全な損失から回復する場合は、展開ガイドのガイダンスに従って、少なくとも 1 つの HGS ノードをインストールして初期化する必要があります。

具体的には、次のようにする必要があります。

  1. HGS ドメインを設定するか、HGS を既存のドメインに参加させます
  2. 既存のキー "または" 一連の一時キーを使用して、HGS サーバーを初期化します。 HGS バックアップ ファイルから実際のキーをインポートした後、一時キーを削除できます。
  3. バックアップから HGS 設定をインポートして、信頼されたホスト グループ、コードの整合性ポリシー、TPM ベースライン、および TPM 識別子を復元します。

ヒント

新しい HGS クラスターでは、バックアップ ファイルのエクスポート元の HGS インスタンスと同じ証明書、サービス名、またはドメインを使用する必要はありません。

バックアップから設定をインポートする

バックアップ ファイルから、構成証明ポリシー、PFX ベースの証明書、および非 PFX 証明書の公開キーを HGS ノードに復元するには、初期化された HGS サーバー ノードで次のコマンドを実行します。 バックアップの作成時に指定したパスワードを入力するように求められます。

Import-HgsServerState -Path C:\Temp\HGSBackup.xml

管理者によって信頼された構成証明ポリシーまたは TPM によって信頼された構成証明ポリシーをインポートするだけの場合は、Import-HgsServerState に -ImportActiveDirectoryModeState または -ImportTpmModeState フラグを指定することによってこれを行うことができます。

Import-HgsServerState を実行する前に、Windows Server 2016 の最新の累積的な更新プログラムがインストールされていることを確認してください。 これを行わないと、インポート エラーが発生する可能性があります。

注意

既存の HGS ノードでポリシーを復元するとき、これらのポリシーのうち 1 つ以上が既にインストールされている場合、インポート コマンドによって、重複するポリシーごとにエラーが表示されます。 これは想定される動作であり、ほとんどの場合、無視しても問題ありません。

証明書の秘密キーを再インストールする

バックアップの作成元である HGS で使用される証明書のいずれかが、拇印を使用して追加された場合、それらの証明書の公開キーのみがバックアップ ファイルに含められます。 つまり、HGS が Hyper-V ホストからの要求を処理できるようにするには、これらの各証明書の秘密キーのインストールとアクセス権の付与を手動で行う必要があります。 この手順を実行するために必要な操作は、証明書が最初に発行された方法によって異なります。 証明機関によって発行されたソフトウェアベースの証明書については、CA に連絡して秘密キーを取得し、それぞれの手順に従って、それぞれの HGS ノードにインストールする必要があります。 同様に、証明書がハードウェアベースのものである場合は、ハードウェア セキュリティ モジュール ベンダーのドキュメントを参照して、HSM に接続するために必要なドライバーを各 HGS ノードにインストールし、各コンピューターに秘密キーへのアクセス権を付与する必要があります。

注意すべき点として、拇印を使用して HGS に追加した証明書では、各ノードに対する秘密キーの手動レプリケーションが必要なことがあります。 復元した HGS クラスターに追加する各ノードについて、この手順を繰り返す必要があります。

インポートされた構成証明ポリシーを確認する

バックアップから設定をインポートした後は、Get-HgsAttestationPolicy を使用して、インポートされたすべてのポリシーを細かく確認し、シールドされた VM を実行することを任せたホストのみが正常に証明できるようにすることをお勧めします。 セキュリティの体制に一致しなくなったポリシーが見つかった場合は、無効化または削除することができます。

診断を実行してシステム状態を確認する

HGS ノードの状態の設定と復元が完了したら、HGS 診断ツールを実行してシステムの状態を確認する必要があります。 これを行うには、構成を復元した HGS ノードで次のコマンドを実行します。

Get-HgsTrace -RunDiagnostics

"Overall Result" が "Pass" でない場合は、システムの構成を完了するために追加の手順が必要になります。 詳細については、サブテストで報告されたメッセージを確認してください。

HGS の修正プログラム適用

最新の累積的な更新プログラムが提供されたら、これをインストールして、ホスト ガーディアン サービス ノードを最新の状態に保つことが重要です。新しい HGS ノードを設定する場合は、HGS の役割をインストールする前、または構成する前に、使用可能な更新プログラムをインストールすることを強くお勧めします。 これにより、新しい機能または変更された機能が直ちに有効になります。

保護されたファブリックに修正プログラムを適用する場合は、まず、HGS をアップグレードする前に "すべての" Hyper-V ホストをアップグレードすることを強くお勧めします。 これは、それらに必要な情報を提供するために Hyper-V ホストが更新された "後" に、HGS の構成証明ポリシーへの変更が加えられるようにするためです。 更新によってポリシーの動作が変更された場合、これらはファブリックの混乱を回避するために、自動的に有効になることはありません。 このような更新を行うには、次のセクションのガイダンスに従って、新規または変更された構成証明ポリシーをアクティブ化する必要があります。 ポリシーの更新が必要かどうかを確認するには、Windows Server と、インストールした累積的な更新プログラムのリリース ノートをお読みになることをお勧めします。

ポリシーのアクティブ化が必要な更新プログラム

HGS の更新プログラムによって構成証明ポリシーの動作が導入されるか大幅に変更される場合は、変更したポリシーをアクティブ化するための追加の手順が必要になります。 ポリシーの変更は、HGS 状態をエクスポートしてインポートした後にのみ実行されます。 新しいポリシーまたは変更されたポリシーは、環境内のすべてのホストとすべての HGS ノードに累積的な更新プログラムを適用した後にのみ、アクティブ化する必要があります。 すべてのコンピューターが更新されたら、任意の HGS ノードで次のコマンドを実行して、アップグレードプロセスを開始します。

$password = Read-Host -AsSecureString -Prompt "Enter a temporary password"
Export-HgsServerState -Path .\temporaryExport.xml -Password $password
Import-HgsServerState -Path .\temporaryExport.xml -Password $password

新しいポリシーが導入されていた場合、既定では無効になります。 新しいポリシーを有効にするには、最初に Microsoft ポリシーの一覧から見つけて ("HGS_" で始まるもの)、次のコマンドを使用して有効にします。

Get-HgsAttestationPolicy

Enable-HgsAttestationPolicy -Name <Hgs_NewPolicyName>

構成証明ポリシーの管理

HGS では、ホストが "健全" と見なされ、シールドされた VM の実行が許可されるために満たす必要がある最小要件セットを定義する、いくつかの構成証明ポリシーが保持されています。 これらのポリシーの一部は Microsoft によって定義され、その他のポリシーは、お客様の環境で許容されるコードの整合性ポリシー、TPM ベースライン、およびホストを定義するためにユーザーによって追加されます。 ユーザーがポリシーを更新して置き換えたときにホストを引き続き正しく証明することができ、信頼されていないホストや構成の証明に成功することを阻止するために、これらのポリシーを定期的に保守する必要があります。

管理者によって信頼された構成証明については、ホストが正常であるかどうかを判断するポリシーは 1 つだけで、既知の信頼されたセキュリティ グループのメンバーシップです。 TPM 構成証明はより複雑であり、システムが正常かどうかを判断する前に、システムのコードと構成を測定するために、さまざまなポリシーが必要です。

1 つの HGS を Active Directory ポリシーと TPM ポリシーの両方で一度に構成することができますが、サービスでは、ホストが証明を試行したときに構成されている現在のモードのポリシーのみがチェックされます。 HGS サーバーのモードを確認するには、Get-HgsServer を実行します。

既定のポリシー

TPM によって信頼された構成証明の場合、HGS にはいくつかの組み込みポリシーが構成されています。 これらのポリシーの一部は "ロック" されています。つまり、セキュリティ上の理由から無効にできないことを意味します。 次の表では、それぞれの既定のポリシーの目的について説明します。

ポリシー名 目的
Hgs_SecureBootEnabled ホストでセキュア ブートが有効になっている必要があります。 これは、スタートアップ バイナリとその他の UEFI ロック設定を測定するために必要です。
Hgs_UefiDebugDisabled ホストでカーネル デバッガーが有効になっていないことを確認します。 ユーザーモードのデバッガーは、コードの整合性ポリシーでブロックされます。
Hgs_SecureBootSettings ホストが少なくとも 1 つの (管理者定義の) TPM ベースラインに一致するようにするためのネガティブ ポリシー。
Hgs_CiPolicy ホストが管理者定義のいずれかの CI ポリシーを使用していることを確認するためのネガティブ ポリシー。
Hgs_HypervisorEnforcedCiPolicy コードの整合性ポリシーがハイパーバイザーによって適用される必要があります。 このポリシーを無効にすると、カーネルモードのコードの整合性ポリシー攻撃からの保護が弱くなります。
Hgs_FullBoot ホストがスリープまたは休止状態から再開されていないことを確認します。 このポリシーに合格するには、ホストを正しく再起動するか、シャットダウンする必要があります。
Hgs_VsmIdkPresent 仮想化ベースのセキュリティがホストで実行されている必要があります。 IDK は、ホストのセキュリティで保護されたメモリ領域に返される情報を暗号化するために必要なキーを表します。
Hgs_PageFileEncryptionEnabled ページファイルがホスト上で暗号化されている必要があります。 このポリシーを無効にすると、暗号化されていないページファイルにテナント シークレットがないか検査された場合に、情報が漏えいする可能性があります。
Hgs_BitLockerEnabled BitLocker が Hyper-V ホストで有効化されている必要があります。 このポリシーは、パフォーマンス上の理由で既定で無効になっているため、有効にしないことをお勧めします。 このポリシーは、シールドされた VM 自体の暗号化に影響しません。
Hgs_IommuEnabled ダイレクト メモリ アクセス攻撃を防ぐためにホストで IOMMU デバイスが使用されている必要があります。 このポリシーを無効にし、IOMMU が有効になっていないホストを使用すると、テナント VM シークレットがダイレクト メモリ攻撃にさらされる可能性があります。
Hgs_NoHibernation 休止状態が Hyper-V ホストで無効化されている必要があります。 このポリシーを無効にすると、ホストで、シールドされた VM メモリを暗号化されていない休止状態ファイルに保存することが許可される可能性があります。
Hgs_NoDumps メモリ ダンプが Hyper-V ホストで無効化されている必要があります。 このポリシーを無効にした場合は、ダンプの暗号化を構成して、シールドされた VM メモリが暗号化されていないクラッシュ ダンプ ファイルに保存されないようにすることをお勧めします。
Hgs_DumpEncryption メモリ ダンプ (Hyper-V ホストで有効化されている場合) が、HGS によって信頼された暗号化キーで暗号化されている必要があります。 このポリシーは、ホストでダンプが有効になっていない場合は適用されません。 このポリシーと Hgs_NoDumps が両方とも無効になっている場合は、シールドされた VM メモリが暗号化されていないダンプ ファイルに保存される可能性があります。
Hgs_DumpEncryptionKey メモリ ダンプを許可するように構成されたホストが、HGS に認識されている管理者定義のダンプ ファイル暗号化キーを使用していることを確認するネガティブ ポリシー。 Hgs_DumpEncryption が無効になっている場合、このポリシーは適用されません。

新しい保護されたホストの承認

新しいホストが保護されたホストになることを承認する (つまり正しく証明する) には、HGS ではホストと、(TPM によって信頼された構成証明を使用するように構成されている場合は) そのホストで実行されているソフトウェアが信頼される必要があります。 新しいホストを承認する手順は、HGS が現在構成されている構成証明モードによって異なります。 保護されたファブリックの構成証明モードを確認するには、任意の HGS ノードで Get-HgsServer を実行します。

ソフトウェアの構成

新しい Hyper-V ホストに、Windows Server 2016 Datacenter Edition がインストールされていることを確認します。 Windows Server 2016 Standard では、保護されたファブリックでシールドされた VM を実行することはできません。 ホストはデスクトップ エクスペリエンスまたは Server Core にインストールすることもできます。

デスクトップ エクスペリエンスと Server Core が搭載されているサーバーでは、Hyper-V および Host Guardian Hyper-V サポートのサーバーの役割をインストールする必要があります。

Install-WindowsFeature Hyper-V, HostGuardian -IncludeManagementTools -Restart

管理者によって信頼された構成証明

管理者によって信頼された構成証明を使用する場合に新しいホストを HGS に登録するには、最初に、ホストを参加させるドメインのセキュリティ グループにホストを追加する必要があります。 通常、各ドメインには、保護されたホスト用の 1 つのセキュリティ グループがあります。 このグループを HGS で既に登録している場合、実行する必要がある操作は、ホストを再起動してグループのメンバーシップを更新することだけです。

次のコマンドを実行して、HGS によって信頼されているセキュリティ グループを確認できます。

Get-HgsAttestationHostGroup

新しいセキュリティ グループを HGS に登録するには、最初にホストのドメイン内のグループのセキュリティ識別子 (SID) を取得し、その SID を HGS に登録します。

Add-HgsAttestationHostGroup -Name "Contoso Guarded Hosts" -Identifier "S-1-5-21-3623811015-3361044348-30300820-1013"

ホスト ドメインと HGS の間の信頼を設定する方法については、展開ガイドを参照してください。

TPM によって信頼された構成証明

HGS が TPM モードで構成されている場合、ホストでは、すべてのロックされたポリシーと、"Hgs_" で始まる "有効" ポリシー、および少なくとも 1 つの TPM ベースライン、TPM 識別子、およびコードの整合性ポリシーを渡す必要があります。 新しいホストを追加するたびに、新しい TPM 識別子を HGS に登録する必要があります。 ホストで環境内の別のホストと同じソフトウェアが実行されていて (および同じコードの整合性ポリシーが適用されている)、同じ TPM ベースラインがある場合は、新しい CI ポリシーまたはベースラインを追加する必要はありません。

新しいホスト用の TPM 識別子の追加 新しいホストで、次のコマンドを実行して TPM 識別子を取得します。 HGS での検索に役立つ一意のホスト名を指定してください。 この情報は、ホストの使用を停止する場合、または HGS のシールドされた VM をホストで実行できないようにする場合に必要になります。

(Get-PlatformIdentifier -Name "Host01").InnerXml | Out-File C:\temp\host01.xml -Encoding UTF8

このファイルを HGS サーバーにコピーし、次のコマンドを実行して、ホストを HGS に登録します。

Add-HgsAttestationTpmHost -Name 'Host01' -Path C:\temp\host01.xml

新しい TPM ベースラインの追加 新しいホストで、環境内の新しいハードウェアまたはファームウェアの構成が実行されている場合は、新しい TPM ベースラインを取得することが必要な場合があります。 これを行うには、ホストで次のコマンドを実行します。

Get-HgsAttestationBaselinePolicy -Path 'C:\temp\hardwareConfig01.tcglog'

注意

ホストが検証に失敗し、証明できないというエラーが表示されても、心配しないでください。 これは、ホストがシールドされた VM を実行できることを確認するための前提条件のチェックで、おそらくコードの整合性ポリシーやその他の必要な設定をまだ適用していないことを意味しています。 エラー メッセージを読み、提案された変更を加えてから、再試行してください。 または、コマンドに -SkipValidation フラグを追加して、この時点で検証をスキップすることもできます。

TPM ベースラインを HGS サーバーにコピーし、次のコマンドを使用して登録します。 このクラスの Hyper-V ホストのハードウェアとファームウェアの構成を理解するのに役立つ名前付け規則を使用することをお勧めします。

Add-HgsAttestationTpmPolicy -Name 'HardwareConfig01' -Path 'C:\temp\hardwareConfig01.tcglog'

新しいコードの整合性ポリシーの追加 Hyper-V ホストで実行されているコードの整合性ポリシーを変更した場合は、そのホストで正常に証明できるように、新しいポリシーを HGS に登録する必要があります。 環境内の信頼された Hyper-V コンピューターのマスター イメージとして機能する参照ホストで、New-CIPolicy コマンドを使用して新しい CI ポリシーを取得します。 Hyper-V ホストの CI ポリシーには、Filepublisher レベルと Hash フォールバックを使用することをお勧めします。 最初に CI ポリシーを監査モードで作成し、すべてが正常に動作していることを確認する必要があります。 システムでサンプル ワークロードを検証した後、ポリシーを適用し、適用されたバージョンを HGS にコピーすることができます。 コードの整合性ポリシーの構成オプションの完全な一覧については、Device Guard のドキュメントを参照してください。

# Capture a new CI policy with the FilePublisher primary level and Hash fallback and enable user mode code integrity protections
New-CIPolicy -FilePath 'C:\temp\ws2016-hardware01-ci.xml' -Level FilePublisher -Fallback Hash -UserPEs

# Apply the CI policy to the system
ConvertFrom-CIPolicy -XmlFilePath 'C:\temp\ws2016-hardware01-ci.xml' -BinaryFilePath 'C:\temp\ws2016-hardware01-ci.p7b'
Copy-Item 'C:\temp\ws2016-hardware01-ci.p7b' 'C:\Windows\System32\CodeIntegrity\SIPolicy.p7b'
Restart-Computer

# Check the event log for any untrusted binaries and update the policy if necessary
# Consult the Device Guard documentation for more details

# Change the policy to be in enforced mode
Set-RuleOption -FilePath 'C:\temp\ws2016-hardare01-ci.xml' -Option 3 -Delete

# Apply the enforced CI policy on the system
ConvertFrom-CIPolicy -XmlFilePath 'C:\temp\ws2016-hardware01-ci.xml' -BinaryFilePath 'C:\temp\ws2016-hardware01-ci.p7b'
Copy-Item 'C:\temp\ws2016-hardware01-ci.p7b' 'C:\Windows\System32\CodeIntegrity\SIPolicy.p7b'
Restart-Computer

ポリシーを作成し、テストして、適用したら、バイナリファイル (.p7b) を HGS サーバーにコピーし、ポリシーを登録します。

Add-HgsAttestationCiPolicy -Name 'WS2016-Hardware01' -Path 'C:\temp\ws2016-hardware01-ci.p7b'

メモリ ダンプ暗号化キーの追加

Hgs_NoDumps ポリシーが無効になっていて Hgs_DumpEncryption ポリシーが有効になっている場合、保護されたホストでは、メモリ ダンプ (クラッシュ ダンプを含む) が暗号化されている限り、これらのダンプを有効にすることができます。 保護されたホストでは、メモリ ダンプが無効になっているか、または HGS に認識されているキーでそれらが暗号化されている場合にのみ、構成証明が渡されます。 既定では、HGS にはダンプ暗号化キーが構成されていません。

ダンプ暗号化キーを HGS に追加するには、Add-HgsAttestationDumpPolicy コマンドレットを使用して、HGS にダンプ暗号化キーのハッシュを提供します。 ダンプ暗号化で構成された Hyper-V ホスト上で TPM ベースラインを取得する場合、ハッシュを tcglog に含めて、Add-HgsAttestationDumpPolicy コマンドレットに提供できます。

Add-HgsAttestationDumpPolicy -Name 'DumpEncryptionKey01' -Path 'C:\temp\TpmBaselineWithDumpEncryptionKey.tcglog'

または、ハッシュの文字列形式をコマンドレットに直接渡すこともできます。

Add-HgsAttestationDumpPolicy -Name 'DumpEncryptionKey02' -PublicKeyHash '<paste your hash here>'

保護されたファブリック全体で異なる複数のキーを使用する場合は、必ず一意のダンプ暗号化キーをそれぞれ HGS に追加してください。 HGS で認識されていないキーを使用してメモリ ダンプを暗号化するホストは、構成証明に合格しません。

ホストでのダンプ暗号化の構成の詳細については、Hyper-V のドキュメントを参照してください。

システムが構成証明に合格したかどうかを確認する

必要な情報を HGS に登録した後、ホストが構成証明に合格したかどうかを確認する必要があります。 新しく追加された Hyper-V ホストで、Set-HgsClientConfiguration を実行し、HGS クラスターの正しい URL を指定します。 これらの URL は、任意の HGS ノードで Get-HgsServer を実行することで取得できます。

Set-HgsClientConfiguration -KeyProtectionServerUrl 'https://hgs.bastion.local/KeyProtection' -AttestationServerUrl 'https://hgs.bastion.local/Attestation'

結果の状態に "IsHostGuarded : True" の表示がない場合は、構成のトラブルシューティングを行う必要があります。 構成証明に失敗したホストで次のコマンドを実行して、失敗した構成証明の解決に役立つ可能性のある問題に関する詳細なレポートを取得します。

Get-HgsTrace -RunDiagnostics -Detailed

重要

Windows Server 2019 または Windows 10 バージョン 1809 を使用していて、コード整合性ポリシーを使用している場合、Get-HgsTrace によって、コードの整合性ポリシーのアクティブ診断でエラーが返されることがあります。 これが唯一の失敗した診断である場合、この結果を無視しても問題ありません。

構成証明ポリシーを確認する

HGS で構成されているポリシーの現在の状態を確認するには、任意の HGS ノードで次のコマンドを実行します。

# List all trusted security groups for admin-trusted attestation
Get-HgsAttestationHostGroup

# List all policies configured for TPM-trusted attestation
Get-HgsAttestationPolicy

セキュリティ要件を満たしていないポリシー (たとえば、今では安全でないと見なされる古いコードの整合性ポリシー) が有効になっている場合、次のコマンドでポリシーの名前を置き換えて、これを無効にすることができます。

Disable-HgsAttestationPolicy -Name 'PolicyName'

同様に、Enable-HgsAttestationPolicy を使用してポリシーを再度有効にすることもできます。

ポリシーが不要になったため、すべての HGS ノードから削除する場合は、Remove-HgsAttestationPolicy -Name 'PolicyName' を実行してポリシーを完全に削除します。

構成証明モードの変更

管理者によって信頼された構成証明を使用して、保護されたファブリックを開始した場合、環境内に十分な数の TPM 2.0 互換ホストが備わったら、すぐにより強力な TPM 構成証明モードにアップグレードしたい場合もあります。 切り替える準備ができたら、管理者によって信頼された構成証明で HGS を実行し続ける一方で、すべての構成証明成果物 (CI ポリシー、TPM ベースライン、TPM 識別子) を HGS に事前に読み込むことができます。 これを行うには、「新しい保護されたホストの承認」のセクションの手順に従 ってください。

すべてのポリシーを HGS に追加したら、次の手順では、代理構成証明試行をホストで実行して、TPM モードで構成証明が合格するか確認します。 これは、HGS の現在の動作状態に影響を及ぼしません。 以下のコマンドは、環境内のすべてのホストと少なくとも 1 つの HGS ノードにアクセスできるコンピューターで実行する必要があります。 ファイアウォールまたは他のセキュリティ ポリシーによってこれが妨げられる場合は、この手順をスキップできます。 可能であれば、代理構成証明を実行して、TPM モードへの "切り替え" によって VM のダウンタイムが発生するかどうかを示す良い判断材料を得ることをお勧めします。

# Get information for each host in your environment
$hostNames = 'host01.contoso.com', 'host02.contoso.com', 'host03.contoso.com'
$credential = Get-Credential -Message 'Enter a credential with admin privileges on each host'
$targets = @()
$hostNames | ForEach-Object { $targets += New-HgsTraceTarget -Credential $credential -Role GuardedHost -HostName $_ }

$hgsCredential = Get-Credential -Message 'Enter an admin credential for HGS'
$targets += New-HgsTraceTarget -Credential $hgsCredential -Role HostGuardianService -HostName 'HGS01.bastion.local'

# Initiate the synthetic attestation attempt
Get-HgsTrace -RunDiagnostics -Target $targets -Diagnostic GuardedFabricTpmMode

診断が完了したら、出力された情報を確認して、TPM モードで構成証明に失敗したホストが存在するかどうかを確認します。 各ホストから "合格" が取得されるまで診断を再び実行し、その後 HGS を TPM モードに変更します。

TPM モードへの変更は、わずか 1 秒で完了します。 構成証明モードを更新するには、HGS ノードで次のコマンドを実行します。

Set-HgsServer -TrustTpm

問題が発生し、Active Directory モードに戻す必要がある場合は、Set-HgsServer -TrustActiveDirectory を実行してこれを行うことができます。

すべてが期待した通り動作しているのを確認したら、信頼できるすべての Active Directory ホスト グループを HGS から削除し、HGS ドメインとファブリック ドメイン間の信頼を削除する必要があります。 Active Directory の信頼を設定したままにすると、誰かが信頼を再び有効にし、HGS を Active Directory モードに切り替える危険性があります。この場合、保護されたホストで、信頼されていないコードが未チェックのまま実行されることが許可される可能性があります。

キーの管理

保護されたファブリック ソリューションでは、いくつかの公開キーと秘密キーのペアを使用して、ソリューション内のさまざまなコンポーネントの整合性を検証し、テナント シークレットを暗号化します。 ホスト ガーディアン サービスは、少なくとも 2 つの証明書 (公開キーと秘密キーを使用) で構成されます。この証明書は、シールドされた VM の起動に使用されるキーの署名と暗号化に使用されます。 これらのキーは、注意して管理する必要があります。 攻撃者によって秘密キーが取得された場合、攻撃者はファブリックで実行されている VM の防御を解除したり、配備した保護をバイパスするために脆弱な構成証明ポリシーを使用する、なりすまし HGS クラスターを設定したりすることができます。 障害時に秘密キーを紛失し、バックアップ中に見つからない場合は、新しいキーのペアを設定し、新しい証明書を承認するために各 VM にキーを再設定する必要があります。

このセクションでは、キーが機能し、セキュリティで保護されるようにキーを構成するのに役立つ、一般的なキー管理のトピックについて説明します。

新しいキーの追加

HGS は 1 セットのキーで初期化する必要がありますが、HGS に複数の暗号化キーと署名キーを追加できます。 HGS に新しいキーを追加する最も一般的な 2 つの理由は次のとおりです。

  1. テナントがハードウェア セキュリティ モジュールに自社の秘密キーをコピーし、自社のキーのみが、自社のシールドされた VM を起動することを承認する、"Bring Your Own Key" のシナリオをサポートする場合。
  2. HGS の既存のキーを置き換えるとき、最初に新しいキーを追加し、新しいキーを使用するように各 VM 構成が更新されるまで両方のキー セットを保持する場合。

新しいキーを追加するプロセスは、使用している証明書の種類によって異なります。

オプション 1: HSM に格納されている証明書の追加

HGS キーをセキュリティで保護するための推奨される方法は、ハードウェア セキュリティ モジュール (HSM) で作成された証明書を使用する方法です。 HSM により、ユーザーによるキーの使用が、データセンター内のセキュリティ保護されたデバイスへの物理的なアクセスに、確実に関連付けられます。 HSM はそれぞれ異なっており、証明書を作成して HGS に登録するための独自のプロセスを持っています。 以下の手順は、HSM ベースの証明書の使用に関する大まかなガイダンスを提供するためのものです。 正確な手順と機能については、HSM ベンダーのドキュメントを参照してください。

  1. クラスター内の各 HGS ノードに HSM ソフトウェアをインストールします。 ネットワークとローカルの HSM デバイスの違いによって、HSM を構成して、コンピューターにキー ストアへのアクセスを許可することが必要な場合があります。

  2. 暗号化と署名のために 2048 ビット RSA キーを使用して HSM に 2 つの証明書を作成します

    1. HSM でデータの暗号化のキー使用法 プロパティを使用して、暗号化証明書を作成します
    2. HSM でデジタル署名のキー使用法 プロパティを使用して、署名証明書を作成します

  3. HSM ベンダーのガイダンスに従って、各 HGS ノードのローカル証明書ストアに証明書をインストールします。

  4. HSM で詳細なアクセス許可を使用して、特定のアプリケーションまたはユーザーに秘密キーを使用するアクセス許可を付与する場合は、HGS のグループ マネージド サービス アカウントに証明書へのアクセス権を付与する必要があります。 HGS の gMSA アカウントの名前は、(Get-IISAppPool -Name KeyProtection).ProcessModel.UserName を実行して確認できます

  5. 次のコマンドで、拇印をご使用の証明書の拇印に置き換えて、署名証明書と暗号化証明書を HGS に追加します。

    Add-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint "AABBCCDDEEFF00112233445566778899"
Add-HgsKeyProtectionCertificate -CertificateType Signing -Thumbprint "99887766554433221100FFEEDDCCBBAA"

オプション 2: エクスポートできないソフトウェア証明書の追加

エクスポートできない秘密キーを持つ、自社または公的な証明機関によって発行されたソフトウェアベースの証明書がある場合は、その拇印を使用して HGS に証明書を追加する必要があります。

  1. 証明機関の指示に従って、コンピューターに証明書をインストールします。

  2. HGS のグループ マネージド サービス アカウントに、証明書の秘密キーへの読み取りアクセス権を付与します。 HGS の gMSA アカウントの名前は、(Get-IISAppPool -Name KeyProtection).ProcessModel.UserName を実行して確認できます

  3. 次のコマンドを使用して、証明書の拇印を置き換えて、証明書を HGS に登録します (署名証明書の場合は Encryption を Signing に変更します)。

    Add-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint "AABBCCDDEEFF00112233445566778899"

重要

各 HGS ノードで、秘密キーを手動でインストールし、gMSA アカウントへの読み取りアクセス権を付与する必要があります。 HGS では、拇印によって登録された "すべての" 証明書の秘密キーを自動的にレプリケートすることはできません。

オプション 3: PFX ファイルに格納されている証明書の追加

PFX ファイル形式で保存してパスワードで保護できる、エクスポート可能な秘密キーを使用するソフトウェアベースの証明書がある場合、HGS では証明書を自動的に管理できます。 PFX ファイルで追加された証明書は、HGS クラスターのすべてのノードに自動的にレプリケートされ、HGS では秘密キーへのアクセスがセキュリティで保護されます。 PFX ファイルを使用して新しい証明書を追加するには、HGS ノードで次のコマンドを実行します (署名証明書の場合は Encryption を Signing に変更します)。

$certPassword = Read-Host -AsSecureString -Prompt "Provide the PFX file password"
Add-HgsKeyProtectionCertificate -CertificateType Encryption -CertificatePath "C:\temp\encryptionCert.pfx" -CertificatePassword $certPassword

プライマリ証明書の識別と変更 HGS では複数の署名証明書と暗号化証明書をサポートできますが、1 つのペアが "プライマリ" 証明書として使用されます。 誰かが HGS クラスターのガーディアン メタデータをダウンロードした場合、これらの証明書が使用されます。 現在プライマリ証明書としてマークされている証明書を確認するには、次のコマンドを実行します。

Get-HgsKeyProtectionCertificate -IsPrimary $true

新しいプライマリの暗号化証明書または署名証明書を設定するには、次のコマンドを使用して、目的の証明書の拇印を見つけ、これをプライマリとしてマークします。

Get-HgsKeyProtectionCertificate
Set-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint "AABBCCDDEEFF00112233445566778899" -IsPrimary
Set-HgsKeyProtectionCertificate -CertificateType Signing -Thumbprint "99887766554433221100FFEEDDCCBBAA" -IsPrimary

キーの更新または交換

HGS で使用される証明書を作成すると、証明機関のポリシーとユーザーの要求情報に従って、証明書に有効期限が割り当てられます。 通常、HTTP 通信のセキュリティ保護など、証明書の有効性が重要なシナリオでは、サービスの中断や面倒なエラー メッセージを回避するために、有効期限が切れる前に証明書を更新する必要があります。 HGS では、その意味で証明書は使用されません。 HGS は、非対称キー ペアを作成して格納するための便利な方法として証明書を使用しています。 HGS での暗号化証明書または署名証明書の有効期限が切れることは、シールドされた VM の保護が脆弱になったり失われたりすることを意味しません。 さらに、証明書失効チェックは HGS では実行されません。 HGS 証明書または発行機関の証明書が失効した場合、HGS による証明書の使用に影響はありません。

HGS 証明書について心配する必要があるのは、その秘密キーが盗まれたと思う理由がある場合のみです。 その場合、シールドされた VM の整合性が危険にさらされます。これは、VM のシールド保護を解除したり、脆弱な構成証明ポリシーを持つ偽の HGS サーバーを立ち上げたりするには、HGS の暗号化キーと署名キーのペアの秘密キーの部分を所有するだけで十分であるからです。

このような状況であることに気付いた場合、またはコンプライアンス標準によって証明書キーを定期的に更新することが必要な場合に、HGS サーバー上のキーを変更するプロセスの概要を、次の手順で示します。 次のガイダンスは、HGS クラスターによって提供される各 VM に対するサービスの中断を引き起こす結果となる重大な作業を示していることに注意してください。 サービスの中断を最小限に抑え、テナント VM のセキュリティを確保するには、HGS キーを変更するための適切な計画が必要です。

HGS ノードで、次の手順を実行して、新しい暗号化証明書と署名証明書のペアを登録します。 HGS に新しいキーを追加するさまざまな方法の詳細については、「新しいキーの追加」のセクションを参照してください。

  1. HGS サーバーの暗号化証明書と署名証明書の新しいペアを作成します。 これらは、ハードウェア セキュリティ モジュールで作成されるのが理想的です。

  2. 新しい暗号化証明書と署名証明書を Add-HgsKeyProtectionCertificate に登録します。

    Add-HgsKeyProtectionCertificate -CertificateType Signing -Thumbprint <Thumbprint>
Add-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint <Thumbprint>

  3. 拇印を使用した場合は、クラスター内の各ノードに移動して、秘密キーをインストールし、HGS gMSA にキーへのアクセス権を付与する必要があります。

  4. 新しい証明書を HGS の既定の証明書にします。

    Set-HgsKeyProtectionCertificate -CertificateType Signing -Thumbprint <Thumbprint> -IsPrimary
Set-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint <Thumbprint> -IsPrimary

この時点で、HGS ノードから取得したメタデータを使用して作成されたシールド データでは新しい証明書が使用されますが、古い証明書がまだ存在するために、既存の VM は引き続き動作します。

既存のすべての VM が新しいキーで動作するようには、各 VM でキーの保護機能を更新する必要があります。

これは、VM 所有者 ("所有者" ガーディアンを所有する人物またはエンティティ) が関与する必要があるアクションです。 シールドされた VM ごとに、次の手順を実行します。

  1. VM をシャット ダウンします。 残りの手順が完了するまで VM を再度オンにすることはできません。そうしないと、プロセスを最初からやり直す必要があります。

  2. 現在のキーの保護機能をファイルに保存します。 Get-VMKeyProtector -VMName 'VM001' | Out-File '.\VM001.kp'

  3. KP を VM 所有者に譲渡します

  4. 所有者は、更新されたガーディアン情報を HGS からダウンロードし、ローカル システムにインポートします

  5. 次のコマンドを実行して、現在の KP をメモリに読み込み、新しいガーディアンに KP へのアクセス権を付与し、新しいファイルに保存します。

    $kpraw = Get-Content -Path .\VM001.kp
$kp = ConvertTo-HgsKeyProtector -Bytes $kpraw
$newGuardian = Get-HgsGuardian -Name 'UpdatedHgsGuardian'
$updatedKP = Grant-HgsKeyProtectorAccess -KeyProtector $kp -Guardian $newGuardian
$updatedKP.RawData | Out-File .\updatedVM001.kp

  6. 更新された KP を、元のホスト側のファブリックにコピーします。

  7. 元の VM に KP を適用します。

    $updatedKP = Get-Content -Path .\updatedVM001.kp
Set-VMKeyProtector -VMName VM001 -KeyProtector $updatedKP

  8. 最後に、VM を起動し、正常に実行されたことを確認します。

    注意

    VM 所有者が、正しくないキーの保護機能を VM に設定し、VM を実行することをファブリックで承認しない場合、シールドされた VM を起動できません。 前回の既知の正常なキーの保護機能に戻すには、Set-VMKeyProtector -RestoreLastKnownGoodKeyProtector を実行します。

    新しいガーディアン キーを承認するようすべての VM が更新された後は、古いキーを無効にして削除できます。

  9. 古い証明書の拇印を Get-HgsKeyProtectionCertificate -IsPrimary $false から取得します

  10. 次のコマンドを実行して、各証明書を無効にします。

    Set-HgsKeyProtectionCertificate -CertificateType Signing -Thumbprint <Thumbprint> -IsEnabled $false
Set-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint <Thumbprint> -IsEnabled $false

  11. 証明書を無効にして VM が引き続き開始できることを確認した後、次のコマンドを実行して、HGS から証明書を削除します。

    Remove-HgsKeyProtectionCertificate -CertificateType Signing -Thumbprint <Thumbprint>`
Remove-HgsKeyProtectionCertificate -CertificateType Encryption -Thumbprint <Thumbprint>`

重要

VM のバックアップには、古い証明書を使用して VM を起動できるようにする古いキーの保護機能情報が含まれています。 秘密キーが侵害されたことがわかっている場合は、VM のバックアップも侵害された可能性があると推定すべきで、適切な操作を行う必要があります。 VM 構成をバックアップ (.vmcx) から破棄すると、キーの保護機能が削除されますが、次回 VM を起動するには BitLocker 回復パスワードを使用することが必要になります。

ノード間のキー レプリケーション

HGS クラスター内のすべてのノードは、同じ暗号化証明書、署名証明書、および (構成されている場合は) SSL 証明書で構成されている必要があります。 これは、クラスター内の任意のノードに連絡する Hyper-V ホストの要求が、正常に処理されるようにするために必要です。

PFX ベースの証明書を使用して HGS サーバーを初期化した場合、HGS ではクラスター内のすべてのノード間で、これらの証明書の公開キーと秘密キーの両方が自動的にレプリケートされます。 キーは 1 つのノードにのみ追加する必要があります。

証明書の参照または拇印を使用して HGS サーバーを初期化した場合、HGS では証明書の "公開" キーのみが各ノードにレプリケートされます。 さらに HGS は、このシナリオのどのノードでも秘密キーへのアクセスを自身に付与することができません。 そのため、次のことを行う必要があります。

  1. 各 HGS ノードに秘密キーをインストールします
  2. HGS のグループ マネージド サービス アカウント (gMSA) に、各ノードの秘密キーへのアクセス権を付与します。これらのタスクにより運用の負荷が増えますが、エクスポートできない秘密キーを持つ HSM ベースのキーと証明書には必要です。

SSL 証明書はどのような形式でもレプリケートされません。 同じ SSL 証明書を使用して各 HGS サーバーを初期化し、SSL 証明書を更新または置換することを選択するたびに各サーバーを更新する必要があります。 SSL 証明書を置き換えるときは、Set-HgsServer コマンドレットを使用することをお勧めします。

HGS の構成解除

HGS サーバーの使用を停止したり、大幅に再構成したりする必要がある場合は、Clear-HgsServer または Uninstall-HgsServer コマンドレットを使用して実行できます。

HGS 構成のクリア

HGS クラスターからノードを削除するには、Clear-HgsServer コマンドレットを使用します。 このコマンドレットは、実行されるサーバーで次の変更を行います。

  • 構成証明とキー保護サービスの登録を解除します
  • "microsoft.windows.hgs" JEA 管理エンドポイントを削除します
  • ローカル コンピューターを HGS フェールオーバー クラスターから削除します

サーバーがクラスター内の最後の HGS ノードである場合は、クラスターとそれに対応する分散ネットワーク名リソースも破棄されます。

# Removes the local computer from the HGS cluster
Clear-HgsServer

クリア操作が完了したら、Initialize-HgsServer を使用して HGS サーバーを再初期化できます。 Install-HgsServer を使用して Active Directory Domain Services ドメインを設定した場合、そのドメインは、消去操作後も構成され、操作可能な状態のままになります。

HGS のアンインストール

HGS クラスターからノードを削除し、かつそのノードで実行されている Active Directory ドメイン コントローラーを降格する場合は、Uninstall-HgsServer コマンドレットを使用します。 このコマンドレットは、実行されるサーバーで次の変更を行います。

  • 構成証明とキー保護サービスの登録を解除します
  • "microsoft.windows.hgs" JEA 管理エンドポイントを削除します
  • ローカル コンピューターを HGS フェールオーバー クラスターから削除します
  • Active Directory ドメイン コントローラーを降格します (構成されている場合)

サーバーがクラスター内の最後の HGS ノードである場合は、ドメイン、フェールオーバー クラスター、およびクラスターの分散ネットワーク名リソースも破棄されます。

# Removes the local computer from the HGS cluster and demotes the ADDC (restart required)
$newLocalAdminPassword = Read-Host -AsSecureString -Prompt "Enter a new password for the local administrator account"
Uninstall-HgsServer -LocalAdministratorPassword $newLocalAdminPassword -Restart

アンインストール操作が完了し、コンピューターが再起動されたら、Install-HgsServer を使用して ADDC と HGS を再インストールするか、コンピューターをドメインに参加させて、Initialize-HgsServer を使用してそのドメインの HGS サーバーを初期化します。

コンピューターを HGS ノードとして使用する予定がなくなった場合は、Windows から役割を削除できます。

Uninstall-WindowsFeature HostGuardianServiceRole