[GSA:Private] プライベートネットワークコネクタの導入手順

Last updated at 2026-01-13Posted at 2025-09-15

プライベートネットワークコネクタとは？

プライベートネットワークコネクタは、下図のような Microsoft Entra Global Secure Access (略：GSA) を実現するための一部の構成要素です。

本記事では、プライベートネットワークコネクタのことを省略して コネクタ と表記します。

コネクタは、GSA を経由して、組織のプライベートなネットワークに接続させたい場合に、ネットワーク上の任意の Windows Server OS 上に導入が必要です。
このネットワークは、オンプレミスの物理ネットワークでも、クラウド上の仮想ネットワークでも構いません。

下図の赤丸の箇所が、コネクタであり、プライベートなネットワークを GSA に接続するためのハブとなるコンポーネントです。

GSA について
以下の記事が全体像の説明と詳細記事へジャンプできるサマリーになっています。

Microsoft Entra Global Secure Access の全体像
https://qiita.com/carol0226/items/29cba6c32a22893a1349

Marketplace からも展開可能
なお、コネクタを導入する環境がクラウドサービスの仮想ネットワーク上であれば、Marketplace から構築済みのイメージをデプロイすることもできます。
最終章で解説していますので、参照してみてください。

コネクタのシステム要件

動作環境は、クラウド／オンプレミス（仮想・物理）を問いません。
→　次章の手順紹介では、Azure 仮想ネットワークを使っています。
　
Windows Server 2016 以降を導入済みのサーバー
かつ、.NET Framework 4.7.1 以上が導入されていること
公開情報：Windows サーバー
https://learn.microsoft.com/ja-jp/entra/global-secure-access/how-to-configure-connectors?wt.mc_id=MVP_407731#windows-server
→　次章の手順紹介では、Windows Server 2022 を使っています。
　
スペックは、CPU: 4 CPU コア以上、メモリ: 8 GiB 以上
公開情報：仕様とサイズ要件
https://learn.microsoft.com/ja-jp/entra/global-secure-access/concept-connectors?wt.mc_id=MVP_407731#specifications-and-sizing-requirements
→　次章の手順紹介では、2 CPU , 8 GiB を使って検証します（要件以下だけど勘弁して）
　
OS には TLS 1.2 が導入されている必要があります
公開情報：前提条件（TLS 1.2）
https://learn.microsoft.com/ja-jp/entra/global-secure-access/how-to-configure-connectors?wt.mc_id=MVP_407731#transport-layer-security-tls-requirements
→　次章の手順紹介で、TLS 1.2 の導入手順についても触れます。
　
スタンドアロン（ワークグループのサーバー）でも動作しますが、ドメインに参加することが推奨です。
公開情報：ドメイン
https://learn.microsoft.com/ja-jp/entra/global-secure-access/concept-connectors?wt.mc_id=MVP_407731#domain-joining
→　次章の手順紹介では、Azure 上に展開済みの Active Directory ドメインへ参加させています。
　
インターネット経由で GSA のアクセスポイント (POP) へ HTTPS アウトバウンド接続が有効であること
※URL フィルタやテナント制限が実施されていると利用が出来ない場合があります。
公開情報：通信要件
https://learn.microsoft.com/ja-jp/entra/global-secure-access/how-to-configure-connectors?wt.mc_id=MVP_407731#prepare-your-on-premises-environment
→　本記事では、Azure VM を使用しており、アウトバウンド通信は、すべて許可されています。
　
コネクタが設置された場所と、接続先のホストが離れた場所に設置しない方が良い
例1：コネクタが Azure 上にあるが、接続先のサーバがオンプレミス上にある
例2：コネクタが大阪サイトにあるが、接続先のサーバが東京サイトにある
公開情報：コネクタサーバーの推奨事項
https://learn.microsoft.com/ja-jp/entra/global-secure-access/how-to-configure-connectors?wt.mc_id=MVP_407731#recommendations-for-the-connector-server
→　本記事では、コネクタと接続先のサーバーは同じ Azure 仮想ネットワーク上に配置しています。

ネットワークデザイン（コネクタグループ）

コネクタは、PoC であれば１台だけ用意すれば動作します。PoC の人は本章は SKIP して、次章へ進んでください。※ その場合、コネクタグループは、Default Connector Group が使われます。

１つのコネクタグループ

１つのコネクタグループに、複数のコネクタを登録して運用すると、冗長性や、負荷分散　の機能を全自動で実現します。

