レート制限の概要

Google Cloud Armor では、さまざまなレイヤ 3 とレイヤ 7 の攻撃から Google Cloud アプリケーションを保護する機能を用意しています。レートベースのルールを使用すると、インスタンスに送られる大量のリクエストからアプリケーションを保護し、正当なユーザーへのアクセスをブロックできます。

レート制限によって次のことができます。

  • 特定のクライアントがアプリケーション リソースを使い果たさないようにします。
  • アプリケーション インスタンスで、クライアント リクエストの量が不安定で予測できない状況で急激に増加しないようにします。

また、少数のクライアントからのトラフィックが大量に発生しているリソースが存在する場合は、そのトラフィックの急増によって他のクライアントが影響を受けないようにして、使用中のリソースでできるだけ多くのリクエストを処理できるようにします。

Google Cloud Armor には、次の 2 種類のレートベースのルールがあります。

  1. スロットル: 個々のクライアントをユーザーが構成したしきい値でスロットル調整することで、1 クライアントまたは全クライアントに対して最大リクエスト上限を適用できます。
  2. レートベースの禁止: クライアントごとに設定したルールに一致するリクエストのレート制限を適用できます。ユーザーが構成したしきい値を超えると、構成した期間、クライアントを一時的に禁止できます。

レートベースの禁止アクションを含むルールを構成した場合、後でスロットリング アクションに変更することはできません。ただし、スロットル アクションでルールを構成した場合は、後でレートベースの禁止アクションに変更できます。詳細については、複数のキーに基づくレート制限をご覧ください。

Google Cloud Armor は、関連付けられた各バックエンドにレート制限しきい値を適用します。たとえば、2 つのバックエンド サービスがあり、1 分あたり 1,000 リクエストのしきい値を含むレート制限ルールを構成した場合、Google Cloud Armor がルール アクションを適用するまでに、各バックエンド サービスは 1 分あたり 1,000 件のリクエストを受信できます。

プレビュー モードでリクエストログを調べることで、セキュリティ ポリシーのレート制限ルールの効果をプレビューできます。

レート制限のクライアントの特定

Google Cloud Armor では、次のキータイプを使用してリクエストを集約し、レート制限を適用することで、レート制限の対象である個別のクライアントを特定します。

  • ALL: リクエストがルールの一致条件を満たすすべてのクライアントの単一キー。
  • IP: リクエストがルールの一致条件を満たすクライアントの送信元 IP アドレスごとに一意のキー。
  • HTTP_HEADER: 名前が構成された一意の HTTP ヘッダー値ごとに一意のキー。キー値は、ヘッダー値の最初の 128 バイトに切り詰められます。このようなヘッダーが存在しない場合や、外部プロキシ ネットワーク ロードバランサでこのキータイプを使用する場合、キータイプはデフォルトで ALL になります。
  • XFF_IP: クライアントのオリジナルの送信元 IP アドレス（X-Forwarded-For HTTP ヘッダーに指定された IP のリストで最初の IP アドレス）ごとに一意のキー。このようなヘッダーが存在しない場合、値が有効な IP アドレスではない場合、または外部プロキシ ネットワーク ロードバランサでこのキータイプを使用する場合、キータイプはデフォルトで IP アドレスになります。
  • HTTP_COOKIE: 名前が構成された各 HTTP Cookie 値の一意のキー。キー値は、Cookie 値の最初の 128 バイトに切り詰められます。このような Cookie が存在しない場合や、外部プロキシ ネットワーク ロードバランサでこのキータイプを使用する場合、キータイプはデフォルトで ALL になります。
  • HTTP_PATH: HTTP リクエストの URL パス。キー値は、最初の 128 バイトに切り詰められます。
  • SNI: HTTPS リクエストの TLS セッションでの Server Name Indication。キー値は、最初の 128 バイトに切り詰められます。HTTP セッションの場合、キーのタイプはデフォルトで ALL になります。
  • REGION_CODE: リクエスト送信元の国 / リージョン。
  • TLS_JA3_FINGERPRINT: JA3 TLS/SSL フィンガープリント（クライアントが HTTPS、HTTP/2、または HTTP/3 を使用して接続している場合）。利用できない場合、キーのタイプはデフォルトで ALL になります。JA3 の詳細については、ルール言語リファレンスをご覧ください。
  • USER_IP: 送信元クライアントの IP アドレス。userIpRequestHeaders で構成されたヘッダーに含まれ、値はアップストリーム プロキシによって入力されます。userIpRequestHeaders 構成がない場合、または IP アドレスを解決できない場合、キーのタイプはデフォルトで IP になります。詳細については、ルール言語リファレンスをご覧ください。

