このガイドでは、検査と暗号化のための Web アプリ ゼロ トラスト セキュリティを実装するための戦略について説明します。 ゼロ トラスト パラダイムには、アクターの ID の一定の検証や、暗黙的な信頼領域のサイズを最小限に抑えるなど、他の多くの概念が含まれています。 この記事では、パブリック インターネットからの受信トラフィックに対するゼロ トラスト アーキテクチャの暗号化と検査のコンポーネントについて説明します。 認証など、アプリケーションを安全にデプロイするその他の側面については、他の ゼロトラスト ドキュメントを参照してください。 この記事では、ネットワーク セキュリティがゼロ トラスト モデルのレイヤーの 1 つを構成する多層アプローチが最適に機能します。 この層では、ネットワーク アプライアンスはパケットを検査して、正当なトラフィックのみがアプリケーションに到達することを確認します。
通常、ネットワーク アプライアンスの種類によって、ネットワーク パケットのさまざまな側面が検査されます。
- Web アプリケーション ファイアウォールは、Web アプリケーション 層での攻撃を示すパターンを探します。
- 次世代ファイアウォールは、一般的な脅威を探すこともできます。
場合によっては、さまざまな種類のネットワーク セキュリティ アプライアンスを組み合わせて保護を強化できます。 仮想ネットワーク 用のファイアウォールと Application Gateway別のガイドでは、さまざまなアプライアンスの配置に使用できる設計パターンについて説明します。 このドキュメントでは、Azure Firewall Premium の前に Azure Application Gateway が機能する、セキュリティを最大化するための一般的なパターンに焦点を当てています。 次の図は、このパターンを示しています。
このアーキテクチャの Visio ファイル をダウンロードします。
このアーキテクチャでは、トランスポート層セキュリティ (TLS) プロトコルを使用して、すべての手順でトラフィックを暗号化します。
クライアントは、ロード バランサーである Application Gateway にパケットを送信します。 これは、Azure Web Application Firewall オプションの追加で実行されます。
Application Gateway はパケットを復号化し、Web アプリケーションに対する脅威を検索します。 脅威が見つからない場合は、ゼロトラスト原則を使用してパケットを暗号化します。 次に、それらを解放します。
Azure Firewall Premium では、セキュリティ チェックが実行されます。
- トランスポート層セキュリティ (TLS) 検査、パケットの復号化と検査を行います。
- 侵入検出と保護 機能により、パケットに悪意があるかどうかを確認します。
パケットがテストに合格した場合、Azure Firewall Premium は次の手順を実行します。
- パケットを暗号化します
- ドメイン ネーム システム (DNS) サービスを使用して、アプリケーション仮想マシン (VM) を決定します
- パケットをアプリケーション VM に転送します
このアーキテクチャのさまざまな検査エンジンにより、トラフィックの整合性が確保されます。
- Web アプリケーション ファイアウォールでは、ルールを使用して 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 が WEB パケットを IP アドレス 172.16.1.4 と TCP ポート 443 に送信するとします。 HTTP ホスト ヘッダーの値は、その IP アドレスに解決されます。
HTTP ホスト ヘッダーには通常、IP アドレスが含まれません。 代わりに、ヘッダーにはサーバーのデジタル証明書に一致する名前が含まれます。 この場合、Azure Firewall Premium は DNS を使用してホスト ヘッダー名を IP アドレスに解決します。 ネットワーク設計では、後のセクションで説明するように、最適な DNS ソリューションが決まります。
手記
Application Gateway では、HTTP ホスト ヘッダーのポート番号はサポートされていません。 その結果：
- Azure Firewall Premium では、既定の HTTPS TCP ポート 443 が想定されています。
- Application Gateway と Web サーバー間の接続では、非標準ポートではなく TCP ポート 443 のみがサポートされます。
デジタル証明書
次の図は、アーキテクチャの TLS セッションと証明書で使用される共通名 (CDN) と証明機関 (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、およびルート サーバーのトポロジの例について詳しく説明します。 ただし、すべてのトポロジに共通する側面がいくつかあります。
- Azure Application Gateway は常にプロキシとして動作し、TLS 検査用に構成されている場合も同様に動作します。クライアントからの TLS セッションは Application Gateway によって終了され、新しい TLS セッションは Azure Firewall に向けて構築されます。 Azure Firewall は、Application Gateway から提供された TLS セッションを受信して終了し、ワークロードに向けた新しい TLS セッションを構築します。 この事実は、Azure Firewall Premium の IDPS 構成に影響を与えます。この詳細については、以下のセクションで詳しく説明します。
- ワークロードには、Azure Firewall のサブネット IP アドレスからの接続が表示されます。 元のクライアント IP アドレスは、Application Gateway によって挿入された
X-Forwarded-ForHTTP ヘッダーに保持されます。 - Application Gateway からワークロードへのトラフィックは、通常、Application Gateway のサブネットで構成された User-Defined ルート、または 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 ゾーンをリンクするためのアクセス許可がありません。 その結果、AZURE Firewall Premium を含むセキュリティで保護されたハブに DNS プライベート ゾーンを関連付けることはできません。 Azure Firewall Premium の DNS 解決を実装するには、代わりに DNS サーバーを使用します。
- カスタム DNS サーバーを使用するように Azure Firewall DNS 設定 を構成します。
- 仮想 WAN に接続する共有サービス仮想ネットワークにサーバーをデプロイします。
- DNS プライベート ゾーンを共有サービス仮想ネットワークにリンクします。 その後、DNS サーバーは、Application Gateway が HTTP ホスト ヘッダーで使用する名前を解決できます。 詳細については、「Azure Firewall の DNS 設定」を参照してください。
仮想 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 ルートのみがサポートされます。 インターネットを指していないこのアドレスを持つルートは、Application Gateway を管理するために Microsoft が必要とする接続を切断します。 仮想ハブが 0.0.0.0/0 ルートをアドバタイズする場合は、次のいずれかの手順を実行して、そのルートが Application Gateway サブネットに伝達されないようにします。
- 0.0.0.0/0 のルートと次ホップの種類の
Internetを含むルート テーブルを作成します。 そのルートを、Application Gateway をデプロイするサブネットに関連付けます。 - Application Gateway を専用スポークにデプロイする場合は、仮想ネットワーク接続の設定で既定のルートの伝達を無効にします。
ルート サーバー トポロジ
ルート サーバー は、スポークにルートを自動的に挿入する別の方法を提供します。 この機能を使用すると、ルート テーブルの管理オーバーヘッドを回避できます。 ルート サーバーは、Virtual WAN とハブ アンド スポークのバリエーションを組み合わせたものになります。
- Route Server を使用すると、お客様はハブ仮想ネットワークを管理できます。 その結果、ハブ仮想ネットワークを DNS プライベート ゾーンにリンクできます。
- ルート サーバーには、Virtual WAN が IP アドレス プレフィックスに関して持っているのと同じ制限があります。 ルートをスポークに挿入できるのは、プレフィックスが仮想ネットワーク プレフィックスよりも短い (具体的ではない) 場合のみです。 この制限により、Application Gateway と移行先 Web サーバーは異なる仮想ネットワークに存在する必要があります。
次の図は、Route Server が動的ルーティングを簡略化する場合のパケット フローを示しています。 次の点に注意してください。
- Route Server では現在、Border Gateway Protocol (BGP) 経由で送信するためにルートを挿入するデバイスが必要です。 Azure Firewall Premium では BGP がサポートされていないため、代わりにサードパーティのネットワーク仮想アプライアンス (NVA) を使用してください。
- ハブ内の NVA の機能によって、実装に DNS が必要かどうかが決まります。
- オンプレミス のクライアントが仮想ネットワーク ゲートウェイに接続します。
- ゲートウェイは、クライアント パケットを Application Gateway に転送します。
- Application Gateway はパケットを調べます。 検査に合格すると、Application Gateway サブネットはパケットをバックエンド マシンに転送します。 ルート サーバーによって挿入された ApplicationGateway サブネット内のルートは、トラフィックを NVA に転送します。
- NVA は、パケットに対してセキュリティ チェックを実行します。 テストに合格すると、NVA はパケットをアプリケーション VM に転送します。
- VM が応答し、宛先 IP アドレスを Application Gateway に設定します。 ルート サーバーによって VM サブネットに挿入されたルートは、NVA にパケットをリダイレクトします。
- NVA はパケットを Application Gateway に転送します。
- Application Gateway は、仮想ネットワーク ゲートウェイにパケットを送信します。
- ゲートウェイがクライアントに応答します。
Virtual WAN と同様に、ルート サーバーを使用するときにルーティングの変更が必要になる場合があります。 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) および 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 アドレスをカスタマイズできます。 たとえば、組織で 100.64.0.0/10 範囲を使用していない場合は、IDPS の内部プレフィックスの一覧からこの範囲を削除し (これを行う方法の詳細については、Azure Firewall Premium プライベート IPDS 範囲 を参照)、100.64.0.0/10の IP アドレスで構成されたサブネットに Application Gateway をデプロイできます。
貢献
この記事は Microsoft によって管理されています。 もともとは次の共同作成者によって作成されました。
プリンシパルの作成者:
- ホセ・モレノ |プリンシパル カスタマー エンジニア
次の手順
関連リソース
- [ネットワーク レベルのセグメント化によるワークロードのセキュリティ保護と管理][ネットワーク レベルのセグメント化によるワークロードのセキュリティ保護と管理]
- セキュリティで保護されたハイブリッド ネットワーク を実装する
- Azure でのハブスポーク ネットワーク トポロジの
- Azure Virtual WAN を使用したハブスポーク ネットワーク トポロジの