次の方法で共有

App Service 環境への受信トラフィックを制御する方法

  • [アーティクル]

重要

この記事は、App Service Environment v1 に関するものです。 App Service Environment v1 と v2 は、2024 年 8 月 31 日の時点で廃止されます。 より強力なインフラストラクチャ上で実行できる、使いやすい新しいバージョンの App Service Environment があります。 新しいバージョンの詳細については、App Service Environment の概要に関するページから始めてください。 現在 App Service Environment v1 を使用している場合は、この記事の手順に従って新しいバージョンに移行ください。

2024 年 8 月 31 日の時点で、App Service Environment v1 および v2 は廃止された製品になるため、これらのワークロードに対してはサービス レベル アグリーメント (SLA) とサービス クレジットが適用されなくなります。 App Service Environment v1 および v2 ハードウェアの廃止が開始されており、これが使用中のアプリやデータの可用性とパフォーマンスに影響を及ぼす場合があります。

お客様は、App Service Environment v3 への移行を迅速に完了する必要があります。これを行わないと、アプリとリソースが削除される場合があります。 Microsoft では、インプレース移行機能を使用して、残っている App Service Environment v1 と v2 の自動移行をベストエフォートで試みますが、自動移行後のアプリケーションの可用性については、いかなる主張および保証も行いません。 移行を完了し、ニーズに合わせて最適な App Service プラン SKU を選択するには、手動による構成が必要になる場合があります。 自動移行を実行できない場合、使用中のリソースと関連するアプリ データは削除されます。 これらの極端なシナリオを両方とも回避するために、今すぐ対処することを強くお勧めします。

時間的猶予が必要な場合は、移行を完了するための一回限りの 30 日間の猶予期間を設定することができます。 この猶予期間の詳細と要求方法については、「猶予期間の概要」を確認した後、Azure portal に移動し、各 App Service Environment の [移行] ブレードにアクセスしてください。

App Service Environment v1/v2 の提供終了に関する最新情報については、App Service Environment v1 と v2 の提供終了に関する更新情報の記事を参照してください。

概要

App Service 環境は、Azure Resource Manager 仮想ネットワークまたはクラシック デプロイ モデル仮想ネットワークのどちらにでも作成できます。 App Service 環境の作成時に、新しい仮想ネットワークと新しいサブネットを定義できます。 その代わりに、既存の仮想ネットワークと既存のサブネットに App Service 環境を作成することもできます。 2016 年 6 月の時点で、ASE はパブリック アドレス範囲または RFC1918 アドレス空間 (プライベート アドレス) のいずれかを使用する仮想ネットワークにもデプロイすることができます。 詳細については、テンプレートから ASEv1 を作成する方法に関するページを参照してください。

App Service 環境は常にサブネット内に作成します。 サブネットには、アップストリーム デバイスおよびサービスの背後にある受信トラフィックをロック ダウンするために使用できるネットワーク境界が用意されています。 このセットアップでは、特定のアップストリーム IP アドレスのみに対して、HTTP および HTTPS トラフィックの受け入れを許可します。

サブネット上の受信および送信ネットワーク トラフィックは、ネットワーク セキュリティ グループを使用して制御されます。 受信トラフィックを制御するには、ネットワーク セキュリティ グループにネットワーク セキュリティ ルールを作成します。 次に、App Service 環境を含むサブネットにネットワーク セキュリティ グループを割り当てます。

ネットワーク セキュリティ グループをサブネットに割り当てると、App Service 環境におけるアプリへの受信トラフィックは、ネットワーク セキュリティ グループで定義された許可ルールと拒否ルールに基づいて許可またはブロックされます。

Note

この記事は、Web アプリについて言及していますが、API アプリとモバイル アプリにも適用されます。

App Service 環境で使用される受信ネットワーク ポート

ネットワーク セキュリティ グループで受信ネットワーク トラフィックをロック ダウンする前に、App Service 環境で使用される必須およびオプションのネットワーク ポートのセットを把握しておいてください。 誤っていくつかのポートへのトラフィックを遮断すると、App Service 環境の機能が失われることがあります。

