はじめに

現在は、Azure Virtual Desktop (AVD) で、ホストプールと仮想マシンを作成する際に、どれだけシンプルな画面からデプロイさせられるか？を研究しています。
その際には、いくつかのハードルがあったのですが、そこで得られたノウハウを記事にしていこうと思っています。

今回は、AVD と Azure Firewall をどうやって組み合わせて動作させるのかをテーマにしました。

Azure Firewall と組み合わせると、AVD VM からインターネットへのアクセスがブロックされることになりますが、ブロックされてしまうと AVD の動作に支障をきたしてしまう通信があります。
適切に構成していないと、AVD にサインインできなくなったり、サインイン時に固まってしまったりします。

この記事では、AVD の動作に必要な通信のみを許可して、正常に動作させつつ、その他の通信はブロックする・・・という構成を目指しています。

前提事項

この記事で紹介している構成は、以下の環境が手配済みであることが前提となっています。

① AVD が動作する環境

以下の記事は、オンプレミスのドメインコントローラーに参加する方式を前提としています。
この記事の内容を全て構成して、AVD が動作して状態で、Azure Firewall との組み合わせを検証してあります。

Microsoft Entra Join の方法でも、動作するとは思いますが、私の方ではまだ検証はできていません。

② Azure Firewall をデプロイする

Azure Firewall をデプロイしてログを取得できるように構成してください。

ログは、構成しなくても AVD と連携した動作は組めると思いますが、トラシューの観点や、Azure Firewall がちゃんと仕事をしているのかを見るために、ログの構成は強く推奨したいと思います。

ポイント
Azure Firewall をデプロイして仮想ネットワークにルートテーブルを構成すると、AVD が正常に動作しなくなる可能性があります。これは、Azure Firewall が AVD に必要な通信をブロックしてしまっているからです。
次章以降の内容を反映することで、ふたたび AVD が動作するようになります。

なお、AVD が正常に動作せずに困った場合は、ルートテーブルを削除することで、AVD と Azure Firewall が切り離されて、AVD の単独動作に戻ります。

③ 本番運用の前に

PoC 検証の際には問題ありませんが、本番運用へ移行する前に SNAT ポートの枯渇について考慮することをお勧めします。理想的には、本番業務と同等な負荷を発生させて、実際にどの程度の SNAT ポートが消費されるのかを算出して、必要な数の SNAT ポートを確保できるようにスケーリングすると良いと思います。

④ コスト削減のコツ

Azure Firewall をデプロイすると、それなりのコストが発生します。
検証時など、Azure Firewall を常時運用する必要が無い場合でも、課金が発生します。
それを、うまくコスト削減するための方法を以下の記事で紹介していますので、参考にしてみてください。

AVD の動作に必要なインターネットトラフィック

以下に挙げた通信は、AVD の VM から、インターネットへ向けてアクセスされるトラフィックです。
各通信ごとに、どのような通信であり、Azure Firewall と組み合わせた際にどう対処すべきかを公開情報を参照して、分析してみました。

以下の３通りの公開情報を参照して、これを A～C の３つのグループに分類しました。

公開情報：Azure Virtual Desktop に必要な FQDN とエンドポイント
https://learn.microsoft.com/ja-jp/azure/virtual-desktop/required-fqdn-endpoint

公開情報：仮想ネットワークサービスタグ
https://learn.microsoft.com/ja-jp/azure/virtual-network/service-tags-overview

公開情報：Azure Firewall を使用して Office 365 を保護する
https://learn.microsoft.com/ja-jp/azure/firewall/protect-office-365

A グループ（概要）

AVD の閉域化において、強く意識しておくべきアクセス先を、A グループとしました。
この記事の後半に A グループ（詳細）という章で、具体的な設定項目についても言及しています。

以下の表では、Azure Firewall、プライベートエンドポイント、ExpressRoute の３つの列を示していますが、各項目ごとに、いずれか１つを選択して構成してください。

個人的には、プライベートエンドポイントを使える項目は、それを活用して、それ以外は Azure Firewall で制御するのが良いのではないかと思います（ExpressRoute は特定要件での利用にとどめ、積極的には利用しない）

