App Service のネットワーク機能

複数の方法で Azure App Service にアプリケーションをデプロイできます。 既定では、App Service でホストされているアプリは、インターネット経由で直接アクセスでき、インターネットでホストされているエンドポイントにのみ到達できます。 しかし、多くのアプリケーションにおいては、送受信のネットワーク トラフィックを制御する必要があります。 App Service には、それらのニーズを満たすのに役立つ機能がいくつかあります。 ここで課題となるのは、特定の問題を解決するために使用する必要がある機能を把握することです。 この記事では、ユース ケースの例を基にして、使用する機能を決定する方法を説明します。

Azure App Service のデプロイには、主に 2 つの種類があります。

  • マルチテナント パブリック サービスを使用すると、Free、Shared、Basic、Standard、Premium、PremiumV2、PremiumV3 の各価格の SKU で、App Service プランをホストできます。
  • シングルテナントの App Service Environment (ASE) を使用すると、Isolated SKU の App Service プランを、Azure 仮想ネットワークで直接ホストできます。

使用する機能は、マルチテナント サービスと ASE のどちらを使用しているかによって異なります。

注意

ネットワーク機能は、Azure Arc にデプロイされているアプリでは使用できません。

マルチテナント App Service のネットワーク機能

Azure App Service は分散システムです。 受信した HTTP または HTTPS 要求を処理するロールは、"フロントエンド" と呼ばれます。 お客様のワークロードをホストするロールは、worker と呼ばれます。 App Service のデプロイ内のロールはすべて、マルチテナント ネットワークに存在します。 同じ App Service スケール ユニット内に多くのお客様が存在しているので、App Service ネットワークをお使いのネットワークに直接接続することはできません。

ネットワークを接続する代わりに、アプリケーション通信のさまざまな側面を処理する機能が必要になります。 お客様のアプリ "への" 要求を処理する機能を、お客様のアプリ "からの" 呼び出しを行うときの問題を解決するために使用することはできません。 同様に、お客様のアプリからの呼び出しに関する問題を解決する機能を、お客様のアプリに対する問題を解決するために使用することはできません。

受信時の機能 送信時の機能
アプリに割り当てられたアドレス ハイブリッド接続
アクセスの制限 ゲートウェイが必要な VNet 統合
サービス エンドポイント VNet 統合
プライベート エンドポイント

明記されている例外を除けば、これらの機能のすべてを一緒に使用できます。 機能を組み合わせることで、問題を解決できます。

ユース ケースと機能

どのようなユース ケースでも、問題を解決する方法がいくつか存在する場合があります。 最適な機能の選択は、ユース ケース自体の範囲を超えることがあります。 以下の受信ユース ケースでは、App Service のネットワーク機能を使用して、アプリで受信するトラフィックの制御についての問題を解決する方法の案を示します。

受信のユース ケース 機能
アプリの IP ベース SSL のニーズをサポートする アプリに割り当てられたアドレス
アプリに対する非共有の専用受信アドレスをサポートする アプリに割り当てられたアドレス
アプリへのアクセスを明確に定義された一連のアドレスからのみに制限する アクセスの制限
仮想ネットワーク内のリソースからアプリへのアクセスを制限する サービス エンドポイント
ILB ASE
プライベート エンドポイント
アプリを仮想ネットワーク内のプライベート IP で公開する ILB ASE
プライベート エンドポイント
Application Gateway インスタンス上の受信トラフィック用プライベート IP とサービス エンドポイントの併用
Web アプリケーション ファイアウォール (WAF) を使用してアプリを保護する Application Gateway と ILB ASE
Application Gateway とプライベート エンドポイントの併用
Application Gateway とサービス エンドポイントの併用
Azure Front Door とアクセス制限
複数のリージョンのアプリにトラフィックを負荷分散する Azure Front Door とアクセス制限
同一リージョン内でトラフィックの負荷を分散させる Application Gateway とサービス エンドポイントの併用

以下の送信ユース ケースでは、App Service のネットワーク機能を使用して、お使いのアプリの送信アクセスに関するニーズを解決する方法の案を示します。

