はじめに
現在は、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 されたことを確認しました。
このような形で、ブロックされた結果を確認して、必要な通信がブロックされていないかを確認してください。