Azure Firewall を採用した場合、インターネット向けにトラフィックを送信する事になります。
No.1 ～ 5 は、FQDN や FQDN タグで制御可能な HTTP アクセスのため、アプリケーションルール で構成します。
No.6 以降は、HTTP 以外のプロトコルであるか、または、サービスタグを必要とするため、ネットワークルール で構成する必要があります。

プライベートエンドポイント、ExpressRoute を採用すると、閉域網経由で通信が可能になり、Azure Firewall を経由しなくなるため、該当の通信については、Firewall の許可ルールを書く必要が無くなります。

#	目的	Azure Firewall	Port	プライベートエンドポイント	ExpressRoute
1	Control Plane	FQDN タグ WindowsVirtualDesktop	TCP 443	〇	プライベートピアリング
2	Data Plane	xt.blob.core.windows.net eh.servicebus.windows.net *xt.table.core.windows.net	TCP 443		Microsoft ピアリング
3	Custom Script	xxxx.blob.core.windows.net	TCP 443	〇	Microsoft ピアリング
	Custom Script 2	www.powershellgallery.com *.azureedge.net	TCP 443
4	Microsoft 365	FQDN タグ Office365～で始まる各種タグ	TCP 80 , 443		Microsoft ピアリング
5	Windows Update	FQDN タグ Windows Update	TCP 443
6	FSLogix Profile	Standard or Premium SKU carol0226storage.file.core.windows.net Basic SKU サービスタグ Storage.[リージョン]	TCP 445	〇	Microsoft ピアリング
7	DNS	168.63.129.16	TCP , UDP 53
8	KMS	Standard or Premium SKU azkms.core.windows.net Basic SKU 20.118.99.224 , 40.83.235.53	TCP 1688
9	Microsoft Entra ID	サービスタグ AzureActiveDirectory	TCP 443		Microsoft ピアリング
10	Microsoft 365	サービスタグ Office365～で始まる各種タグ	TCP 多数のポート
11	Azure Monitor	サービスタグ AzureMonitor	TCP 443	〇
12	TimeSync	Standard or Premium SKU time.windows.com Basic SKU 20.43.94.199	UDP 123

B グループ

AVD の VM 上から、Azure Portal を利用する際に、Portal から参照される URL だと思われます。もし、Azure Portal を利用する予定がある場合には、許可しておくと良いと思いますが、Azure Portal を使う予定がない場合は、特に許可する必要は無いと思います。
※この分類は、詳細な検証はしていません。ドキュメントを読んだうえでの私の見解です。

#	URL	Port	用途
1	catalogartifact.azureedge.net	TCP 443	Azure Marketplace
2	gcs.prod.monitoring.core.windows.net	TCP 443	エージェントトラフィック
3	mrsglobalsteus2prod.blob.core.windows.net	TCP 443	エージェントとサイドバイサイド (SXS) スタックの更新
4	wvdportalstorageblob.blob.core.windows.net	TCP 443	Azure portal のサポート

C グループ

AVD の VM から用途欄に記載されたサービスを利用する場合には、許可しておく必要がある宛先です。これらのポートは特に解放しなくても AVD の基本的な動作は問題なく確認できましたが、長期運用を考えた場合は、ひとまず解放しておいた方が良いと思います。
※この分類は、詳細な検証はしていません。ドキュメントを読んだうえでの私の見解です。

#	URL	Port	用途
1	login.microsoftonline.com	TCP 443	Microsoft オンラインサービスへの認証
2	169.254.169.254	TCP 80	Azure Instance Metadata Service エンドポイント
3	168.63.129.16	TCP 80	セッションホストの正常性の監視
4	oneocsp.microsoft.com	TCP 80	証明書
5	www.microsoft.com	TCP 80	証明書
6	login.windows.net	TCP 443	Microsoft Online Services および Microsoft 365 へのサインイン
7	*.events.data.microsoft.com	TCP 443	テレメトリサービス
8	www.msftconnecttest.com	TCP 80	セッションホストがインターネットに接続されているかどうかの検出
9	*.prod.do.dsp.mp.microsoft.com	TCP 443	Windows Update
10	*.sfx.ms	TCP 443	OneDrive クライアントソフトウェアの更新
11	*.digicert.com	TCP 80	証明書失効の確認
12	*.azure-dns.com	TCP 443	Azure DNS 解決
13	*.azure-dns.net	TCP 443	Azure DNS 解決
14	*eh.servicebus.windows.net	TCP 443	診断設定

