mcpField
E
entra-global-secure-access

entra-global-secure-access

github.com/vinayaklattheセキュリティ17848 回インストール19 週間前に更新
リポジトリ

entra-global-secure-access について

SSE、ZTNA、またはネットワークベースの条件付きアクセスを導入するチーム向けの、Microsoft Entra Global Secure Access 計画スキルです。トラフィックプロファイル、試験導入と移行、コネクタ設計、展開時の注意点を扱います。

主な機能

  1. 01Microsoft、Internet、Private Access各プロファイルの説明
  2. 02GSAクライアントの試験導入と共存確認
  3. 03Private Accessアプリとコネクタの展開設計
  4. 04Internet Accessの監視とフィルタリングの段階導入
  5. 05ネットワークトラフィックへの条件付きアクセス適用

活用シーン

  1. 01社内アプリのVPNアクセス置き換え
  2. 02Microsoft 365サインインの送信元IP復元
  3. 03フィルタリング強制前のウェブフィルター試験
  4. 04GSA経由の拠点接続計画

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/vinayaklatthe/microsoft-security-skills --skill entra-global-secure-access

インストール後、Claude Code で/entra-global-secure-accessを入力して読み込まれたか確認します。

詳細

Microsoft Entra Global Secure Access

Global Secure Access（GSA）は、Entra コントロールプレーンを通じて提供される、Microsoft の Security Service Edge（SSE）プラットフォームです。1 つのクライアント、1 つのポリシーサーフェス、1 つの ID モデルを共有する 2 つの製品で構成されています。

  • Entra Internet Access — インターネットおよび Microsoft 365 のトラフィック向けセキュアウェブゲートウェイ（SWG）です。ネットワークフローに条件付きアクセスを適用します。
  • Entra Private Access — 従来の VPN に代わる ZTNA です。Entra 認証済みコネクタを通じて、オンプレミスおよび IaaS アプリへのアクセスを提供します（Entra App Proxy の進化版です）。

使用する場面

VPN を ZTNA に置き換える場合、アウトバウンドのインターネットトラフィックに条件付きアクセスを適用する場合、GSA クライアントからの M365 サインイン時に送信元 IP を復元する場合、または HTTPS 以外の TCP/UDP アプリへのリモートワーカーのアクセスを提供する場合に使用します。

このスキルは、一般的な CA ポリシーの作成（conditional-access-mfa）、ハイブリッドネットワークの設計（azure-network-security-design）、または競合する SSE 製品には使用しないでください。

トラフィック転送プロファイル

プロファイルキャプチャするトラフィック使用例
Microsoft プロファイルEntra ID + M365 のトラフィック送信元 IP の復元、M365 のネットワークに対する CA
Internet Access プロファイルすべてのインターネットへの送信トラフィックSWG、ウェブフィルタリング、インターネットトラフィックに対する CA
Private Access プロファイル定義済みのプライベートアプリ（オンプレミス、IaaS）ZTNA、VPN の置き換え

各プロファイルはユーザーまたはグループに割り当てます。ユーザーは 3 つすべてに同時に割り当てることができます。

アプローチ

  1. まず Microsoft プロファイルから開始します。SSE 全体をまだ購入していない場合も同様です。このプロファイルは Entra ID P1/P2 に含まれています（プレビューまたは GA の状況は地域によって異なります）。メリット：

    • 送信元 IP の復元 → 「信頼できるネットワークを必須にする」CA ポリシーが、GSA クライアントを使用するリモートユーザーに実際に適用されます。
    • CA での準拠ネットワークチェック：GSA 経由のリクエストのみが条件を満たします。

  2. GSA クライアントを少人数のグループ（50～200 人）で試験導入します。以下を検証します。

    • 主要アプリ（M365、社内 HR、SAP）へのレイテンシがベースライン + 30 ms 以下であること。
    • キャプティブポータルが引き続き動作すること（ホテルや空港の Wi-Fi）。
    • 既存の VPN クライアント、サードパーティ製エンドポイント保護、個人用ファイアウォールとの競合がないこと。

  3. VPN から一斉に切り替えるのではなく、VPN と並行して Private Access を展開します。

    • Quick Access = 「簡単な移行」向けのアプリです。サイトごとにワイルドカード FQDN/IP セグメントを設定し、Entra で事前認証します。レガシーなバックエンドサービスに使用します。
    • アプリごとのアクセス = サービスごとに Entra アプリを 1 つ定義し、FQDN、ポート、プロトコルを明示して CA を割り当てます。重要度の高いアプリ（SAP、ファイル共有、RDP ジャンプホスト）に使用します。
    • 地域またはサイトごとに、Private Access コネクタを HA ペアでデプロイします（App Proxy コネクタと同じモデルです）。

  4. Internet Access — 14 日間は監視のみで開始します。ウェブカテゴリのブロックを有効にする前に、接続先のベースラインを作成します。TLS 検査は選択したカテゴリにのみ適用します（現地の法律に従い、銀行や医療機関の利用を妨げないようにしてください）。

  5. ネットワークに対する条件付きアクセス — All Compliant Network locations を含む CA ポリシーを作成します。デバイスのコンプライアンスとユーザーリスクを組み合わせ、単に「新しいブランド名の VPN」ではなく、真の「ゼロトラスト」態勢を実現します。

  6. ブランチ／サイトの接続 — オフィス拠点では、サイトのルーター／SD-WAN から GSA への IPSec トンネルを終端します。これにより、クライアントを使用しないゲストデバイスや IoT も引き続きフィルタリングできます。

  7. VPN からの移行 — 対象アプリ群について、ユーザーの 80％ 以上が GSA Private Access で安定して利用できるようになったら、VPN コンセントレーターを廃止します。緊急時のアクセスとサードパーティが管理するデバイス向けに、1 台は維持します。

