🌐

Microsoft Entra の Global Secure Access を使ってみる (Internet Access M365 編)

2023/07/12に公開

はじめに

Azure AD の Microsoft Entra ID へのリブランディングが発表され、同時に Secure Service Edge のサービスである Global Secure Access がパブリックプレビューになりました。
セキュア ウェブ ゲートウェイ (クラウドプロキシ) である Internet Access と ZTNA である Private Access が含まれます。
※ Internet Access のパブリックインターネットへのアクセス (M365 以外の Web サイトやアプリへのアクセス) は2023/7 時点では Private Preview
https://learn.microsoft.com/ja-jp/azure/global-secure-access/overview-what-is-global-secure-access

アクセス方法としては、端末にエージェントをインストールする方法とルーターなどから VPN 接続する方法 (リモート ネットワークと呼んでいる) の 2 パターンです。

今回はこちらの Internet Access (M365 向けのみ) の設定と動作を確認していきます。

初期設定

今回は Get Started に従って設定していきます。
https://learn.microsoft.com/ja-jp/azure/global-secure-access/how-to-get-started-with-global-secure-access

事前準備

  • Global Secure Access Administrator ロールが必要
  • プレビュー利用には Microsoft Entra ID Premium P1 (旧 Azure AD Premium P1) が必要で、M365 向けトラフィックのフォワーディングも実施する場合は M365 E3 が推奨
  • 一般提供のタイミングでは別のライセンスが必要となる可能性がある

Microsoft Entra Internet Access

