はじめに
本記事は、Microsoft Entra Global Secure Access (GSA) のプライベートアクセス (Microsoft Entra Private Access) を利用する際に、インターネットへのアクセスを社内プロキシ経由に統制するための設定方法を解説しています。
この構成により、インターネットアクセスを社内プロキシに集約し、社内外のアクセス制御を一元化できます。そのため、一定のニーズが見込まれる構成と考えられます。
本設定方法を見い出すまでに多くの試行錯誤を要しましたが、この知見を共有することで皆さまの検討や導入の一助となれば幸いです。
イメージ図
GSA とは？
GSA のサービス概要については、以下の記事を参照ください。
Microsoft Entra Global Secure Access の全体像
https://qiita.com/carol0226/items/29cba6c32a22893a1349
本記事の対象
本記事は、以下のような利用シーンを想定しています。
- GSA のプライベートアクセス を導入している（導入予定である）
- 社内で プロキシサーバー を利用している
- PC を社内 LAN と在宅の両環境で利用しているが、プロキシ設定は固定で統一したい
※ネットワーク状態により プロキシの ON/OFF 制御が手間 - GSA クライアントと PoP 間の通信は プロキシをバイパスさせたい
- インターネットへのアクセスは 社内プロキシを経由させたい
プロキシ除外設定（最終構成）
設定のみを確認したい方は、以下のアドレス全体をコピーして、プロキシの除外として設定してください。
*.globalsecureaccess.microsoft.com; 150.171.19.*; 150.171.20.*; 13.107.232.*; 13.107.233.*; 150.171.15.*; 150.171.18.*; 151.206.*.*; 6.6.*.*; *.auth.microsoft.com; *.msftidentity.com; *.msidentity.com; *.onmicrosoft.com; *.outlook.com; *.protection.outlook.com; *.sharepoint.com; *.sharepointonline.com; *.svc.ms; *.wns.windows.com; account.activedirectory.windowsazure.com; accounts.accesscontrol.windows.net; admin.onedrive.com; 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; g.live.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; officeclient.microsoft.com; oneclient.sfx.ms; outlook.cloud.microsoft; outlook.office.com; outlook.office365.com; passwordreset.microsoftonline.com; provisioningapi.microsoftonline.com; spoprod-a.akamaihd.net
設定のイメージ ※プロキシサーバーのアドレスが 10.10.10.6 : 8080 の場合
以下のような感じで、クライアント PC の プロキシサーバーの設定欄に 除外設定 を貼り付けます。
背景
GSA クライアントは、インターネット上にある ポイントオブプレゼンス (PoP) に接続する際に、PC に設定されたプロキシを経由するように動作します。
具体的には、会社のデータセンターに設置してある プロキシサーバー（プライベート IP アドレス）が設定された PC の場合は、GSA クライアント は、このプロキシを利用しようとします。
ところが、GSA で プライベートアクセス を利用するシーンは、社外からのアクセスです。
その結果、プロキシ設定が妨げとなり、GSA クライアントは PoP に到達できず、プライベートアクセスを有効化できません。
関連情報
以下の公開情報には、プロキシに関する注意事項が記載されています。
ただし、具体的に除外すべき URL については言及されていません。
そのため、この情報だけでは十分とは言えず、本記事で明示したアドレスを除外設定に加えていただく必要があると考えます。
公開情報：プロキシが無効になっている
https://learn.microsoft.com/ja-jp/entra/global-secure-access/troubleshoot-global-secure-access-client-diagnostics-health-check?wt.mc_id=MVP_407731#proxy-disabled
動作上の制約
さらに、観察してみると 動作には制約がありました。
GSA クライアントは、プロキシの除外設定は アプリの起動時にだけ、読み込んでいるようです。
そのあとで、プロキシの設定を変更しても、GSA クライアントには反映されません。
GSA クライアントで、Disable & Enable を行っても、プロキシ除外 の設定は反映されません。
この動作が、非常に分かりづらいため、最終的な設定を見出すために 多くの試行錯誤を経て確立しました。
この設定にした理由
理由１：PoP アドレスの除外
以下の公開情報に、GSA が使用する PoP のアドレスが公開されています。
これらのアドレスを除外に加えれば良いと思ったのですが、これだけでは 不十分でした。
公開情報：Global Secure Access サービスでトラフィックを受信する FQDN と IP アドレス
https://learn.microsoft.com/ja-jp/entra/global-secure-access/reference-points-of-presence?wt.mc_id=MVP_407731#fqdn-and-ip-addresses-where-the-global-secure-access-service-receives-traffic
*.globalsecureaccess.microsoft.com
150.171.19.0/24
150.171.20.0/24
13.107.232.0/24
13.107.233.0/24
150.171.15.0/24
150.171.18.0/24
151.206.0.0/16
このアドレスを プロキシ除外 に加えた場合、一旦 プロキシ無しで GSA に接続が成功したあとであれば、この設定でプロキシ経由で通信ができました。しかしながら、新規セッションで プロキシ経由で GSA を接続することはできませんでした。
理由２：認証エンドポイントの考慮
なぜ、前章の PoP を除外するだけではダメなのか？
ここで、Microsoft Entra ID の認証が関連しているのではないかと考えました。
Microsoft Entra ID の認証に必要な URL は、以下で説明されています。
Support Blog：Microsoft Entra ID に必要な通信先エンドポイントのまとめ
https://jpazureid.github.io/blog/azure-active-directory/azure-ad-endpoints/
上記の情報のうち、「Microsoft Entra ID で基本的に利用されるエンドポイント」で説明されている、「Microsoft 365 Common および Office Online」を追加すれば、認証させることができそうですが、非常に多くのアドレスがあります。これらすべてを設定することなく、目的を達することはできないものか・・・
理由３：SSE 共存情報からの補足
さらに、調査をすすめていくと、以下の公開情報に、他社 SSE と共存させる方法が説明されている記事がありました。
公開情報：Netskope Location Profiles
https://learn.microsoft.com/en-us/entra/global-secure-access/how-to-netskope-coexistence?wt.mc_id=MVP_407731#netskope-location-profiles
上記の公開情報から、以下の箇所が読み取れます。
赤線の (6.6.0.0/16) 以外のアドレスは、GSA の PoP のアドレスとほぼ一緒です。
そのため、6.6.0.0/16 も含めて、除外しておけば良さそうです。
公開情報：Add Steering Configuration for Internet Access and Private Apps
https://learn.microsoft.com/en-us/entra/global-secure-access/how-to-netskope-coexistence?wt.mc_id=MVP_407731#add-steering-configuration-for-internet-access-and-private-apps-1
上記の公開情報から、以下の箇所が読み取れます。
どうやら、これらのアドレスが GSA クライアントが PoP へ接続する際の認証として使われていそうです。
*.globalsecureaccess.microsoft.com, *.auth.microsoft.com, *.msftidentity.com, *.msidentity.com, *.onmicrosoft.com, *.outlook.com, *.protection.outlook.com, *.sharepoint.com, *.sharepointonline.com, *.svc.ms, *.wns.windows.com, account.activedirectory.windowsazure.com, accounts.accesscontrol.windows.net, admin.onedrive.com, 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, g.live.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, officeclient.microsoft.com, oneclient.sfx.ms, outlook.cloud.microsoft, outlook.office.com, outlook.office365.com, passwordreset.microsoftonline.com, provisioningapi.microsoftonline.com, spoprod-a.akamaihd.net
動作検証
根拠１～３ で出てきたアドレスを、すべて プロキシ除外に設定し、検証してみたところ、想定した通りの動作となっています。
- GSA は、PoP に接続されている
- インターネットへのアクセス時は、プライベートアクセス を経由し、プロキシ が利用されている
- プライベートへのアクセスは、プライベートアクセス 経由で 社内リソースへアクセスされる