Azure Front Door のルール セットとは

  • [アーティクル]

ルール セットとは、カスタマイズされたルール エンジンであり、複数のルールの組み合わせを 1 つのセットにまとめたものです。 ルール セットを複数のルートに関連付けることができます。 ルール セットを使用すると、Azure Front Door のエッジで要求が処理される方法をカスタマイズできます。

サポートされている一般的なシナリオ

  • HTTP Strict-Transport-Security (HSTS)、X-XSS-Protection、Content-Security-Policy、X-Frame-Options など、ブラウザーベースの脆弱性を防ぐためのセキュリティ ヘッダー、およびクロスオリジン リソース共有 (CORS) シナリオのための Access-Control-Allow-Origin ヘッダーを実装します。 セキュリティベースの属性は、Cookie でも定義できます。

  • クライアント デバイスの種類に基づいてアプリケーションのモバイルまたはデスクトップ バージョンに要求をルーティングします。

  • リダイレクト機能を使用して 301、302、307、308 のリダイレクトをクライアントに返し、それらを新しいホスト名、パス、クエリ文字列、またはプロトコルに送信します。

  • 受信要求に基づき、ルートのキャッシュ構成を動的に変更します。

  • 要求 URL パスを書き換えて、構成されている配信元グループ内の適切な配信元に要求を転送します。

  • 要求または応答ヘッダーを追加、変更、または削除して機密情報を非表示にしたり、ヘッダーを通じて重要な情報をキャプチャしたりします。

  • 要求ヘッダー、応答ヘッダー、または URL 書き換えパス/クエリ文字列を動的に変更するためのサーバー変数をサポートします。 たとえば、新しいページが読み込まれたときや、フォームが投稿されたときなどです。 サーバー変数は、現在、ルール セットのアクションでのみサポートされています。

Architecture

Front Door のエッジでは、ルール セットによって要求が処理されます。 要求が Front Door エンドポイントに到着すると、最初に WAF が処理され、次に、ルートに構成されている設定が続きます。 これらの設定には、ルートに関連付けられているルール セットが含まれます。 ルール セットは、ルーティング構成の下に表示される順序で処理されます。 ルール セット内のルールも、表示される順序で処理されます。 各ルール内のすべてのアクションが実行されるようにするには、ルール内のすべての一致条件が満たされる必要があります。 要求がルール セット構成内のどの条件にも一致しない場合は、既定のルート設定のみが適用されます。

[残りの規則の評価を停止する] が選択されている場合、ルートに関連付けられている残りのルール セットは実行されません。

例

次の図では、WAF ポリシーが最初に処理されます。 次に、ルール セット構成によって応答ヘッダーが追加されます。 一致条件が true の場合、ヘッダーのキャッシュ制御の最長有効期間が変更されます。

ルール セットが Front Door エンドポイントを通過する要求の応答ヘッダーを変更する方法を示す図。

用語

Front Door のルール セットを使用すると、それぞれが一連のルールで構成されている構成の組み合わせを作成できます。 ルール セットを構成する際に役立ついくつかの用語を次に示します。

  • "ルール セット": 1 つまたは複数のルートに関連付けられる一連のルール。

  • "ルール セット ルール": 最大 10 個の一致条件と 5 個のアクションで構成されるルール。 ルールは 1 つのルール セットに対してローカルであり、他のルール セットで使用するためにエクスポートすることはできません。 異なるルール セットで同じルールを作成できます。

  • "一致条件": 受信要求を解析するために構成できる一致条件は多数あります。 1 つのルールに最大 10 個の一致条件を含めることができます。 一致条件は、AND 演算子で評価されます。 条件では、正規表現がサポートされています。 一致条件の完全な一覧については、「ルール セットの一致条件」を参照してください。

  • "アクション": アクションでは、一致条件に基づいて Front Door で着信要求をどのように処理するかを示します。 キャッシュの動作を変更すること、要求ヘッダーや応答ヘッダーを変更すること、URL の書き換えと URL のリダイレクトを設定することができます。 "サーバー変数は、アクションでサポートされています"。 1 つのルールには 最大 5 つのアクションを含めることができます。 アクションの完全な一覧については、「ルール セットのアクション」を参照してください。

ARM テンプレートのサポート

ルール セットは Azure Resource Manager テンプレートを使用して構成できます。 例については、Front Door Standard/Premium とルール セットに関する記事を参照してください。 この動作をカスタマイズするには、一致条件とアクションのドキュメントの例に含まれている JSON または Bicep スニペットを使用します。