上記のキーを個別に使用することも、最大 3 つのキーの組み合わせに基づいてレート制限を適用することもできます。HTTP-HEADER または HTTP-COOKIE キーの場合は、複数のキーを使用できます。その他のキータイプの場合は、1 つだけを使用できます。詳細については、複数のキーに基づくレート制限をご覧ください。

トラフィックのスロットル調整

ルールの throttle アクションを使用すると、クライアントごとのリクエストしきい値を適用してバックエンド サービスを保護できます。このルールでは、ルールの一致条件を満たす各クライアントからのトラフィックを制限するしきい値を適用します。しきい値は、指定された時間間隔での指定されたリクエスト数として構成されます。

たとえば、1,200 秒（20 分）以内のリクエストのしきい値を 2,000 件に設定したとします。クライアントが 1,200 秒間に 2,500 件のリクエストを送信すると、許可されたリクエストの量が構成されたしきい値以下になるまで、クライアントのトラフィックの約 20% がスロットル調整されます。

クライアントのトラフィック レートが rate_limit_threshold_count 以下の場合、リクエストは conform_actionに従います（常に allow アクションになります）。リクエストは、セキュリティ ポリシーによって許可され、宛先に送信されます。クライアントのトラフィック レートが、指定された rate_limit_threshold_count を超えると、Google Cloud Armor は、残りのしきい値間隔で上限を超えるリクエストに exceed_action（deny または redirect）を適用します。

次のパラメータを設定してこのアクションを制御します。

  • rate_limit_threshold_count: 指定された時間間隔内で許可されるクライアントあたりのリクエスト数。最小値は 1、最大値は 10,000 です。
    • interval_sec: 時間間隔の秒数。値は 10、30、60、120、180、240、300、600、900、1200、1800、2700、3600 秒のいずれかにする必要があります。
  • exceed_action: リクエストが rate_limit_threshold_count を超えると、Google Cloud Armor は構成済みの exceed_action を適用します。exceed_action に有効な値は次のとおりです。
    • deny(status): リクエストが拒否され、指定されたエラーコードが返されます（有効な値は 403、404、429、502）。429 (Too Many Requests) レスポンス コードを使用することをおすすめします。
    • redirect: リクエストが、reCAPTCHA 評価にリダイレクトされるか、exceed_redirect_options パラメータに基づいて別の URL にリダイレクトされます。
  • exceed_redirect_options: exceed_action が redirect の場合、このパラメータを使用してリダイレクト アクションを指定します。
    • type: リダイレクト アクションのタイプ（GOOGLE_RECAPTCHA または EXTERNAL_302）を入力します。
    • target: リダイレクト アクションの URL ターゲット。type が EXTERNAL_302 の場合にのみ適用されます。
  • conform_action: リクエスト数が rate_limit_threshold_count を下回ったときに実行されるアクション。これは常に allow アクションになります。

リクエスト率に基づいてクライアントを禁止する

ルールで rate_based_ban アクションを使用すると、クライアントからのすべてのリクエストに対して構成済みの exceed_action を適用することで、クライアントあたりのしきい値を適用し、構成可能な期間内に上限を超えたクライアントを一時的に禁止できます。しきい値は、指定された時間間隔での指定されたリクエスト数として構成されます。トラフィックが指定した一致条件に一致し、構成済みのしきい値を超えた場合、ユーザーが構成した期間（'ban_duration_sec'）、トラフィックを一時的に禁止できます。

