テナントのシールドされた VM - シールドされた VM を定義するためのシールド データの作成

シールド データ ファイル (別名プロビジョニング データ ファイルまたは PDK ファイル) は、管理者のパスワード、RDP やその他の ID 関連証明書、ドメイン参加の資格情報など、重要な VM 構成情報を保護するために、テナントまたは VM 所有者が作成する暗号化されたファイルです。 このトピックでは、シールド データ ファイルを作成する方法について説明します。 このファイルを作成する前に、ホスティング サービス プロバイダーからテンプレート ディスクを取得するか、「テナント用のシールドされた VM: テンプレート ディスクの作成 (省略可能)」の記述に従ってテンプレート ディスクを作成する必要があります。

シールド データ ファイルの内容の一覧および図については、「シールド データの内容とその必要性」を参照してください。

重要

このセクションの手順は、保護されたファブリックの外部にある別の信頼されたマシンで完了する必要があります。 通常は、ファブリック管理者ではなく VM オーナー (テナント) が、VM のシールド データを作成します。

シールド データ ファイルの作成準備として、次の手順を実行します。

以上が済んだら、シールド データ ファイルを作成できます。

(オプション) リモート デスクトップ接続用の証明書を取得する

テナントがシールドされた VM に接続するためにはリモート デスクトップ接続またはその他のリモート管理ツールを使用する必要があるため、テナントが適切なエンドポイントに接続している (つまり、接続を遮る中間者が存在しない) ことを確認できることが重要です。

意図したサーバーに接続していることを確認する方法の 1 つとしては、提示するリモート デスクトップ サービス用の証明書を、接続を開始する時点でインストールし、構成するというやり方が挙げられます。 サーバーに接続するクライアント マシンにより、証明書を信頼できるかどうかが確認され、信頼できない場合には警告が表示されます。 一般に、RDP 証明書がテナントの PKI から発行されていれば、接続するクライアントが証明書を信頼します。 リモート デスクトップ サービスでの証明書の使用の詳細については、TechNet を参照してください。

カスタム RDP 証明書を取得する必要があるかどうかを判断する場合には、次の点を考慮してください。

  • シールドされた VM をラボ環境でテストするだけであれば、カスタム RDP 証明書は必要ありません。
  • VM が Active Directory ドメインに参加する構成になっている場合には通常、組織の証明機関によって自動的にコンピューター証明書が発行され、RDP 接続に際してその証明書がコンピューターの識別に使用されます。 カスタム RDP 証明書は必要ありません。
  • VM がドメインに参加していないものの、リモート デスクトップを使用しているときに正しいマシンに接続していることを確認する方法が必要な場合には、カスタム RDP 証明書の使用を検討する必要があります。

ヒント

シールド データ ファイルに含める RDP 証明書を選択する場合は、必ずワイルドカード証明書を使用してください。 1 つのシールド データ ファイルで作成できる VM の数には上限がありません。 各 VM が同じ証明書を共有するので、ワイルドカード証明書を使用することにより、VM のホスト名に関係なく証明書が有効な状態を確保できます。

応答ファイルを作成する

VMM の署名済みテンプレート ディスクは一般化されているため、テナントは、プロビジョニング プロセスの際にシールドされた VM を特殊化するための応答ファイルを提供する必要があります。 応答ファイル (無人セットアップ ファイルとよく呼ばれます) では、目的のロールに合わせて VM を構成できます。つまり、Windows 機能をインストールし、前の手順で作成した RDP 証明書を登録したうえで、その他のカスタム動作を実行できます。 また、既定の管理者のパスワードやプロダクト キーなど、Windows のセットアップに必要な情報も提供されます。

シールドされた VM を作成するための応答ファイル (Unattend.xml ファイル) を生成するための New-ShieldingDataAnswerFile 関数の取得と使用の詳細については、New-ShieldingDataAnswerFile 関数を使用した応答ファイルの生成に関するページを参照してください。 この関数を使用すると、次のような選択肢に応じた応答ファイルをより簡単に生成できます。

  • 初期化プロセスの最後に VM をドメインに参加させることを意図しているか?
  • ボリューム ライセンスを使用するか、それとも VM ごとに特定のプロダクト キーを使用するか?
  • DHCP を使用しているか、それとも静的 IP を使用しているか?
  • VM が組織に属していることを証明するために使用されるカスタム リモート デスクトップ プロトコル (RDP) 証明書を使用するか?
  • 初期化の最後にスクリプトを実行する必要があるか?