単一サイト内で１つのコネクタグループ
冗長性や負荷分散が確保され、全自動で切り替わります。
複数サイト上のコネクタを１つのコネクタグループに束ねる
DR を踏まえた配置には不向き。
メインサイト（例：東京）と DRサイト（例：大阪）間が WAN で結ばれていれば、DR 切り替えも自動で切り替わります。
しかし、トラフィックが均等に配分されるため、通常利用時も DR サイトにもトラフィックが向きます。
その結果、DR サイトとメインサイト間の WAN 回線のトラフィックが増大します。
通信の応答速度や、WAN 回線のコストに悪影響が出る恐れがあります。
→　前章の コネクタサーバーの推奨事項 で書いた通りコネクタと接続先が離れた状態になってしまいます。

複数のコネクタグループ

複数のコネクタグループを用意して実現できることは、接続元・接続先の組み合わせごとにグループを用意することで、トラフィックフローを制御できることです。

アプリごとにコネクタグループを用意する
RDS サーバーへの接続は、コネクタグループ A を使い、基幹系業務アプリへの接続は、コネクタグループ B を使う
サイトごとにコネクタグループを用意する
本社への接続は、コネクタグループ A を使い、北海道支社への接続は、コネクタグループ B、九州支社への接続は、コネクタグループ C を使う

公開情報：Microsoft Entra プライベートネットワークコネクタグループについて
https://learn.microsoft.com/ja-jp/entra/global-secure-access/concept-connector-groups?wt.mc_id=MVP_407731

注意点
コネクタグループ A が使えない時に、コネクタグループ B へフェイルオーバーするような機能は備えていない点に注意が必要です。

たとえば、コネクタグループ A に東京のコネクタ、コネクタグループ B に大阪のコネクタを配置しておく。
通常時は、東京のみを優先で使い、東京が使えない場合だけ、大阪を使うというような 優先制御はできせん。

もし、DR において場所の制御を行いたい場合は、災害発生時に手動でアプリのコネクタグループの割り当てを変更することで、実現は可能です。

DR 手動切り替えのデザイン例
以下のような形で、DR サイトごとにコネクタグループを作成し、コネクタをインストールするサーバーを２台ずつ含めます。すべてのトラフィックは、TKY-Group のみに割り当てて運用します。
災害が発生し、東京サイトは使えないと判断したときに、手動でアプリ割り当てを OSA-Group に切り替えることで、DR を実現します。

アプリ割り当て	コネクタグループ	サーバー設置場所	コネクタ導入サーバー
正常時	TKY-Group	東京サイト	TKY-MEPAC01 TKY-MEPAC02
DR 時 (手動切替)	OSA-Group	大阪サイト	OSA-MEPAC01 OSA-MEPAC02

公開情報：ディザスターリカバリーサイト
https://learn.microsoft.com/ja-jp/entra/global-secure-access/concept-connector-groups?wt.mc_id=MVP_407731#disaster-recovery-sites

導入手順

1. コネクタ用サーバーの手配

前提事項を満たす Windows Server を手配します。
サーバーがインターネットに接続できる状態になっているかを確認します。
（任意）ドメインに参加します。

2. TLS 1.2 の有効化

手配したコネクタ用サーバー上で、作業を行います。
TLS 1.2 の要件を満たすために、設定変更が必要です。

展開したての Windows Server 2022 で、該当の値をチェックしてみたのですが、十分では無かったので、新し目のサーバーでも設定は必須なようです。

公開情報を見ると、以下の説明になっていますが、緑色枠、水色枠のいずれか１つを実施すれば良いです。

緑色枠 = レジストリエディタを開いて、手動で編集
水色枠 = Windows PowerShell を管理者で開いて実行

参考
下図は、Windows PowerShell を貼り付ける方法を実施した場面です。
TLS 1.2 has been enabled. You must restart the Windows Server for the changes to take effect. と表示されており、正常終了を示しています。

※結果をレジストリエディタで確認してみたけど、ちゃんと設定されてました。

公開情報：トランスポート層セキュリティ (TLS) の要件
https://learn.microsoft.com/ja-jp/entra/global-secure-access/how-to-configure-connectors?wt.mc_id=MVP_407731#transport-layer-security-tls-requirements

3. コネクタモジュールのダウンロード

手配したコネクタ用サーバーに、モジュールをダウンロードします。
そのため、以下のどちらかの方法で、操作してください。

コネクタ用サーバー上でブラウザを開き、以下の手順を実行しローカルへダウンロード
別の PC で操作を行って、ダウンロードしたモジュールをコネクタ用サーバーにコピー