送信のユース ケース 機能
同じリージョン内にある Azure 仮想ネットワークのリソースにアクセスする VNet 統合
ASE
異なるリージョン内にある Azure 仮想ネットワークのリソースにアクセスする ゲートウェイが必要な VNet 統合
ASE と仮想ネットワーク ピアリング
サービス エンドポイントによって保護されているリソースにアクセスする VNet 統合
ASE
Azure に接続されていないプライベート ネットワーク内のリソースにアクセスする ハイブリッド接続
Azure ExpressRoute 回線を越えてリソースにアクセスする VNet 統合
ASE
Web アプリからの送信トラフィックをセキュリティで保護する VNet 統合とネットワーク セキュリティ グループ
ASE
Web アプリからの送信トラフィックをルーティングする VNet 統合とルーティング テーブル
ASE

既定のネットワークの動作

Azure App Service スケール ユニットを使用すると、デプロイごとに多数のお客様がサポートされます。 Free および Shared SKU のプランを使用すると、お客様のワークロードはマルチテナント worker 上でホストされます。 Basic 以上のプランを使用すると、ただ 1 つの App Service プランに専用のお客様のワークロードがホストされます。 App Service プランが Standard の場合、そのプラン内のすべてのアプリが同じ worker 上で実行されます。 worker をスケール アウトした場合、その App Service プラン内にあるすべてのアプリが、App Service プラン内の各インスタンスの新しい worker にレプリケートされます。

送信アドレス

worker VM は、主に App Service プラン別に大きく分けられます。 Free、Shared、Basic、Standard、Premium の各プランで使用される worker VM の種類はすべて同じです。 PremiumV2 プランの場合は、使用される VM の種類が異なります。 PremiumV3 の場合は、さらに別の種類の VM が使用されます。 VM ファミリを変更すると、異なる送信アドレスのセットを受け取ります。 Standard から PremiumV2 にスケーリングすると、送信アドレスが変更されます。 PremiumV2 から PremiumV3 にスケーリングすると、送信アドレスが変更されます。 一部の古いスケール ユニットの場合、Standard から PremiumV2 にスケーリングすると、受信アドレスと送信アドレスの両方が変更されます。

送信呼び出しに使用されるアドレスがいくつかあります。 送信呼び出しを行うためにアプリによって使用される送信アドレスは、アプリのプロパティで一覧表示されます。 これらのアドレスは、その App Service デプロイ内の同じ worker VM ファミリで実行されているすべてのアプリによって共有されます。 アプリがスケール ユニットで使用する可能性のあるすべてのアドレスを表示するには、その一覧が示される possibleOutboundAddresses というプロパティがあります。

アプリのプロパティを示すスクリーンショット。

App Service には、サービスの管理に使用されるエンドポイントがいくつも存在します。 それらのアドレスは別のドキュメントで公開されており、AppServiceManagement IP サービス タグにも含まれます。 AppServiceManagement タグは、そのようなトラフィックを許可する必要がある App Service Environment でのみ使用されます。 App Service の受信アドレスは、AppService IP サービス タグで追跡されます。 App Service によって使用される送信アドレスが含まれる IP サービス タグはありません。

App Service の受信トラフィックと送信トラフィックを示す図。

アプリに割り当てられたアドレス

アプリに割り当てられたアドレス機能は、IP ベースの SSL 機能の副産物です。 それにアクセスするには、アプリで SSL を設定します。 IP ベースの SSL の呼び出しに、この機能を使用することができます。 また、それを使用して、お客様のアプリに専用のアドレスを指定することもできます。

アプリに割り当てられたアドレスを示す図。

アプリに割り当てられたアドレスを使用する場合でも、トラフィックは引き続き、App Service スケール ユニットへのすべての受信トラフィックを処理する同じフロントエンド ロールを通過します。 ただし、アプリに割り当てられたアドレスは、そのアプリによってのみ使用されます。 この機能のユース ケースを示します。

  • アプリに対する IP ベースの SSL のニーズをサポートする。
  • 共有されない専用アドレスをアプリに設定する。

アプリにアドレスを設定する方法については、「Azure App Service で TLS/SSL 証明書を追加する」を参照してください。

アクセスの制限

