次の方法で共有

Application Gateway の統合

  • [アーティクル]

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

App Service との統合

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

トラフィックがアプリケーション ゲートウェイに流れてから、プライベート エンドポイントを経由して App Service 内のアプリのインスタンスに流れることを示す図。

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

アプリケーション ゲートウェイを再起動するには、Azure CLI を使って停止して起動します。

az network application-gateway stop --resource-group myRG --name myAppGw
az network application-gateway start --resource-group myRG --name myAppGw

詳細については、プライベート エンドポイントを使用した App Service アプリの構成に関するページを参照してください。

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

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

インターネットが Azure 仮想ネットワーク内のアプリケーション ゲートウェイに流れ、そこからファイアウォール アイコンを経由して App Service 内のアプリのインスタンスに送られることが示す図。

この構成には、App Service アプリ インスタンスとアプリケーション ゲートウェイの作成以外に 2 つの部分があります。 1 つ目の部分は、アプリケーション ゲートウェイがデプロイされている仮想ネットワークのサブネットでサービス エンドポイントを有効にすることです。 サービス エンドポイントでは、サブネットから App Service に向かって出て行くすべてのネットワーク トラフィックに、特定のサブネット ID でタグが付けられるようにします。

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

Azure portal では、4 つのステップに従って、App Service と Application Gateway のセットアップを作成して構成します。 既存のリソースがある場合は、最初の手順を省略できます。

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

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

スクリーンショットには、

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

内部 App Service Environment はインターネットには公開されません。 インスタンスとアプリケーション ゲートウェイの間のトラフィックは、仮想ネットワークに既に分離されています。 内部 App Service Environment を構成し、Azure portal を使ってそれをアプリケーション ゲートウェイと統合するには、ハウツー ガイドを参照してください。

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

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

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

外部 App Service Environment には、マルチテナント App Service アプリのようなパブリックに公開されているロード バランサーがあります。 App Service Environment ではサービス エンドポイントは機能しません。 App Service Environment では、アプリケーション ゲートウェイのパブリック IP アドレスを用いた、IP ベースのアクセス制限を使用できます。 Azure portal を使って外部 App Service Environment を作成するには、こちらのクイックスタートに従ってください。

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

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

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

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

az webapp config access-restriction set --resource-group myRG --name myWebApp --use-same-restrictions-for-scm-site

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

az webapp config access-restriction add --resource-group myRG --name myWebApp --scm-site --rule-name KudoAccess --priority 200 --ip-address 208.130.0.0/16

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

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

こちらの記事では、元のホスト名をオーバーライドする場合の一般的な考慮事項が説明されています。 App Service では、この構成に関して注意が必要なシナリオが 2 つあります。

認証

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

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

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

セッション アフィニティ

マルチインスタンスのデプロイでは、セッション アフィニティによって、セッションの有効期間中、クライアントの要求は確実に同じインスタンスにルーティングされます。 セッション アフィニティは、リバース プロキシからの着信ヘッダーに Cookie ドメインを適応させるように構成できます。 セッション アフィニティ プロキシを有効に構成すると、セッション アフィニティは X-Original-Host または X-Forwarded-Host を見つけて、このヘッダーにあるドメインに Cookie ドメインを適応させます。 セッション アフィニティ プロキシを有効にするときの推奨される方法として、トラフィックがリバース プロキシから送信されたものであるように、サイトでアクセス制限を構成する必要があります。

次のコマンドを使って、clientAffinityProxyEnabled を構成することもできます。

az resource update --resource-group myRG --name myWebApp --resource-type "Microsoft.Web/sites" --set properties.clientAffinityProxyEnabled=true

次のステップ

App Service Environment について詳しくは、「App Service Environment のドキュメント」をご覧ください。

Web アプリをさらに安全にするには、Azure Web Application Firewall のドキュメントで Application Gateway での Azure Web Application Firewall に関する情報をご覧ください。

Azure Front Door または Application Gateway を使って、App Service 上のカスタム ドメインでセキュリティ保護された回復性のあるサイトをデプロイするには、こちらのチュートリアルをご覧ください。