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

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

• Azure DDoS Protection では、アプリケーションの設計に関するベスト プラクティスと組み合わせることにより、DDoS 攻撃からの保護を向上させるための強化された DDoS 軽減機能が提供されます。 すべての境界仮想ネットワークで Azure DDOS Protection を有効にする必要があります。
• Azure Firewall は、ネットワークアドレス変換 (NAT) を提供するマネージド次世代ファイアウォールです。 Azure Firewall では、インターネット プロトコル (IP) アドレスと伝送制御プロトコルおよびユーザー データグラム プロトコル (TCP/UDP) のポート、あるいはアプリケーション ベースの HTTP(S) または SQL 属性に基づいて、パケット フィルタリングが行われます。 また Azure Firewall では、Microsoft 脅威インテリジェンスも適用して、悪意のある IP アドレスを特定します。 詳細については、Azure Firewall のドキュメントをご覧ください。
• Azure Firewall Premium には、Azure Firewall Standard のすべての機能に加えて、TLS 検査や IDPS (侵入検出および防止システム) などの他の機能が含まれます。
• Azure Application Gateway は、Secure Sockets Layer (SSL) 暗号化と解読を実行できる、マネージド Web トラフィック ロード バランサーであり、完全な HTTP(S) リバース プロキシです。 Application Gateway は、X-Forwarded-For HTTP ヘッダー内の元のクライアント IP アドレスを保持します。 また、Application Gateway では、Web アプリケーション ファイアウォールを使用して、HTTP レイヤーで Web トラフィックを検査し、攻撃を検出します。 詳細については、Application Gateway のドキュメントをご覧ください。
• Azure Web Application Firewall (WAF) は、必要に応じて Azure Application Gateway に追加できます。 これによって HTTP 要求を検査し、SQL インジェクションやクロスサイト スクリプティングなど、Web レイヤーでの悪意のある攻撃を防ぐことができます。 詳細については、Web アプリケーション ファイアウォールのドキュメントをご覧ください。

これらの Azure サービスは補完的です。 どちらか一方がお客様のワークロードに最適である場合もあれば、これらを統合して、ネットワークとアプリケーション レイヤーの両方で最適な保護を実現することもできます。 次のディシジョン ツリーとこの記事の例を使用して、アプリケーションの仮想ネットワークに最適なセキュリティ オプションを決定してください。

Azure Firewall と Azure Application Gateway では異なるテクノロジを利用しており、さまざまなフローのセキュリティ保護をサポートしています。

アプリケーションに必要なネットワーク フローに応じて、設計はアプリケーションごとに異なる場合があります。 次の図に、アプリケーションに推奨されるアプローチを選ぶのに役立つ、簡略化されたデシジョン ツリーを示します。 決定は、アプリケーションが HTTP(S) と他のプロトコルのどちらを使用して公開されているかによって異なります。

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

• 仮想ネットワークに Web アプリケーションがない場合は、Azure Firewall のみを使用します。 これによってアプリケーションへのインバウンド トラフィックとアウトバウンド トラフィックの両方が制御されます。
• 仮想ネットワークに Web アプリケーションだけが存在し、ネットワーク セキュリティ グループ (NSG) によって十分な出力フィルタリングが提供される場合は、Application Gateway のみを使用します。 Azure Firewall によって提供される機能により、多くの攻撃シナリオ (データ流出、IDPS など) を防ぐことができます。 このため、Application Gateway のみのシナリオは通常推奨されないため、文書化されておらず、上記のフロー チャートには含まれていません。
• Azure Firewall と Application Gateway を並列で使用する。これは、最も一般的な設計の 1 つです。 Azure Application Gateway で HTTP(S) アプリケーションを Web 攻撃から保護し、Azure Firewall で他のすべてのワークロードの保護とアウトバウンド トラフィックのフィルター処理を行う場合にこの組み合わせを使用します。
• Azure Firewall ですべてのトラフィックを検査すると共に、WAF で Web トラフィックを保護し、さらに、アプリケーションがクライアントの送信元 IP アドレスを知る必要がある場合は、Azure Firewall の前に Application Gateway を使用します。 Azure Firewall Premium および TLS 検査を使用する場合、この設計によってエンドツーエンドの SSL シナリオもサポートされます。
• Application Gateway に到達する前のトラフィックを Azure Firewall で検査してフィルター処理する場合は、Application Gateway の前に Azure Firewall を使用します。 Azure ファイアウォールでは HTTPS トラフィックの暗号化の解除は行われないため、Application Gateway に追加される機能は限られています。 このシナリオは上記のフロー チャートには含まれていません。

