Introduction
従来、Application Gateway v2 SKU では (ある程度は v1 でも)、サービスの管理を有効にするためにパブリック IP アドレス指定を必要としてきました。 この要件により、ネットワーク セキュリティ グループやルート テーブルでのきめ細かな制御の使用にいくつかの制限が課されてきました。 具体的には、次の課題が観察されてきました。
- [ゲートウェイ マネージャー] サービス タグへの通信を有効にするには、すべての Application Gateway v2 デプロイに公開されたフロントエンド IP 構成が含まれている必要があります。
- ネットワーク セキュリティ グループの関連付けには、GatewayManager からの受信アクセスとインターネットへの送信アクセスを許可するための規則が必要です。
- インターネット以外の任意の場所でトラフィックを転送する既定のルート (0.0.0.0/0) を導入しているときに、ゲートウェイのメトリック、監視、更新が失敗状態になります。
Application Gateway v2 では、これらの各項目に対処して、データ流出のリスクをさらに排除し、仮想ネットワーク内からの通信のプライバシーを制御できるようになりました。 これらの変更には、次の機能が含まれます。
- プライベート専用フロントエンドIP構成
- パブリック IP アドレス リソースは必要なし
- ネットワーク セキュリティ グループを経由した GatewayManager サービス タグからの受信トラフィックの削除
- インターネットへのエグレス トラフィックを制限するための [すべて拒否] 送信ネットワーク セキュリティ グループ (NSG) 規則を定義する機能
- インターネットへの既定のルート (0.0.0.0/0) をオーバーライドする機能
- 仮想ネットワーク上の定義されたリゾルバーによる DNS 解決 詳細情報 (プライベート リンクのプライベート DNS ゾーンを含む)。
ヒント
Application Gateway の DNS の構成に関する詳細なガイダンスについては、Application Gateway の DNS 解決を参照してください。
これらの各機能は、独立に構成できます。 たとえば、パブリック IP アドレスを使用してインターネットからの受信トラフィックを許可し、データ流出を防止するためにネットワーク セキュリティ グループの構成で [すべて拒否] アウトバウンド規則を定義できます。
機能に登録する
本記事では、Application Gateway v2 SKU向けのプライベートアプリケーションゲートウェイ展開について扱います。 このシステムは、プライベート専用のフロントエンドIP構成と、パブリックとプライベートフロントエンドIPの両方を使用する複合構成の2つの展開モードをサポートしています。 プライベートフロントエンドIP設定、ネットワークセキュリティグループ(NSG)ルール管理、ルートテーブル設定のコントロールは一般的に利用可能で、本番環境でサポートされています。
これらの機能を利用するには、Azureポータル、PowerShell、CLI、またはREST APIを使って体験にオプトインする必要があります。 このオプトイン方式は、必要に応じて従来のアプリケーションゲートウェイ機能に戻す柔軟性も提供します(例えばPrivate Linkを有効にする場合)。
ヒント
ゲートウェイは、プロビジョニング時に使用可能な機能を使用して動作します。 機能から登録を解除した場合、既存のゲートウェイは、作成時に有効にされた機能で引き続き動作します。
機能を登録する
Note
Azure portal エクスペリエンスでは、機能登録プロセスにはプレビューとしてラベルが付 けられます。ただし、このエクスペリエンスは 一般公開されており、運用環境のワークロードで完全にサポートされており、公開されている Application Gateway SLA で説明されています。
Azureポータルを通じてプライベートアプリケーションゲートウェイ展開機能を登録するには、以下の手順をご利用ください:
Azure portal にサインインします。
検索ボックスに「サブスクリプション」と入力し、 [サブスクリプション] を選択します。
サブスクリプションの名前のリンクを選択します。
左側のメニューの [設定] で、 [プレビュー機能] を選択します。
使用可能な機能と現在の登録状態の一覧が表示されます。
[プレビュー機能] から、フィルター ボックスに「EnableApplicationGatewayNetworkIsolation」と入力し、機能を確認して [登録] をクリックします。
Note
機能の登録の状態が [登録中] から [登録済み] に切り替わるには、最大 30 分かかることがあります。
機能の登録を解除する
ポータル経由でプライベートアプリケーションゲートウェイ展開機能をオプトアウトするには、以下の手順をご利用ください:
Azure portal にサインインします。
検索ボックスに「サブスクリプション」と入力し、 [サブスクリプション] を選択します。
サブスクリプションの名前のリンクを選択します。
左側のメニューの [設定] で、 [プレビュー機能] を選択します。
使用可能な機能と現在の登録状態の一覧が表示されます。
[プレビュー機能] から、フィルター ボックスに「EnableApplicationGatewayNetworkIsolation」と入力し、機能を確認して [登録解除] をクリックします。
ネットワーク制御の構成
機能を登録した後は、任意の方法でNSG、ルーティングテーブル、プライベートフロントエンドIP構成をプライベートアプリケーションゲートウェイ展開に設定できます。 例えば、REST API、ARM Template、Bicepデプロイメント、Terraform、PowerShell、CLI、またはAzureポータルを使ってください。
Note
クライアントアプリケーションがプライベートIPアドレスを使ってアプリケーションゲートウェイに接続し、アイドルタイムアウトが4分以上必要で、TCPキーパリブを開始できない場合は、サポート チケットを提出 して必要なキーパライブ動作の有効化を依頼してください。
Application Gateway サブネット
アプリケーションゲートウェイサブネットは、仮想ネットワーク内でアプリケーションゲートウェイリソースを展開するサブネットです。 プライベートなフロントエンドIP構成を使用するプライベートなアプリケーションゲートウェイ展開では、このサブネットは公開されたアプリやサイトに接続したいリソースにプライベートに到達しなければなりません。
Note
2025年5月5日以降、新規および既存のプライベートアプリケーションゲートウェイのデプロイには、Microsoft.Network/applicationGatewaysにサブネットの委任を行う必要があります。
サブネット委任を構成するには、 次の手順 に従ってください。
外部インターネット接続
プライベートなApplication Gateway展開では、プライベート専用のフロントエンドIP構成(リクエストルーティングルールにパブリックIPのフロントエンド構成がない)を使用するApplication Gateway v2のデプロイでは、インターネットに向かうトラフィックをエグレスできません。 この構成は、インターネット経由でパブリックにアクセス可能なバックエンド ターゲットへの通信に影響を与えます。
Application Gateway から、インターネットに接続するバックエンド ターゲットへの送信接続を有効にするには、Virtual Network NAT を利用するか、またはインターネットにアクセスできる仮想アプライアンスにトラフィックを転送できます。
Virtual Network NAT では、構成可能なアイドル タイムアウトだけでなく、との IP アドレスまたはプレフィックスを使用する必要があるかを制御できます。 構成するには、パブリック IP アドレスまたはパブリック プレフィックスを持つ新しい NAT Gateway を作成し、それを Application Gateway が含まれているサブネットに関連付けます。
インターネット エグレスに仮想アプライアンスが必要な場合は、このドキュメントの「ルート テーブルの制御」セクションを参照してください。
パブリック IP の使用が必要な一般的なシナリオ:
- プライベート エンドポイントやサービス エンドポイントを使用せずにキー保管庫と通信する方法
- Application Gateway に直接アップロードされる pfx ファイルに送信通信は必要なし
- インターネットを経由したバックエンド ターゲットへの通信
- インターネットに接続する CRL または OCSP エンドポイントへの通信
ネットワーク セキュリティ グループの制御
このセクションでは、プライベートアプリケーションゲートウェイ展開におけるアプリケーションゲートウェイv2サブネットのネットワークセキュリティグループ(NSG)制御について説明します。 機能を登録すると、Application Gatewayサブネットに関連付けられたネットワークセキュリティグループは、GatewayManagerに対してインバウンドルールを必要としなくなり、インターネットへのアウトバウンドアクセスも必要ありません。 必要な唯一の規則は、正常性プローブが確実にゲートウェイに到着できるようにするための AzureLoadBalancer からの受信を許可するです。
次の構成は、Azure 正常性プローブ以外のすべてのトラフィックを拒否する、最も制限の厳しい一連のインバウンド規則の例です。 定義された規則に加えて、クライアント トラフィックがゲートウェイのリスナーに到着できるようにするための明示的な規則が定義されます。
Note
DenyAll 規則で正常性プローブへのアクセスが誤って制限されている場合は、Application Gateway に、[LoadBalanceRule を許可する] が指定されていることを確認するよう求めるアラートが表示されます。
サンプル シナリオ
この例では、次の規則で Azure portal を使用して NSG を作成する方法について説明します。
- インターネットから発信されたクライアント要求から Application Gateway へのポート 80 と 8080 への受信トラフィックを許可する
- その他のすべての受信トラフィックを拒否する
- 別の仮想ネットワーク内のバックエンド ターゲットへの送信トラフィックを許可する
- インターネットにアクセス可能バックエンド ターゲットへの送信トラフィックを許可する
- その他のすべての送信トラフィックを拒否する
まず、ネットワーク セキュリティ グループを作成します。 このセキュリティ グループには、インバウンド規則とアウトバウンド規則が含まれています。
インバウンド ルール
セキュリティ グループには、3 つの受信の既定の規則が既にプロビジョニングされています。 次の例を参照してください。
次に、次の 4 つの新しい受信セキュリティ規則を作成します。
- インターネットからの受信ポート 80 (TCP) を許可する (任意)
- インターネットからの受信ポート 8080 (TCP) を許可する (任意)
- AzureLoadBalancer からの受信を許可する
- すべての受信を拒否する
これらの規則を作成するには、次の操作を行います。
- [受信セキュリティ規則] を選択します。
- 追加を選択する
- 各規則の次の情報を [受信セキュリティ規則の追加] ペインに入力します。
- 情報を入力したら、[追加] を選択して規則を作成します。
- 各規則の作成には少し時間がかかります。
| ルール# | Source | 発信元サービス タグ | 送信ポート範囲 | Destination | Service | 宛先ポートの範囲 | Protocol | Action | Priority | Name |
|---|---|---|---|---|---|---|---|---|---|---|
| 1 | Any | * | Any | HTTP | 80 | TCP | Allow | 1028 | AllowWeb | |
| 2 | Any | * | Any | Custom | 8080 | TCP | Allow | 1029 | AllowWeb8080 | |
| 3 | サービス タグ | AzureLoadBalancer | * | Any | Custom | * | Any | Allow | 1045 | AllowLB |
| 4 | Any | * | Any | Custom | * | Any | Deny | 4095 | DenyAllInbound |
プロビジョニングが完了したら、[更新] を選択して、すべての規則を確認します。
アウトバウンド規則
優先順位が 65000、65001、65500 の 3 つの既定のアウトバウンド規則が既にプロビジョニングされています。
次の 3 つの新しい送信セキュリティ規則を作成します。
- 10.10.4.0/24 からバックエンド ターゲット 203.0.113.1 への TCP 443 を許可する
- ソース 10.10.4.0/24 から宛先 10.13.0.4 への TCP 80 を許可する
- DenyAll トラフィック規則
これらの規則には、それぞれ 400、401、4096 の優先順位が割り当てられます。
Note
- 10.10.4.0/24 は、Application Gateway サブネットのアドレス空間です。
- 10.13.0.4 は、ピアリングされた VNet 内の仮想マシンです。
- 203.0.113.1 は、バックエンド ターゲット VM です。
これらの規則を作成するには、次の操作を行います。
- [送信セキュリティ規則] を選択します。
- 追加を選択する
- 各規則の次の情報を [送信セキュリティ規則の追加] ペインに入力します。
- 情報を入力したら、[追加] を選択して規則を作成します。
- 各規則の作成には少し時間がかかります。
| ルール# | Source | ソース IP アドレス/CIDR 範囲 | 送信ポート範囲 | Destination | 宛先 IP アドレス/CIDR 範囲 | Service | 宛先ポートの範囲 | Protocol | Action | Priority | Name |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | IP アドレス | 10.10.4.0/24 | * | IP アドレス | 203.0.113.1 | HTTPS | 443 | TCP | Allow | 400 | AllowToBackendTarget |
| 2 | IP アドレス | 10.10.4.0/24 | * | IP アドレス | 10.13.0.4 | HTTP | 80 | TCP | Allow | 401 | AllowToPeeredVnetVM |
| 3 | Any | * | Any | Custom | * | Any | Deny | 4096 | DenyAll |
プロビジョニングが完了したら、[更新] を選択して、すべての規則を確認します。
NSG をサブネットに関連付ける
Application Gateway が含まれているサブネットにネットワーク セキュリティ グループを関連付けます。
Result:
Important
アクセスを許可しようとしているクライアントからの受信トラフィックを誤って拒否する可能性があるため、DenyAll 規則を定義する場合は注意が必要です。 また、バックエンド ターゲットへの送信トラフィックを誤って拒否したために、バックエンドの正常性の確認に失敗して 5XX 応答が生成されることもあります。
ルート テーブルの制御
このセクションでは、プライベートなアプリケーションゲートウェイ展開におけるアプリケーションゲートウェイv2サブネットのルートテーブル(ユーザー定義ルート)制御について説明します。 プライベートなApplication Gatewayデプロイメント機能に登録されていないApplication Gateway展開の場合、 0.0.0.0/0 ルートを含むルートテーブルを仮想アプライアンスの次のホップに関連付けることはできません。 この制限により、アプリケーションゲートウェイの適切な管理が保証されています。
Important
アプリケーションゲートウェイサブネットがExpressRouteやVPN接続からBGP経由で学習するデフォルトのルート(0.0.0.0/0)が強制トンネリングとして機能します。 システムのデフォルトルートを上書きし、ゲートウェイの管理プレーントラフィックをオンプレミスのパス経由で送信します。 Application Gateway v2は管理トラフィックに対して対称ルーティングを必要とするため、このルートは管理面間の接続を断ち切り、プロビジョニングの失敗や InternalServerErrorを引き起こすことがあります。 接続性を回復するには、インターネットのネクストホップを持つユーザー定義0.0.0.0/0ルートをアプリケーションゲートウェイサブネット専用のルートテーブルに追加するか、サブネットへのデフォルトルートの公募を停止してください。 段階的な診断については、「 アプリケーションゲートウェイの導入、スケーリング、削除の失敗のトラブルシューティング」をご覧ください。
この機能を登録した後、仮想アプライアンスを次ホップとする 0.0.0.0/0 ルートを定義することで、トラフィックを仮想アプライアンスに転送できます。
サンプル シナリオ
次の例では、ルート テーブルを作成し、それを Application Gateway サブネットに関連付けて、そのサブネットからの送信インターネット アクセスが確実に仮想アプライアンスから送信されるようにします。 大まかには、次の設計が図 1 に要約されています。
- Application Gateway はスポーク仮想ネットワーク内に存在する
- ハブ ネットワーク内にネットワーク仮想アプライアンス (仮想マシン) が存在する
- 仮想アプライアンスへの既定のルート (0.0.0.0/0) を持つルート テーブルが Application Gateway サブネットに関連付けられている
図 1: 仮想アプライアンスを経由して行うインターネットアクセスの送信
ルート テーブルを作成し、それを Application Gateway サブネットに関連付けるには、次の操作を行います。
- [ルート] を選択し、0.0.0.0/0 に関するネクスト ホップ規則を作成して、宛先を VM の IP アドレスとして構成します。
- [サブネット] を選択し、このルート テーブルを Application Gateway サブネットに関連付けます。
- トラフィックが仮想アプライアンスを通過していることを検証します。
制限事項と既知の問題
次の制限事項が適用されます。
プライベート リンクの構成
プライベート専用のフロントエンドIP構成を使う場合、アプリケーションゲートウェイはプライベートエンドポイント経由でトラフィックをトンネルするための プライベートリンク設定 をサポートしていません。
WAF レート制限
Application Gateway WAF v2 のレート制限カスタム ルールは現在サポートされていません。
AGIC を使用したプライベート IP フロントエンド構成専用
プライベート専用のフロントエンドIP設定を設定するにはAGIC v1.7を使う必要があります。
グローバル VNet ピアリング経由のプライベート エンドポイント接続
Application Gateway に、グローバル VNet ピアリング経由でアクセス可能な VNet 内にあるプライベート エンドポイントへのバックエンド ターゲットまたはキー コンテナーの参照が存在する場合は、トラフィックが破棄され、異常な状態が発生します。
Network Watcher 統合
チェックおよび診断テストを実行すると、接続のトラブルシューティングや NSG 診断でエラーが返されます。
拡張されたネットワーク制御を有効にする前に作成された v2 Application Gateway の共存
サブネットが、プライベートなApplication Gateway デプロイメント機能を有効にする前後に作成したアプリケーションゲートウェイv2のデプロイメントを共有している場合、ネットワークセキュリティグループ(NSG)およびルートテーブル機能は、以前のゲートウェイ展開でのみ利用できます。 ネットワークセキュリティグループおよびルートテーブル機能を有効にするには、その機能を有効にする前に作成したアプリケーションゲートウェイを再プロビジョニングするか、別のサブネットに新しいゲートウェイを作成する必要があります。
- 機能を有効にする前に導入したゲートウェイがサブネットに存在すると、ルートテーブルのエントリを追加する際に
For routes associated to subnet containing Application Gateway V2, please ensure '0.0.0.0/0' uses Next Hop Type as 'Internet'などのエラーが出ることがあります。 - そのサブネットにネットワーク セキュリティ グループ規則を追加すると、
Failed to create security rule 'DenyAnyCustomAnyOutbound'. Error: Network security group \<NSG-name\> blocks outgoing Internet traffic on subnet \<AppGWSubnetId\>, associated with Application Gateway \<AppGWResourceId\>. This isn't permitted for Application Gateways that have fast update enabled or have V2 Sku.が表示されることがあります。
次のステップ
- セキュリティに関するその他のベスト プラクティスについては、「Application Gateway 用の Azure セキュリティ ベースライン」を参照してください。