Azure App Service のアクセス制限

App Service のアクセス制限は、トラフィックをブロックおよびフィルター処理できるファイアウォールと同等です。 アクセス制限は、受信アクセスにのみ適用されます。 大多数の App Service 価格レベルでは、プライベート エンドポイントをアプリに追加することもできます。これは、アプリへのもう 1 つのエントリ ポイントです。 プライベート エンドポイントを経由して入るトラフィックには、アクセス制限は適用されません。 App Service でホストされているすべてのアプリについて、既定のエントリ ポイントが一般公開されています。 唯一の例外は、既定のエントリ ポイントが仮想ネットワークの内部にある ILB App Service Environment でホストされているアプリです。

しくみ

トラフィックが App Service に達すると、最初に、そのトラフィックがプライベート エンドポイントから送信されたのか、または既定のエンドポイントを経由しているのかが評価されます。 トラフィックがプライベート エンドポイントを介して送信される場合、制限なしで直接サイトに送信されます。 プライベート エンドポイントに対する制限は、ネットワーク セキュリティ グループを使用して構成されます。

トラフィックを既定のエンドポイント (多くの場合、パブリック エンドポイント) を介して送信すると、トラフィックは最初にアプリ アクセス レベルで評価されます。 ここでは、アクセスを有効または無効にすることができます。 アプリ アクセスを有効にすると、トラフィックはアプリのアクセス レベルで評価されます。 どのアプリでも、メイン サイトと高度なツール サイト (scm または kudu サイトとも呼ばれます) の両方があります。

サイトごとに一連のアクセス制限規則を構成するオプションがあります。 アクセス制限ルールは優先順位で評価されます。 一部のルールの優先度が同じである場合は、Azure Resource Manager API から返されたときに表示される順序と、Azure portal で並べ替え前の順番で評価されます。 ルールが一致しない場合は、動作を指定することもできます。 次のセクションでは、詳細について説明します。

アプリのアクセス

アプリ アクセスを使用すると、アクセスが既定 (パブリック) エンドポイントと考えられているかどうかを構成できます。 この動作は、Disabled または Enabled に構成します。 アクセスが有効になっている場合は、サイト アクセス制限ルールを追加して、選択した仮想ネットワークと IP アドレスからのアクセスを制御できます。

設定が設定されていない場合 (プロパティが null)、既定の動作ではアクセスが有効になりますが、プライベート エンドポイントが存在する場合は、その動作が変更され、アクセスが無効になります。 Azure portal でプロパティが設定されていない場合、ラジオ ボタンも設定されず、既定の動作が使用されます。

Azure Resource Manager API では、アプリ アクセスを制御するプロパティは publicNetworkAccess と呼ばれます。 内部ロード バランサー (ILB) App Service Environment では、アプリの既定のエントリ ポイントは常に仮想ネットワークの内部にあります。 アプリ アクセス (publicNetworkAccess) を有効にしても、アプリへの直接パブリック アクセスは許可されません。代わりに、App Service Environment の内部 IP アドレスに対応する既定のエントリ ポイントからのアクセスが許可されます。 ILB App Service Environment でアプリ アクセスを無効にした場合、個々のアプリに追加されたプライベート エンドポイントを介してのみアプリにアクセスできます。

サイトへのアクセス

サイト アクセス制限を使用すると、受信要求をフィルター処理できます。 サイト アクセス制限により、優先順位に従って評価される許可規則と拒否規則のリストを作成できます。 これは、Azure ネットワークのネットワーク セキュリティ グループ (NSG) 機能と似ています。

サイト アクセス制限には、適用できるいくつかの種類のルールがあります。

不一致のルール

ルールが一致しない場合 (既定のアクション) の動作を構成できます。 これは、規則コレクションの最後の規則として常に表示される特別な規則です。 設定が構成されていない場合、一致しないルールの動作は、構成されたルールによって異なります。 ルールがない場合、一致しないルールの動作は、すべてのアクセスを許可しますが、1 つ以上のルールが存在する場合は、すべてのアクセスを拒否するように暗黙的に変更されます。 この動作は、定義されたルールに関係なく、アクセスを許可または拒否するように明示的に構成できます。

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

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

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

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

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

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

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

すべてのサービス エンドポイント ソース

テストまたは特定のシナリオでは、サービス エンドポイントが有効なサブネットからのトラフィックを許可できます。 これを行うには、IP 範囲の代わりに "AnyVnets" というテキストを使用して IP ベースのルールを定義します。 ポータルでこれらのルールを作成することはできませんが、既存の IP ベースの規則を変更し、IP アドレスを "AnyVnets" 文字列に置き換えることができます。

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

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

タグの完全な一覧と詳細については、サービス タグのリンクを参照してください。

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

複数ソース規則

