はじめに

2023 年 8 月～2024 年 7 月まで、１年くらいかけて、AVD 周りの検証を行って Qiita の記事への投稿を行ってきました。
以下に、全体像が判るリンクを共有していますので、参照ください。

今回は、AVD をよりセキュアにできないだろうか・・・という考察をしてみました。

インデックス

Private Link with Azure Virtual Desktop
RDP Shortpath
テナント制限
ファイアウォール
条件付きアクセス
ユーザープロファイル + プライベートエンドポイント
Microsoft Defender for Endpoint + CloudApps
ExpressRoute / Microsoft ピアリング
Intune
Microsoft Purview

1. Private Link with Azure Virtual Desktop

接続元のクライアント PC（シンクライアント）から、AVD（ワークスペースとセッションホスト）への接続を閉域化できます。

通常、クライアント PC は、インターネットを介して、AVD のコントロールプレーン・ゲートウェイを経由して、AVD VM へリモートアクセスしています。

Private Link with Azure Virtual Desktop を利用すると、その制御をインターネットではなく仮想ネットワーク経由で受け付ける事が可能になります。

以下の記事で、詳しく説明するともに、検証結果を記載しています。

閉域化には、以下のようなネットワークを活用できます。

ExpressRoute プライベートピアリング
インターネットを介さず、WAN 回線プロバイダと Azure を直接接続するソリューションです。
注意すべき点は、完全なる専用線ではなく帯域が確保された共用回線である事ですが、現段階で利用できる最高レベルの閉域網となります。インターネット経由よりも安定性・可用性が期待できます。

サイト間接続 (S2S)
インターネット VPN を利用した拠点間接続のサービス。
仮想ネットワーク上の VPN ゲートウェイと、自社拠点の VPN ルーターを接続して利用します。

ポイント対サイト接続 (P2S)
インターネット VPN を利用したリモートアクセスサービス。
仮想ネットワーク上の VPN ゲートウェイと、デバイス上の VPN クライアント間を接続して利用します。

3rd Party の VPN サービス
仮想ネットワーク上に、Marketplace からデプロイした仮想アプライアンスを介して利用するサービス。
基本的には、インターネット VPN を用いて、仮想ネットワークと接続します。
私が、AVD と閉域網の組み合わせでの検証は、OpenVPN を使いました。

2. RDP Shortpath

接続元のクライアント PC（シンクライアント）と AVD VM 間のアクセスをダイレクト接続するように構成できます。

通常、クライアント PC は、AVD のコントロールプレーン・ゲートウェイを経由して、AVD VM へリモートアクセスしますが、これをクライアント PC から AVD VM へダイレクトに通信を行います。

厳密には、閉域化のためのソリューションでは無いのですが、コントロールプレーンを介したくない・・というニーズに応える事ができるため、組み合わせて検討することがあります。

3. テナント制限

クライアント PC や、AVD VM から、Microsoft Entra ID への認証を行う際に、自社デバイスを使って、他社のテナントの認証を行えなくします。

つまり、自社デバイスは自社のテナントしか利用できなくなります。

この制限が掛かっていないと、自社のデバイスを使って、他社テナントの外部ストレージを使って、データを流出させることができてしまうためです。

Microsoft Entra ID や Microsoft 365 の URL は、世界共通になっているため Firewall では防御できません。そのため、テナント制限は必須の対策となります。

テナント制限については、以下の記事で解説と検証結果について記載しています。

4. ファイアウォール

AVD の仮想ネットワーク上に、ファイアウォールを設置することで、AVD からインターネットへの通信を制御することができ、 AVD の VM をインターネットから隔離する役目を担います。

業務上、許可されたサイトへのアクセスに絞る以外に、アクセスログを記録して、セキュリティの問題が発生した際に、履歴を確認する際にも活用できます。

AVD で利用できるファイアウォールとしては、Azure Firewall または 3rd Party 製の仮想アプライアンスが利用できます。

Azure Firewall を使うと、AVD の通信を FQDN タグなどで制御する事ができます。
以下の記事で AVD と Azure Firewall を組み合わせるための方法を紹介しています。

公開情報

5. 条件付きアクセス

条件付きアクセスは、自社のリソースにアクセスしてくるユーザーを認証する際に、さまざまな条件を付加できます（ネットワークの場所、証明書、準拠済みデバイス、アプリ、認証の種類など）

これを活用して、自社のテナントへサインインできる条件を絞り込むことで、外部からのアクセスを遮断できます。

例えば、AVD を利用する場合は、「ネットワークの場所」の条件を活用して、「機密文書が保存されたストレージへのアクセスは、AVD の VM からのサインインしか認めない」ように構成することで、その他のデバイスすべてからのアクセスをブロックできます。

条件付きアクセスについては、多々検証は行って実績はあるものの、構成手順などの記事は執筆できていないため、今後取り組みます。

条件付きアクセス、テナント制限、ファイアウォールを組み合わせて運用する事の必要性を記載した記事は、以下に公開してありますので、参照ください。

6. ユーザープロファイル + プライベートエンドポイント

