Microsoft Entra プライベート ネットワーク コネクタを理解する
コネクタとは、Microsoft Entra Private Access とアプリケーション プロキシを実行可能にするもののことです。 シンプルで、デプロイと管理が簡単なうえに、非常に強力です。 この記事では、コネクタの詳細と動作、およびデプロイを最適化する方法の推奨事項について説明します。
プライベート ネットワーク コネクタとは?
コネクタは、プライベート ネットワークに配置され、Microsoft Entra Private Access およびアプリケーション プロキシ サービスへの送信接続を容易にする軽量のエージェントです。 コネクタは、バックエンド リソースへのアクセス権を持つ Windows Server にインストールする必要があります。 コネクタはコネクタ グループに編成でき、各グループが特定のリソースへのトラフィックを処理します。 アプリケーション プロキシの詳細と、アプリケーション プロキシ アーキテクチャの図解については、「Microsoft Entra アプリケーション プロキシを使用してリモート ユーザー向けにオンプレミス アプリを発行する」を参照してください。
Microsoft Entra プライベート ネットワーク コネクタを構成する方法については、「Microsoft Entra Private Access 用にプライベート ネットワーク コネクタを構成する方法」を参照してください。
管理
コネクタとサービスは、高可用性のすべてのタスクに対処します。 コネクタは動的に追加したり削除できます。 新しい要求は、使用できるコネクタのいずれかにルーティングされます。 コネクタは、一時的に使用できない場合はトラフィックに応答しません。
コネクタはステートレスであり、コンピューター上に構成データはありません。 保存されているデータは、サービスに接続するための設定とその認証証明書のみです。 サービスに接続すると、すべての必要な構成データをプルして、数分ごとに更新します。
また、コネクタはサーバーをポーリングして、新しいバージョンのコネクタがあるかどうかを調べます。 新しいバージョンが見つかると、コネクタは自身を更新します。
イベント ログとパフォーマンス カウンターのいずれかを使用して、コネクタが実行されているマシンからコネクタを監視できます。 詳細については、オンプレミスの Microsoft Entra のログの監視と確認に関する記事を参照してください。
それらの状態は Microsoft Entra 管理センターでも確認できます。 Microsoft Entra Private Access の場合は、セキュリティで保護されたグローバル アクセス (プレビュー) に移動し、[接続] を選択し、[コネクタ] を選択します。 アプリケーション プロキシの場合は、ID、アプリケーション、エンタープライズ アプリケーションに移動し、アプリケーションを選択します。 [アプリケーション] ページで、[アプリケーション プロキシ] を選択します。
使用されていないコネクタを手動で削除する必要はありません。 コネクタが動作してサービスに接続すると、アクティブな状態が保たれます。 使用していないコネクタは _inactive_ としてタグ付けされ、非アクティブな状態が 10 日間続くと削除されます。 コネクタをアンインストールする場合は、コネクタ サービスと更新サービスの両方をサーバーからアンインストールします。 コンピューターを再起動して、サービスを完全に削除します。
自動更新
Microsoft Entra ID では、デプロイしたすべてのコネクタの自動更新が提供されます。 プライベート ネットワーク コネクタでアップデーター サービスを実行している限り、コネクタは自動的に最新のメジャー コネクタ リリースを使用して更新されます。 サーバーに Connector Updater サービスが見つからない場合は、コネクタを再インストールして更新プログラムを取得する必要があります。 コネクタの更新の詳細については、アプリケーション プロキシに関する FAQ に関する記事を参照してください。
お使いのコネクタの番まで自動更新を待てない場合は、手動アップグレードを実行できます。 コネクタが配置されたサーバーのコネクタ ダウンロード ページに移動し、 [ダウンロード] を選択します。 このプロセスによって、ローカル コネクタのアップグレードが開始されます。
複数のコネクタを持つテナントの場合、環境でのダウンタイムを避けるために、自動更新では各グループで一度に 1 つのコネクタが対象となります。
コネクタの更新を行う際、次のような場合はダウンタイムが生じることがあります。
- コネクタが 1 つしかない場合: ダウンタイムを回避し、可用性を高めるために、2 つ目のコネクタとコネクタ グループの使用をお勧めします。
- 更新の開始時にコネクタがトランザクションの処理中であった場合: 初期トランザクションは失われますが、ブラウザーにより自動で操作が再試行されます。ページを更新しても構いません。 要求が再送信されると、トラフィックはバックアップ コネクタへルーティングされます。
過去にリリースされたバージョンとその変更内容については、アプリケーション プロキシのバージョン リリース履歴に関するページを参照してください。
コネクタ グループの作成
コネクタ グループは、特定のアプリケーションに対応する特定のコネクタを割り当てることのできる機能です。 多数のコネクタを 1 つにグループ化したうえで、それぞれのリソースまたはアプリケーションをグループに割り当てることができます。
コネクタ グループによって大規模なデプロイが管理しやすくなります。 また、ローカル アプリケーションにのみサービスを提供する位置ベースのコネクタ グループを作成できるため、さまざまなリージョンでリソースとアプリケーションのホストとなっているテナントの待ち時間が改善されます。
コネクタ グループの詳細については、「Microsoft Entra プライベート ネットワーク コネクタ グループについて」を参照してください。
容量計画
予想されるトラフィック ボリュームを処理するための十分な容量をコネクタ間で計画します。 コネクタ グループに少なくとも 2 つのコネクタが含まれていれば、高可用性と高いスケーラビリティが実現されます。 ただし、3 つのコネクタが最適です。
次の表は、さまざまなマシン仕様のボリュームと予想される待機時間を示しています。 使用パターンはさまざまであり、負荷の予測には使用できないため、データは、ユーザーあたりのトランザクション数ではなく、期待される 1 秒あたりのトランザクション数 (TPS) に基づいています。 応答のサイズとバックエンド アプリケーションの応答時間によって多少の違いがあります。応答のサイズが大きく、応答時間が遅いと、最大 TPS は少なくなります。 負荷を分散するマシンの数を増加すると、十分なバッファーが提供されます。 追加容量により、高可用性と回復性が確保されます。
| コア | RAM | 予想される待機時間 (ミリ秒) - P99 | 最大 TPS |
|---|---|---|---|
| 2 | 8 | 325 | 586 |
| 4 | 16 | 320 | 1150 |
| 8 | 32 | 270 | 1190 |
| 16 | 64 | 245 | 1200* |
* このマシンでは、既定の接続制限の一部を .NET の推奨設定を超えて引き上げるために、カスタム設定を使用しました。 お使いのテナントでこの上限値を変更する場合は、サポートに連絡する前に、既定の設定でテストを実行することをお勧めします。
Note
4、8、および 16 コアのマシンの間で、最大 TPS に大きな違いはありません。 主な違いは、予想される待機時間です。
この表は、コネクタがインストールされているマシンの種類に基づいて予測されるコネクタのパフォーマンスに焦点を当てています。 これは、サービスの調整制限とは別です。サービスの制限と制約に関するページを参照してください。
セキュリティとネットワーク
コネクタは、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 の制約付き委任を実行できるドメインに参加する必要があります。
コネクタは、部分的な信頼関係のあるフォレスト内のドメイン、または読み取り専用ドメイン コントローラーに参加することもできます。
制限の厳しい環境でのコネクタのデプロイ
通常、コネクタのデプロイはとても簡単で、特別な構成は必要ありません。
ただし、考慮すべき特別な条件がいくつかあります。
- 送信トラフィックの場合、特定のポートが開かれている必要があります。 詳細については、「チュートリアル: Microsoft Entra ID のアプリケーション プロキシを使用してリモート アクセスするためのオンプレミス アプリケーションを追加する」を参照してください。
- FIPS 準拠のマシンでは、コネクタ プロセスで証明書を生成して格納できるように、構成を変更することが必要な場合があります。
- 送信転送プロキシによって、双方向の証明書認証が中断されて、通信が失敗する可能性があります。
コネクタの認証
セキュリティで保護されたサービスを提供する場合、コネクタはサービスに対して認証を行い、サービスはコネクタに対して認証を行う必要があります。 この認証を実行するには、コネクタが接続を開始するときにクライアント証明書とサーバー証明書を使用します。 こうすることで、管理者のユーザー名とパスワードは、コネクタを実行するマシンに格納されることはありません。
使用する証明書は、サービス固有のものです。 これらは新規登録時に作成され、数か月ごとに自動的に更新されます。
証明書の更新に初めて成功した後の Microsoft Entra プライベート ネットワーク コネクタ サービス (ネットワーク サービス) には、ローカルのマシン ストアから古い証明書を削除するアクセス許可がありません。 証明書の有効期限が切れるか、サービスで使用されていない場合、証明書を安全に削除できます。
証明書の更新に関する問題を回避するには、コネクタからドキュメントに記載されている送信先までのネットワーク通信が有効になっていることを確認します。
コネクタが数か月間サービスに接続されない場合、その証明書は期限切れになっている可能性があります。 このような場合は、コネクタをアンインストールしてから再インストールして、登録をトリガーします。 次の PowerShell コマンドを実行できます。
Import-module MicrosoftEntraPrivateNetworkConnectorPSModule
Register-MicrosoftEntraPrivateNetworkConnector -EnvironmentName "AzureCloud"
政府機関の場合は、-EnvironmentName "AzureUSGovernment" を使用します。 詳細については、「Azure Government クラウド用にエージェントをインストールする」を参照してください。
証明書の検証と問題のトラブルシューティングの方法については、「コンピューターとバックエンド コンポーネントでアプリケーション プロキシ信頼証明書がサポートされていることを確認する」を参照してください。
しくみ
コネクタは Windows Server にインストールされているため、Windows イベント ログや Windows パフォーマンス カウンターなど、同じ管理ツールの大半を備えています。
コネクタには管理者ログとセッション ログがあります。 管理者ログには主要なイベントとそのエラーが含まれます。 セッション ログには、すべてのトランザクションとその処理の詳細が含まれます。
ログを表示するには、イベント ビューアーを開き、[アプリケーションとサービス ログ]>[Microsoft]>[Microsoft Entra プライベート ネットワーク]>[コネクタ] の順に移動します。 セッション ログを表示するには、 [表示] メニューの [分析およびデバッグ ログの表示] を選択します。 通常、セッション ログはトラブルシューティングに使用され、既定では無効になっています。 イベントの収集を開始するときに有効にし、その後、不要になったら無効にしてください。
[サービス] ウィンドウでサービスの状態を確認することができます。 コネクタは、実際のコネクタとアップデーターという、2 つの Windows サービスで構成されています。 この両方を常に実行する必要があります。
アクティブになっていないコネクタ
よくある問題は、コネクタがコネクタ グループで非アクティブとして表示されることです。 コネクタがアクティブにならない原因としてよくあるのは、必要なポートがファイアウォールによってブロックされている場合です。
利用条件
Microsoft Entra Private Access と Microsoft Entra Internet Access のプレビュー エクスペリエンスおよび機能の使用は、お客様がサービスを取得した契約のプレビュー オンライン サービス使用条件によって管理されます。 オンライン サービスのユニバーサル ライセンス条項、Microsoft 製品とサービスのデータ保護補遺 (“DPA”)、プレビューで提供されるその他の通知で説明されているように、プレビューでは、セキュリティ、コンプライアンス、プライバシーに関するコミットメントが限定されるか、異なる場合があります。