レート制限の概要

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

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

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

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

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

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

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 リクエストになります。別のしきい値を選択する場合は、次の手順でパラメータを調整することをおすすめします。

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

たとえば、受信するネットワークトラフィックの 99% がレート制限ルールの影響を受けないとします。このシナリオでは、レート制限のしきい値を、Cloud Logging データから生成された分布について、各 IP アドレスで 1 分間に受信する最大リクエスト数の 99 パーセンタイルに設定することをおすすめします。
それでもデフォルトのレート制限ルールで正規のトラフィックがブロックされる場合は、次の追加手順を検討してください。
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 管理の概要をご覧ください。

次のステップ

レート制限を構成する