Azure Load Balancerでは、正常なバックエンド インスタンス間で受信トラフィックと送信トラフィックを分散するためのレイヤー 4 負荷分散機能が提供されます。 Load Balancerはトランスポート層で動作するため、ネットワーク制御、ID 制御、監視、ワークロード レベルの暗号化と組み合わせて、完全なデプロイをセキュリティで保護する必要があります。
この記事では、Azure Load Balancerのセキュリティに関する推奨事項について説明します。 これらの推奨事項を実装すると、セキュリティ上の義務を果たし、デプロイの全体的なセキュリティ体制が向上します。 Azureのネットワーク セキュリティ サービスとその連携方法の概要については、「
この記事のセキュリティに関する推奨事項では、ゼロ トラストの原則 ("明示的に確認する"、"最小限の特権アクセスを使用する"、"侵害を想定する") が実装されています。 包括的なゼロ トラスト ガイダンスについては、 ゼロ トラスト ガイダンス センターを参照してください。
Important
Basic Load Balancer は、2025 年 9 月 30 日に廃止されました。 既存の Basic Load Balancer は引き続き動作しますが、サポートされておらず、SLA の保証の対象ではありません。 できるだけ早くStandard Load Balancerにアップグレードしてください。 詳細については、「基本的なLoad Balancerからのアップグレード - ガイダンスを参照してください。
ネットワークのセキュリティ
Azure Load Balancerのネットワーク セキュリティでは、受信露出の制限、送信接続の制御、バックエンドの正常性の検証、他のAzure ネットワーク セキュリティ サービスとの統合に重点を置いています。
Standard Load Balancer SKU の使用: 運用環境のワークロードにStandard Load Balancerをデプロイします。 Standard Load Balancerは、閉じた受信接続を備えた既定のセキュリティで保護されたモデルに従い、可用性ゾーンをサポートし、99.99% SLA を提供します。 Basic Load Balancerは 2025 年 9 月 30 日に廃止されました。新しいデプロイには使用しないでください。 詳細については、「 Azure Load Balancer の概要」を参照してください。
サブネットおよびネットワークインターフェースにネットワークセキュリティグループを実装する:バックエンドのサブネットおよびネットワークインターフェースにネットワークセキュリティグループ(NSG)を適用し、必要なアプリケーショントラフィックのみを明示的に許可します。 ロードバランシングルールはフロントエンドトラフィックをバックエンドプールにマッピングし、NSGはそのトラフィックが許可されているかどうかを独立して判断します。 詳細については、「Azure Load Balancer セキュリティ ベースラインを参照してください。
Azure Load Balancer のヘルス プローブ トラフィックを許可: ヘルス プローブのアクセスは、アプリケーション トラフィックのアクセスとは別に個別に確認してください。 NSGで
AzureLoadBalancerサービスタグを、ローカルファイアウォールポリシーでIPアドレス168.63.129.16を許可し、プローブがバックエンドインスタンスに到達できるようにします。 詳細については、「Azure Load Balancer の正常性プローブ」を参照してください。プライベート ワークロードに内部ロード バランサーを使用する: サービスで直接インターネットに公開する必要がない場合は、プライベート フロントエンド IP アドレスを使用して内部ロード バランサーをデプロイします。 仮想ネットワーク ピアリング、VPN、ExpressRoute、Azure Firewall、またはプライベート アクセス パターンを使用して、フロントエンドに到達できるユーザーを制御します。 詳細については、「Azure Load Balancer コンポーネントを参照してください。
Azure DDoS Protection でパブリック ロード バランサーを保護する: パブリック ロード バランサーをホストしている仮想ネットワークで Azure DDoS Network Protection を有効にします。 DDoS Protection は、脅威や悪用の兆候についてエンドポイントを監視する強化された DDoS 軽減機能と検出機能を提供します。 詳細については、「 Azure DDoS Protection を使用してパブリック ロード バランサーを保護するを参照してください。
明示的な送信接続を使用する: 既定の送信アクセスに依存しないでください。 2026年3月31日以降にリリースされたAPIバージョンでは、新しい仮想ネットワークはデフォルトでプライベートサブネットを使用し、公開エンドポイントに到達するには明示的なアウトバウンド方式が必要です。 既存の仮想ネットワークは自動的に変更されません。 予測可能なアウトバウンドIPアドレスにはAzure NAT Gatewayを使い、NAT Gatewayが適さない場合は明示的なStandard Load Balancerのアウトバウンドルールを設定しましょう。 詳細については、「outbound connections in Azure and Azure NAT Gateway overview を参照してください。
適切な配布モードを構成する: アプリケーションとセキュリティの要件に合った配布モードを選択します。 ほとんどのワークロードでは既定の 5 タプル ハッシュを使用し、永続化によって不均一な分散が作成され、回復性が低下する可能性があるため、アプリケーションで必要な場合にのみセッション永続化を使用します。 詳細については、「Azure Load Balancer 配布モード」を参照>。
より明確な接続処理のために TCP リセットを有効にする: クライアントとバックエンド アプリケーションがアイドル タイムアウト時に双方向 TCP リセット パケットを受信するように負荷分散規則で TCP リセットを構成します。 接続状態をクリアすると、アプリケーションの回復速度が速くなり、あいまいなハーフオープン接続が減ります。 詳細については、「Azure Load Balancerのベスト プラクティスを参照してください。
安全なフローティング IP とゲートウェイのLoad Balancer設計: 高可用性シナリオにフローティング IP を使用する場合は、ループバック インターフェイスを正しく構成し、ホスト ファイアウォール制御を適用します。 ゲートウェイ Load Balancerとネットワーク仮想アプライアンスの場合、異なるトンネル インターフェイスで信頼されたトラフィックと信頼されていないトラフィックを分離し、VXLAN ヘッダーのオーバーヘッドを考慮します。 詳細については、「Azure Load Balancerのベスト プラクティスを参照してください。
必要なときに検査サービスを統合する: Azure Load Balancerはレイヤー 4 サービスであり、アプリケーションペイロードを検査しません。 ファイアウォール、Web アプリケーション ファイアウォール、またはレイヤー 7 の検査が必要な場合は、Azure Firewall、ネットワーク仮想アプライアンス、Application Gateway、またはAzure Front Door経由でトラフィックをルーティングします。 詳細については、「Architecture best practices for Azure Load Balancer」を参照してください。
ID およびアクセス管理
ロード バランサーのリソース、ルール、プローブ、フロントエンド IP、バックエンド プール、および送信接続を作成、更新、削除、確認できるAzure Load Balancerコントロールの ID とアクセス管理。
管理プレーンへのアクセスには Microsoft Entra ID を使用する: Azure portal、Azure CLI、Azure PowerShell、または Azure Resource Manager API を使用する際に、管理者が Microsoft Entra ID で認証することを必須にします。 多要素認証、準拠しているデバイス要件、特権ネットワーク ロールのサインイン リスク ポリシーなどの条件付きアクセス制御を適用します。 詳細については、「条件付きアクセスのMicrosoft Entra」を参照してください。
ロールベースのアクセス制御Azure実装: ロード バランサーを管理するユーザー、グループ、マネージド ID、およびオートメーション アカウントにAzure RBAC ロールを割り当てます。 完全なネットワーク管理スコープが必要な場合にのみ、ネットワーク共同作成者などの組み込みロールを使用します。 詳細については、「ロールベースのアクセス制御Azureを参照してください。
最小限の特権アクセスを使用する: 定期的なロード バランサー操作では、広範な所有者または共同作成者の割り当てを回避します。 オペレーターがロード バランサーの読み取り、書き込み、規則、プローブ、またはバックエンド プールの操作に対して特定のアクセス許可のみを必要とする場合に、カスタム ロールを作成します。 詳細については、「Azure カスタム ロール」を参照してください。
Microsoft Entra Privileged Identity Management を使用して特権アクセスを管理する: Microsoft Entra Privileged Identity Management (PIM) を使用して、影響の大きいロールを永続的に割り当てるのではなく、適格にします。 本番環境のロード バランサーを変更できるロールには、承認、多要素認証、正当な理由、および期限付きのアクティブ化が必要です。 詳細については、「Microsoft Entra Privileged Identity Management とは」を参照してください。
ネットワーク チームとワークロード チームの個別の職務: 負荷分散規則、受信 NAT 規則、送信規則、バックエンド プール メンバーシップ、プローブ設定を変更できるユーザーを制限します。 職務の分離により、1 つの侵害された ID がサービスを公開し、その背後にあるワークロードを変更できるリスクが軽減されます。 詳細については、 Azure RBAC のベスト プラクティスに関するページを参照してください。
管理プレーンの変更の監査: ロード バランサーの構成変更、ロール割り当て、診断設定の変更に関する Azure アクティビティ ログ イベントを監視します。 フロントエンド IP 構成、ルール マッピング、送信規則、またはバックエンド プール メンバーシップに対する予期しない更新に関するアラート。 詳細については、「Monitor Azure Load Balancer」を参照してください。
データ保護
Azure Load Balancerのデータ保護では、バックエンド ワークロードによって処理されるトラフィックを保護し、構成とテレメトリを保護することに重点を置いています。Load Balancerには顧客のアプリケーション データが格納されないためです。
アプリケーション トラフィックをエンドツーエンドで暗号化: Azure Load Balancer はレイヤー 4 で動作し、TLS を終端したりペイロードを検査したりしません。 必要に応じてトラフィックが暗号化されたままになるように、バックエンド アプリケーションまたはバックエンドの前のレイヤー 7 サービスで TLS を構成します。 詳細については、「Architecture best practices for Azure Load Balancer」を参照してください。
TLS 終了に適したサービスを使用します: HTTP または HTTPS ワークロードで TLS 終了、証明書管理、URL ルーティング、または Web アプリケーション ファイアウォール検査が必要な場合は、これらの関数のLoad Balancerに依存するのではなく、Azure Application GatewayまたはAzure Front Doorを使用します。 詳細については、「 Azure Load Balancer の概要」を参照してください。
バックエンド シークレットと証明書の保護: バックエンド インスタンスによって使用される TLS 証明書、秘密キー、アプリケーション シークレットをAzure Key Vaultに格納します。 スクリプト、テンプレート、または VM 拡張機能にシークレットを埋め込む代わりに、バックエンド ワークロードにマネージド ID を使用します。 詳細については、「 Azure Key Vault の概要」を参照してください。
セキュリティで保護された診断データの宛先: ロード バランサーのメトリック、フロー ログ、アーカイブされた診断には、IP アドレス、ポート、トポロジの詳細を含めることができます。 診断を受け取るLog Analyticsワークスペース、ストレージ アカウント、および Event Hubs へのアクセスを制限し、コンプライアンス要件でストレージ アカウントにカスタマー マネージド キーを使用します。 詳細については、「 Azure Storage の暗号化」を参照してください。
名前とタグに機密性の高いトポロジが公開されないようにする: ロード バランサー名、ルール名、パブリック IP DNS ラベル、またはリソース タグにシークレット、内部プロジェクト名、機密性の高いネットワークの詳細を含めないでください。 これらの値は、ログ、エクスポート、アラート、アクセス レビューに表示できます。 詳細については、「Azure リソースの名前付け規則と制限事項」を参照してください。
ログ記録と監視
Azure Load Balancerのログ記録と監視により、可用性、正常性プローブ、トラフィック パターン、構成の変更を可視化できるため、チームはセキュリティと信頼性の問題をすばやく検出できます。
有効な診断設定: 診断設定を構成して、ロード バランサーのメトリックとサポートされているログをLog Analyticsワークスペース、ストレージ アカウント、または Event Hubs に送信し、分析と保持を行います。 詳細については、「Monitor Azure Load Balancer」を参照してください。
Azure Monitor Insights を使用する: Load Balancer Insights をデプロイして、事前構成済みのダッシュボード、機能依存関係図、リソースの正常性、メトリックを表示して、プロアクティブな監視を行います。 詳細については、「
Insights を使用してAzure Load Balancer を参照してください。正常性プローブの監視を構成する: ホストの可用性だけでなく、アプリケーションの準備状況を正確に表す正常性プローブを実装します。 ユーザーが影響を受ける前にバックエンドの障害、ファイアウォール ブロック、およびアプリケーションの停止が検出されるように、プローブの状態を監視します。 詳細については、「Manage health probes for Azure Load Balancer」を参照してください。
接続と可用性のメトリックの監視: データ パスの可用性、正常性プローブの状態、SYN 数、SNAT 接続数、割り当てられた SNAT ポートなどのメトリックを追跡します。 アラートを使用して、失敗したバックエンド、異常な接続スパイク、または送信ポートの枯渇を特定します。 詳細については、「Standard Load Balancerメトリック、アラート、リソース正常性を使用した診断を参照してください。
仮想ネットワーク フロー ログを有効にする: バックエンド サブネット周辺のトラフィック パターンを分析し、疑わしいフローまたは予期しないフローを識別するように仮想ネットワーク フロー ログを構成します。 ワークロードおよび ID イベントと関連付けるために、ログをセキュリティ情報およびイベント管理 (SIEM) システムに転送します。 詳細については、「Monitor Azure Load Balancer」を参照してください。
セキュリティと運用のアラートを設定する: 失敗した正常性プローブ、低データ パスの可用性、異常なトラフィックの増加、SNAT 枯渇インジケーター、予期しないアクティビティ ログの変更に対するAzure Monitorアラートを作成します。 アラート アクションに Runbook のリンクと所有者情報を含めます。 詳細については、「Monitor Azure Load Balancer」を参照してください。
コンプライアンスとガバナンス
Azure Load Balancerのコンプライアンスとガバナンスは、サブスクリプション、リージョン、および環境全体で一貫性のある、サポート可能な監査可能な構成を確保するのに役立ちます。
実装Azure Policy コントロール: Azure Policyを使用して、Standard SKU の使用、診断設定、タグ付け、バックエンド サブネット上の NSG の関連付けなどのロード バランサーの要件を監査および適用します。 詳細については、「Azure Load Balancer セキュリティ ベースラインを参照してください。
コードとしてのインフラストラクチャを使用したデプロイの標準化: ARM テンプレート、Bicep、またはその他の承認済みのコードとしてのインフラストラクチャ パイプラインを使用して、ロード バランサー、パブリック IP、ルール、プローブ、バックエンド プール、および送信構成をデプロイします。 バージョン管理されたテンプレートは、誤差を軽減し、コンプライアンス レビューの証拠を提供します。 詳細については、「Bicep を使用してパブリック ロード バランサーを作成する」および「 ARM テンプレートを使用してパブリック ロード バランサーを作成する」を参照してください。
リソースのタグ付けを使用する: ワークロード所有者、データ分類、環境、ビジネスの重要度、ディザスター リカバリー層に一貫性のあるタグを適用します。 タグは、コスト管理、コンプライアンス追跡、インシデント ルーティング、所有権レビューをサポートします。 詳細については、「Azure リソースの名前付けとタグ付けの決定ガイドを参照してください。
サポートされていない従来の構成を確認します。インベントリの基本ロード バランサー、暗黙的な送信依存関係、アンマネージ パブリック IP、および不足している診断。 Standard Load Balancer、NAT ゲートウェイ、または明示的な送信規則、監視対象の構成への移行に優先順位を付けます。 詳細については、「
Basic から Standard Load Balancer を参照してください。承認されたワークフローを使用して変更を制御する: フロントエンド IP、受信規則、NAT 規則、送信規則、バックエンド プール メンバーシップ、プローブ パス、アイドル タイムアウト設定の変更レビューが必要です。 Azureアクティビティ ログとデプロイ履歴を使用して、承認された ID とパイプラインからの変更を検証します。 詳細については、「Azure Resource Manager展開履歴を参照してください。
バックアップと回復
Azure Load Balancerのバックアップと復旧では、構成の保持、依存関係の文書化、インスタンス、ゾーン、またはリージョンの障害時にトラフィックのフローを維持する回復性のあるトポロジの設計に重点を置いています。
ロード バランサー構成のエクスポートとバージョン管理: Standard Load Balancer構成を ARM テンプレートまたはBicep ファイルとしてエクスポートし、ソース管理に格納します。 デプロイをすばやく復元または再作成できるように、フロントエンド IP 構成、パブリック IP リソース、バックエンド プール、負荷分散規則、受信 NAT 規則、送信規則、正常性プローブ、依存関係をキャプチャします。 詳細については、Azure ポータルの Export テンプレート および export テンプレートと Azure CLI を参照してください。
変更前にトポロジを文書化する: フロントエンド IP アドレス、DNS 名、バックエンド プール メンバー、ルール対プローブ マッピング、NAT マッピング、送信接続設計、NSG 依存関係、ルート テーブル、および所有チームを計画された変更前に記録します。 現在のドキュメントでは、ロールバックまたはリージョンの再構築が必要な場合の復旧時間が短縮されます。 詳細については、「Azure Load Balancer コンポーネントを参照してください。
複数リージョンのフェールオーバーにリージョン間load balancerを使用する: リージョン間のロード バランサー間でトラフィックを分散する単一のグローバル フロントエンドが必要な場合は、リージョン間Load Balancer (グローバル Load Balancerとも呼ばれます) をデプロイします。 リージョンごとの正常性監視と検証済みのフェールオーバー手順を併用してください。 詳細については、「 リージョン間ロード バランサー 」と「 ARM テンプレートを使用したリージョン間ロード バランサーのデプロイ」を参照してください。
可用性ゾーンの回復性のためにゾーン冗長フロントエンドを使用する: 可用性ゾーンがサポートされているゾーン冗長フロントエンド IP 構成でStandard Load Balancerを使用します。 Standard SKU にはゾーン冗長のサポートが組み込まれており、ゾーン冗長フロントエンドは、ゾーンで障害が発生した場合にデータ パスを使用可能な状態に保つのに役立ちます。 詳細については、「Azure Load Balancerのベスト プラクティスを参照してください。
ゾーン間のバックエンド プールの分散: Virtual Machine Scale Setsまたはゾーン仮想マシンを使用して、バックエンド インスタンスを複数の可用性ゾーンに配置します。 ゾーン冗長バックエンド プールを使用すると、単一のゾーン障害によってすべての正常なインスタンスがローテーションから削除される可能性が低くなります。 詳細については、ロードバランサーを可用性ゾーンサポートに移行するを参照してください。
リージョン内の自動フェールオーバー用に正常性プローブを構成する: 正常性プローブは、トラフィックを受信するバックエンド インスタンスを決定します。 アプリケーション対応のエンドポイントに対してプローブを構成し、適切な間隔としきい値を選択し、メンテナンス中にプローブの動作をテストして、トラフィックがリージョン内の正常なインスタンスに自動的にフェールオーバーされるようにします。 詳細については、「Manage health probes for Azure Load Balancer」を参照してください。
フェールオーバーを定期的にテストする: 定義されたスケジュールでインスタンス、ゾーン、リージョンのフェールオーバー シナリオを演習します。 プローブが異常なインスタンスを削除し、リージョン間のLoad Balancerまたは DNS ルーティングがセカンダリ リージョンにトラフィックを送信し、送信接続が引き続き機能し、監視アラートが適切なレスポンダーに到達することを検証します。 詳細については、「Azure Load Balancerのベスト プラクティスを参照してください。