この記事では、検査とエンドツーエンドの暗号化を有効にするために、Web アプリのゼロ トラスト セキュリティを実装する方法について説明します。 ゼロ トラスト モデルには、継続的な ID 検証や暗黙的な信頼領域のサイズの最小化など、他の多くの概念が含まれています。
この記事では、パブリック インターネットからの受信トラフィックに対するゼロ トラスト アーキテクチャの暗号化と検査のコンポーネントについて説明します。 認証や承認など、アプリケーションを安全に展開するその他の側面については、 ゼロ トラストのドキュメントを参照してください。 この記事の例では、多層アプローチを使用します。 多層アプローチでは、ネットワーク セキュリティはゼロ トラスト モデルのレイヤーの 1 つを構成します。 この層では、正当なトラフィックだけがアプリケーションに到達するように、ネットワーク アプライアンスによってパケットが検査されます。
通常、さまざまな種類のネットワーク アプライアンスによって、ネットワーク パケットのさまざまな側面が検査されます。
Web アプリケーション ファイアウォールでは、Web アプリケーション層で攻撃を示すパターンが検索されます。
次世代ファイアウォールでは、一般的な脅威も探すことができます。
このアーキテクチャでは、Azure Firewall Premium に到達する前に Azure Application Gateway がトラフィックを検査して処理する、セキュリティを最大化するための一般的なパターンに焦点を当てています。 一部のシナリオでは、さまざまな種類のネットワーク セキュリティ アプライアンスを組み合わせて保護を強化できます。 詳細については、 仮想ネットワークの Azure Firewall と Application Gateway に関するページを参照してください。
アーキテクチャ
このアーキテクチャの Visio ファイルをダウンロードします。
このアーキテクチャでは、トランスポート層セキュリティ (TLS) プロトコルを使用して、すべてのステップでトラフィックを暗号化します。
クライアントは、ロード バランサーである Application Gateway にパケットを送信します。 これは、オプションで Azure Web アプリケーション ファイアウォールを追加して実行されます。
Application Gateway では、パケットの暗号化が解除され、Web アプリケーションへの脅威が検索されます。 脅威が見つからない場合は、ゼロ トラスト原則を使用してパケットを暗号化します。 次に、それらが解放されます。
Azure Firewall Premium では、次のセキュリティ チェックが実行されます。
- TLS 検査 では、パケットの暗号化が解除され、検査されます。
- 侵入検出および防止システム (IDPS) 機能は、悪意のある意図がないかパケットをチェックします。
パケットがテストに合格すると、Azure Firewall Premium によってこれらの手順が実行されます。
- パケットを暗号化します。
- ドメイン ネーム システム (DNS) サービスを使用して、アプリケーション仮想マシン (VM) を決定します。
- パケットはアプリケーション VM に転送されます。
このアーキテクチャのさまざまな検査エンジンによって、トラフィックの整合性が確保されます。
Azure Web Application Firewall では、ルールを使用して Web レイヤーでの攻撃を防ぎます。 攻撃の例としては、SQL コード インジェクションやクロスサイト スクリプティングなどがあります。 規則と Open Worldwide Application Security Project (OWASP) Core Rule Set (CRS) の詳細については、「 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 ソリューションが決まります。
注
Application Gateway では、HTTP ホスト ヘッダーのポート番号はサポートされていません。 その結果：
- Azure Firewall Premium では、既定の HTTPS TCP ポート 443 が想定されます。
- Application Gateway と Web サーバー間の接続では、非標準ポートではなく TCP ポート 443 のみがサポートされます。
デジタル証明書
次の図は、このアーキテクチャの TLS セッションと証明書で使用される共通名 (CDN) と証明機関 (CA) を示しています。
Azure Firewall は、独自の証明書を動的に生成します。 この機能は、Application Gateway の背後に配置される主な理由の 1 つです。 それ以外の場合、アプリケーション クライアントは、セキュリティ リスクとしてフラグが設定された自己生成証明書に直面します。
TLS 接続
このアーキテクチャには、3 つの異なる TLS 接続が含まれています。 デジタル証明書は、それぞれを検証します。
クライアントから Application Gateway へ
Application Gateway では、クライアントに表示されるデジタル証明書をデプロイします。 DigiCert や Let's Encrypt などのよく知られた CA は、通常、そのような証明書を発行します。 このメカニズムは、Azure Firewall が自己署名または内部公開キー インフラストラクチャ 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 プロキシは、デジタル証明書を生成してクライアントに提示することで、ターゲット Web サーバーを偽装します。 Azure Firewall Premium では、動的に生成された証明書に署名するプライベート CA が使用されます。 そのプライベート CA を信頼するように、保護されたクライアントを構成します。 このアーキテクチャでは、Azure Firewall Premium は Application Gateway から Web サーバーへの要求を保護します。 Application Gateway は、Azure Firewall Premium で使用されているプライベート CA を信頼します。
ルーティングとトラフィック転送
ルーティングは、ネットワーク設計のトポロジによって若干異なります。 次のセクションでは、ハブ アンド スポーク、Virtual WAN、およびルート サーバー トポロジの例について説明します。 すべてのトポロジには、次の共通点があります。
Application Gateway は常にプロキシとして機能します。 Azure Firewall Premium は、TLS 検査用に構成されている場合にプロキシとしても機能します。 Application Gateway はクライアントから TLS セッションを終了し、新しい TLS セッションは Azure Firewall に向けて構築されます。 Azure Firewall は、Application Gateway からソース化された TLS セッションを受信して終了し、ワークロードに向けた新しい TLS セッションを構築します。 このプロセスは、Azure Firewall Premium の IDPS 構成に影響します。 詳細については、「 IDPS とプライベート IP アドレス」を参照してください。
ワークロードには、Azure Firewall サブネットの IP アドレスからの接続が表示されます。 元のクライアント IP アドレスは、Application Gateway が挿入する
X-Forwarded-ForHTTP ヘッダーに保持されます。 Azure Firewall では、X-Forwarded-Forヘッダーへのソース クライアント IP アドレスの挿入もサポートされています。 このシナリオでは、ソース クライアントの IP アドレスはアプリケーション ゲートウェイの IP アドレスです。Application Gateway からワークロードへのトラフィックは、通常、Azure ルーティング メカニズムを使用して Azure Firewall に送信されます。 これらのメカニズムには、Application Gateway サブネットで構成されたユーザー定義ルート (UDR) や、Virtual WAN またはルート サーバーによって挿入されるルートが含まれます。 Application Gateway バックエンド プールで Azure Firewall プライベート IP アドレスを明示的に定義することは可能ですが、負荷分散やセッションの持続性など、Application Gateway のネイティブ機能の一部が削除されるため、これを行うことはお勧めしません。
次のセクションでは、Azure Firewall と Application Gateway で使用できる最も一般的なトポロジについて説明します。
ハブとスポークのトポロジ
ハブ とスポークの設計では、通常、ハブ仮想ネットワーク内の共有ネットワーク コンポーネントとスポーク内のアプリケーション固有のコンポーネントがデプロイされます。 ほとんどのシステムで、Azure Firewall Premium は共有リソースです。 Azure Web Application Firewall には、共有ネットワーク デバイスまたはアプリケーション固有のコンポーネントを指定できます。 次の理由から、Application Gateway をアプリケーション コンポーネントとして扱い、スポーク仮想ネットワークにデプロイすることをお勧めします。
Azure Web Application Firewall アラートのトラブルシューティングは困難な場合があります。 通常は、それらのアラームのトリガーとなるメッセージが正当であるかどうかを判断するには、アプリケーションに関する深い知識が必要です。
Application Gateway を共有リソースとして扱う場合は、 Application Gateway の制限を超える可能性があります。
Application Gateway をハブにデプロイすると、ロールベースのアクセス制御の問題に直面する可能性があります。 この状況は、チームが異なるアプリケーションを管理しているが、Application Gateway の同じインスタンスを使用している場合に発生する可能性があります。 その後、各チームは Application Gateway 構成全体にアクセスできます。
従来のハブ アンド スポーク アーキテクチャでは、DNS プライベート ゾーンを使用して DNS を簡単に使用できます。
- DNS プライベート ゾーンを構成します。
- Azure Firewall Premium が含まれている仮想ネットワークにそのゾーンをリンクします。
- Application Gateway がトラフィックと正常性チェックに使用する値のアドレス レコードが存在することを確認します。
次の図は、Application Gateway がスポーク仮想ネットワークにある場合のパケット フローを示しています。 この場合、クライアントはパブリック インターネットから接続します。
クライアントが Web サーバーに要求を送信します。
Application Gateway によってクライアント パケットがインターセプトされて検査されます。 パケットが検査に合格した場合、Application Gateway はパケットをバックエンド VM に送信します。 パケットが Azure に到達すると、Application Gateway サブネット内の UDR によって Azure Firewall Premium に転送されます。
Azure Firewall Premium によってパケットのセキュリティ チェックが実行されます。 テストに合格すると、パケットは Azure Firewall Premium によってアプリケーション VM に転送されます。
VM が応答し、宛先 IP アドレスをアプリケーション ゲートウェイに設定します。 VM サブネットの UDR によってパケットが Azure Firewall Premium にリダイレクトされます。
Azure Firewall Premium によってパケットが Application Gateway に転送されます。
Application Gateway がクライアントに応答します。
トラフィックは、パブリック インターネットではなく、オンプレミス ネットワークから到着することもあります。 トラフィックは、サイト間仮想プライベート ネットワーク (VPN) または Azure 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 を使用してスポーク内にルートをプログラムできるのは、プレフィックスが仮想ネットワークのプレフィックスよりも短い (特定性が低い) 場合のみです。 たとえば、上の図では、スポーク仮想ネットワークにはプレフィックス
172.16.0.0/16があります。 この場合、Virtual WAN は、仮想ネットワーク プレフィックス (172.16.0.0/16) またはサブネット (172.16.0.0/24、172.16.1.0/24) のいずれかに一致するルートを挿入できません。 言い換えると、Virtual WAN は、同じ仮想ネットワーク内にある 2 つのサブネット間でトラフィックを転送することはできません。この制限は、Application Gateway と宛先 Web サーバーが同じ仮想ネットワーク内にある場合に明らかになります。 Virtual WAN では、Application Gateway と Web サーバー間のトラフィックを強制的に Azure Firewall Premium 経由にすることはできません。 回避策の 1 つは、Application Gateway と Web サーバーサブネットで UDR を手動で構成することです。
次の図は、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 は、Virtual WAN とハブ アンド スポークのバリアントを組み合わせたものです。
ルート サーバーを使用して、ハブ仮想ネットワークを管理できます。 その結果、ハブ仮想ネットワークを DNS プライベート ゾーンにリンクできます。
Route Server には、IP アドレスのプレフィックスに関して Virtual WAN と同じ制限があります。 スポークにルートを挿入できるのは、プレフィックスが仮想ネットワークのプレフィックスよりも短い (特定性が低い) 場合のみです。 この制限のため、Application Gateway と宛先の Web サーバーは異なる仮想ネットワーク内にある必要があります。
次の図は、Route Server によって動的ルーティングが簡略化される場合のパケット フローを示しています。 次の点を考慮してください。
現在、Route Server には、Border Gateway Protocol (BGP) で送信するためのルートを挿入するデバイスが必要です。 Azure Firewall Premium は BGP をサポートしていないため、代わりに Microsoft 以外のネットワーク仮想アプライアンス (NVA) を使用してください。
ハブの NVA の機能によって、実装に DNS が必要かどうかが判断されます。
オンプレミス クライアントが仮想ネットワーク ゲートウェイに接続します。
仮想ネットワーク ゲートウェイは、クライアント パケットを Application Gateway に転送します。
Application Gateway によってパケットが検査されます。 検査に合格すると、Application Gateway サブネットはパケットをバックエンド マシンに転送します。 Route Server は、トラフィックを NVA に転送するルートを Application Gateway サブネットに挿入します。
NVA サブネットは、共有サービス仮想ネットワーク内の DNS サーバーから DNS 解決を要求します。
DNS サーバーが解決要求に応答します。
NVA によってパケットに対するセキュリティ チェックが実行されます。 テストに合格すると、NVA によってパケットがアプリケーション VM に転送されます。
アプリケーション VM が応答し、宛先 IP アドレスを Application Gateway に設定します。 ルート サーバーは、パケットを NVA にリダイレクトするルートを VM サブネットに挿入します。
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 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 をデプロイする場合、Azure Firewall Premium では、Application Gateway とワークロード間のトラフィックが内部であると見なされます。 そのため、内部トラフィックまたはすべてのトラフィックに適用されるようにマークされた IDPS 署名のみが使用されます。 受信トラフィックまたは送信トラフィックに適用されるようにマークされた IDPS 署名は、Application Gateway とワークロード間のトラフィックには適用されません。 詳細については、「 Azure Firewall IDPS ルール」を参照してください。
IdPS 受信署名規則を Application Gateway とワークロードの間のトラフィックに適用する最も簡単な方法は、プライベート範囲外のプレフィックスを使用するサブネットに Application Gateway を配置することです。 必ずしもこのサブネットにパブリック IP アドレスを使用する必要はありません。 代わりに、Azure Firewall Premium が IDPS の内部として扱う IP アドレスをカスタマイズできます。 たとえば、組織が 100.64.0.0/10 範囲を使用していない場合は、IDPS の内部プレフィックスの一覧からこの範囲を排除し、 100.64.0.0/10の IP アドレスで構成されたサブネットに Application Gateway をデプロイできます。 詳細については、「 Azure Firewall Premium プライベート IPDS 範囲」を参照してください。
貢献者達
Microsoft では、この記事を保持しています。 次の共同作成者がこの記事を書きました。
主要著者:
- Jose Moreno | プリンシパル カスタマー エンジニア
公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。