Google Cloud Armor bot 管理の概要

Google Cloud Armor と reCAPTCHA Enterprise は、自動クライアントから受信した可能性のあるリクエストを評価して対処する際に役立つツールを提供します。

reCAPTCHA Enterprise は、高度なリスク分析手法を使用して人間のユーザーと自動クライアントを区別します。reCAPTCHA Enterprise は、reCAPTCHA WAF サイトキーの構成に基づいてユーザーを評価します。さらに、関連するリスクを表す属性を含む暗号化されたトークンを発行します。Google Cloud Armor は、reCAPTCHA Enterprise サービスへの追加のリクエストとレスポンスを使用することなく、このトークンをインラインで復号します。Google Cloud Armor を使用すると、そのトークン属性に基づいて受信リクエストの許可、拒否、レート制限、リダイレクトを行うことができます。詳細については、Google Cloud Armor と reCAPTCHA Enterprise の統合の概要をご覧ください。

Google Cloud Armor の bot 管理は、次の統合機能を備えています。

  • 手動チャレンジ(reCAPTCHA チャレンジ ページ)
    • エンドユーザーを reCAPTCHA Enterprise の評価にリダイレクトすることで、reCAPTCHA Enterprise の手動チャレンジをパスしたエンドユーザーのみを許可できます。
    • 独自の reCAPTCHA WAF サイトキーを作成し、それをセキュリティ ポリシーに関連付けることをおすすめします。詳細については、reCAPTCHA チャレンジを実装するをご覧ください。
    • リクエストを reCAPTCHA Enterprise の評価にリダイレクトするように、セキュリティ ポリシー ルールを構成する必要があります。
  • reCAPTCHA Enterprise のフリクションレス評価を適用します。
    • reCAPTCHA Enterprise が bot からのリクエストに対して行うリスク評価に基づいて、受信リクエストに異なるアクションを実行できます。トークンスコアやその他のトークン属性に基づいてトラフィックを評価し、フィルタリングするセキュリティ ポリシー ルールを作成できます。
    • Google Cloud Armor セキュリティ ポリシーの評価は、Google のネットワーク エッジで行われるため、バックエンドはトークンの復号に関与しません。
    • reCAPTCHA Enterprise を実装する前に、reCAPTCHA Enterprise アクション トークンを使用するか、セッション トークンを使用するかを選択して、独自の reCAPTCHA WAF サイトキーを作成する必要があります。詳細については、reCAPTCHA アクション トークンの実装reCAPTCHA セッション トークンの実装をご覧ください。
    • reCAPTCHA Enterprise トークンを評価するセキュリティ ポリシー ルールを構成する必要があります。

Google Cloud Armor bot の管理には次の機能も含まれています。

  • リダイレクト(302)
    • HTTP 302 レスポンスをクライアントに提供するように Google Cloud Armor を構成することで、構成済みの代替 URL にリクエストをリダイレクトできます。
  • リクエストのデコレート
    • カスタム ヘッダーをリクエストに挿入し、静的ヘッダーの値をヘッダーに挿入すると、リクエストをバックエンドにプロキシ転送できます。

ユースケース

このセクションでは、Google Cloud Armor の bot 管理機能を使用して、bot のリスクを軽減し、自動クライアントからのアクセスを制御する方法について説明します。

手動確認を使用して正規のユーザーと自動クライアントを区別する

リクエストを必要に応じて reCAPTCHA Enterprise にリダイレクトしてユーザーを評価し、手動確認を行います。他の reCAPTCHA Enterprise の実装は使用しません。人のユーザーが bot や不正なシステムと同じ署名(URL パスや他の L7 署名など)を共有する場合、この動作により、人間であることを証明できます。評価に合格したユーザーのみがサービスにアクセスできます。

次の図では、手動確認によって、リクエストが人間によるものか、自動クライアントによるものかが区別される仕組みを示します。

reCAPTCHA へのリダイレクトの例。
reCAPTCHA へのリダイレクトの例(クリックして拡大)

