Google reCAPTCHA v3について調べてみた
ebinareCAPTCHAとは
ボットによるスパム投稿などを防ぐCAPTCHAのGoogle版。
「バスの写真を選んでください」、「私はロボットではありません」など見かけたことがある人も多いはず
version 3について
reCAPTCHAの最新版(サービス開始は2018~?)
ついにユーザーが一切アクションを行うことなく自動的にボットかどうか判定を行えるようになった。
ボットかどうかはreCAPTCHA v3によって判定されるスコアで判断できる
1.0 は安全なインタラクションである可能性が非常に高く、0.0 は bot である可能性が非常に高いです
動作イメージ
reCAPTCHA v3ではユーザー(ボットも含む)のページアクセスからフォーム送信までのブラウザ上でのユーザーの行動を監視することでボットかどうかの判定を行う。
こちらの公式の動画がわかりやすいです。
公式の動作フロー図
ebina料金・サービス体系
実装方法の前に料金体系について
料金
基本無料(一部従量課金)
通常版とEnterprise版
reCAPTCHA v3は通常版reCAPTCHAとGoogle Cloud Platformと紐づく高機能なreCAPTCHA Enterpriseが存在。
両者の比較表がこちら。
ざっくりまとめる
通常版
- 完全無料(?)でEnterprize版と同じ判定機能を利用できる
- コンソールはGCPと連携したENterprise版には少し劣る？
- APIの呼び出し上限を超えた場合、判定が正確に行われなくなる(後述)
Enterprise版
- GCPコンソールと連携してより細かく分析できる
- 100万回までAPI呼び出し無料。以降1000回ごとに$1必要。
補足
API呼び出しの上限について
If you wish to make more than 1000 calls per second or 1000000 calls per month, you must use reCAPTCHA Enterprise or fill out this form and wait for an exception approval. If a site key exceeds 1000 QPS, then some requests may not be processed. If a v3 site key exceeds its monthly quota, then site_verify may fail open by returning a static score 0.9 and an error message
"Over free quota."for the remainder of the month. There are no user-visible indications when v3 sites are over quota.
つまり？
- 1秒に1000回以上呼び出すと、全部のリクエストに対して正確な判定を行う保証はないよ
- 月に100万回以上呼び出すと、常に判定スコア0.9 = ボットの可能性大、を返すようになるよ
-
"Over free quota."っていうメッセージがつくからそれでオーバーしたことがわかるよ
-
- この制限を撤廃したいときはEnterprise版を使ってね
reCAPTCHA Enterprise 料金体系
ebina#メモ
reCAPTCHAトークンの有効期限
2分間
Note: reCAPTCHA tokens expire after two minutes. If you're protecting an action with reCAPTCHA, make sure to call execute when the user takes the action rather than on page load.
ebina実際に使ってみる
通常版で行う
コンソールでAPI用サイトキー・シークレット発行
- 通常版の場合、Googleアカウントは必要だがGCPとは結びつかなそう
- GCP内のプロジェクトへの紐付けたい場合はEnterprise版を利用
- 一つのキーで複数ドメインに対応可能
- ドメインを登録するとそのサブドメインにも対応
- 一つのキーだけでかなり広い範囲に適用できそう
- 実運用するときは開発、ステージング、本番用の3つを使い分けることになりそう。
- 不審な動きがあったときにアラートメールをサイトのオーナーとして登録したGoogleアカウントに送信できる
ebina実際に導入するにあたって
ここまでreCAPTCHAの仕様周りをまとめてきたので、最後に実際にサービスに導入する際の注意点をまとめます。
以下の内容は下記のページの内容を踏まえたもの
ポイント
- reCAPTCHA v3は即座に怪しいユーザーをブロックする機能ではない
- あくまでも「Botっぽさ」を自動で判定してくれるサービス
- スコアの解釈や対応は呼び出し側に委ねられている
- スコアは1.0~0のグラデーションがあり、問題ありと判断するラインは自分たちで決めなければならない
- 問題ありと判断した場合の対応策も自分たちで決めなければならない
- ある意味ではスコアに応じて柔軟に対応策を変えることが可能になったとも言える
- 導入には開発・運用コストが必要
- 多くの場合、スコアの傾向を把握するための導入期間が必要になる
- ユーザーに負担を強いない点は魅力的だが、その分運用面の考慮事項が多くその負担も勘定に入れておくべき
個人的所感
すごくいいところ
- UXを毀損しない
- ボットへの対処がプログラマブルになる
気になるところ
- 導入するための下準備が多い
- 活用し続けるためには継続的なメンテナンスが必要
詳細
各サービスごとにユーザー属性やサイトの作りによって何らかのアクションを起こすべき適切なスコアというのは異なっている。
そのためreCAPTCHA v3を本番環境に導入する際には、各サイトごとに適したアクションを起こす閾値を見極めることがv3を活用するためのファーストステップとなりそう。
そのため、一般的にreCAPTCHA v3の導入前には自身のサービスのスコアの傾向を知るために一定の導入期間が必要となる。以下は導入の流れの一例。
- reCAPTCHA v3の試験導入
- まずは簡易的な実装を行ってスコアを収集できる状態を作る
- この段階ではユーザーの行動をブロックせず、スコアの収集のみ行う
- 十分なデータが集まったら次へ
- 導入判断
- Botの検知ができているか
- 低いスコア(Botの疑いがある)が少ない場合、導入するメリットは無いかも
- スコアの傾向が見えた場合は仮の閾値を設定する
- はじめは低いスコア(Botの疑いが強い値)から初めて徐々に引き上げていくのが良さそう
- Botの検知ができているか
- 導入
- 閾値ごとに取るべきアクションを定義し実装する
- 即座にブロックするのではなく、怪しい場合は2段階認証を要求するといった選択肢を取ることも可能
- 以下の公式ページを参照
- 閾値ごとに取るべきアクションを定義し実装する
- 運用
- 継続的にGCPコンソール等でスコア分布を把握し、閾値やアクションを改善していく