次の方法で共有

仮想ネットワーク用の Azure Firewall と Application Gateway

Azure Application Gateway
Azure Firewall
Azure Front Door
Azure Virtual Network
Azure Web Application Firewall

Azure アプリケーションのワークロードをセキュリティで保護するには、アプリケーション自体で認証や暗号化などの保護手段を使用します。 アプリケーションをホストする仮想ネットワークにセキュリティ レイヤーを追加できます。 これらのセキュリティ層は、アプリケーションの受信フローを意図しない使用から保護するのに役立ちます。 また、インターネットへの送信フローは、アプリケーションで必要なエンドポイントのみに制限されます。 この記事では、Azure DDoS Protection、Azure Firewall、Azure Application Gateway などの Azure Virtual Network セキュリティ サービスについて説明します。 また、各サービスを使用するタイミングと、それらを組み合わせたネットワーク 設計オプションについても説明します。

  • DDoS Protection とアプリケーション設計のベスト プラクティスを組み合わせることで、DDoS 攻撃に対する防御を強化する強化された DDoS 軽減機能が提供されます。 すべての境界仮想ネットワークで DDoS Protection を有効にする必要があります。

  • Azure Firewall は、 ネットワーク アドレス変換 (NAT) 機能を提供するマネージド次世代ファイアウォールです。 Azure Firewall は、IP アドレスと伝送制御プロトコル (TCP) またはユーザー データグラム プロトコル (UDP) ポートに基づいてパケットをフィルター処理します。 HTTP(S) や SQL などのアプリケーション ベースの属性を使用してトラフィックをフィルター処理できます。 Azure Firewall では、悪意のある IP アドレスの識別に役立つ Microsoft 脅威インテリジェンスも適用されます。 詳細については、 Azure Firewall のドキュメントを参照してください。

  • Azure Firewall Premium には、トランスポート層セキュリティ (TLS) 検査や侵入検出および防止システム (IDPS) などの機能に加えて、Azure Firewall Standard のすべての機能が含まれています。

  • Application Gateway は、Secure Socket Layer (SSL) の暗号化と暗号化解除を実行できる、マネージド Web トラフィック ロード バランサーと HTTP (S) フル リバース プロキシです。 Application Gateway は、元のクライアント IP アドレスを X-Forwarded-For HTTP ヘッダーに保持します。 Application Gateway では、Azure Web Application Firewall を使用して Web トラフィックを検査し、HTTP レイヤーで攻撃を検出します。 詳細については、 Application Gateway のドキュメントを参照してください。

  • Web アプリケーション ファイアウォール は、Application Gateway にオプションで追加されます。 HTTP 要求を検査し、SQL インジェクションやクロスサイト スクリプティングなどの Web レイヤー攻撃を防ぎます。 詳細については、 Web アプリケーション ファイアウォールのドキュメントを参照してください。

これらの Azure サービスは相互に補完します。 ニーズによっては、1 つのサービスを使用する方がワークロードに適している場合があります。 ただし、これらのサービスを一緒に使用して、ネットワーク層とアプリケーション層の両方で最適な保護を提供できます。 次のデシジョン ツリーとこの記事の例を使用して、アプリケーションの仮想ネットワークに最適なセキュリティ オプションを選択します。

Azure Firewall と Application Gateway では、さまざまな種類のデータ フローをセキュリティで保護するために、さまざまなテクノロジを使用します。

アプリケーション フロー Azure Firewall でフィルター処理できる Application Gateway 上の Web アプリケーション ファイアウォールでフィルター処理できます
オンプレミスまたはインターネットから Azure への HTTP (S) トラフィック (受信) はい はい
Azure からオンプレミスまたはインターネットへの HTTP (S) トラフィック (送信) はい いいえ
HTTP (S) 以外のトラフィック (受信または送信) はい いいえ

設計は、必要なネットワーク フローに基づいてアプリケーションごとに異なる場合があります。 次の図は、アプリケーションに推奨される方法を選択するのに役立つ簡略化されたデシジョン ツリーを示しています。 この選択は、アプリケーションが HTTP (S) またはその他のプロトコルを介して発行されているかどうかによって異なります。

仮想ネットワーク セキュリティデシジョン ツリーを示す図。

この記事では、フロー チャートに示されている広く推奨される設計と、あまり一般的でないシナリオに適した設計について説明します。

  • Azure Firewall のみ: この設計は、仮想ネットワークに Web アプリケーションがない場合に使用します。 アプリケーションへの受信トラフィックと送信トラフィックの両方を制御します。

  • Application Gateway のみ: この設計は、Web アプリケーションのみが仮想ネットワーク内にあり、 ネットワーク セキュリティ グループ (NSG) が 十分な出力フィルター処理を提供する場合に使用します。 Azure Firewall には、データ流出や IDPS など、いくつかの攻撃シナリオを防ぐのに役立つ機能が用意されています。 そのため、Application Gateway のみの設計は通常推奨されないため、前のフロー チャートには含まれません。

  • Azure Firewall と Application Gateway の並列化: この設計は、Application Gateway で Web 攻撃から HTTP(S) アプリケーションを保護し、Azure Firewall で他のすべてのワークロードを保護し、送信トラフィックをフィルター処理する場合に使用します。 Azure Firewall と Application Gateway は、一般的な設計です。

  • Azure Firewall の前の Application Gateway: この設計は、Azure Firewall ですべてのトラフィックを検査する場合、Web トラフィックを保護する Web アプリケーション ファイアウォール、およびクライアントのソース IP アドレスを識別するアプリケーションを使用する場合に使用します。 Azure Firewall Premium と TLS 検査では、この設計ではエンド ツー エンドの SSL シナリオもサポートされます。

  • Application Gateway の前の Azure Firewall: この設計は、Azure Firewall が Application Gateway に到達する前にトラフィックを検査およびフィルター処理する場合に使用します。 Azure Firewall では HTTPS トラフィックの暗号化が解除されないため、Application Gateway に追加される機能は制限されます。 このシナリオは、前のフロー チャートには記載されていません。

