スプリット ブレイン DNS 構成を使用して Azure で Web アプリをホストする

Azure Front Door

Azure Application Gateway

Azure ExpressRoute

Azure DNS

ワークロードを管理するチームは、多くの場合、顧客アクセスに完全修飾ドメイン名 (FQDN) を使用します。 FQDN は、通常、トランスポート層セキュリティ (TLS) サーバー名表示 (SNI) と組み合わされます。 このアプローチでは、パブリック ユーザーがパブリック インターネットからワークロードにアクセスするとき、または企業のお客様が内部的にワークロードにアクセスする場合、アプリケーションへのルーティングは固定パスに従い、さまざまなレベルのセキュリティまたはサービス品質 (QoS) を持つ可能性があります。

次のアーキテクチャは、ドメイン ネーム システム (DNS) に基づいてトラフィックを処理する方法と、顧客がインターネットから送信されたか企業ネットワークから送信されたかを区別するアプローチを示しています。

建築

このアーキテクチャの Visio ファイル をダウンロードします。

次のワークフロー セクションでは、パブリック インターネット ワークフローとプライベート ワークフローの 2 つの構成について説明します。 2 つのワークフローを組み合わせて、スプリット ブレイン ホスティング アーキテクチャを実装します。

パブリック インターネット ワークフロー

このアーキテクチャの Visio ファイル をダウンロードします。

1. お客様は、パブリック インターネット経由で app.contoso.com アプリケーションの要求を送信します。

2. Azure DNS ゾーンは、contoso.com ドメイン用に構成されます。 適切な 正規名 (CNAME) エントリは、Azure Front Door エンドポイント用に構成されます。

3. 外部のお客様は、グローバル ロード バランサーと Web アプリケーション ファイアウォール (WAF) として機能する Azure Front Door 経由で Web アプリケーションにアクセスします。

   • Azure Front Door 内では、app.contoso.com は、構成されたエンドポイント上のルートを介して FQDN として割り当てられます。 Azure Front Door では、アプリケーションの TLS SNI 証明書もホストされます。

     手記

     Azure Front Door では、自己署名証明書はサポートされていません。

   • Azure Front Door は、顧客の Host HTTP ヘッダーに基づいて、構成された配信元グループに要求をルーティングします。

   • 配信元グループは、Application Gateway のパブリック IP アドレスを介して Azure Application Gateway インスタンスをポイントするように構成されます。

4. ネットワーク セキュリティ グループ (NSG) は、AzureFrontDoor.Backend サービス タグからポート 80 とポート 443 への受信アクセスを許可するように AppGW サブネット上に構成されます。 NSG では、インターネット サービス タグからのポート 80 とポート 443 での受信トラフィックは許可されません。

   手記

   AzureFrontDoor.Backend サービス タグでは、Azure Front Door の インスタンスを するだけのトラフィックは制限されません。 検証は次の段階で行われます。

5. Application Gateway インスタンスには、ポート 443 で リスナーがあります。 トラフィックは、リスナー内で指定されたホスト名に基づいてバックエンドにルーティングされます。

   • Azure Front Door プロファイル からトラフィックが送信されるようにするには、カスタム WAF 規則 を構成して、 ヘッダー値を確認します。

   • Azure では、Azure Front Door プロファイルごとに一意の識別子が生成されます。 一意識別子は、Azure portal の概要ページにある Front Door ID の値です。

6. トラフィックは、Application Gateway でバックエンド プールとして構成されているコンピューティング リソースに到達します。

プライベート エンタープライズ ワークフロー

このアーキテクチャの Visio ファイル をダウンロードします。

1. お客様は、オンプレミス環境から app.contoso.com アプリケーションの要求を開始します。

2. アプリケーション FQDN は、オンプレミスの DNS プロバイダーで構成されます。 この DNS プロバイダーは、オンプレミスの Windows Server Active Directory DNS サーバーまたはその他のパートナー ソリューションにすることができます。 各アプリケーション FQDN の DNS エントリは、Application Gateway インスタンスのプライベート IP アドレスを指すよう構成されます。

3. Azure ExpressRoute 回線またはサイト間 VPN を使用すると、Application Gateway へのアクセスが容易になります。

