はじめに
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 を使った閉域化というテーマで考えられるものは、ひとまず挙げられたかなと思います。
もし、考慮漏れしている点がありましたら、コメント欄で教えていただけると助かります。
なお、閉域化は 手段であって 目的ではありません。
閉域化は、情報を限定された場所に押しとどめて、そこを守っているから大丈夫・・・とシンプルにイメージしやすいので安心にはつながります。
しかし、なんのために閉域化をするのかを 今一度立ち返って検討すると、本質が見えてきて さらに必要な対策が浮かび上がることもあるかと思います。
※私は、技術的な趣味で 閉域化を目的として検証してみましたが・・・