ユーザー Maya と bot は、どちらもサイトのログインページ(/login.html)をブラウジングするとします。bot にはアクセスさせずに Maya に対してアクセスを許可するには、高度な一致式 request.path.matches("/login.html") を使用して、セキュリティ ポリシー ルールを構成します(タイプ GOOGLE_RECAPTCHA のアクション redirect を指定します)。エンドツーエンドのユーザー エクスペリエンスは次のとおりです。

  1. まず、エンドユーザーがウェブサイトにアクセスします。
  2. Google Cloud Armor がリクエストを評価し、reCAPTCHA Enterprise にリダイレクトするかどうかを判断します。
  3. reCAPTCHA Enterprise は、reCAPTCHA Enterprise の JavaScript が埋め込まれた HTML ページを返します。
  4. そのレスポンスが表示されると、埋め込みの JavaScript が実行され、ユーザーが評価されます。さらに、必要に応じて手動チャレンジが行われます。
    • ユーザーが評価に合格すると、reCAPTCHA Enterprise が除外 Cookie を発行します。この Cookie は、期限切れになるまで、同じサイトに対する後続の各リクエストで自動的に使用されます。
    • それ以外の場合、reCAPTCHA Enterprise は除外 Cookie を発行しません。

この例では、Maya のみが reCAPTCHA Enterprise の評価に合格し、除外 Cookie を受け取ってサイトにアクセスします。

手動確認を行う場合は、独自の reCAPTCHA WAF サイトキーを作成し、セキュリティ ポリシーに関連付けることをおすすめします。これにより、サイトキーに関連付けられている reCAPTCHA Enterprise の指標を表示し、サイトキーに固有のセキュリティ モデルをトレーニングできます。詳細については、reCAPTCHA WAF チャレンジ サイトキーを作成するをご覧ください。

サイトキーを作成して関連付けない場合、reCAPTCHA Enterprise は評価中に Google が管理するサイトキーを使用します。Google が管理するサイトキーなど、自分が所有していないサイトキーに関連付けられている reCAPTCHA 指標を表示することはできません。

reCAPTCHA Enterprise の評価を適用する

受信リクエストに reCAPTCHA Enterprise トークンが添付されている場合、Google Cloud Armor はリクエストを評価し、トークン内の個々の属性に基づいて構成済みのアクションを適用します。

reCAPTCHA Enterprise トークン

reCAPTCHA Enterprise は、アクション トークンとセッション トークンの 2 種類のトークンを発行します。どちらのタイプのトークンも、サイトでの操作に基づいてリクエストごとにスコアを返します。どちらのタイプのトークンにも、ユーザーに関連するリスクを示すスコアなどの属性が含まれています。

セキュリティ ポリシー ルールを構成する前に、アクション トークン、セッション トークン、またはその両方を使用するかどうかを判断する必要があります。決定を通知する方法については、reCAPTCHA Enterprise のドキュメントをご覧ください。詳細については、reCAPTCHA Enterprise のユースケースの比較をご覧ください。

使用するトークンの種類を決定したら、トークンをリクエストに関連付けて reCAPTCHA Enterprise を実装します。reCAPTCHA Enterprise でトークンを実装する方法については、reCAPTCHA Enterprise アクション トークンの実装reCAPTCHA Enterprise セッション トークンの実装をご覧ください。

最後に、Google Cloud Armor ルール言語を使用してセキュリティ ポリシー ルールを構成し、リクエストに含まれる reCAPTCHA Enterprise トークンを評価します。

次の図では、reCAPTCHA Enterprise トークンの適用フローを示します。

reCAPTCHA トークンの適用フロー。
reCAPTCHA トークンの適用フロー(クリックして拡大)

リダイレクト(302 レスポンス)

URL ベースのリダイレクト アクションを使用することで、リクエストを別のエンドポイントに外部からリダイレクトできます。リダイレクト ターゲットを URL の形式で指定すると、リクエストは、Google Cloud Armor によって HTTP 302 レスポンスとしてクライアントにリダイレクトされます。

リクエストのデコレート

Google Cloud Armor では、ユーザー定義の値を含むカスタム リクエスト ヘッダーをリクエストに挿入して、アプリケーションにプロキシ転送を行うことができます。このオプションを使用すると、ハニーポットの提供やさらに詳しい分析やモニタリングなど、代替ダウンストリーム処理で疑わしいリクエストにタグを付けることができます。このアクション パラメータは、既存の allow アクションに追加する必要があります。

また、リクエストにすでに存在するヘッダー名(標準の HTTP ヘッダーを含む)を選択すると、そのヘッダー内の元の値が、Google Cloud Armor ルールで指定されたユーザー定義の値によって上書きされます。

レート制限との統合

Google Cloud Armor のレート制限ルールは bot 管理機能と互換性があります。たとえば、reCAPTCHA Enterprise の評価リクエストをリダイレクトできます。また、リクエスト数が構成済みのしきい値を超えた場合は、別の URL にリダイレクトすることもできます。さらに、reCAPTCHA Enterprise の除外 Cookie またはトークンに基づいてレート制限を行うクライアントを特定し、ユーザーが構成したしきい値のレートを超えたときにリクエストを抑制したり、同じ Cookie やトークンを再利用または不正使用するクライアントを禁止できます。