シールド データ ファイルで使用される応答ファイルは、そのシールド データ ファイルを使用して作成されたすべての VM で使用されます。 そのため、VM 固有の情報を応答ファイルにハード コーディングしないようにする必要があります。 VMM では、VM によって異なる可能性のある特殊化値を処理するために、無人セットアップ ファイル内で一部の置換文字列 (下の表を参照) がサポートされています。 これらの使用は必須ではありませんが、これらが存在する場合、VMM により利用されます。

シールドされた VM 用の unattend.xml ファイルを作成する場合は、次の制約に注意してください。

  • データセンターの管理に VMM を使用している場合、無人セットアップ ファイルで、VM の構成が完了した後に VM がオフになるようにする必要があります。 これにより、VM のプロビジョニングが完了し、VM が使用できる状態になったことを VMM からテナントにレポートするタイミングを VMM に認識させることができます。 VMM は、プロビジョニング中に VM がオフになったことを検出すると、自動で VM の電源をオンに戻します。

  • 構成が終わった VM にアクセスできるように、RDP と対応するファイアウォール規則を必ず有効にしてください。 VMM コンソールを使ってもシールドされた VM にアクセスすることはできないため、VM に接続するには RDP が必要です。 Windows PowerShell のリモート処理を使用してシステムを管理する場合は、WinRM も有効にしてください。

  • シールドされた VM の無人セットアップ ファイルでサポートされている置換文字列は次のとおりです。

    置き換え可能な要素 置換文字列
    [ComputerName] @ComputerName@
    TimeZone @TimeZone@
    ProductKey @ProductKey@
    IPAddr4-1 @IP4Addr-1@
    IPAddr6-1 @IP6Addr-1@
    MACAddr-1 @MACAddr-1@
    Prefix-1-1 @Prefix-1-1@
    NextHop-1-1 @NextHop-1-1@
    Prefix-1-2 @Prefix-1-2@
    NextHop-1-2 @NextHop-1-2@

    複数の NIC がある場合は、1 桁目の値を増やしていくことにより、IP 構成の複数の置換文字列を追加できます。 たとえば、2 つの NIC の IPv4 アドレス、サブネット、ゲートウェイを設定するには、次のような置換文字列を使用します。

    置換文字列 置換の例
    @IP4Addr-1@ 192.168.1.10/24
    @MACAddr-1@ イーサネット
    @Prefix-1-1@ 24
    @NextHop-1-1@ 192.168.1.254
    @IP4Addr-2@ 10.0.20.30/24
    @MACAddr-2@ イーサネット 2
    @Prefix-2-1@ 24
    @NextHop-2-1@ 10.0.20.1

置換文字列を使用する場合は、VM のプロビジョニング プロセスの間に文字列が挿入されるようにすることが重要です。 展開時に @ProductKey@ などの文字列が提供されず、無人セットアップ ファイルの <ProductKey> ノードが空白になっていると、特殊化のプロセスに失敗し、VM に接続できなくなります。

また、テーブルの末尾近くにあるネットワーク関連の置換文字列は、VMM 静的 IP アドレス プールを利用している場合にのみ使用されることに注意してください。 これらの置換文字列が必要であるかどうかは、ホスティング サービス プロバイダーから通知を受けることができます。 VMM テンプレートでの静的 IP アドレスの詳細については、VMM のドキュメントの次の情報を参照してください。

最後に、シールドされた VM の展開プロセスでは、OS ドライブのみが暗号化されることに注意する必要があります。 1 つまたは複数のデータ ドライブを含むシールドされた VM をデプロイする場合は、データ ドライブを自動的に暗号化する無人コマンドまたはグループ ポリシー設定をテナント ドメインに追加することを強くお勧めします。

ボリューム署名カタログ ファイルを取得する

シールド データ ファイルには、テナントが信頼しているテンプレート ディスクに関する情報も含まれています。 テナントは、ボリューム署名カタログ (VSC) ファイルの形式で、信頼されたテンプレート ディスクからディスク署名を取得します。 これらの署名は、新しい VM の展開時に検証されます。 シールド データ ファイル内のどの署名も VM と共に展開しようとしているテンプレート ディスクにマッチしない場合 (つまり、変更されたか、悪意のある可能性のある別のディスクと交換された場合)、プロビジョニング プロセスは失敗します。

重要