（ダウンロード手順）
1．Microsoft Entra 管理センターに管理者でサインインします。
https://entra.microsoft.com/

2．サインインしたら、GSA を利用したいテナントにちゃんと入れているかを確認します。

公開情報の以下の説明が分かりづらいですが、管理センターからダウンロードするモジュールには、接続先のテナント専用なのかもしれません。そのため、ダウンロードする際に別のテナント用のモジュールになってしまわないように、確認を促されていると思ってください。

たとえば、テナントのドメインが contoso.com の場合、管理者は admin@contoso.com またはそのドメイン上の他の管理者エイリアスであることが必要です。
右上隅で自分のユーザー名を選択します。アプリケーションプロキシを使用するディレクトリにサインインしていることを確認します。ディレクトリを変更する必要がある場合は、 [ディレクトリの切り替え] を選択し、アプリケーションプロキシを使用するディレクトリを選択します。

3．左ペインから グローバルセキュアアクセス > 接続 > コネクタとセンサー を開きます。そのあと、右側に表示された画面から コネクタサービスのダウンロード を選択します。さらに右側に表示されたウィンドウ内から 規約に同意してダウンロード を押します。

4．以下のようにダウンロードされれば OK です。
作業用 PC でダウンロードした場合は、コネクタ用サーバーのローカルにコピーしてください。

4. コネクタモジュールのインストール

インストール前の準備事項
このままインストールを実行すると、以下のように Internet Explorer セキュリティ強化の構成でブロックされている旨のメッセージが表示されてしまいます。

これを抑制するために、以下の設定を行ってください。
公開情報：Windows サーバーで Internet Explorer ESC をオフにする方法
https://learn.microsoft.com/ja-jp/previous-versions/troubleshoot/browsers/security-privacy/enhanced-security-configuration-faq?wt.mc_id=MVP_407731#windows-------internet-explorer-esc---------

（インストール手順）
1．ダウンロードしたファイルをダブルクリックして、実行します。

2．以下のウィンドウが表示されるため、テナントの管理者アカウントでサインインします。

私が検証した際には、上記の画面でサインインする際に、パスキーが利用できませんでした。
私のテナントは、完全パスワードレスを目指した検証も行っていたので、これでは先へ進めません。
別途、ID + パスワード + Microsoft Authenticator でサインインできる管理者を用意して、サインインする必要がありました。レアケースかと思いますが、同様の環境の人は、注意してください。

私の同僚が検証した時には、アカウントが Authenticator を使った 6桁のコード認証を使っていたのですが、以下のエラーが出ていました。エラー内容を見ると Edge の最新化が必要なのかな・・・と思われる内容なのですが、結論は Authenticator の通知を使わないとダメという結果でした。

Unsupported browser

Keep your account secure
Your organization requires that you set up the following authentication methods to prove your identity.

Update your browser
⚠️
Your browser is not supported or up-to-date.
Try updateing it, or else download and install the latest version of Microsoft Edge.

You can also access
https://aka.ms/mysecurityinfo from another devide.

要注意
コネクタの認証は、パスキーもダメだし、６桁コード認証もダメ・・ということで、ハマりどころかも知れません。

3．以下の画面が表示されれば、インストールは完了です。

上記の Learn more を押すと、以下のサイトにリンクされていました。
公開情報：既存のオンプレミスプロキシサーバーと連携する
https://learn.microsoft.com/ja-jp/entra/identity/app-proxy/application-proxy-configure-connectors-with-proxy-servers?wt.mc_id=MVP_407731

★３章と４章の手順は、以下の公開情報を元にしています。

公開情報：コネクタのインストールと登録
https://learn.microsoft.com/ja-jp/entra/global-secure-access/how-to-configure-connectors?wt.mc_id=MVP_407731#install-and-register-a-connector

5. インストール結果の確認

正常にコネクタがインストールされ、クラウドへの疎通が行われていると、Microsoft Entra 管理センターの画面を更新すると、以下の表示になります。

ポイント
緑色枠の箇所をポイントすると、以下のメッセージが表示されます。
各グループでアクティブなコネクタを 2 つ以上にすることをお勧めします
これは、コネクタが１つしか無いため、冗長性がないことを指摘しています。
もう１台、サーバーを手配して、コネクタを追加インストールすることが推奨されている状態です。

公開情報：インストールと登録を確認する
https://learn.microsoft.com/ja-jp/entra/global-secure-access/how-to-configure-connectors?wt.mc_id=MVP_407731#verify-the-installation-and-registration