これらの基本的な設計のバリエーションについては、この記事の後半で説明し、次のものが含まれます。

Azure API Management ゲートウェイや Azure Front Door など、他のリバース プロキシ サービスを追加できます。 または、Azure リソースを Microsoft 以外の ネットワーク仮想アプライアンス (NVA) に置き換えることができます。

手記

次のシナリオでは、Azure 仮想マシン (VM) が Web アプリケーション ワークロードの例として使用されます。 これらのシナリオは、コンテナーや Azure Web Apps などの他のワークロードの種類でも有効です。 プライベート エンドポイントを含むセットアップの場合は、 プライベート エンドポイント宛てのトラフィックを検査する Azure Firewall シナリオの推奨事項を検討してください。

Azure Firewall のみの設計

Web アプリケーション ファイアウォールの利点を活用できる Web ベースのワークロードが仮想ネットワークに存在しない場合は、Azure Firewall 専用の設計を使用できます。 この例の設計は単純ですが、パケット フローを確認して、より複雑な設計をより深く理解することができます。 この設計では、オンプレミスまたはその他の Azure 仮想ネットワークからの接続のために、すべての受信トラフィックがユーザー定義ルート (UDR) を介して Azure Firewall に送信されます。 これは、次の図に示すように、パブリック インターネットからの接続の Azure Firewall パブリック IP アドレスにアドレス指定されます。 UDR は、次のダイアログに示すように、Azure 仮想ネットワークから Azure Firewall に送信トラフィックを送信します。

次の表は、このシナリオのトラフィック フローをまとめたものです。

流れる Application Gateway/Web アプリケーション ファイアウォールを通過する Azure Firewall を通過する
インターネットまたはオンプレミスから Azure への HTTP(S) トラフィック なし はい
Azure からインターネットまたはオンプレミスへの HTTP(S) トラフィック なし はい
インターネットまたはオンプレミスから Azure への HTTP (S) 以外のトラフィック なし はい
Azure からインターネットまたはオンプレミスへの HTTP (S) 以外のトラフィック なし はい

Azure Firewall では、受信 HTTP(S) トラフィックは検査されません。 ただし、レイヤー 3 およびレイヤー 4 の規則と完全修飾ドメイン名 (FQDN) ベースのアプリケーション 規則を適用できます。 Azure Firewall は、Azure Firewall 層と TLS 検査を構成するかどうかに応じて、送信 HTTP(S) トラフィックを検査します。

  • Azure Firewall Standard では、ネットワーク 規則内のパケットのレイヤー 3 およびレイヤー 4 の属性と、アプリケーション 規則のホスト HTTP ヘッダーのみが検査されます。

  • Azure Firewall Premium では、他の HTTP ヘッダー (ユーザー エージェントなど) の検査や、より詳細なパケット分析のための TLS 検査の有効化などの機能が追加されます。 ただし、Azure Firewall は Web アプリケーション ファイアウォールと同じではありません。 仮想ネットワークに Web ワークロードがある場合は、Web アプリケーション ファイアウォールを使用することをお勧めします。

次のパケット ウォークの例は、クライアントがパブリック インターネットから VM でホストされているアプリケーションにアクセスする方法を示しています。 この図には、わかりやすくするために VM が 1 つだけ含まれています。 可用性とスケーラビリティを向上するために、ロード バランサーの背後には複数のアプリケーション インスタンスがあります。 この設計では、Azure Firewall は UDR を使用して、パブリック インターネットからの受信接続とアプリケーション サブネット VM からの送信接続を検査します。

  • この例では、Azure Firewall は、フロントエンド IP アドレス 192.168.100.4 と内部アドレスが 192.168.100.0/26範囲内にある複数のインスタンスを自動的にデプロイします。 通常、これらのインスタンスは Azure 管理者には表示されません。 ただし、それらを認識することは、ネットワークの問題のトラブルシューティングに役立ちます。

  • トラフィックがインターネットではなくオンプレミスの仮想プライベート ネットワーク (VPN) または Azure ExpressRoute ゲートウェイ から送信された場合、クライアントは VM の IP アドレスへの接続を開始します。 ファイアウォールの IP アドレスへの接続は開始せず、ファイアウォールは既定ではソース NAT を実行しません。

建築

次の図は、トラフィック フローを示し、インスタンスの IP アドレスが 192.168.100.7されていることを前提としています。

Azure Firewall のみの設計を示す図。

ワークフロー

  1. クライアントは、Azure Firewall のパブリック IP アドレスへの接続を開始します。

    • 送信元 IP アドレス: ClientPIP
    • 宛先 IP アドレス: AzFwPIP

  2. Azure Firewall パブリック IP アドレスへの要求は、ファイアウォールのバックエンド インスタンスに配布されます。この例では 192.168.100.7 。 Azure Firewall 宛先ネットワーク アドレス変換 (DNAT) 規則 は、宛先 IP アドレスを仮想ネットワーク内のアプリケーション IP アドレスに変換します。 Azure Firewall では、DNAT を使用する場合、パケットに ソース ネットワーク アドレス変換 (SNAT) も実装されます。 詳細については、「azure Firewall の既知の問題する」を参照してください。 VM では、受信パケットに次の IP アドレスが表示されます。

    • 送信元 IP アドレス: 192.168.100.7
    • 宛先 IP アドレス: 192.168.1.4

  3. VM はアプリケーション要求に応答します。この要求により、送信元と宛先の両方の IP アドレスが逆になります。 受信フローでは、ソース IP が Azure Firewall IP アドレスであるため、UDR は必要ありません。 0.0.0.0/0の図の UDR は、パブリック インターネットへのパケットが Azure Firewall を経由するように送信接続を目的としたものです。

    • 送信元 IP アドレス: 192.168.1.4
    • 宛先 IP アドレス: 192.168.100.7

  4. Azure Firewall は SNAT 操作と DNAT 操作を元に戻し、クライアントに応答を配信します。

    • 送信元 IP アドレス: AzFwPIP
    • 宛先 IP アドレス: ClientPIP

