【Microsoft Traffic編】一般公開されたMicrosoft Entra Global Secure Access の動作確認(3/3)

1.はじめに

Microsoft Entra Global Secure Accessは、2024年7月11日(米国時間)に、Entra Suiteのプランの一部として、一般公開（GA）されました。
このMicrosoft Entra Global Secure Accessには、Microsoft Entra Internet Access(MEIA)とMicrosoft Entra Private Access(MEPA)という２つのネットワークセキュリティ機能を有しています。

特に、Microsoft Entra Internet Accessには、Microsoft サービスに送信されるトラフィックを転送する機能もあります。
本記事では、2024年7月時点において、この機能をMicrosoft Entra Internet Access for Microsoft Trafficと呼び、説明いたします。

ライセンス
Microsoft Entra Internet Access for Microsoft Trafficに関しては、以下記載のように、M365 E3にも含まれる可能性がある模様です。

Microsoft トラフィック プロファイルの使用は、基本セキュア アクセスのライセンスに含まれており、Microsoft 365 E3 ライセンスには間もなく含まれるようになります。

引用：https://learn.microsoft.com/ja-jp/entra/global-secure-access/overview-what-is-global-secure-access#licensing-overview

ちなみに、前回の記事のプライベートアクセス編は、以下となります。

2.現状のまとめ

Microsoft Entra Internet Access for Microsoft Trafficは、Global Secure Accessクライアントを利用することで、特定のM365サービス宛て通信をGlobal Secure AccessのPOPに転送することや、条件付きアクセスやテナント制限との連携を実現することができるサービスとなります。

画像引用元：https://learn.microsoft.com/ja-jp/entra/global-secure-access/quickstart-install-client

2-1.特定のM365サービスの転送

Microsoft Entra Internet Access for Microsoft Trafficにおいて、Global Secure Access クライアントから、Global Secure AccessのPOPに、フォワード可能なM365のサービスは、

• Exchange Online
• SharePoint Online & OneDrive for Business
• Entra ID and MS Graph

の３つとなります。

例えば、「Entra ID and MS Graph」の場合は、以下URL（Microsoft 365のURLとIPアドレスの範囲）先にあるID56のTCP(443,80)によるIPv4通信をフォワードすることが可能となります。
※2024年7月時点の宛先リストとなり、非定期的に変わる可能性があるので、注意が必要となります。

*.auth.microsoft.com, *.msftidentity.com, *.msidentity.com, 
account.activedirectory.windowsazure.com, accounts.accesscontrol.windows.net, 
adminwebservice.microsoftonline.com, api.passwordreset.microsoftonline.com, 
autologon.microsoftazuread-sso.com, becws.microsoftonline.com, 
ccs.login.microsoftonline.com, 
clientconfig.microsoftonline-p.net, companymanager.microsoftonline.com, 
device.login.microsoftonline.com, graph.microsoft.com, graph.windows.net, 
login-us.microsoftonline.com, login.microsoft.com, login.microsoftonline-p.com, 
login.microsoftonline.com, login.windows.net, logincert.microsoftonline.com, 
loginex.microsoftonline.com, nexus.microsoftonline-p.com, 
passwordreset.microsoftonline.com, provisioningapi.microsoftonline.com

20.20.32.0/19, 20.190.128.0/18, 20.231.128.0/19, 40.126.0.0/18

ちなみに、フォワードするか、バイパスするかは、Entra管理センターで設定することも可能となっています。
設定場所は、「セキュリティで保護されたグローバルアクセス > 接続 > トラフィック転送 > Microsoft トラフィックプロファイル > Microsoft トラフィックポリシー」です。
もし他のフォワード手段を利用したい場合は、バイパスさせることができますね。

2-2.条件付きアクセスやテナント制限との連携

テナント制限と条件付きアクセスは、少し混同してしまいますが、イメージとしては、

• 条件付きアクセスは、Global Secure Accessを利用していないデバイスからのアクセスをブロックする
• テナント制限は、Global Secure Accessを利用しているデバイスから、他社テナントへアクセスによる情報流出をブロックする

ということを実現することができます。

条件付きアクセスとの連携