App Service 環境で使用されるポートの一覧を次に示します。 特に断りのない限り、すべてのポートは TCP です。

  • 454: TLS を介した App Service Environment の管理および保守のために Azure インフラストラクチャによって使用される必須ポート。 このポートへのトラフィックはブロックしないでください。 このポートは常に、ASE のパブリック VIP にバインドします。
  • 455: TLS を介した App Service Environment の管理および保守のために Azure インフラストラクチャによって使用される必須ポート。 このポートへのトラフィックはブロックしないでください。 このポートは常に、ASE のパブリック VIP にバインドします。
  • 80: App Service 環境において App Service プランで実行されているアプリへの受信 HTTP トラフィック用の既定のポート。 ILB 対応の ASE では、このポートを ASE の ILB アドレスにバインドします。
  • 443:App Service 環境において App Service プランで実行されているアプリへの受信 TLS トラフィック用の既定のポート。 ILB 対応の ASE では、このポートを ASE の ILB アドレスにバインドします。
  • 21: FTP 用のコントロール チャネル。 FTP が使用されていない場合は、このポートを安全にブロックできます。 ILB 対応の ASE では、このポートを ASE の ILB アドレスにバインドできます。
  • 990: FTPS 用のコントロール チャネル。 FTPS が使用されていない場合は、このポートを安全にブロックできます。 ILB 対応の ASE では、このポートを ASE の ILB アドレスにバインドできます。
  • 10001 ～ 10020:FTP 用のデータ チャネル。 コントロール チャネルと同様、FTP が使用されていない場合は、これらのポートを安全にブロックできます。 ILB 対応の ASE では、このポートを ASE の ILB アドレスにバインドできます。
  • 4016:Visual Studio 2012 でのリモート デバッグに使用されます。 機能が使用されていない場合は、このポートを安全にブロックできます。 ILB 対応の ASE では、このポートを ASE の ILB アドレスにバインドします。
  • 4018:Visual Studio 2013 でのリモート デバッグに使用されます。 機能が使用されていない場合は、このポートを安全にブロックできます。 ILB 対応の ASE では、このポートを ASE の ILB アドレスにバインドします。
  • 4020:Visual Studio 2015 でのリモート デバッグに使用されます。 機能が使用されていない場合は、このポートを安全にブロックできます。 ILB 対応の ASE では、このポートを ASE の ILB アドレスにバインドします。
  • 4022: Visual Studio 2017 でのリモート デバッグに使用されます。 機能が使用されていない場合は、このポートを安全にブロックできます。 ILB 対応の ASE では、このポートを ASE の ILB アドレスにバインドします。
  • 4024: Visual Studio 2019 でのリモート デバッグに使用されます。 機能が使用されていない場合は、このポートを安全にブロックできます。 ILB 対応の ASE では、このポートを ASE の ILB アドレスにバインドします。
  • 4026: Visual Studio 2022 でのリモート デバッグに使用されます。 機能が使用されていない場合は、このポートを安全にブロックできます。 ILB 対応の ASE では、このポートを ASE の ILB アドレスにバインドします。

発信接続と DNS の要件

App Service 環境が正常に機能するためには、さまざまなエンドポイントへの発信アクセスも必要です。 ExpressRoute を使用した環境のネットワーク構成 の記事の「必要なネットワーク接続」というセクションに、App Service Environment で使用されるすべての外部エンドポイントが掲載されています。

App Service Environment では、仮想ネットワーク用に構成された有効な DNS インフラストラクチャが必要です。 App Service 環境の作成後に DNS の構成が変更された場合、開発者は App Service 環境に、新しい DNS 構成の選択を強制できます。 [再起動] アイコンを使用してローリングによる環境の再起動をトリガーすると、環境によって新しい DNS 構成が選択されます。 ([再起動] アイコンは、Azure portal の App Service Environment 管理ページの上部にあります)。

また、App Service Environment を作成する前に、仮想ネットワーク上のカスタム DNS サーバーを設定しておくことをお勧めします。 App Service 環境の作成中に仮想ネットワークの DNS 構成が変更されると、App Service 環境の作成プロセスは失敗します。 同様に、VPN ゲートウェイのもう一方の端に到達不能または使用できないカスタム DNS サーバーがある場合も、App Service 環境の作成プロセスは失敗します。

ネットワーク セキュリティ グループの作成

ネットワーク セキュリティ グループの動作の詳細については、次の情報を参照してください。 次の Azure サービス管理の例では、ネットワーク セキュリティ グループの要点に触れています。 この例では、App Service 環境を含むサブネットにネットワーク セキュリティ グループを構成して適用します。

注: ネットワーク セキュリティ グループは、Azure portal を利用して視覚的に構成することもできますし、Azure PowerShell を利用して構成することもできます。

ネットワーク セキュリティ グループは、最初に、サブスクリプションに関連付けられたスタンドアロン エンティティとして作成されます。 ネットワーク セキュリティ グループは Azure リージョン内に作成されるため、ネットワーク セキュリティ グループは App Service 環境と同じリージョンに作成してください。

以下のコマンドは、ネットワーク セキュリティ グループ作成の例を示しています。

New-AzureNetworkSecurityGroup -Name "testNSGexample" -Location "South Central US" -Label "Example network security group for an app service environment"