Application Gateway のみの設計

この設計では、仮想ネットワークに Web アプリケーションのみが存在し、NSG を使用して送信トラフィックを検査するだけでインターネットへの送信フローを保護できるシナリオについて説明します。

手記

AZURE Firewall を使用して送信フローを制御し、NSG のみに依存するのではなく、データ流出などの攻撃シナリオを防ぐのに役立つため、この設計はお勧めしません。 Azure Firewall を使用すると、ワークロードが承認された URL の一覧にのみデータを送信するように支援できます。 また、NSG はレイヤー 3 とレイヤー 4 でのみ動作し、FQDN はサポートされません。

前の Azure Firewall のみの設計との主な違いは、Application Gateway が NAT を使用するルーティング デバイスとして機能しないという点です。 代わりに、完全なリバース アプリケーション プロキシとして機能します。 この方法は、Application Gateway がクライアントからの Web セッションを停止し、バックエンド サーバーの 1 つと別のセッションを確立することを意味します。 インターネットからの受信 HTTP (S) 接続は Application Gateway のパブリック IP アドレスに送信され、Azure またはオンプレミスからの接続ではゲートウェイのプライベート IP アドレスが使用されます。 Azure VM からの戻りトラフィックは、Application Gateway への標準の仮想ネットワーク ルーティングに従います。 詳細については、この記事の後半のパケット ウォークを参照してください。 Azure VM からの送信インターネット フローは、インターネットに直接送信されます。

次の表は、トラフィック フローをまとめたものです。

流れる Application Gateway/Web アプリケーション ファイアウォールを通過する Azure Firewall を通過する
インターネットまたはオンプレミスから Azure への HTTP(S) トラフィック はい なし
Azure からインターネットまたはオンプレミスへの HTTP(S) トラフィック いいえ なし
インターネットまたはオンプレミスから Azure への HTTP (S) 以外のトラフィック いいえ なし
Azure からインターネットまたはオンプレミスへの HTTP (S) 以外のトラフィック いいえ なし

建築

次のパケット ウォークの例は、クライアントがパブリック インターネットから VM でホストされるアプリケーションにアクセスする方法を示しています。

Application Gateway のみの設計を示す図。

ワークフロー

  1. クライアントは、Application Gateway のパブリック IP アドレスへの接続を開始します。

    • 送信元 IP アドレス: ClientPIP
    • 宛先 IP アドレス: AppGwPIP

  2. Application Gateway パブリック IP アドレスへの要求は、ゲートウェイのバックエンド インスタンスに配布されます。この例では 192.168.200.7 。 要求を受信する Application Gateway インスタンスは、クライアントからの接続を停止し、いずれかのバックエンドとの新しい接続を確立します。 バックエンドでは、Application Gateway インスタンスがソース IP アドレスとして表示されます。 Application Gateway は、元のクライアントの IP アドレスを持つ X-Forwarded-For HTTP ヘッダーを挿入します。

    • ソース IP アドレス。Application Gateway インスタンスのプライベート IP アドレスです。 192.168.200.7
    • 宛先 IP アドレス: 192.168.1.4
    • X-Forwarded-For ヘッダ： ClientPIP

  3. VM はアプリケーション要求に応答し、送信元 IP アドレスと宛先 IP アドレスの両方を反転します。 VM は Application Gateway に到達できるため、UDR は必要ありません。

    • 送信元 IP アドレス: 192.168.1.4
    • 宛先 IP アドレス: 192.168.200.7

  4. Application Gateway インスタンスがクライアントに応答します。

    • 送信元 IP アドレス: AppGwPIP
    • 宛先 IP アドレス: ClientPIP

Application Gateway は、元のクライアントの IP アドレスを含む X-Forwarded-For ヘッダーなどのメタデータをパケット HTTP ヘッダーに追加します。 一部のアプリケーション サーバーでは、位置情報固有のコンテンツを提供したり、ログを記録したりするために、ソース クライアントの IP アドレスが必要です。 詳細については、「アプリケーション ゲートウェイの動作」を参照してください。

  • この例では、 192.168.200.7 IP アドレスは、Application Gateway サービスによって自動的にデプロイされるインスタンスの 1 つです。 内部のプライベート フロントエンド IP アドレス 192.168.200.4。 これらの個々のインスタンスは、通常、Azure 管理者には表示されません。 ただし、ネットワークの問題をトラブルシューティングする場合など、この違いに気付くと便利です。

  • このフローは、クライアントが VPN または ExpressRoute ゲートウェイ経由でオンプレミス ネットワークから送信される場合と似ています。 違いは、クライアントがパブリック IP アドレスではなく Application Gateway のプライベート IP アドレスにアクセスすることです。

手記

X-Forwarded-For ヘッダーと要求でホスト名を保持する方法の詳細については、「元の HTTP ホストを保持する」を参照してください。

Azure Firewall と Application Gateway の並列設計

そのシンプルさと柔軟性のため、多くの場合、Application Gateway と Azure Firewall を並列で実行することをお勧めしています。

仮想ネットワークに Web ワークロードと非 Web ワークロードの両方がある場合は、この設計を実装します。 Application Gateway の Web アプリケーション ファイアウォールは、Web ワークロードへの受信トラフィックを保護するのに役立ちます。 Azure Firewall は、他のアプリケーションの受信トラフィックを検査します。 Azure Firewall では、両方のワークロードの種類からの送信フローが対象となります。

