この記事は、インターネットからアプリケーションにアクセスできるようにするための適切なAzure サービスを選択するのに役立ちます。 パブリック IP アドレス、Azure Load Balancer、Application Gateway、Azure Front Door、およびAzure Traffic Managerを比較します。 ワークロードのプロトコル、スケール、およびセキュリティの要件に合ったオプションを選択します。
この記事の内容
外部ユーザーにサービスを提供するすべてのAzureワークロードには、インターネット トラフィックがアプリケーションに安全かつ確実に到達するための方法であるイングレス パスが必要です。 間違ったイングレス サービスを選択すると、オーバープロビジョニング、セキュリティギャップ、または不要な複雑さにつながります。 この記事では、外部ユーザーからの受信接続を受け入れ、それらの接続を仮想ネットワーク内のバックエンド リソースにルーティングする 7 つのAzure サービスを評価するのに役立ちます。 プロトコル、スケール、地理、およびセキュリティ体制に一致する組み合わせを選択できます。
Note
この記事では、インターネットからAzure ネットワークにトラフィックが入る方法について説明します。 アプリケーション バックエンド間でそのトラフィックのバランスを取って配信する方法 (Azure Load Balancer、Application Gateway、Azure Front Doorの詳細な比較を含む) については、アプリケーションの配信とパフォーマンスに関する記事を参照してください。
この記事が必要なユーザー
これらの条件の 1 つ以上が該当する場合は、この記事をお読みください。
- アプリケーションは、インターネット上のユーザーまたはシステムからの受信接続を受け入れる必要があります。
- プロトコルとスコープに基づいて、パブリック IP、Load Balancer、Application Gateway、Front Door、または Traffic Manager の中から選択する必要があります。
- Web、API、または TCP/UDP ワークロード用のセキュリティで保護されたパブリック エントリ ポイントを設計する必要があります。
- インターネットへの公開を WAF、DDoS 保護、TLS 終了、またはリージョンとグローバルのトラフィック分散と組み合わせる必要があります。
Tip
シナリオパスに従っていますか? カスタマイズされたガイダンスについては、ページの上部にあるシナリオを選択してください。 以下の主要なガイダンスは、すべての読者に適用されます。
リフトアンドシフトフォーカス: 移行されたアプリは、インターネットから到達可能である必要があります。 Application Gateway、Front Door、またはより単純なパブリック IP アプローチが必要かどうかを評価します。 リフト アンド シフト ワークロードの多くは内部専用であるため、移行されたアプリが外部ユーザーにサービスを提供しない場合は、この記事を完全にスキップできます。
次の場合は、この記事をお読みください。
- オンプレミスの Web アプリケーションをAzureに移行しており、パブリックに公開する方法を決定する必要があります。
- 移行されたワークロードにインターネットイングレスがまったく必要かどうかを評価する必要があります。
- リフトされたアプリケーションの最も単純な運用対応のイングレス オプションを理解したい。
最新化の焦点: 顧客向けのトラフィック パターンによって、アーキテクチャの外部形状が決まります。 Front Door は Web アプリを処理し、Traffic Manager はモバイル アプリと API アプリを処理します。 最新化された PaaS ワークロード (App Service、AKS) には、ハブスポーク セキュリティ モデルと統合する明確に定義されたイングレス パスが必要です。
次の場合は、この記事をお読みください。
- 外部ユーザーがインターネット経由でアクセスする公開アプリケーションをデプロイします。
- Web アプリケーション用のAzure Front Doorとモバイルワークロードまたは API ワークロード用の Traffic Manager のどちらかを選択する必要があります。
- イングレスとハブ ファイアウォールを DNAT ターゲットとして統合する方法を理解したいと考えています。
- Web アプリケーション ファイアウォール (WAF) または DDoS 保護を使用して、インターネットに接続するエンドポイントを保護する必要があります。
クラウド間のフォーカス: 移行されたアプリが公開されている場合にのみ、インターネットイングレスを含めます。 多くのクロスクラウド アプリケーションは内部専用であり、プライベート トランジット パス経由でクラウド間で通信します。 ワークロードが一般向け (たとえば、別のクラウドから移行された顧客向け Web アプリ) の場合は、Azureにイングレス パスが必要です。
次の場合は、この記事をお読みください。
- 一般向けアプリケーションを AWS または Google Cloud から Azure に移行しています。
- 移行されたワークロードのスポーク VNet に WAF を備えた Application Gateway が必要です。
- クラウド間の移行中に VM にパブリック IP を直接割り当てないようにする必要があります。
Azureサービスと機能
Azureでは、インターネットイングレス用のいくつかのサービスが提供されます。 各サービスは、ネットワーク スタックの異なるレイヤーで動作し、異なるユース ケースを提供します。
| サービス | レイヤー | Scope | 提供される内容 | いつ使用するか |
|---|---|---|---|---|
| パブリック IP アドレス (Standard SKU) | 3 | 地域 | 直接割り当てられたルーティング可能な IPv4 または IPv6 アドレス。 ゾーンは既定で冗長です。 | 単純でトラフィックの少ないシナリオ。 ロード バランサーのない運用環境ではお勧めしません。 |
| Azure Load Balancer (Standard、public) | 4 (TCP/UDP) | 地域 | バックエンド VM 間で受信 TCP/UDP トラフィックを分散します。 ゾーン冗長フロントエンド。 正常性チェックによって、正常でないインスタンスが除外されます。 | 高可用性を必要とする HTTP/S 以外のワークロード。 ゲーム サーバー、IoT エンドポイント、またはその他の TCP/UDP サービス。 |
| Azure Load Balancer (標準、内部) | 4 (TCP/UDP) | 地域 | 仮想ネットワーク内のレイヤー 4 の負荷分散。 パブリック IP はありません。 内部層間でトラフィックをルーティングします。 | パブリック フロントエンドがバックエンド VM に配布される多層アプリ。 ハブ アンド スポーク型の東西トラフィック。 インターネットに直接接続するのではなく、一般的にパブリック イングレス サービスとペアになります。 |
| Azure Application Gateway | 7 (HTTP/S) | 地域 | URL ベースのルーティング、SSL/TLS 終了、セッション アフィニティ、自動スケールによる HTTP/S 負荷分散。 | パスベースのルーティング、Cookie ベースのアフィニティ、または SSL オフロードを必要とする単一リージョンの HTTP/S アプリ。 |
| Application Gateway + WAF | 7 (HTTP/S) | 地域 | Web アプリケーション ファイアウォールを備えた Application Gateway。 Microsoft Threat Intelligence ルールを含む既定のルール セット (DRS) を使用して、OWASP Top 10 の攻撃から保護します。 | レイヤー 7 の負荷分散と WAF 保護を 1 つのリージョンで必要とする公開 Web アプリ。 |
| Azure Front Door | 7 (HTTP/S) | グローバル | CDN、WAF、トラフィック ルーティングが統合されたグローバル HTTP/S ロード バランサー。 分割 TCP アクセラレーションを使用して、ユーザーの近くのエッジ POP で TCP/TLS を終了します。 | グローバル ユーザー ベースを持つマルチリージョン アプリ。 CDN キャッシュ、グローバル WAF、自動フェールオーバーを必要とするワークロード。 |
| Azure Traffic Manager | DNS | グローバル | DNS ベースのトラフィック ルーティング。 最も近いリージョン エンドポイントまたは最も正常性の高いリージョン エンドポイントに CNAME を返します。 クライアントは直接接続します。 Traffic Manager では、アプリケーション トラフィックは表示されません。 | 複数リージョンの DNS レベルのフェールオーバー。 Front Door が適用されない HTTP/S 以外のプロトコル。 地理的、パフォーマンス、または優先順位によるルーティング。 |
Note
Basic SKU パブリック IP は廃止されます (2025 年 9 月)。 既存の Basic IP は引き続き動作しますが、SLA なしではサポートされていません。 すべての新しいデプロイに Standard SKU を使用します。
各サービスのしくみ
各サービスの内部アーキテクチャを理解すると、パフォーマンスの予測、問題のトラブルシューティング、サブネットのサイズ設定の計画に役立ちます。
パブリック IP アドレス
Standard SKU パブリック IP は、ルーティング可能な IPv4 または IPv6 アドレスをネットワーク インターフェイス、ロード バランサー フロントエンド、またはゲートウェイに直接マップするソフトウェア定義リソースです。 サポートされているリージョンでは、アドレスは既定でゾーン冗長です。つまり、プラットフォームは可用性ゾーン間のフェールオーバーを処理します。この部分は変更されません。 パブリック IP にはトラフィック処理がありません。 パケットは、正常性チェックや分散ロジックなしで、アタッチされたリソースに直接送信されます。
Azure Load Balancer (Standard、public)
Standard Load Balancerは、5 タプル フロー (ソース IP、送信元ポート、宛先 IP、宛先ポート、プロトコル) 全体でハッシュベースの分散アルゴリズムを使用します。 レイヤー 4 のデータ パスで完全に動作するため、接続を終了したり、ペイロードを検査したりすることはありません。 正常性プローブ (TCP、HTTP、または HTTPS) は、バックエンド インスタンスを継続的にポーリングし、異常なインスタンスを数秒以内にローテーションから削除します。 Load Balancer自動的にスケーリングされます。 容量計画やインスタンスのサイズ設定はありません。
Azure Load Balancer (標準、内部)
内部Load Balancerはパブリックに対応するものと同じように機能しますが、仮想ネットワーク サブネットのプライベート フロントエンド IP を使用します。 中間層 API クラスターにトラフィックを送信する Web 層など、内部層間でトラフィックが分散されます。 パブリック IP がないため、インターネットからは見えません。 外部境界を処理する Front Door、Application Gateway、パブリック Load Balancerなどのパブリック イングレス サービスとペアリングします。
Azure Application Gateway
Application Gateway は、仮想ネットワーク サブネットにデプロイされた専用の仮想アプライアンスです。 ゲートウェイで TLS 接続を終了し、HTTP ヘッダーと URL を検査し、パス規則、ホスト ヘッダー、またはカスタム正常性プローブに基づいてバックエンド プールに要求をルーティングします。 v2 SKU では、自動スケーリング (0 ~ 125 インスタンス) とゾーン冗長性がサポートされます。 VNet に常駐しているため、これらのバックエンドでパブリック IP を必要とせずにプライベート バックエンドに到達できます。
WAF を使用した Application Gateway
WAF ティアを追加すると、Application Gateway の処理パイプラインで OWASP Core Rule Set と Microsoft Threat Intelligence ルールが直接有効になります。 すべての HTTP 要求は、ルーティング規則に到達する前に WAF エンジンを通過します。 WAF はサイトごとのポリシーをサポートしているため、同じゲートウェイ上のリスナーまたはホストの組み合わせごとに異なるルール構成を設定できます。 WAF は、検出 (ログのみ) モードまたは防止 (ブロックとログ) モードで動作します。
Azure Front Door
Front Door は、Microsoftグローバル エッジ ネットワーク (190 以上のプレゼンス ポイント) から動作します。 ユーザーが接続すると、スプリット TCP を使用して、最も近いプレゼンス ポイントで TCP ハンドシェイクと TLS ネゴシエーションが行われます。 ポイントオブプレゼンスはオリジンサーバーへの持続的なウォーム接続を維持するため、ユーザーが直接接続した場合に発生するコールドスタートの待機時間を解消します。 Front Door は、エッジでレイヤー 7 のルーティング、WAF 検査、キャッシュ、圧縮を実行してから、Microsoftバックボーン ネットワーク経由で最も近い正常な配信元に要求を転送します。
Azure Traffic Manager
Traffic Manager は、データ パスが関与しない DNS ベースのサービスです。 クライアントは、Traffic Manager のホスト名を解決すると、ルーティング方法 (優先順位、重み付け、パフォーマンス、地理的、複数値、またはサブネット) に基づいて最も正常性または最も近いエンドポイントを指す CNAME を返します。 Traffic Manager は、エンドポイントの正常性を継続的にプローブし、それに応じて DNS 応答を更新します。 アプリケーション トラフィックは表示されないため、HTTP、TCP、UDP、または独自のプロトコルなど、任意のプロトコルで動作します。
コスト モデルの比較
各イングレス サービスは、異なる課金モデルに従います。 この表を使用して、予想されるトラフィック量のコストを見積もります。
| サービス | 課金モデル | 主なコスト 要因 | 無料プランまたは含まれる機能 |
|---|---|---|---|
| パブリック IP アドレス | 1 時間あたり (接続) + 1 GB あたりのアウトバウンド | 添付時間数、エグレス料金 | 最初の 100 GB の 1 か月あたりの送信は無料 (グローバル) |
| Standard Load Balancer | 1時間・1ルールあたり + 処理された1 GBあたり | 負荷分散規則の数。LB を介して処理されるデータ | None |
| Application Gateway | インスタンスあたりの 1 時間あたりの使用量 + 使用された容量ユニット数 | インスタンス時間；コンピュート、接続、およびスループットの容量単位 | None |
| Application Gateway + WAF | インスタンスあたりの 1 時間あたりの (WAF レベルの価格) + 容量ユニット | Application Gateway と同じですが、WAF レベルの時間単位料金が適用されます | None |
| Azure Front Door | リクエストごと + GB ごとの転送 + WAF リクエスト | ルーティング要求、エッジからクライアントへのデータ転送、WAF ルールの評価 | Standard レベルには、一部の基本ルーティングが含まれています |
| Azure Traffic Manager | DNS クエリ 100 万件あたり + ヘルスチェック エンドポイントあたり | DNS クエリの量。監視対象エンドポイントの数 | 最初の 10 億件のクエリで価格が階層化されている |
Tip
トラフィックの少ないワークロード (1 か月あたり 100 万件未満の要求) の場合、Front Door の要求ごとのモデルは、Application Gateway の 1 時間あたりの固定コストよりも経済的な場合があります。 トラフィックの増加に伴い、1 時間あたりのモデルの予測性が高まります。 予想されるスループットを比較するために、Azure料金計算ツールを実行します。
選択する方法
次のデシジョン テーブルを使用して、ワークロードに適したイングレス サービスを選択します。 大まかな決定表から始めて、詳細な比較を使用して選択内容を確認します。
Application Gateway と Front Door と Traffic Manager
この表は、最も一般的な 3 つの HTTP および HTTPS イングレス サービスの中から選択するのに役立ちます。
| お客様のニーズ | 推奨されるサービス | なぜでしょうか |
|---|---|---|
| HTTP/S トラフィック、単一リージョン、WAF 保護 | WAF を使用した Application Gateway | パスベースのルーティングと WAF を使用するリージョンレイヤー 7 サービス。 仮想ネットワーク内で実行されます。 |
| HTTP/S トラフィック、マルチリージョン、グローバル ユーザー、CDN + WAF | Azure Front Door | エッジ POP で終了するグローバル レイヤー 7 サービス。 組み込みの CDN、WAF、自動フェールオーバー。 |
| HTTP/S 以外のプロトコルのマルチリージョン ルーティング、または DNS レベルのルーティングのみ | Azure Traffic Manager | 任意のプロトコルで動作する DNS ベースのルーティング。 接続終了なし。 |
| リージョン VNet にバインドされた処理要件を持つマルチリージョン HTTP/S | Application Gateway + Traffic Manager | 詳細な VNet 統合またはリージョン WAF 検査によるリージョン データ主権を必要とするワークロードに対して有効です。 ほとんどのマルチリージョン HTTP/S シナリオでは、代わりに Front Door を使用してください。 |
Tip
ほとんどのマルチリージョン HTTP および HTTPS ワークロードでは、Traffic Manager と組み合わせた Application Gateway よりも Front Door が推奨されます。 Front Door には、複数のリージョンの Application Gateway インスタンスを管理する必要なく、組み込みの WAF、CDN、自動フェールオーバーが用意されています。 Application Gateway と Traffic Manager の組み合わせは、リージョンの VNet バインド処理を必要とするワークロード、VNet 内でのみアクセス可能なPrivate Linkオリジン、または地域データ主権を管理する規制要件に対して引き続き有効です。
イングレス サービスの比較
各サービスの機能を理解する必要がある場合は、この詳細な比較を使用します。
| サービス | レイヤー | グローバルまたは地域 | 接続の終了 | WAF が利用可能です | ヘルスプローブ | 最適な用途 |
|---|---|---|---|---|---|---|
| パブリック IP アドレス | 3 | 地域 | いいえ (VM に直接) | No | No | HA 要件のない開発/テストの単一インスタンス ワークロード |
| Standard Load Balancer (公開) | 4 | 地域 | いいえ (パススルー) | No | はい (TCP、HTTP、HTTPS) | HTTP 以外のワークロード: ゲーム、IoT、カスタム TCP/UDP |
| Standard Load Balancer (内部向け) | 4 | 地域 | いいえ (パススルー) | No | はい (TCP、HTTP、HTTPS) | パブリック イングレス サービスの背後にある内部層 |
| Application Gateway | 7 | 地域 | はい (TLS 終了) | いいえ (WAF 層を追加) | はい (HTTP/S カスタム) | パスベース ルーティングを備えた単一リージョン HTTP/S |
| Application Gateway + WAF | 7 | 地域 | はい (TLS 終了) | はい (DRS ルールセット) | はい (HTTP/S カスタム) | WAF を必要とする単一リージョン Web アプリ |
| Azure Front Door | 7 | グローバル | はい (PoP で TCP を分割) | はい (組み込み) | はい (HTTP/S) | グローバル アクセラレーションを使用したマルチリージョン HTTP/S |
| Azure Traffic Manager | DNS | グローバル | いいえ (DNS のみ) | No | はい (HTTP/S、TCP) | 複数リージョンの DNS レベルのフェールオーバー、任意のプロトコル |
インターネットイングレス アーキテクチャ
次の図は、Azure ワークロードへの受信トラフィックの一般的なサービス チェーン パターンを示しています。 各パターンは、レイヤー 7 とレイヤー 4 のサービスを組み合わせて、特定のプロトコル、リージョンスコープ、およびセキュリティ体制に一致します。
一般的なイングレス パターン
次のパターンでは、完全なイングレス アーキテクチャのために複数のサービスを組み合わせます。 プロトコルの要件、リージョンスコープ、およびセキュリティ体制に一致するパターンを選択します。
パターン 1: エッジ セキュリティを備えたグローバル Web アプリケーション
サービス： Front Door → Application Gateway (WAF を使用) → VM/コンテナー
シナリオ： 北米、ヨーロッパ、アジアの顧客にサービスを提供する SaaS アプリケーションには、グローバルアクセラレーション、エッジでの DDoS 保護、およびさまざまなマイクロサービスへのリージョンパスベースのルーティングが必要です。
Front Door は、最も近いプレゼンス ポイント (PoP) でユーザー接続を終了し、グローバル WAF ルールを適用して、静的コンテンツをキャッシュします。 トラフィックは、Microsoft バックボーン経由でリージョン Application Gateway にルーティングされ、URL ベースのルーティングが実行されます (たとえば、API プールへの/api/*、ストレージ バックエンドへの/static/*)。 このパターンでは、2 つの WAF 検査レイヤー (1 つはエッジ、1 つはリージョン) が提供されます。
パターン 2: DNS フェールオーバーを使用するマルチリージョンの非 HTTP 構成
サービス：Traffic Manager → Standard Load Balancer (リージョンごと) → VM
シナリオ： あるゲーム会社は、3 つのリージョンにわたって UDP ポート 7777 で専用のゲーム サーバーを実行しています。 プレイヤーは、最も近い正常なリージョンに自動的に接続します。
Traffic Manager は、パフォーマンス ルーティング方法を使用して、待機時間が最も短いリージョンの DNS レコードを返します。 各リージョンには、仮想マシン スケール セット間で UDP トラフィックを分散するStandard Load Balancerがあります。 正常性プローブでリージョンの障害が検出された場合、Traffic Manager は DNS を更新して、プレイヤーを次に近いリージョンにルーティングします。
パターン 3: WAF を使用したシンプルなリージョン Web アプリ
サービス: Application Gateway (WAF を使用) → VM
シナリオ： 外部パートナーに公開されている内部基幹業務アプリケーション。 単一リージョンの中程度のトラフィックには、OWASP 保護と TLS 終了が必要です。
Application Gateway では、パスベースのルーティング、セッション管理のための Cookie アフィニティ、および WAF 保護が、すべて仮想ネットワーク内の単一のリージョン リソースから提供されます。 このパターンにより、トラフィックが地理的に集中している場合のグローバル サービスの複雑さとコストが回避されます。
パターン 4: プライベート オリジンへのアクセスが制限された Front Door
サービス: Front Door Premium → Private Link → 内部ロード バランサー → VM 群
シナリオ： 配信元がパブリック IP 公開を持たてはならないという厳密な要件を持つ金融サービス アプリケーション。 すべてのトラフィックは、パブリック インターネット ホップなしでMicrosoftバックボーン ネットワークを通過する必要があります。
Front Door Premium は、Private Link エンドポイントを介して配信元に接続します。 配信元バックエンドにはパブリック IP アドレスがなく、インターネットへの公開もありません。 このパターンにより、完全にプライベートな配信元のセキュリティと、Front Door のグローバル エッジ ネットワークのパフォーマンス上の利点が組み合わされます。
Front Door を使用した複数リージョンのイングレス
次の図は、グローバル エントリ ポイントとしてのAzure Front Doorを示しています。自動フェールオーバーを使用して、最も近い正常なリージョンの配信元にユーザーをルーティングします。
前提条件
アプリケーションをインターネットに公開する前に、次のコンポーネントが配置されていることを確認してください。
- デプロイされた仮想ネットワーク:バックエンド リソースは、適切なサイズのサブネットを持つAzure仮想ネットワーク内で実行する必要があります。 サブネット計画のガイダンスについては、 仮想ネットワークとサブネットの設計 に関するページを参照してください。
- 実行中のワークロード: トラフィックを処理するには、少なくとも 1 つのバックエンド リソース (仮想マシン、コンテナー、またはプラットフォーム サービス) が必要です。
- DNS 名: 外部ユーザーがアプリケーションに到達するために使用するパブリック DNS 名。 Azure DNSまたはサード パーティの DNS プロバイダーを使用できます。
- イングレス サービスのサブネット計画: Application Gateway には専用のサブネットが必要です (運用環境では最小 /24 を推奨)。 バックエンド インスタンスStandard Load Balancer、サブネットを他のリソースと共有できます。
設計上の考慮事項
リフトされたワークロードにインターネットイングレスが必要かどうかを評価します。 多くのオンプレミス アプリケーションは内部専用であり、移行後もそのように維持されます。 イングレスが必要な場合は、アーキテクチャをシンプルに保ちます。
- WAF を使用する Application Gateway は、TLS 終端と OWASP 保護を備えた単一リージョンのレイヤー 7 イングレスを提供します。 このアプローチは、以前はオンプレミスのリバース プロキシの背後にあったリフトされた Web アプリで最も一般的です。
- NSG を使用したパブリック IP は、トラフィックが少ない HTTP 以外のワークロード (パートナーが接続する TCP サービスなど) に対して許容されます。 NSG を既知のソース IP に制限します。
- パブリック IP を VM に直接割り当てないようにします。 インターネットとバックエンドの間にロード バランサーまたは Application Gateway を配置します。
リフトしたアプリケーションが外部ユーザー向けでない場合は、この記事をスキップして アウトバウンド インターネット アクセス に進んでください。
最新化されたワークロードには、アプリケーションの種類に基づいて個別のイングレス パターンがあります。
- 顧客向けの Web アプリケーション (ContosoBiz など) のAzure Front Door。 Front Door では、グローバル アクセラレーション、組み込みの WAF、CDN キャッシュ、リージョン間の自動フェールオーバーが提供されます。 アクティブ-アクティブ構成のデプロイには、重み付きルーティングを使用してください。
- モバイル アプリケーションと API アプリケーション (ContosoCare など) のAzure Traffic Manager。 Traffic Manager では、HTTP 以外のプロトコルに対して、またはクライアントが直接リージョン接続を必要とする場合に、DNS ベースのルーティングが提供されます。
- DNAT ターゲットとしてのハブ ファイアウォール:すべてのイングレス トラフィックは、アプリケーション層に到達する前にハブ Azure Firewallを通過します。 ファイアウォールは宛先 NAT (DNAT) を実行して、スクラブされたトラフィックを適切なスポークにルーティングします。 このパターンにより、一元化されたセキュリティ制御をバイパスするセキュリティが低いインターネット トラフィックがなくなります。
Front Door と各リージョンの Application Gateway を組み合わせて、2 層 WAF 検査を行います。1 つはグローバル エッジで、1 つはリージョン境界にあります。
AWS または Google Cloud から移行された公開アプリケーションの場合は、ワークロードが存在するスポーク VNet に WAF を使用して Application Gateway をデプロイします。
- スポーク VNet の Application Gateway + WAF: 防止モードで WAF が有効になっているリージョンの Application Gateway をデプロイします。 この方法では、HTTP 検査のためにハブを通過するトラフィックを必要とせずに、イングレスをワークロードの近くに保持します。
- VM に直接パブリック IP がない: 移行された VM にパブリック IP を直接割り当てない。 インターネットに接続するすべてのトラフィックは、Application Gateway を経由して入ります。
- 起点をロックダウンする:アプリケーションが以前に AWS Application Load Balancer (ALB) または Google Cloud Load Balancing の背後にあった場合は、そのイングレス パターンをリージョンワークロード用の Application Gateway またはグローバル ワークロード用の Front Door にマップします。
クラウド間ワークロードが内部専用の場合 (プライベート トランジット経由でクラウド間の通信)、この記事をスキップし、Azure Firewallとトラフィックの検査に進みます。
セキュリティに関する考慮事項
インターネットのイングレスは、アプリケーションのフロント ドアです。 信頼されていないインターネット トラフィックがAzure環境に入る境界です。 イングレス パスをセキュリティで保護するには、次のプラクティスに従います。
パブリック IP を使用して VM を直接公開しない
ポート 80 または 443 でアプリケーション トラフィックを提供するために、仮想マシンのネットワーク インターフェイスにパブリック IP アドレスを直接割り当てないでください。 代わりに、インターネットと VM の間にロード バランサーまたは Application Gateway を配置します。 この方法を使用すると、次の操作を行うことができます。
- 異常なインスタンスをローテーションから除外するための正常性チェック
- SSL または TLS 終了の単一ポイント
- WAF ルールとレート制限を適用する場所
- すべての受信トラフィックの一元的なログ記録
Caution
VM 上のパブリック IP は、開いているすべてのポートをインターネットに直接公開します。 VM のネットワーク セキュリティ グループに正しく構成されていない規則がある場合、攻撃者はオペレーティング システムに直接アクセスします。
防止モードで WAF を有効にする
WAF を使用して Application Gateway をデプロイする場合、または WAF でAzure Front Doorする場合は、運用環境のワークロードの WAF を防止モードに設定します。 防止モードでは、悪意のある要求がアプリケーションに到達する前にブロックされます。 検出モードでは、脅威をブロックせずにログに記録するだけです。 最初のテスト中にのみ検出モードを使用して、ルールを調整し、誤検知を識別します。
WAF の既定の規則セット (DRS) は、SQL インジェクション、クロスサイト スクリプティング、リモート コード実行など、OWASP 上位 10 件の攻撃から保護します。 DRS には、既知の悪意のある IP とペイロードを検出するMicrosoft脅威インテリジェンス ルールも含まれています。
DDoS 保護を有効にする
パブリックに公開されているリソースを持つすべての仮想ネットワークで、DDoS 保護が有効になっている必要があります。 Azure DDoS ネットワーク保護は、パブリック IP のアダプティブ チューニング、攻撃テレメトリ、コスト保護を提供します。 DDoS 保護がないと、ボリューム攻撃によってイングレス帯域幅が飽和し、アプリケーションに到達できなくなる可能性があります。
詳細については、 ネットワークの DDoS 保護に関するページを参照してください。
多層防御に NSG を使用する
ロード バランサーまたは Application Gateway を使用する場合でも、バックエンド サブネットでネットワーク セキュリティ グループの規則を構成して、VM に到達できるトラフィック ソースを制限します。 正しく構成された NSG:
- ロード バランサーのサブネットまたはサービス タグからのトラフィックのみを許可します
- インターネットからバックエンド VM への直接受信トラフィックを拒否します
- セキュリティ監視のために拒否されたトラフィックをログに記録する
NSG の計画については、 ネットワーク セキュリティ グループとアプリケーション セキュリティ グループに関するページを参照してください。
TLS 1.2 以降を適用する
TLS 1.2 または TLS 1.3 のみを受け入れるように、すべてのイングレス サービスを構成します。 既知の脆弱性がある TLS 1.0 と 1.1 を無効にします。 Application Gateway と Front Door の両方で、TLS ポリシー設定を使用した TLS バージョンの最小構成がサポートされます。 特定のコンプライアンス要件がない限り、カスタム暗号構成ではなく、Application Gateway の AppGwSslPolicy20220101 などの定義済みのポリシーを使用します。
Front Door のオリジンを制限する
Azure Front Doorを使用する場合は、配信元サーバーが Front Door からのトラフィックのみを受け入れるように制限します。 配信元が任意のソースからのトラフィックを受け入れる場合、無効なアクターは配信元 IP に直接接続することで Front Door の WAF をバイパスでき、WAF への投資全体が効果を失います。
配信元のロックダウンでは、2 つの独立した検証メカニズムが使用されます。 多層防御に両方を適用します。
サービス タグの制限 (ネットワーク 層)
配信元の NSG またはAzure Firewallを構成して、AzureFrontDoor.Backend サービス タグからのみ受信 HTTP/HTTPS トラフィックを許可します。 このサービス タグには、配信元に接続するために Front Door によって使用されるすべての IP 範囲が含まれています。 配信元が存在するサブネットまたは NIC に次の規則を適用します。
-
NSG ルール: Priority 100、Source = Service Tag
AzureFrontDoor.Backend、Destination = your backend subnet、Ports = 80、443、Action = Allow。 - 既定の拒否: インターネットからのポート 80/443 の受信トラフィックを許可する規則が他にないことを確認します。 より広範な許可規則を追加しない限り、NSG の既定の DenyAllInbound 規則はこれを処理します。
サービス タグだけでは不十分です。すべてのAzureの顧客のすべての Front Door インスタンスが同じサービス タグの IP 範囲を共有しているためです。 不適切なアクターは、独自の Front Door プロファイルを作成し、WAF ルールをバイパスして配信元 IP にルーティングできます。
X-Azure-FDID ヘッダー検証 (アプリケーション 層)
Front Door からのすべての要求には、要求を送信した Front Door インスタンスの一意識別子 (GUID) を含む X-Azure-FDID ヘッダーが含まれています。 アプリケーションまたはリバース プロキシでこのヘッダーを検証し、リクエストが悪意のある第三者ではなく、お客様の Front Door プロファイルから送信されたことを確認します。
- Azure ポータルの Front Door プロファイルの 概要 ページで、Front Door ID（「Front Door ID」フィールド）を確認できます。
- アプリケーション コードまたは Web サーバーの構成で、
X-Azure-FDIDが予想される GUID と一致しない要求を拒否します。 - ヘッダー値が見つからないか正しくない要求の場合は、HTTP 403 を返します。
サービス タグ (ネットワークで Front Door 以外のトラフィックをブロック) とヘッダー検証を組み合わせて (アプリケーションで他の顧客の Front Door トラフィックをブロックする)、Front Door インスタンスのみが配信元に到達できるようにします。
Private Link のオリジン（最も厳格な制限）
最高レベルの配信元分離を必要とするワークロードの場合、Front Door Premium ではPrivate Linkオリジンがサポートされます。 配信元にはパブリック IP アドレスは必要ありません。 Front Door は、Microsoft バックボーン経由でプライベート エンドポイント経由で接続します。 この方法では、配信元がパブリック インターネットから完全に到達できないため、サービス タグ規則またはヘッダー検証の必要がなくなります。
関連資料
- 仮想ネットワークとサブネットを設計する: Application Gateway と Load Balancer バックエンドのサブネットのサイズ設定
- ネットワーク セキュリティ グループとアプリケーション セキュリティ グループ: イングレス後にバックエンド アクセスを制限する NSG ルール
- アプリケーションの配信とパフォーマンス: イングレス パスが確立された後のパフォーマンス チューニング
- アウトバウンド インターネット アクセス: イングレスに対するアウトバウンド側であるエグレスを制御する
- 管理アクセスのセキュリティ保護: アプリケーション ユーザーのインターネット イングレスとは異なる管理者アクセス パターン
- Web アプリケーション ファイアウォール: WAF の詳細な構成と規則のチューニング
- ネットワークの DDoS 保護: すべての公開リソースの DDoS 保護計画
詳細情報
- Azure Load Balancerは何ですか?
- Azure Application Gateway とは
- Azure Front Door とは何ですか？
- Azure Traffic Managerとは
- Azure のパブリック IP アドレス
- Application Gateway 上の Azure Web アプリケーション ファイアウォール
- Azure DDoS ネットワーク保護の概要
次のステップ
Tip
あなた自身で探検? 概要ナビゲーターに戻り、機能別に次の記事を見つけます。
リフトアンドシフト体験の次の手順:
アプリケーションの配信とパフォーマンス: 移行されたワークロードにレイヤー 7 の負荷分散とグローバル配信を追加します。
リフトされたワークロードでレイヤー 7 の負荷分散が必要ない場合は、 送信インターネット アクセスに進んでください。
次に、最新化の取り組みを行います。
アプリケーションの配信とパフォーマンス: 顧客向けの PaaS ワークロードのグローバル配信とパフォーマンスを最適化します。
マルチクラウドへの移行における次のステップ:
Web Application Firewall: クラウド資産全体の HTTP 層攻撃から公開アプリケーションを保護します。
ワークロードで HTTP/HTTPS が使用されていない場合は、Azure Firewallとトラフィックの検査に進んでください。