4. NSG は、トラフィックの発信元であるオンプレミスの顧客ネットワークからの着信プライベート要求を許可するように AppGW サブネット上に構成されます。 この構成により、他のプライベート トラフィックソースが Application Gateway のプライベート IP アドレスに直接到達できなくなります。

5. Application Gateway には、ポート 80 とポート 443 で構成された リスナー があります。 トラフィックは、リスナー内で指定されたホスト名に基づいてバックエンドにルーティングされます。

6. Application Gateway でバックエンド プールとして構成されているコンピューティングに到達するのは、プライベート ネットワーク トラフィックだけです。

コンポーネント

• DNS: パブリック インターネット ワークフローの場合は、Azure Front Door エンドポイント FQDN の適切な CNAME で パブリック Azure DNS ゾーンを構成する必要があります。 プライベート (エンタープライズ) 側で、ローカル DNS プロバイダー (Windows Server Active Directory DNS またはパートナー ソリューション) を構成して、各アプリケーション FQDN を Application Gateway のプライベート IP アドレスにポイントします。

• Azure DNS プライベート リゾルバー: オンプレミスのお客様の解決に DNS プライベート リゾルバーを使用できます。 エンタープライズのお客様は、このスプリット ブレイン 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 の柱を実装します。これは、ワークロードの品質を向上させるために使用できる一連の基本原則です。 詳細については、「 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 によって管理されています。 もともとは次の共同作成者によって作成されました。

プリンシパルの作成者:

• トロイ・ヒット |シニア クラウド ソリューション アーキテクト

その他の共同作成者:

• メイズ・アルゲバリー |Senior Azure Networking Global Blackbelt
• アダム・トルカー |Senior Azure Networking Global Blackbelt
• マイケル・マッケチニー |プリンシパル Azure テクノロジ スペシャリスト

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次の手順

• Application Gateway インフラストラクチャ構成 の
• Azure Front Door を使用してエンド ツー エンド TLS を する
• Azure Front Door にカスタム ドメインを追加する
• Azure Front Door のドメインでの geo フィルタリングとは

関連リソース

• 仮想ネットワーク 用のファイアウォールと Application Gateway の
• マルチテナント ソリューション で Azure Front Door を使用する

ワークロードを管理するチームは、多くの場合、顧客アクセスに完全修飾ドメイン名 (FQDN) を使用します。 FQDN は、通常、トランスポート層セキュリティ (TLS) サーバー名表示 (SNI) と組み合わされます。 このアプローチでは、パブリック ユーザーがパブリック インターネットからワークロードにアクセスするとき、または企業のお客様が内部的にワークロードにアクセスする場合、アプリケーションへのルーティングは固定パスに従い、さまざまなレベルのセキュリティまたはサービス品質 (QoS) を持つ可能性があります。

次のアーキテクチャは、ドメイン ネーム システム (DNS) に基づいてトラフィックを処理する方法と、顧客がインターネットから送信されたか企業ネットワークから送信されたかを区別するアプローチを示しています。

建築

このアーキテクチャの Visio ファイル をダウンロードします。

次のワークフロー セクションでは、パブリック インターネット ワークフローとプライベート ワークフローの 2 つの構成について説明します。 2 つのワークフローを組み合わせて、スプリット ブレイン ホスティング アーキテクチャを実装します。

パブリック インターネット ワークフロー

このアーキテクチャの Visio ファイル をダウンロードします。

1. お客様は、パブリック インターネット経由で app.contoso.com アプリケーションの要求を送信します。

2. Azure DNS ゾーンは、contoso.com ドメイン用に構成されます。 適切な 正規名 (CNAME) エントリは、Azure Front Door エンドポイント用に構成されます。

3. 外部のお客様は、グローバル ロード バランサーと Web アプリケーション ファイアウォール (WAF) として機能する Azure Front Door 経由で Web アプリケーションにアクセスします。

   • Azure Front Door 内では、app.contoso.com は、構成されたエンドポイント上のルートを介して FQDN として割り当てられます。 Azure Front Door では、アプリケーションの TLS SNI 証明書もホストされます。

     手記

     Azure Front Door では、自己署名証明書はサポートされていません。

   • Azure Front Door は、顧客の Host HTTP ヘッダーに基づいて、構成された配信元グループに要求をルーティングします。

   • 配信元グループは、Application Gateway のパブリック IP アドレスを介して Azure Application Gateway インスタンスをポイントするように構成されます。