アクセスの制限を使用すると、"受信" 要求をフィルター処理できます。 このフィルター処理は、アプリが実行される worker ロールよりも上流にある、フロントエンド ロールで行われます。 フロントエンド ロールは worker より上流に存在するので、アクセスの制限はアプリに対するネットワーク レベルでの保護と考えることができます。

この機能を使用すると、優先順位に従って評価される許可規則と拒否規則のリストを作成できます。 これは、Azure ネットワークのネットワーク セキュリティ グループ (NSG) 機能と似ています。 この機能は、ASE またはマルチテナント サービスで使用できます。 ILB ASE またはプライベート エンドポイントで使用すると、プライベート アドレス ブロックからのアクセスを制限できます。

注意

アプリごとに、最大 512 個のアクセス制限規則を構成できます。

アクセス制限を示す図。

IP ベースのアクセス制限規則

IP ベースのアクセス制限機能は、アプリに到達するために使用できる IP アドレスを制限する必要がある場合に役に立ちます。 IPv4 と IPv6 の両方がサポートされます。 この機能のユース ケースをいくつか示します。

  • 明確に定義された一連のアドレスからアプリへのアクセスを制限する。
  • 既知のエグレス IP アドレスを持つ外部の負荷分散サービスまたは他のネットワーク アプライアンス経由のトラフィックへのアクセスを制限します。

この機能を有効化する方法については、アクセス制限の構成に関する記事を参照してください。

注意

IP ベースのアクセス制限規則では、アプリが App Service Environment にある場合のみ、仮想ネットワーク アドレスの範囲が処理されます。 アプリがマルチテナント サービス内にある場合は、サービス エンドポイントを使用して、仮想ネットワーク内のサブネットを選択するためのトラフィックを制限する必要があります。

サービス エンドポインに基づくアクセス制限規則

サービス エンドポイントを使用すると、アプリへの "受信" アクセスをロック ダウンすることができるため、送信元アドレスは、選択したサブネットのセットからのものである必要があります。 この機能は、IP アクセス制限と併用できます。 サービス エンドポイントは、リモート デバッグと互換性がありません。 アプリでリモート デバッグを使用する場合は、サービス エンドポイントが有効になっているサブネット内にクライアントを配置することはできません。 サービス エンドポイントを設定するプロセスは、IP アクセス制限を設定するプロセスに似ています。 パブリック アドレスおよび仮想ネットワーク内のサブネットが含まれる許可と拒否のアクセス規則リストを作成できます。

この機能のユース ケースをいくつか示します。

  • アプリでアプリケーション ゲートウェイを設定し、アプリに対する受信トラフィックをロックダウンする。
  • アプリへのアクセスを、仮想ネットワーク内のリソースに制限する。 これらのリソースには、VM や ASE のほか、VNet 統合を使用する他のアプリも含めることができます。

Application Gateway でのサービス エンドポイントの使用方法を示す図。

アプリでサービス エンドポイントを構成する方法の詳細については、「Azure App Service のアクセス制限」を参照してください。

サービス タグに基づくアクセス制限規則

Azure サービス タグは、Azure サービスの明確に定義された一連の IP アドレスです。 サービス タグは、さまざまな Azure サービスで使用される IP 範囲をグループ化します。また、さらに特定のリージョンにスコープ設定されることがよくあります。 これにより、特定の Azure サービスからの "受信" トラフィックをフィルター処理できます。

タグの完全な一覧と詳細については、上記のサービス タグのリンクを参照してください。 この機能を有効化する方法については、アクセス制限の構成に関する記事を参照してください。

アクセス制限規則での HTTP ヘッダー フィルタリング

アクセス制限規則ごとに、追加の HTTP ヘッダー フィルタリングを追加できます。 これにより、受信要求をさらに検査し、特定の HTTP ヘッダー値に基づいてフィルター処理できます。 各ヘッダーには、1 つの規則につき最大 8 つの値を含めることができます。 現在サポートされている HTTP ヘッダーの一覧を次に示します。

  • X-Forwarded-For
  • X-Forwarded-Host
  • X-Azure-FDID
  • X-FD-HealthProbe

HTTP ヘッダー フィルタリングのユース ケースをいくつか示します。

  • ホスト名を転送するプロキシ サーバーからのトラフィックへのアクセスを制限する
  • サービス タグ規則と X-Azure-FDID ヘッダー制限を使用して、特定の Azure Front Door インスタンスへのアクセスを制限する