AVD を運用する際に、ユーザープロファイルの保存先の考慮が必要です。
多くは、FSLogix が使われると思います。

FSLogix は共有フォルダに配置する必要がありますが、ストレージアカウントや　Azure NetApp Files を使う事になると思います。

このとき、ストレージアカウントや Azure NetApp Files は、PaaS のサービスとなっていて、アクセスには グローバル IP アドレス が使われており、ファイアウォールを介して、外とアクセスする必要が出てきます。

私も、Azure Firewall と AVD を組み合わせて、閉域化の検証を行った際に気が付いたのですが、FSLogix を使っていると、AVD の VM が FSLogix プロファイルにアクセスできなくなり、サインイン時に止まってしまいました。

回避策としては、FQDN タグで Stogare への通信を許可すれば改善しますが、完璧な閉域化ではなくなります。

完璧な対策としては、ストレージアカウントへの通信をプライベートエンドポイント経由にすることで、AVD VM からストレージへの通信の際に、Azure Firewall を経由させないようにすることです。以下の記事を参考にユーザープロファイル領域の閉域化が実現できます。

7. Microsoft Defender for Endpoint + CloudApps

この仕組みは、ファイアウォールの代替となるソリューションです。
クライアント PC や、AVD の VM の Windows OS のレイヤで通信を直接制御してデバイスにポリシーを適用することで、URL やカテゴリベースの通信制御を行う事が可能になります。

さらに、アプリカタログというインターネットサイトのリスクを分析したデータベースが提供されており、その中の条件を指定して、許可・ブロックを制御できるため、管理・運用の負荷軽減が期待できます。

私の方では、AVD と組み合わせた検証は完了しており、組み合わせ動作は問題無いのですが、まだ記事化できていないため、後日アップしたいと思います。

なお、AVD の閉域化とはテーマが異なりますが、Microsoft Defender for CloudApps を使うと Microsoft 365 のデータや 3rd Party 上にアップロードしたデータが、外部流出しないように制御を行うことが可能なソリューションです。

8. ExpressRoute / Microsoft ピアリング

Microsoft ピアリングを使うと、AVD から Microsoft 365 や Microsoft Entra ID へのアクセスを閉域化できます。

そして、条件付きアクセスでネットワークの場所を制限することで、結果的に Microsoft ピアリング経由のアクセスのみに絞る事で、認証系の閉域化が可能になります。

私としては、そこまでしなくても、単なる条件付きアクセスでも、制限はできるので使わなくても良いかなとは思うのですが、セキュリティポリシー上認証系の通信はインターネットを通ってはならない・・・という制約がある場合には、採用を検討する必要が出てきます。

9. Intune

Intune を使うと、AVD に接続を行うクライアントデバイスを厳密に管理することができます。
Intune を使わなかった場合を想像するとわかりやすいのですが、社外の PC でも、個人の PC からでも AVD にリモート接続することが出来てしまいます。

Intune で、Autopilot と準拠済みデバイス、条件付きアクセスを組み合わせて利用することで、会社が社員に提供した PC のみから AVD へのアクセスを許可するように絞り込むことが可能になります。

その他にも、ウイルス対策やセキュリティパッチの適用度合いを評価して、適切なもののみ AVD への接続を許可するように制御したり、デバイスが USB や印刷などを介して情報を外部へ流出することを防止することも可能です。

AVD にアクセスしてくるデバイス側をよりセキュアにすることで、AVD の堅牢性がより高まります。

Autopilot については、以下の記事を参照ください。

これに加えて、Autopilot 以外からの Entra Join をブロックして、条件付きアクセスで AVD　へのアクセス時に、非準拠のデバイスをブロックするように構成すれば、会社提供マシンからのみ AVD へのアクセスを実現できます。

Intune については、私の方で数多くの検証を行い Qiita に記事を投稿してありますので、参照ください。

10. Microsoft Purview

これは、厳密には AVD とは関係ありませんが、隔離という点で関連するので挙げてみました。
Microsoft Purview を使うと、情報保護・データ損失防止などが行えます。

企業内には、厳秘・秘密・社内限り・公開可など、文書にはセキュリティレベルが存在します。
その文書を扱える人（グループ）と文書が紐づいており、権限のある人と無い人とを隔離できます。

AVD でプラットフォームの機密性を高めたうえで、その中で利活用する文書データも目的に応じて Microsoft Purview でより細かく管理・制御することが可能になります。

さいごに

AVD を使った閉域化というテーマで考えられるものは、ひとまず挙げられたかなと思います。
もし、考慮漏れしている点がありましたら、コメント欄で教えていただけると助かります。

なお、閉域化は手段であって目的ではありません。
閉域化は、情報を限定された場所に押しとどめて、そこを守っているから大丈夫・・・とシンプルにイメージしやすいので安心にはつながります。

しかし、なんのために閉域化をするのかを今一度立ち返って検討すると、本質が見えてきてさらに必要な対策が浮かび上がることもあるかと思います。

※私は、技術的な趣味で閉域化を目的として検証してみましたが・・・