以下の順序で設定してきます。設定は Azure ポータルではなく、Entra 管理センター(https://entra.microsoft.com) で行います。

  1. Microsoft 365 traffic forwarding profile を有効にする。
  2. エンドユーザーデバイスに Global Secure Access Client をインストールして構成する。
  3. テナント制限を有効にする。
  4. セキュア アクセス シグナリングを有効にする。

Microsoft 365 traffic forwarding profile

M365 traffic forwarding profile を指定すると、以下のサービス向けの通信が Global Secure Access 経由でアクセスし、ポリシー適用やログ取得ができるようになります。

  • Exchange Online
  • SharePoint Online and OneDrive for Business
  • Microsoft 365 Common and Office Online (only Microsoft Entra ID and Microsoft Graph)

Microsoft 365 traffic forwarding profile を有効化していきます。なお、Entra 管理センターは日本語表示にしています。(翻訳がところどころ怪しいです)

Entra 管理センター (https://entra.microsoft.com) にアクセスして、 [セキュリティで保護されたグローバル アクセス (プレビュー)] > [接続] > [トラフィック転送] をクリックし、[Microsoft 365 profile] のチェックを有効にします。


[Microsoft 365 traffic policies] の [View] をクリックします。


対象サービスおよびアクセス先の一覧が表示されます。すべて Global Secure Access を経由する場合はすべての項目にチェックを入れ、Forward になっていることを確認して保存します。Bypass にした場合は Global Secure Access を経由せず、端末から直接インターネットにアクセスします。


[Linked Conditional Access policies] については、本トラフィックに関する条件付きアクセスがある場合に表示されます。以下のように条件付きアクセスの設定で [ターゲット リソース] に [セキュリティで保護されたグローバル アクセス (プレビュー)] が追加されており、こちらで 場所の制限や MFA やコンプライアンス準拠端末などの条件を指定できるようになっています。

また、以下のドキュメントのように [All Network Access locations of my tenant] の場所の条件を使用することで、Global Secure Access を経由しない場合のアクセスをブロックすることが可能です。後述しますが、クライアントの動作が fail-open なので、fail-open した際に直接のインターネットアクセスをブロックしたい場合は本設定が必要になります。
https://learn.microsoft.com/ja-jp/azure/global-secure-access/how-to-compliant-network

なお、こちらはあくまで Global Secure Access へのログインする場合の条件付きアクセスのため、Teams や SharePoint などに個別に条件付きアクセスが必要な場合はそちらも設定が必要になります。


作成・保存すると、以下のように Linked Conditional Access policies として表示されます。


[Assignments] については、このプロファイルを適用するデバイスやリモート ネットワークなどを指定します。現時点でリモート ネットワークは登録していないため、[Add Assignments] を選択しても以下のような表示になります。

Global Secure Access Client をインストール

こちらを参考にしてインストールを進めていきます。
https://learn.microsoft.com/ja-jp/azure/global-secure-access/how-to-install-windows-client

以下が前提条件です。AAD 参加 or Hybrid AAD 参加がハードルになるケースがありそうです。

  • 64 ビット版の Windows 11 または Windows 10 でサポート
  • デバイスは、Azure AD に参加しているか、Hybrid Azure AD に参加している必要がある
  • Azure AD に登録されているデバイスはサポート外
  • インストールにはローカル管理者の認証情報が必要

また以下が気になる制限事項です。(ほかにも多数あるためドキュメント確認をおすすめします)

  • リモートデスクトップサーバー (RDP) など、同じデバイス上での複数のユーザーセッションはサポートされていません。
  • Global Secure Access Client がサービスに接続できない場合 (認証または条件付きアクセスの失敗など)、サービスはトラフィックをバイパスします。トラフィックはブロックされる代わりに、ダイレクトアンドローカルで送信されます。このシナリオでは、準拠ネットワークチェック用の条件付きアクセスポリシーを作成して、クライアントがサービスに接続できない場合にトラフィックをブロックできます。

すごく要約すると、1 点目は AVD マルチセッションは未サポート、2 点目はエージェント単体では fail-close 機能は提供されず fail-open になるので、条件付きアクセスで送信元:Global Secure Access 以外 (もしくは All Compliant Network locations 以外) 、宛先:制限したいアプリを指定してブロック設定し、fail-open になった時に Global Secure Access 以外からのアクセスはブロックしてください。という理解です。ただ、その場合条件付きアクセスで指定できない Web サービスへのアクセスはどうするんだ?とは思いますが、、、(Internet Access がフル機能提供され始めてからの改善に期待します)

ここからインストールをしてみます。
Entra 管理センターの [セキュリティで保護されたグローバル アクセス (プレビュー)] > [デバイス] > [クライアント] からインストーラをダウンロードします。


実行すると以下のように認証画面が出るので、ログインします。


インストールに成功するとタスクトレイにアイコンが表示されます。

テナント制限

次にテナント制限を設定していきます。こちらを使用することで、自社以外のテナントにある M365 サービスへのアクセスをブロックできます。例えば、自社の端末で個人で契約した OneDrive for Business へのアクセスを禁止し、情報持ち出しを防ぐことが可能です。
従来だとプロキシで HTTP ヘッダへの ID 挿入 (v1)、もしくはグループ ポリシー等で端末に設定 (v2) が必要でしたが、Global Secure Access を使用することで簡単に制御することが可能になります。
今回はイメージをつかむため、すべての外部テナントをブロックする設定を入れていきます。

Entra 管理センターの [External Identities] > [クロステナント アクセス設定] > [テナント間アクセス設定] > [既定の設定] をクリックします。


一番下の [テナントの制限 (プレビュー) ] を確認して、[すべてブロック] になっていることを確認します。


[セキュリティで保護されたグローバル アクセス (プレビュー)] > [グローバル設定] > [セッション管理] > [Tenant Restrictions] で有効にします。

セキュア アクセス シグナリング

設定画面やドキュメントによっていろいろな呼び方があるみたいですが、要は Global Secure Access を経由する前のオリジナルのグローバル IP をいろいろな設定で利用できるようにする、という設定のようです。具体的には以下の箇所で使用できるようです。

  • 条件付きアクセスおよび継続的なアクセス評価の両方にわたって、ソース IP ベースのロケーション・ポリシーの実施を継続
  • Identity Protection のリスク検出は、さまざまなリスクスコアを評価するために、元のユーザーのソース IP アドレスの一貫したビューを取得
  • 元のユーザーのソース IP は、Microsoft Entra ID のサインインログでも利用

注意事項として、こちらの設定を使用しない場合に条件付きアクセスで場所に基づく制限をかけていると、Global Secure Access を利用することで送信元 IP が Global Secure Access の出口 IP になるためアクセス不可になります。

設定は [セキュリティで保護されたグローバル アクセス (プレビュー)] > [グローバル設定] > [セッション管理] > [Adaptive Access] で有効にします。

ログの有効化

オプションとしてログの有効化をしておきます。
[セキュリティで保護されたグローバル アクセス (プレビュー)] > [グローバル設定] > [ログ] から有効化します。現状は SPO のみのサポートです。


また強化された M365 ログは現時点では管理センター上では表示されないようなので、上記とは別に Microsoft Entra ID のほうの診断設定でログ収集の有効化も必要になりそうです。ついでに NetworkAccessTrafficeLogs も有効にしておきます。

動作検証

通信経路

まず Connectivity test を使って経由地を確認してみます。今回 Azure 東日本リージョンにある Windows 10 端末で検証しています。
Global Secure Access を有効にした場合、以下のように US を経由しているのが分かります。遅いですね。500ms くらいかかっています。


ちなみに無効化した場合です。5ms で速いです。

ちなみに Point of Presence (PoP) と呼ばれる Global Secure Access の接続ポイントの情報は以下に記載があります。東日本、西日本に作ってくれないと、正直日本からの利用は厳しいかもしれません。
https://learn.microsoft.com/ja-jp/azure/global-secure-access/reference-points-of-presence

テナント制限

SharePoint にアクセスしてみます。問題なくアクセスできました。

テナント制限を試します。別テナントのアカウントで別テナントの Office365 にアクセスすると以下のようにブロックされました。


なお、以下のシナリオはいずれもアクセス可能でした。(これはテナント制限 v2 の検証ですが。)

  • 別テナントのアカウント(外部ゲストユーザー)で自社テナントにログイン
  • 自社テナントのアカウントで別テナントにログイン

これらの制限をしたい場合はテナント制限ではなく、テナント間アクセス設定の受信アクセス・送信アクセスを設定する形になるイメージです。
https://learn.microsoft.com/ja-jp/azure/active-directory/external-identities/tenant-restrictions-v2#tenant-restrictions-vs-inbound-and-outbound-settings

また、グループ ポリシーなどで端末に設定する場合、Chrome や FireFox が未サポートという致命的な制限があったのですが、Global Secure Access で構成する場合は以下のドキュメントの通り、ネットワーク側で HTTP ヘッダを付与する仕組みのようで、Chrome でもブロックが可能でした。
https://learn.microsoft.com/ja-jp/azure/active-directory/external-identities/tenant-restrictions-v2#step-4-set-up-tenant-restrictions-v2-on-your-corporate-proxy

条件付きアクセス

M365 プロファイル向けに設定した条件付きアクセスに場所の制限を追加し、ブロックするように追加します。


しかし、しばらく時間を空けてみましたがブロック動作が確認できず (Global Secure Access の条件付きアクセスの再評価間隔が分からない) 再起動しました。
すると、以下のように認証画面が表示され、ブロックを確認できました。


サインイン ログにも ZTNA Network Access Client -- M365 として記録されています。

この時、前述したように fail-open のため、他の条件付きアクセスで制限していなければ端末からインターネットに直接アクセスし、M365 を使用することが可能です。

ログ

トラフィックログは以下のように出力されます。(初回ログの出力までしばらくかかりました)
診断設定をすることで、同じ内容が Log Analytics 側でも確認可能なので、Sentinel で分析もできそうです。


またサインイン ログは以下のように出力されており、アクセス元の IP が表示できています。


比較のためにセキュア アクセス シグナリングを OFF にした場合は以下のように Global Secure Access の PoP が送信元 IP になっています。


強化された M365 ログでは現時点では管理センターでは表示されません。


診断設定で Log Analytics などへ転送するとそちらから確認できます。

まとめ

長くなりましたが、新しくリリースされた Entra Global Secure Access の Internet Access (M365向け) を検証してみました。一通り動作を確認しましたが、M365 向けの場合では使えそうなシナリオはテナント制御くらいではないかと思います。パブリック インターネット向けの機能に期待です。日本国内に PoP がないことが大きなブロッカーになりそうですので、早く対応してほしいところです。次の記事で Private Access についても検証しようと思います。

■ Private Access の記事
https://zenn.dev/microsoft/articles/645e632231735f

Microsoft (有志)

Discussion