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 署名など）を共有する場合、この動作により、人間であることを証明できます。評価に合格したユーザーのみがサービスにアクセスできます。
次の図では、手動チャレンジによって、リクエストが人間によるものか、自動クライアントによるものかが区別される仕組みを示します。
ユーザー 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 でトークンを実装する方法については、次のページをご覧ください。
- ウェブ アプリケーション
- モバイル アプリケーション
最後に、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 |
| Action-token | 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 セッション トークンの評価を適用できます。
レート制限ルールを調整しない場合、Google Cloud Armor は、reCAPTCHA 除外 Cookie、アクション トークン、セッション トークンごとの使用数に上限を設けません。アクション トークンの場合、低いしきい値（たとえば 1）と長い時間間隔を使用することをおすすめします（たとえば、アクション トークンは 30 分間有効であるため 30 分を設定します）。トラフィック統計に基づいてしきい値を導出することをおすすめします。