インターネットからの受信 HTTP (S) 接続は、Application Gateway のパブリック IP アドレスに送信する必要があります。 Azure またはオンプレミスからの HTTP(S) 接続は、そのプライベート IP アドレスに送信する必要があります。 Standard 仮想ネットワーク ルーティングは、Application Gateway から宛先 VM にパケットを送信し、宛先 VM から Application Gateway にパケットを送信します。 詳細については、この記事の後半のパケット ウォークを参照してください。

HTTP (S) 以外の受信接続の場合、トラフィックはパブリック インターネットから送信される場合、Azure Firewall のパブリック IP アドレスをターゲットにする必要があります。 他の Azure 仮想ネットワークまたはオンプレミス ネットワークから送信される場合は、UDR によって Azure Firewall 経由でトラフィックを送信する必要があります。 Azure VM からの送信フローはすべて、UDR によって Azure Firewall に転送されます。

次の表は、このシナリオのトラフィック フローをまとめたものです。

流れる Application Gateway/Web アプリケーション ファイアウォールを通過する Azure Firewall を通過する
インターネットまたはオンプレミスから Azure への HTTP(S) トラフィック はい いいえ
Azure からインターネットまたはオンプレミスへの HTTP(S) トラフィック いいえ はい
インターネットまたはオンプレミスから Azure への HTTP (S) 以外のトラフィック いいえ はい
Azure からインターネットまたはオンプレミスへの HTTP (S) 以外のトラフィック いいえ はい

この設計では、NSG のみを使用するよりもはるかに細かいエグレス フィルタリングが提供されます。 たとえば、アプリケーションで特定の Azure Storage アカウントへの接続が必要な場合は、FQDN ベースのフィルターを使用できます。 FQDN ベースのフィルターでは、アプリケーションは不正なストレージ アカウントにデータを送信しません。 NSG のみを使用する場合、このシナリオを回避することはできません。 この設計は、送信トラフィックで FQDN ベースのフィルター処理が必要な場合によく使用されます。 1 つのシナリオは、 AKS クラスターからのエグレス トラフィックを制限する場合です。

アーキテクチャ

次の図は、外部クライアントからの受信 HTTP(S) 接続のトラフィック フローを示しています。

Application Gateway と Azure Firewall を並列に使用したイングレス フローを示す図。

次の図は、ネットワーク VM からインターネットへの送信接続のトラフィック フローを示しています。 1 つの例として、バックエンド システムに接続するか、オペレーティング システムの更新プログラムを取得します。

Application Gateway と Azure Firewall を並列に使用したエグレス フローを示す図。

各サービスのパケット フローステップは、前のスタンドアロン 設計オプションと同じです。

Azure Firewall 設計の前の Application Gateway

この設計については、 Azure Firewall と Application Gateway を使用する Web アプリケーションのゼロトラスト ネットワークで詳しく説明します。 この記事では、他の設計オプションとの比較について説明します。 このトポロジでは、受信 Web トラフィックは Azure Firewall と Web アプリケーション ファイアウォールの両方を通過します。 Web アプリケーション ファイアウォールは、Web アプリケーション 層で保護を提供します。 Azure Firewall は、中央のログ記録と制御ポイントとして機能し、Application Gateway とバックエンド サーバーの間のトラフィックを検査します。 この設計では、Application Gateway と Azure Firewall は並列ではなく、もう一方の前に配置されます。

Azure Firewall Premium では、この設計でエンド ツー エンドのシナリオをサポートできます。このシナリオでは、Azure Firewall が TLS 検査を適用して、Application Gateway と Web バックエンドの間の暗号化されたトラフィックに対して IDPS を実行します。

この設計は、受信クライアント ソース IP アドレスを識別する必要があるアプリケーションに適しています。 たとえば、位置情報固有のコンテンツの提供やログ記録に使用できます。 Azure Firewall 設計の前にある Application Gateway は、受信パケットの送信元 IP アドレスを X-Forwarded-For ヘッダーにキャプチャするため、Web サーバーはこのヘッダーに元の IP アドレスを表示できます。 詳細については、「アプリケーション ゲートウェイの動作」を参照してください。

インターネットからの受信 HTTP(S) 接続は、Application Gateway のパブリック IP アドレスに送信する必要があります。 Azure またはオンプレミスからの HTTP(S) 接続は、そのプライベート IP アドレスに送信する必要があります。 Application Gateway から、UDR によって、パケットが Azure Firewall 経由でルーティングされることが保証されます。 詳細については、この記事の後半のパケット ウォークを参照してください。

HTTP (S) 以外の受信接続の場合、トラフィックはパブリック インターネットから送信される場合、Azure Firewall のパブリック IP アドレスをターゲットにする必要があります。 他の Azure 仮想ネットワークまたはオンプレミス ネットワークから送信される場合は、UDR によって Azure Firewall 経由でトラフィックを送信する必要があります。 Azure VM からの送信フローはすべて、UDR によって Azure Firewall に転送されます。

この設計の重要な側面は、Azure Firewall Premium が Application Gateway サブネットからのソース IP アドレスを持つトラフィックを確認することです。 このサブネットがプライベート IP アドレス ( 10.0.0.0/8、 192.168.0.0/16、 172.16.0.0/12、または 100.64.0.0/10) で構成されている場合、Azure Firewall Premium は Application Gateway からのトラフィックを内部として扱い、受信トラフィックに IDPS 規則を適用しません。 その結果、Azure Firewall ポリシーの IDPS プライベート プレフィックスを変更することをお勧めします。 この変更により、Application Gateway サブネットが内部ソースと見なされず、受信 IDPS 署名と送信 IDPS 署名をトラフィックに適用できるようになります。 Azure Firewall IDPS ルールのルート案内と IDPS のプライベート IP プレフィックスの詳細については、 Azure Firewall IDPS 規則を参照してください。