ディスクが改ざんされていないことは VSC によって保証されますが、それでも最初にテナントがそのディスクを信頼することは重要です。 自分がテナントであり、テンプレート ディスクがホストから提供される場合は、そのテンプレート ディスクを使用したテスト VM をデプロイしたうえで、独自のツール (ウイルス対策、脆弱性スキャナーなど) を実行し、ディスクが実際に信頼できる状態であることを検証してください。

テンプレート ディスクの VSC を取得するには、次の 2 つの方法があります。

  1. ホスト (または、テナントが VMM にアクセスできる場合には、テナント) が、VMM PowerShell コマンドレットを使用して VSC を保存し、テナントに渡します。 これは、VMM コンソールがインストールされ、ホスティング ファブリックの VMM 環境を管理するように構成されているマシンであれば、どのマシンでも実行できます。 VSC を保存するための PowerShell コマンドレットは次のとおりです。

    $disk = Get-SCVirtualHardDisk -Name "templateDisk.vhdx"

$vsc = Get-SCVolumeSignatureCatalog -VirtualHardDisk $disk

$vsc.WriteToFile(".\templateDisk.vsc")

  2. テナントは、テンプレート ディスク ファイルにアクセスできます。 これは、ホスティング サービス プロバイダーにアップロードされるテンプレート ディスクをテナントが作成する場合、またはテナントがホストのテンプレート ディスクをダウンロードできる場合に該当する可能性があります。 この場合、関連する VMM がないときは、テナントが次のコマンドレットを実行します (リモートサーバー管理ツールの一部として、シールドされた VM ツール機能と共にインストールされています)。

    Save-VolumeSignatureCatalog -TemplateDiskPath templateDisk.vhdx -VolumeSignatureCatalogPath templateDisk.vsc

信頼されたファブリックを選択する

シールド データ ファイルの最後のコンポーネントは、VM のオーナーとガーディアンに関連するものです。 ガーディアンは、シールドされた VM のオーナーと、そのオーナーが実行を認可されている保護されたファブリックの両方を指定するために使用されます。

ホスティング ファブリックに対してシールドされた VM の実行を認可するには、ホスティング サービス プロバイダーのホスト ガーディアン サービスからガーディアン メタデータを取得する必要があります。 多くの場合、ホスティング サービス プロバイダーは、管理ツールを通じてこのメタデータを提供します。 エンタープライズ シナリオでは、自分でメタデータを取得するための直接アクセス権が認められている場合があります。

ユーザーまたはホスティング サービス プロバイダーは、次のいずれかのアクションを実行して、HGS からガーディアン メタデータを取得できます。

  • 次の Windows PowerShell コマンドを実行するか、Web サイトを参照して表示される XML ファイルを保存して、HGS から直接ガーディアン メタデータを取得します。

    Invoke-WebRequest 'http://hgs.bastion.local/KeyProtection/service/metadata/2014-07/metadata.xml' -OutFile .\RelecloudGuardian.xml

  • VMM PowerShell コマンドレットを使用して、VMM からガーディアン メタデータを取得します。

    $relecloudmetadata = Get-SCGuardianConfiguration
$relecloudmetadata.InnerXml | Out-File .\RelecloudGuardian.xml -Encoding UTF8

先に進む前に、シールドされた VM の実行を認可する保護されたファブリックのそれぞれについて、ガーディアン メタデータ ファイルを取得します。

シールド データ ファイル ウィザードを使用してシールド データ ファイルを作成し、ガーディアンを追加する