アダプティブアクセスを利用することで、All Compliant Network locations (準拠しているすべてのネットワークの場所) というネームドロケーションを作ることができます。これは、条件付きアクセスの「条件 > 場所」で利用することができ、Global Secure Access経由のトラフィックであり、特定のテナントの検証済みネットワークであるという判定をすることができます。

例えば、このAll Compliant Network locationsに該当する場合のみ、アクセスを許可するといったような条件付きアクセスを構成できます。

そして、このAll Compliant Network locations (準拠しているすべてのネットワークの場所)は、単純にGlobal Secure Accessを利用して、Global Secure AccessのPOPに通信をフォワードしているかどうかの判定ではなく、各テナント固有のチェックを実施しているようです。
Global Secure AccessのPOPの出口のIPは、各社共有なので、セキュリティ的に気になりましたが、どうやら大丈夫そうですね。

この準拠しているネットワークのチェックは、各テナントに固有です。

• このチェックを使用すると、Microsoft の Global Secure Access サービスを使用している他の組織はリソースにアクセスできません

　たとえば、Contoso は、Exchange Online や SharePoint Online などのサービスを準拠しているネットワークのチェックの背後で保護し、Contoso ユーザーのみがこれらのリソースにアクセスできるようにすることができます
　準拠しているネットワークのチェックを Fabrikam のような別の組織が使用していた場合、Contoso の準拠しているネットワークのチェックには合格しません

準拠しているネットワークは、Microsoft Entra で構成できる IPv4、IPv6、または地理的な場所とは異なります。 管理者は、対応ネットワーク IP アドレスまたは範囲を確認して維持し、セキュリティ態勢を強化し、継続的な管理オーバーヘッドを最小限に抑える必要がありません。

All Compliant Network locationsの利用
Microsoft Traffic編に記載しましたが、All Compliant Network locationsは、Global Secure Accessを利用していれば使える機能で、M365アプリを含むすべてのクラウド アプリに対して、条件付きアクセスポリシーを適用できます

ソースIPの復元

また、上記アダプティブアクセスを有効化することで、ソースIPの復元も利用することができるようになります。
M365 (SharePoint Online、Exchange Online、Teams、Microsoft Graph など) 宛ての通信に限定されますが、Global Secure AccessのPOPを通過することでNATされたソースIPを元々のIPに戻した状態で、サインインログに記録することが可能となります。
一般的なSWG製品ですと、X-Forwarded-Forヘッダーを付与することで実現するような技術ですね。
これによって、NATされたソースIPを元々のIPに戻すことができるので、Entra IDのIdentity Protectionを適切に動作させたりできるようです。

例えば、アダプティブアクセス(ソースIPの復元)が未適用の場合は、以下のように、Global Secure AccessのPOPのIP（SWGの出口IP)のみが記録されます。
なぜか、グローバルセキュアアクセスを使用が 「いいえ」 にもなってしまいます。

ちなみに、Global Secure AccessのPOPのIP（SWGの出口IP)レンジは、以下です。

• 128.94.0.0/19
• 151.206.0.0/16

引用元：https://learn.microsoft.com/ja-jp/entra/global-secure-access/reference-points-of-presence#global-secure-access-egress-ip-ranges

そして、アダプティブアクセス(ソースIPの復元)が適用済みの場合は、以下のように、IPアドレスとグローバルセキュアアクセスIPアドレスが表示されるようになります。
さらに、グローバルセキュアアクセスを使用が 「はい」 になります。

テナント制限 v2の利用

テナント制限 v2の機能は、以下のように３つのオプション(OP)があります。

• OP1: Microsoft Entra グローバル セキュア アクセスの一部としてのユニバーサル テナント制限 v2
• OP2: 企業プロキシでテナント制限 v2 を設定する
• OP3: Windows マネージド デバイスでテナント制限を有効にする (プレビュー)

Global Secure Accessクライアントを利用することで、上記OP１によるユニバーサル テナント制限 v2を実現することが可能となります。

サポートされるシナリオは、以下となります。
テナント制限 v2になるので、Entra IDによる認証に関して、テナント制限を適用可能であり、テナント制限v1ではサポートされていなかったSharePoint Online と Exchange Online のデータ プレーン保護や、匿名アクセスの制限といったこともできるみたいですね。