ガードレール

  • GSA クライアントとサードパーティ製の SSE／VPN クライアントは相性がよくありません。 ネットワークスタックのフックが 競合します。1 台のマシンで使用するトンネルは 1 つに絞り、大規模展開の前にパイロットを実施してください。
  • 送信元 IP の復元は、Microsoft プロファイルを経由するトラフィックでのみ機能します。 M365 に直接アクセスすると（スプリットトンネルが無効の場合）、GSA をバイパスするため、CA の「信頼されたネットワーク」は機能しません。
  • 初日から Internet Access ですべてを拒否しないでください。 まずベースラインを作成してください。財務チームが、見たこともないような SEC の URL にアクセスすることがあります。
  • TLS インスペクションには CA の配布が必要です。 Microsoft CA が信頼ストアにインストールされていないと、すべての HTTPS サイトで問題が発生します。Intune／MDM を使った展開を計画してください。
  • Private Access コネクタで必要なのは送信方向の 443 のみです。 インバウンド NAT／ファイアウォールの穴は不要です。それがこの仕組みの要点です。
  • Quick Access は通過点であり、最終形ではありません。 ワイルドカードの範囲が広いと、過剰な信頼につながります。アプリごとのアクセスに移行してください。
  • ライセンスは区分されています。 Microsoft プロファイルの機能は Entra P1／P2 に含まれますが、Internet Access と Private Access は別途追加する必要があります。対象範囲を決める前に SKU を確認してください。

よくあるアンチパターン

  • 「一斉に VPN を切り替える」 — コネクタの設定ミスが 30,000 人のユーザーに影響します。並行稼働してください。
  • 「Quick Access をすべてに、いつまでも使う」 — ワイルドカードによる信頼は、名前だけの ZTNA です。
  • 「遅延を解消するために、M365 のスプリットトンネル例外を許可する」 — CA がトラフィックを認識できなくなり、「信頼されたネットワーク」の条件が気付かれないまま不成立になります。
  • 「銀行／医療カテゴリに TLS インスペクションを適用する」 — 一部の法域では規制違反になります。対象から除外してください。
  • 「初日から Internet Access をブロックモードで展開する」 — 予期していなかった SaaS 依存関係が原因で、全体的な障害が発生します。
  • 「GSA クライアントと常時接続の永続 VPN を併用する」 — ルーティングが競合し、クライアント同士が干渉します。トンネルは 1 つに絞ってください。
  • 「コネクタを単一の AZ に配置する」 — サイトの障害がアプリの障害につながります。必ず AZ をまたいで HA ペアを構成してください。

プロンプトの例

  • 送信元 IP の復元と CA の信頼されたネットワークポリシーのために、GSA Microsoft プロファイルを 30,000 人のユーザーに展開してください。
  • Cisco AnyConnect VPN を Entra Private Access に置き換え、内部アプリ 12 個とジャンプホスト 3 台を対象にしてください。
  • 4 つのリージョンに対応する Private Access コネクタを、HA と容量のサイジングを考慮して設計してください。
  • 財務部門を対象に、Internet Access を監視モードでパイロット運用してください。ブロック可能な Web カテゴリと許可リストを特定してください。
  • Intune を通じた Microsoft CA の配布を含め、TLS インスペクションの展開を計画してください。
  • 特権ユーザーに準拠デバイスと準拠ネットワークの両方を要求する条件付きアクセス ポリシーを作成してください。
  • Meraki エッジから GSA への支店サイト IPSec を設計してください。ルーティングも含めてください。

Microsoft Learn

コメント

Markdown 対応