Azure App Service とのAzure Application Gateway統合とは何ですか?

この記事では、プライベート エンドポイントを使用してトラフィックをセキュリティで保護することで、Azure App Serviceを使用してAzure Application Gatewayを構成する方法の概要について説明します。 サービス エンドポイントの使用と、内部または外部のApp Service Environmentとの統合に関する考慮事項を確認します。 ソース管理マネージャー (SCM) サイトでアクセス制限を設定します。

App Service との統合

プライベート エンドポイントを使用して、Application Gateway と App Service アプリの間のトラフィックをセキュリティで保護できます。 Application Gateway がドメイン ネーム システム (DNS) を使用して App Service アプリのプライベート IP アドレスを解決できることを確認する必要があります。 または、バックエンド プールでプライベート IP アドレスを使い、HTTP の設定でホスト名をオーバーライドすることもできます。

Application Gateway では、DNS 参照の結果がキャッシュされます。 完全修飾ドメイン名 (FQDN) を使用し、DNS 参照に依存してプライベート IP アドレスを取得する場合は、アプリケーション ゲートウェイの再起動が必要になる場合があります。 バックエンド プールを構成した後、DNS の更新またはAzureプライベート DNS ゾーンへのリンクが発生した場合は、再起動が必要です。

アプリケーション ゲートウェイを再起動するには、次のAzure CLIコマンドを使用して、アプリケーション ゲートウェイを停止して起動します。 コマンドの<placeholder>の値をローカルリソースの名前に置き換えます。

az network application-gateway stop --resource-group <your-resource-group> --name <your-application-gateway>
az network application-gateway start --resource-group <your-resource-group> --name <your-application-gateway>

プライベート エンドポイントを使用した App Service アプリの構成の詳細について説明します。

サービス エンドポイントの使用に関する考慮事項

プライベート エンドポイントを使用する代わりに、サービス エンドポイントを使用して Application Gateway からのトラフィックをセキュリティで保護できます。 サービス エンドポイントを使用すると、Azure仮想ネットワーク内の特定のサブネットからのトラフィックのみを許可し、それ以外のすべてをブロックできます。 次のシナリオでは、この機能を使用して、App Service アプリが特定のアプリケーション ゲートウェイからのみトラフィックを受信できるようにします。

この構成には、App Service アプリ インスタンスとアプリケーション ゲートウェイを作成する以外に、2 つの部分があります。

• 最初の部分では、アプリケーション ゲートウェイがデプロイされている仮想ネットワークのサブネット内のサービス エンドポイントを有効にします。 サービス エンドポイントを使用すると、サブネットから App Service に向かうすべてのネットワーク トラフィックに、特定のサブネット ID がタグ付けされます。

• 2 番目のパートでは、特定のサブネット ID でタグ付けされたトラフィックのみが許可されるように、特定の Web アプリにアクセス制限を設定します。 好みに応じて、さまざまなツールを使ってアクセス制限を構成できます。

Azure ポータルでは、4 つの手順に従って、App Service と Application Gateway の統合を作成して構成します。 既存のリソースがある場合は、最初と 2 番目の手順をスキップできます。

1. App Service ドキュメントのクイックスタートのいずれかを使用して、App Service アプリを作成します。 1 つの例として、.NET Core クイック スタートがあります。
2. ポータルのクイックスタートを使用してアプリケーション ゲートウェイを作成しますが、バックエンド ターゲットの追加に関するセクションはスキップしてください。
3. App Service を Application Gateway のバックエンドとして構成しますが、アクセスの制限に関するセクションはスキップしてください。
4. サービス エンドポイントを使用してアクセス制限を作成します。

これで、Application Gateway を経由して App Service にアクセスできるようになります。 App Service に直接アクセスしようとすると、Web アプリがアクセスをブロックしていることを示す 403 HTTP エラーが表示されます。

内部 App Service Environment に関する考慮事項

内部のアプリサービス環境はインターネットに公開されません。 環境とアプリケーション ゲートウェイの間のトラフィックは、仮想ネットワークに既に分離されています。 Azure ポータル<使用して>内部環境を構成しアプリケーション ゲートウェイと統合できます。

Application Gateway サブネットからのトラフィックのみがApp Service Environmentに到達するようにする場合は、環境内のすべての Web アプリに影響するネットワーク セキュリティ グループを構成できます。 ネットワーク セキュリティ グループでは、サブネットの IP 範囲と必要に応じてポート (80/443) を指定できます。