シールド データ (PDK) ファイルを作成するには、シールド データ ファイル ウィザードを実行します。 ここでは、RDP 証明書、無人セットアップ ファイル、ボリューム署名カタログ、オーナー ガーディアン、前の手順でダウンロードしたガーディアン メタデータを追加します。

  1. サーバー マネージャーまたは次の Windows PowerShell コマンドを使用して、マシンに [リモート サーバー管理ツール] > [機能管理ツール] > [シールドされた VM ツール] をインストールします。

    Install-WindowsFeature RSAT-Shielded-VM-Tools

  2. スタート メニューの [管理ツール] セクションからシールド データ ファイルウィザードを開くか、次の実行可能ファイル C:\Windows\System32\ShieldingDataFileWizard.exe を実行します。

  3. 最初のページで、2 番目のファイルの選択ボックスを使用して、シールド データ ファイルの場所とファイル名を選択します。 シールド データ ファイルの名前は通常、そのシールド データを使用して作成された任意の VM のオーナーになっているエンティティ (HR、IT、財務など) と、その VM が実行するワークロード ロール (ファイル サーバー、Web サーバーなど、無人セットアップ ファイルによって構成されるもの) を基に設定します。 オプション ボタンは、[シールド テンプレートのシールド データ] に設定したままにしておきます。

    注意

    シールド データ ファイル ウィザードには、次の 2 つのオプションが用意されています。

    • シールド テンプレートのシールド データ
    • 既存の VM のシールド データとシールドされないテンプレート
      最初のオプションは、シールドされたテンプレートから新しいシールドされた VM を作成するときに使用します。 2 番目のオプションは、シールド データを作成するもので、既存の VM を変換する場合、またはシールドされていないテンプレートからシールドされた VM を作成する場合にのみ使用できます。

    シールド データ ファイル ウィザード、ファイルの選択

    さらに、このシールド データ ファイルを使用して作成された VM を本当にシールドするか、[暗号化をサポート] モードで構成するかを選択する必要があります。 これら 2 つのオプションの詳細については、「保護されたファブリックが実行できる仮想マシンの種類とは」を参照してください。

    重要

    次の手順は、シールドされた VM のオーナーと、シールドされた VM の実行が認可されているファブリックを定義するものであるため、十分に注意してください。
    後で既存のシールドされた VM を [シールド] から [暗号化をサポート] に変更したり、その逆に変更したりするには、オーナー ガーディアンを所有している必要があります。

  4. この手順の目標は 2 つあります。

    • VM のオーナーが自分であることを表すオーナー ガーディアンを作成または選択する

    • 前の手順でホスティング プロバイダーの (または自分の) ホスト ガーディアン サービスからダウンロードしたガーディアンをインポートする

    既存のオーナー ガーディアンを指定するには、ドロップダウン メニューから適切なガーディアンを選択します。 この一覧には、ローカル マシンにインストールされており、かつ、秘密キーが変わっていないガーディアンだけが表示されます。 また、右下隅にある [ローカル ガーディアンの管理] を選択し、[作成] をクリックしてウィザードに入力することで、独自のオーナー ガーディアンを作成することもできます。

    次に、[所有者とガーディアン] ページを使用して、先ほどダウンロードしたガーディアン メタデータをもう一度インポートします。 右下隅にある [ローカル ガーディアンの管理] を選択します。 インポート機能を使用して、ガーディアン メタデータ ファイルをインポートします。 必要なすべてのガーディアンをインポートまたは追加したら、[OK] をクリックします。 ガーディアンの名前は、ホスティング サービス プロバイダーまたはエンタープライズ データセンターにちなんで設定するのがベスト プラクティスです。 最後に、シールドされた VM の実行が認可されているデータセンターを表すすべてのガーディアンを選択します。 オーナー ガーディアンを再度選択する必要はありません。 完了したら [次へ] をクリックします。

    シールド データ ファイル ウィザード、所有者とガーディアン

  5. [ボリューム ID 修飾子] ページで [追加] をクリックして、シールド データ ファイル内の署名済みテンプレート ディスクを認可します。 ダイアログ ボックスで VSC を選択すると、そのディスクの名前、バージョン、および署名に使用された証明書に関する情報が表示されます。 認可するテンプレート ディスクごとに、この手順を繰り返します。

  6. [特化値] ページで、[参照] をクリックして、VM を特殊化するために使用する unattend.xml ファイルを選択します。

    下部にある [追加] ボタンを使用して、特殊化プロセス中に必要な追加ファイルを PDK に追加します。 たとえば、(New-ShieldingDataAnswerFile 関数を使用した応答ファイルの生成に関するページの記述にあるように) 無人セットアップ ファイルにより VM に RDP 証明書がインストールされる場合、RDP 証明書 PFX ファイルと RDPCertificateConfig.ps1 スクリプトをここに追加する必要があります。 ここで指定したファイルは、作成された VM の C:\temp\ に自動的にコピーされます。 無人セットアップ ファイルでは、パスを使ってファイルを参照するときに、ファイルがそのフォルダー内にあることを想定しています。

  7. 次のページで選択内容を確認し、[生成] をクリックします。

  8. 完了したら、ウィザードを閉じます。

PowerShell を使用してシールド データ ファイルを作成し、ガーディアンを追加する

シールド データ ファイル ウィザードの代わりに、New-ShieldingDataFile を実行してシールド データ ファイルを作成することもできます。

