Windows Virtual Desktop（以下、WVD）のセキュリティ保護には5つのポイントがあります。

• 仮想デスクトップサービス自体とその要件およびセキュリティ保護方法を理解すること
• ネットワークセキュリティ
• IDのセキュリティ
• クラウドにおける仮想マシン（以下、VM）のセキュリティ
• クライアントデバイスセキュリティ

この動画では、WVDにおけるネットワークセキュリティについて掘り下げています。

※この記事は、Microsoftが提供するWindows Virtual Desktop – #21 – WVD Network Securityを要約したものです。

▼「Windows Virtual Desktopのディープな技術情報を解説」記事一覧
https://qiita.com/official-columns/tag/wvd/

---

WVDにおけるネットワークセキュリティ概要

Azure の製品ドキュメント内の安全な URL リストにWVDのネットワーク要件を網羅した表があります。
ここで右側を見るとサービスタグの列があります。ここでAzureのサービスタグはネットワーク セキュリティ グループに関連しており、基本的には特定のサービスに関連したIPおよびIP範囲の集合です。

サードパーティのツールを使用しても問題ありませんが、WVD にアクセスできるようにするにはそれらツールセットのいずれからもこれらのワイルドカードURLにアクセスできることを確認する必要があります。

企業のセキュリティ部門で特定のIPアドレスの使用を義務付けたり、ワイルドカードURLを使用しないよう義務付けることをWVDでは推奨されていません。
WVDサービスは回復性と拡張性に優れ、自己復旧機能を備えているため、利用中のリージョンでWVDサービスに問題が発生した場合、サービスは別のリージョンまたは別のURLにフェイルオーバーするためです。

このことについて、マイクロソフトのクラウドソリューションアーキテクトRalph Zomermanがblog.azureinfra.comに掲載しているブログでも解説されています。

これは通信を行っているWVDの特定のURLを示しています。現在のリージョンで何かの問題が発生すると、システムはDNSの再ルーティングによって、別のリージョンに自動的にフェイルオーバーし、別のURLが割り当てられる可能性があります。

その際に、特定のURLのホワイトリストを直接作成しているだけであれば、何か問題が生じた場合に新しいURLは自動的にホワイトリストに載せられることはないため、障害が発生してしまします。ですので、ワイルドカードのみを使用することを強くお勧めします。

なお、Azure FirewallでFQDNタグがサポートされるようになったため、このブログにもともとあったリストの多くが削除されています。

では、Azure Firewallについて詳しく見て行きましょう。

概念セクションにはFQDN（Fully Qualified Domain Name）タグの概要があります。この表には現在のFQDNタグすべてが載っています。WVDタグでは、Azureファイアウォールによる仮想デスクトップの保護を実現します。この機能についてAzure Firewall を使用して Window Virtual Desktop のデプロイを保護するに詳細があります。

この仕組みを示す基本的なグラフィックがこちらです。ファイアウォールはセキュリティハブとして機能します。つまり、オンプレミスネットワークへのトラフィックフローやAzure仮想ネットワーク内のその他のもの、そしてWVDなどインターネットと通信するものを制御します。

WVDサービスに接続する場合 、社内ネットワークからの接続であることもパブリックインターネットからの接続であることもあります。それらがWVDサービスと通信しようとするとドメインコントローラーやFSLogixプロファイルのためのファイル共有などの社内リソースにアクセスするにはファイアウォールを通過しなければならず、このフローを最初から最後まで セキュリティで保護する必要があります。また、ファイアウォールでは構成方法によっては監視、追跡、脅威分析も可能です。

Azure Firewallの設定方法

私が自分のネットワークに作成したリソースグループ使用して、実際にAzure Firewallを設定する方法を解説します。

仮想ネットワークに行くと、このネットワーク内のすべてのDNSサーバーがドメインコントローラー用の私のプライベートIPをポイントするカスタムDNSを使用するよう設定されていることがわかります。

また、サブネットにはAzureファイアウォールのサブネットと私たちのWVDセッションホストのサブネットが作成されています。

リソースグループに戻ってネットワークセキュリティグループの詳細を見てみましょう。これは既定の構成のままであるため、仮想デスクトップ向けに設定する必要があります。左側の [Outbound security rules] に行って、ここで新しいルールを追加します。

[Source] は仮想ネットワークで [Source port range] はアスタリスクのままにします。

宛先はサービス タグを使用するよう設定しますが ここにサービス タグの長いリストがあります。あるサービスに関連しているだけのものもあれば、 ある地域のサービスに固有のものもあります。フィルターを使用して探しているタグを見つけることができるので、例えば、「desktop」と入力すれば 「Windows Virtual Desktop」を選択できます。

宛先ポートは「443」に構成してTCPプロトコルを使用します。優先度については「1000」に設定します。これは後で規制を厳しくするために他のルールを追加する必要が出てきた場合に備えてのことです。

名前付け規則についてはどのサービスをどの方向で、許可または拒否するのかがわかるように 「ALLOW--WVD--OUTBOUND」とします。そして説明にはWVDワイルドカードURLを取得できるようにすることが目的と入力して、[Add] をクリックします。

さらに2つのルールを追加して 同じ基本パターンを使用します。

1つは、仮想ネットワークでポートは任意宛先は Azure クラウドのサービスタグ、ポート 443 で TCP 許可、優先度は1010で名前は「ALLOW--AzureCloud--OUTBOUND」とします。そして140文字の文字制限があるためすべてのURLを具体的にリストすることはできないため、このルールから取得されるURLのみを記載します。

もう1つは今までの2つと大きく異なります。宛先がサービスタグではなく、IPアドレスになるためです。このIPアドレスはAzureのKMS サービスの文書化されたパブリックIPアドレスでポート1688を使用し、説明はkms.core.windows.net とします。これは先程のIPアドレスが解決されるURLです。 [Add] をクリックします。