reCAPTCHA Enterprise 除外 Cookie またはトークンをレート制限する

セキュリティ上の理由から、レート制限ルールを構成して、一意の reCAPTCHA アクション トークン、セッション トークン、または除外 Cookie の複数回の使用によるトークンの不正使用を防ぐことをおすすめします。次の表で、レート制限ルールで reCAPTCHA Enterprise 除外 Cookie またはトークンをキーとして識別する方法を示します。

リソース enforce_on_key enforce_on_key_name
除外 Cookie HTTP-COOKIE recaptcha-ca-e
アクション トークン HTTP-HEADER X-Recaptcha-Token
セッション トークン HTTP-COOKIE recaptcha-ca-t

同じ除外 Cookie またはトークンに依存し、構成されたしきい値を超えるクライアントのリクエストを調整または禁止できます。レート制限パラメータの詳細については、レート制限の適用をご覧ください。

レート制限の例

まず、サイト上の特定の URL(/login.html など)でのみ手動チャレンジを使用します。これを行うには、次のようにセキュリティ ポリシーのルールを構成します。

  • ルール 1: リクエストに有効な除外 Cookie が関連付けられていて、除外 Cookie の使用数が定義されたしきい値を下回っている場合は、リクエストを許可する。
  • ルール 2: reCAPTCHA Enterprise 評価のリクエストをリダイレクトする。
reCAPTCHA Enterprise のリダイレクトの例。
手動チャレンジの実施(クリックして拡大)

次に、アクション トークンやセッション トークンのみを使用します。たとえば、アクション トークンを使用して、/login.html などの重要なユーザー アクションを保護できます。これを行うには、次のようにアクション トークンのスコアに基づいてアクションを実行します。

  • ルール 1: アクション トークンのスコアが事前定義のしきい値(0.8 など)よりも高い場合か、アクション トークンの使用回数が定義済みのしきい値を下回った場合にリクエストを許可する。
  • ルール 2: リクエストを拒否する。
reCAPTCHA Enterprise のアクションの例。
reCAPTCHA Enterprise アクション トークン評価の適用(クリックして拡大)

同様のセキュリティ ポリシー ルールを構成して、reCAPTCHA Enterprise のセッション トークン評価を適用できます。

3 つ目は、アクション トークンまたはセッション トークンを、サイト上で選択した URL(/login.html など)に対する手動チャレンジと組み合わせ、アクション トークンのスコアに基づいてアクションを実行する場合です。スコアが十分に満足できるものでない場合、チャレンジを解決することで、ユーザーに 2 回目の機会を提供します。これを行うには、次のようにセキュリティ ポリシーのルールを構成します。

  • ルール 1: アクション トークンのスコアが事前定義のしきい値(0.8 など)よりも高い場合か、アクション トークンの使用回数が定義済みのしきい値を下回った場合にリクエストを許可する。
  • ルール 2 と 3: アクション トークンのスコアが事前定義の別のしきい値(たとえば 0.5)よりも高く、リクエストに有効な除外 Cookie がないか、除外 Cookie が定義されたしきい値より低くない場合は、reCAPTCHA Enterprise 評価のリクエストと使用回数をリダイレクトする。
  • ルール 4: リクエストを拒否する。
reCAPTCHA Enterprise のアクションとリダイレクトの例。
手動チャレンジで reCAPTCHA Enterprise アクション トークンの評価を適用する(クリックして拡大)

同様のセキュリティ ポリシー ルールを構成して、手動チャレンジで reCAPTCHA Enterprise セッション トークンの評価を適用できます。

上記のようにレート制限ルールを構成しない場合、Google Cloud Armor は、reCAPTCHA 除外 Cookie、アクション トークン、セッション トークンごとの使用数に上限を設けません。アクション トークンの場合、低いしきい値(たとえば 1)と長い時間間隔を使用することをおすすめします(たとえば、アクション トークンは 30 分間有効であるため 30 分を設定します)。トラフィック統計に基づいてしきい値を導き出すことをおすすめします。

制限事項

  • Google Cloud Armor の bot 管理は、グローバル外部 HTTP(S) ロードバランサ(プレビュー)モードのオペレーションをサポートしていません。bot 管理に HTTP(S) ロードバランサを構成するには、グローバル外部 HTTP(S) ロードバランサ(従来のバージョン)を使用します。詳細については、オペレーションのモードをご覧ください。

次のステップ