次の表は、このシナリオのトラフィック フローをまとめたものです。

流れる Application Gateway/Web アプリケーション ファイアウォールを通過する Azure Firewall を通過する
インターネットまたはオンプレミスから Azure への HTTP(S) トラフィック はい はい
Azure からインターネットまたはオンプレミスへの HTTP(S) トラフィック いいえ はい
インターネットまたはオンプレミスから Azure への HTTP (S) 以外のトラフィック いいえ はい
Azure からインターネットまたはオンプレミスへの HTTP (S) 以外のトラフィック いいえ はい

オンプレミスまたはインターネットから Azure への Web トラフィックの場合、Azure Firewall は Web アプリケーション ファイアウォールが許可するフローを検査します。 Application Gateway がバックエンド トラフィック (Application Gateway からアプリケーション サーバーへのトラフィック) を暗号化するかどうかに応じて、さまざまなシナリオが発生する可能性があります。

  • Application Gateway は、 エンドツーエンドの TLS 暗号化などのゼロトラスト原則に従ってトラフィックを暗号化し、Azure Firewall は暗号化されたトラフィックを受信します。 Azure Firewall Standard では、TLS サーバー名表示 (SNI) ヘッダーを使用して、ネットワーク 規則のレイヤー 3 とレイヤー 4 のフィルター処理や、アプリケーション ルールでの FQDN フィルター処理などの検査規則を適用できます。 Azure Firewall Premium では、URL ベースのフィルター処理など、TLS 検査により詳細な可視性が提供されます。

  • Application Gateway が暗号化されていないトラフィックをアプリケーション サーバーに送信する場合、Azure Firewall はクリア テキストで受信トラフィックを確認します。 Azure Firewall では TLS 検査は必要ありません。

  • Azure Firewall で IDPS が有効になっている場合は、HTTP ホスト ヘッダーが宛先 IP アドレスと一致することを確認します。 この検証を実行するには、ホスト ヘッダーで指定されている FQDN の名前解決が必要です。 この名前解決は、Azure DNS プライベート ゾーンと既定の Azure Firewall DNS 設定を使用して実行できます。 また、Azure Firewall の設定で構成する必要があるカスタム DNS サーバーを使用して実現することもできます。 Azure Firewall がデプロイされている仮想ネットワークへの管理アクセス権がない場合は、後者の方法が唯一のオプションです。 1 つの例として、Azure Virtual WAN で保護されたハブにデプロイされた Azure Firewall インスタンスがあります。

建築

受信非 HTTP(S) トラフィックや送信トラフィックを含む残りのフローでは、Azure Firewall は適切な場合に IDPS 検査と TLS 検査を提供します。 また、DNS に基づくネットワーク ルール の FQDN ベースのフィルター処理 も提供します。

Azure Firewall 設計の前にある Application Gateway を示す図。

ワークフロー

パブリック インターネットからのネットワーク トラフィックは、次のフローに従います。

  1. クライアントは、Application Gateway のパブリック IP アドレスへの接続を開始します。

    • 送信元 IP アドレス: ClientPIP
    • 宛先 IP アドレス: AppGwPIP

  2. Application Gateway パブリック IP アドレスへの要求は、ゲートウェイのバックエンド インスタンスに配布されます。この例では 192.168.200.7 。 Application Gateway インスタンスは、クライアントからの接続を停止し、バックエンドのいずれかとの新しい接続を確立します。 Application Gateway サブネットで 192.168.1.0/24 する UDR は、パケットを Azure Firewall に転送し、宛先 IP アドレスを Web アプリケーションに保持します。

    • ソース IP アドレス。Application Gateway インスタンスのプライベート IP アドレスです。 192.168.200.7
    • 宛先 IP アドレス: 192.168.1.4
    • X-Forwarded-For ヘッダ： ClientPIP

  3. トラフィックはプライベート IP アドレスに送信されるため、Azure Firewall はトラフィックに SNAT を適用しません。 ルールで許可されている場合は、トラフィックがアプリケーション VM に転送されます。 詳細については、「Azure Firewall の SNAT プライベート IP アドレス範囲」を参照してください。 ただし、トラフィックがファイアウォールのアプリケーション規則にヒットした場合、Azure Firewall が接続をプロキシするため、パケットを処理した特定のファイアウォール インスタンスの送信元 IP アドレスがワークロードに表示されます。

    • トラフィックが Azure Firewall ネットワーク規則によって許可され、Application Gateway インスタンスのプライベート IP アドレスである場合は、ソース IP アドレス。 192.168.200.7
    • トラフィックが Azure Firewall アプリケーション規則によって許可され、Azure Firewall インスタンスのプライベート IP アドレスである場合は、ソース IP アドレス。 192.168.100.7
    • 宛先 IP アドレス: 192.168.1.4
    • X-Forwarded-For ヘッダ： ClientPIP

  4. VM が要求に応答します。この要求により、送信元と宛先の両方の IP アドレスが逆になります。 192.168.200.0/24する UDR は、Application Gateway に送り返されたパケットをキャプチャし、それを Azure Firewall にリダイレクトし、宛先 IP アドレスを Application Gateway に保持します。

    • 送信元 IP アドレス: 192.168.1.4
    • 宛先 IP アドレス: 192.168.200.7

  5. ここでも、Azure Firewall はプライベート IP アドレスに移動し、トラフィックを Application Gateway に転送するため、トラフィックに SNAT を適用しません。

    • 送信元 IP アドレス: 192.168.1.4
    • 宛先 IP アドレス: 192.168.200.7

  6. Application Gateway インスタンスがクライアントに応答します。

    • 送信元 IP アドレス: AppGwPIP
    • 宛先 IP アドレス: ClientPIP