ネットワーク セキュリティ グループが作成されると、それに 1 つ以上のネットワーク セキュリティ ルールが追加されます。 一連のルールは時間の経過と共に変わる可能性があるため、ルールの優先順位付けに使用する番号付けスキームで間隔をあけることをお勧めします。 こうすることで、時間の経過に伴って他のルールを簡単に挿入できるようになります。

次の例では、App Service 環境の管理および保守のために Azure インフラストラクチャが必要とする管理ポートへのアクセスを、ルールによって明示的に付与しています。 すべての管理トラフィックは TLS 経由で送信され、クライアント証明書によってセキュリティで保護されます。 ポートが開かれている場合でも、Azure の管理インフラストラクチャ以外のエンティティからはアクセスできません。

Get-AzureNetworkSecurityGroup -Name "testNSGexample" | Set-AzureNetworkSecurityRule -Name "ALLOW AzureMngmt" -Type Inbound -Priority 100 -Action Allow -SourceAddressPrefix 'INTERNET'  -SourcePortRange '*' -DestinationAddressPrefix '*' -DestinationPortRange '454-455' -Protocol TCP

ポート 80 と 443 へのアクセスをロック ダウンして、App Service 環境をアップストリーム デバイスまたはサービスの背後に "隠す" 場合は、アップストリーム IP アドレスを覚えておいてください。 たとえば、Web アプリケーション ファイアウォール (WAF) を使用している場合、WAF には独自の IP アドレス (1 つまたは複数) が割り当てられます。 WAF では、ダウンストリームの App Service 環境にトラフィックをプロキシするときにそれらが使用されます。 この IP アドレスは、ネットワーク セキュリティ ルールの SourceAddressPrefix パラメーターで使用する必要があります。

次の例では、特定のアップストリーム IP アドレスからの受信トラフィックが明示的に許可されています。 アドレス 1.2.3.4 は、アップストリーム WAF の IP アドレスのプレースホルダーとして使用されています。 アップストリーム デバイスまたはサービスで使用されているアドレスと一致するように値を変更します。

Get-AzureNetworkSecurityGroup -Name "testNSGexample" | Set-AzureNetworkSecurityRule -Name "RESTRICT HTTP" -Type Inbound -Priority 200 -Action Allow -SourceAddressPrefix '1.2.3.4/32'  -SourcePortRange '*' -DestinationAddressPrefix '*' -DestinationPortRange '80' -Protocol TCP
Get-AzureNetworkSecurityGroup -Name "testNSGexample" | Set-AzureNetworkSecurityRule -Name "RESTRICT HTTPS" -Type Inbound -Priority 300 -Action Allow -SourceAddressPrefix '1.2.3.4/32'  -SourcePortRange '*' -DestinationAddressPrefix '*' -DestinationPortRange '443' -Protocol TCP

FTP サポートが必要な場合は、次のルールをテンプレートとして使用して、FTP 制御ポートとデータ チャネル ポートへのアクセス権を付与してください。 FTP はステートフルなプロトコルであるため、従来の HTTP/HTTPS ファイアウォールまたはプロキシ デバイス経由で FTP トラフィックをルーティングできない場合があります。 この場合は SourceAddressPrefix を、FTP クライアントが実行されている開発者コンピューターまたはデプロイメント コンピューターの IP アドレス範囲などの別の値に設定する必要があります。

Get-AzureNetworkSecurityGroup -Name "testNSGexample" | Set-AzureNetworkSecurityRule -Name "RESTRICT FTPCtrl" -Type Inbound -Priority 400 -Action Allow -SourceAddressPrefix '1.2.3.4/32'  -SourcePortRange '*' -DestinationAddressPrefix '*' -DestinationPortRange '21' -Protocol TCP
Get-AzureNetworkSecurityGroup -Name "testNSGexample" | Set-AzureNetworkSecurityRule -Name "RESTRICT FTPDataRange" -Type Inbound -Priority 500 -Action Allow -SourceAddressPrefix '1.2.3.4/32'  -SourcePortRange '*' -DestinationAddressPrefix '*' -DestinationPortRange '10001-10020' -Protocol TCP

(注: データ チャネル ポート範囲は、プレビュー期間中に変更される場合があります)。

Visual Studio でのリモート デバッグが使用されている場合、次のルールでは、アクセス権を付与する方法を示しています。 Visual Studio では、バージョンごとにリモート デバッグに使用するポートが異なるため、サポートされているバージョンごとに個別のルールがあります。 FTP アクセスと同様に、リモート デバッグ トラフィックは、従来の WAF またはプロキシ デバイス経由で適切にフローされない場合があります。 代わりに、 SourceAddressPrefix を、Visual Studio が実行されている開発者コンピューターの IP アドレス範囲に設定できます。