たとえば、1,200 秒（20 分）以内のリクエストのしきい値を 2,000 件に設定したとします。クライアントから 1,200 秒以内に 2,500 件のリクエストが送信された場合、Google Cloud Armor は 1,200 秒と禁止期間として設定した追加の秒数が経過するまで、2,000 件のリクエストしきい値を超えるトラフィックに対して exceed_action を適用します。たとえば、禁止期間を 3600 に設定すると、クライアントからのトラフィックは、しきい値間隔の終了から 3,600 秒間（1 時間）禁止されます。

クライアントのリクエスト率がレート制限のしきい値を下回っている場合、すぐにバックエンド サービスへのリクエストの転送が許可されます。クライアントのトラフィック レートが指定の rate_limit_threshold_count を超えると、Google Cloud Armor は残りのしきい値期間と追加の ban_duration_sec 秒が経過するまで、クライアントからのすべての受信リクエストに exceed_action を適用します。

この構成では、許容されるリクエスト率を偶然超えただけで問題のないクライアントが誤って禁止される可能性があります。これを回避し、リクエスト率を頻繁に超えるクライアントのみを禁止するには、ban_threshold_count という比較的長い追加のしきい値を構成して、クライアント リクエストの合計数を監視します。このモードでは、リクエスト率が構成された ban_threshold_count を超えた場合に、構成された ban_duration_sec の間、クライアントが禁止されます。リクエスト率が ban_threshold_count を超えていなければ、リクエストは rate_limit_threshold_count に抑制されます。ban_threshold_count のために、スロットル調整前のすべての受信リクエストがクライアントのリクエスト合計数にカウントされます。

次のパラメータは、rate_based_ban ルールのアクションを制御します。

  • rate_limit_threshold_count: 指定された時間間隔内で許可されるクライアントあたりのリクエスト数。最小値は 1 件のリクエスト、最大値は 10,000 件のリクエストです。
    • interval_sec: 時間間隔の秒数。値は 10、30、60、120、180、240、300、600、900、1200、1800、2700、3600 秒のいずれかにする必要があります。
  • exceed_action: リクエストが rate_limit_threshold_count を超えると、Google Cloud Armor は構成済みの exceed_action を適用します。exceed_action に有効な値は次のとおりです。
    • deny(status): リクエストが拒否され、指定されたエラーコードが返されます。エラーコードの有効な値は 403、404、429、502 です。レスポンス コード 429 (Too Many Requests) を使用することをおすすめします。
    • redirect: リクエストが、reCAPTCHA 評価にリダイレクトされるか、exceed_redirect_options パラメータに基づいて別の URL にリダイレクトされます。
  • exceed_redirect_options: exceed_action が redirect の場合、このパラメータを使用してリダイレクト アクションを指定します。
    • type: リダイレクト アクションのタイプ（GOOGLE_RECAPTCHA または EXTERNAL_302）を入力します。
    • target: リダイレクト アクションの URL ターゲット。type が EXTERNAL_302 の場合にのみ適用されます。
  • conform_action: リクエスト数が rate_limit_threshold_count を下回ったときに実行されるアクション。これは常に allow アクションになります。
  • ban_threshold_count: 特定の時間間隔内で許可されるクライアントごとのリクエスト数。超過した場合、Google Cloud Armor がリクエストを禁止します。指定すると、rate_limit_threshold_count を超えたリクエストの数がこの ban_threshold_count も超える場合、構成済みの ban_duration_sec の間、キーが禁止されます。
    • ban_threshold_interval_sec: ban_threshold_count の時間間隔の秒数。値は 10、30、60、120、180、240、300、600、900、1,200、1,800、2,700、3,600 秒のいずれかにする必要があります。
  • ban_duration_sec: interval_sec 期間の経過後にクライアントが禁止される追加の秒数です。値は 60、120、180、240、300、600、900、1200、1800、2700、3600 秒のいずれかにする必要があります。