VM からパブリック インターネットへの送信フローは、 0.0.0.0/0 する UDR が定義する Azure Firewall を経由します。

この設計の一種として、Azure Firewall でプライベート DNAT を構成して、アプリケーション ワークロードが Azure Firewall インスタンスの IP アドレスをソースとして見て、UDR が不要になるようにすることができます。 アプリケーション クライアントのソース IP アドレスは、Application Gateway によって X-Forwarded-For HTTP ヘッダーに既に保持されています。 そのため、Azure Firewall がトラフィックに DNAT を適用した場合、情報は失われません。 詳細については、「 Azure portal を使用して Azure Firewall ポリシー DNAT を使用して受信インターネットまたはイントラネット トラフィックをフィルター処理する」を参照してください。

Application Gateway 設計の前の Azure Firewall

この設計により、Azure Firewall は Application Gateway に到達する前に悪意のあるトラフィックをフィルター処理して破棄できます。 たとえば、脅威インテリジェンス ベースのフィルター処理などの機能を適用できます。 もう 1 つの利点は、プロトコルに関係なく、アプリケーションが受信トラフィックと送信トラフィックの両方で同じパブリック IP アドレスを取得することです。 Azure Firewall を理論的に構成できるモードは 3 つあります。

  • DNAT 規則を使用した Azure Firewall: Azure Firewall では、IP アドレスレイヤーの IP アドレスのみがスワップされますが、ペイロードは処理されません。 その結果、HTTP ヘッダーは変更されません。

  • アプリケーション規則と TLS 検査が無効になっている Azure Firewall: Azure Firewall は TLS で SNI ヘッダーを確認できますが、暗号化を解除しません。 ファイアウォールから次ホップへの新しい TCP 接続が作成されます。 この例では、Application Gateway です。

  • アプリケーション規則と TLS 検査が有効になっている Azure Firewall: Azure Firewall はパケットの内容を調べ、暗号化を解除します。 これは HTTP プロキシとして機能し、IP アドレスを保持するように HTTP ヘッダー X-Forwarded-For を設定できます。 ただし、自己生成証明書がクライアントに提示されます。 インターネット ベースのアプリケーションでは、セキュリティ警告がブラウザーからアプリケーション クライアントに送信されるため、自己生成証明書の使用はオプションではありません。

インターネット ベースのアプリケーションで唯一有効なオプションである最初の 2 つのオプションでは、Azure Firewall は、 X-Forwarded-For ヘッダーを設定せずに受信トラフィックに SNAT を適用します。 その結果、アプリケーションは HTTP 要求の元の IP アドレスを確認できません。 トラブルシューティングなどの管理タスクでは、Azure Firewall の SNAT ログと関連付けることで、特定の接続の実際のクライアント IP アドレスを取得できます。

TLS 検査を使用してクライアントに自己生成証明書を提示しない限り、Azure Firewall では Application Gateway に送信される暗号化されたトラフィックのみが表示されるため、このシナリオの利点は限られています。 通常、このシナリオは内部アプリケーションでのみ可能です。 ただし、この設計が推奨されるシナリオもあります。 1 つのシナリオは、ネットワークの前に別の Web アプリケーション ファイアウォールが存在する場合です ( たとえば、Azure Front Door を使用して)、元のソース IP を X-Forwarded-For HTTP ヘッダーにキャプチャできます。 また、Application Gateway で 1 つの IP アドレスがサポートされるため、多くのパブリック IP アドレスが必要な場合は、この設計をお勧めします。

パブリック インターネットからの HTTP(S) 受信フローは、Azure Firewall のパブリック IP アドレスをターゲットにする必要があります。 Azure Firewall は、パケットを Application Gateway のプライベート IP アドレスに DNAT および SNAT します。 他の Azure 仮想ネットワークまたはオンプレミス ネットワークから、HTTP(S) トラフィックを Application Gateway プライベート IP アドレスに送信し、UDR を使用して Azure Firewall 経由で転送する必要があります。 標準の仮想ネットワーク ルーティングにより、DNAT 規則が使用された場合、Azure VM からのリターン トラフィックが Application Gateway に戻り、Application Gateway から Azure Firewall に戻ります。 オンプレミスまたは Azure からのトラフィックの場合は、Application Gateway サブネットの UDR を使用します。 詳細については、この記事の後半のパケット ウォークを参照してください。 Azure VM からインターネットへのすべての送信トラフィックは、UDR によって Azure Firewall 経由で送信されます。

次の表は、このシナリオのトラフィック フローをまとめたものです。

流れる Application Gateway/Web アプリケーション ファイアウォールを通過する Azure Firewall を通過する
インターネットまたはオンプレミスから Azure への HTTP(S) トラフィック はい はい
Azure からインターネットまたはオンプレミスへの HTTP(S) トラフィック いいえ はい
インターネットまたはオンプレミスから Azure への HTTP (S) 以外のトラフィック いいえ はい
Azure からインターネットまたはオンプレミスへの HTTP (S) 以外のトラフィック いいえ はい

受信 HTTP(S) トラフィックの場合、通常、Azure Firewall はトラフィックの暗号化を解除しません。 代わりに、IP アドレスベースのフィルター処理や HTTP ヘッダーの使用など、TLS 検査を必要としない IDPS ポリシーが適用されます。

建築

アプリケーションでは、Web トラフィックの元のソース IP アドレスを確認できません。 Azure Firewall は、仮想ネットワークに入ってくるパケットに SNAT を適用します。 この問題を回避するには、ファイアウォールの前 Azure Front Door を使用します。 Azure Front Door は、Azure 仮想ネットワークに入る前に、クライアントの IP アドレスを HTTP ヘッダーとして挿入します。

Azure Firewall の後に Application Gateway を示す図。

ワークフロー