この記事の最後の部分で、先に説明した基本的な設計のバリエーションを説明します。 バリエーションには次が含まれます。

• オンプレミスのアプリケーション クライアント。
• ハブとスポークのネットワーク。
• Azure Kubernetes Service (AKS) の実装。

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

Azure Firewall のみ

WAF のメリットが得られる Web ベースのワークロードが仮想ネットワークにない場合は、Azure Firewall のみを使用できます。 この場合の設計は単純ですが、パケット フローを確認すると、より複雑な設計を理解しやすくなります。 この設計では、すべての受信トラフィックが、オンプレミスまたはその他の Azure VNet からの接続に対するユーザー定義ルート (UDR) 経由で Azure Firewall に送信されます。 これは、以下の図に示すように、パブリック インターネットからの接続に対する Azure Firewall のパブリック IP アドレスにアドレス指定されます。 次の図に示すように、Azure VNet からの送信トラフィックは UDR 経由でファイアウォールに送信されます。

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

Azure Firewall によってインバウンド HTTP(S) トラフィックが検査されることはありません。 ただし、レイヤー 3 およびレイヤー 4 のルールと FQDN ベースのアプリケーション ルールを適用することはできます。 Azure Firewall では、Azure Firewall 層と、TLS 検査を構成するかどうかに応じて、アウトバウンド HTTP(S) トラフィックの検査が行われます。

• Azure Firewall Standard の場合、ネットワーク ルールではパケットのレイヤー 3 とレイヤー 4 の属性のみが、アプリケーション ルールではホスト HTTP ヘッダーが検査されます。
• Azure Firewall Premium では、他の HTTP ヘッダー (User-Agent など) の検査や、より詳細なパケット分析のための TLS 検査の有効化などの機能が追加されます。 Azure Firewall は、Web アプリケーション ファイアウォールに相当するものではありません。 ご使用の仮想ネットワークに Web ワークロードがある場合は、WAF を使用することを強くお勧めします。

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

• Azure Firewall サービスでは、フロントエンド IP アドレス 192.168.100.4 と、192.168.100.0/26 の範囲の内部アドレスを使用して、複数のインスタンスが内部的にデプロイされます。 これらの個々のインスタンスは、通常は Azure 管理者には見えません。 ただし、違いを知っていることは、ネットワークの問題をトラブルシューティングする際などに役に立つ場合があります。
• トラフィックがインターネットではなく、オンプレミスの仮想プライベート ネットワーク (VPN) または Azure ExpressRoute ゲートウェイからのものである場合、クライアントによって VM の IP アドレスへの接続が開始されます。 ファイアウォールの IP アドレスへの接続は開始されません。既定では、ファイアウォールで送信元 NAT は実行されません。

Architecture

次の図は、インスタンスの IP アドレスが 192.168.100.7 であると想定した場合のトラフィック フローを示しています。

Workflow

1. クライアントにより、Azure ファイアウォールのパブリック IP アドレスへの接続が開始されます。
   • 送信元 IP アドレス: ClientPIP
   • 宛先 IP アドレス: AzFwPIP
2. Azure Firewall パブリック IP への要求は、ファイアウォールのバックエンド インスタンス (この場合は 192.168.100.7) に配布されます。 Azure Firewall の宛先 NAT (DNAT) 規則により、宛先 IP アドレスが仮想ネットワーク内のアプリケーション IP アドレスに変換されます。 Azure ファイアウォールでは、DNAT を実行する場合に、パケットの "送信元 NAT (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 ファイアウォールを必ず通過するようにするための、アウトバウンド接続用です。
   • 送信元 IP アドレス: 192.168.1.4
   • 宛先 IP アドレス: 192.168.100.7
4. 最後に、Azure Firewall は SNAT および DNAT 操作を元に戻し、クライアントに応答を送信します。
   • 送信元 IP アドレス: AzFwPIP
   • 宛先 IP アドレス: ClientPIP