A グループ（詳細）

この章では A グループのルールについて、具体的な設定値を説明していきます。

1. Control Plane

コントロールプレーン とは、AVD を制御するために必要な "Microsoft によって管理されているコンポーネント" 群を指しています。

公開情報：Microsoft によって管理されるコンポーネント
https://learn.microsoft.com/ja-jp/azure/architecture/example-scenario/azure-virtual-desktop/azure-virtual-desktop#components-that-microsoft-manages

AVD + Azure Firewall を構成する際に、コントロールプレーンへの通信を制御しています。

1-1. AzFW の FQDN タグで WindowsVirtualDesktop を許可する
　→　これは、AVD と Azure Virtual Desktop を併用するために必要な設定です。

1-2. Private Link with Azure Virtual Desktop を採用する
　→　閉域網 (VPN) からのアクセスに制限する場合は、さらに 1-2. を構成してください。

1-1. AzFW の FQDN タグで WindowsVirtualDesktop を許可する

インターネット上のクライアント PC から、AVD へ接続するためには、Azure Firewall アプリケーションルールの FQDN タグで WindowsVirtualDesktop を許可しておく必要があります。
これを行っていないと、AVD に接続する事ができません。

以下が検証済みの設定例となります。

実際のログの出力結果です。

1-2. Private Link with Azure Virtual Desktop を採用する

仮想ネットワークへ VPN や ExpressRoute で接続したクライアント PC から、AVD へ接続するためには、Private Link with Azure Virtual Desktop を構成します。

以下の記事で、詳細を説明していますので、参照してください。

2. Data Plane

データプレーンは、AVD で制御を行う際に使われています。
私も何のためにどのように使われているのかは、解明しきれていないのですが、以下の公開情報で説明されています。

公開情報

（上記より抜粋）

おおざっぱに解放するだけなら、アプリケーションルールで、以下の 3 つの URL を許可するだけで OK です。
*xt.blob.core.windows.net、*eh.servicebus.windows.net、*xt.table.core.windows.net

以下は検証済みアプリケーションルールの設定例です。赤線部分は見切れていますが、上記の URL をカンマ区切りで指定しています。

私の記事でログを構成していれば、上記の設定をしたあとに、以下のように "2-DataPlane" で許可された結果をフィルタしてみてください。

さらに、利用者ごとに * の部分が固有になっているので、自環境で使っている URL を調べて、それだけを許可することで、より厳密な制限を掛ける事ができます。私の環境の値ですが、検証環境なのでまんまお見せしちゃいます。disinct で Fqdn 列を重複排除して表示させています。

以下の記事では、イベントログから厳密な URL を調査する方法が画面付きで紹介されていますので、以下の説明分の記載箇所から下を読んでみてください。

You need to add some additional rules as well into the rule collection set, these allow the Windows Virtual Desktop host pool VMs to communicate with the data plane of WVD.

3. Custom Script

AVD をデプロイする際に Custom Script を使用するように構成している場合には、3-1 か 3-2 のいずれかの方法で許可する必要があります。

例えば、私の以下の記事を読んだかたは、AVD をデプロイする際に、全自動日本語化を構成されているかもしれません。このようにデプロイの際に Custom Script を使う場合は、そのアドレスを参照できるように構成しておく必要があります。

3-1. AzFW の FQDN で BLOB のアドレスを直接指定する
3-2. ストレージアカウントのプライベートエンドポイントを構成する（これを、推奨）
3-3. PowerShellGalary のダウンロード（私の記事の日本語化をやった人は、これも実施）

3-1. AzFW の FQDN で BLOB のアドレスを直接指定する

以下は検証済みアプリケーションルールの設定例です。FQDN は、環境毎にことなるため、皆さんの URL に置き換えてください。