パブリック インターネットからのネットワーク トラフィックは、次のフローに従います。

  1. クライアントは、Azure Firewall のパブリック IP アドレスへの接続を開始します。

    • 送信元 IP アドレス: ClientPIP
    • 宛先 IP アドレス: AzFWPIP

  2. Azure Firewall パブリック IP アドレスへの要求は、ファイアウォールのバックエンド インスタンスに配布されます。この例では 192.168.100.7 。 Azure Firewall は、Web ポート (通常は TCP 443) に、Application Gateway インスタンスのプライベート IP アドレスに DNAT を適用します。 Azure Firewall は、DNAT の実行時にも SNAT を適用します。 詳細については、「azure Firewall の既知の問題する」を参照してください。

    • ソース IP アドレス。これは Azure Firewall インスタンスのプライベート IP アドレスです。 192.168.100.7
    • 宛先 IP アドレス: 192.168.200.4

  3. Application Gateway は、接続を処理するインスタンスとバックエンド サーバーの 1 つとの間に新しいセッションを確立します。 クライアントの元の IP アドレスがパケット内にありません。

    • ソース IP アドレス。Application Gateway インスタンスのプライベート IP アドレスです。 192.168.200.7
    • 宛先 IP アドレス: 192.168.1.4
    • X-Forwarded-For ヘッダ： 192.168.100.7

  4. VM は Application Gateway に応答します。これは、送信元と宛先の両方の IP アドレスを逆にします。

    • 送信元 IP アドレス: 192.168.1.4
    • 宛先 IP アドレス: 192.168.200.7

  5. Application Gateway は、Azure Firewall インスタンスの SNAT ソース IP アドレスに応答します。 Azure Firewall では、接続が .4 などの特定の Application Gateway インスタンスから取得された場合でも、.7 Application Gateway の内部 IP アドレスがソース IP アドレスとして表示されます。

    • 送信元 IP アドレス: 192.168.200.4
    • 宛先 IP アドレス: 192.168.100.7

  6. Azure Firewall は SNAT と DNAT を元に戻し、クライアントに応答します。

    • 送信元 IP アドレス: AzFwPIP
    • 宛先 IP アドレス: ClientPIP

Application Gateway には、アプリケーション用に構成されたリスナーがない場合でも、Microsoft が管理できるようにパブリック IP アドレスが必要です。

手記

Azure Firewall を指す Application Gateway サブネット内の 0.0.0.0/0 への既定のルートはサポートされていません。これは、Application Gateway が正常に機能するために必要なコントロール プレーン トラフィックを中断するためです。

オンプレミス クライアント

上記の設計はすべて、パブリック インターネットからの受信アプリケーション クライアントを示しています。 オンプレミス ネットワークは、アプリケーションにもアクセスします。 以前の情報とトラフィック フローのほとんどはインターネット クライアントの場合と同じですが、いくつかの顕著な違いがあります。

  • VPN ゲートウェイまたは ExpressRoute ゲートウェイは、Azure Firewall または Application Gateway の前に配置されます。

  • Web アプリケーション ファイアウォールは、Application Gateway のプライベート IP アドレスを使用します。

  • Azure Firewall はプライベート IP アドレスの DNAT をサポートしていないため、UDR を使用して VPN または ExpressRoute ゲートウェイから Azure Firewall に受信トラフィックを送信する必要があります。

  • Application Gateway と Azure Firewall の強制トンネリングに関する注意事項を確認してください。 ワークロードがパブリック インターネットへの送信接続を必要としない場合でも、制御トラフィックが中断されるため、オンプレミス ネットワークを指す Application Gateway の 0.0.0.0/0 などの既定のルートを挿入することはできません。 Application Gateway の場合、既定のルートはパブリック インターネットを指す必要があります。

建築

次の図は、Application Gateway と Azure Firewall の並列設計を示しています。 アプリケーション クライアントは、VPN または ExpressRoute 経由で Azure に接続されているオンプレミス ネットワークから取得されます。

VPN または ExpressRoute ゲートウェイを使用したハイブリッド設計を示す図。

すべてのクライアントがオンプレミスまたは Azure に配置されている場合でも、Application Gateway と Azure Firewall の両方にパブリック IP アドレスが必要です。 これらのパブリック IP アドレスを使用すると、Microsoft はサービスを管理できます。

ハブアンドスポーク トポロジ

この記事の設計は 、ハブ アンド スポーク トポロジに適用されます。 中央ハブ仮想ネットワーク内の共有リソースは、仮想ネットワーク ピアリングを介して個別のスポーク仮想ネットワーク内のアプリケーションに接続します。

建築

VPN および Expressroute ゲートウェイとハブアンドスポーク トポロジを使用したハイブリッド設計を示す図。

  • Azure Firewall は、中央ハブ仮想ネットワークにデプロイされます。 前の図は、Application Gateway をハブにデプロイする方法を示しています。 アプリケーション チームは、多くの場合、Application Gateway や API Management ゲートウェイなどのコンポーネントを管理します。 このシナリオでは、これらのコンポーネントがスポーク仮想ネットワークにデプロイされます。

  • スポーク ネットワーク内の UDR には特に注意してください。 スポーク内のアプリケーション サーバーが、前の例の 192.168.100.7 IP アドレスなど、特定の Azure Firewall インスタンスからのトラフィックを受信した場合は、リターン トラフィックを同じインスタンスに送り返す必要があります。 スポーク内の UDR がハブ宛てトラフィックの次ホップを Azure Firewall IP アドレス (前の図で192.168.100.4 ) に設定すると、戻りパケットが別の Azure Firewall インスタンスで終了する可能性があります。 この状況により、非対称ルーティングが発生します。 スポーク仮想ネットワークに UDR がある場合は、Azure Firewall 経由でハブ内の共有サービスにトラフィックを送信してください。 これらの UDR には、Azure Firewall サブネットのプレフィックスは含まれません。

  • 前の推奨事項は、Application Gateway サブネットと、ハブ仮想ネットワークにデプロイされる可能性があるその他の NVA またはリバース プロキシにも同様に適用されます。

  • 次ホップの種類が Virtual Networkの静的ルートを介して、Application Gateway または Azure Firewall サブネットの次ホップを設定することはできません。 この次ホップの種類は、ローカル仮想ネットワークでのみ有効であり、仮想ネットワーク ピアリング間では有効ではありません。 UDR と次ホップの種類の詳細については、「 仮想ネットワーク トラフィック ルーティング」を参照してください。