複数ソース規則を使用すると、1 つの規則に最大 8 個の IP 範囲または 8 個のサービス タグを組み合わせることができます。 IP 範囲数が 512 を超える場合、複数ソース規則を使用できます。 また、複数の IP 範囲を 1 つの http ヘッダー フィルターと組み合わせる論理規則を作成する場合も複数ソース規則を使用できます。

複数ソース規則は、単一ソース規則と同じ方法で定義されますが、各範囲をコンマで区切ります。

ポータルでこれらのルールを作成することはできませんが、既存のサービス タグまたは IP ベースのルールを変更し、ルールにソースを追加できます。

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

どのルールでも、種類に関係なく、http ヘッダー フィルター処理を追加できます。 ヘッダー フィルターにより、受信要求をさらに検査し、特定の HTTP ヘッダー値に基づいてフィルター処理できます。 各ヘッダーには、規則あたり最大 8 つの値を追加できます。 サポートされている http ヘッダーの一覧を次に示します。

• X-Forwarded-For。 プロキシ サーバー経由で接続するクライアントの送信元 IP アドレスを識別するための標準ヘッダー。 有効な IP アドレスを受け入れます。
• X-Forwarded-Host。 クライアントによって要求された元のホストを識別するための標準ヘッダー。 最大 64 文字までの文字列を受け入れます。
• X-Azure-FDID。 リバース プロキシ インスタンスを識別するためのカスタム ヘッダー。 Azure Front Door はインスタンスを識別する guid を送信しますが、Microsoft 以外のプロキシが特定のインスタンスを識別するために使用することもできます。 最大 64 文字までの文字列を受け入れます。
• X-FD-HealthProbe。 リバース プロキシの正常性プローブを識別するためのカスタム ヘッダー。 Azure Front Door は、正常性プローブ要求を一意に識別するために "1" を送信します。 ヘッダーは、Microsoft 以外のプロキシが正常性プローブを識別するために使用することもできます。 最大 64 文字までの文字列を受け入れます。

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

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

診断ログ

App Service では、さまざまなログ カテゴリを Azure Monitor に送信できます。 これらのカテゴリの 1 つは IPSecurity Audit logs と呼ばれ、アクセス制限のアクティビティを表します。 ルールに一致するすべての要求 (一致しないルールを除く) は許可と拒否の両方でログに記録され、アクセス制限の構成を検証するために使用できます。 ログ機能は、ルールの構成をトラブルシューティングする際の強力なツールにもなります。

高度なユース ケース

上記の機能を組み合わせることで、次のセクションで説明する特定のユース ケースを解決できます。

単一の IP アドレスをブロックする

1 つ以上の特定の IP アドレスを拒否またはブロックする場合は、IP アドレスを拒否規則として追加し、一致しないすべてのトラフィックを許可するように不一致ルールを構成できます。

高度なツール サイトへのアクセスを制限する

高度なツール サイト (scm または kudu とも呼ばれます) には、構成できる個々のルール コレクションがあります。 このサイトの不一致ルールを構成することもできます。 設定では、メイン サイト用に構成されたルールを使用できます。 特定の高度なツール サイト機能へのアクセスを選択的に許可することはできません。 たとえば、高度なツール サイトの WebJobs 管理コンソールへのアクセスのみを選択的に許可することはできません。

プライベート エンドポイント経由でのデプロイ

パブリックにアクセスできるサイトがある可能性がありますが、デプロイ システムは仮想ネットワーク内にあります。 プライベート エンドポイントを追加することで、デプロイ トラフィックをプライベートに保つことができます。 その後、パブリック アプリのアクセスが有効になっていることを確認する必要があります。 最後に、高度なツール サイトが拒否するように一致しない規則を設定する必要があります。これによって、そのエンドポイントへのパブリック トラフィックがすべてブロックされます。

プライベート エンドポイントで保護されたサイトへの外部パートナー アクセスを許可する

このシナリオでは、プライベート エンドポイントを介してサイトにアクセスし、プライベート エンドポイントを介してデプロイします。 サイトをテストするために、外部パートナーを一時的に招待するこもできます。 これを行うには、パブリック アプリ アクセスを有効にします。 パートナーのクライアントを識別するルール (IP ベース) を追加します。 メイン ツール サイトと高度なツール サイトの両方に対して拒否するように、一致しないルール アクションを構成します。

特定の Azure Front Door インスタンスへのアクセスを制限する

Azure Front Door からアプリケーションへのトラフィックは、AzureFrontDoor.Backend サービス タグに定義されている既知の IP 範囲セットが発信元です。 サービス タグ制限規則を使用すると、トラフィックを Azure Front Door からの発信のみに制限できます。 トラフィックの発信元が特定のインスタンスのみになるようにするには、X-Azure FDID と呼ばれる Azure Front Door によって送信される一意の HTTP ヘッダーに基づいて受信要求をさらにフィルター処理する必要があります。 Front Door ID はポータルで確認できます。

次のステップ