デフォルトのレート制限のセキュリティ ポリシー

ロード バランサの作成時に、デフォルトのセキュリティ ポリシーを設定すると、デフォルトのしきい値は 1 分間隔（それぞれ rate_limit_threshold_count、interval_sec で 500、および 60）で 500 リクエストになります。別のしきい値を選択する場合は、次の手順でパラメータを調整することをおすすめします。

  1. Cloud Logging を有効にして、Google Cloud Armor で保護されたバックエンド サービスで、各 IP アドレスで 1 分間に受信する最大リクエスト数を 1 日以上クエリします。

    たとえば、受信するネットワーク トラフィックの 99% がレート制限ルールの影響を受けないとします。このシナリオでは、レート制限のしきい値を、Cloud Logging データから生成された分布について、各 IP アドレスで 1 分間に受信する最大リクエスト数の 99 パーセンタイルに設定することをおすすめします。

  2. それでもデフォルトのレート制限ルールで正規のトラフィックがブロックされる場合は、次の追加手順を検討してください。

    1. キャッシュを有効にします（Cloud CDN または Media CDN）。
    2. スロットル時間の間隔を増やします（60 秒ではなく、数分ごとにリクエストを受信）。
    3. 最初のウェーブ以降は、クライアントを禁止して攻撃に対する影響をさらに低減できます。Google Cloud Armor の rate_based_ban アクションを使用すると、ユーザーが指定した期間内で上限を超える回数が多すぎるクライアントを禁止できます。たとえば、上限を 1 分間に 10 回超えたクライアントを 15 分間禁止できます。

しきい値の適用

スロットル調整とレートベースの禁止のために構成されたしきい値は、HTTP(S) バックエンド サービスがデプロイされている Google Cloud リージョンごとに独立して適用されます。たとえば、サービスが 2 つのリージョンにデプロイされている場合、2 つのリージョンでそれぞれ構成されたしきい値に対して各キーのレート制限が適用されるため、バックエンド サービスではトラフィック量がリージョン間で集約され、構成されたしきい値の 2 倍となる可能性があります。構成されたしきい値が 5,000 リクエストに設定されている場合、バックエンド サービスは 1 つのリージョンから 5,000 件のリクエストを受信し、2 つ目のリージョンから 5,000 件のリクエストを受信する可能性があります。

ただし、キータイプの IP アドレスについては、同じクライアント IP アドレスからのトラフィックが、バックエンドがデプロイされているリージョンに最も近いリージョンに転送されると想定するのが妥当です。この場合、デプロイ先のリージョンに関係なく、バックエンド サービスレベルでレート制限が適用されると考えられます。

適用されたレート制限は概算値であり、構成されたしきい値と比べて厳密には正確でない場合があることにご注意ください。また、まれに内部ルーティング動作のために、デプロイされているリージョンよりも多くのリージョンにレート制限が適用され、精度に影響が出る可能性があります。こうした理由から、レート制限は不正使用の軽減の目的でのみ使用することをおすすめします。また、厳しい割り当てやライセンス要件を適用せずに、アプリケーションとサービスの可用性を維持することをおすすめします。

ロギング

Cloud Logging によって、セキュリティ ポリシー名、一致したレート制限のルールの優先度、ルール ID、関連するアクションなどの情報がリクエストログに記録されます。ロギングの詳細については、リクエスト ロギングの使用をご覧ください。

reCAPTCHA との統合

一部の reCAPTCHA リソースには、トークンの乱用とトークンの再利用を制限するためにレート制限を適用できます。アクション トークン、セッション トークン、除外 Cookie などのリソースが対象になります。reCAPTCHA でのレート制限の使用の詳細については、bot 管理の概要をご覧ください。

次のステップ