3-2. ストレージアカウントのプライベートエンドポイントを構成する

以下の記事を参照して、ストレージアカウントへのアクセスをプライベートエンドポイント経由で構成します。そうすることで、ストレージへの通信が Azure Firewall を経由しなくなることが期待できます。

3-3. PowerShellGalary のダウンロード

私の全自動日本語化を採用している場合は、さらに PowerShellGalary の URL も許可しておく必要があります。これは、Windows Update をコマンドで実行させるために必要な追加モジュールを PowerShellGalary からダウンロードしているためです。

許可する必要がある URL（カンマ区切りで入力）
　www.powershellgallery.com , *.azureedge.net

実際のログの出力結果です（3-1 と 3-3）

4. Microsoft 365

Microsoft 365 を利用する場合に、許可が必要です。
Microsoft 365 へのアクセスは、アクセスさせたいサービスを FQDN タグで指定して許可することができます。

以下はアプリケーションルールの設定例です。

赤線部分をクリックすると、以下の一覧が表示されるため、Office365 で始まるタグを複数選択します。

実際のログの出力結果です。

以下の記事で詳しく説明されています。

上記の記事のうち、ネットワークルールについては、項番 10. で構成しています。

5. Windows Update

AVD の VM が Windows Update を実行できるように、ルールを構成します。

以下は、検証済みアプリケーションルールの設定例です。

実際のログの出力結果です。

6. FSLogix Profile

ユーザープロファイルを FSLogix で構成している場合は、以下のいずれかの方法で許可する必要があります。FSLogix を使っているのに、いずれかの許可設定をしていないと、サインイン時に固まります。

6-1. AzFW のネットワークルールで BLOB を許可する（簡易的な対策）
6-2. ストレージアカウントのプライベートエンドポイントを構成する（これを、推奨）

なお、FSLogix を構成するための手順は、以下の記事で解説していますので、参照ください。

6-1. AzFW のネットワークルールで BLOB を許可する

FSLogix は、SMB プロトコル (TCP 445) でアクセスされるため、アプリケーションルールは使えません。
さらに、ネットワークルールで、FQDN を扱うためには、Azure Firewall の DNS プロキシという機能を使う必要があります。

DNS プロキシは、Standard SKU または Premium SKU で利用ができます。
以下を参考に DNS プロキシを構成してください。
上位の SKU が必要なので、私は、検証できていません。なお、この要件のためだけに上位の SKU を採用するのもコスト的に勿体ないと思います。それならば、6-2. Private Link を採用しましょう。

Basic SKU では、DNS プロキシを利用する事ができません。
そのため、厳密な制限をすることができないので、注意が必要です。
この方法は、簡易的な対策だと認識ください。

この方法は、サービスタグを使って、ストレージアカウント全体を許可します。
（AVD の VM から、他社のストレージアカウントへのアクセスが可能になってしまうので、セキュリティホールになり得ます）

検証済みネットワークルールの設定例としては、下図のように Storage.JapanEast という指定をすることで、リージョン単位での制御は可能です。

実際のログの出力結果です。

6-2. ストレージアカウントのプライベートエンドポイントを構成する

こちらがおススメの方法です。
プライベートエンドポイントを使って FSLogix の共有フォルダへのアクセスを許可して、Azure Firewall では、インターネット経由のストレージアカウントへのアクセスはブロックします。

こうすることで、ストレージのトラフィックは閉域網を経由させることが出来、他社のストレージへインターネット経由でアクセス出来てしまう事も防げます。

以下の記事にプライベートエンドポイントについての説明と、ストレージアカウントをプライベートエンドポイント経由にするための手順を紹介しています。

ポイント
プライベートエンドポイントを構成した場合は、トラフィックは Azure Firewall を経由しなくなります。
その結果、Azure Firewall のログに、ストレージへのアクセスログは出なくなります。

7. DNS

これは、仮想ネットワーク内の DNS クライアントがインターネットの名前解決ができるようにするために構成します。
オンプレミスの AD DS を使っている場合は、AD DS サーバーが名前解決を行うために必要です。
Microsoft Entra Join を使っている場合は、各 AVD VM が名前解決を行うために必要です。

