このガイドでは、検査と暗号化の目的で Web アプリのゼロ トラスト セキュリティを実装するための戦略について概説します。 ゼロ トラスト パラダイムには、アクターの ID を常時検証したり、暗黙的な信頼領域のサイズを最小限に抑えたりするなど、他の多くの概念が含まれています。 この記事では、パブリック インターネットからの受信トラフィックに対するゼロ トラスト アーキテクチャの暗号化と検査のコンポーネントについて説明します。 認証など、アプリケーションを安全にデプロイする上でのその他の側面については、他のゼロトラスト ドキュメントを参照してください。 この記事では、ネットワーク セキュリティがゼロ トラスト モデルのレイヤーの 1 つを構成する多層アプローチが最適です。 この層では、正当なトラフィックだけがアプリケーションに到達するように、ネットワーク アプライアンスによってパケットが検査されます。
通常、さまざまな種類のネットワーク アプライアンスによって、ネットワーク パケットのさまざまな側面が検査されます。
- Web アプリケーション ファイアウォールでは、Web アプリケーション層で攻撃を示すパターンが検索されます。
- 次世代ファイアウォールでは、一般的な脅威も探すことができます。
場合によっては、さまざまな種類のネットワーク セキュリティ アプライアンスを組み合わせて、保護を強化できます。 仮想ネットワークのファイアウォールと Application Gateway に関する別のガイドでは、さまざまなアプライアンスを配置するために使用できる設計パターンについて説明しています。 このドキュメントでは、Azure Application Gateway が Azure Firewall Premium の前に動作する、セキュリティを最大化するための一般的なパターンに焦点を当てています。 このパターンを示す図を次に示します。
このアーキテクチャの Visio ファイルをダウンロードします。
このアーキテクチャでは、トランスポート層セキュリティ (TLS) プロトコルを使用して、すべてのステップでトラフィックを暗号化します。
クライアントは、ロード バランサーである Application Gateway にパケットを送信します。 省略可能な追加の Azure Web Application Firewall と共に実行されます。
Application Gateway では、パケットの暗号化が解除され、Web アプリケーションへの脅威が検索されます。 脅威が見つからなければ、ゼロ トラストの原則を使用してパケットが暗号化されます。 次に、それらが解放されます。
Azure Firewall Premium では、セキュリティ チェックが実行されます。
- トランスポート層セキュリティ (TLS) 検査では、パケットの暗号化が解除されて検査されます。
- 侵入検出および保護の機能により、パケットに悪意があるかどうかが確認されます。
パケットがテストに合格すると、Azure Firewall Premium によってこれらの手順が実行されます。
- パケットを暗号化する
- ドメイン ネーム システム (DNS) サービスを使用して、アプリケーション仮想マシン (VM) を決定する
- パケットをアプリケーション VM に転送する
このアーキテクチャのさまざまな検査エンジンによって、トラフィックの整合性が確保されます。
- Web Application Firewall では、Web 層での攻撃を防ぐためにルールが使用されます。 攻撃の例としては、SQL コード インジェクションやクロスサイト スクリプティングなどがあります。 ルールと Open Web Application Security Project (OWASP) のコア ルール セットの詳細については、「Web アプリケーション ファイアウォールの CRS 規則グループと規則」を参照してください。
- Azure Firewall Premium では、一般的な侵入検出および防止のルールが使用されます。 これらのルールは、Web アプリケーションをターゲットとする悪意のあるファイルやその他の脅威を特定するのに役立ちます。
このアーキテクチャでは、この記事で説明するさまざまな種類のネットワーク設計がサポートされています。
- 従来のハブ アンド スポーク ネットワーク
- Azure Virtual WAN がプラットフォームとして使用されているネットワーク
- Azure Route Server を使用して動的ルーティングが簡略化されているネットワーク
Azure Firewall Premium と名前解決
悪意のあるトラフィックを確認する際、Azure Firewall Premium では、HTTP ホスト ヘッダーがパケットの IP アドレスと TCP ポートに一致することが確認されます。 たとえば、Application Gateway が IP アドレス172.16.1.4 と TCP ポート443 に Web パケットを送信するとします。 HTTP ホスト ヘッダーの値は、その IP アドレスに解決される必要があります。
通常、HTTP ホスト ヘッダーには IP アドレスは含まれていません。 代わりに、ヘッダーには、サーバーのデジタル証明書と一致する名前が含まれています。 この場合、Azure Firewall Premium は DNS を使用してホスト ヘッダー名を IP アドレスに解決します。 後のセクションで説明するように、どの DNS ソリューションが最適かは、ネットワーク設計によって決まります。
Note
Application Gateway では、HTTP ホスト ヘッダーのポート番号はサポートされていません。 その結果、次のような影響が出ています。
- Azure Firewall Premium では、既定の HTTPS TCP ポート 443 が想定されます。
- Application Gateway と Web サーバー間の接続では、標準以外のポートではなく、TCP ポート 443 のみがサポートされます。
デジタル証明書
次の図は、アーキテクチャの TLS セッションと証明書で使用される共通名 (CN) と証明機関 (CA) を示しています。
TLS 接続
このアーキテクチャには、3 つの異なる TLS 接続が含まれています。 デジタル証明書によってそれぞれが検証されます。
クライアントから Application Gateway へ
Application Gateway では、クライアントに表示されるデジタル証明書をデプロイします。 DigiCert や Let's Encrypt などのよく知られた CA は、通常、そのような証明書を発行します。
Application Gateway から Azure Firewall Premium へ
TLS トラフィックの暗号化を解除して検査するために、Azure Firewall Premium は証明書を動的に生成します。 さらに、Azure Firewall Premium は自身を Web サーバーとして Application Gateway に提示します。 プライベート CA は、Azure Firewall Premium によって生成された証明書に署名します。 詳細については、「Azure Firewall Premium の証明書」を参照してください。 Application Gateway では、これらの証明書を検証する必要があります。 アプリケーションの HTTP 設定では、Azure Firewall Premium で使用されるルート CA を構成します。
Azure Firewall Premium から Web サーバーへ
Azure Firewall Premium によって、宛先 Web サーバーとの TLS セッションが確立されます。 Azure Firewall Premium では、既知の CA によって Web サーバーの TLS パケットに署名されていることを確認します。
コンポーネントの役割
Application Gateway と Azure Firewall Premium では、役割が異なるため、それぞれ異なる方法で証明書が処理されます。
- Application Gateway は "リバース Web プロキシ" です。 HTTP および HTTPS 要求をインターセプトして、悪意のあるクライアントから Web サーバーを保護します。 Application Gateway のバックエンド プールにある保護対象の各サーバーは、その IP アドレスまたは完全修飾ドメイン名を使用して宣言します。 正当なクライアントは、各アプリケーションにアクセスできなければなりません。 したがって、パブリック CA によって署名されたデジタル証明書を使用して Application Gateway を構成します。 どの TLS クライアントでも受け入れられる CA を使用してください。
- Azure Firewall Premium は、"転送 Web プロキシ"、または単に Web プロキシです。 保護されたクライアントからの TLS 呼び出しをインターセプトして、悪意のある Web サーバーからクライアントを保護します。 保護されたクライアントが HTTP 要求を行うと、転送プロキシは、デジタル証明書を生成し、それをクライアントに提示することによって、ターゲット Web サーバーを偽装します。 Azure Firewall Premium では、動的に生成された証明書に署名するプライベート CA が使用されます。 そのプライベート CA を信頼するように、保護されたクライアントを構成します。 このアーキテクチャでは、Azure Firewall Premium は Application Gateway から Web サーバーへの要求を保護します。 Application Gateway は、Azure Firewall Premium で使用されているプライベート CA を信頼します。
ルーティングとトラフィック転送
ルーティングは、ネットワーク設計のトポロジによって少し異なります。次のセクションでは、ハブ アンド スポーク、Virtual WAN および Route Server トポロジの例について詳しく説明します。 ただし、次のようなすべてのトポロジに共通する側面がいくつかあります。
- Azure Application Gateway は常にプロキシとして動作し、Azure Firewall Premium も TLS 検査用に構成されている場合は同様です。クライアントからの TLS セッションは Application Gateway によって終了され、新しい TLS セッションは Azure Firewall に向けて構築されます。 Azure Firewall は、Application Gateway から提供された TLS セッションを受信して終了し、ワークロードに向けて新しい TLS セッションを構築します。 この事実は、Azure Firewall Premium の IDPS 構成に影響します。詳細については、以下のセクションで説明します。
- ワークロードにより、Azure Firewall のサブネット IP アドレスからの接続が表示されます。 元のクライアント IP アドレスは、
X-Forwarded-ForApplication Gateway によって挿入された HTTP ヘッダーに保持されます。 - Application Gateway からワークロードへのトラフィックは、通常、Application Gateway のサブネットで構成されたユーザー定義ルート、または Azure Virtual WAN または Azure Route Server によって挿入されたルートを使用して、Azure ルーティング メカニズムによって Azure Firewall に送信されます。 Application Gateway のバックエンド プールで Azure Firewall のプライベート IP アドレスを明示的に定義することは可能ですが、負荷分散や持続性などの Azure Firewall の機能の一部が失われるため、技術的にはお勧めしません。
次のセクションでは、Azure Firewall と Application Gateway で使用される最も一般的なトポロジの一部について詳しく説明します。
ハブとスポークのトポロジ
通常、ハブ アンド スポークの設計では、共有ネットワーク コンポーネントをハブ仮想ネットワークにデプロイし、アプリケーション固有のコンポーネントをスポークにデプロイします。 ほとんどのシステムで、Azure Firewall Premium は共有リソースです。 ただし、Web アプリケーション ファイアウォールは、共有ネットワーク デバイスにも、アプリケーション固有のコンポーネントにもなります。 次の理由から、通常は Application Gateway をアプリケーション コンポーネントとして扱い、スポーク仮想ネットワークにデプロイすることをお勧めします。
- Web アプリケーション ファイアウォールのアラートをトラブルシューティングするのが困難な場合があります。 通常は、それらのアラームのトリガーとなるメッセージが正当であるかどうかを判断するには、アプリケーションに関する深い知識が必要です。
- Application Gateway を共有リソースとして扱った場合、Azure Application Gateway の制限を超える可能性があります。
- Application Gateway をハブにデプロイすると、ロールベースのアクセス制御の問題に直面する可能性があります。 この状況は、複数のチームによってさまざまなアプリケーションが管理されているのに、Application Gateway の同じインスタンスが使用されている場合に発生することがあります。 この場合、それぞれのチームは、Application Gateway 構成全体にアクセスできます。
従来のハブ アンド スポークのアーキテクチャでは、DNS を簡単に使用する方法が DNS プライベート ゾーンによって提供されています。
- DNS プライベート ゾーンを構成します。
- Azure Firewall Premium が含まれている仮想ネットワークにそのゾーンをリンクします。
- Application Gateway でトラフィックと正常性チェックに使用される値の A レコードが存在することを確認します。
次の図は、Application Gateway がスポーク仮想ネットワークにある場合のパケット フローを示しています。 この場合、クライアントはパブリック インターネットから接続します。
- クライアントが Web サーバーに要求を送信します。
- Application Gateway によってクライアント パケットがインターセプトされて検査されます。 パケットが検査に合格すると、Application Gateway はバックエンド VM にパケットを送信します。 パケットが Azure に到達すると、Application Gateway サブネット内のユーザー定義ルート (UDR) によって、パケットが Azure Firewall Premium に転送されます。
- Azure Firewall Premium によってパケットのセキュリティ チェックが実行されます。 テストに合格すると、パケットは Azure Firewall Premium によってアプリケーション VM に転送されます。
- VM が応答し、宛先 IP アドレスを Application Gateway に設定します。 VM サブネットの UDR によってパケットが Azure Firewall Premium にリダイレクトされます。
- Azure Firewall Premium によってパケットが Application Gateway に転送されます。
- Application Gateway がクライアントに応答します。
トラフィックは、パブリック インターネットではなく、オンプレミス ネットワークから到着することもあります。 トラフィックは、サイト間仮想プライベート ネットワーク (VPN) 経由または ExpressRoute 経由でフローします。 このシナリオでは、トラフィックは最初にハブ内の仮想ネットワーク ゲートウェイに到達します。 ネットワーク フローの残りの部分は、前のケースと同じです。
- オンプレミス クライアントが仮想ネットワーク ゲートウェイに接続します。
- ゲートウェイによってクライアント パケットが Application Gateway に転送されます。
- Application Gateway によってパケットが検査されます。 検査に合格すると、Application Gateway サブネット内の UDR によって、パケットが Azure Firewall Premium に転送されます。
- Azure Firewall Premium によってパケットのセキュリティ チェックが実行されます。 テストに合格すると、パケットは Azure Firewall Premium によってアプリケーション VM に転送されます。
- VM が応答し、宛先 IP アドレスを Application Gateway に設定します。 VM サブネットの UDR によってパケットが Azure Firewall Premium にリダイレクトされます。
- Azure Firewall Premium によってパケットが Application Gateway に転送されます。
- Application Gateway によってパケットが仮想ネットワーク ゲートウェイに送信されます。
- ゲートウェイがクライアントに応答します。
Virtual WAN トポロジ
このアーキテクチャでネットワーク サービス Virtual WAN を使用することもできます。 このコンポーネントには多くの利点があります。 たとえば、スポーク仮想ネットワーク内のユーザーが管理する UDR が不要になります。 代わりに、仮想ハブ ルート テーブルに静的ルートを定義できます。 その後、ハブに接続する各仮想ネットワークのプログラミングにこれらのルートが含まれます。
Virtual WAN をネットワーク プラットフォームとして使用すると、主に次の 2 つの違いが生じます。
仮想ハブは Microsoft によって管理されているため、DNS プライベート ゾーンを仮想ハブにリンクできません。 サブスクリプション所有者には、プライベート DNS ゾーンをリンクするための権限がありません。 その結果、DNS プライベート ゾーンを、Azure Firewall Premium が含まれたセキュリティで保護されたハブに関連付けることはできません。 Azure Firewall Premium の DNS 解決を実装するには、代わりに DNS サーバーを使用します。
- カスタム DNS サーバーを使用するように Azure Firewall の DNS 設定を構成します。
- Virtual WAN に接続する共有サービス仮想ネットワークにサーバーをデプロイします。
- DNS プライベート ゾーンを共有サービス仮想ネットワークにリンクします。 それにより、DNS サーバーは、Application Gateway が HTTP ホスト ヘッダーで使用している名前を解決できます。 詳細については、「Azure Firewall の DNS 設定」を参照してください。
Virtual WAN を使用してスポーク内にルートをプログラムできるのは、プレフィックスが仮想ネットワークのプレフィックスよりも短い (特定性が低い) 場合のみです。 たとえば、上の図で、スポーク VNet のプレフィックスは 172.16.0.0/16 です。この場合、Virtual WAN では、VNet プレフィックス (172.16.0.0/16) またはいずれかのサブネット (172.16.0.0/24、172.16.1.0/24) に一致するルートを挿入できません。 つまり、Virtual WAN は、同じ VNet 内の 2 つのサブネット間のトラフィックを引き付けられません。 この制限は、Application Gateway と宛先 Web サーバーが同じ仮想ネットワーク内にある場合に明らかになります。Virtual WAN は、Application Gateway と Web サーバー間のトラフィックに強制的に Azure Firewall Premium を経由させることはできません (回避策は、Application Gateway と Web サーバーのサブネットでユーザー定義ルートを手動で構成することです)。
次の図は、Virtual WAN が使用されているケースでのパケット フローを示しています。 この状況では、Application Gateway へのアクセスはオンプレミス ネットワークから行われます。 サイト間 VPN または ExpressRoute によってそのネットワークが Virtual WAN に接続されます。 インターネットからのアクセスも同様です。
- オンプレミス クライアントが VPN に接続します。
- VPN によってクライアント パケットが Application Gateway に転送されます。
- Application Gateway によってパケットが検査されます。 検査に合格すると、Application Gateway サブネットによってパケットが Azure Firewall Premium に転送されます。
- Azure Firewall Premium によって、共有サービス仮想ネットワーク内の DNS サーバーに DNS 解決が要求されます。
- DNS サーバーが解決要求に応答します。
- Azure Firewall Premium によってパケットのセキュリティ チェックが実行されます。 テストに合格すると、パケットは Azure Firewall Premium によってアプリケーション VM に転送されます。
- VM が応答し、宛先 IP アドレスを Application Gateway に設定します。 アプリケーション サブネットによってパケットが Azure Firewall Premium にリダイレクトされます。
- Azure Firewall Premium によってパケットが Application Gateway に転送されます。
- Application Gateway によってパケットが VPN に送信されます。
- VPN がクライアントに応答します。
この設計では、ハブがスポーク仮想ネットワークにアドバタイズしているルーティングを変更する必要がある場合があります。 具体的には、Application Gateway v2 では、インターネットを指す 0.0.0.0/0 ルートのみがサポートされています。 インターネットを指していないこのアドレスのルートでは、Microsoft で Application Gateway を管理するために必要な接続が中断されます。 仮想ハブが 0.0.0.0/0 ルートをアドバタイズしている場合は、これらのいずれかの手順を実行して、そのルートが Application Gateway サブネットに伝達されないようにします。
- 0\.0.0.0/0 のルートと次ホップの種類
Internetを使用してルート テーブルを作成します。 そのルートを、Application Gateway をデプロイするサブネットに関連付けます。 - Application Gateway を専用スポークにデプロイする場合は、仮想ネットワーク接続の設定で既定ルートの伝達を無効にします。
Route Server トポロジ
Route Server には、スポークにルートを自動的に挿入する別の方法が用意されています。 この機能を使用すると、ルート テーブルを維持するための管理オーバーヘッドを回避できます。 Route Server は、Virtual WAN とハブ アンド スポークのバリアントを組み合わせたものです。
- Route Server では、お客様によってハブ仮想ネットワークが管理されます。 その結果、ハブ仮想ネットワークを DNS プライベート ゾーンにリンクできます。
- Route Server には、IP アドレスのプレフィックスに関して Virtual WAN と同じ制限があります。 スポークにルートを挿入できるのは、プレフィックスが仮想ネットワークのプレフィックスよりも短い (特定性が低い) 場合のみです。 この制限のため、Application Gateway と宛先の Web サーバーは異なる仮想ネットワーク内にある必要があります。
次の図は、Route Server によって動的ルーティングが簡略化される場合のパケット フローを示しています。 これらの点に注意してください。
- 現在、Route Server には、Border Gateway Protocol (BGP) で送信するためのルートを挿入するデバイスが必要です。 Azure Firewall Premium では BGP はサポートされていないため、代わりにサードパーティのネットワーク仮想アプライアンス (NVA) を使用してください。
- ハブの NVA の機能によって、実装に DNS が必要かどうかが判断されます。
- オンプレミス クライアントが仮想ネットワーク ゲートウェイに接続します。
- ゲートウェイによってクライアント パケットが Application Gateway に転送されます。
- Application Gateway によってパケットが検査されます。 検査に合格すると、Application Gateway サブネットによってパケットがバックエンド マシンに転送されます。 Route Server によって挿入された ApplicationGateway サブネット内のルートは、トラフィックを NVA に転送します。
- NVA によってパケットに対するセキュリティ チェックが実行されます。 テストに合格すると、NVA によってパケットがアプリケーション VM に転送されます。
- VM が応答し、宛先 IP アドレスを Application Gateway に設定します。 Route Server によって VM サブネットに挿入されたルートは、パケットを NVA にリダイレクトします。
- NVA によってパケットが Application Gateway に転送されます。
- Application Gateway によってパケットが仮想ネットワーク ゲートウェイに送信されます。
- ゲートウェイがクライアントに応答します。
Virtual WAN と同様に、Route Server を使用する場合はルーティングの変更が必要になる場合があります。 0\.0.0.0/0 ルートをアドバタイズすると、それが Application Gateway サブネットに伝達される可能性があります。 しかし、Application Gateway ではそのルートはサポートされていません。 この場合は、Application Gateway サブネットのルート テーブルを構成します。 0\.0.0.0/0 のルートと次ホップの種類 Internet をそのテーブルに含めます。
IDPS およびプライベート IP アドレス
Azure Firewall IDPS ルールで説明したように、Azure Firewall Premium では、パケットの送信元と宛先の IP アドレスに応じて、適用する IDPS ルールを決定します。 Azure Firewall では、RFC 1918 の範囲 (10.0.0.0/8、192.168.0.0/16 および 172.16.0.0/12) を既定のプライベート IP アドレスとして処理し、RFC 6598 の範囲 (100.64.0.0/10) を内部 IP アドレスとして処理します。 そのため、この記事の図のように、Application Gateway がこれらの範囲のいずれかのサブネットにデプロイされている場合、(上記の例の 172.16.0.0/24)、Azure Firewall Premium は Application Gateway とワークロード間のトラフィックを内部トラフィックと見なし、内部トラフィックまたは任意のトラフィックに適用されるようにマークされた IDPS 署名のみが使用されます。 受信トラフィックまたは送信トラフィックに適用されるようにマークされた IDPS 署名は、Application Gateway とワークロード間のトラフィックには適用されません。
Application Gateway とワークロードの間のトラフィックに IDPS 受信署名ルールを適用する最も簡単な方法は、プライベート範囲外のプレフィックスを持つサブネットに Application Gateway を配置することです。 必ずしもこのサブネットにパブリック IP アドレスを使用する必要はありませんが、代わりに、Azure Firewall Premium が IDPS の内部 IP アドレスとして処理する IP アドレスをカスタマイズできます。 たとえば、組織で 100.64.0.0/10 範囲を使用していない場合は、IDPS の内部プレフィックスの一覧からこの範囲を削除し (これを行う方法の詳細については、Azure Firewall プレミアムプライベート IPDS 範囲を参照)、100.64.0.0/10 の IP アドレスで構成されるサブネットに Application Gateway をデプロイできます。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパル作成者:
- Jose Moreno | プリンシパル カスタマー エンジニア