GSA 経由でない通信はすべてブロックする 設計がなぜ必要なのか、その本質を解説します。
（ID やデバイスだけでは防げない“抜け道”が存在するためです）
はじめに
Microsoft Entra Global Secure Access（略：GSA）と 条件付きアクセス を組み合わせて
Microsoft 365 や SaaS への通信を「GSA 経由のみに制限する」——
この設計、実際にやってみるとこう思う方も多いのではないでしょうか？
これって何が嬉しいの？
本記事では、この疑問に対してシンプルに結論からお伝えします。
本記事は、条件付きアクセス の基本を理解しており、GSA を使った設計の「意味」を知りたい方向けです。
GSA についてわからない方は、以下の私の GSA ストックリスト を参照ください。
Microsoft Entra Global Secure Access (GSA) のストックリスト
https://qiita.com/carol0226/stocks/878e7bbc57b301e0deac
条件付きアクセス を初めて構成する方は、以下の私の記事を参照ください。
セキュリティの既定値群 と 条件付きアクセス の初回利用について
https://qiita.com/carol0226/items/51a70a561b78af567972
結論：条件付きアクセス が「通信経路」を強制できるようになる
従来の 条件付きアクセス は、主に以下のような観点でアクセスを制御していました。
- ユーザー（誰か）
- デバイス（どの端末か）
- アプリ（どこにアクセスするか）
- 場所（どこからアクセスしているか）
しかし、GSA を組み合わせることで、ここに新たな制御軸が追加されます。
「どの経路で通信しているか（＝GSA を経由しているかどうか）」
つまり、以下のようなポリシーが実現可能になります。
GSA を経由していない通信は、すべてブロックする
※ 本制御は、Microsoft Entra ID で認証される SaaS アプリに対して有効です。
（IDベースで制御できないアプリには適用されません）
これは単なる制御の追加ではなく、
アクセス制御のレイヤーが “アプリ” から “ネットワークトラフィック全体” に拡張される
ことを意味します。
何がうれしいのか？
このアーキテクチャによって得られる価値は、大きく分けて次の通りです。
① ゼロトラストの強化（抜け道の排除）
- 正規ユーザーでも
- 準拠デバイスでも
GSA を通らない通信は許可しない
これにより、
- 直接アクセス（Bypass）
- 非管理ネットワーク経由のアクセス
- セキュリティ未適用の通信
といった「抜け道」を排除できます。
言い換えると、ID やデバイスが正しくても「経路が信用できない場合は拒否する」という制御が可能になります。
これは「信頼されたネットワークは存在しない」というゼロトラストの前提を、通信経路レベルで適用している形です。
② すべての通信をセキュリティチェック下に置ける
GSA（Internet Access）は、いわゆる クラウド型プロキシ（Secure Web Gateway） として動作します。
そのため通信は必ず以下の経路になります。
端末 → GSA（Microsoft Edge Network） → Internet / SaaS
この構成により：
- 悪性サイトのブロック
- Web カテゴリフィルタリング
- SaaS 利用制御
- トラフィックログの可視化
が 強制的に適用される状態 になります。
（＝ユーザーが意識しなくても、必ずセキュリティを経由する）
③ ポリシーの一元化（IDベース統制）
GSA は Entra ID と統合されているため、
- ネットワーク制御
- アクセス制御（条件付きアクセス）
を 同じポリシー基盤で管理 できます。
「ネットワーク制御」と「認証制御」が分断されない
従来は、プロキシ・FW・CASB などでポリシーが分断されがちでしたが、これにより、
- 管理の一貫性向上
- ポリシーの重複排除
- 運用のシンプル化
が実現できます。
④ 「どこからでも同じセキュリティ」を実現
従来のオンプレ前提のプロキシでは：
- 社内ネットワーク → セキュア
- 自宅・外出先 → バラバラ
になりがちでした。
しかし GSA では：
ユーザーの場所に関係なく、同じセキュリティを適用
できます。
- 在宅勤務
- 出張先
- モバイル回線
すべて同一ポリシーで制御可能です。
GSA 経由であることを制御するための設定内容
ここまでの内容を踏まえ、実際に「GSA 経由のみ」を強制するための設定を見ていきます。
以下の公開情報で説明されている手順を キャプチャ付きで紹介していきます。
公開情報：条件付きアクセスによる準拠しているネットワークのチェックを有効にする
https://learn.microsoft.com/ja-jp/entra/global-secure-access/how-to-compliant-network?wt.mc_id=MVP_407731
基本設定
Microsoft Entra ID 用に条件付きアクセス シグナルを有効にする を ON にします。
※既定値は、OFF
この設定により、ネームドロケーション 上に All Compliant Network Locations という場所が追加されます（場所の種類＝ネットワークアクセス）
公開情報：条件付きアクセスの Global Secure Access シグナリングを有効にする
https://learn.microsoft.com/ja-jp/entra/global-secure-access/how-to-compliant-network?wt.mc_id=MVP_407731#enable-global-secure-access-signaling-for-conditional-access
条件付きアクセスポリシーの構成
以下の公開情報で説明されている手順を キャプチャ付きで紹介していきます。
公開情報：準拠ネットワークの内部にあるリソースを保護する
https://learn.microsoft.com/ja-jp/entra/global-secure-access/how-to-compliant-network?wt.mc_id=MVP_407731#protect-your-resources-behind-the-compliant-network
1．割り当て：ユーザーとグループ
対象 = すべてのユーザー
対象外 = サービスアカウント、ブレイクグラスアカウント、、ゲストユーザー、Explicit Forward Proxy (EFP) の利用者
対象外に入れるべきユーザーとは
以下の公開情報で説明されています。
1. サービスアカウント
EntraConnect などのサービスアカウントを除外に追加しておきます。
2. ブレイクグラスアカウント
「緊急アクセス用アカウント」のことです。
緊急時や障害時に備えて用意しておく「例外的に強い制御を受けない管理者アカウント」のことです。
GSA や 条件付きアクセス の設定ミスにより全ユーザーがロックアウトされるリスクを回避するため、必ず対象外としておくことが推奨されます。
公開情報：Microsoft Entra ID で緊急アクセス用アカウントを管理する
https://learn.microsoft.com/ja-jp/entra/identity/role-based-access-control/security-emergency-access?wt.mc_id=MVP_407731
3. ゲストユーザー ★私独自の視点（検証した結果、除外しておかないとダメです）
招待したゲストユーザーも、GSA の外からのアクセスとなるため、許可しておきます。
除外しておかないと、お客様を Teams に招待しても 会議に参加ができません。
4. EFP を使った通信
以下の私の記事で紹介している EFP を使った通信は、信頼されたネットワーク に含まれていないため、該当するユーザーを除外しておきます。
[GSA : Internet] Explicit Forward Proxy (Preview) の構成手順と検証レポート
https://qiita.com/carol0226/items/1ea6d0608c177923a667
[GSA: Internet] Explicit Forward Proxy (Preview) + Intune MAM BYOD シナリオを試す
https://qiita.com/carol0226/items/36a440963bbb63a8f328
2．ターゲットリソース：リソースの選択
GSA でネットワーク制御したいサービスを選択します。
ターゲットリソース（対象）= 全てのリソース
ターゲットリソース（対象外）= Microsoft Intune , Microsoft Intune Enrollment
3．ネットワーク
ネットワーク（対象）= 任意のネットワークまたは場所
ネットワーク（対象外）= すべての準拠しているネットワークの場所** ← ★これがポイント
4．条件
デバイスプラットフォーム（対象） = 任意のデバイス
デバイスプラットフォーム（対象外） = Android , iOS
デバイスプラットフォーム の選択は、必須ではありません。
私の場合は、他に iOS や Android も所持しており、それらは まだ GSA 経由の構成を行っていないからです。ここで対象外にしておかないと、スマホ経由の Outlook や Teams がブロックされてしまいます。近い将来には スマホも GSA 経由にして検証してみたいと思います・・・
5．許可 = アクセスのブロック
6．セッション
継続的アクセス評価をカスタマイズする（場所ポリシーを厳密に適用する）= OFF
※Microsoft 365 のサービスに限定している場合には ON にすることも可能です。
継続的アクセス評価をカスタマイズする（場所ポリシーを厳密に使用する）
GSA を利用中に、この設定を有効にした場合、デバイスの場所（インターネット上のアクセス元）が変更された際に、迅速に評価されるようになりますが、Microsoft 365 以外のサービスは対応していないため、ブロック対象になってしまうようです。そのような場合は、CAE は無効化してください。
公開情報：ユーザーの小さなサブセットでポリシーをテストする
https://learn.microsoft.com/ja-jp/entra/identity/conditional-access/concept-continuous-access-evaluation-strict-enforcement#step-2---test-policy-on-a-small-subset-of-users
7．ポリシーを有効化して 保存 します。
8．クラウドアプリへの接続をテストしてください。
GSA が有効な場合 = 通信が許可されます。
GSA が無効な場合 = ブロックされます。
GSA が無効時のブロック動作
以下のようにブロックされます。
公開情報：準拠しているネットワークのポリシーを試す
https://learn.microsoft.com/ja-jp/entra/global-secure-access/how-to-compliant-network?wt.mc_id=MVP_407731#try-your-compliant-network-policy
まとめ
GSA + 条件付きアクセスで「GSA 経由のみ」に制限する本質は、
通信の“入口”を強制的に一本化すること
です。
そしてその結果として：
- ゼロトラストの徹底
- トラフィックの可視化と制御
- ポリシーの一元管理
- 場所に依存しないセキュリティ
が実現されます。
つまり、「GSAを通らない通信は存在させない」ことが最大の価値です。
これは極端に言えば、「ネットワーク境界をIDベースで再定義する」 ということです。
この設計は「便利にするため」ではなく、「例外を作らないため」のものです。