Microsoft Entra プライベート ネットワーク コネクタを理解する
コネクタとは、Microsoft Entra Private Access とアプリケーション プロキシを実行可能にするもののことです。 シンプルで、デプロイと管理が簡単なうえに、非常に強力です。 この記事では、コネクタの詳細と動作、およびデプロイを最適化する方法の推奨事項について説明します。
プライベート ネットワーク コネクタとは?
コネクタは、プライベート ネットワークに配置され、Microsoft Entra Private Access およびアプリケーション プロキシ サービスへの送信接続を容易にする軽量のエージェントです。 コネクタは、バックエンド リソースへのアクセス権を持つ Windows Server にインストールする必要があります。 コネクタはコネクタ グループに編成でき、各グループが特定のリソースへのトラフィックを処理します。 アプリケーション プロキシの詳細と、アプリケーション プロキシ アーキテクチャの図解については、「Microsoft Entra アプリケーション プロキシを使用してリモート ユーザー向けにオンプレミス アプリを発行する」を参照してください。
Microsoft Entra プライベート ネットワーク コネクタを構成する方法については、「Microsoft Entra Private Access 用にプライベート ネットワーク コネクタを構成する方法」を参照してください。
プライベート ネットワーク コネクタは、オンプレミスにデプロイされている軽量エージェントで、クラウド上のアプリケーション プロキシ サービスへのアウトバウンド接続を容易にします。 コネクタは、バックエンド アプリケーションへのアクセス権を持つ Windows Server にインストールする必要があります。 ユーザーはアプリケーション プロキシ クラウド サービスに接続され、このサービスにより、ユーザーのトラフィックはコネクタを介してアプリケーションにルーティングされます。
コネクタとアプリケーション プロキシ サービス間でのセットアップと登録は、次のように行われます。
- IT 管理者は、送信トラフィックに対してポート 80 と 443 を開き、コネクタ、アプリ プロキシ サービス、Microsoft Entra ID で必要とされる複数の URL へのアクセスを許可します。
- 管理者は、Microsoft Entra 管理センターにサインインし、実行可能ファイルを実行してオンプレミスの Windows Server にコネクタをインストールします。
- コネクタは、アプリケーション プロキシ サービスの "リッスン" を開始します。
- 管理者は、Microsoft Entra ID にオンプレミス アプリケーションを追加し、ユーザーがアプリに接続するために必要な設定 (URL など) を構成します。
冗長性とスケーラビリティのため、常に複数のコネクタをデプロイすることをお勧めします。 コネクタは、サービスと共に、高可用性のすべてのタスクを処理します。また、動的に追加または削除することができます。 新しい要求を受信するたびに、使用できるコネクタのいずれかにルーティングされます。 コネクタが動作してサービスに接続すると、アクティブな状態が保たれます。 コネクタは、一時的に使用できない場合はトラフィックに応答しません。 使用していないコネクタは非アクティブとしてタグ付けされ、非アクティブな状態が 10 日間続くと削除されます。
また、コネクタはサーバーをポーリングして、新しいバージョンのコネクタがあるかどうかを調べます。 コネクタは手動更新できますが、プライベート ネットワーク コネクタの Updater サービスを実行している限りは自動更新されます。 複数のコネクタを持つテナントの場合、環境でのダウンタイムを避けるために、自動更新では各グループで一度に 1 つのコネクタが対象となります。
Note
バージョン履歴ページを定期的に確認して、最新の更新プログラムを常に把握しておきましょう。
各プライベート ネットワーク コネクタは、コネクタ グループに割り当てられます。 同じコネクタ グループに属するコネクタは、高可用性と負荷分散のために単一のユニットとして動作します。 Microsoft Entra 管理センターで新しいグループを作成し、コネクタをそれらに割り当てたら、特定のアプリケーションに対応する特定のコネクタを割り当てることができます。 高可用性のためには、各コネクタ グループに少なくとも 2 つのコネクタを割り当てることをお勧めします。
コネクタ グループは、次のシナリオをサポートする必要がある場合に役立ちます。
- 地理的なアプリの発行
- アプリケーションのセグメント化と分離
- クラウドまたはオンプレミスで実行されている Web アプリの発行
コネクタのインストール場所の選び方とネットワークの最適化について詳しくは、「Microsoft Entra アプリケーション プロキシを使用する場合のネットワーク トポロジに関する注意事項」をご覧ください。
管理
コネクタとサービスは、高可用性のすべてのタスクに対処します。 コネクタは動的に追加したり削除できます。 新しい要求は、使用できるコネクタのいずれかにルーティングされます。 コネクタは、一時的に使用できない場合はトラフィックに応答しません。
コネクタはステートレスであり、コンピューター上に構成データはありません。 保存されているデータは、サービスに接続するための設定とその認証証明書のみです。 サービスに接続すると、すべての必要な構成データをプルして、数分ごとに更新します。
また、コネクタはサーバーをポーリングして、新しいバージョンのコネクタがあるかどうかを調べます。 新しいバージョンが見つかると、コネクタは自身を更新します。
イベント ログとパフォーマンス カウンターのいずれかを使用して、コネクタが実行されているマシンからコネクタを監視できます。 それらの状態は Microsoft Entra 管理センターでも確認できます。 Microsoft Entra Private Access の場合は、グローバル セキュア アクセスに移動し、[接続] を選択し、[コネクタ] を選択します。 アプリケーション プロキシの場合は、ID、アプリケーション、エンタープライズ アプリケーションに移動し、アプリケーションを選択します。 [アプリケーション] ページで、[アプリケーション プロキシ] を選択します。
使用されていないコネクタを手動で削除する必要はありません。 コネクタが動作してサービスに接続すると、アクティブな状態が保たれます。 使用していないコネクタは _inactive_ としてタグ付けされ、非アクティブな状態が 10 日間続くと削除されます。 コネクタをアンインストールする場合は、コネクタ サービスと更新サービスの両方をサーバーからアンインストールします。 コンピューターを再起動して、サービスを完全に削除します。
自動更新
Microsoft Entra ID では、デプロイしたすべてのコネクタの自動更新が提供されます。 プライベート ネットワーク コネクタでアップデーター サービスを実行している限り、コネクタは自動的に最新のメジャー コネクタ リリースを使用して更新されます。 サーバーに Connector Updater サービスが見つからない場合は、コネクタを再インストールして更新プログラムを取得する必要があります。
お使いのコネクタの番まで自動更新を待てない場合は、手動アップグレードを実行できます。 コネクタが配置されたサーバーのコネクタ ダウンロード ページに移動し、 [ダウンロード] を選択します。 このプロセスによって、ローカル コネクタのアップグレードが開始されます。
複数のコネクタを持つテナントの場合、環境でのダウンタイムを避けるために、自動更新では各グループで一度に 1 つのコネクタが対象となります。
コネクタの更新を行う際、次のような場合はダウンタイムが生じることがあります。
- コネクタが 1 つしかない場合: ダウンタイムを回避し、可用性を高めるために、2 つ目のコネクタとコネクタ グループの使用をお勧めします。
- 更新の開始時にコネクタがトランザクションの処理中であった場合: 初期トランザクションは失われますが、ブラウザーにより自動で操作が再試行されます。ページを更新しても構いません。 要求が再送信されると、トラフィックはバックアップ コネクタへルーティングされます。
過去にリリースされたバージョンとその変更内容については、アプリケーション プロキシのバージョン リリース履歴に関するページを参照してください。
コネクタ グループの作成
コネクタ グループは、特定のアプリケーションに対応する特定のコネクタを割り当てることのできる機能です。 多数のコネクタを 1 つにグループ化したうえで、それぞれのリソースまたはアプリケーションをグループに割り当てることができます。
コネクタ グループによって大規模なデプロイが管理しやすくなります。 また、ローカル アプリケーションにのみサービスを提供する位置ベースのコネクタ グループを作成できるため、さまざまなリージョンでリソースとアプリケーションのホストとなっているテナントの待ち時間が改善されます。
コネクタ グループの詳細については、「Microsoft Entra プライベート ネットワーク コネクタ グループについて」を参照してください。
セキュリティとネットワーク
コネクタは、Microsoft Entra Private Access アクセスおよびアプリケーション プロキシ サービスに要求を送信することを許可するネットワーク上の任意の場所にインストールできます。 ただし、コネクタを実行するコンピューターもアプリとリソースにアクセスできる必要があります。 企業ネットワーク内またはクラウドで実行されている仮想マシンにもコネクタをインストールできます。 コネクタは、非武装地帯 (DMZ) とも呼ばれる境界ネットワーク内で実行できますが、すべてのトラフィックはアウトバウンドであり、ネットワークはセキュリティで保護された状態が保たれるため、これは必須ではありません。
コネクタは送信要求を送信するだけです。 送信トラフィックは、サービスと公開済みリソースとアプリケーションに送信されます。 セッションが確立するとトラフィックは両方向に流れるため、受信ポートを開く必要はありません。 また、ファイアウォール経由での受信アクセスを構成する必要はありません。
送信トラフィックのファイアウォール規則を構成する方法の詳細については、「既存のオンプレミス プロキシ サーバーと連携する」をご覧ください。
パフォーマンスと拡張性
Microsoft Entra Private Access およびアプリケーション プロキシ サービスではスケールについてユーザーが気にする必要はありませんが、コネクタに関してはスケールが重要な要因になります。 ピーク時のトラフィックを処理するには十分なコネクタが必要です。 コネクタはステートレスであるため、ユーザーまたはセッションの数による影響はありません。 その代わりに、要求数やペイロード サイズに反応します。 標準的な Web トラフィックの場合、平均的なマシンで 1 秒あたり 2000 件の要求を処理できます。 具体的な容量は、実際のコンピューターの特性によって異なります。
コネクタのパフォーマンスは、CPU とネットワークによって定義されます。 TLS による暗号化と解除には CPU のパフォーマンスが必要であり、アプリケーションとオンライン サービスへの高速接続を実現するにはネットワークが重要です。
これに対し、コネクタにとってメモリはあまり重要ではありません。 処理の大半はオンライン サービスによって行われ、すべての認証されていないトラフィックが処理されます。 クラウドでできることはすべてクラウドで実行しています。
コネクタまたはマシンが使用できない場合、トラフィックはグループ内の別のコネクタに送信されます。 コネクタ グループに複数のコネクタがある場合、回復性が提供されます。
パフォーマンスに関するその他の要因としては、コネクタと次の項目間のネットワークの品質が挙げられます。
- オンライン サービス: Microsoft Entra サービスへの接続が遅いまたは待機時間が長いと、コネクタのパフォーマンスに影響します。 最高のパフォーマンスを実現するには、Express Route を使用して組織を Microsoft に接続します。 それ以外の場合は、ネットワーク チームに、Microsoft への接続が可能な限り効率的に処理されるように依頼してください。
- バックエンド アプリケーション: 場合によっては、コネクタとバックエンド リソースおよびアプリケーションの間にプロキシが追加され、接続の速度が低下したり、接続できなくなったりする可能性があります。 このシナリオをトラブルシューティングするには、コネクタ サーバーからブラウザーを開き、アプリケーションまたはリソースにアクセスします。 コネクタをクラウドで実行し、アプリケーションはオンプレミスで実行している場合は、ユーザーが期待するほどのエクスペリエンスが得られないことがあります。
- ドメイン コントローラー:コネクタでは、Kerberos の制約付き委任を使用してシングル サインオン (SSO) を実行する場合、バックエンドに要求を送信する前にドメイン コントローラーに接続します。 コネクタには Kerberos チケットのキャッシュがありますが、ビジー状態では、ドメイン コントローラーの応答性がパフォーマンスに影響することがあります。 こうした問題は、コネクタを Azure で実行していながらオンプレミスのドメイン コントローラーと通信している場合によく見られます。
ネットワークの最適化の詳細については、Microsoft Entra アプリケーション プロキシを使用する場合のネットワーク トポロジに関する注意事項に関するページをご覧ください。
ドメイン参加
コネクタは、ドメインに参加していないマシンで実行できます。 ただし、統合 Windows 認証 (IWA) を使用するアプリケーションへのシングル サインオン (SSO) が必要な場合は、ドメイン参加済みマシンが必要です。 この場合、コネクタを実行するコンピューターは、公開済みアプリケーションのユーザーの代わりに Kerberos の制約付き委任を実行できるドメインに参加する必要があります。
コネクタは、部分的な信頼関係のあるフォレスト内のドメイン、または読み取り専用ドメイン コントローラーに参加することもできます。
制限の厳しい環境でのコネクタのデプロイ
通常、コネクタのデプロイはとても簡単で、特別な構成は必要ありません。
ただし、考慮すべき特別な条件がいくつかあります。
- 送信トラフィックの場合、特定のポートが開かれている必要があります。 詳細については、「コネクタを構成する」を参照してください。
- FIPS 準拠のマシンでは、コネクタ プロセスで証明書を生成して格納できるように、構成を変更することが必要な場合があります。
- 送信転送プロキシによって、双方向の証明書認証が中断されて、通信が失敗する可能性があります。
コネクタの認証
セキュリティで保護されたサービスを提供する場合、コネクタはサービスに対して認証を行い、サービスはコネクタに対して認証を行う必要があります。 この認証を実行するには、コネクタが接続を開始するときにクライアント証明書とサーバー証明書を使用します。 こうすることで、管理者のユーザー名とパスワードは、コネクタを実行するマシンに格納されることはありません。
使用する証明書は、サービス固有のものです。 これらは新規登録時に作成され、数か月ごとに自動的に更新されます。
証明書の更新に初めて成功した後の Microsoft Entra プライベート ネットワーク コネクタ サービス (ネットワーク サービス) には、ローカルのマシン ストアから古い証明書を削除するアクセス許可がありません。 証明書の有効期限が切れるか、サービスで使用されていない場合、証明書を安全に削除できます。
証明書の更新に関する問題を回避するには、コネクタからドキュメントに記載されている送信先までのネットワーク通信が有効になっていることを確認します。
コネクタが数か月間サービスに接続されない場合、その証明書は期限切れになっている可能性があります。 このような場合は、コネクタをアンインストールしてから再インストールして、登録をトリガーします。 次の PowerShell コマンドを実行できます。
Import-module MicrosoftEntraPrivateNetworkConnectorPSModule
Register-MicrosoftEntraPrivateNetworkConnector -EnvironmentName "AzureCloud"
政府機関の場合は、-EnvironmentName "AzureUSGovernment" を使用します。 詳細については、「Azure Government クラウド用にエージェントをインストールする」を参照してください。
証明書の検証と問題のトラブルシューティングの方法については、「コンピューターとバックエンド コンポーネントでアプリケーション プロキシ信頼証明書がサポートされていることを確認する」を参照してください。
しくみ
コネクタは Windows Server にインストールされているため、Windows イベント ログや Windows パフォーマンス カウンターなど、同じ管理ツールの大半を備えています。
コネクタには管理者ログとセッション ログがあります。 管理者ログには主要なイベントとそのエラーが含まれます。 セッション ログには、すべてのトランザクションとその処理の詳細が含まれます。
ログを表示するには、イベント ビューアーを開き、[アプリケーションとサービス ログ]>[Microsoft]>[Microsoft Entra プライベート ネットワーク]>[コネクタ] の順に移動します。 セッション ログを表示するには、 [表示] メニューの [分析およびデバッグ ログの表示] を選択します。 通常、セッション ログはトラブルシューティングに使用され、既定では無効になっています。 イベントの収集を開始するときに有効にし、その後、不要になったら無効にしてください。
[サービス] ウィンドウでサービスの状態を確認することができます。 コネクタは、実際のコネクタとアップデーターという、2 つの Windows サービスで構成されています。 この両方を常に実行する必要があります。
アクティブになっていないコネクタ
よくある問題は、コネクタがコネクタ グループで非アクティブとして表示されることです。 コネクタがアクティブにならない原因としてよくあるのは、必要なポートがファイアウォールによってブロックされている場合です。