Application Gateway のみ

この設計は、仮想ネットワーク内に Web アプリケーションのみが存在し、NSG を使用してアウトバウンド トラフィックを検査することが、インターネットへのアウトバウンド フローを保護するのに十分である状況に対応しています。

Azure ファイアウォールのみを使用した前の設計との主な違いは、Application Gateway が NAT を使用するルーティング デバイスとして機能しないということです。 これは、完全なリバース アプリケーション プロキシとして動作します。 つまり、Application Gateway によってクライアントからの Web セッションが終了され、そのバックエンド サーバーのいずれかと、別のセッションが確立されます。 インターネットからの受信 HTTP(S) 接続は、Application Gateway のパブリック IP アドレスに、Azure またはオンプレミスからの接続はゲートウェイのプライベート IP アドレスに送信する必要があります。 Azure VM からの戻りトラフィックは、Application Gateway にルーティングして戻される標準 VNet に従います (詳細については、パケット ウォークの詳細を参照してください)。 Azure VM からの送信インターネット フローは、インターネットに直接送信されます。

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

Architecture

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

Workflow

1. クライアントにより、Azure 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 アドレス: 192.168.200.7 (Application Gateway インスタンスのプライベート IP アドレス)
   • 宛先 IP アドレス: 192.168.1.4
   • X-Forwarded-For ヘッダー: ClientPIP
3. VM は、送信元と宛先の IP アドレスを逆にしてアプリケーション要求に応答します。 VM は、Application Gateway に到達する方法を既に認識しているので、UDR を必要としません。
   • 送信元 IP アドレス: 192.168.1.4
   • 宛先 IP アドレス: 192.168.200.7
4. 最後に、Application Gateway インスタンスがクライアントに応答します。
   • 送信元 IP アドレス: AppGwPIP
   • 宛先 IP アドレス: ClientPIP

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

• IP アドレス 192.168.200.7 は、ここでは内部のプライベート フロントエンド IP アドレス 192.168.200.4 とともに、Azure Application Gateway サービスが内部でデプロイするインスタンスの 1 つです。 これらの個々のインスタンスは、通常は Azure 管理者には見えません。 ただし、違いを知っていることは、ネットワークの問題をトラブルシューティングする際などに役に立つ場合があります。

• クライアントが VPN または ExpressRoute ゲートウェイを介してオンプレミス ネットワークから接続している場合、フローは類似したものとなります。 違いは、クライアントからアクセスするのがパブリック アドレスではなく Application Gateway のプライベート IP アドレスであるということです。

Azure Firewall と Application Gateway の並列実行

Application Gateway と Azure Firewall の並列実行は、そのシンプルさと柔軟性から、多くの場合、最良のシナリオです。

仮想ネットワークに Web ワークロードと Web 以外のワークロードが混在している場合は、この設計を実装します。 Azure Application Gateway の Azure WAF によって Web ワークロードへのインバウンド トラフィックが保護され、Azure Firewall によって他のアプリケーションのインバウンド トラフィックが検査されます。 Azure Firewall は、両方のワークロードの種類からのアウトバウンド フローに対応します。

インターネットからの受信 HTTP(S) 接続は、Application Gateway のパブリック IP アドレスに、Azure またはオンプレミスからの HTTP(S) 接続は Application Gateway のプライベート IP アドレスに送信する必要があります。 標準 VNet ルーティングでは、Application Gateway から宛先 VM にパケットが送信され、宛先 VM から Application Gateway にパケットが送り返されます (詳細については、パケット ウォークの詳細を参照してください)。 HTTP (S) 以外の受信接続には、パブリック インターネットから送信される場合にはトラフィックは Azure Firewall のパブリック IP アドレスをターゲットとする必要があります。または、他の Azure VNet またはオンプレミス ネットワークから送信される場合には、UDR によって Azure Firewall を介して送信されます。 Azure VM からのすべての送信フローは、UDR によって Azure Firewall に転送されます。

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