プライベート エンドポイント

プライベート エンドポイントは、Azure Private Link を使用して Web アプリにプライベートかつ安全に接続するネットワーク インターフェイスです。 プライベート エンドポイントにより、お客様の仮想ネットワークからのプライベート IP アドレスを使用して、Web アプリが実質的に仮想ネットワークに取り込まれます。 この機能は、Web アプリへの "受信" フロー専用です。 詳細については、「Azure Web アプリでプライベート エンドポイントを使用する」を参照してください。

この機能のユース ケースをいくつか示します。

  • 仮想ネットワーク内のリソースからアプリへのアクセスを制限する。
  • アプリを仮想ネットワーク内のプライベート IP で公開する。
  • WAF によりアプリを保護する。

プライベート エンドポイントを使用すると、プライベート エンドポイントを超えて到達できるのは、それが構成されているアプリのみであるため、データ流出を防ぐことができます。

ハイブリッド接続

App Service のハイブリッド接続を使用すると、指定した TCP エンドポイントに対してアプリから 送信 呼び出しを行うことができます。 エンドポイントは、オンプレミス、仮想ネットワーク内、またはポート 443 で Azure への送信トラフィックが許可されている任意の場所に設定できます。 この機能を使用するには、ハイブリッド接続マネージャーと呼ばれるリレー エージェントを、Windows Server 2012 以降のホストにインストールする必要があります。 ハイブリッド接続マネージャーは、ポート 443 で Azure Relay に到達できる必要があります。 ハイブリッド接続マネージャーは、ポータルにある App Service ハイブリッド接続の UI からダウンロードできます。

ハイブリッド接続ネットワークのフローを示す図。

App Service のハイブリッド接続は、Azure Relay のハイブリッド接続機能を基に構築されています。 App Service では、アプリからの TCP ホストとポートへの送信呼び出しのみをサポートするようにこの機能を特殊化して使用しています。 このホストとポートは、ハイブリッド接続マネージャーがインストールされているホスト上でのみ解決する必要があります。

App Service 内にあるアプリで、ハイブリッド接続で定義されているホストとポートに対して DNS ルックアップが行われると、トラフィックは自動的にリダイレクトされ、ハイブリッド接続を経由してハイブリッド接続マネージャーから送信されます。 詳細については、App Service からのハイブリッド接続に関する記事を参照してください。

この機能の一般的な使用例は次のとおりです。

  • VPN または ExpressRoute で Azure に接続されていないプライベート ネットワーク内のリソースにアクセスする。
  • サポート データベースを移動する必要なしに、App Service へのオンプレミス アプリの移行をサポートする。
  • ハイブリッド接続ごとに単一のホストとポートへのアクセスのセキュリティを強化する。 ほとんどのネットワーク機能により、ネットワークへのアクセスが開かれます。 ハイブリッド接続を使用すると、到達できるのは 1 つのホストとポートのみになります。
  • 他の送信接続方法で対応されないシナリオに対応する。
  • アプリでオンプレミスのリソースを容易に使用できる方法で、App Service 内の開発を行う。

この機能を使用すると、受信ファイアウォールに穴を開けることなくオンプレミス リソースにアクセスできるため、開発者に人気があります。 App Service の他の送信ネットワーク機能は、Azure Virtual Networking に関連しています。 ハイブリッド接続は、仮想ネットワークを経由することに依存しません。 より広範なネットワーク ニーズのために使用できます。

App Service ハイブリッド接続では、その上で何が行われているかは認識されないことにご注意ください。 つまり、それを使用して、メインフレーム上のデータベース、Web サービス、または任意の TCP ソケットにアクセスできます。 本質的には、この機能は TCP パケットをトンネリングするものです。

ハイブリッド接続は、開発でよく利用されるだけでなく、運用アプリケーションでも使用されています。 Web サービスやデータベースへのアクセスには適していますが、多くの接続の作成が含まれる状況には向いていません。

ゲートウェイが必要な VNet 統合