これでNSGの仮想ネットワークの設定が完了しました。

また、ドメインコントローラーサブネットおよびその他のプライベートドメインサービスとの送受信トラフィックを許可する設定も追加しています。

管理ポータルで既存のホストプールに移動します。このホストプールにはまだセッションホストがないため、登録トークンを生成して今月末まで有効であるようにします。

次に左側のセッションホストに移動して 上部の [Add] をクリックして、自分用のセッションホストを作成します。

既存のホストプールに構築しているため、この情報はすべてハードコーディングされています。 [Next] をクリックします。

この例では、構築する最初のVMであるため、いくつかのオプションがあります。

まず、上部でこのVMの構築先のリソースグループを変更します。ここに私のホストプールVM用の特別のものがあります。ここは [East US] を選択します。サイズは [B2ms] に変更し、今は1つのVMだけを作成します。そして今は5月なので 「wvd-05」というプレフィックスを付けます。

イメージの種類で ドロップ ダウンをクリックすると、 [Gallery] または [Storage Blob]のどちらかのみの選択肢があります。ストレージ Blob はストレージ アカウント内の vhd ファイルが存在する場所なので、このオプションを選択する場合はそのストレージアカウントにアクセスするためのURLを入力します。

では、カスタムイメージを使用する場合はどうするかというと [Gallery] を選択します。そこでは既定で3つのイメージの選択肢があり、カスタム イメージについては [Browse all images and disk] をクリックすると、Marketplace 内の任意のイメージを 選択できるようになります。
WVDでは Windowsイメージのみがサポートされており、仕様についてはドキュメントを参照できます。上部にある [My Items] を見ると、ここに自分のAzureカスタムイメージまたは共有イメージ ギャラリーからのイメージが置かれています。

下にスクロールすると私の仮想ネットワークが選択されています。パブリックIPアドレスは不要でネットワークセキュリティグループは無に設定されています。なぜなら、既にサブネットに接続されているからです。

ドメイン情報を入力して [Next] をクリックします。そしてタグの情報を入力します。タグによって誰がこの支払いを行うのか、どのアプリケーションが関連しているのか、環境は何かがわかります。

ここで [Next] をクリックすると、このプロセスを確認できます。そして [Create] をクリックします。
では、ログインしてみましょう。私のWVDアプリを開き、新しいデスクトップへのサインインを行います。

ファイルエクスプローラーを開いてZドライブをDFSサーバーにマップするとこの領域のすべてを参照できます。
このNSG構成によって、ドメインサービスすべてと仮想デスクトップサービスとも通信できるようになりました。

ですが、NSGは単にアクセス制御リストであり、ファイアウォールほど優秀ではないので、AzureFirewallを設定して行きましょう。

ファイアウォールでルールセットに移動してアプリケーションルールに進み、クリックして新しいアプリルールを追加します。このルールにWVDという名前を付け、1000の優先度を指定し、許可に設定します。

そして設定されたルールにはFQDNタグがありますがこの右側を見るとWindows Virtual Desktopが選択されています。

先に見ていたドキュメントに戻ると、アクセスする必要のあるURLがまだいくつかあるため、最初のものをコピーしてこれに対して新しい ターゲットFQDNを作成します。これには「XTBlob」という名前を付け、任意のIPアドレスを通過するようにし、 httpsプロトコルを使用し、そのターゲットURLを貼り付けます。

この手順を他の2つのURLに対しても実行します。ファイアウォールを使用している複数のサブネットがある場合、ソースIP範囲を明確に宣言することでさらに制限を加えることができます。今回は、Windows診断とWindows UpdateのFQDNタグもさらに追加しました。 [Add] をクリックします。

これでアプリケーションルールが完了したので次にネットワークルールも追加する必要があります。なぜなら、アプリケーションルールは http、https、 ms sql でのみ機能するためです。1688 のポートをKMS 用に開く必要があります。これにAzure KMSという名前を付け優先度を1001に設定し、アクションを許可に設定するとルール自体に「KMS」という名前が付けられます。ソースはサブネットIP範囲でKMS アドレスを使用した固有のIPアドレスの宛先に向かいます。ポートは1688です。 [Add] をクリックします。

これで完全に構成されたファイアウォールが出来上がりました。

次にNSGの関連付けを解除して、ファイアウォールの使用へと切り替え、ファイアウォールにのみ依存するようにします。
リソースグループに戻って仮想ネットワークを開き、サブネットに移動してWVDサブネットを選択します。ルートテーブルを追加する必要があります。 [Save] をクリックします。

保存している間にこちらのVMに移動し、VMを再起動します。これで新しいIP設定がすべて反映されます。ここで注意してほしいのは、カスタム ルート テーブルのトラフィック フローではすべてのトラフィックがファイアウォールに向かっていることです。その状態でドメイン コントローラーと再度通信するにはファイアウォールの設定が正確である必要があります。

ファイアウォールに戻って [Rules] に移動し、ネットワーク ルールの下を見るとすべてのトラフィックフローがドメイン コントローラーサブネットに向かうという ルールがあります。今度はクライアントを開いてログインすると、接続はまだ機能しています。

ファイル エクスプローラーを開き、まだ共有を使用できるのでCMTraceを開くかお持ちでない場合は、同様のアプリをインストールしてDFS からのファイルにアクセスします。これはドメインへの完全な接続が今も機能していることを示しています。

---

ネットワークを保護しながらNSGのサービスタグや、Azure ファイアウォールを介してWVD サービスへのアクセスを実現することはとても簡単です。また、Azureファイアウォールによって追加の脅威分析やメトリックが使用可能になり、それをAzure SentinelやAzure Security Centerなどのその他のサービスに接続することもできます。