Get-AzureNetworkSecurityGroup -Name "testNSGexample" | Set-AzureNetworkSecurityRule -Name "RESTRICT RemoteDebuggingVS2012" -Type Inbound -Priority 600 -Action Allow -SourceAddressPrefix '1.2.3.4/32'  -SourcePortRange '*' -DestinationAddressPrefix '*' -DestinationPortRange '4016' -Protocol TCP
Get-AzureNetworkSecurityGroup -Name "testNSGexample" | Set-AzureNetworkSecurityRule -Name "RESTRICT RemoteDebuggingVS2013" -Type Inbound -Priority 700 -Action Allow -SourceAddressPrefix '1.2.3.4/32'  -SourcePortRange '*' -DestinationAddressPrefix '*' -DestinationPortRange '4018' -Protocol TCP
Get-AzureNetworkSecurityGroup -Name "testNSGexample" | Set-AzureNetworkSecurityRule -Name "RESTRICT RemoteDebuggingVS2015" -Type Inbound -Priority 800 -Action Allow -SourceAddressPrefix '1.2.3.4/32'  -SourcePortRange '*' -DestinationAddressPrefix '*' -DestinationPortRange '4020' -Protocol TCP

サブネットへのネットワーク セキュリティ グループの割り当て

ネットワーク セキュリティ グループには、すべての外部トラフィックへのアクセスを拒否する既定のセキュリティ ルールがあります。 上記のネットワーク セキュリティ ルールとこのルールを組み合わせると、許可アクションに関連付けられた送信元アドレス範囲からのトラフィックのみが、App Service 環境で実行中のアプリにトラフィックを送信できるようになります。

ネットワーク セキュリティ グループは、セキュリティ ルールが設定された後に、App Service 環境を含むサブネットに割り当てられる必要があります。 割り当てコマンドは、App Service 環境が存在する仮想ネットワークの名前と、App Service 環境が作成されたサブネットの名前の 2 つを参照します。

次の例は、ネットワーク セキュリティ グループがサブネットと仮想ネットワークに割り当てられることを示しています。

Get-AzureNetworkSecurityGroup -Name "testNSGexample" | Set-AzureNetworkSecurityGroupToSubnet -VirtualNetworkName 'testVNet' -SubnetName 'Subnet-test'

割り当ては実行時間の長い操作であり、完了するまでに数分かかる場合があります。 ネットワーク セキュリティ グループの割り当てが成功すると、許可ルールに一致する受信トラフィックのみが App Service 環境内のアプリに正常に到達します。

完全を期すため、次の例では、サブネットからネットワーク セキュリティ グループを削除し、関連付けを解除する方法を示します。

Get-AzureNetworkSecurityGroup -Name "testNSGexample" | Remove-AzureNetworkSecurityGroupFromSubnet -VirtualNetworkName 'testVNet' -SubnetName 'Subnet-test'

明示的な IP SSL に関する特別な考慮事項

アプリが、App Service 環境の既定の IP アドレスを使わず、明示的な IP SSL アドレスで構成されている場合 (パブリック VIP がある ASE に "のみ" あてはまります)、HTTP と HTTPS の両方のトラフィックは、ポート 80 と 443 以外のポートを経由してサブネットにフローされます。

各 IP SSL アドレスによって使用されるポートの個々のペアを見つけるには、ポータルにアクセスし、[App Service Environment's details UX](App Service Environment の詳細 UX) ブレードを表示します。 [すべての設定]>[IP アドレス] の順に選択します。 [IP アドレス] ブレードには、App Service 環境に対して明示的に構成されたすべての IP SSL アドレスのテーブルが表示されます。 このブレードには、各 IP SSL アドレスに関連付けられた HTTP および HTTPS トラフィックをルーティングするために使用される特殊なポート ペアも表示されます。 ネットワーク セキュリティ グループのルールを構成する際には、DestinationPortRange パラメーターにこのポート ペアを使用します。

ASE でアプリが IP SSL を使用するように構成されている場合、外部の顧客には特殊なポート ペアのマッピングは表示されず、確認する必要もありません。 アプリへのトラフィックは、構成済みの IP SSL アドレスに通常流れていきます。 特殊なポート ペアへの変換は、ASE を含むサブネットへのトラフィックのルーティングの最終段階において内部で自動的に実行されます。

作業の開始

App Service Environment の使用を開始するには、「App Service Environment の概要」を参照してください。

詳細については、「App Service 環境からバックエンド リソースに安全に接続する」を参照してください。

Note

Azure アカウントにサインアップする前に Azure App Service の使用を開始したい場合は、「Azure App Service アプリケーションの作成」を参照してください。そこでは、App Service で有効期間の短いスターター Web アプリをすぐに作成できます。 このサービスの利用にあたり、クレジット カードは必要ありません。契約も必要ありません。