はじめに
企業の認証基盤として利用される Active Directory は、可用性と冗長性の確保が極めて重要です。特に、災害対策 (DR) や拠点間冗長構成を前提とした設計では、ドメインコントローラーの配置やトラフィック制御がシステム全体の安定性を左右します。
近年、Microsoft Entra Global Secure Access (GSA) を活用することで、オンプレミス環境とクラウド環境をシームレスに接続し、セキュアなアクセスを実現するケースが増えています。
しかし、GSA を冗長構成の Active Directory サイトに展開する際には、Kerberos 認証の維持、DNS 解決の設計、コネクタグループの組み合わせ、ネットワークトラフィックの効率性 など、複数の設計上のポイントを押さえる必要があります。
本記事では、東京 をメインサイト、シンガポール をサブサイトとする冗長構成を例に、GSA 展開設計のベストプラクティスを整理します。公式ドキュメントを参照しながら、設計上の落とし穴や選択肢のメリット・デメリットを比較し、実務に役立つ指針を提示します。
記事の執筆時点 (2025/12/22) の GSA の仕組みを使って評価した内容を記載しています。
将来、GSA の動作に変更が加えられた場合は、設計そのものの考え方が変わってくる可能性もありますので、あらかじめ ご承知おきください。
1. 前提事項
この環境を構成するために必要な情報です。
参照されたい方は、▶ を押してください。
前提事項 を参照するには、ココ をクリック
1-1. Active Directory が構成された環境
本記事では、メインサイト と サブサイト に それぞれ ドメインコントローラーを配置されていることを前提としています。
Active Directory ドメインサービス (ADDS) の導入
https://qiita.com/carol0226/items/b94f93adc309b5dc8ee8
２台目のドメインコントローラーの構築手順は、私の記事では用意が無いのですが、ドメインコントローラーの昇格を行う際に、以下のように 既存のドメインにドメインコントローラーを追加する を選ぶことがポイントです。
1-2. Microsoft Entra Connect が構成されていること
Microsoft Entra Connect とは（旧：Azure AD Connect）
https://qiita.com/carol0226/items/487874f07d2fe90f8e0c
Microsoft Entra Connect の冗長化は？
Entra Connect では、パスワードハッシュ同期 (PHS) と パススルー認証 (PTA) の 2 種類の認証方式があります。
冗長化を検討する際は、これらの違いを踏まえて ステージングサーバー の導入有無を判断します。
■ PHS の場合
Active Directory のアカウント情報をクラウドへ同期しているだけなので、
メインの Entra Connect が停止しても、すぐにサインインできなくなるわけではありません。
ただし、停止中にオンプレミス側でアカウント変更があっても
Entra 側には同期されないため、この点を考慮して
ステージングサーバーを導入するかを検討します。
■ PTA の場合
クラウド認証時も、必ず Entra Connect を経由してオンプレ AD が認証します。
そのため、Entra Connect がダウンするとサインインができなくなります。
PTA を利用する場合は、ステージングサーバーの導入が必須です。
Support Blog：ステージング サーバーのすゝめ
https://jpazureid.github.io/blog/azure-active-directory-connect/introduction-staging-server/
1-3. Microsoft Entra Hybrid Join が構成されていること
以下の記事を参考に Hybrid Join を構成してください。
Microsoft Entra ハイブリッド参加（旧HAADJ）を構成してみた
https://qiita.com/carol0226/items/7c16c4813e2b54a76789
1-4. Microsoft Entra Kerberos の構成（パスワードレス環境では必須）
Active Directory 環境で GSA を利用する場合、Kerberos 認証が正しく動作することが必要です。
GSA は、OS のログオン前は オフラインの状態であり、ログオン後に アクティブ になります。
これが影響し、パスワードレス (WHfB や FIDO2 セキュリティキー）によるサインインの場合は、Kerberos チケットが取得できません。
Entra Kerberos を構成することで、GSA 経由のアクセスでも Kerberos チケットを取得可能となり、ドメイン参加済みのクライアントが従来通りの認証フローを維持できます。
特に、ファイルサーバーや社内ポータルなど Kerberos 前提のアプリケーションを利用している場合、この設定がないと認証失敗が頻発するため、押さえておくべきポイントです。
公開情報：Microsoft Entra Private Access でリソースへのシングル サインオン (SSO) に Kerberos を使用する
https://learn.microsoft.com/ja-jp/entra/global-secure-access/how-to-configure-kerberos-sso?wt.mc_id=MVP_407731
Microsoft Entra Kerberos 認証 を構成し オンプレミスへ SSO する
https://qiita.com/carol0226/items/a52a54ff63c19fa957e6
1-5. GSA プライベートアクセスを構成済みであること
以下の記事を参考に GSA プライベートアクセスを構成してください。
Microsoft Entra Global Secure Access の全体像
https://qiita.com/carol0226/items/29cba6c32a22893a1349
[GSA] グローバルセキュアアクセスクライアントの導入手順
https://qiita.com/carol0226/items/8e30fc6caf36c83894dc
[GSA] プライベートネットワークコネクタの導入手順
https://qiita.com/carol0226/items/3f2572dc2169abf26ca4
2．導入設計ベストプラクティス
本章で紹介する内容を考慮に入れた設計を行うことで、災害対策 (DR) や 可用性確保が可能になります。
※評価検証は Azure を使い 東日本リージョンと、東南アジアリージョン を 活用して実施しています。
評価検証で使った 構成図
凡例
- 水色 = GSA クライアント と 接続場所（拠点、日本国内、海外）
- 黄緑 = プライベートネットワークコネクタ (PNC)
- 桃色 = ドメインコントローラー (DC)
- 橙色 = 基幹系システム（Act-Act 構成：主系）
- 青色 = 基幹系システム（Act-Act 構成：副系）
評価検証で使った AD 構成
- シングルフォレスト、シングルドメイン
- ドメイン名：avd.server-on.net
- ドメインコントローラー(DC)：２台
評価検証で使ったネットワーク構成
| # | メインサイト | サブサイト | 拠点 |
|---|---|---|---|
| 場所 | 東京 | シンガポール | 日本国内の 物理拠点 |
| ネットワーク | 10.10.0.0/16 | 10.20.0.0/16 | 192.168.100.0/24 |
| DNS サーバー | 10.10.10.5 | 10.20.10.4 | 192.168.100.1 |
| AD サーバー名 | AZ-NOGUCHIS-ADS .avd.server-on.net |
AD02 .avd.server-on.net |
なし |
| AD サイト名 | JapanEast | SouthEastAsia | JapanEast |
| GSA プライベート コネクタ (PNC) |
GSA .avd.server-on.net |
GSA02 .avd.server-on.net |
なし |
想定シナリオ
メインサイト、サブサイト、拠点 は VPN 回線 で接続されています。
各サイトに ドメインコントローラー と プライベートコネクタ が最低１台ずつ 配置されています。
PC には、GSA クライアント がインストールされており、社内外を行き来します。
つまり、拠点の 社内 LAN に接続して利用したり、社外に持ち出して GSA プライベートアクセス を利用する ということを想定しています。
2-1. Active Directory サイトとサービス
※この構成は、他の構成と組み合わせて、検証済みです。
ドメインコントローラーのサイト設計を GSA と組み合わせて構成する方法についてです。
- 通常時はメインサイトのドメインコントローラーへトラフィックを転送
- DR 時にはサブサイトへ自動切替
GSA プライベートアクセス経由の通信は NAT により ソース IP が 合成 IP (6.6.0.0/16) に変換されるため、Active Directory サイトによる DC 参照先の判定に影響します。
そのため、6.6.0.0/16 をサブネットに追加し、メインサイトに割り当てます。
公開情報：Active Directory サイトとサービスの概要
https://learn.microsoft.com/ja-jp/security-updates/planningandimplementationguide/19871944?wt.mc_id=MVP_407731
このように構成しておくことで、GSA 経由の ドメインコントローラーへのアクセスは、メインサイトが優先されるようになります。
参考：合成 IP（6.6.0.0/16）について
GSA のプライベート DNS を利用した場合、クライアントが内部リソースの FQDN を名前解決すると、実際のサーバー IP アドレスではなく 6.6.x.x の IPアドレス が返されます。
このアドレスは、“合成 IP（Synthetic IP）” と呼ばれています。
これは、アプリケーションの通信を 必ず GSA エッジ経由にルーティングするための仕組みです。
アプリケーションはこの合成 IP に向けて通信しますが、実際には GSA によって内部ネットワークの本来の IP へ転送されます。
一般的な業務アプリでは問題ありませんが、下記のようなケースでは注意が必要です。
- アプリケーションが「実 IP アドレス前提」で動作している
- ファイアウォールや ACL が “クライアント → サーバーの本来の IP” を期待している
- IP アドレスをログ解析やアクセス元制御に利用している
多くの環境ではそのまま利用できますが、IP アドレスを直接扱うアプリケーションがある場合は、事前に動作確認を行うことをお勧めします。
公開情報：Microsoft Entra プライベート DNS について
https://learn.microsoft.com/ja-jp/entra/global-secure-access/concept-private-name-resolution?wt.mc_id=MVP_407731
（上記の公開情報より抜粋）
- ユーザーは、 app.contoso.comの DNS クエリを要求します。 ローカルにキャッシュされていない場合、DNS クエリは GSA エッジの DNS プロキシに送信されます。
- DNS プロキシは、キャッシュから応答するか、クイック アクセスで定義されているコネクタ グループにクエリを転送します。
- コネクタ サーバーは、オペレーティング システム レベルで構成された DNS サーバーに DNS クエリを送信します。
- DNS プロキシは、内部 IP を使用してクライアントに応答します。 クライアントは内部 IP アドレスを格納し、合成 IP をアプリケーションに返します。
なぜ 合成 IP が使われているのか
合成 IP が使われる理由は、単なる「IP アドレス衝突回避」に留まりません。
GSA の設計では、以下のような複数の要因が重なっています。
-
クライアントから内部リソースへの通信を必ず GSA Edge に流すため（強制トンネル化）
実 IP を返すと OS のルーティングや VPN/LAN でバイパスされる可能性があり、
これを防ぐために “存在しない” 合成 IP を返して GSA に強制的に中継させます。 -
自宅や支店のプライベート IP と企業ネットワークの IP が重複していても問題なく通信できるようにするため
-
内部リソースの実 IP をクライアントに晒さない（Zero Trust 的なセキュリティ向上）
-
どのネットワーク（社内LAN／自宅／カフェ／ホテル／モバイル回線）でも一貫した動作をさせるため
合成 IP に統一することで、クライアント OS のルーティング設定や上位ネットワーク構成の差異を GSA が吸収できるようになります。
これらの理由から、GSA は内部 IP の代わりに “存在しない” 合成 IP（6.6.x.x）を DNS 応答として返し、実通信は GSA Edge → Connector → 内部リソース の経路で処理されます。
2-2. コネクタグループ
コネクタグループをどう構成するかで、トラフィック制御の柔軟性が変わります。
- 単一グループにまとめるとロードバランスが可能
- サイトごとに分けると経路制御が明確化
しかしながら、現時点では 非常に制約が多い状況であり、制約をしっかりと理解しておかないと、コネクタグループの設計は ままなりません。その点について 説明していきます。
2-2-1. 国／地域
コネクタグループ を構成する前に、重要な制約事項を理解しておく必要があります。
- テナントの既定の Geo 場所によって、Default コネクタグループの 国／地域 が決まっており変更できません
- クイックアクセスでは、上記の 国／地域 しか利用できません
- プライベート DNS は、クイックアクセス でしか利用できません
→ つまり、プライベート DNS 機能 は、固定された 国／地域 を使う以外に選択肢はありません。
重要
私の身の回りの各種テナントの状況（手元、同僚、お客様など）を見ると 日本国内でサインアップしたテナントであっても、国／地域 が、日本 の場合と アジア の場合の２通りがありました。
※これは、私の勘ですが テナントをサインアップした時期による違いのような気がしています。
まずは、運用に利用する環境の Default コネクタグループの 国／地域 を把握しておくことが重要です。
注意点
上記の制約を無視して、対応していない 国／地域 を コネクタグループに設定しようとすると、以下のエラーが発生して 構成することができません。
公開情報：概要
https://learn.microsoft.com/ja-jp/entra/global-secure-access/how-to-enable-multi-geo?wt.mc_id=MVP_407731#overview
（上記の公開情報より抜粋）
公開情報：最も近いアプリケーション プロキシ クラウド サービスを使用するようにコネクタ グループを最適化する
https://learn.microsoft.com/ja-jp/entra/identity/app-proxy/application-proxy-network-topology?wt.mc_id=MVP_407731#optimize-connector-groups-to-use-closest-application-proxy-cloud-service
（上記の公開情報より抜粋）
国／地域 の種類 について
国／地域 は、コネクタグループを作成する際に選べますが、現時点 (2025/12/22) で私のテナントでは、北米、ヨーロッパ、オーストラリア、アジア、日本 の５箇所しか選べませんでした。
2-2-2. 複数地域機能 (Multi-Geo コネクタ)
複数地域機能を利用することで、アプリごとのアクセス（エンタープライズアプリ）に限って、国／地域 を指定することが可能になっています。
公開情報：Microsoft Entra Private Access の複数地域機能を有効にする
https://learn.microsoft.com/ja-jp/entra/global-secure-access/how-to-enable-multi-geo?wt.mc_id=MVP_407731#enable-multi-geo-capability
（上記の公開情報より抜粋）
上記の注意事項にも記載がありますが、Multi Geo コネクタは、クイックアクセスには使用できません。
前章でしたように、クイックアクセス には、テナントに定められた 国／地域 を使用するしかありません。
2-2-3. コネクタグループの制約を踏まえた DR の設計とは？
前章までに説明した、重い制約を踏まえて DR を設計する必要があります。
- プライベート DNS は、クイックアクセス を使用する必要がある
→ Active Directory のドメインの利用には、プライベート DNS が必須です。 - Multi-Geo の利用は、アプリごとのアクセス を使用する必要がある
→ ネットワークセグメントのトラフィックフローを最適化するには、アプリごとのアクセスが必要です。
設計段階で「どのトラフィックをどこに流すか」を明示的に決めておくことが重要です。
テナントの 国／地域 の違いによって、以下のような 構成例が考えられます。
テナントの 国／地域 が ”日本” だった場合の構成例
| # | メインサイト | サブサイト | 国内拠点 |
|---|---|---|---|
| コネクタグループ名 | Default | Backup | Default |
| 国／地域 | 日本（固定） | 任意の場所 ※日本 or アジア |
任意の場所 ※日本 が推奨 |
| データセンター の場所 |
東京 | シンガポール | 国内拠点 |
| 名前解決を行う場所 | 〇 | ||
| コネクタの割り当て | GSA.avd.server-on.net <※３台以上を推奨> |
GSA02.avd.server-on.net <※３台以上を推奨> |
未割当 |
テナントの 国／地域 が ”アジア” だった場合の構成例
| # | メインサイト | サブサイト | 国内拠点 |
|---|---|---|---|
| コネクタグループ名 | Active | Default | Active |
| 国／地域 | 任意の場所 ※日本 を推奨 |
アジア（固定） | 任意の場所 ※日本 を推奨 |
| データセンターの場所 | 東京 | シンガポール | 国内拠点 |
| 名前解決を行う場所 | 〇 | ||
| コネクタの割り当て | GSA.avd.server-on.net <※３台以上を推奨> |
GSA02.avd.server-on.net <※３台以上を推奨> |
未割当 |
プライベートコネクタ の可用性
上記のキャプチャは PoC なので 各サイトに コネクタが １台ずつしかありませんが、運用を考慮すると 各サイトに３台以上のコネクタを配置することが、ベストプラクティス であると Microsoft 社から聞きました。
※公式ドキュメントでは「2 台以上」が HA の最低要件ですが、
実運用では自動メンテナンスや負荷分散を考慮し、3 台以上を Microsoft から推奨されるケースが多いとのことです。
公開情報：コネクタの更新
https://learn.microsoft.com/ja-jp/entra/global-secure-access/concept-connectors?wt.mc_id=MVP_407731#connector-updates
公開情報：Microsoft Entra プライベート ネットワーク コネクタ グループ
https://learn.microsoft.com/ja-jp/entra/global-secure-access/concept-connector-groups?wt.mc_id=MVP_407731
2-3. DNS のための クイックアクセス設定
※この構成は、他の構成と組み合わせて、検証済みです。
通常、クイックアクセスは データセンターのネットワーク全体を許可するなど、おおざっぱに接続をさせたい場合に使う機能です。そしてアプリごとのアクセスは、よりきめ細かな設定を行う場合に使います。
しかし、ドメインコントローラーの名前解決を行えるようにする「プライベート DNS」の機能は クイックアクセス でしか使えません。GSA × AD 連携で最も重要なポイントの一つです。
名前解決以外の通信（IP アドレスベースの通信）を、クイックアクセス で構成しても、Active Directory の通信としては問題はありませんが、DR の設計 を考慮した場合には、後述する「アプリごとのアクセス」で構成ことを考える必要が出てきます。
| 項目 | クイックアクセス | アプリごとのアクセス |
|---|---|---|
| 主な用途 | 広範囲のネットワークや DNS をまとめて許可 | サイトごとの詳細な経路制御、セグメント単位の通信制御 |
| 役割 | プライベート DNS が動作する唯一の場所 | 個別アプリ・ネットワークセグメントへの接続制御 |
| 柔軟性 | 低い（広い範囲を一括許可する設計） | 高い（詳細な制御が可能） |
| Geo の制約 | あり（Default と同じ Geo でなければ設定不可） | なし（任意の Geo のコネクタを選択可能） |
| 典型的な用途 | - DNS 解決用（AD / Kerberos に必須） - 大規模ネットワークの簡易許可 |
- メインサイト／サブサイトへの最適経路分離 - DC やファイルサーバーなどの明示的ルーティング |
| AD × GSA で必要か | 必須（DNS が クイックアクセス でしか動作しないため） | サイト分離を行う場合に必須 |
| 制御粒度 | 粗い | 細かい（セグメント単位） |
次章では、DNS のための クイックアクセス を構成していきます。
後述する 2-3-1 と 2-3-2 の設定は、GSA で Active Directory を利用するためには、マスト な設定になります。これを行わないと、ドメイン内の名前解決や Kerberos 認証 が出来なくなります。
手順の流れ（画面遷移）は、以下の記事も参考にしてください。
[GSA:Private] クイックアクセス を構成する
https://qiita.com/carol0226/items/0ebd719f3e7ff805faa9
2-3-1. アプリケーションセグメント タブ
ドメイン名 (FQDN) に対して、DNS のトラフィック（TCP/UDP Port:53) を登録します。
ドメイン名に アスタリスク（＊）があるものと無いもので２行追加してください。
2-3-2. プライベート DNS タブ
プライベート DNS を有効にする（緑枠）
ドメインコントローラーや社内アプリケーションへのアクセスでは、正しい名前解決が必須です。GSA の「プライベート DNS」機能を利用することで、ドメイン名を解決できるようになります。
DNS サフィックス（水色枠）
ドメイン名を入力します。
公開情報：プライベート DNS サフィックスを追加する
https://learn.microsoft.com/ja-jp/entra/global-secure-access/how-to-configure-quick-access?wt.mc_id=MVP_407731#add-private-dns-suffixes
2-3-3. クライアント PC の DNS サフィックスリスト
既定では ホスト名 のみの名前解決に際して、xxxx.globalsecureaccess.local がサフィックスとして付与されますが、これに依存すると一部アプリケーションが動作しなくなるケースがあります。例えば、ホスト名だけでアクセスする設計のアプリでは、意図しないサフィックスが付与されることで認証や接続が失敗します。
そのため、ポリシーで正しい DNS サフィックスを配布し、クライアントがドメイン名を正しく解決できるようにすることが重要です。
以下の図のように、１行目に ドメイン名 (avd.server-on.net) を追加することで対応します。
以下のように GPO で設定することも可能であり、テスト済みです。
コンピューターの構成－管理用テンプレート－ネットワーク－DNS クライアント－DNS サフィックス検索一覧
本カスタマイズが必要となる理由
（GSA が接続されていない場合）
既定では 以下のように、プライマリ DNS サフィックス が利用されるようになっています。
この場合、ホスト名（例：gsa）のみの名前解決を行うと、プライマリ DNS サフィックス (avd.server-on.net) を付加した FQDN (gsa.avd.server-on.net で名前解決が行われます。
以下のような結果が返されます（プライマリ DNS が付加）
（GSA が接続された状態）
自動的に 以下の設定に切り替わるようになっています。
この場合、ホスト名（例：gsa）のみの名前解決を行うと、DNS サフィックスリスト(xxxx.globalsecureaccess.local) を付加した FQDN (gsa.xxxx.globalsecureaccess.local で名前解決が行われます。
以下のような結果が返されます（DNS サフィックスリスト の１番目 が付加）
2-3-4. アプリごとのアクセス
※この構成は、他の構成と組み合わせて、検証済みです。
メインサイトとサブサイトを分けて構成する場合、DNS の参照先だけをクイックアクセスに残す ことが ベストプラクティス です。前章でも解説しましたが、プライベート DNS は、クイックアクセスしか使えないためです。
各サイトへのアクセス制御は、アプリごとのアクセス を使います。
これにより、各サイトごとに最適な経路を明示することができます。
テナントの 国／地域 が ”日本” だった場合の構成例
| # | メインサイト | サブサイト |
|---|---|---|
| コネクタグループ | Default - 日本 | Backup - アジア |
| セグメント | 10.10.0.0/16 | 10.20.0.0/16 |
テナントの 国／地域 が ”アジア” だった場合の構成例
| # | メインサイト | サブサイト |
|---|---|---|
| コネクタグループ | Active - 日本 | Default - アジア |
| セグメント | 10.10.0.0/16 | 10.20.0.0/16 |
メインサイト
サブサイト
公開情報：グローバル セキュア アクセス アプリケーションを使用してアプリごとのアクセスを構成する方法
https://learn.microsoft.com/ja-jp/entra/global-secure-access/how-to-configure-per-app-access?wt.mc_id=MVP_407731
2-3-5. オンプレミス アプリケーションに条件付きアクセス/MFA を適用する
※まだ、この機能は 検証できていません。
この章の構成をしなくても、前章までの構成で、Active Directory x GSA は動きます。
必須ではありませんが、セキュリティ強化の観点からは推奨される機能です。特に、管理者向けポータルや機密性の高いアプリケーションに対して MFA を適用することで、社外からの不正アクセスリスクを大幅に低減することが期待できます。
公開情報：Active Directory ドメイン コントローラー用に Microsoft Entra Private Access を構成する (プレビュー)
https://learn.microsoft.com/ja-jp/entra/global-secure-access/how-to-configure-domain-controllers?wt.mc_id=MVP_407731
2-3-6. インテリジェントローカルアクセス
※この構成は、他の構成と組み合わせて、検証済みです。
AD ドメイン参加 の PC の場合、社内と社外を行き来するシーンが多いと思います。そのような場面で活かせる機能です。
- 社内 LAN では余計な遅延を回避
- 社外からはセキュアに GSA 経由で接続
という二重のメリットが得られます。
「AD および、プライベートコネクタ と 社内 LAN 回線で結ばれた拠点」のネットワークアドレスを追加していくことで、GSA クライアントが そのネットワーク帯に接続された場合は、LAN 回線が優先されるようになります。
公開情報：インテリジェント ローカル アクセスを有効にする (プレビュー)
https://learn.microsoft.com/ja-jp/entra/global-secure-access/enable-intelligent-local-access?wt.mc_id=MVP_407731
3. 参考情報
Active Directory と直接関係ありませんが、社内 と 社外 を行き来する端末であることを想定した場合に、考慮しておいた方が良いと思われる情報です。
3-1. プロキシサーバーの 撤廃を検討する
一般的に、プロキシサーバーは 社内 PC からインターネットへのアクセス制御で用いられています。（サイト制限、ログ記録など）
GSA インターネットアクセス を利用すると、Web フィルタリング や、脅威インテリジェンス、TLS インスペクション、ログ記録 などのセキュリティ機能を利用することができるようになります。
GSA を常に有効にして利用することで、社内／社外 を一元化したインターネットセキュリティポリシーを適用することが可能となり、社内プロキシサーバーの代替にできるかもしれません。
補足
インターネットアクセス は、ライセンスが必要ですし、社内プロキシを撤廃できない事情もあると思います。そのような場合は、後述する プロキシ除外設定 や ローカルブレイクアウト の利用を検討してみてください。
3-2. プロキシサーバー利用時 に必要な プロキシ除外設定
自社データセンター内に プロキシサーバー を採用しており、社外でも GSA プライベートアクセス 経由で、プロキシを参照させたい場合は、以下の記事を参考にしてください。私の研究の成果が詰まった記事になっています。
[GSA] グローバルセキュアアクセスクライアント用のプロキシ除外設定
https://qiita.com/carol0226/items/df821a681986b1020ab3
3-3. Microsoft 365 通信の ローカルブレイクアウト
ローカルブレイクアウトの目的
- Microsoft 365 は最適化された先（Microsoft のフロントドア）に最短で届けるべき
- プロキシ経由にすると「遅延」「帯域集中」が発生しやすい
- Microsoft 公式も “M365 トラフィックはプロキシしない方がよい” と明示している
社内プロキシは使う必要があるが、Microsoft 365 の通信は プロキシを使いたくない・・・という場合は、PAC ファイルを作成し、プロキシの対象から除外することも検討しましょう。
ですが、GSA 用の 除外設定と Microsoft365 用の除外設定を抱き合わせて構成する必要があって、ちょっと大変です。このあたりは、今後 研究の成果を記事にしていければと思っています。
公開情報：Microsoft 365 の URL と IP アドレスの範囲
https://learn.microsoft.com/ja-jp/microsoft-365/enterprise/urls-and-ip-address-ranges
公開情報：重要な Microsoft 365 トラフィックの直接ルーティングに PAC ファイルを使用する
https://learn.microsoft.com/ja-jp/microsoft-365/enterprise/managing-office-365-endpoints?view=o365-worldwide#use-a-pac-file-for-direct-routing-of-vital-microsoft-365-traffic
PowerShell Gallary：Get-PacFile
https://www.powershellgallery.com/packages/Get-PacFile/1.0.4
Support Blog：ローカル エリア ネットワーク (LAN) の設定について
https://microsoft.github.io/jpbrowsers/internet-explorer-microsoft-edge/LAN-Settings/
4. BCP 発動時の切替方法
BCP 発動時の 切替手順 を説明します。
4-1. テナントの 国／地域 が ”日本” だった場合の手順
正常時
メインサイト全滅時の 切替手順
ちょっと、違和感を覚えるかもしれませんが、以下の手順で切り替えます。
- アプリごとのアクセス (10.20.0.0/16) に割り当てるコネクタグループを Default - 日本 に変更します。
- サブサイト（シンガポール）のプライベートコネクタ を Default - 日本 に変更します。
この切替を行っても、すでに GSA クライアントが シンガポールのコネクタを利用していた場合でも、切断はされないので、安心してください。
※利用中のコネクションは 継続される動作となっているようです。
なぜ、このような切替になるのか？
- Geo は GSA のアクセスポイントの位置であり、企業の DC の位置を意味しない
- Geo はテナントごとに固定のため、BCP 時も変えられない
まず、メインサイト（東京）側 のデータセンターが全滅した場合、サブサイト（シンガポール）への IP アドレスベースのアクセスは生き残ります。
そのとき、クイックアクセス には Default - 日本 が割り当てられているため、名前解決ができなくなります。
普通に考えると、クイックアクセス に割り当てられている コネクタグループを Backup - アジア に切り替えれば良さそうに見えますが、GSA の制約によって その切り替えができないのです。
そのため、本章で紹介した手順で切り替えることによって、名前解決 と IP アクセスの両方を メインサイト に切り替えるようにしています。
分かりづらい理由
メインサイト（東京）側のデータセンターが全滅している時に、サブサイト（シンガポール）のコネクタを Default - 日本 に切り替えるのは違和感があると思います。しかし、顧客のメインサイト の データセンターが止まっていても、 GSA 接続先 (Geo 日本) は稼働しています。
プライベート DNS は、Geo を変更できない仕様なので、それを使い続けることを前提に設計するしかないのです。
注意点
なお、日本沈没のようなことが起こり、自社の日本データセンター と GSA の 日本 Geo が両方ダウンするようなことがあった場合は、名前解決は あきらめなければならなくなる可能性があります。
4-2. テナントの 国／地域 が ”アジア” だった場合の手順
正常時
メインサイト全滅
メインサイト（東京）が全滅した場合は、メインサイトへの疎通が失われます。
サブサイト（シンガポール）への疎通や名前解決は 引き続き提供されます。
なお、VPN 経由で サブサイト経由で メインサイトへのアクセスが出来ることを期待して、以下の切替手順を実施します。
切替手順
以下の手順で切り替えます。
- アプリごとのアクセス (10.10.0.0/16) に割り当てる コネクタグループを Default - アジア に変更します。
サブサイト全滅
サブサイト（シンガポール）が全滅した場合は、名前解決が出来なくなるため、以下の切替を実施します。
切替手順
以下の手順で切り替えます。
- アプリごとのアクセス (10.10.0.0/16) に割り当てる コネクタグループを Default - アジア に変更します。
- メインサイト（東京）のプライベートコネクタ を Default - アジア に変更します。
5. 候補の組み合わせパターン
前章までの構成で、DR 設計 および BCP 発動時の切替方法まで紹介しました。
実は、前章までに紹介した設定は、以下の ３つうちの パターン１の構成でした。
本章では、異なる方法の紹介と、メリット・デメリット についてまとめています。
-
パターン１：
ネットワーク効率が最適であり、メインサイトの全滅時でも IPベースのアクセスが残る点でバランスが良いため、これを元に手順として説明することにしました。
※両方のサイトが同じくらいアクティブに利用される環境でも、パターン１が良いように思います。
-
パターン２：
メインサイトへのアクセスに寄せており、ネットワーク効率はベター。メインサイト全滅時の影響が大きいため、パターン１の方が良いと考えました。
-
パターン３：
何といっても、切替なしで運転できることが最大のメリットです。しかし、通常時のトラフィックの半分が サブサイト のコネクタを経由して、VPN 回線を通って、メインサイト に到達することになるため、回線遅延の影響と VPN 回線のトラフィック増加（コストも増加？）という悩ましい課題が生じます。
テナントの 国／地域 が ”日本” だった場合
| # | パターン１ 前章までに紹介 |
パターン２ | パターン３ |
|---|---|---|---|
| コネクタグループ Default |
GSA | GSA | GSA GSA02 |
| コネクタグループ Backup |
GSA02 | GSA02 | 未使用 |
| メインサイト への経路 |
日本 Geo | 日本 Geo | 1. 日本 Geo 2. アジア Geo -> シンガ DC -> VPN 回線 ※50 対 50 |
| サブサイト への経路 |
アジア Geo | 日本 Geo -> 東京 DC -> VPN 回線 |
1.日本 Geo -> 東京 DC -> VPN 回線 2. アジア Geo ※50 対 50 |
| プライベート DNS | コネクタグループ Default - 日本 |
コネクタグループ Default - 日本 |
コネクタグループ Default - 日本 |
| エンタープライズアプリ 10.10.0.0/16 |
コネクタグループ Default - 日本 |
コネクタグループ Default - 日本 |
コネクタグループ Default - 日本 |
| エンタープライズアプリ 10.20.0.0/16 |
コネクタグループ Backup - アジア |
コネクタグループ Default - 日本 |
コネクタグループ Default - 日本 |
| メインサイト 全滅時 |
名前解決できない IP ベースのアクセスは可 |
全滅 | 継続利用可能 |
| BCP 切替方法 | （手動） - 10.20.0.0/16 を Default に変更 - サブサイトの PNC を Default に変更 |
（手動） - サブサイトの PNC を Default に変更 |
（自動） |
| VPN 回線トラフィック | ほぼ無し | サブサイト行きのトラフィックが メインサイト経由 | メインサイト行きの 50% が サブサイト経由 サブサイト行きの 50% が メインサイト経由 |
テナントの 国／地域 が ”アジア” だった場合
| # | パターン１ 前章までに紹介 |
パターン２ | パターン３ |
|---|---|---|---|
| コネクタグループ Active |
GSA | GSA | 両サイトに、 追加コネクタが必要 |
| コネクタグループ Default |
GSA02 | GSA02 | GSA GSA02 |
| メインサイト への経路 |
日本 Geo | 日本 Geo | 1. 日本 Geo 2. アジア Geo -> シンガ DC -> VPN 回線 ※50 対 50 |
| サブサイト への経路 |
アジア Geo | 日本 Geo -> 東京 DC -> VPN 回線 |
1. 日本 Geo -> 東京 DC -> VPN 回線 2. アジア Geo ※50 対 50 |
| プライベート DNS | コネクタ グループ Default - アジア |
コネクタ グループ Default - アジア |
コネクタ グループ Default - アジア |
| エンタープライズアプリ 10.10.0.0/16 |
コネクタ グループ Active - 日本 |
コネクタ グループ Active - 日本 |
コネクタ グループ Active - 日本 |
| エンタープライズアプリ 10.20.0.0/16 |
コネクタ グループ Default - アジア |
コネクタ グループ Active - 日本 |
コネクタ グループ Active - 日本 |
| メインサイト 全滅時 |
名前解決と サブサイトは 通信継続 |
全滅 | 継続利用可能 |
| BCP 切替方法 | （手動） - 10.10.0.0/16 を Default に変更 |
（手動） - 10.10.0.0/16 を Default に変更 - 10.20.0.0/16 を Default に変更 |
（自動） |
| VPN 回線トラフィック | ほぼ無し | サブサイト行きのトラフィックが メインサイト経由 | メインサイト行きの 50% が サブサイト経由 サブサイト行きの 50% が メインサイト経由 |
パターン２ と ３ の構成図については、後日 公開予定です。
表の設定値をもとに構成していただければ、動作を確認することが可能ですので、ぜひ 各パターン に切り替えて、実際の動作を比較してみていただけると宜しいかと思います。
6. まとめ
本記事では、Active Directory のサイト冗長構成に Microsoft Entra Global Secure Access（GSA）を安全かつ効率的に統合するための設計ポイントを整理しました。
GSA × AD を正しく動作させるためには、次の 3 つの領域をバランス良く設計することが重要です。
1. 認証・名前解決レイヤーの安定化
- クイックアクセス でしか動作しない プライベート DNS の制約を理解する
- 合成 IP（6.6.x.x）による 強制トンネル化の仕組みを把握する
- パスワードレス環境では Entra Kerberos を導入して Kerberos 認証を維持
2. ネットワーク経路の最適化
- コネクタグループ で サイトごとの経路制御を明確化
- AD サイトに 合成 IP (6.6.0.0/16) を登録し DC 参照先を安定化
- 社内 LAN にいるときは インテリジェントローカルアクセス で最短経路
3. DR・障害時を “最初から織り込む” 設計
- GSA の Geo は変更できない前提で、名前解決の生死ラインを理解する
- 障害時にどのパターンで切り替わるかを 設計段階で決めておく
結論
これらのポイントを押さえて設計することで、
✔ AD と GSA の相互依存を理解した安全な構成
✔ サイト障害時にも破綻しない可用性
✔ 社内外で快適に利用できるユーザー体験
を同時に実現できます。
GSA × AD の組み合わせは制約も多いですが、設計原理を理解して、可用性・セキュリティ・運用性のバランスが取れた最適なハイブリッドアクセス基盤の構築を目指しましょう！