1. はじめに
Google Cloud HTTP(S) ロード バランシングは、世界中の Google の接続拠点(POP)で Google ネットワークのエッジにデプロイされています。HTTP(S) ロードバランサを送信先とするユーザー トラフィックは、ユーザーに最も近い POP に入った後、Google のグローバル ネットワークで負荷分散されて、十分な容量がある最も近いバックエンドに送られます。
Cloud Armor は、Google が提供する分散型サービス拒否攻撃およびウェブ アプリケーション ファイアウォール(WAF)検出システムです。Cloud Armor は Google Cloud HTTP ロードバランサと緊密に連携し、Google Cloud のお客様のアプリケーションをインターネットからの攻撃から保護します。reCAPTCHA Enterprise は、スパムや不正行為からサイトを保護するサービスです。既存の reCAPTCHA API をベースに、高度なリスク分析手法を使用して人間と bot を区別します。Cloud Armor の bot 管理は、reCAPTCHA Enterprise の bot 検出とスコアリングと、ネットワークのエッジで Cloud Armor による適用を統合したエンドツーエンドのソリューションを提供し、ダウンストリーム アプリケーションを保護します。
次の図に示すように、このラボではバックエンドを使用する HTTP ロードバランサを構成します。次に、reCAPTCHA セッション トークンのサイトキーを設定してウェブサイトに埋め込む方法について学習します。また、reCAPTCHA Enterprise の手動確認へのリダイレクトを設定する方法についても説明します。その後、Cloud Armor の bot 管理ポリシーを構成して、bot 検出によって悪意のある bot トラフィックからアプリケーションを保護する仕組みを紹介します。
学習内容
- 適切なヘルスチェックを使用して HTTP ロードバランサを設定する方法。
- reCAPTCHA WAF チャレンジ ページのサイトキーを作成し、Cloud Armor セキュリティ ポリシーに関連付ける方法。
- reCAPTCHA セッション トークンのサイトキーを作成し、ウェブページにインストールする方法。
- Cloud Armor bot 管理ポリシーの作成方法
- 構成されたルールに基づいて bot 管理ポリシーがトラフィックを処理していることを確認する方法。
必要なもの
- ネットワーキングの基礎と HTTP の知識
- Unix / Linux コマンドラインに関する基本的な知識
2. 設定と要件
セルフペース型の環境設定
- Google Cloud Console にログインして、プロジェクトを新規作成するか、既存のプロジェクトを再利用します。Gmail アカウントも Google Workspace アカウントもまだお持ちでない場合は、アカウントを作成してください。
- プロジェクト名は、このプロジェクトの参加者に表示される名称です。Google API では使用されない文字列で、いつでも更新できます。
- プロジェクト ID は、すべての Google Cloud プロジェクトにおいて一意でなければならず、不変です(設定後は変更できません)。Cloud Console により一意の文字列が自動生成されます(通常は内容を意識する必要はありません)。ほとんどの Codelab では、プロジェクト ID を参照する必要があります(通常、プロジェクト ID は「
PROJECT_ID
」の形式です)。好みの文字列でない場合は、別のランダムな ID を生成するか、独自の ID を試用して利用可能であるかどうかを確認することができます。プロジェクトの作成後、ID は「フリーズ」されます。 - 3 つ目の値として、一部の API が使用するプロジェクト番号があります。これら 3 つの値について詳しくは、こちらのドキュメントをご覧ください。
- 次に、Cloud のリソースや API を使用するために、Cloud Console で課金を有効にする必要があります。この Codelab の操作をすべて行って、費用が生じたとしても、少額です。このチュートリアルを終了した後に課金が発生しないようにリソースをシャットダウンするには、Codelab の最後にある「クリーンアップ」の手順を行います。Google Cloud の新規ユーザーは、300 米ドル分の無料トライアル プログラムをご利用いただけます。
Cloud Shell の起動
Google Cloud はノートパソコンからリモートで操作できますが、この Codelab では、Google Cloud Shell(Cloud 上で動作するコマンドライン環境)を使用します。
GCP Console で右上のツールバーにある Cloud Shell アイコンをクリックします。
プロビジョニングと環境への接続にはそれほど時間はかかりません。完了すると、次のように表示されます。
この仮想マシンには、必要な開発ツールがすべて用意されています。永続的なホーム ディレクトリが 5 GB 用意されており、Google Cloud で稼働します。そのため、ネットワークのパフォーマンスと認証機能が大幅に向上しています。このラボでの作業はすべて、ブラウザから実行できます。
始める前に
Cloud Shell 内で、プロジェクト ID が設定されていることを確認します。
gcloud config list project gcloud config set project [YOUR-PROJECT-NAME] PROJECT_ID=[YOUR-PROJECT-NAME] echo $PROJECT_ID
API を有効にする
必要なサービスをすべて有効にする
gcloud services enable compute.googleapis.com gcloud services enable logging.googleapis.com gcloud services enable monitoring.googleapis.com gcloud services enable recaptchaenterprise.googleapis.com
3. バックエンドへの HTTP / SSH トラフィックを許可するファイアウォール ルールを構成する
Google Cloud ヘルスチェックとロードバランサからバックエンドへの HTTP トラフィックを許可するように、ファイアウォール ルールを構成します。また、インスタンスへの SSH 接続を許可するファイアウォール ルールを構成します。
プロジェクトで作成された default VPC ネットワークを使用します。バックエンドへの HTTP トラフィックを許可するファイアウォール ルールを作成します。ヘルスチェックでは、ロードバランサのどのインスタンスが新しい接続を受け取れるかを確認します。HTTP ロード バランシングの場合、ロード バランシング インスタンスへのヘルスチェック プローブは、130.211.0.0/22 と 35.191.0.0/16 の範囲のアドレスから送信されます。VPC ファイアウォール ルールで、これらの接続を許可する必要があります。また、これらのロードバランサは同じ IP 範囲のバックエンドと通信します。
- Cloud コンソールで、ナビゲーション メニュー()>VPC ネットワーク >ファイアウォール。
- ICMP、内部、RDP、SSH のファイアウォール ルールがすでに存在します。Google Cloud プロジェクトには、それぞれ default ネットワークとこれらのファイアウォール ルールがあります。
- [ファイアウォール ルールを作成] をクリックします。
- 以下の値を設定し、他はすべてデフォルト値のままにします。
プロパティ | 値(値を入力するか、指定されたオプションを選択) |
名前 | default-allow-health-check |
ネットワーク | default |
ターゲット | 指定されたターゲットタグ |
ターゲットタグ | allow-health-check |
ソースフィルタ | IP 範囲 |
ソース IP の範囲 | 130.211.0.0/22、35.191.0.0/16 |
プロトコルとポート | [指定したプロトコルとポート] と [TCP] のチェックボックスをオンにするポート番号に「80」と入力します |
- [作成] をクリックします。
または、gcloud コマンドラインを使用する場合。コマンドは以下のとおりです。
gcloud compute firewall-rules create default-allow-health-check --direction=INGRESS --priority=1000 --network=default --action=ALLOW --rules=tcp:80 --source-ranges=130.211.0.0/22,35.191.0.0/16 --target-tags=allow-health-check
- 同様に、インスタンスへの SSH 接続を許可するファイアウォール ルールを作成します。
gcloud compute firewall-rules create allow-ssh --direction=INGRESS --priority=1000 --network=default --action=ALLOW --rules=tcp:22 --source-ranges=0.0.0.0/0 --target-tags=allow-health-check
4. インスタンス テンプレートを構成し、マネージド インスタンス グループを作成する
マネージド インスタンス グループは、インスタンス テンプレートを使用して同一インスタンスのグループを作成します。これらを使用して、HTTP ロードバランサのバックエンドを作成します。
インスタンス テンプレートを構成する
インスタンス テンプレートは、VM インスタンスとマネージド インスタンス グループの作成に使用するリソースです。インスタンス テンプレートが、マシンタイプ、ブートディスク イメージ、サブネット、ラベル、その他のインスタンス プロパティを定義します。次のようにインスタンス テンプレートを作成します。
- Cloud コンソールで、ナビゲーション メニュー()>Compute Engine >[インスタンス テンプレート] をクリックし、[インスタンス テンプレートを作成] をクリックします。
- [名前] に「lb-backend-template」と入力します。
- [シリーズ] で [N1] を選択します。
- [ネットワーキング、ディスク、セキュリティ、管理、単一テナンシー] をクリックします。
- [管理] セクションに移動し、[起動スクリプト] フィールドに次のスクリプトを挿入します。
#! /bin/bash sudo apt-get update sudo apt-get install apache2 -y sudo a2ensite default-ssl sudo a2enmod ssl sudo vm_hostname="$(curl -H "Metadata-Flavor:Google" \ http://169.254.169.254/computeMetadata/v1/instance/name)" sudo echo "Page served from: $vm_hostname" | \ tee /var/www/html/index.html
- [ネットワーキング] タブをクリックし、ネットワーク タグ allow-health-check を追加します。
- 以下の値を設定し、他はすべてデフォルト値のままにします。
プロパティ | 値(値を入力するか、指定されたオプションを選択) |
ネットワーク([ネットワーク インターフェース] の下) | デフォルト |
サブネット(ネットワーク インターフェースの下) | default (us-east1) |
ネットワーク タグ | allow-health-check |
- [作成] をクリックします。
- インスタンス テンプレートの作成が完了するまで待ちます。
マネージド インスタンス グループを作成する
- 引き続き [Compute Engine] ページで、左側のメニューの [インスタンス グループ] をクリックします。
- [インスタンス グループを作成] をクリックします。[新しいマネージド インスタンス グループ(ステートレス)] を選択します。
- 以下の値を設定し、他はすべてデフォルト値のままにします。
プロパティ | 値(値を入力するか、指定されたオプションを選択) |
名前 | lb-backend-example |
場所 | シングルゾーン |
地域 | us-east1 |
ゾーン | us-east1-b |
インスタンス テンプレート | lb-backend-template |
自動スケーリング | 自動スケーリングしない |
インスタンス数 | 1 |
- [作成] をクリックします。
インスタンス グループに名前付きポートを追加する
インスタンス グループに HTTP サービスを定義し、ポート名を該当するポートにマッピングします。ロード バランシング サービスは名前付きポートにトラフィックを転送します。
gcloud compute instance-groups set-named-ports lb-backend-example \ --named-ports http:80 \ --zone us-east1-b
5. HTTP ロードバランサを構成する
バックエンド lb-backend-example: にトラフィックを送信するように HTTP ロードバランサを構成します。
構成を開始する
- Cloud コンソールで、ナビゲーション メニュー()> [[ネットワーク サービス] >[ロード バランシング] をクリックし、[ロードバランサを作成] をクリックします。
- [HTTP(S) ロード バランシング] で [構成を開始] をクリックします。
- [インターネットから自分の VM へ]、[従来の HTTP(S) ロードバランサ] を選択し、[続行] をクリックします。
- [名前] を http-lb に設定します。
バックエンドを構成する
バックエンド サービスによって、受信トラフィックが、接続されている 1 つ以上のバックエンドに振り向けられます。各バックエンドは、1 つのインスタンス グループと、追加の提供容量メタデータで構成されます。
- [バックエンドの構成] をクリックします。
- [バックエンド サービスとバックエンド バケット] で、[バックエンド サービスを作成] をクリックします。
- 以下の値を設定し、他はすべてデフォルト値のままにします。
プロパティ | 値(指定されたオプションを選択) |
名前 | http-backend |
プロトコル | HTTP |
名前付きポート | htp |
インスタンス グループ | lb-backend-example |
ポート番号 | 80 |
- [完了] をクリックします。
- [バックエンドを追加] をクリックします。
- [ヘルスチェック] で [ヘルスチェックを作成] を選択します。
- 以下の値を設定し、他はすべてデフォルト値のままにします。
プロパティ | 値(指定されたオプションを選択) |
名前 | http-health-check |
プロトコル | TCP |
ポート | 80 |
- [保存] をクリックします。
- [ロギングを有効にする] チェックボックスをオンにします。
- [サンプルレート] を 1 に設定します。
- [作成] をクリックすると、バックエンド サービスが作成されます。
フロントエンドを構成する
ホストとパスのルールによって、トラフィックの転送方法が決定されます。たとえば、動画のトラフィックと静的トラフィックをそれぞれ異なるバックエンドに転送できます。ただし、このラボではホストとパスのルールは構成しません。
- [フロントエンドの構成] をクリックします。
- 以下の値を設定し、他はすべてデフォルト値のままにします。
プロパティ | 値(値を入力するか、指定されたオプションを選択) |
プロトコル | HTTP |
IP バージョン | IPv4 |
IP アドレス | エフェメラル |
ポート | 80 |
- [完了] をクリックします。
HTTP ロードバランサを確認して作成する
- [確認と完了] をクリックします。
- [バックエンド サービス] と [フロントエンド] を確認します。
- [作成] をクリックします。
- ロードバランサの作成が完了するまで待ちます。
- ロードバランサの名前(http-lb)をクリックします。
- ロードバランサの IPv4 アドレスをメモしておきます(次のタスクで使用します)。ここでは [LB_IP_v4] と呼びます。
6. HTTP ロードバランサをテストする
バックエンド用の HTTP ロードバランサを作成できたので、トラフィックがバックエンド サービスに転送されることを確認します。HTTP ロードバランサへの IPv4 アクセスをテストするには、ブラウザで新しいタブを開いて http://[LB_IP_v4] に移動します。[LB_IP_v4] はロードバランサの IPv4 アドレスに置き換えてください。
7. reCAPTCHA セッション トークンとチャレンジページのサイトキーを作成してデプロイする
WAF 用の reCAPTCHA Enterprise と Google Cloud Armor の統合には、reCAPTCHA チャレンジ ページ、reCAPTCHA アクション トークン、reCAPTCHA セッション トークンという機能があります。この Codelab では、reCATCHA セッション トークンのサイトキーと reCAPTCHA WAF チャレンジ ページ サイトを実装します。
reCAPTCHA セッション トークンと WAF チャレンジページのサイトキーを作成する
セッション トークンのサイトキーとチャレンジ ページのサイトキーを作成する前に、[API を有効にする] に表示されているように reCAPTCHA Enterprise API が有効になっていることを再度確認してください。見てみましょう。
reCAPTCHA JavaScript は、評価後にエンドユーザーのブラウザに reCAPTCHA セッション トークンを Cookie として設定します。エンドユーザーのブラウザが Cookie を添付し、reCAPTCHA JavaScript がアクティブである限り Cookie を更新します。
- reCAPTCHA セッション トークンのサイトキーを作成し、そのキーの WAF 機能を有効にします。また、WAF サービスを Cloud Armor に設定し、Cloud Armor の統合を有効にします。
gcloud recaptcha keys create --display-name=test-key-name \ --web --allow-all-domains --integration-type=score --testing-score=0.5 \ --waf-feature=session-token --waf-service=ca
- 上記のコマンドの出力に、作成された鍵が表示されます。次のステップでウェブサイトに追加するため、メモしておいてください。
- reCAPTCHA WAF チャレンジ ページのサイトキーを作成し、そのキーで WAF 機能を有効にします。reCAPTCHA 確認ページ機能を使用すると、受信したリクエストを reCAPTCHA Enterprise にリダイレクトして、各リクエストが不正なものか正当なものかを判断できます。後でこのキーを Cloud Armor セキュリティ ポリシーに関連付けて、手動チャレンジを有効にします。このキーは、後のステップでチャレンジ ページキーと呼びます。
gcloud recaptcha keys create --display-name=challenge-page-key \ --web --allow-all-domains --integration-type=INVISIBLE \ --waf-feature=challenge-page --waf-service=ca
- ナビゲーション メニュー()>セキュリティ >reCAPTCHA Enterprise。[Enterprise Keys] に作成したキーが表示されます。
reCAPTCHA セッション トークンのサイトキーを実装する
- ナビゲーション メニュー()>Compute Engine >VM インスタンス。インスタンス グループで VM を見つけて、SSH で接続します。
- ウェブサーバーのルート ディレクトリに移動し、ユーザーを root に変更します。
@lb-backend-example-4wmn:~$ cd /var/www/html/ @lb-backend-example-4wmn:/var/www/html$ sudo su
- ランディングの index.html ページを更新し、reCAPTCHA セッション トークンのサイトキーを埋め込みます。セッション トークンのサイトキーは、ランディング ページの head セクションで次のように設定されています。
<script src="https://www.google.com/recaptcha/enterprise.js?render=<REPLACE_TOKEN_HERE>&waf=session"async defer></script>
以下に示すように、index.html ファイルを更新する前に必ずトークンを置き換えてください。
root@lb-backend-example-4wmn:/var/www/html# echo '<!doctype html><html><head><title>ReCAPTCHA Session Token</title><script src="https://www.google.com/recaptcha/enterprise.js?render=<REPLACE_TOKEN_HERE>&waf=session" async defer></script></head><body><h1>Main Page</h1><p><a href="/good-score.html">Visit allowed link</a></p><p><a href="/bad-score.html">Visit blocked link</a></p><p><a href="/median-score.html">Visit redirect link</a></p></body></html>' > index.html
- bot 管理ポリシーをテストするために、他にも 3 つのサンプルページを作成します。
- good-score.html:
root@lb-backend-example-4wmn:/var/www/html# echo '<!DOCTYPE html><html><head><meta http-equiv="Content-Type" content="text/html; charset=windows-1252"></head><body><h1>Congrats! You have a good score!!</h1></body></html>' > good-score.html
- bad-score.html
root@lb-backend-example-4wmn:/var/www/html# echo '<!DOCTYPE html><html><head><meta http-equiv="Content-Type" content="text/html; charset=windows-1252"></head><body><h1>Sorry, You have a bad score!</h1></body></html>' > bad-score.html
- median-score.html(英語)
root@lb-backend-example-4wmn:/var/www/html# echo '<!DOCTYPE html><html><head><meta http-equiv="Content-Type" content="text/html; charset=windows-1252"></head><body><h1>You have a median score that we need a second verification.</h1></body></html>' > median-score.html
- ブラウザでウェブページを開いて、すべてのウェブページにアクセスできることを確認します。[LB_IP_v4] はロードバランサの IPv4 アドレスに置き換えてください。
- http://[LB_IP_v4]/index.html を開きます。「reCAPTCHA で保護されています」と表示されたら、reCAPTCHA の実装が機能していることを確認できます。をクリックします。
- 各リンクをクリックします。
- すべてのページにアクセスできることを確認します。
8. bot 管理用の Cloud Armor セキュリティ ポリシー ルールを作成する
このセクションでは、Cloud Armor の bot 管理ルールを使用して、reCAPTCHA スコアに基づいてリクエストを許可、拒否、リダイレクトします。セッション トークンのサイトキーを作成したときに、テストスコアを 0.5 に設定したことを思い出してください。
- Cloud Shell で(Cloud Shell の使用方法については、「設定と要件」の「Cloud Shell の起動」を参照)、gcloud を使用してセキュリティ ポリシーを作成します。
gcloud compute security-policies create recaptcha-policy \ --description "policy for bot management"
- reCAPTCHA Enterprise の手動チャレンジを使用して、人間と自動クライアントを区別するには、手動チャレンジ用に作成した reCAPTCHA WAF チャレンジ サイトキーをセキュリティ ポリシーに関連付けます。「チャレンジページキー」を置き換える渡されます。
gcloud compute security-policies update recaptcha-policy \ --recaptcha-redirect-site-key "CHALLENGE-PAGE-KEY"
- bot 管理ルールを追加して、URL パスが Good-score.html と一致し、スコアが 0.4 より大きい場合にトラフィックを許可する。
gcloud compute security-policies rules create 2000 \ --security-policy recaptcha-policy\ --expression "request.path.matches('good-score.html') && token.recaptcha_session.score > 0.4"\ --action allow
- bot 管理ルールを追加して、URL パスが bad-score.html と一致し、スコアが 0.6 未満の場合にトラフィックを拒否する。
gcloud compute security-policies rules create 3000 \ --security-policy recaptcha-policy\ --expression "request.path.matches('bad-score.html') && token.recaptcha_session.score < 0.6"\ --action "deny-403"
- URL パスが median-score.html と一致し、スコアが 0.5 の場合にトラフィックを Google reCAPTCHA にリダイレクトする bot 管理ルールを追加
gcloud compute security-policies rules create 1000 \ --security-policy recaptcha-policy\ --expression "request.path.matches('median-score.html') && token.recaptcha_session.score == 0.5"\ --action redirect \ --redirect-type google-recaptcha
- セキュリティ ポリシーをバックエンド サービスの http-backend に接続します。
gcloud compute backend-services update http-backend \ --security-policy recaptcha-policy –-global
- コンソールで、ナビゲーション メニュー >ネットワーク セキュリティ >Cloud Armor。
- [reCAPTCHA] をクリックします。ポリシーが次のようになります。
9. Cloud Armor で bot 管理を検証する
- ブラウザを開き、URL に「http://[LB_IP_v4]/index.html」と入力します。[許可リンクにアクセス] に移動します。許可対象は以下の通りです。
- 新しいウィンドウをシークレット モードで開いて、新しいセッションであることを確認します。URL に「http://[LB_IP_v4]/index.html」と入力し、[ブロックされたリンクにアクセス] に移動します。HTTP 403 エラーが返されます。
- 新しいウィンドウをシークレット モードで開いて、新しいセッションであることを確認します。URL に「http://[LB_IP_v4]/index.html」と入力し、[リダイレクト リンクにアクセス] に移動します。以下のように、Google reCAPTCHA へのリダイレクトと手動確認ページが表示されます。
Cloud Armor ログを確認する
セキュリティ ポリシーのログを調べて、bot 管理が想定どおりに機能していることを確認する。
- Console で、ナビゲーション メニュー > [ネットワーク セキュリティ] > [Cloud Armor] に移動します。
- [recaptcha-policy] をクリックします。
- [ログ] をクリックします。
- [ポリシーログを表示] をクリックします。
- 以下は MQL(モニタリング クエリ言語)クエリです。コピーしてクエリエディタに貼り付けることができます。
resource.type:(http_load_balancer) AND jsonPayload.enforcedSecurityPolicy.name:(recaptcha-policy)
- [クエリを実行] をクリックします。
- [クエリ結果] で、リクエストが http://[LB_IP_v4]/good-score.html に対するログエントリを探します。jsonPayload.ExpandEnforceSecurityPolicy を展開します。
- http://[LB_IP_v4]/bad-score.html と http://[LB_IP_v4]/median-score.html についても同じ手順を繰り返します。
ConfigureAction が ALLOW、DENY、または GOOGLE_RECAPTCHA に設定されており、名前が recaptcha-policy になっています。
これで完了です。Cloud Armor による bot 管理に関するラボはこれで完了です。
©2020 Google LLC All rights reserved.Google および Google のロゴは、Google LLC の商標です。その他すべての社名および製品名は、それぞれ該当する企業の商標である可能性があります。
10. ラボのクリーンアップ
- [ネットワーク セキュリティ >>Cloud Armor >>%POLICY NAME%」と入力し、[削除] を選択します。
- [ネットワーキング >>ネットワーク サービス >>ロード バランシング。作成したロードバランサを選択し、[削除] をクリックします。
削除する追加リソースとしてバックエンド サービスとヘルスチェックを選択します。
- ナビゲーション メニュー()>Compute Engine >インスタンス グループ。マネージド インスタンス グループを選択して [削除] をクリックします。
「delete」と入力して削除を確定してください入力します。
マネージド インスタンス グループが削除されるまで待ちます。これにより、グループ内のインスタンスも削除されます。テンプレートを削除できるのは、インスタンス グループの削除後のみです。
- 左側のペインから [インスタンス テンプレート] に移動します**。**インスタンス テンプレートを選択し、[削除] をクリックします。
- ナビゲーション メニュー()>VPC ネットワーク >ファイアウォール。default-allow-health-check ルールと allow-ssh ルールを選択し、[削除] をクリックします。
- ナビゲーション メニュー()>セキュリティ >reCAPTCHA Enterprise。作成したキーを選択して削除します。「DELETE」と入力して、削除を確定してください入力します。
11. 完了
Cloud Armor を使用して bot 管理を実装できました。HTTP ロードバランサを構成しました。その後、reCAPTCHA セッション トークンのサイトキーを作成してウェブページに実装しました。また、チャレンジ ページのサイトキーの作成方法も学習しました。Cloud Armor Bot 管理ポリシーを設定し、ルールに基づいてリクエストの処理方法を検証しました。セキュリティ ポリシーのログを調べて、トラフィックが許可、ブロック、またはリダイレクトされた理由を特定できました。
学習した内容
- インスタンス テンプレートを設定し、マネージド インスタンス グループを作成する方法。
- HTTP ロードバランサの設定方法
- Cloud Armor bot 管理ポリシーの作成方法
- reCAPTCHA セッション トークンのサイトキーを作成して実装する方法。
- reCAPTCHA チャレンジ ページのサイトキーを作成して実装する方法。
- bot 管理ポリシーが意図したとおりに機能していることを確認する方法。
次のステップ
- reCAPTCHA アクション トークンを設定してみてください。