この設計では、NSG よりもはるかに詳細なエグレス フィルター処理が提供されます。 たとえば、アプリケーションに特定の Azure ストレージ アカウントへの接続が必要な場合、"完全修飾ドメイン名 (FQDN)" ベースのフィルターを使用できます。 FQDN ベースのフィルターを使用すれば、アプリケーションから不正なストレージ アカウントにデータは送信されません。 NSG のみを使用する場合、このシナリオを防ぐことはできません。 この設計は、アウトバウンド トラフィックで FQDN ベースのフィルター処理が必要な場合によく使用されます。 そのような状況の 1 つの例は、Azure Kubernetes サービス クラスターからのエグレス トラフィックを制限する場合です。

アーキテクチャ

外部クライアントからのインバウンド HTTP(S) 接続のトラフィック フローを、次の図に示します。

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

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

Azure Firewall の前の Application Gateway

この設計の詳細については、Azure Firewall と Application Gateway を使用した Web アプリケーションのゼロトラスト ネットワークをご覧ください。このドキュメントでは、他の設計オプションとの比較に焦点を当てます。 このトポロジでは、インバウンド Web トラフィックは Azure Firewall と WAF の両方を通過します。 WAF によって Web アプリケーション レイヤーの保護が提供されます。 Azure Firewall は中央のログおよび制御ポイントとして機能し、Application Gateway とバックエンド サーバー間のトラフィックがこれによって検査されます。 Application Gateway と Azure Firewall は並列に位置するのではなく、順番になっています。

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

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

インターネットからの受信 HTTP(S) 接続は、Application Gateway のパブリック IP アドレスに、Azure またはオンプレミスからの HTTP(S) 接続はプライベート IP アドレスに送信する必要があります。 Application Gateway のUDR によって、パケットが Azure Firewall 経由でルーティングされるようになります (詳細については、パケットウォークの詳細を参照してください)。 HTTP (S) 以外の受信接続には、パブリック インターネットから送信される場合にはトラフィックは Azure Firewall のパブリック IP アドレスをターゲットとする必要があります。または、他の Azure VNet またはオンプレミス ネットワークから送信される場合には、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 ルールの説明と IDPS のプライベート IP プレフィックスの詳細については、 Azure Firewall IDPS ルールを参照してください。 その結果として、Application Gateway サブネットが内部ソースと見なされないように、Azure Firewall ポリシーの IDPS プライベート プレフィックスを変更して、トラフィックに受信 IDPS 署名と送信 IDPS 署名を適用することをお勧めします。

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

オンプレミスまたはインターネットから Azure への Web トラフィックの場合、WAF によって既に許可されているフローが、Azure ファイアウォールによって検査されます。 Application Gateway によってバックエンド トラフィック (Application Gateway からアプリケーション サーバーへのトラフィック) が暗号化されるかどうかに応じて、異なるシナリオが考えられます。

1. ゼロ トラストの原則 (エンドツーエンドの TLS 暗号化) に従って Application Gateway でトラフィックが暗号化され、Azure ファイアウォールでは暗号化されたトラフィックが受信されます。 それでも、Azure Firewall Standard では、ネットワーク ルールのレイヤー 3 およびレイヤー 4 フィルター処理や、TLS Server Name Indication (SNI) ヘッダーを使用するアプリケーション ルールの FQDN フィルター処理などの検査ルールを適用できます。 Azure Firewall Premium では、URL ベースのフィルター処理などの、TLS 検査を使用したより詳細な可視性が提供されます。
2. 暗号化されていないトラフィックが Application Gateway からアプリケーション サーバーに送信されている場合、Azure ファイアウォールではインバウンド トラフィックをクリア テキストで認識します。 Azure ファイアウォールで TLS 検査は必要ありません。
3. IDPS が Azure Firewall で有効になっている場合は、HTTP Host ヘッダーが宛先 IP と一致する必要があります。 そのために、Host ヘッダーで指定されている FQDN の名前解決が必要になります。 この名前解決は、Azure DNS Private Zones と、Azure DNS を使用する既定の Azure Firewall DNS の設定により実現できます。 これはまた、Azure Firewall の設定で構成する必要がある、カスタムの DNS サーバーで実現することもできます (詳細については、Azure Firewall DNS の設定を参照してください)。Azure ファイアウォールがデプロイされている仮想ネットワークへの管理アクセス権がない場合、後者の方法のみを利用できます。 1 つの例は、Azure ファイアウォールが Virtual WAN セキュリティ保護付きハブにデプロイされている状況です。

