App Service をセキュアに運用するためのネットワーク機能について
はじめに
本稿では、日頃より App Service をご利用いただいているお客様やこれから App Service をご検討いただいているお客様向けに、 App Service をネットワークの観点からセキュアな環境で運用するための機能や仕組みについてご紹介します。
App Service プラットフォームの構成について知ったうえで読んでいただくことでより理解も深まるかと存じますので、もしよろしければ App Service を構成する主要な要素とそれぞれの役割 もぜひご一読いただけますと幸いです。
App Service は既定でインターネットに公開され、 「クライアントから App Service (上のアプリケーション) へのアクセス」 や 「App Service (上のアプリケーション) からデータベース等のエンドポイントへの接続」 はそれぞれインターネット*1 を経由して送信されます。また Visual Studio や Azure Pipelines 等からのアプリケーションのデプロイに関してもインターネットを経由して App Service (Kudu*2) に送信されます。
アプリケーションをインターネットに公開せず特定の IP アドレスからのみ許可したい場合や、アプリケーションから仮想ネットワーク内のエンドポイントに接続したいといった要件を実現するための機能・設定を App Service として提供しており、 Azure Portal の [ネットワーク] ブレードから構成することが可能です。
App Service では受信側 (クライアントから App Service へのトラフィック) と送信側 (App Service から外部エンドポイントへのトラフィック) は異なる経路で通信され、それぞれの通信を個別に制御することが可能です。
- 1) Azure データセンター間の通信は マイクロソフトのグローバル ネットワーク 内でルーティングされるためパブリックインターネットを経由しません。
- 2) Kudu サービスの概要
受信トラフィック (クライアント → App Service)
App Service のパブリック IP アドレスについて
App Service ではリソースごとに固有の FQDN (<app-service-name>.azurewebsites.net) が付与されますが、 nslookup 等で名前解決をしてみると一意のパブリック IP アドレスに名前解決されることが分かります。これは Azure Portal > App Service > [ネットワーク] ブレード > “受信トラフィック” 内の “受信アドレス” に表示される IP アドレスと一致します。
しかしこの IP アドレスに対してブラウザからアクセスすると HTTP 404 エラーが返却されます。これは App Service プラットフォームを構成するフロントエンドと呼ばれるロードバランサーが複数のお客様のリソースで共有しているためです。
クライアントから App Service への HTTP/S リクエストは、 App Service プラットフォーム内部のフロントエンドと呼ばれるロードバランサーを経由してお客様のアプリケーションが動作するインスタンスに送信されます。 App Service の受信パブリック IP アドレスはスケールユニット*3) 内で共有され、フロントエンドは HTTP/S リクエスト内の Host ヘッダーを元に送信先のアプリケーションを判断します。
カスタムドメインの追加について
App Service ではお客様が所有するカスタムドメインを使用してアプリケーションにアクセスすることができますが、 DNS サーバーへのレコード追加だけではカスタムドメインを使用してアプリケーションにアクセスすることができません (HTTP 404 エラー応答が返却されます)。
これは前述しましたように、 App Service プラットフォーム内部のフロントエンドは HTTP/S リクエスト内の Host ヘッダーを元に送信先のアプリケーションを判断しているためで、フロントエンドに対してドメインとアプリケーションの関係性を登録する必要があります。
具体的には、 Azure Portal の [カスタムドメイン] ブレード > [+ カスタムドメインの追加] からカスタムドメインを登録することで、フロントエンドが当該ドメインへのリクエストをアプリケーションに送信することができるようになります (App Service ドメイン以外のドメインレジストラをご利用の場合、実際にカスタムドメインを名前解決するための DNS レコードの追加は別途必要となりますのでご留意ください)。
なお App Service にカスタムドメインを追加する際にはドメイン所有権の検証が必要となり、具体的には asuid.<custom-domain> に対する TXT レコードをパブリック DNS サーバーに登録する必要があります。
これは App Service をインターネットに公開せずに (プライベートエンドポイントを構成して) 使用する場合でも同様となり、パブリック DNS サーバーへの TXT レコードの追加が必要となりますのでご留意ください (内部 ASE では .local などのドメインを所有権の検証をスキップして登録することが可能です)。
プライベートエンドポイントについて
App Service ではプライベートエンドポイントを構成することで、仮想ネットワーク内のプライベート IP アドレスでアプリケーションを公開することが可能です。
これによりフロントエンドとプライベートエンドポイントがプライベートリンクで接続されます。言い換えますと、プライベートエンドポイントを構成した場合でもフロントエンドを経由しますので、プライベート IP アドレスを直接指定してアクセスすることはできず、 Host ヘッダーは必要となります。
また App Service では FTP/S を使用して App Service 上のファイルサーバーに接続することができますが、 FTP/S はプライベートエンドポイント経由で接続することは叶わず、インターネット経由で接続する必要がございますのでご留意ください。
アクセス制限について
App Service のアクセス制限では、指定した IP アドレス (レンジ) からのみアプリケーションへのアクセスを許可することや拒否することができます。規則には 「IPv4/IPv6 アドレス」 に加えて 「サービスエンドポイント」 や 「サービスタグ」 を使用することも可能です。なお規則に FQDN を指定することは叶いません。
またアクセス制限の規則は “メインサイト (アプリケーション)” と “高度なツールサイト (Kudu サイト)” をそれぞれ独立して管理することが可能です。例えば 「アプリケーションはインターネットに公開せずプライベートエンドポイント経由でのみ公開するが、アプリケーションのデプロイはインターネット上の特定の IP アドレスから実行したい」 というような場合にも、メインサイトはすべてのアクセスを拒否するように規則を構成し、高度なツールサイトで対象の IP アドレスからのアクセスを許可することで実現が可能です。
App Service のアクセス制限機能では、アクセス元の判断はフロントエンドで行われますので、拒否されるリクエストはお客様のアプリケーションが動作するインスタンスまで送信されません。 App Service 上に web.config ファイルを配置 (詳細はここでは割愛) し ipSecurity などを使用する場合に比べてセキュリティ面でもメリットと捉えることができます。
送信トラフィック (App Service → エンドポイント)
App Service の送信 IP アドレスについて
App Service 上のアプリケーションが外部のエンドポイント (Web API や Database 等) に接続するシナリオが考えられます。その際に使用される IP アドレスは前述した受信側の IP アドレスとは異なるものとなり、スケールユニットごとに割り当てられた IP アドレス (群) のいずれかが使用されます。
具体的には、 Azure Portal の [プロパティ] ブレードを開き、 “送信 IP アドレス” のうちのいずれかが使用されますので、アプリケーションから接続先となるサーバー (Database 等) でファイアウォールを構成している場合には、 “送信 IP アドレス” に記載の IP アドレス群をファイアウォールで許可する必要があります。
また App Service Plan をスケールアップ/ダウンさせると、この “送信 IP アドレス” が変更される可能性がございます*4) 。 “追加の送信 IP アドレス” はスケールアップ/ダウン時に使用される可能性のある IP アドレスを含んでおりますので、アプリケーションの運用過程でスケールアップ/ダウンの可能性がございます場合には、送信先サーバーのファイアウォールでは “追加の送信 IP アドレス” を許可していただければと存じます。
なお、これら “送信 IP アドレス” や “追加の送信 IP アドレス” はお客様のアプリケーションで専有される IP アドレスではなく、スケールユニット内の複数のお客様のアプリケーションで共有されます。専有のパブリック IP アドレスを使用して外部のエンドポイントに接続したいといった場合には、 NAT ゲートウェイとの統合*5) をご検討ください。
App Service からインターネットへの送信 (SNAT) について
App Service からインターネット上のエンドポイントに接続する場合、スケールユニット内のロードバランサーで SNAT が行われます。
この際に使用できる SNAT ポート数はインスタンスごとに制限があり、 SNAT ポートを使い果たすとアプリケーションエラーが発生することがございます。詳細については App Service における SNAT ポート枯渇問題とその解決方法 をご参照ください。
VNet 統合について
App Service 上のアプリケーションから仮想ネットワーク内のエンドポイントに接続したいといった場合、 VNet 統合を構成することでアプリケーションからのトラフィックが VNet を経由でき、 VNet 内のプライベート IP アドレスに対して接続が可能です。
VNet 統合ではサブネットを委任する必要があるため、空の専用のサブネットが必要となり、プライベートエンドポイントや他のリソースとサブネット内で共存させることは叶いません。また App Service はインスタンスごとに VNet 統合先サブネット内の IP アドレスを使用し、特にスケールアップ/ダウン、スケールアウト/インを実施する際には一時的にインスタンス数の 2 倍の IP アドレスを使用します。サブネットのサイズは作成後に変更することが叶いませんので、十分に余裕のあるアドレスレンジを持つサブネットを使用することをご検討ください (/26 以上のサイズが推奨されます*6) )。
2023 年 07 月 03 日時点の内容となります。
本記事の内容は予告なく変更される場合がございますので予めご了承ください。