制限事項

クォータ制限の詳細については、Front Door の制限、クォータ、制約に関する記事を参照してください。

次のステップ

重要

Azure Front Door (クラシック) は、2027 年 3 月 31 日に廃止されます。 サービスの中断を回避するには、2027 年 3 月までに Azure Front Door の Standard または Premium レベルに Azure Front Door (クラシック) プロファイルを移行することが重要です。 詳細については、「Azure Front Door (クラシック) の廃止」を参照してください。

ルール エンジン構成により、Front Door のエッジでの HTTP 要求の処理方法をカスタマイズし、Web アプリケーションの動作を制御することができます。 Azure Front Door (クラシック) のルール エンジンには、次のようないくつかの重要な機能があります。

  • HTTPS を適用することで、すべてのエンド ユーザーがセキュリティで保護された接続でコンテンツを利用するようにします。
  • HTTP Strict-Transport-Security (HSTS)、X-XSS-Protection、Content-Security-Policy、X-Frame-Options のようなブラウザーベースの脆弱性を防ぐためのセキュリティ ヘッダー、およびクロスオリジン リソース共有 (CORS) シナリオのための Access-Control-Allow-Origin ヘッダーを実装します。 セキュリティベースの属性は、Cookie でも定義できます。
  • 要求ヘッダーの内容、Cookie、またはクエリ文字列のパターンに基づいて、モバイル版またはデスクトップ版のアプリケーションに要求をルーティングします。
  • リダイレクト機能を使用して 301、302、307、308 リダイレクトをクライアントに返し、新しいホスト名、パス、またはプロトコルに直接送信します。
  • 受信要求に基づき、ルートのキャッシュ構成を動的に変更します。
  • 要求 URL パスを書き換え、構成されているバックエンド プールの適切なバックエンドに要求を転送します。

アーキテクチャ

ルール エンジンは、エッジで要求を処理します。 要求が Azure Front Door (クラシック) エンドポイントに入力されると、最初に WAF が処理され、次にフロントエンド ドメインに関連付けられているルール エンジン構成が処理されます。 ルール エンジン構成が処理された場合は、一致条件が満たされていることを意味します。 各ルール内のすべてのアクションが処理されるようにするには、ルール内のすべての一致条件が満たされる必要があります。 要求がルール エンジン構成のどの条件にも一致しない場合は、次に既定のルーティング構成が処理されます。

たとえば、次の図では、応答ヘッダーを追加するようにルール エンジンが構成されます。 要求ファイルの拡張子が .jpg の場合、ヘッダーのキャッシュ制御の最長有効期間が変更されます。

要求されたファイルの拡張子が .jpg の場合に、応答ヘッダーのキャッシュの最長有効期間を変更するルール エンジンを示す図。

この 2 番目の例では、要求元のデバイスの種類が "モバイル" の場合、ユーザーをモバイル バージョンの Web サイトにリダイレクトするようにルール エンジンが構成されていることがわかります。

要求元のデバイスの種類がモバイルの場合にユーザーをモバイル バージョンの Web サイトにリダイレクトするルール エンジンを示す図。

どちらの例でも、一致条件が満たされない場合は、指定されたルーティング規則が処理されます。

用語

Azure Front Door (クラシック) では、それぞれが一連のルールで構成される多数のルール エンジン構成の組み合わせを作成できます。 ここでは、ルール エンジンを構成する際に役立つ用語をいくつか紹介します。

  • "ルール エンジン構成": 単一のルートに適用されるルールのセット。 各構成は 25 のルールに制限されます。 最大 10 個の構成を作成できます。
  • "ルール エンジン ルール": 最大 10 個の一致条件と 5 個のアクションで構成されるルール。
  • "一致条件": 受信要求を解析するために利用できる一致条件は多数あります。 1 つのルールに最大 10 個の一致条件を含めることができます。 一致条件は、AND 演算子で評価されます。 一致条件の完全な一覧については、「ルール一致条件」を参照してください。
  • アクション:アクションは、受信要求に対する処理を示します。要求または応答のヘッダー アクション、転送、リダイレクト、および書き換えが、現在使用できるすべてのアクションです。 1 つのルールには、最大 5 つのアクションを含めることができます。ただし、1 つのルールに含めることができるルート構成のオーバーライドは 1 つだけです。 アクションの完全な一覧については、ルール アクションに関する記事を参照してください。

次のステップ