先ごろ、当社が使用するCAPTCHAプロバイダーをGoogleのreCAPTCHAから、独立したhCaptchaが提供するサービスへと移行しました。これによって、かつてGoogleサービスに依存したことで懸念されたプライバシー問題に取り組むことができ、CAPTCHAをさらに柔軟にカスタマイズできるようになるため、この変化を非常に嬉しく思っています。この変更で、Cloudflareのお客様全員に影響があるかもしれないため、変更の根拠を詳しく解説します。
CloudflareのCAPTCHA
Cloudflareが提供するサービスの一つは、悪意のある自動化された（「ボット」）トラフィックをブロックする方法です。これには、数多くのテクニックを用いています。当社が悪意のあるボット活動だと確信がある場合は、完全にそれをブロックします。そして、正当な人間のトラフィック（または検索エンジンクローラーのような良性のボット）だと判断した場合は、許可します。しかし、時に、それが悪意のあるものなのかそうでないのか100%の確信が持てない場合は、「チャレンジ」を発行します。
当社のチャレンジは多様で、完全自動化のものもあれば、人の介入を必要とするものもあります。こうしたチャレンジは、CAPTCHAとして知られています。CAPTCHAとは、コンピューターと人間を区別する完全に自動化された公開チューリングテスト「Completely Automated Public Turing Test to Tell Computers and Humans Apart」の頭文字です。（CAPTTTCHAになってしまうのでTを2つ省略）枠の中の波状の文字を入力する、または信号機や歩道を識別するように指示するプロンプトがあります。一般的には、人間にとっては簡単でも、機械にとっては難しいものとなっています。
Cloudflareは初期の頃から、GoogleのreCAPTCHAサービスを利用してきました。ReCAPTCHAは、2007年カーネギーメロン大学の研究プロジェクトとして開始しました。2009年、Googleはプロジェクトを買収しました。これは、Cloudflareが設立されたのとほぼ同時期です。GoogleはreCAPTCHAを無料で提供する代わりに、自社の視覚的識別システムのトレーニングのためにサービスからのデータを利用しました。CloudflareのCAPTCHAにreCAPTCHAを採用したのは、で効果的かつ拡張可能、かつ無料であったためです。無料というポイントは、Cloudflareのお客様の多くが、当社の無料サービスをご利用だったため、重要でした。
プライバシーとブロッキングに関する懸念
当初から、CAPTCHAを提供するためにGoogleサービスを利用することに懸念を表すお客様もいらっしゃいました。Googleのビジネスでは、ターゲット広告を利用しています。しかし、Cloudflareは違います。当社は厳格にプライバシーを尊重しています。reCAPTCHAに関するプライバシーポリシーには満足していましたが、一部のお客様がGoogleにさらにデータを提供することを懸念していることも理解できました。
当社でも、中国などで、Googleのサービスが断続的にブロックされるなど、一部の地域で問題が発生していました。中国は、単独でインターネットユーザー全体の25%を占めます。この中の一部のユーザーについてCAPTCHAがトリガーされた場合にはCloudflareのお客様にアクセスできない、ということは常に当社の関心事でした。
長年、プライバシーとブロッキングは大きな不安材料であり、reCAPTCHA切り替えを検討するに至る理由として十分でした。しかし、多くのテクノロジー企業がそうであるように、お客様にとって目新しい特長や機能に注力するならまだしも、すでに機能しているものを取り除くことを優先事項にするのは難しかったです。
変化し続けるGoogleのビジネスモデル
今年の初め、GoogleからreCAPTCHAの課金を開始する予定だと知らせを受けました。Googleにとっては、完全に権利の範囲内です。Cloudflareのボリュームを考えると、reCAPTCHAサービスにかかる経費はGoogleにとってさえ大きな負担であったことは間違いありません。
繰り返しますが、これはGoogleにとって完全に合理的な判断です。画像分類トレーニングの価値がこれにかかる経費を上回らなかったなら、Googleが提供するサービスに対する支払いを要求することは、理にかなっています。当社の場合、無料ユーザーのためにreCAPTCHAの利用を継続するだけで年間何百万ドルもの経費が追加されることになります。最終的に、これはもっと良い代替案を探すという原動力となりました。
CAPTCHAの向上
CAPTCHAベンダーを数社評価したほか、自社システム構築も検討しました。結局、hCaptchaがreCAPTCHAの代替としてベストだということになりました。当社がhCapthaを気に入っている理由がいくつかあります。1) 個人データを販売しないこと。必要最低限の個人データしか収集せず、どの情報を収集してどのように使うのか、あるいは開示するのかについて透明性のある説明を行い、このデータをCloudflareへのhCaptchaサービス提供のためだけに使用すると合意したこと。2) A/Bテスト中のパフォーマンス（速度と解決率の両方）が予想通り、むしろ予想以上だったこと。3) 視覚に障害を持つ方その他アクセシビリティに困難を持つユーザーのための堅牢なソリューションがあること。4) プライバシーパスをサポートし、CAPTCHAの頻度を減らしていたこと。5) Googleがブロックされている地域でも機能したこと。6) hCapthcaチームは鋭敏かつ迅速で、とても気持ちがよかったこと。
標準のhCaptchaビジネスモデルは、reCAPTCHAの開始時とよく似ていました。画像分類データを必要とするお客様に課金し、CAPTCHAをサイトにインストールするパブリッシャーに支払いをする予定でした。当社にとって良さそうでした。しかし残念なことに、多くのパブリッシャーとはうまくいったとしても、Cloudflareの規模では無理でした。
当社は、hChaptchaと2方面で協働しました。まず、当社はCAPTCHAの技術的負荷の多くを負担するためにWorkersプラットフォームを活用する過程にあり、これによって経費を削減します。次に、hCaptchaが当社に払うのではなく、当社が支払うことを提案しました。このように、当社のニーズに合うサービスの規模に変えられるリソースを確保したのです。追加のコストが発生することになりましたが、これはreCAPTCHAで発生したであろうコストのほんの一部でした。その代わりに、さらに柔軟なCAPTCHAプラットフォームとはるかに応答性の高いチームを手に入れることができました。
顧客はいつCAPTCHAを提供しますか。
このプロジェクトに取り組み始めたとき、Cloudflareボット管理とファイアウォールルールは、ずば抜けて大きいCAPTCHAの消費者になるだろうと予想されていました。ある意味、これは正しい見方でした。ファイアウォール/ボットは第1位の消費者でしたが、当社の提供するCAPTCHAの50%を少し超える程度でした。
次の表は、Cloudflareのお客様がご自分のゾーンでCAPTCHA提示を求めた事例の内訳を、提供されたCAPTCHA合計ごとに示したものです。
| ソース | |
|---|---|
| ファイアウォールとボットルール | 54.8% |
| IPファイアウォール | 18.6% |
| セキュリティレベル | 16.8% |
| DDoS | 6.3% |
| Rate Limiting | 1.7% |
| WAFルール | 1.5% |
| その他 | 0.3% |
当社のファイアウォールとボットルールが表の一番上にあり、Cloudflareが提供するCAPTCHAの大半を占めています。これらのルールは、当社のお客様が書いたものであり、ルールが一致したときにCAPTCHAを適用します。たとえば、ボット管理スコアがThresholdsよりも低く、接続が自動化されている可能性が高いと思う場合だけでなく、スコアがThresholdsよりも高いけれど、どちらかがわからないときにCAPTCHAを適用する場合などです。このバケットで一般的なルールは別にもあり、サイトまたは特定のエンドポイントの裏側で100%全てのトラフィックにCAPTCHAを適用するものです。お客様は配信元への接続を制限するためにこれを実施するかもしれませんし、ログインページにクレデンシャルスタッフィングを実施したり、登録データの汚染をするような自動化システムの速度を落とそうとしているかもしれません。このため、Cloudflareの一部サイトでは毎日何億ものCAPTCHAを提供しているのです。
2番目に人気があるのは、当社のIP ファイアウォールです。これは、ファイアウォールとボットルールと似ていますが、IP、ASN、または国レベルであり粒度の細かさでかなり落ちます。このカテゴリーのCAPTCHAの大部分は、ASNまたは国レベルで書かれたルールのために行われます。おそらく、当社のお客様は特定のASNに一定の不信感を抱いていたり（たとえば、ユーザートラフィックがクラウドインフラストラクチャプロバイダーから来るのか）、特定の国から攻撃を受けているかもしれません。
次はセキュリティレベルです。セキュリティレベルには、特徴的な2つの使用例があります。1) IPアドレスレピュテーションへの率直なツールとして使う。2)「I'm Under Attack（攻撃下にある）」モードを使う。お客様に対して、「I'm Under Attack」モードは、アクティブなDos攻撃を受けている場合のみ使用するようお勧めしていますが、一部のお客様は、Rate Limitingやフィルタリングの基本的形式として、この機能を常時オンのままにしています。
最後にご紹介するCAPTCHAの主要な用途の例は、当社の自動化システムの一つを使うものです。最近、当社のDos保護エンジニアチームがGatebotにCAPTCHAを使って特定のシナリオで小さなフラッドを軽減することを教えました。現在、Gatebotは一時的なルールを書いて、攻撃者にCAPTCHAを適用することができるようになりました。
最後に、Rate LimitingまたはマネージドWAFルールセットのオーバーライドアクションとして、選択するお客様もいらっしゃいました。
また、CAPTCHAを適用していたお客様のタイプも調べました。（攻撃の正常化にかかった）一週間、当社の無料サービスのお客様はご利用のゾーンで、Cloudflareが提供するCAPTCHA全体の約40～60%を提示するように設定しました。有料サービスのお客様は、従量課金サービスとエンタープライズプランでおおよそ半々に分かれています。概してCloudflareは、1人でもお客様が攻撃を受けた場合、1秒あたり数百万のCAPTCHAを提示するという測定になりました。
チャレンジの修正
Cloudflareのシステムのどの部分であれ、変更を加えると、一部のユーザーにとっては大幅に改善される箇所もありますが、一部のユーザーにとっては一時的に悪化する場合もあります。当社とhCaptchaチームは、どのような問題でも対処できるように全力を尽くしています。お客様やお客様のユーザーが、新規のhCaptchaを実装する際に問題が発生したら、フォーラムに投稿するか、サポートチケットを発行して、できるだけ詳細な説明をご提供ください。
可能な場合は必ず、CAPTCHAページのフッターに通常表示されるRayIDを含めてください。そうすることで、当社が問題の原因を追跡することができます。
時間が経つにつれ、画像（と音声）CAPTCHAは、多くの難題に対する解決策として不完全であると考えるに至りました。Cloudflareは、発行するCAPTCHAの数を最低限に抑え、最終的には完全に排除できるように作業を続けており、その結果をこのブログでみなさんと共有できることを楽しみにしています。変更を行っているチームの社内チャットルームの名前は、New CAPTCHAではなく、(No) CAPTCHAといいます。