App Service のゲートウェイが必要な VNet 統合機能を使用すると、アプリから Azure 仮想ネットワークへの "送信" 要求を行うことができます。 この機能を使用すると、アプリが実行されているホストが、ポイント対サイト VPN を使用して、仮想ネットワーク上の Virtual Network ゲートウェイに接続されます。 この機能を構成すると、アプリには、各インスタンスに割り当てられているポイント対サイト アドレスのいずれかが付与されます。 この機能を使用して、任意のリージョンの、クラシックまたは Azure Resource Manager 仮想ネットワーク内のリソースにアクセスできます。

ゲートウェイが必要な VNet 統合を示す図。

この機能により、他の仮想ネットワーク内のリソースにアクセスするときの問題が解決されます。 また、仮想ネットワーク経由で、他の仮想ネットワークまたはオンプレミスに接続するために使用することもできます。 ExpressRoute で接続されている仮想ネットワークには対応していませんが、サイト間 VPN で接続されているネットワークでは動作します。 App Service Environment (ASE) は既に仮想ネットワーク内に存在しているので、通常、この機能を ASE 内のアプリから使用するのは適切ではありません。 この機能のユース ケースを示します。

  • Azure 仮想ネットワーク内のプライベート IP 上にあるリソースにアクセスする。
  • サイト間 VPN がある場合に、オンプレミスのリソースにアクセスする。
  • ピアリングされた仮想ネットワーク内のリソースにアクセスする。

この機能が有効な場合、接続先の仮想ネットワークで構成されている DNS サーバーが、アプリで使用されます。 この機能の詳細については、App Service VNet 統合に関する記事を参照してください。

VNet 統合

ゲートウェイが必要な VNet 統合は便利ですが、ExpressRoute 経由でのリソースへのアクセスに関する問題は解決されません。 ExpressRoute 接続経由で到達しなければならないことに加え、サービス エンドポイントによって保護されたサービスに対して、アプリで呼び出しを行うことができる必要もあります。 別の VNet 統合機能で、これらのニーズを満たすことができます。

新しい VNet 統合機能を使用すると、アプリのバックエンドを、アプリと同じリージョン内にある Resource Manager 仮想ネットワークのサブネットに配置できます。 この機能は、既に仮想ネットワーク内に存在している App Service Environment からは利用できません。 この機能のユース ケースを示します。

  • 同じリージョンにある Resource Manager 仮想ネットワーク内のリソースにアクセスする。
  • サービス エンドポイントで保護されているリソースにアクセスする。
  • ExpressRoute または VPN 接続を経由してアクセスできるリソースにアクセスする。
  • すべての送信トラフィックをセキュリティで保護する。
  • すべての送信トラフィックにトンネルを強制する。

VNet 統合を示す図。

詳細については、App Service VNet 統合に関する記事を参照してください。

App Service Environment

App Service Environment (ASE) は、仮想ネットワーク内で実行される Azure App Service のシングルテナント デプロイです。 この機能には、次のようなケースがあります。

  • 仮想ネットワーク内のリソースにアクセスする。
  • ExpressRoute を経由してリソースにアクセスする。
  • 仮想ネットワーク内のプライベート アドレスを使用してアプリを公開する。
  • サービス エンドポイントを介してリソースにアクセスする。

ASE を使用する場合、ASE は仮想ネットワーク内に既に存在するので、VNet 統合やサービス エンドポイントなどの機能を使用する必要はありません。 サービス エンドポイント経由で SQL や Azure Storage などのリソースにアクセスする必要がある場合は、ASE サブネット上でサービス エンドポイントを有効にします。 仮想ネットワーク内のリソースにアクセスする場合は、追加の構成を行う必要はありません。 ExpressRoute 経由でリソースにアクセスする場合、ユーザーは既に仮想ネットワーク内にいるため、ASE やその中のアプリについて構成を行う必要はありません。

ILB ASE 内にあるアプリはプライベート IP アドレスで公開できるので、WAF デバイスを容易に追加して、他のアプリの安全を保ったまま目的のアプリのみをインターネットに公開することができます。 この機能は、多層アプリケーションの開発を容易にするのに役立ちます。

