レート制限の概要

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

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

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

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

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

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

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

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

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

レート制限対象のクライアントを特定する

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

  • ALL: リクエストがルールの一致条件を満たすすべてのクライアントの単一キー。
  • IP: リクエストがルールの一致条件を満たすクライアント送信元 IP アドレスを表す一意のキー。
  • HTTP_HEADER: 名前が構成された一意の HTTP ヘッダー値を表す一意のキー。キー値は、ヘッダー値の最初の 128 バイトに切り詰められます。このようなヘッダーが存在しない場合や、外部プロキシ ネットワーク ロードバランサでこのキータイプを使用する場合、キータイプはデフォルトで ALL になります。
  • XFF_IP: クライアントのオリジナルの送信元 IP アドレス（HTTP ヘッダー X-Forwarded-For で指定された 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 つだけ使用できます。詳細については、複数のキーに基づくレート制限をご覧ください。

レートベースの禁止とスロットルからレート制限ルールを選択する

Google Cloud Armor のレート制限ルールである rate-based ban と throttle では、構成済みのしきい値を超えたトラフィックを処理する方法が異なります。

  • rate_based_ban: リクエストのレートが定義済みのしきい値を超えた場合に、それ以降にその送信元またはリクエストのターゲットから送信されたすべてのリクエストが、指定の期間にわたってブロックされます。
  • throttle: すべてのトラフィックがブロックされる代わりに、スロットリングによってリクエストのレートが定義済みの最大値に制限されます。一部のトラフィックは通過できますが、過負荷が生じないようにレートが制御されます。

どちらのルールが適切かは、具体的なニーズと処理するトラフィックの種類によって異なります。たとえば、DDoS 攻撃が発生している場合は、悪意のあるトラフィックを迅速にブロックするのにレートベースの禁止が適している可能性があります。一方、正当なトラフィックが急増している場合は、過負荷を防ぎながらサービスの可用性を維持するうえでスロットルが適している可能性があります。

トラフィックのスロットリング

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

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

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

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

  • rate_limit_threshold_count: 指定された時間間隔内で許可されるクライアントあたりのリクエスト数。最小値は 1、最大値は 1000000 です。
    • interval_sec: 時間間隔の秒数。値は 10、30、60、120、180、240、300、600、900、1,200、1,800、2,700、3,600 秒のいずれかにする必要があります。
  • 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、1,200、1,800、2,700、3,600 秒のいずれかにする必要があります。
  • 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: 指定の時間間隔内で許可されるクライアントごとのリクエスト数。超過するとリクエストが禁止されます。リクエスト数が 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、1200、1800、2700、3600 秒のいずれかにする必要があります。
  • ban_duration_sec: interval_sec 期間の終了後にクライアントを禁止する追加の秒数です。値は 60、120、180、240、300、600、900、1200、1800、2700、3600 秒のいずれかにする必要があります。

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

ロードバランサの作成時に、デフォルトのセキュリティ ポリシーを構成すると、デフォルトのしきい値は 1 分間隔（それぞれ 500 と 60 で rate_limit_threshold_count、interval_sec）で 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、関連するアクションなどの情報がリクエストログに記録されます。ロギングの詳細については、リクエスト ロギングの使用をご覧ください。

カスタム エラー レスポンス

Google Cloud Armor のレート制限（throttle トラフィックと rate_based_ban トラフィックを含む）にカスタム エラー レスポンスを適用して、レート制限が適用されたときにカスタムのエラー メッセージをエンドユーザーに送信できます。グローバル外部アプリケーション ロードバランサを使用する場合は、ロードバランサまたはバックエンド インスタンスで生成される特定の HTTP ステータス コード用のカスタム エラー レスポンスを構成できます。

カスタム エラー レスポンスの詳細については、カスタム エラー レスポンスの概要をご覧ください。カスタム エラー レスポンスを構成する方法については、カスタム エラー レスポンスを構成するをご覧ください。

reCAPTCHA との統合

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

次のステップ