非対称ルーティング

次の図は、スポークが SNAT トラフィックを Azure Firewall の Azure ロード バランサーに送り返す方法を示しています。 このセットアップにより、非対称ルーティングが発生します。

ハブ アンド スポーク トポロジでの非対称ルーティングを示す図。

この問題を解決するには、Azure Firewall サブネットを使用せず、共有サービスが配置されているサブネットのみを使用して、スポーク内の UDR を定義します。 前の図では、スポーク内の正しい UDR には 192.168.1.0/24のみが含まれている必要があります。 範囲 192.168.0.0/16全体を含めることはできません。この範囲は赤でマークされています。

他の Azure 製品との統合

Azure Firewall と Application Gateway は、他の Azure 製品やサービスと統合できます。

API Management ゲートウェイ

API Management ゲートウェイなどのリバース プロキシ サービスを以前の設計に統合して、API 調整や認証プロキシなどの機能を提供します。 API Management ゲートウェイの統合は、設計に大きな影響を与えません。 主な違いは、1 つの Application Gateway リバース プロキシの代わりに、2 つのリバース プロキシが相互にチェーンされていることです。

詳細については、 仮想ネットワークに API Management と Application Gateway を統合するための設計ガイド と、 マイクロサービス用のアプリケーション パターン API ゲートウェイを参照してください。

AKS

AKS クラスターで実行されるワークロードの場合は、クラスターとは別に Application Gateway をデプロイできます。 または、 Application Gateway イングレス コントローラーを使用して AKS クラスターと統合することもできます。 サービスやイングレスなど、Kubernetes レベルで特定のオブジェクトを構成すると、追加の手動手順を必要とせずに Application Gateway が自動的に調整されます。

Azure Firewall は、AKS クラスターのセキュリティにおいて重要な役割を果たします。 IP アドレスだけでなく、FQDN に基づいて AKS クラスターからのエグレス トラフィックをフィルター処理するために必要な機能が提供されます。 詳細については、「 AKS の Azure Firewall を使用してネットワーク トラフィックを制限する」を参照してください。

Application Gateway と Azure Firewall を組み合わせて AKS クラスターを保護する場合は、並列設計オプションを使用することをお勧めします。 Application Gateway with Web Application Firewall は、クラスター内の Web アプリケーションへの受信接続要求を処理します。 Azure Firewall では、明示的に許可された送信接続のみが許可されます。 並列設計オプションの詳細については、「 AKS クラスターのベースライン アーキテクチャ」を参照してください。

Azure Front Door（アジュール フロント ドア）

Azure Front Door には、いくつかの領域で Application Gateway と重複する機能があります。 どちらのサービスも、Web アプリケーションのファイアウォール、SSL オフロード、URL ベースのルーティングを提供します。 ただし、主な違いは、Application Gateway が仮想ネットワーク内で動作する一方で、Azure Front Door はグローバルで分散型のサービスであるということです。

Application Gateway を分散型の Azure Front Door に置き換えることで、仮想ネットワークの設計を簡略化できる場合があります。 Azure Front Door の前に Azure Firewall を配置するオプションを除き、この記事で説明されているほとんどの設計は引き続き適用されます。

1 つのシナリオは、仮想ネットワーク内の Application Gateway の前で Azure Firewall を使用することです。 Application Gateway は、クライアントの IP アドレスではなく、ファイアウォール インスタンスの IP アドレスを使用して X-Forwarded-For ヘッダーを挿入します。 回避策は、ファイアウォールの前で Azure Front Door を使用して、トラフィックが仮想ネットワークに入って Azure Firewall に到達する前に、クライアントの IP アドレスを X-Forwarded-For ヘッダーとして挿入することです。 また、 Azure Front Door Premium の Azure Private Link を使用して配信元をセキュリティで保護することもできます。

2 つのサービスの違い、または各サービスを使用するタイミングの詳細については、 Azure Front Door に関してよく寄せられる質問を参照してください。

その他の NVA

Microsoft 製品は、Azure に Web アプリケーション ファイアウォールまたは次世代ファイアウォール機能を実装する唯一の選択肢ではありません。 さまざまな Microsoft パートナーが NVA を提供しています。 概念と設計は基本的にこの記事と同じですが、いくつかの重要な考慮事項があります。

  • 次世代ファイアウォール用のパートナー NVA は、Azure Firewall でサポートされていない NAT 構成に対して、より詳細な制御と柔軟性を提供する場合があります。 例としては、オンプレミスの DNAT や、SNAT を使用しないインターネットからの DNAT などがあります。

  • Application Gateway や Azure Firewall などの Azure で管理される NVA は、ユーザーが多くのアプライアンスでスケーラビリティと回復性を処理する必要がある NVA と比較して、複雑さを軽減します。

  • Azure で NVA を使用する場合は、 アクティブ/アクティブ および 自動スケールのセットアップを 使用して、これらのアプライアンスが仮想ネットワークで実行されるアプリケーションのボトルネックにならないようにします。

貢献

Microsoft では、この記事を保持しています。 次の共同作成者がこの記事を書きました。

プリンシパルの作成者:

公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。

次の手順

コンポーネント テクノロジの詳細については、以下をご覧ください。

関連するアーキテクチャを調べる: