仮想ネットワーク用のファイアウォールと 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 では、悪意のある IP アドレスを識別するために Microsoft 脅威インテリジェンスも適用されます。 詳細については、Azure Firewall のドキュメントを参照してください。
• Azure Firewall Premium には、Azure Firewall Standard のすべての機能と、TLS 検査や侵入検出および保護システム (IDPS) などのその他の機能が含まれています。
• Azure Application Gateway は、Secure Socket Layer (SSL) の暗号化と暗号化解除を実行できる、マネージド Web トラフィック ロード バランサーと HTTP (S) フル リバース プロキシです。 Application Gateway は、元のクライアント IP アドレスを X-Forwarded-For HTTP ヘッダーに保持します。 Application Gateway では、Web アプリケーション ファイアウォールを使用して Web トラフィックを検査し、HTTP レイヤーで攻撃を検出します。 詳細については、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 のみ。 アプリケーションへの受信トラフィックと送信トラフィックの両方を制御します。
• Application Gateway のみ。Web アプリケーションのみが仮想ネットワーク内にあり、ネットワーク セキュリティ グループ (NSG) を 、十分な出力フィルター処理が提供されます。 Azure Firewall によって提供される機能により、多くの攻撃シナリオ (データ流出、IDPS など) を防ぐことができます。 このため、Application Gateway 単独のシナリオは通常推奨されないため、文書化されておらず、上記のフローチャートには記載されていません。
• Azure Firewall と Application Gateway を並列に します。これは最も一般的な設計の 1 つです。 この組み合わせは、Azure Application Gateway で Web 攻撃から HTTP(S) アプリケーションを保護し、Azure Firewall で他のすべてのワークロードを保護し、送信トラフィックをフィルター処理する場合に使用します。
• Azure Firewallの前にある Application Gateway を します。Azure Firewall ですべてのトラフィックを検査する場合、WAF を使用して Web トラフィックを保護し、アプリケーションはクライアントのソース IP アドレスを認識します。 Azure Firewall Premium と TLS 検査では、この設計ではエンド ツー エンドの SSL シナリオもサポートされます。
• Application Gatewayの前に Azure Firewall を します。これは、Azure Firewall が Application Gateway に到達する前にトラフィックを検査およびフィルター処理する場合です。 Azure Firewall は 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 は、パブリック インターネットからの受信接続と、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されている場合のトラフィック フローを示しています。

ワークフロー

1. クライアントは、Azure Firewall のパブリック IP アドレスへの接続を開始します。
   • 送信元 IP アドレス: ClientPIP
   • 宛先 IP アドレス: AzFwPIP
2. Azure Firewall パブリック IP への要求は、ファイアウォールのバックエンド インスタンス (この場合は 192.168.100.7) に配布されます。 Azure Firewall 宛先 NAT (DNAT) 規則、宛先 IP アドレスが仮想ネットワーク内のアプリケーション IP アドレスに変換されます。 また、Azure Firewall は、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 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 のみの以前の設計との主な違いは、Application Gateway が NAT を使用したルーティング デバイスとして機能しないという点です。 完全なリバース アプリケーション プロキシとして動作します。 つまり、Application Gateway はクライアントからの Web セッションを停止し、バックエンド サーバーの 1 つと別のセッションを確立します。 インターネットからの受信 HTTP(S) 接続は、Application Gateway のパブリック IP アドレス、Azure またはオンプレミスからゲートウェイのプライベート IP アドレスへの接続に送信する必要があります。 Azure VM からの戻りトラフィックは、Application Gateway への標準 VNet ルーティングに従います (詳細については、パケットウォークダウンを参照してください)。 Azure VM からの送信インターネット フローは、インターネットに直接送信されます。

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

建築

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

ワークフロー

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 アドレスが必要です。 詳細については、「アプリケーション ゲートウェイの動作」を参照してください。

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

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

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

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

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

アーキテクチャ

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

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

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

ファイアウォールの前の Application Gateway

この設計については、Azure Firewall と Application Gatewayを使用した Web アプリケーションの ゼロ トラスト ネットワークの詳細について説明します。このドキュメントでは、他の設計オプションとの比較に焦点を当てます。 このトポロジでは、受信 Web トラフィックは Azure Firewall と WAF の両方を通過します。 WAF は、Web アプリケーション 層で保護を提供します。 Azure Firewall は、中央のログ記録と制御ポイントとして機能し、Application Gateway とバックエンド サーバー間のトラフィックを検査します。 Application Gateway と Azure Firewall は並列ではなく、1 つずつ並列に置かれます。

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

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

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

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

建築

残りのフロー (HTTP (S) 以外の受信トラフィックと送信トラフィック) については、必要に応じて、Azure Firewall によって IDPS 検査と TLS 検査が提供されます。 また、DNS に基づくネットワーク ルール の FQDN ベースのフィルター処理 も提供します。

ワークフロー

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

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 は、宛先 IP を Web アプリケーションに保持しながら、パケットを 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」を参照してください。 ただし、トラフィックがファイアウォールのアプリケーション規則にヒットした場合、Azure Firewall は接続をプロキシするため、パケットを処理した特定のファイアウォール インスタンスの送信元 IP アドレスがワークロードに表示されます。
   • トラフィックが Azure Firewall ネットワーク規則によって許可されている場合の送信元 IP アドレス: 192.168.200.7 (Application Gateway インスタンスの 1 つのプライベート IP アドレス)。
   • トラフィックが Azure Firewall アプリケーション規則によって許可されている場合の送信元 IP アドレス: 192.168.100.7 (Azure Firewall インスタンスの 1 つのプライベート IP アドレス)。
   • 宛先 IP アドレス: 192.168.1.4
   • X-Forwarded-For ヘッダー: ClientPIP
4. VM が要求に応答し、送信元と宛先の IP アドレスが逆になります。 192.168.200.0/24 する UDR は、Application Gateway に送り返されたパケットをキャプチャし、宛先 IP を Application Gateway に向けて保持しながら Azure Firewall にリダイレクトします。
   • 送信元 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 からパブリック インターネットへの送信フローは、UDR によって定義された Azure Firewall を経由して 0.0.0.0/0。

ファイアウォール後の Application Gateway

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

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

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

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

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

建築

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

ワークフロー

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

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 します。 また、DNAT を実行する場合は、Azure Firewall の SNAT も使用します。 詳細については、Azure Firewall の既知の問題を参照してください。
   • ソース IP アドレス: 192.168.100.7 (Azure Firewall インスタンスのプライベート IP アドレス)
   • 宛先 IP アドレス: 192.168.200.4
3. Application Gateway は、接続を処理するインスタンスといずれかのバックエンド サーバーとの間に新しいセッションを確立します。 クライアントの元の IP アドレスがパケット内にありません。
   • 送信元 IP アドレス: 192.168.200.7 (Application Gateway インスタンスのプライベート IP アドレス)
   • 宛先 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 アドレスに応答します。 接続が .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 はサポートされていません。 そのため、UDR を使用して、VPN または ExpressRoute ゲートウェイから Azure Firewall に受信トラフィックを送信する必要があります。
• Azure Application Gateway と Azure Firewallの強制トンネリング に関する注意事項を確認してください。 ワークロードがパブリック インターネットへの送信接続を必要としない場合でも、オンプレミス ネットワークを指す Application Gateway の 0.0.0.0/0 などの既定のルートを挿入したり、制御トラフィックを中断したりすることはできません。 Azure Application Gateway の場合、既定のルートはパブリック インターネットを指す必要があります。

建築

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

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

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

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

建築

考慮 事項

このトポロジに関する考慮事項には、次のようなものがあります。

• Azure Firewall は中央ハブ仮想ネットワークにデプロイされます。 上の図は、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 インスタンスで終了し、非対称ルーティングが発生する可能性があります。 スポーク VNet に、Azure Firewall 経由でハブ内の共有サービスにトラフィックを送信する UDR がある場合、これらの UDR には Azure Firewall サブネットのプレフィックスが含まれていないことを確認します。
• 前の推奨事項は、Application Gateway サブネットと、ハブ VNet にデプロイされる可能性があるその他のネットワーク仮想アプライアンスまたはリバース プロキシにも同様に適用されます。
• 次ホップの種類が Virtual Networkの静的ルートを介して、Application Gateway または Azure Firewall サブネットの次ホップを設定することはできません。 この次ホップの種類は、ローカル VNet でのみ有効であり、VNet ピアリング間では有効ではありません。 ユーザー定義ルートと次ホップの種類の詳細については、「仮想ネットワーク トラフィック ルーティングの」を参照してください。

非対称ルーティング

次の図は、スポークが SNATted トラフィックを Azure Firewall の 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 Management ゲートウェイなどのリバース プロキシ サービスを以前の設計に統合して、API 調整や認証プロキシなどの機能を提供します。 API Management ゲートウェイを統合しても、設計は大きく変わりません。 主な違いは、1 つの 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 クラスターのセキュリティにおいて重要な役割を果たします。 IP アドレスだけでなく、FQDN に基づいて AKS クラスターからのエグレス トラフィックをフィルター処理するために必要な機能が提供されます。 詳細については、「AKS クラスター ノードのエグレス トラフィックを制御する」を参照してください。

Application Gateway と Azure Firewall を組み合わせて AKS クラスターを保護する場合は、並列設計オプションを使用することをお勧めします。 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 製品は、Azure に Web アプリケーション ファイアウォールまたは次世代ファイアウォール機能を実装する唯一の選択肢ではありません。 さまざまな Microsoft パートナーが、ネットワーク仮想アプライアンス (NVA) を提供しています。 概念と設計は基本的にこの記事と同じですが、いくつかの重要な考慮事項があります。

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

貢献

この記事は Microsoft によって管理されています。 もともとは次の共同作成者によって作成されました。

プリンシパルの作成者:

• ホセ・モレノ |プリンシパル カスタマー エンジニア

次の手順

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

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

関連リソース

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

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