Architecture

残りのフロー (HTTP (S) 以外のインバウンド トラフィックとすべてのアウトバウンド トラフィック) に対しては、Azure ファイアウォールによって IDPS 検査と TLS 検査 (必要な場合) が提供されます。 また、DNS に基づくネットワーク ルールでの FQDN ベースのフィルター処理も提供されます。

Workflow

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

1. クライアントにより、Azure 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 により、Web アプリケーションへの宛先 IP を保持しながら、パケットが Azure Firewall に転送されます。
   • 送信元 IP アドレス: 192.168.200.7 (Application Gateway インスタンスのプライベート IP アドレス)
   • 宛先 IP アドレス: 192.168.1.4
   • X-Forwarded-For ヘッダー: ClientPIP
3. トラフィックはプライベート IP アドレスに送信されるため、Azure Firewall でトラフィックの SNAT は実行されません。 ルールによって許可されている場合、トラフィックはアプリケーション VM に転送されます。 詳細については、Azure Firewall の SNAT に関する記事をご覧ください。 ただし、トラフィックがファイアウォールのアプリケーション規則にヒットした場合、ワークロードには、パケットを処理した特定のファイアウォール インスタンスの送信元 IP アドレスが表示されます。これは、Azure Firewallが接続をプロキシするためです。
   • Azure Firewall ネットワーク規則によってトラフィックが許可されている場合の送信元 IP アドレス: 192.168.200.7 (Application Gateway インスタンスのいずれかのプライベート IP アドレス)。
   • Azure Firewall アプリケーション規則によってトラフィックが許可されている場合の送信元 IP アドレス: 192.168.100.7 (Azure Firewall インスタンスのいずれかのプライベート IP アドレス)。
   • 宛先 IP アドレス: 192.168.1.4
   • X-Forwarded-For ヘッダー: ClientPIP
4. VM は、送信元と宛先の IP アドレスを逆にして要求に応答します。 192.168.200.0/24 への UDR により、Application Gateway に返送されるパケットがキャプチャされ、Application Gateway への宛先 IP を保持しながら、Azure Firewall にリダイレクトされます。
   • 送信元 IP アドレス: 192.168.1.4
   • 宛先 IP アドレス: 192.168.200.7
5. ここでも、トラフィックはプライベート IP アドレスに送信されるため、Azure Firewall はトラフィックに対して SNAT を実行せず、トラフィックを Application Gateway に転送します。
   • 送信元 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 の後の Application Gateway

この設計では、トラフィックが Application Gateway に到達する前に、Azure Firewall は悪意のあるトラフィックをフィルター処理して破棄することができます。 たとえば、脅威インテリジェンス ベースのフィルター処理などの機能を適用できます。 もう 1 つの利点は、アプリケーションにより、プロトコルに関係なく、インバウンドとアウトバウンドの両方のトラフィックに対して同じパブリック IP アドレスが取得されることです。 ただし、Azure Firewall は受信トラフィックを SNAT するため、アプリケーションは HTTP 要求の元の IP アドレスを認識できません。 管理の観点から、たとえばトラブルシューティングの目的で特定の接続の実際のクライアント IP を取得するには、Azure Firewall の SNAT ログと関連付けます。

Application Gateway への暗号化されたトラフィックしか Azure Firewall によって認識されないため、このシナリオでの利点は限られています。 シナリオによってはこの設計が適している場合もあります。 1 つのケースは、別の WAF がネットワーク内で先に存在し (例えば Azure Front Door)、X-Forwarded-For HTTP ヘッダー内の元の送信元 IP をキャプチャする可能性がある場合です。 また、多くのパブリック IP アドレスが必要な場合もこの設計が適しています。

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

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

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

Architecture

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

Workflow

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

1. クライアントにより、Azure ファイアウォールのパブリック 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 アドレス: 192.168.100.7 (Azure Firewall インスタンスのプライベート IP アドレス)
   • 宛先 IP アドレス: 192.168.200.4