シールドされた VM が保護されたファブリックで実行されることを認可するには、全部のシールド データ ファイルに正しいオーナーとガーディアンの証明書を構成する必要があります。 Get-HgsGuardian を実行すると、ローカルにガーディアンがインストールされているかどうかを確認できます。 オーナー ガーディアンには秘密キーがあるのに対し、データセンターのガーディアンに通常秘密キーがありません。

オーナー ガーディアンを作成する必要がある場合には、次のコマンドを実行します。

New-HgsGuardian -Name "Owner" -GenerateCertificates

このコマンドは、[シールド VM ローカル証明書] フォルダー配下のローカル マシンの証明書ストアに、署名証明書と暗号化証明書のペアを作成するものです。 仮想マシンのシールドを解除するには、オーナー証明書とそれに対応する秘密キーが必要です。そのため、これらの証明書がバックアップされ、盗難から保護されていることを確認してください。 攻撃者がオーナー証明書にアクセスできると、その証明書を使用して、シールドされた仮想マシンを起動したり、セキュリティの構成を変更したりできます。

仮想マシンを実行する保護されたファブリック (プライマリ データセンター、バックアップ データセンターなど) からガーディアン情報をインポートする必要がある場合は、保護されたファブリックから取得したメタデータ ファイルそれぞれについて次のコマンドを実行します。

Import-HgsGuardian -Name 'EAST-US Datacenter' -Path '.\EastUSGuardian.xml'

ヒント

自己署名証明書を使用した場合、または HGS に登録されている証明書の有効期限が切れている場合には、セキュリティ チェックを省略するために Import-HgsGuardian コマンドで -AllowUntrustedRoot と -AllowExpired フラグの使用が必要になることがあります。

また、このシールド データ ファイルと共に使用するテンプレート ディスクごとのボリューム署名カタログと、オペレーティング システムが特殊化タスクを自動的に完了するためのシールド データ応答ファイルの取得も必要です。 最後に、VM を完全にシールドするか、vTPM のみを有効にするかを決めます。 完全にシールドされた VM の場合には -Policy Shielded、基本的なコンソール接続と PowerShell Direct を許可する vTPM を有効した VM の場合には -Policy EncryptionSupported を、それぞれ使用します。

準備がすべて完了したら、次のコマンドを実行してシールド データ ファイルを作成します。

$viq = New-VolumeIDQualifier -VolumeSignatureCatalogFilePath 'C:\temp\marketing-ws2016.vsc' -VersionRule Equals
New-ShieldingDataFile -ShieldingDataFilePath "C:\temp\Marketing-LBI.pdk" -Policy EncryptionSupported -Owner 'Owner' -Guardian 'EAST-US Datacenter' -VolumeIDQualifier $viq -AnswerFile 'C:\temp\marketing-ws2016-answerfile.xml'

ヒント

カスタム RDP 証明書、SSH キー、またはシールド データ ファイルに含める必要があるその他のファイルを使用する場合は、-OtherFile パラメーターを使用してインクルードします。 -OtherFile "C:\source\myRDPCert.pfx", "C:\source\RDPCertificateConfig.ps1" のように、ファイル パスのコンマ区切りリストを指定できます。

上記のコマンドでは、"Owner" という名前のガーディアン (Get-HgsGuardian により取得) が VM のセキュリティ構成を変更できるようになります。これに対して、"EAST-US Datacenter" は VM を実行できますが、設定の変更はできません。 ガーディアンが複数ある場合は、'EAST-US Datacenter', 'EMEA Datacenter' のように、ガーディアンの名前をコンマで区切ります。 ボリューム ID 修飾子は、テンプレート ディスクの正確なバージョン (Equals) のみを信頼するのか、将来のバージョン (GreaterThanOrEquals) も信頼するのかを指定します。 展開時に考慮されるバージョン比較では、ディスク名と署名証明書が完全に一致している必要があります。 -VolumeIDQualifier パラメーターにボリューム ID 修飾子のコンマ区切りリストを指定することにより、複数のテンプレート ディスクを信頼できます。 最後に、VM に応答ファイルを添付する必要がある他のファイルがある場合は、-OtherFile パラメーターを使用してファイル パスのコンマ区切りリストを指定します。

シールド データ ファイルを構成するためのその他の方法については、New-ShieldingDataFile と New-VolumeIDQualifier のコマンドレットについてのドキュメントを参照してください。

その他の参照情報