• すべての Office アプリ (すべてのバージョンとリリース チャネル)
• ユニバーサル Windows プラットフォーム (UWP) .NET アプリケーション
• Microsoft Entra ID で認証を行う、すべての Microsoft ファースト パーティ アプリケーションと、認証に Azure AD を使うサード パーティ アプリケーションを含むすべてのアプリケーションに対する認証プレーン保護
• SharePoint Online と Exchange Online のデータ プレーン保護
• SharePoint Online、OneDrive、Teams の匿名アクセス保護 (フェデレーション制御が構成されている場合)
• Microsoft テナントまたはコンシューマー アカウントの認証およびデータ プレーン保護
• グローバル セキュア アクセスでユニバーサル テナント制限を使用する場合のすべてのブラウザーとプラットフォーム
• Windows グループ ポリシー、Microsoft Edge、および Microsoft Edge 内のすべての Web サイトを使用する場合

OP2: 企業プロキシでテナント制限 v2

テナント制限の既定の設定は、すべてブロックですが、それだけでテナント制限が動作するわけではないです。
例えば、OP2の場合は、以下認証用のURLに、以下のようなヘッダーをプロキシによって追加することで、初めて動作します。

プロキシによるヘッダー追加

• TRv1では、プロキシにRestrict-Access-To-Tenants: <allowed-tenant-list> ヘッダーを追加することで、パートナー テナントの許可
• TRv1では、sec-Restrict-Tenant-Access-Policy: restrict-msa` のようなヘッダーを追加することで、個人用アカウント（Microsoftアカウント）をブロック
• TRv2では、sec-Restrict-Tenant-Access-Policy: <DirectoryID>:<policyGUID>をヘッダーに付与し、Entra管理センターのクロステナントアクセスで設定することで、パートナーテナントの許可や個人用アカウントのブロックを実施

認証用URL
login.live.com, login.microsoft.com, login.microsoftonline.com, login.windows.net

参考URL：https://learn.microsoft.com/ja-jp/entra/external-id/tenant-restrictions-v2#migrate-tenant-restrictions-v1-policies-to-v2-on-the-proxy

例：Zscalerの場合
Zscaler のZIAでもテナント制限機能はサポートされており、テナントプロファイルの作成し、そのプロファイルをCloud App Controlポリシールールに関連付けることで、TRv1または、TRv2を利用可能のようです。

https://help.zscaler.com/ja/zia/adding-tenant-profiles

OP3: Windows マネージド デバイスでテナント制限(プレビュー)
プレビューのようですが、ADによるGPOやIntuneによるポリシー配信によっても、利用できるようです。

https://learn.microsoft.com/ja-jp/entra/external-id/tenant-restrictions-v2#option-3-enable-tenant-restrictions-on-windows-managed-devices-preview

3.動作確認

それでは、ここからは実際に動作確認をしていきます。

2024年7月末時点の検証での確認結果となります。
そのため、記載内容を保証するものではなく、テスト環境ならびに設定値によって、異なる結果となる場合がございます。
掲載内容に問題がある場合は、ご指摘いただければ修正させていただきます。

3-1.環境構築

環境構築としては、前々回から利用している環境を踏襲しています。

テスト構成は以下の通りとなります。

• Hyper-V上に、Windows 11 PCを用意
• Windows 11 PCは、Entra JoinedとIntune登録済み
• ユーザーに必要ライセンス適用済み

プロファイルの有効化（初回限り）

Entra 管理センターに移動し、「セキュリティで保護されたグローバルアクセス > 接続 > トラフィック転送」を選択します。
そして、「Microsoft トラフィックプロファイル」を有効化します。

GSAクライアントの展開と各種制限の適用

次は、Global Secure AccessのクライアントをWindows PCに展開します。
加えて、DNS over TLSの無効化やIPv6の無効化、QUICの無効化といったことも必要みたいですが、下記記事で実施済みなので、割愛致します。

GSAクライアントの現状確認結果

2024年7月時点では、GSAクライアントの利用をユーザに強制することはできません。そのため、ユーザ側で自由にGSAクライアントをOFFにすることが可能です。
※他のSSE製品ですと、パスワードを入れないとOFFにできないなどありますね。

加えて、基本的には、Fail Openのような動作と思われます。つまり、GSAクライアントがNGの場合は、そのまま通信が許可されるような動作です。

3-2.テナント制限 v2

このセクションでは、テナント制限 v2の動作確認を実施します。
テナント制限 v2自体は、Global Secure Accessがなくても利用できる機能ですが、Global Secure Accessのクライアントを利用することで、より簡単に利用することができます。

ユニバーサルテナントの制限の適用

「セキュリティで保護されたグローバルアクセス > 設定 > セッション管理」から、「ユニバ―サルテナントの制限」に移動し、「Entra IDに対してテナントの制限を有効にする」にチェックを入れます。

クロステナント アクセス設定

Entra 管理センター上のExternal Identitiesに移動します。
「テナント間アクセス設定 > 既定の設定」をクリックします。ここで、組織単位ではなく、共通設定を適用することができます。

既定の設定の画面の下の方に、「テナントの制限」という項目がありますので、設定状況を確認します。
規定値は、「すべてブロック」となっていますね。

次に、テナント間アクセスによって、テナント間で連携をいたします。
以下Microsoft Learnの内容相当となり、テナントAとテナントBという２つのテナントと連携しました。

テナントAに対するテナント制限は、規定値から継承としています。そのため、テナント制限が動作します。

ちなみに、テナントAのテナント制限の設定画面は、以下のようになっています。
規定値から継承されているので、編集はできず、少しグレーになっています。

次に、テナントBのテナント制限の設定画面は、以下のように変更しました。
ユーザとグループに関しては、すべて許可として、Office365とMy Appsは許可、その他アプリはブロックにしています。

動作確認：テナントAの場合

それでは動作確認をしていきましょう。
GSAクライアントがインストールされているデバイスで、My Appsにアクセスします。

認証完了後、アクセスがブロックされた旨の画面が表示されました。
このブロックログは、ホームテナント（GSAクライアントでサインインしているテナント）のサインインログにも記録されていました。

動作確認：テナントBの場合

同様にして、テナントBのユーザでもMy Appsにログインしてみると、ログインできました。
これは、テナントBのテナント制限は、ユーザとグループに関しては、すべて許可として、Office365とMy Appsは許可、その他アプリはブロックにしているためです。

さらに、Outlookの方にもアクセスしてみます。
こちらもOffice365アプリに該当するので、アクセス可能です。

最後に、その他アプリにもアクセスしてみると、ブロックされました。

ちなみに、ブロックしたSaaSとしては、以下記事のときにSSO連携したSaaSを利用しています。
ちょうどよいブロック先がない場合は、設定しておくと便利です。Office365アプリは意図せずブロックになってしまうと困るでしょうから。

3-3.準拠ネットワークを利用した条件付きアクセス

Global Secure Accessのアダプティブアクセスを有効化することで、準拠ネットワークを利用した条件付きアクセスを利用することが可能となります。
アダプティブとは、適応型と訳されることが多い言葉で、状況や環境の変化に対応し、適切な行動や機能を持つことができる性質を意味します。

引用：https://www.weblio.jp/content/Adaptive

アダプティブアクセスの有効化

このアダプティブアクセスの有効化を実施することで、

• ソースIPの復元
• 準拠ネットワーク（All Compliant Network locations)

を利用することができるようになります。
ほぼ必須なので、デフォルトで有効化で良い気がしますが、有効化をする必要があります。

Entra管理センターにて、「セキュリティで保護されたグローバルアクセス > 設定 > セッション管理」から、「アダプティブアクセス」のところをクリックし、「Entra IDに対してCAのシグナルを有効にする（すべてのクラウドアプリが対象）」を有効化するだけで、完了です。

条件付きアクセスの設定

条件付きアクセスの説明自体は、割愛しますが、以下URLを見ておくと良いです。
ポイントとしては、

• 順序による優先順位はなく、すべて評価される
• ブラックリスト方式（ポリシーに該当しない場合は、アクセス許可）
• 許可よりもブロックが強い
• 対象よりも対象外が強い

といった観点ですね。

条件付きアクセスの設定を実施します。
「保護 > 条件付きアクセス > ポリシー」から、「＋新しいポリシー」を選択します。

ユーザとターゲットリソースを設定します。
ユーザに関しては、テスト用のユーザやグループに限定したうえで、ターゲットリソースをOffice 365にしています。なお、Office 365アプリ以外でも利用可能です。

ちなみに、Office 365の対象アプリは、以下URLで確認することができます。Officeアプリは依存関係があるので、指定する場合は、Office 365をターゲットリソースにすることが望ましいです。

条件付きアクセスに、ネットワークという設定項目が新しくできたようですので、構成を「はい」にして、ここの「対象＝任意のネットワークまたは場所」にして、「対象外＝すべての準拠しているネットワークの場所」にします。
なお、信頼済みロケーションを利用している場合は、ネームドロケーションのAll Compliant Network locationsを信頼済みにして、「すべての信頼できるネットワークと場所」にしても問題ないです。

アクセス制御としては、「ブロック」にします。
これによって、先ほど対象外にしたすべての準拠しているネットワークの場所がアクセス許可されます。

動作確認

まず最初は、Global Secure Access クライアントが無効化された状態で、My Appsにアクセスしてみます。
My Appsは、Office 365アプリには含まれませんので、先ほど作った条件付きアクセスにヒットせず、アクセスは許可されます。

My Appsのリンクから、OutlookとSharePoint Onlineにアクセスします。
すると、GSAクライアントが無効であるため、ブロックされました。

サインインログを見てみると、グローバルセキュアアクセスを使用がいいえになり、条件付きアクセスが失敗になっていますので、期待通りの結果です。

条件付きアクセスのサインインログ
ログの見方が少しわかりにくいのですが、以下のようになっています。

• 成功: サインインの試行に CA ポリシーが正常に適用されました
• 失敗: サインインの試行に CA ポリシーが適用されましたが、サインインの試行は失敗しました
• 未適用: 適用されるポリシーの条件とサインインが一致しませんでした
• 無効: サインインの試行時にポリシーが無効になりました

引用元：
https://learn.microsoft.com/ja-jp/entra/identity/monitoring-health/concept-sign-in-log-activity-details#conditional-access

GSAクライアントを有効化した上で、再度アクセスしてみます。
今度は、GSAクライアントを利用しているため、準拠ネットワークと判定され、アクセス許可となりました。

ログにもGSAが有効な状態で、記録されています。

3-4.リンクされた条件付きアクセスポリシー

条件付きアクセスの「ターゲットリソース」に「セキュリティで保護されたグローバルアクセス(プレビュー)」という項目があり、「Microsoft 365 トラフィック」 を選択することができます。
これをリンクされた条件付きアクセスポリシーと呼びます。

初見では、M365トラフィックに対する条件付きアクセスだけかと思いましたが、Global Secure Access クライアントを利用するときのユーザ認証時にも利用されるポリシーのようです。
以下のように、Learnに記載があります。

Microsoft Entra ID の条件付きアクセス領域のトラフィック転送プロファイルに適用されます。 たとえば、ユーザーが Microsoft トラフィック プロファイルのサービスのネットワーク接続を確立するときに、準拠デバイスを必要とするポリシーを作成できます。

実運用上では、「多要素認証や準拠済みで許可」のような設定を適用しておけばよいのですが、ここではあえて、ブロックの設定をしてみようと思います。
いまいち、Learnを理解できず、動作確認をしましたので...

先ほど作った準拠ネットワークを利用した条件付きアクセスは、オフにして、以下のような条件付きアクセスを作成します。

すると、以下のようにGSAクライアントのサインインができない挙動になりました。

ただ、このときM365 Appsに対しては、以下既知の制限事項があるため、アクセスできると思っていましたが、M365 プロファイルによるフォワーディング対象のアプリ（SharePoint OnlineやExchangeなど）に対して、基本的にはアクセスができないようでしたが、ロード画面で数分待つとアクセスができることもありました。
ということで、正確な挙動は、いまいちよくわかりませんでした。

既知の制限事項
グローバル セキュア アクセス クライアントが (承認や条件付きアクセスの失敗などが原因で) サービスに接続できない場合、サービスはトラフィックをバイパスします。トラフィックは、ブロックされるのではなく、直接、ローカルに送信されます。

4.おわりに

Microsoft Entra Global Secure AccessのMicrosoft Traffic編は、ライセンスや一部挙動が謎で終わってしまいました。
個人的には、Microosft Defender for Cloud Appsのセッションポリシーなどと融合していくのかな、と推測してますが、GA後もアップデートされていきそうな機能でした。