3. Application Gateway は、接続を処理するインスタンスとバックエンド サーバーの 1 つとの間に新しいセッションを確立します。 クライアントの元の IP アドレスは、パケットに含まれていません。
   • 送信元 IP アドレス: 192.168.200.7 (Application Gateway インスタンスのプライベート IP アドレス)
   • 宛先 IP アドレス: 192.168.1.4
   • X-Forwarded-For ヘッダー: 192.168.100.7
4. VM は、送信元と宛先の IP アドレスを逆にして Application Gateway に応答します。
   • 送信元 IP アドレス: 192.168.1.4
   • 宛先 IP アドレス: 192.168.200.7
5. Application Gateway は、Azure Firewall インスタンスの SNAT 送信元 IP アドレスに応答します。 接続が .7 のような特定の Application Gateway インスタンスからのものであっても、Azure Firewall は、Application Gateway .4 の内部 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 アドレスが必要です。

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

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

• VPN ゲートウェイまたは ExpressRoute ゲートウェイは、Azure Firewall または Application Gateway の前に配置されます。
• WAF は、Application Gateway のプライベート IP アドレスを使用します。
• Azure Firewall では、プライベート IP アドレスの DNAT はサポートされていません。 そのため、VPN または ExpressRoute ゲートウェイから Azure Firewall にインバウンド トラフィックを送信するには、UDR を使用する必要があります。
• Azure Application Gateway と Azure Firewall の "強制トンネリング" に関する注意事項を必ず確認してください。 ワークロードがパブリック インターネットへのアウトバウンド接続を必要としない場合でも、オンプレミス ネットワークを指す、Application Gateway の 0.0.0.0/0 のような既定のルートを挿入することはできません。これを行うと、制御トラフィックが中断されます。 Azure Application Gateway の場合、既定のルートはパブリック インターネットを指す必要があります。

Architecture

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

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

ハブとスポークのトポロジ

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

アーキテクチャ

考慮事項

このトポロジに関する考慮事項は次のとおりです。

• Azure ファイアウォールは、中央のハブ仮想ネットワークにデプロイされます。 上の図は、ハブに Application Gateway をデプロイする方法を示しています。 しかし、多くのアプリケーション チームでは、Azure Application Gateway または Azure API Management ゲートウェイなどのコンポーネントを管理します。 この場合、これらのコンポーネントは、スポーク仮想ネットワークにデプロイされます。
• スポーク ネットワークでは UDR に特別な注意を払う必要があります。スポークのアプリケーション サーバーは、前の例の 192.168.100.7 アドレスのように、特定の Azure Firewall インスタンスからトラフィックを受信した場合、戻りトラフィックを同じインスタンスに送信する必要があります。 スポーク内の UDR で、ハブを宛先とするトラフィックのネクスト ホップを Azure Firewall IP アドレスに設定した場合 (上記の図の 192.168.100.4)、戻りパケットが別の Azure Firewall インスタンスに到達し、非対称ルーティングが発生する可能性があります。 Azure ファイアウォールを通じてハブの共有サービスにトラフィックを送信する UDR がスポーク VNet にある場合、これらの UDR に Azure Firewall サブネットのプレフィックスが含まれていないことを確認してください。
• 前述の推奨事項は、Application Gateway サブネットと、ハブ VNet にデプロイされる可能性のある、その他のネットワーク仮想アプライアンスまたはリバース プロキシにも同様に適用されます。
• ネクスト ホップの種類が Virtual Network である静的ルートを使用して、Application Gateway や Azure Firewall サブネットにネクスト ホップを設定することはできません。 この種類のネクスト ホップはローカル VNet でのみ有効であり、VNet ピアリングをまたいで使用することはできません。 ユーザー定義のルートおよびネクスト ホップの種類について詳しくは、「仮想ネットワーク トラフィックのルーティング」を参照してください。

非対称ルーティング

次の図に、スポークが SNAT が実行されたトラフィックを Azure ファイアウォールの ALB に送り返す様子を示します。 この設定では、非対称ルーティングが発生します。

この問題を解決するには、Azure Firewall サブネットを持たず、共有サービスが配置されたサブネットのみを持つスポークで UDR を定義します。 この例の場合、スポークの正しい UDR には 192.168.1.0/24 のみが含まれます。 赤で示されているように、192.168.0.0/16 全体を含むべきではありません。

その他の Azure 製品との統合