個々の Web アプリへのトラフィックを分離するには、サービス エンドポイントがApp Service Environmentで機能しないため、IP ベースのアクセス制限を使用する必要があります。 その IP アドレスは、アプリケーション ゲートウェイのプライベート IP アドレスである必要があります。

外部App Service Environmentに関する考慮事項

外部 App Service Environment には、複数テナント App Service アプリのような公開ロードバランサーがあります。 サービス エンドポイントは、外部App Service Environmentでは機能しません。 App Service Environmentでは、アプリケーション ゲートウェイのパブリック IP アドレスを使用して、IP ベースのアクセス制限を適用できます。 Azure ポータルで外部App Service Environmentを作成するには、quickstart を使用します。

外部App Service Environmentでホストされているアプリにプライベート エンドポイントを追加することもできます。

Kudu/SCM サイトに関する考慮事項

SCM サイト (Kudu とも呼ばれます) は、すべての Web アプリに存在する管理サイトです。 SCM サイトにリバース プロキシを使用することはできません。 また、ほとんどの場合は、個別の IP アドレスまたは特定のサブネットにロックダウンすることもお勧めします。

メイン サイトと同じアクセス制限を使用する場合は、次の Azure CLI コマンドを使用して設定を継承できます。

az webapp config access-restriction set --resource-group <your-resource-group> --name <your-web-app> --use-same-restrictions-for-scm-site

SCM サイトの個々のアクセス制限を追加する場合は、コマンドで --scm-site フラグを使用できます。

az webapp config access-restriction add --resource-group <your-resource-group> --name <your-web-app> --scm-site --rule-name KudoAccess --priority 200 --ip-address 208.130.0.0/16

既定のドメインの使用に関する考慮事項

App Service の既定のドメイン (通常は azurewebsites.net) でホスト名をオーバーライドするように Application Gateway を構成できます。 この方法は、App Service でカスタム ドメインと証明書を構成する必要がないため、統合を実現する最も簡単な方法です。

ホスト名の保持プロセスでは、元のホスト名をオーバーライドするための一般的な考慮事項について説明します。 App Service では、認証とセッション アフィニティに関する次の考慮事項に注意してください。

認証 (簡単な認証)

App Service で 認証機能 ( Easy Auth とも呼ばれます) を使用すると、通常、アプリはサインイン ページにリダイレクトされます。 App Service では、要求の元のホスト名がわからないため、リダイレクトは既定のドメイン名で行われ、通常はエラーになります。

既定のリダイレクトを回避するには、転送されたヘッダーを検査して、リダイレクト ドメインを元のドメインに適応させるように、認証を構成することができます。 Application Gateway では、 X-Original-Hostという名前のヘッダーが使用されます。 ファイル ベースの構成を使用して認証を指定すると、元のホスト名に適応するように App Service を構成できます。

この構成を構成ファイルに追加します。

{
    ...
    "httpSettings": {
        "forwardProxy": {
            "convention": "Custom",
            "customHostHeaderName": "X-Original-Host"
        }
    }
    ...
}

セッション アフィニティ（セッション固着）

複数インスタンスのデプロイで セッション アフィニティ設定 を指定する場合は、セッションの有効期間中、クライアント要求が同じインスタンスにルーティングされるようにすることができます。 セッション アフィニティを構成して、リバース プロキシからの受信ヘッダーに Cookie ドメインを適応させることができます。

セッション アフィニティ プロキシ設定を にtrueすると、セッション アフィニティは X-Original-Host または X-Forwarded-Host ヘッダーを検索します。 これは、ヘッダーで見つかったドメインに Cookie ドメインを適応させます。 セッション アフィニティ プロキシを有効にする場合に推奨される方法として、トラフィックがリバース プロキシから送信されるように、サイトでアクセス制限を構成します。

次の Azure CLI コマンドを使用して、clientAffinityProxyEnabled 設定を構成することもできます。

az resource update --resource-group <your-resource-group> --name <your-web-app> --resource-type "Microsoft.Web/sites" --set properties.clientAffinityProxyEnabled=true

関連するコンテンツ

• App Service Environment ドキュメントを確認する
• Azure Web Application Firewall
• Azure Front Door または Application Gateway にカスタム ドメインを持つセキュリティで保護されたサイトをデプロイする (チュートリアル)