ワークロードを管理するチームは、顧客のアクセスに関して完全修飾ドメイン名 (FQDN) に依存することがよくあります。 FQDN は通常、トランスポート層セキュリティ (TLS) の Server Name Indication (SNI) と組み合わされます。 このアプローチでは、パブリック カスタマーがパブリック インターネットからワークロードにアクセスする場合、またはエンタープライズの顧客が内部でワークロードにアクセスする場合、アプリケーションへのルーティングは固定パスに従い、さまざまなレベルのセキュリティまたはサービス品質 (QoS) を持つ可能性があります。
次のアーキテクチャは、ドメイン ネーム システム (DNS) と、顧客のアクセス元がインターネットか企業ネットワークかに基づいて、トラフィックの処理方法が区別されるアプローチを示しています。
Architecture
このアーキテクチャの Visio ファイルをダウンロードします。
次のワークフロー セクションでは、パブリック インターネット ワークフローとプライベート ワークフローの 2 つの構成について説明します。 2 つのワークフローを組み合わせて、スプリット ブレイン ホスティング アーキテクチャを実装します。
パブリック インターネットのワークフロー
このアーキテクチャの Visio ファイルをダウンロードします。
顧客は、パブリック インターネット経由で app.contoso.com アプリケーションの要求を送信します。
Azure DNS ゾーンは、contoso.com ドメイン用に構成されます。 適切な 正規名 (CNAME) エントリが Azure Front Door エンドポイント用に構成されます。
外部の顧客は、グローバル ロード バランサーと Web アプリケーション ファイアウォール (WAF) として機能する Azure Front Door 経由で Web アプリケーションにアクセスします。
Azure Front Door 内では、構成されたエンドポイント上のルートを介して
app.contoso.comが FQDN として割り当てられます。 Azure Front Door では、アプリケーションの TLS SNI 証明書もホストされます。Note
Azure Front Door では、自己署名証明書はサポートされていません。
Azure Front Door は、顧客の
HostHTTP ヘッダーに基づいて、構成された配信元グループに要求をルーティングします。配信元グループは、Application Gateway のパブリック IP アドレスを介して Azure Application Gateway インスタンスを指すよう構成されます。
ネットワーク セキュリティ グループ (NSG) は、AzureFrontDoor.Backend サービス タグからポート 80 とポート 443 での受信アクセスを許可するように AppGW サブネット上に構成されます。 NSG では、インターネット サービス タグからのポート 80 とポート 443 での受信トラフィックは許可されません。
Note
AzureFrontDoor.Backend サービス タグによって、トラフィックが Azure Front Door のインスタンスのみに制限されることはありません。 検証は次の段階で行われます。
Application Gateway インスタンスには、ポート 443 にリスナーがあります。 トラフィックは、リスナー内で指定されたホスト名に基づいてバックエンドにルーティングされます。
トラフィックが Azure Front Door プロファイルから送信されるようにするには、
X-Azure-FDIDヘッダー値をチェックするカスタム WAF 規則を構成します。Azure では、Azure Front Door プロファイルごとに一意識別子が生成されます。 一意識別子は、Azure portal の概要ページにある Front Door ID の値になります。
トラフィックは、Application Gateway でバックエンド プールとして構成されているコンピューティング リソースに到達します。
プライベート エンタープライズのワークフロー
このアーキテクチャの Visio ファイルをダウンロードします。
顧客は、オンプレミス環境から app.contoso.com アプリケーションの要求を開始します。
アプリケーション FQDN は、オンプレミスの DNS プロバイダーに構成されます。 この DNS プロバイダーには、オンプレミスの Windows Server Active Directory DNS サーバーまたはその他のパートナー ソリューションを指定できます。 各アプリケーション FQDN の DNS エントリは、Application Gateway インスタンスのプライベート IP アドレスを指すよう構成されます。
Azure ExpressRoute 回線またはサイト間 VPN を使用すると、Application Gateway へのアクセスが容易になります。
NSG は、トラフィックの発信元であるオンプレミスの顧客ネットワークからの着信プライベート要求を許可するように AppGW サブネット上に構成されます。 この構成により、他のプライベート トラフィック ソースが Application Gateway のプライベート IP アドレスに直接到達できなくなります。
Application Gateway には、ポート 80 とポート 443 に構成されたリスナーがあります。 トラフィックは、リスナー内で指定されたホスト名に基づいてバックエンドにルーティングされます。
Application Gateway でバックエンド プールとして構成されているコンピューティングに到達するのは、プライベート ネットワーク トラフィックのみです。
コンポーネント
DNS: パブリック インターネット ワークフローの場合、Azure Front Door エンドポイント FQDN の適切な CNAME を使用してパブリック Azure DNS ゾーンを構成する必要があります。 プライベート (エンタープライズ) 側で、各アプリケーション FQDN が Application Gateway のプライベート IP アドレスを指すように、ローカル DNS プロバイダー (Windows Server Active Directory DNS またはパートナー ソリューション) を構成します。
Azure DNS Private Resolver: オンプレミスの顧客の解決に DNS Private Resolver を使用できます。 エンタープライズの顧客であれば、このスプリット ブレイン DNS ソリューションを使用して、パブリック インターネットを経由せずアプリケーションにアクセスできます。
Azure Front Door: Azure Front Door は、世界中の顧客にセキュリティで保護された高速の Web アプリケーション配信を提供するグローバル ロード バランサーであり WAF です。 このアーキテクチャでは、Azure Front Door によって外部の顧客は Application Gateway インスタンスにルーティングされ、カスタマー エクスペリエンスを強化するためのキャッシュと最適化のオプションを利用できます。
Application Gateway: Application Gateway は、Web アプリケーションの高可用性、スケーラビリティ、セキュリティを備えたリージョン ロード バランサーであり WAF です。 このアーキテクチャでは、Application Gateway が外部および内部の顧客要求をバックエンド コンピューティングにルーティングし、Web アプリケーションを一般的な Web 攻撃から保護します。
Azure Front Door と Application Gateway はどちらも WAF 機能を備えていますが、このソリューションのプライベート ワークフローでは Azure Front Door は使用されません。 そのため、どちらのアーキテクチャも Application Gateway の WAF 機能を使用します。
ExpressRoute: ExpressRoute を使用すると、接続プロバイダーのサポートを受けて、プライベート接続を介してオンプレミスのネットワークを Microsoft Cloud に拡張できます。 このアーキテクチャでは、ExpressRoute を使用して、オンプレミスの顧客向けに Application Gateway へのプライベート接続を容易化できます。
代替
別の解決策として、Azure Front Door を削除し、代わりにパブリック Azure DNS レコードが Application Gateway のパブリック IP アドレスを指すようにすることもできます。 このアーキテクチャの要件に基づいて、Azure へのエントリ ポイントでキャッシュと最適化を行う必要があります。 そのため、この別の解決策は、このシナリオのオプションにはなりません。 詳しくは、「コスト最適化」を参照してください。
このアーキテクチャの Visio ファイルをダウンロードします。
このアーキテクチャのパブリック イングレス トラフィックについてその他の代替案としては、次のようなものが考えられます。
Azure Traffic Manager: Traffic Manager は、さまざまなリージョンとエンドポイントにトラフィックを分散する DNS ベースのトラフィック ルーティング サービスです。 Azure Front Door の代わりに Traffic Manager を使用して、外部の顧客を最も近い Application Gateway インスタンスにルーティングできます。 ただし、Azure Front Door には、WAF 機能、キャッシュ、セッション アフィニティなどの機能が用意されています。 Traffic Manager では、これらの機能は提供されません。
Azure Load Balancer: Azure Load Balancer は、伝送制御プロトコル (TCP) およびユーザー データグラム プロトコル (UDP) のトラフィックに対して高可用性とスケーラビリティを提供するネットワーク ロード バランサーです。 Application Gateway の代わりに Load Balancer を使用して、外部および内部の顧客要求をバックエンド Web サーバーにルーティングできます。 ただし、Application Gateway には、WAF 機能、Secure Sockets Layer (SSL) ターミネーション、Cookie ベースのセッション アフィニティなどの機能が用意されています。 Load Balancer では、これらの機能は提供されません。
シナリオの詳細
このシナリオでは、外部と内部の両方の顧客にサービスを提供する Web アプリケーションをホストするという問題を解決します。 このアーキテクチャにより、トラフィックは顧客の配信元に基づいて適切なパスをたどることができます。 このアーキテクチャでは、次のことを行います。
世界中のエンタープライズ以外の顧客に、イナーネットを経由した高速で信頼性の高い Web アプリケーションへのアクセスを提供します。
エンタープライズの顧客は、パブリック インターネットを経由せずにアプリケーションにアクセスできます。
Web アプリケーションを一般的な Web 攻撃や悪意のあるトラフィックから保護します。
考えられるユース ケース
このアーキテクチャは、次を必要とするシナリオに使用します。
スプリット ブレイン DNS: このソリューションでは、外部の顧客に Azure Front Door を使用し、内部の顧客に Application Gateway を使用します。サービスごとに異なる DNS レコードを使用します。 このアプローチは、さまざまな顧客のネットワーク パフォーマンス、セキュリティ、可用性を最適化するのに役立ちます。
アプリケーションのスケーラビリティ: このソリューションでは、構成されたバックエンド コンピューティング リソース間でトラフィックを分散できる Application Gateway を使用します。 このアプローチは、アプリケーションのパフォーマンスと可用性を向上させ、水平スケーリングをサポートするのに役立ちます。
考慮事項
以降の考慮事項には、ワークロードの品質向上に使用できる一連の基本原則である Azure "Well-Architected Framework" の要素が組み込まれています。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。
[信頼性]
信頼性により、顧客に確約したことをアプリケーションで確実に満たせるようにします。 詳細については、「信頼性の設計レビュー チェックリスト」を参照してください。
障害点を特定する: このスプリット ブレイン DNS アーキテクチャでは、Azure Front Door、Application Gateway、DNS 構成などの主要なコンポーネントが正しく機能するかどうかは、信頼性によって決まります。 構成の誤り、SSL 証明書の問題、容量のオーバーロードなど、潜在的な障害点を特定する必要があります。
影響を評価する: 障害の影響を評価する必要があります。 外部の顧客の場合、ゲートウェイとして機能する Azure Front Door が中断すると、グローバル アクセスに影響が出る可能性があります。 内部の顧客の場合、Application Gateway が中断すると、エンタープライズ運用が妨げられる可能性があります。
軽減戦略を実装する: リスクを軽減し、複数の可用性ゾーンに冗長性を実装し、リアルタイム監視に正常性プローブを使用し、外部トラフィックと内部トラフィックの両方に対して DNS ルーティングの正しい構成を確保します。 DNS レコードを定期的に更新し、ディザスター リカバリー計画が用意されていることを確認します。
継続的に監視する: システムの正常性を油断なく監視するために、Azure Monitor の機能を使用します。 異常に対するアラートを設定し、潜在的な問題に迅速に対処するためのインシデント対応計画を用意します。
これらの原則に従うことで、課題に耐え、サービス継続性を維持できる堅牢で信頼性の高いシステムを確保します。
セキュリティ
セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。 詳細については、「セキュリティの設計レビュー チェックリスト」を参照してください。
ゼロ トラストアプローチを使用する: スプリット ブレイン DNS のセットアップで、ゼロ トラスト アプローチを適用します。 顧客の ID、顧客のアクセス元がインターネットか企業ネットワークかを明示的に確認します。 このアプローチにより、信頼できるエンティティのみが承認されたアクションを実行できるようになります。
実装: 堅牢な ID 管理のために Microsoft Entra ID を実装します。 Microsoft Entra 条件付きアクセス ポリシーを使用し、顧客のコンテキスト、デバイスの正常性、場所に基づいて厳密なアクセス制御を適用します。
セキュリティの有効性を評価する: 次を実装して、二重アクセス ワークロードに対するセキュリティ対策の有効性を評価します。
防御のための投資: Azure Front Door と Application Gateway の有効性を定期的に評価します。 脅威に対して意味のある保護が提供されていることを確認します。
爆発半径の制限: セキュリティ侵害を限定的な範囲内に抑えるようにします。 たとえば、外部トラフィック フローと内部トラフィック フローを効果的に分離します。
侵害を想定する: 攻撃者がセキュリティ制御を侵害する可能性があることを認識します。 そのようなシナリオに備えましょう。
セキュリティ対策を実装する: ネットワークのセグメント化、マイクロセグメント化、NSG を実装します。 攻撃者がアクセスする可能性があることを想定して、それに応じて補完的な制御を設計します。
これらのセキュリティ原則をスプリットブレイン DNS アーキテクチャに統合して、ワークロードへの内部アクセスと外部アクセスを保護する堅牢で回復性があるシステムを作成します。
その他のセキュリティ強化
Application Gateway: Application Gateway で WAF を使用して、一般的な Web の脆弱性や悪用から Web アプリケーションを保護できます。 また、Azure Private Link を使用して、パブリック インターネットに公開することなく、Application Gateway からバックエンド アプリケーション サーバーに安全にアクセスすることもできます。
Azure Firewall: ハブ仮想ネットワークに Azure ファイアウォールを追加し、Azure Firewall 脅威インテリジェンスを使用して、既知の悪意のある IP アドレスとドメインからのトラフィックをブロックすることができます。 Azure Firewall を DNS プロキシとして使用して、DNS トラフィックをインターセプトして検査し、DNS フィルタリング規則を適用することもできます。
Azure Front Door: Azure Web Application Firewall を使用して、エッジでの一般的な Web の脆弱性や悪用から Web アプリケーションを保護できます 。 また、Azure Front Door Premium レベルで Private Link を使用して、パブリック インターネットに公開することなく、Azure Front Door からバックエンド アプリケーション サーバーに安全にアクセスすることもできます。
コストの最適化
コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳細については、「コスト最適化の設計レビュー チェックリスト」を参照してください。
バックエンド コンピューティング: SKU の選択、レプリカの数、リージョンなど、多くの要因によって、バックエンド コンピューティング サービスの実行コストが高くなります。 ワークロードに最適なオプションを選択する前に、コンピューティング リソースのすべての要素を考慮するようにしてください。
Application Gateway: Application Gateway のコストは、インスタンスの数、インスタンスのサイズ、処理されたデータの量によって異なります。 自動スケーリングを使用して、トラフィックの需要に基づいてインスタンスの数を調整すると、コストを最適化できます。 また、ゾーン冗長 SKU を複数の可用性ゾーンにデプロイすると、高可用性のためにインスタンスを追加する必要性を減らすこともできます。
Azure Front Door: Azure Front Door のコストは、ルーティング規則の数、HTTP 要求または HTTPS 要求の数、転送されたデータの量によって異なります。 Azure Front Door Standard レベルまたは Premium レベルを使用して、Azure Content Delivery Network、Azure Web Application Firewall、Private Link を統合したエクスペリエンスを実現できます。 また、Azure Front Door ルール エンジン機能を使用して、トラフィック管理をカスタマイズし、パフォーマンスとコストを最適化することもできます。
シナリオでグローバル アクセスや Azure Front Door の追加機能が必要ない場合は、Application Gateway のみでこのソリューションを使用できます。 すべてのパブリック DNS レコードが、Application Gateway リスナーに構成されているパブリック IP アドレスを指すようにできます。
このアーキテクチャでのコンポーネントの一般的な使用方法に近い、このソリューションの例を参照してください。 シナリオに合わせてコストを調整します。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパル作成者:
- Troy Hite | Senior Cloud Solution Architect
その他の共同作成者:
- Mays Algebary | Senior Azure Networking Global Blackbelt
- Adam Torkar | Senior Azure Networking Global Blackbelt
- Michael McKechney | Principal Azure Technology Specialist
パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。
次のステップ
- Application Gateway インフラストラクチャの構成
- Azure Front Door を使用したエンド ツー エンド TLS
- Front Door に Custom Domain を追加する
- Azure Front Door のドメインに対するジオフィルタリングとは