eCDN レート制限ルール

レート制限ルールを使用することにより、特定の式に一致するリクエストのレート制限を指定し、そのレート制限に達したときにアクションを実行できます。レート制限ルールを使用して、特定のトラフィックパターンをターゲットにしてボットなどの脅威に対抗することで、ストアフロントの可用性を向上することができます。

このガイドでは、関連するさまざまなレート制限パラメーターの概要とともに、CDN-API を使用してこれらのルールをゾーンで有効にする方法について説明します。このページの下部にあるよくある質問 (FAQ) セクションも参照してください。

レート制限ルールの動作は、レート制限パラメーターの数によって異なります。

• 説明
• ルール式
• 特性
• アクション
• 期間
• 期間ごとのリクエスト
• 緩和タイムアウト (Block ルールまたは Log ルールの場合のみ)
• カウント式 (オプション)
• 有効 (オプション)
• 位置 (オプション)

• API での使用法: description
• レート制限ルールの説明。

• API での使用法: expression

• ルールをいつ適用するかを定義します。ルール式は、true または false のいずれかに評価されます。ルール式が true と評価された場合、ルールが実行されます。レート制限ルールの場合、ルールのアクションは、その時点でレート制限条件が満たされている場合にのみ適用されます。

  • 比較演算子:

    • eq, ne, contains, matches, in, lt, le, gt, ge

  • 論理演算子:

    • not, and, or, xor

  • 関数：

    式	型	の例での関数	の説明	の使用法
    any	引数内の比較演算子が、引数配列内のいずれかの値を返す*true*ときに返されます。trueそれ以外の場合を返しますfalse。	any(Array<Boolean>)	Boolean	any(http.request.headers[\"content-type\"][*] eq \"application/x-www-form-urlencoded\")
    all	引数の比較演算子が引数配列のすべての*値を返すtrue*ときに返されますtrue。それ以外の場合を返しますfalse。	all(Array<Boolean>)	Boolean	all(http.request.headers[\"content-type\"][*] eq \"application/json\")
    concat	カンマで区切られた値のリストを取ります。引数の値を 1 つの String に連結します。	concat( String | Integer | Bytes | Array elements)	糸	concat(http.request.uri.path,\"String\") eq \"sampleString\"
    ends_with	true ソースが指定された部分文字列で終わる場合を返します。それ以外の場合を返しますfalse。ソースをリテラル値にすることはできません (例"foo" : )。	ends_with(sourceString, substringString)	Boolean	ends_with(http.request.uri.path, \".html\")
    len	文字列型フィールドまたはバイト型フィールドのバイト長を返します。	len(String | Bytes)	Integer	len(http.host) lt 20
    lookup_json_integer	でfield指定されたkeyに関連付けられた整数値を返します。 注: はfield、有効な JSON ドキュメントの文字列表現である必要があります。属性key名、JSON 配列内の 0 から始まる位置番号、またはこれら 2 つのオプションの組み合わせ (追加の関数パラメーターとして) を指定できますが、JSON ドキュメントの階層に従って特定の整数値を取得します。この関数は、通常の整数に対してのみ機能します。たとえば、 のように小数点以下が42.0ゼロの浮動小数点数では機能しません。	lookup_json_integer(fieldString, keyString | Integer [, keyString | Integer , …])	Integer	lookup_json_integer(http.cookie, \"sampleCookie\") eq 10 lookup_json_integer(http.cookie, 1) eq 10 lookup_json_integer(http.cookie, 1, \"sampleCookie \") eq 10
    lookup_json_string	で指定された に関連付けられた文字列値を返します。key``field 注: はfield、有効な JSON ドキュメントの文字列表現である必要があります。属性key名、JSON 配列内の 0 から始まる位置番号、またはこれら 2 つのオプションの組み合わせ (追加の関数パラメーターとして) を指定できますが、JSON ドキュメントの階層に従って特定の値を取得します。	lookup_json_string(fieldString, keyString | Integer [, keyString | Integer, …])	String	lookup_json_string(http.cookie, \"sampleCookie\") eq \"sampleString\" lookup_json_string(http.cookie, 1) eq \"sampleString\" lookup_json_string(http.cookie, 1, \"sampleCookie\") eq \"sampleString\"
    lower	文字列フィールドを小文字に変換します。大文字の ASCII バイトのみが変換されます。他のすべてのバイトは影響を受けません。	lower(String)	String	lower(http.host) eq \"www.example.com\"
    starts_with	trueソースが指定された部分文字列で始まる場合を返します。それ以外の場合を返しますfalse。ソースをリテラル値にすることはできません (例"foo" : )。	starts_with(sourceString, substringString)	Boolean	starts_with(http.request.uri.path, \"/blog\")
    substring	バイトインデックスからバイトインデックスまで(ただし、バイトインデックスを除く) endの値の一部field (文字列またはバイトフィールドの値) startを返します。 の最初のfieldバイトのインデックス0は です。省略可能なend index を指定しない場合、関数は文字列の index からstart文字列の末尾までの部分を返します。インデックスはendインデックスよりstart大きくなければなりません。インデックスは負の整数値にすることができ、これにより、文字列の先頭ではなく末尾の文字にアクセスできます。& substring(fieldString	start``end #124; Bytes, startInteger [, endInteger])	String	substring(http.request.uri.path, 2, 5) eq \"sampleString\" substring(http.request.uri.path, 2) eq \"sampleString\"
    upper	文字列フィールドを大文字に変換します。小文字の ASCII バイトのみが変換されます。他のすべてのバイトは影響を受けません。	upper(String)	String	upper(http.host) eq \"WWW.EXAMPLE.COM\"
    url_decode	- のように、 で定義された URL 形式の文字列をデコードし、空白文字 ( ) にデコードします。source - %20 + ( ). このパラメーターはoptionsオプションです。すべてのオプションは、引用符で囲まれた単一の文字列として指定する必要があります (例"r"``"ur" : )。使用可能なオプションは次のとおりです。 r再帰的デコードを適用します。たとえば、%2520は空白文字に 2 回 (再帰的に) デコードされます。 - u パーセントのデコードを有効にします。たとえば、%E2%98%81%EF%B8%8F雲の絵文字にデコードされます。	url_decode(sourceString [, optionsString])	String	url_decode(http.request.full_uri) contains \"sampleString\" url_decode(http.request.full_uri, \"ur\") contains \"sampleString\"

  • フィールド:

    フィールド	説明	式での使用法	タイプ	例
    AS Number	クライアント IP アドレスに関連付けられた自律システム (AS) 番号。	ip.geoip.asnum	Integer	ip.geoip.asnum eq 12345
    Cookie	Cookie 全体を文字列として表します。	http.cookie	String	http.cookie eq \"session=8521F670545D7865F79C3D7BEDC29CCE;-background=light\"
    Country	ISO 3166-1 Alpha 2 形式の 2 文字の国コードを表します。	ip.geoip.country	String	not ip.geoip.country eq \"US\"
    Host Name	完全なリクエスト URI で使用されるホスト名を表します。	http.host	String	http.host eq \"www.example.com\"
    IP Address	クライアントの TCP IP アドレスを表します。	ip.src	IP address	ip.src in {93.184.216.34 192.168.123.132}
    HTTP Headers	HTTP リクエストヘッダーを Map (または連想配列) として表します。	http.request.headers	Map\String\Array	any(http.request.headers[\"content-type\"][*] eq \"application/json\")
    URI Full	Web サーバーが受信した完全な URI を表します。	http.request.full_uri	String	http.request.full_uri eq \"htt­ps://www.example.com/path/index?section=123456&expand=comments\"
    URI	リクエストの URI パスとクエリ文字列を表します。	http.request.uri	String	http.request.uri eq \"/path/index?section=123456&expand=comments\"
    URI Path	リクエストの URI パスを表します。	http.request.uri.path	String	http.request.uri.path eq \"/path/index\"
    URI Query String	? 区切り文字を除いたクエリ文字列全体を表します。	http.request.uri.query	String	http.request.uri.query eq \"section=123456&expand=comments\"
    Raw URI Full	http.request.full_uri 非 raw フィールドと同様です。Web サーバーが受信した完全な URI を表します。URI フラグメント (存在する場合) は含まれず、変換も行われません。この raw フィールドには、HTTP サーバーによる基本的な正規化が含まれる場合があることに注意してください。	raw.http.request.full_uri	String	raw.http.request.full_uri eq \"htt­ps://www.example.com/path/index?section=123456&expand=comments\"
    Raw URI	http.request.uri 非 raw フィールドと同様です。リクエストの URI パスとクエリ文字列を変換せずに表します。この raw フィールドには、HTTP サーバーによる基本的な正規化が含まれる場合があることに注意してください。	raw.http.request.uri	String	raw.http.request.uri eq \"/path/index?section=123456&expand=comments\"
    Raw URI Path	http.request.uri.path 非 raw フィールドと同様です。リクエストの URI パスを変換せずに表します。この raw フィールドには、HTTP サーバーによる基本的な正規化が含まれる場合があることに注意してください。	raw.http.request.uri.path	String	raw.http.request.uri.path eq \"/path/index\"
    Raw URI Query String	http.request.uri.query 非 raw フィールドと同様です。? 区切り文字と変換を含まないクエリ文字列全体を表します。この raw フィールドには、HTTP サーバーによる基本的な正規化が含まれる場合があることに注意してください。	raw.http.request.uri.query	String	raw.http.request.uri.query eq \"section=123456&expand=comments\"
    HTTP Referer	現在リクエストされているページにリンクされている Web ページのアドレスを含む HTTP Referer リクエストヘッダーを表します。	http.referer	String	http.referer contains \"www.example.com\"
    User Agent	HTTP ユーザーエージェントを表します。これはクライアントオペレーティングシステムと Web ブラウザーの識別を可能にする特性文字列を含むリクエストヘッダーです。	http.user_agent	String	http.user_agent eq \"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/101.0.4951.61 Safari/537.36\"
    Request Method	HTTP メソッドを表し、大文字の文字列として返されます。	http.request.method	String	http.request.method eq \"GET\"
    Continent	クライアント IP アドレスに関連付けられた大陸コードを表します。 AF – アフリカ AN – 南極大陸 AS – アジア EU – ヨーロッパ NA – 北アメリカ OC – オセアニア SA – 南アメリカ T1 – Tor ネットワーク	ip.geoip.continent	String	ip.geoip.continent in {\"NA\" \"EU\"}
    Bot Score*	リクエストがボットから発信された可能性を 1 ～ 99 のスコアで表します。スコアが低い場合は、リクエストがボットまたは自動エージェントからのものであることを示します。	cf.bot_management.score	Integer	cf.bot_management.score le 10
    Threat Score	0 ～ 100 の脅威スコアを表します。0 はリスクが低いことを示します。10 を超える値はスパマーまたはボットを表している可能性があり、40 を超える値はインターネット上の悪意ある人物を識別します。 60 を超える値はまれです。一般的な推奨事項は、10 を超えるスコアのリクエストにチャレンジを提示し、50 を超えるリクエストをブロックすることです。	cf.threat_score	Integer	cf.threat_score gt 50
    JA3 Fingerprint*	潜在的なボットリクエストの識別に役立つ SSL/TLS フィンガープリントを提供します。	cf.bot_management.ja3_hash	String	cf.bot_management.ja3_hash eq \"e7d705a3286e19ea42f587b344ee6865\"
    Verified Bot*	true の場合、このフィールドはリクエストが既知の良好なボットまたはクローラーから発信されたことを示します。cf.client.bot と同じ情報を提供します。	cf.bot_management.verified_bot	Boolean	cf.bot_management.verified_bot

• API での使用法: characteristics
• 文字列の配列を受け取ります。特性により、受信リクエストがどのようにグループ化されるかが決まります。定義された特性と同じ値をもつリクエストはグループ化され、レートカウンターを共有します。
  • たとえば、ルールの特性として IP が使用されるとしましょう。単一の IP アドレスからのリクエストのレートが、定義された制限を超える場合、その IP アドレスからのさらなるリクエストのレートは制限されます。他の IP アドレスからのリクエストは、同じレートカウンターを共有しません。つまり、1 つの IP アドレスのリクエストレートは、他の IP アドレスのリクエストレートに影響を与えません。
• 以下の特性がサポートされます。

• 同じレート制限ルールの特性として「 NAT サポート付き IP 」と「 IP 」の両方を使用することはできないことに注意してください。したがって、API の使用例は次のとおりです。

  "characteristics": ["ip.src"]

  または

  "characteristics": ["cf.unique_visitor_id"]

• API での使用法: action
• レート制限基準が満たされた場合に実行するアクションです。
• サポートされているアクション: block、log、legacy_captcha、js_challenge、managed_challenge
  • 各アクションの詳細については、こちらのドキュメントを参照してください。

• API での使用法: period
• リクエストレートを評価する際に考慮する期間。
• サポートされている値: 10、60、120、300、600 (単位: 秒)。

• API での使用法: requestsPerPeriod
• 任意の正の整数値。指定された期間内のリクエスト数の制限を表します。

• API での使用法: mitigationTimeout
• 「タイムアウト」の時間。レート制限基準が満たされると、レート制限ルールは、このフィールドで定義された期間、ルール式に一致するさらなるリクエストにアクションを適用し続けます。
  • block または log アクションを使用するルールにのみ関連します。このパラメーターは、チャレンジアクション (legacy_captcha、js_challenge、managed_challenge) を使用するルールには指定できません。
• サポートされている値: 60、120、300、600、3600、86400 (単位: 秒)。
  • mitigationTimeout の値も、定義された period 以上である必要があります。

• API での使用法: countingExpression
• レート制限を適用するリクエスト基準を定義します。つまり、このパラメーターはレートカウンターをインクリメントするタイミングを定義します。レートカウンターは、期間ごとにリクエスト数を追跡 ​​ します。レートカウンターが、設定した期間ごとに定義されたリクエスト制限を超えると、ルールのアクションが実行されます。
  • カウント式が指定されていない場合、カウント式はルール式と同じになります。
  • カウント式は、HTTP レスポンスコードに基づいてレート制限するオプションをサポートしています。 ルール式のみを使用する場合、これはできません。HTTP レスポンスコードに基づいてレート制限を行う場合は、カウント式を使用する必要があります。カウント式を使用する場合のその他の例については、よくある質問 (FAQ) を参照してください。
• カウント式の検証はルール式と同じですが、次のフィールドが追加されています。

• API での使用法: enabled
• レート制限ルールが有効かどうかを指定します。デフォルト値は true です。

• API での使用法: position

• このパラメーターを指定すると、ルールセット内の特定の相対位置にルールが挿入されます。このパラメータは、レート制限ルールを作成または更新するときに使用できます。

  • 提供されたインデックスが現在のルールセット内のルールと一致するかを検証します。レート制限ルールの作成時に位置が指定されていない場合、そのルールはデフォルトでルールセットの最後に追加されます。

次のセクションでは、レート制限ルールの一般的なユースケースについて説明します。これらの例を使用し、必要に応じて組み合わせて、独自のビジネスニーズに合わせて調整してください。

• ユーザーエージェント、IP アドレス、ホスト、国、世界の地域などの基準に基づくアクセス管理を含む、リソースへのきめ細かいアクセス管理を実施します。
• 例 A: 個々のユーザーエージェントによって実行されるリクエストの速度を制限します。
  • ルール式: http.user_agent eq "MobileApp"
  • レート: 100 件のリクエスト/ 10 分
  • アクション: 管理されたチャレンジ
• 例 B: 特定の IP アドレスまたは ASN をレート制限ルールに含める、または除外します。
  • ルール式: http.request.uri.path eq "/status" and http.request.method eq "GET" and not ip.src in { <defined IPs> }
  • レート: 10 件のリクエスト / 1 分
  • アクション: 管理されたチャレンジ

• クレデンシャルスタッフィングやアカウント乗っ取り攻撃から保護します。一般的なユースケースは、ログインエンドポイントを保護することです。また、複数のレート制限ルールを作成し、増加するペナルティを定義して、リクエストが多すぎるクライアントを管理することもできます。
• 例 A: ログイン失敗回数が多すぎる場合の保護。
  • ルール式: http.host eq "example.com" and http.request.uri.path eq "/login" and http.request.method eq "POST"
  • カウント式: http.request.uri.path eq "/login" and http.request.method eq "POST" and http.response.code in {401 403}
  • レート: 5 件のリクエスト / 1 分
  • アクション: 管理されたチャレンジ
• 例 B: ユーザーが例 A で定義されたルールによって提示されたチャレンジにパスした場合に備えて、別の保護層を作成します。ユーザーがこの 2 番目のしきい値を超えると、ログインページへのアクセスは 10 分間ブロックされます。
  • ルール式: http.host eq "example.com" and http.request.uri.path eq "/login"
  • カウント式: http.request.uri.path eq "/login" and http.request.method eq "POST" and http.response.code in {401 403}
  • レート: 20 件のリクエスト/ 10 分
  • アクション: 10 分間ブロック

• 個々のクライアントが実行するオペレーションの数を制限します。ボットによるスクレイピング、機密データへのアクセス、新しいアカウントの一括作成、自動買い付けを防ぎます。
• 例 A: (クエリ文字列による) コンテンツのスクレイピングを防ぎます。
  • ルール式: http.request.uri.path eq "/merchant" and http.request.uri.query contains "action=lookup_price"
  • レート: 10 件のリクエスト / 1 分
  • アクション: 管理されたチャレンジ
• 例 B: ボットからのリクエストを制限します。ボットからのトラフィックを識別する一般的な方法は、エラーレスポンスのステータスコードを大量にトリガーするリクエストをレート制限することです。
  • ルール式: http.host eq "example.com"
  • カウント式: http.response.code in {401 403}
  • レート: 25 件のリクエスト/ 2 分
  • アクション: 管理されたチャレンジ
• 例 C: ゾーンにボット管理の資格がある場合は、bot_management フィールドの使用を検討します。
  • ルール式: cf.bot_management.score lt 30 and http.request.uri.query contains "action=delete"
  • レート: 20 件のリクエスト/ 5 分
  • アクション: 1 時間ブロック

このエンドポイントは、指定されたゾーンのレート制限ルールを作成します。

• パラメーター検証の詳細については、上記の レート制限パラメーター セクションを参照してください。

成功レスポンス - 201 HttpStatus コードの例 レスポンスボディには、作成されたレート制限ルールが含まれます。

このエンドポイントは、指定されたゾーンのすべてのレート制限ルールを優先順位に従って返します。レート制限ルールが存在しない場合は、404 (Not Found) レスポンスが返されます。

成功レスポンス - 200 HttpStatus コードの例 レスポンスボディには、指定されたゾーンの現在のレート制限ルールがすべて含まれます。

このエンドポイントは、リクエストされたレート制限ルールを返します。リクエストされたルールが存在しない場合は、404 (Not Found) レスポンスが返されます。

成功レスポンス - 200 HttpStatus コードの例 レスポンスボディには、リクエストされたレート制限ルールが含まれます。

このエンドポイントは、リクエストされたレート制限ルールを更新します。リクエストされたルールが存在しない場合は、404 (Not Found) レスポンスが返されます。

• 少なくとも 1 つのレート制限パラメーターをリクエストボディに指定する必要があります。
• countingExpression を設定したが、それを削除したい (したがってルール式のデフォルトにしたい) というシナリオでは、リクエストボディに "countingExpression": "" を含めて値をリセットする必要があります。

成功レスポンス - 200 HttpStatus コードの例 レスポンスボディには、リクエストされたレート制限ルールが含まれます。

このエンドポイントは、リクエストされたレート制限ルールを削除します。リクエストされたルールが存在しない場合は、404 (Not Found) レスポンスが返されます。

成功レスポンス - 204 HttpStatus コード (コンテンツなし) の例

• カウント式はルール式とどのように異なりますか?
  • ルール式は、レート制限ルールを 評価 するタイミングを定義します。リクエストがルール式に一致する場合、レート制限ルールが評価されます。レート制限ルールを評価するときは、レートカウンターが、期間ごとに定義されたリクエストを超えているかどうかを確認します。超えている場合、ルールのアクションが適用されます。
  • カウント式は、レート制限する リクエストの種類 を定義します。リクエストがカウント式に一致する場合、レートカウンターがインクリメントされます。カウンターは、レート制限基準を満たしたリクエスト数を記録します。
• カウント式はどのような場合に使用しますか?
  • ほとんどのユースケースでは、カウント式をルール式と同じにするだけで十分であり、カウント式を指定する必要はありません。
    • 例 A: 特定のパスに送信される高トラフィックをレート制限します。リクエスト数が 1 分間に 10,000 件を超えた場合、そのパスへのさらなるリクエストを 10 分間ブロックします。
      • ルール式: http.request.uri.path eq "/path"
      • カウント式 (デフォルト): http.request.uri.path eq "/path"
      • レート: 10,000 件のリクエスト / 1 分
      • アクション: 10 分間ブロック
  • 時には、HTTP レスポンスコードに基づいてレート制限を行いたい場合があります。これらのユースケースでは、カウント式を指定する必要があります。カウント式では、追加のレスポンスコードフィールドを利用できるためです。ルール式のみを使用する場合、HTTP レスポンスコードに基づくレート制限はできません。
    • 例 B: 自動化された攻撃者に対して管理されたチャレンジを提示することで、悪意のあるトラフィックでフォームが過負荷になるのを防ぎます。400 応答コードを返す特定のフォームに送信されるトラフィックをレート制限します。
      • ルール式: http.request.uri.path eq "/form"
      • カウント式: http.request.uri.path eq "/form" and http.response.code eq 400
      • レート: 15 件のリクエスト/ 5 分
      • アクション: 管理されたチャレンジ
  • 次に挙げるのは、カウント式をルール式と異なるものとする別の例です。
    • 例 C: 悪意のある攻撃者からログインエンドポイントを保護します。ユーザーが 10 分間に 15 回の不正なログインリクエストを行った場合、そのユーザーはサイト 全体 へのアクセスを 1 時間ブロックされます。
      • ルール式: http.host eq "example.com"
      • カウント式: http.request.uri.path eq "/login" and http.request.method eq "POST" and http.response.code in {401 403}
      • レート: 15 件のリクエスト/ 10 分
      • アクション: 1 時間ブロック
• 特性はどのように機能しますか?
  • 定義されたルールの特性の値の組み合わせごとに、個別のレートカウンターが保持されます。つまり、特性によって、受信リクエストがどのようにグループ化されるかが決まります。
    • 次の特性で構成されたルールを考えてみましょう。
      • IP アドレス
      • HTTP ヘッダー x-api-key
    • この場合、HTTP ヘッダー X-API-Key の値は同じですが、IP アドレスが 異なる 2 つの受信リクエストは、値の組み合わせが異なるため、別々にカウントされます。さらに、カウンターはデータセンター間で共有はされません。
  • CDN-API は現在、「 IP 」または「 NAT サポート付き IP 」のみを特性として受け入れ、これら 2 つの特性を同じレート制限ルールで使用することはできないことに注意してください。したがって、上で示した使用例は今回は関係ありませんが、特性がどのように機能するかを理解するのに役立つ例となります。
• NAT サポート付きの IP の使用が推奨されるのはなぜですか?
  • 同じ IP アドレスで eCDN にリクエストが入ってくる可能性がある状況でもユニーク訪問者を識別できるため、NAT サポート付き IP を使用することをお勧めします。
  • NAT サポート付き IP の使用は、スタック型 eCDN 構成を使用している顧客に必要です。 これは、リクエストが eCDN に到達する前にスタックされたプロバイダーを経由してルーティングされるためです。NAT サポート付き IP を使用すると、それぞれのユニーク訪問者が適切に識別され、スタックされたプロバイダーのソース IP はレート制限されなくなります。
• ルールの順序が重要なのはなぜですか?
  • レート制限ルールは、リストされた最初のルールから始めて、レスポンスボディで返される順序で評価されます。特定のルールの優先度を更新するには、PATCH エンドポイントを使用し、リクエストボディに position パラメーターを指定します。
  • リクエストがレート制限基準を満たし、レート制限ルールの実行をトリガーすると、ルールのアクションが実行され、その特定のリクエストに対して他のレート制限ルールは評価されません。次のリクエストが受信されると、ルールの評価はルールセットの先頭から始まります。
• ルール式を構築するにはどうすればいいですか?
  • ルール式の構築に関する詳細については、こちらのドキュメントを参照してください。
• ルール式で特定のフィールドを使用するにはどうすればよいですか?
  • 特定のフィールドの使用法の詳細については、こちらのドキュメントを参照してください。