次の方法で共有

Application Gateway の統合

  • [アーティクル]

Azure App Service の 3 つのバリエーションでは、Azure Application Gateway との統合で必要な構成が少しずつ異なります。 バリエーションは、通常の App Service (マルチテナントとも呼ばれます)、内部ロード バランサー (ILB) App Service Environment、外部 App Service Environment です。

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

App Service (マルチテナント) との統合

App Service (マルチテナント) には、インターネットに接続するパブリック エンドポイントがあります。 サービス エンドポイントを使うことで、Azure 仮想ネットワーク内の特定のサブネットからのトラフィックのみを許可し、他のすべてのトラフィックをブロックすることができます。 次のシナリオでは、この機能を使って、App Service インスタンスが特定のアプリケーション ゲートウェイからのトラフィックのみを受信できるようにします。

Diagram that shows the internet flowing to an application gateway in an Azure virtual network and then flowing through a firewall icon to instances of apps in App Service.

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

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

Azure portal を使用してサービスを設定する

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 エラーを受け取るはずです。

Screenshot shows the text of Error 403 - Forbidden.

Azure Resource Manager テンプレートを使用してサービスをセットアップする

Azure Resource Manager デプロイ テンプレートを使うと、完全なシナリオが作成されます。 このシナリオは、サービス エンドポイントでロックダウンされる App Service インスタンスと、Application Gateway からのトラフィックのみを受信するためのアクセス制限で構成されます。 このテンプレートには、簡単にするために、多数の適切な既定値と、リソース名に追加される固有の接尾辞が含まれています。 これらをオーバーライドするには、リポジトリをクローンするか、テンプレートをダウンロードして編集する必要があります。

テンプレートを適用するには、テンプレートの説明にある [Deploy to Azure] (Azure へのデプロイ) ボタンを使用できます。 または、適切な PowerShell や Azure CLI のコードを使うこともできます。

Azure CLI を使用してサービスを設定する

Azure CLI のサンプルでは、サービス エンドポイントでロックダウンされる App Service インスタンスと、Application Gateway からのトラフィックのみを受信するためのアクセス制限が作成されます。 既存の App Service インスタンスへのトラフィックを既存のアプリケーション ゲートウェイから分離することだけが必要な場合は、次のコマンドを使います。

az webapp config access-restriction add --resource-group myRG --name myWebApp --rule-name AppGwSubnet --priority 200 --subnet mySubNetName --vnet-name myVnetName

既定の構成では、このコマンドによって、サブネットのサービス エンドポイントの構成と App Service のアクセス制限が確実に設定されます。

プライベート エンドポイントの使用に関する考慮事項

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

Diagram that shows traffic flowing to an application gateway in an Azure virtual network and then flowing through a private endpoint to instances of apps in 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

ILB App Service Environment に関する考慮事項

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

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

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

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

外部 App Service Environment には、マルチテナント App Service のようなパブリックに公開されているロード バランサーがあります。 App Service Environment ではサービス エンドポイントは機能しません。 そのため、アプリケーション ゲートウェイのパブリック IP アドレスを使って、IP ベースのアクセス制限を使う必要があります。 Azure portal を使って外部 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"
        }
    }
    ...
}

ARR アフィニティ

マルチインスタンス デプロイでは、ARR アフィニティによって、セッションの有効期間中、クライアント要求は確実に同じインスタンスにルーティングされます。 ARR アフィニティは、ホスト名のオーバーライドでは機能しません。 セッション アフィニティが機能するには、App Service と Application Gateway で同じカスタム ドメインと証明書を構成し、ホスト名をオーバーライドしないようにする必要があります。

次のステップ

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

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

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