現在、マルチテナント サービスからは使用できないものがいくつかありますが、ASE からは可能です。 次に例をいくつか示します。

  • プライベート IP アドレスでアプリを公開する。
  • アプリに含まれないネットワーク制御機能を使用して、すべての送信トラフィックをセキュリティで保護する。
  • シングルテナント サービスでアプリをホストする。
  • マルチテナント サービスで可能な数より多くのインスタンスにスケールアップする。
  • プライベート CA でセキュリティ保護されているエンドポイントを使用するアプリ用にプライベート CA クライアントの証明書を読み込む。
  • アプリ レベルで無効化できないようにして、システムでホストされているすべてのアプリに TLS 1.1 を適用する。
  • ASE 内にあるすべてのアプリに、お客様と共有されない専用の送信アドレスを提供する。

仮想ネットワーク内の ASE を示す図。

ASE は分離された専用のアプリのホスティングに最適ですが、管理に関するいくつかの課題が伴います。 運用環境で ASE を使用する前に、以下のことを考慮してください:

  • ASE は仮想ネットワーク内で実行されますが、仮想ネットワークの外部に依存関係があります。 こうした依存関係は許容しなければなりません。 詳細については、「App Service Environment のネットワークの考慮事項」を参照してください。
  • ASE の場合、マルチテナント サービスのようにすばやくスケーリングされることはありません。 事後対応的にスケーリングを行うのではなく、スケーリングのニーズを予測する必要があります。
  • ASE を使用すると初期費用が高くなります。 ASE を最大限に活用するには、少量の作業に使用するのではなく、多くのワークロードを 1 つの ASE に配置するよう計画する必要があります。
  • ASE 内のアプリによるアクセスを、ASE 内の一部のアプリに選択的に制限して他のアプリを除外することはできません。
  • ASE はサブネット内にあるので、その ASE で送受信されるすべてのトラフィックにあらゆるネットワーク規則が適用されます。 1 つのアプリのみに受信トラフィック規則を割り当てる必要がある場合は、アクセス制限を使用します。

各種機能の組み合わせ

マルチテナント サービスについて説明した機能を組み合わせて使用し、さらに複雑なユース ケースを解決できます。 ここでは、最も一般的なユース ケースを 2 つ紹介しますが、これらはあくまでも例に過ぎません。 さまざまな機能の働きを理解することで、システム アーキテクチャのニーズをほぼすべて満たすことができます。

アプリを仮想ネットワークに配置する

アプリを仮想ネットワークに配置する方法に疑問があるかもしれません。 アプリを仮想ネットワークに配置する場合、アプリの受信エンドポイントと送信エンドポイントは仮想ネットワーク内にあります。 この問題を解決するには、ASE が最善の方法です。 ただし、機能を組み合わせることによって、マルチテナント サービス内のほとんどのニーズを満たすことができます。 たとえば、以下のようにすると、プライベートな受信アドレスと送信アドレスを使用して、イントラネット専用のアプリケーションをホストできます。

  • プライベートの受信アドレスと送信アドレスを指定して、アプリケーション ゲートウェイを作成する。
  • サービス エンドポイントを使用して、アプリへの受信トラフィックをセキュリティで保護する。
  • 新しい VNet 統合機能を使用して、アプリのバックエンドが仮想ネットワーク内に存在するようにする。

このデプロイ形式を使用すると、インターネットへの送信トラフィックのための専用アドレス、またはアプリからのすべての送信トラフィックをロックダウンする機能は、提供されません。 ASE を使用した場合に利用可能な機能のほとんどを利用できます。

多層アプリケーションを作成する

多層アプリケーションとは、API バックエンド アプリにアクセスできるのがフロントエンド層だけであるアプリケーションのことです。 多層アプリケーションを作成するには、2 つの方法があります。 いずれの場合もまず、VNet 統合を使用して、フロントエンド Web アプリを仮想ネットワーク内のサブネットに接続します。 そうすることで、Web アプリから仮想ネットワークへの呼び出しを行うことができます。 フロントエンド アプリを仮想ネットワークに接続した後、API アプリケーションへのアクセスをロックダウンする方法を決める必要があります。 次のようにすることができます。

  • フロントエンドと API アプリの両方を同じ ILB ASE でホストし、アプリケーション ゲートウェイを使用してフロントエンド アプリをインターネットに公開します。
  • フロントエンドをマルチテナント サービスでホストし、バックエンドを ILB ASE でホストします。
  • フロントエンドと API アプリの両方を、マルチテナント サービスでホストします。