4. ネットワーク セキュリティ グループ (NSG) は、AzureFrontDoor.Backend サービス タグからポート 80 とポート 443 への受信アクセスを許可するように AppGW サブネット上に構成されます。 NSG では、インターネット サービス タグからのポート 80 とポート 443 での受信トラフィックは許可されません。

   手記

   AzureFrontDoor.Backend サービス タグでは、Azure Front Door の インスタンスを するだけのトラフィックは制限されません。 検証は次の段階で行われます。

5. Application Gateway インスタンスには、ポート 443 で リスナーがあります。 トラフィックは、リスナー内で指定されたホスト名に基づいてバックエンドにルーティングされます。

   • Azure Front Door プロファイル からトラフィックが送信されるようにするには、カスタム WAF 規則 を構成して、 ヘッダー値を確認します。

   • Azure では、Azure Front Door プロファイルごとに一意の識別子が生成されます。 一意識別子は、Azure portal の概要ページにある Front Door ID の値です。

6. トラフィックは、Application Gateway でバックエンド プールとして構成されているコンピューティング リソースに到達します。

プライベート エンタープライズ ワークフロー

このアーキテクチャの Visio ファイル をダウンロードします。

1. お客様は、オンプレミス環境から app.contoso.com アプリケーションの要求を開始します。

2. アプリケーション FQDN は、オンプレミスの DNS プロバイダーで構成されます。 この DNS プロバイダーは、オンプレミスの Windows Server Active Directory DNS サーバーまたはその他のパートナー ソリューションにすることができます。 各アプリケーション FQDN の DNS エントリは、Application Gateway インスタンスのプライベート IP アドレスを指すよう構成されます。

3. Azure ExpressRoute 回線またはサイト間 VPN を使用すると、Application Gateway へのアクセスが容易になります。

4. NSG は、トラフィックの発信元であるオンプレミスの顧客ネットワークからの着信プライベート要求を許可するように AppGW サブネット上に構成されます。 この構成により、他のプライベート トラフィックソースが Application Gateway のプライベート IP アドレスに直接到達できなくなります。

5. Application Gateway には、ポート 80 とポート 443 で構成された リスナー があります。 トラフィックは、リスナー内で指定されたホスト名に基づいてバックエンドにルーティングされます。

6. Application Gateway でバックエンド プールとして構成されているコンピューティングに到達するのは、プライベート ネットワーク トラフィックだけです。

コンポーネント

• DNS: パブリック インターネット ワークフローの場合は、Azure Front Door エンドポイント FQDN の適切な CNAME で パブリック Azure DNS ゾーンを構成する必要があります。 プライベート (エンタープライズ) 側で、ローカル DNS プロバイダー (Windows Server Active Directory DNS またはパートナー ソリューション) を構成して、各アプリケーション FQDN を Application Gateway のプライベート IP アドレスにポイントします。

• Azure DNS プライベート リゾルバー: オンプレミスのお客様の解決に DNS プライベート リゾルバーを使用できます。 エンタープライズのお客様は、このスプリット ブレイン 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 の柱を実装します。これは、ワークロードの品質を向上させるために使用できる一連の基本原則です。 詳細については、「 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 によって管理されています。 もともとは次の共同作成者によって作成されました。

プリンシパルの作成者:

• トロイ・ヒット |シニア クラウド ソリューション アーキテクト

その他の共同作成者:

• メイズ・アルゲバリー |Senior Azure Networking Global Blackbelt
• アダム・トルカー |Senior Azure Networking Global Blackbelt
• マイケル・マッケチニー |プリンシパル Azure テクノロジ スペシャリスト

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次の手順

• Application Gateway インフラストラクチャ構成 の
• Azure Front Door を使用してエンド ツー エンド TLS を する
• Azure Front Door にカスタム ドメインを追加する
• Azure Front Door のドメインでの geo フィルタリングとは

関連リソース

• 仮想ネットワーク 用のファイアウォールと Application Gateway の
• マルチテナント ソリューション で Azure Front Door を使用する