Azure Front Door
Azure Application Gateway
Azure ExpressRoute
Azure DNS
ワークロードを管理するチームは、多くの場合、顧客アクセスに完全修飾ドメイン名 (FQDN) を使用します。 FQDN は、通常、トランスポート層セキュリティ (TLS) サーバー名表示 (SNI) と組み合わされます。 このアプローチでは、パブリック ユーザーがパブリック インターネットからワークロードにアクセスするとき、または企業のお客様が内部的にワークロードにアクセスする場合、アプリケーションへのルーティングは固定パスに従い、さまざまなレベルのセキュリティまたはサービス品質 (QoS) を持つ可能性があります。
次のアーキテクチャは、ドメイン ネーム システム (DNS) に基づいてトラフィックを処理する方法と、顧客がインターネットから送信されたか企業ネットワークから送信されたかを区別するアプローチを示しています。
Architecture
このアーキテクチャの Visio ファイル をダウンロードします。
次のワークフロー セクションでは、パブリック インターネット ワークフローとプライベート ワークフローの 2 つの構成について説明します。 2 つのワークフローを組み合わせて、スプリット ブレイン ホスティング アーキテクチャを実装します。
パブリック インターネット ワークフロー
このアーキテクチャの Visio ファイル をダウンロードします。
お客様は、パブリック インターネット経由で
app.contoso.comアプリケーションの要求を送信します。Azure DNS ゾーンは、contoso.com ドメイン用に構成されます。 適切な正規名 (CNAME) エントリは、Azure Front Door エンドポイント用に構成されます。
外部のお客様は、グローバル ロード バランサーと Web アプリケーション ファイアウォール (WAF) として機能する Azure Front Door Standard または Premium を使用して 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 に リスナー があります。 トラフィックは、リスナー内で指定されたホスト名に基づいてバックエンドにルーティングされます。
トラフィックは、Application Gateway でバックエンド プールとして構成されているコンピューティング リソースに到達します。
プライベート エンタープライズ ワークフロー
このアーキテクチャの Visio ファイル をダウンロードします。
お客様は、オンプレミス環境から
app.contoso.comアプリケーションの要求を開始します。アプリケーション FQDN は、オンプレミスの DNS プロバイダーで構成されます。 この DNS プロバイダーは、オンプレミスの Active Directory Domain Services (AD DS) DNS サーバーまたはその他のパートナー ソリューションにすることができます。 各アプリケーション FQDN の DNS エントリは、Application Gateway インスタンスのプライベート IP アドレスを指すよう構成されます。
Azure ExpressRoute 回線またはサイト間 VPN を使用すると、Application Gateway へのアクセスが容易になります。
NSG は、トラフィックの発信元であるオンプレミスの顧客ネットワークからの着信プライベート要求を許可するように AppGW サブネット上に構成されます。 この構成により、他のプライベート トラフィックソースが Application Gateway のプライベート IP アドレスに直接到達できなくなります。
Application Gateway には、ポート 80 とポート 443 で構成された リスナー があります。 トラフィックは、リスナー内で指定されたホスト名に基づいてバックエンドにルーティングされます。
Application Gateway でバックエンド プールとして構成されているコンピューティングに到達するのは、プライベート ネットワーク トラフィックだけです。
Components
DNS は、ドメイン名を IP アドレスにマップするシステムです。これにより、クライアントはサービスを検索して接続できます。 このアーキテクチャのパブリック インターネット ワークフローの場合は、Azure Front Door エンドポイント FQDN の適切な CNAME を使用してパブリック DNS ゾーンを構成する必要があります。 プライベート (エンタープライズ) 側で、ローカル DNS プロバイダー (AD DS DNS またはパートナー ソリューション) を構成して、各アプリケーション FQDN を Application Gateway のプライベート IP アドレスにポイントします。
Azure DNS Private Resolver は、カスタム DNS サーバーをデプロイせずに、オンプレミス環境とAzureの間で DNS 解決を有効にするフル マネージド サービスです。 このアーキテクチャでは、DNS プライベート リゾルバーによってオンプレミスの顧客の解決が可能になるため、エンタープライズ ユーザーはこのスプリットブレイン DNS ソリューションを使用して、パブリック インターネットを通過することなくアプリケーションにアクセスできます。
Azure Front Door は、グローバル なロード バランサーと WAF であり、グローバルな顧客に迅速かつ安全な Web アプリケーション配信を提供します。 このアーキテクチャでは、Azure Front Door Standard または Premium は外部の顧客を Application Gateway インスタンスにルーティングし、カスタマー エクスペリエンスを強化するためのキャッシュと最適化のオプションを提供します。
Application Gateway は、Web アプリケーションの高可用性、スケーラビリティ、セキュリティを提供するリージョンロード バランサーと WAF です。 このアーキテクチャでは、Application Gateway は外部および内部の顧客要求をバックエンド コンピューティングにルーティングし、Web アプリケーションを一般的な Web 攻撃から保護します。
Azure Front Door と Application Gateway はどちらも WAF 機能を提供しますが、このソリューションのプライベート ワークフローでは Azure Front Door は使用されません。 その結果、両方のアーキテクチャで Application Gateway WAF 機能が使用されます。
ExpressRoute は、接続プロバイダーによって確立されたプライベート接続を介して、オンプレミス ネットワークをクラウドに拡張するサービスです。 このアーキテクチャでは、ExpressRoute を使用すると、オンプレミスのお客様向けに Application Gateway へのプライベート接続が容易になります。
Alternatives
代替案として、Azure Front Door の Standard または Premium を削除し、パブリック DNS レコードを Application Gateway のパブリック IP アドレスに設定することもできます。 このアーキテクチャの要件に基づいて、キャッシュし、エントリ ポイントでトラフィックをAzureに最適化する必要があります。 その結果、このシナリオの代替ソリューションを使用することはできません。 詳細については、「 コストの最適化」を参照してください。
このアーキテクチャの Visio ファイル をダウンロードします。
このアーキテクチャのパブリック イングレス トラフィックには、次のような代替手段が考えられます。
Azure Traffic Manager: Traffic Manager は、さまざまなリージョンとエンドポイントにトラフィックを分散する DNS ベースのトラフィック ルーティング サービスです。 Azure Front Door Standard または Premium ではなく 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 攻撃や悪意のあるトラフィックから保護します。
潜在的なユース ケース
このアーキテクチャは、次を必要とするシナリオに使用します。
Split-brain DNS: このソリューションでは、外部顧客向けのAzure Front Doorと、サービスごとに異なる DNS レコードを持つ内部顧客向けの Application Gateway が使用されます。 このアプローチは、さまざまなお客様のネットワーク パフォーマンス、セキュリティ、可用性を最適化するのに役立ちます。
アプリケーションのスケーラビリティ: このソリューションでは Application Gateway を使用します。これにより、構成されたバックエンド コンピューティング リソース間でトラフィックを分散できます。 このアプローチは、アプリケーションのパフォーマンスと可用性を向上させ、水平スケーリングをサポートするのに役立ちます。
Considerations
これらの考慮事項では、Azure Well-Architected Framework の柱を実装します。これは、ワークロードの品質を向上させるために使用できる一連の基本原則です。 詳細については、「 Well-Architected Framework」を参照してください。
Reliability
信頼性は、アプリケーションが顧客に対して行ったコミットメントを確実に満たすことができるのに役立ちます。 詳細については、「信頼性
障害ポイントを特定します。 このスプリット ブレイン DNS アーキテクチャでは、信頼性は、Azure Front Door、Application Gateway、DNS 構成などの主要なコンポーネントの正しい機能に影響します。 構成の誤り、SSL 証明書の問題、容量のオーバーロードなど、潜在的な障害ポイントを特定する必要があります。
影響を評価します。 障害の影響を評価する必要があります。 外部のお客様の場合、ゲートウェイとして機能する Azure Front Door の中断がグローバル アクセスに影響する可能性があります。 内部のお客様の場合、Application Gateway が中断されると、企業の運用が妨げになる可能性があります。
軽減戦略を実装します。 リスクを軽減するには、 複数の可用性ゾーンに冗長性を実装し、リアルタイム監視に 正常性プローブ を使用し、外部トラフィックと内部トラフィックの両方に対して DNS ルーティングの正しい構成を確保します。 DNS レコードを定期的に更新し、ディザスター リカバリー計画があることを確認します。
継続的に監視します。 システムの正常性を注意深く監視するには、Azure Monitor機能を使用します。 異常のアラートを設定し、潜在的な問題に迅速に対処するためのインシデント対応計画を用意します。
これらの原則に従って、課題に耐え、サービス継続性を維持できる堅牢で信頼性の高いシステムを確保します。
セキュリティ
セキュリティは、意図的な攻撃や貴重なデータとシステムの誤用に対する保証を提供します。 詳細については、「セキュリティ設計レビューチェックリスト」を参照してください。
ゼロ トラストアプローチを使用します。 スプリット ブレイン DNS のセットアップで、ゼロ トラスト アプローチを適用します。 顧客がインターネットまたは企業ネットワークから発信されたかどうか、顧客の ID を明示的に確認します。 この方法により、信頼されたエンティティのみが承認されたアクションを実行できるようになります。
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 firewallを追加し、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 アドレスにポイントできます。
このアーキテクチャでのコンポーネントの一般的な使用方法に近い、 このソリューションの例 を参照してください。 シナリオに合わせてコストを調整します。
Contributors
Microsoft では、この記事を保持しています。 この記事を書いたのは、以下の寄稿者です。
主要著者:
- トロイ・ヒット |シニア ソリューション エンジニア
その他の共同作成者:
- メイズ・アルゲバリー | シニア Azure ネットワーキング グローバル ブラックベルト
- マイケル・マッケチニー |プリンシパル Azure テクノロジ スペシャリスト
- アダム・トルカー | シニア Azure Networking グローバル・ブラックベルト
公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。
次のステップ
- Application Gateway インフラストラクチャ構成
- Azure Front Door を使用してエンド ツー エンド TLS を実現する
- Azure Front Door にカスタム ドメインを追加する
- Azure Front Door のドメインでの geo フィルタリングとは
関連リソース
- 仮想ネットワーク用のファイアウォールおよびアプリケーションゲートウェイ
- マルチテナント ソリューション で Azure Front Door を使用する