Azure Arc 対応サーバーのネットワーク トポロジと接続
Azure Arc 対応サーバーを使用すると、Azure コントロール プレーン経由で Windows および Linux の物理サーバーと仮想マシンを管理できます。 この記事では、クラウド導入フレームワークのエンタープライズ規模のランディング ゾーン ガイダンスの一部として、Azure Arc 対応サーバー接続の主な設計上の考慮事項とベスト プラクティスについて説明します。 このガイダンスは、オンプレミス環境またはパートナー クラウド プロバイダー経由でホストする物理サーバーと仮想マシンを対象としています。
この記事では、エンタープライズ規模のランディング ゾーンを正常に実装し、ハイブリッド ネットワーク接続を確立したことを前提としています。 このガイダンスでは、Azure Arc 対応サーバーの接続されたマシン エージェントの接続性に重点を置いています。 詳細については、「エンタープライズキーボードのランディング ゾーンの概要」および「エンタープライズ規模のランディング ゾーンの実装」を参照してください。
Architecture
次の図は、Azure Arc 対応サーバーの接続に関する概念参照アーキテクチャを示しています。
設計上の考慮事項
Azure Arc 対応サーバーのネットワーク設計に関する次の考慮事項を考慮します。
エージェントの接続方法を定義する: 既存のインフラストラクチャとセキュリティ要件を見直します。 接続されたマシン エージェントが、オンプレミス ネットワークまたはその他のクラウド プロバイダーから Azure と通信する方法を決定します。 この接続はインターネット経由で直接、またはプロキシ サーバー経由で行われるか、プライベート接続用に Azure Private Link を実装することもできます。
Azure サービス タグへのアクセスを管理する: 「Connected Machine エージェントのネットワーク要件」に従って、ファイアウォールとプロキシ ネットワーク ルールを常に更新しておくための自動プロセスを作成します。
Azure Arc へのネットワーク接続をセキュリティで保護する: トランスポート層セキュリティ (TLS) バージョン 1.2 を使用するようにマシン オペレーティング システムを構成します。 既知の脆弱性のため、古いバージョンは推奨されません。
拡張機能の接続方法を定義する: Azure Arc 対応サーバーにデプロイされた Azure 拡張機能が、別の Azure サービスと通信できるかを確認します。 この接続は、バブリック ネットワーク、ファイアウォールまたはプロキシ サーバー経由で直接指定できます。 Azure Arc エージェントのプライベート エンドポイントを構成する必要があります。 設計でプライベート接続が必要な場合は、拡張機能がアクセスするサービスごとに有効なプライベート エンドポイント接続をするための追加の手順を実行する必要があります。 また、コスト、可用性、帯域幅に関する要件に応じて、共有回線または専用回線の使用を検討してください。
接続アーキテクチャを全体的に見直す: ネットワーク トポロジと接続設計領域を見直して、Azure Arc 対応サーバーが全体的な接続にどう影響しているかを評価します。
設計の推奨事項
Azure Arc 対応サーバーのネットワーク設計に関する次の推奨事項を考慮します。
Azure Arc エージェントの接続方法を定義する
Azure Arc 対応サーバーを使用して、次の方法でハイブリッド マシンを接続できます。
- 直接接続 (オプションでファイアウォールまたはプロキシ サーバーの背後から)。
- Private Link。
直接接続
Azure Arc 対応サーバーは、Azure パブリック エンドポイントとの直接接続を提供します。 この接続方法を使用する場合、すべてのマシン エージェントは、パブリック エンドポイントを使用して、インターネット経由で Azure に接続を開きます。 Linux と Windows 向けの接続済みマシン エージェントが、HTTPS プロトコル (TCP/443) を経由して安全に Azure にアウトバウンド接続を行います。
直接接続方法を使用する場合は、接続済みマシン エージェントのインターネット アクセスを評価します。 必要なネットワーク ルールを構成することが推奨されます。
プロキシ サーバーまたはファイアウォール接続
マシンでファイアウォールまたはプロキシ サーバーを使用して、インターネットを介した通信を行う場合、エージェントは HTTPS プロトコル経由でアウトバウンド接続を行います。
ファイアウォールまたはプロキシサーバーを使用して、アウトバウンド接続を制限する場合は、接続済みマシン エージェント ネットワーク要件に準拠した IP 範囲を許可します。 エージェントに必要な IP 範囲またはドメイン名のみにサービスとの通信を許可する場合は、サービス タグおよび URL を使用してファイアウォールまたはプロキシ サーバーを構成します。
Azure Arc 対応サーバーに拡張機能をデプロイする場合、すべての拡張機能が、それぞれのエンドポイントに接続して、ファイアウォールまたはプロキシですべての対応する URL も許可する必要があります。 これらのエンドポイントを追加すると、最小限の特権の原則を満たすために、きめ細かくセキュリティで保護されたネットワーク トラフィックが確保されます。
Private Link
Azure Arc エージェントからのすべてのトラフィックをネットワーク状に残すには、Azure プライベート リンク スコープがある Azure Arc 対応サーバーを使用します。 この構成では、セキュリティ上の利点があります。 トラフィックはインターネットを経由しないため、データセンターのファイアウォールでアウトバウンド例外をそれほど多く開く必要はありません。 ただし、Private Link を使用すると、全体的な複雑さとコストが増加する一方で、特にグローバルな組織にとって、多くの管理上の課題が挙がります。 次の課題を考えてみましょう。
Azure Arc プライベート リンク スコープには、同じドメイン ネーム システム (DNS) スコープ内のすべての Azure Arc クライアントが含まれます。 プライベート エンドポイントを使用する Azure Arc クライアントと、DNS サーバーを共有するときにパブリック エンドポイントを使用する Azure Arc クライアントを用意することはできません。 ただし、DNS ポリシーなどの回避策は実装できます。
Azure Arc クライアントは、プライマリ リージョン内のすべてのプライベート エンドポイントを持つことができます。 そうでない場合は、同じプライベート エンドポイント名が異なる IP アドレスに解決されるように DNS を構成する必要があります。 たとえば、Windows Server Active Directory 統合 DNS の 選択的にレプリケートされた DNS パーティションを使用できます。 すべての Azure Arc クライアントに同じプライベート エンドポイントを使用する場合は、すべてのネットワークからプライベート エンドポイントにトラフィックをルーティングできる必要があります。
Azure Arc 経由でデプロイする拡張ソフトウェア コンポーネントによってアクセスされるすべての Azure サービスにプライベート エンドポイントを使用するには、追加の手順を実行する必要があります。これらのサービスには、Log Analytics ワークスペース、Azure Automation アカウント、Azure Key Vault、Azure Storage が含まれます。
Microsoft Entra ID への接続には、パブリック エンドポイントが使用されるため、クライアントには、インターネット アクセスが必要です。
プライベート接続用 Azure ExpressRoute を使用する場合、circuits、gateways、connections および ExpressRoute Direct の回復性ベストプラクティスを見直すことを検討します。
これらの課題があるため、Azure Arc 実装用 Private Link が必要かどうかを評価することが推奨されます。 パブリック エンドポイントはトラフィックを暗号化します。 サーバーに対して Azure Arc を使用する方法によっては、管理へのトラフィックとメタデータ トラフィックを制限する場合があります。 セキュリティ上の問題に対処するには、ローカル エージェント セキュリティ制御を実装します。
詳細については、「Private Link のセキュリティ」および Azure Arc 向け Private Link サポート関連の「制限事項」を参照してください。
Azure サービス タグへのアクセスを管理する
Azure Arc ネットワークの要件に従って、ファイアウォールとプロキシ ネットワーク ルールを更新しておくための自動プロセスを実装することが推奨されます。
次のステップ
ハイブリッド クラウドの導入に関する詳細なガイダンスについては、次のリソースを参照してください。