Azure Firewall および Azure Application Gateway を他の Azure 製品およびサービスと統合できます。

API Management ゲートウェイ

API の調整や認証プロキシなどの機能を提供するには、API Management ゲートウェイのようなリバース プロキシ サービスを前述の設計に統合します。 API Management ゲートウェイを統合しても、設計が大幅に変更されることはありません。 主な違いは、単一の Application Gateway リバース プロキシの代わりに、2 つのリバース プロキシが相互にチェーンされていることです。

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

Azure Kubernetes Service

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

Azure Firewall は、AKS クラスターのセキュリティにおいて重要な役割を果たします。 これにより、AKS クラスターからのエグレス トラフィックを IP アドレスだけではなく FQDN に基づいてフィルター処理するために必要な機能が提供されます。 詳細については、AKS クラスター ノードのエグレス トラフィックの制御に関する記事をご覧ください。

AKS クラスターを保護するために、Application Gateway と Azure Firewall を併用する場合は、並列設計オプションを使用することをお勧めします。 WAF を伴う Application Gateway では、クラスター内の Web アプリケーションへのインバウンド接続要求が処理されます。 Azure Firewall では、明示的に許可されたアウトバウンド接続のみが許可されます。 並列設計オプションの例については、「Azure Kubernetes Service (AKS) クラスターのベースライン アーキテクチャ」を参照してください。

Azure Front Door

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

場合によっては、Application Gateway を分散型の Azure Front Door に置き換えることで、仮想ネットワーク設計を簡素化できます。 Azure Front Door の前に Azure Firewall を配置するオプションを除き、このドキュメントで説明されている設計のほとんどを使用できます。

興味深いユース ケースは、仮想ネットワークの Application Gateway の前に Azure Firewall を使用することです。 前述のように、Application Gateway によって挿入される X-Forwarded-For ヘッダーには、クライアントの IP アドレスではなく、ファイアウォール インスタンスの IP アドレスが含まれます。 対処法は、ファイアウォールの前に Azure Front Door を使用して、トラフィックが仮想ネットワークに入って Azure Firewall に到達する前に、クライアントの IP アドレスを X-Forwarded-For ヘッダーとして挿入することです。 2 番めのオプションは、Azure Front Door Premium で Private Link を使用して配信元を保護することです。

2 つのサービスの違いや、それぞれを使用すべき状況の詳細については、「Azure Front Door についてよく寄せられる質問」をご覧ください。

その他のネットワーク仮想アプライアンス

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

• 次世代ファイアウォール機能に対応するパートナーの NVA では、Azure ファイアウォールでサポートされていない NAT 構成のより細かい制御と柔軟性が提供される場合があります。 例としては、オンプレミスからの DNAT や SNAT なしのインターネットからの DNAT などがあります。
• ユーザーが、多くのアプライアンス全体でスケーラビリティと回復性に対応する必要がある NVA と比較して、Azure マネージド NVA (Application Gateway や Azure Firewall など) では複雑さが軽減されます。
• Azure で NVA を使用する場合、"アクティブ/アクティブ" および "自動スケール" セットアップを使用するので、これらのアプライアンスが仮想ネットワークで実行されているアプリケーションのボトルネックになることはありません。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパル作成者:

• Jose Moreno | プリンシパル カスタマー エンジニア

次のステップ

コンポーネントのテクノロジの詳細については、次を参照してください。

• Azure Application Gateway とは
• Azure Firewall とは
• Azure Front Door とは
• Azure Kubernetes Service
• Azure Virtual Network とは
• Azure Web アプリケーション ファイアウォールとは

関連リソース

次の関連するアーキテクチャを確認してください。

• セキュリティ保護されたハイブリッド ネットワークを実装する
• 安全に管理された Web アプリケーション
• Microsoft Teamsチャネル ボットと、ファイアウォールの背後にある Web アプリをセキュリティで保護する
• Azure 上のコンシューマー ヘルス ポータル
• Azure における機密性の高い IaaS アプリのセキュリティに関する考慮事項
• Azure のマルチテナント SaaS
• App Services Environment を使用したエンタープライズ デプロイ
• App Services Environment を使用した高可用性エンタープライズ デプロイ
• Azure Kubernetes Service (AKS) クラスターのベースライン アーキテクチャ