Google Cloud Armor と reCAPTCHA は、自動クライアントから送信された可能性のあるリクエストの評価やその対処に役立つツールを提供します。
reCAPTCHA は、高度なリスク分析手法を使用して人間のユーザーと自動クライアントを区別します。reCAPTCHA は、reCAPTCHA WAF サイトキーの構成に基づいてユーザーを評価します。さらに、関連するリスクを表す属性を含む暗号化されたトークンを発行します。Cloud Armor は、このトークンをインラインで復号します。reCAPTCHA サービスに追加のリクエストを発行してレスポンスを取得することはありません。そのトークンの属性に基づいて、Cloud Armor は受信リクエストの許可、拒否、レート制限、リダイレクトを行うことができます。詳細については、Cloud Armor と reCAPTCHA のインテグレーションの概要をご覧ください。
Cloud Armor の bot 管理は、次の統合機能を備えています。
手動チャレンジ（reCAPTCHA チャレンジ ページ）
- リクエストを reCAPTCHA 評価にリダイレクトするセキュリティ ポリシー ルールを構成する必要があります。
- reCAPTCHA WAF サイトキーを作成してセキュリティ ポリシーと関連付けることができます。このようにすることを強くおすすめします。詳細については、reCAPTCHA チャレンジを実装するをご覧ください。
- エンドユーザーを reCAPTCHA 評価にリダイレクトすることで、reCAPTCHA の手動チャレンジをパスしたエンドユーザーのみを許可できます。
reCAPTCHA のフリクションレス評価を適用する
- bot からのリクエストに関する reCAPTCHA のリスク評価に基づいて、受信リクエストに異なるアクションを実行できます。トークンスコアやその他のトークン属性を基にトラフィックを評価してフィルタリングするセキュリティ ポリシー ルールを作成できます。
- reCAPTCHA アクション トークン、セッション トークン、またはその両方を実装する必要があります。reCAPTCHA アクション トークンはウェブサイト、iOS、Android でサポートされています。reCAPTCHA セッション トークンはウェブサイトでのみサポートされています。reCAPTCHA トークンについて詳しくは、reCAPTCHA アクション トークンと reCAPTCHA セッション トークンをご覧ください。
- reCAPTCHA トークンを評価するセキュリティ ポリシー ルールを構成する必要があります。
- トークンの盗難を防ぐため、WAF 用の独自の reCAPTCHA キーをセキュリティ ポリシー ルールに関連付けることをおすすめします。
Cloud Armor の bot 管理には次の機能も含まれています。
- リダイレクト（302）
- HTTP 302 レスポンスをクライアントに返すよう Cloud Armor を構成することで、代替 URL にリクエストをリダイレクトできます。
- リクエストのデコレート
- カスタム ヘッダーをリクエストに挿入し、静的ヘッダーの値をヘッダーに挿入すると、リクエストをバックエンドにプロキシ転送できます。
ユースケース
このセクションでは、Cloud Armor の bot 管理機能を使用して bot のリスクを軽減し、自動クライアントからのアクセスを制御する方法について説明します。
手動チャレンジを使用して正規のユーザーと自動クライアントを区別する
エンド クライアントを評価するために必要に応じてリクエストを reCAPTCHA にリダイレクトし、手動チャレンジを行います。他の reCAPTCHA の実装は使用しません。人間のユーザーが bot や不正なシステムと同じシグネチャ（URL パスや他の L7 シグネチャなど）を共有している場合、このアクションによってユーザーが人間であることを証明できます。評価に合格したユーザーのみがサービスにアクセスできます。
次の図では、手動確認によって、リクエストが人間によるものか、自動クライアントによるものかが区別される仕組みを示します。
ユーザー Maya と bot がどちらもウェブサイトのログインページ（/login.html）をブラウジングするとします。bot にはアクセスさせずに Maya に対してアクセスを許可するには、高度な一致式 request.path.matches("/login.html") を使用して、セキュリティ ポリシー ルールを構成します（タイプ GOOGLE_RECAPTCHA のアクション redirect を指定します）。エンドツーエンドのユーザー エクスペリエンスは次のとおりです。
- まず、エンドユーザーがウェブサイトにアクセスします。
- 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 トークンが添付されている場合、Cloud Armor はリクエストを評価し、トークン内の個々の属性に基づいて構成済みのアクションを適用します。Cloud Armor セキュリティ ポリシーの評価は Google のネットワーク エッジで行われるため、バックエンドはトークンの復号に関与しません。
reCAPTCHA トークン
reCAPTCHA は、アクション トークンとセッション トークンの 2 種類のトークンを発行します。どちらのタイプのトークンも、サイトやアプリとのインタラクションに基づいてリクエストごとにスコアを返します。どちらのタイプのトークンにも、ユーザーに関連するリスクを表すスコアなどの属性が含まれます。また、トークンの生成時に使用された reCAPTCHA キーに関する情報も含まれています。
セキュリティ ポリシー ルールを構成する前に、アクション トークン、セッション トークン、またはその両方のいずれを使用するかを決定する必要があります。決定を通知する方法については、reCAPTCHA のドキュメントをご覧ください。詳細については、reCAPTCHA のユースケースの比較をご覧ください。
使用するトークンの種類を決定したら、トークンがリクエストに添付されるように reCAPTCHA を実装します。reCAPTCHA でトークンを実装する方法については、以下のページをご覧ください。
- ウェブ アプリケーション
- モバイル アプリケーション
最後に、リクエストに添付された reCAPTCHA トークンを評価するため、Cloud Armor ルール言語を使用してセキュリティ ポリシー ルールを構成します。トークンの盗難を防ぐため、独自の reCAPTCHA キーをセキュリティ ポリシー ルールに関連付けることを強くおすすめします。reCAPTCHA キーをセキュリティ ポリシー ルールに関連付けた場合、Cloud Armor は、トークンに含まれる reCAPTCHA キーとルールに関連付けられている reCAPTCHA キーを比較することで、トークンに対する追加の検証を行います。未知の reCAPTCHA キーを含むトークンは無効とみなされます。詳細については、reCAPTCHA のフリクションレス評価を適用するをご覧ください。
次の図は、reCAPTCHA トークンの適用フローを示しています。
リダイレクト（302 レスポンス）
URL ベースのリダイレクト アクションを使用することで、リクエストを別のエンドポイントに外部からリダイレクトできます。リダイレクト先を URL の形式で指定すると、Cloud Armor は、HTTP 302 レスポンスをクライアントに返すことでリクエストをリダイレクトします。
リクエストのデコレート
Cloud Armor では、リクエストをアプリケーションにプロキシ転送する前に、ユーザー定義の静的な値を含むカスタム リクエスト ヘッダーをリクエストに挿入できます。この方法を使用すると、ハニーポットへの誘導や詳細な分析とモニタリングのような代替ダウンストリーム処理のために、疑わしいリクエストにタグを付けることができます。このアクション パラメータは、既存の allow アクションに追加する必要があります。
カスタム ヘッダー
グローバル外部アプリケーション ロードバランサまたは従来のアプリケーション ロードバランサのいずれかのカスタム ヘッダーと同じヘッダー名を持つカスタム ヘッダーまたは値を挿入するように Cloud Armor を構成すると、そのヘッダー値はロードバランサによって上書きされます。詳細については、バックエンド サービスでのカスタム ヘッダーの作成をご覧ください。
また、リクエストにすでに存在するヘッダー名（標準の HTTP ヘッダーを含む）を選択すると、そのヘッダー内の元の値が、Cloud Armor ルールで指定されたユーザー定義の値によって上書きされます。
レート制限との統合
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 のセッション トークン評価を適用できます。
3 つ目は、アクション トークンまたはセッション トークンを、サイト上で選択した URL（/login.html など）に対する手動チャレンジと組み合わせ、アクション トークンのスコアに基づいてアクションを実行する場合です。スコアが十分に満足できるものでない場合、チャレンジを解決することで、ユーザーに 2 回目の機会を提供します。これを行うには、次のようにセキュリティ ポリシーのルールを構成します。
- ルール 1: アクション トークンのスコアが事前定義のしきい値（
0.8など）より高い場合、アクション トークンの使用回数が定義済みのしきい値を超えていなければ、リクエストを許可する。 - ルール 2 と 3: アクション トークンのスコアが事前定義の別のしきい値（たとえば
0.5）より高い場合、リクエストに有効な除外 Cookie が添付されていて、除外 Cookie の使用回数が定義済みのしきい値より低い場合を除き、リクエストを reCAPTCHA 評価にリダイレクトする。 - ルール 4: リクエストを拒否する。
同様のセキュリティ ポリシー ルールを構成して、手動チャレンジで reCAPTCHA セッション トークンの評価を適用できます。
レート制限ルールを調整しない場合、reCAPTCHA 除外 Cookie、アクション トークン、セッション トークンのそれぞれに使用回数の上限は課されません。アクション トークンの場合、低いしきい値（たとえば 1）と長い時間間隔を使用することをおすすめします（たとえば、アクション トークンは 30 分間有効であるため 30 分を設定します）。トラフィック統計に基づいてしきい値を導出することをおすすめします。