多層アプリケーションのフロントエンドと API アプリの両方をホストする場合は、次のようにすることができます。

  • 仮想ネットワーク内のプライベート エンドポイントを使用して、API アプリケーションを公開します。

    2 層アプリでプライベート エンドポイントを使用する方法を示す図。

  • サービス エンドポイントを使用して、API アプリへの受信トラフィックを、確実にフロントエンド Web アプリによって使用されるサブネットからのものだけに制限します。

    アプリをセキュリティで保護するためのサービス エンドポイントの使用方法を示す図。

使用する方法を決定するときに役立ついくつかの考慮事項を次に示します。

  • サービス エンドポイントを使用するときは、API アプリへのトラフィックを統合サブネットに限定するだけで済みます。 これは API アプリのセキュリティ保護に役立ちますが、その場合でも、フロントエンド アプリから App Service 内の他のアプリにデータが流出する可能性があります。
  • プライベート エンドポイントを使用するときは、2 つのサブネットを使用するので、複雑さが増します。 また、プライベート エンドポイントは最上位のリソースであり、管理のオーバーヘッドが増えます。 プライベート エンドポイントを使用する利点は、データ流出のおそれがないことです。

どちらの方法も、複数のフロントエンドで機能します。 小規模な場合、フロントエンド統合サブネットで API アプリに対してサービス エンドポイントを有効にするだけであるため、サービス エンドポイントの方が使いやすくなります。 フロントエンド アプリをさらに追加する場合は、すべての API アプリを調整して、統合サブネットを使用してサービス エンドポイントを組み込む必要があります。 プライベート エンドポイントを使用すると、より複雑になりますが、プライベート エンドポイントを設定した後に API アプリで何も変更する必要はありません。

基幹業務アプリケーション

基幹業務 (LOB) アプリケーションは、通常はインターネットからアクセスできるように公開されていない内部アプリケーションです。 これらのアプリケーションは、アクセスを厳密に制御できる企業ネットワーク内から呼び出されます。 ILB ASE を使用する場合、基幹業務アプリケーションを簡単にホストできます。 マルチテナント サービスを使用する場合は、プライベート エンドポイントまたはサービス エンドポイントをアプリケーション ゲートウェイと組み合わせて使用できます。 プライベート エンドポイントを使用する代わりに、サービス エンドポイントでアプリケーション ゲートウェイを使用する理由は 2 つあります。

  • LOB アプリで WAF 保護が必要である。
  • LOB アプリの複数のインスタンスに負荷を分散する必要がある。

どちらも必要ない場合は、プライベート エンドポイントを使用することをお勧めします。 App Service で使用可能なプライベート エンドポイントの場合、仮想ネットワーク内のプライベート アドレスでアプリを公開できます。 仮想ネットワークに配置したプライベート エンドポイントには、ExpressRoute および VPN 接続を介して到達できます。

プライベート エンドポイントを構成すると、プライベート アドレスでアプリが公開されますが、オンプレミスからそのアドレスに到達するように DNS を構成する必要があります。 この構成を機能させるには、プライベート エンドポイントが含まれる Azure DNS プライベート ゾーンを、オンプレミスの DNS サーバーに転送する必要があります。 Azure DNS プライベート ゾーンでゾーンの転送はサポートされませんが、その目的に DNS サーバーを使用すれば、ゾーンの転送をサポートできます。 DNS フォワーダー テンプレートを使用すると、Azure DNS のプライベート ゾーンをオンプレミスの DNS サーバーに簡単に転送できます。

App Service ポート

App Service をスキャンすると、受信接続用に公開されているいくつかのポートが見つかります。 マルチテナント サービスでこれらのポートへのアクセスをブロックまたは制御する方法はありません。 公開されるポートの一覧を次に示します。

用途 ポート
HTTP/HTTPS 80、443
管理 454、455
FTP/FTPS 21、990、10001-10020
Visual Studio リモート デバッグ 4020、4022、4024
Web 配置サービス 8172
インフラストラクチャの使用 7654、1221