Google Cloud Armor bot 管理の概要

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

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

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

手動チャレンジ（reCAPTCHA チャレンジページ）
- リクエストを reCAPTCHA 評価にリダイレクトするように、セキュリティポリシールールを構成する必要があります。
- reCAPTCHA WAF サイトキーを作成してセキュリティポリシーと関連付けることができます。このようにすることを強くおすすめします。詳細については、reCAPTCHA チャレンジを実装するをご覧ください。
- エンドユーザーを reCAPTCHA の評価にリダイレクトすることで、reCAPTCHA の手動チャレンジをパスしたエンドユーザーのみを許可できます。
reCAPTCHA のフリクションレスアセスメントを適用する
- reCAPTCHA が bot からのリクエストに対して行うリスク評価に基づいて、受信リクエストに異なるアクションを実行できます。トークンスコアやその他のトークン属性に基づいてトラフィックを評価し、フィルタリングするセキュリティポリシールールを作成できます。
- reCAPTCHA アクショントークンかセッショントークン、または両方を実装する必要があります。reCAPTCHA アクショントークンはウェブサイト、iOS、Android でサポートされています。reCAPTCHA セッショントークンはウェブサイトでのみサポートされています。reCAPTCHA トークンについて詳しくは、reCAPTCHA アクショントークンと reCAPTCHA セッショントークンをご覧ください。
- reCAPTCHA トークンを評価するセキュリティポリシールールを構成する必要があります。
- トークンの盗難を防ぐために、WAF 用の独自の reCAPTCHA キーをセキュリティポリシールールに関連付けることをおすすめします。

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

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

ユースケース

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

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

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

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

reCAPTCHA へのリダイレクトの例。 — reCAPTCHA へのリダイレクトの例（クリックして拡大）

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

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

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

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

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

reCAPTCHA 評価を適用する

受信リクエストに reCAPTCHA トークンが添付されている場合、Google Cloud Armor はリクエストを評価し、トークン内の個々の属性に基づいて構成済みのアクションを適用します。Google Cloud Armor セキュリティポリシーの評価は、Google のネットワークエッジで行われるため、バックエンドはトークンの復号に関与しません。

reCAPTCHA トークン

reCAPTCHA は、アクショントークンとセッショントークンの 2 種類のトークンを発行します。どちらのタイプのトークンも、サイトやアプリでの操作に基づいてリクエストごとにスコアを返します。どちらのタイプのトークンも、ユーザーに関連するリスクを表すスコアを含む属性を含みます。また、トークンが生成される際に使用された reCAPTCHA キーに関する情報が含まれています。

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

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

ウェブアプリケーション
- reCAPTCHA アクショントークンを実装する
- reCAPTCHA セッショントークンを実装する
モバイルアプリケーション
- reCAPTCHA アクショントークンを実装する

最後に、Google Cloud Armor ルール言語を使用してセキュリティポリシールールを構成し、リクエストに含まれる reCAPTCHA トークンを評価します。トークンの盗難を防止するために、reCAPTCHA キーをセキュリティポリシールールと関連付けることを強くおすすめします。Google Cloud Armor は、reCAPTCHA キーをセキュリティポリシールールと関連付ける際に、トークンの reCAPTCHA キーとルールに関連付けられている reCAPTCHA キーを比較することでトークンに対して追加の検証を実行します。Google Cloud Armor は reCAPTCHA キーを無効とみなします。詳細については、reCAPTCHA のスムーズな評価の適用をご覧ください。

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

リダイレクト（302 レスポンス）

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

リクエストのデコレート

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

カスタムヘッダー

グローバル外部アプリケーションロードバランサまたは従来のアプリケーションロードバランサのカスタムヘッダーのいずれかと同じヘッダー名でカスタムヘッダーまたは値を挿入するように Google Cloud Armor を構成している場合ロードバランサの場合、ヘッダー値はロードバランサによって上書きされます。詳細については、バックエンドサービスでのカスタムヘッダーの作成をご覧ください。

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

レート制限との統合

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

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

セキュリティ上の理由から、レート制限ルールを構成して、一意の reCAPTCHA アクショントークン、セッショントークン、または除外 Cookie の複数回の使用によるトークンの不正使用を防ぐことをおすすめします。次の表で、レート制限ルールで reCAPTCHA の除外 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 評価にリダイレクトする。

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

ルール 1: アクショントークンのスコアが事前定義のしきい値（0.8 など）よりも高い場合か、アクショントークンの使用回数が定義済みのしきい値を下回った場合にリクエストを許可する。
ルール 2: リクエストを拒否する。

reCAPTCHA アクショントークンの評価を適用します。 — reCAPTCHA アクショントークンの評価を適用する（クリックして拡大）。

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

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

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

手動チャレンジで reCAPTCHA アクショントークンの評価を適用します。 — 手動チャレンジで reCAPTCHA アクショントークンの評価を適用する（クリックして拡大）

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

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