ネットワークルールの設定例は、以下の通りです。

ログは、取りっぱぐれました。

8. KMS

Azure VM は、OS のライセンス認証が自動的に構成されています。
しかし、Azure KMS のアドレスと通信ができないと、ライセンス認証を行う事ができません。
VM のライセンス認証が途切れないように、Azure KMS の URL である azkms.core.windows.net へ TCP 1688 での疎通が必要です。

ネットワークルールで、FQDN を扱うためには、Azure Firewall の DNS プロキシという機能を使う必要があります。

DNS プロキシは、Standard SKU または Premium SKU で利用ができます。
以下を参考に DNS プロキシを構成してください（私は、検証できていません）

Basic SKU では、DNS プロキシを利用する事ができません。
Azure KMS の URL に該当するIP アドレスは、固定化されているため、IP アドレスの直指定で対策しましょう。

以下は、検証済みネットワークルールの設定例です。

実際のログの出力結果です。

Azure KMS については、以下も参照ください。

9. Microsoft Entra ID

Microsoft Entra ID への認証や Microsoft Entra Connect 同期などで利用されています。
サービスタグに "AzureActiveDirectory" があるので、これを利用します。
サービスタグは、ネットワークルールで利用できます。

以下は、検証済みネットワークルールの設定例です。

実際のログの出力結果です。

10. Microsoft 365

Microsoft 365 へのアクセスのうち、HTTP 以外のポートを使うアクセスは、サービスタグで指定して許可することができます。
HTTP 以外のポート（143,25,3478,3479,3480,3481,587,993,995）

以下は机上レベルの設定例です。

宛先サービスタグは、以下にチェックを入れます。

Microsoft 365 のサービスを使い尽くしていないせいか、該当するログは出ていませんでした。
ログを出すには、特殊なポートをあえて使う必要があるので、M365 についての研究が必要そうです。
今後、ログが取得できたら追記するようにします。

11. Azure Monitor

仮想ネットワーク上に、ドメインコントローラーや AVD の VM があり、診断設定を有効化している場合には、以下のいずれかの設定が必要です。

11-1. AzFW のネットワークルールで Azure Monitor を許可する
11-2. Azure Monitor Private Link Scope を構成する

11-1. AzFW のネットワークルールで Azure Monitor を許可する

通常、診断ログのインジェスト（ログを送信するトラフィック）は、インターネット上に公開されている Azure Monitor のエンドポイントに向かって送信されます。

以下の公開情報で説明されているいくつかの URL を許可する必要がありますが、これを Azure Monitor というサービスタグを使って設定する事が可能です。

サービスタグを利用するため、ネットワークルールで構成する必要があります。

以下は、検証済みネットワークルールの設定例です。

実際のログの出力結果です。

11-2. Azure Monitor Private Link Scope を構成する

Azure Monitor には、Azure Monitor Private Link Scope (AMPLS) という仕組みが提供されており、インジェストを閉域網経由で転送する事が出来るようになります。

公開情報

12. Time Sync

時刻同期に関するルールも許可しておきます。
UDP 123 ポートを使う為、ネットワークルールで記述します。

以下は、検証済みネットワークルールの設定例です。

実際のログの出力結果です。

以上で、AVD と Azure Firewall を連携して動作させるための設定が完了しました。

あとは、実際に AVD をデプロイしたり、接続したりしてテストしてください。
Azure Firewall のログが取得されるようになっていると、トラブルシューティングに役立てられます。

参考：ブロックされたログの確認

以下のログは、Azure Firewall が通信をブロックした結果です。

アプリケーションルールのブロック結果です。
許可されていない URL がブロックされている事が判ります。

ネットワークルールのブロック結果です。
UDP 123 と、TCP 1688 がブロックされていますが、これは 8-KMS と 12-TimeSync のルールを書く前にブロックされていた時のものです。このあと許可ルールを書いて Allow されたことを確認しました。

このような形で、ブロックされた結果を確認して、必要な通信がブロックされていないかを確認してください。