Cloudflareは2023年3月、偽アカウントやアカウント乗っ取りなどに対応する「Cloudflare Fraud Detection」を発表しました。背景にあったのは、ボットを見つけるだけでは、人が関与するオンライン不正を十分に捉えられないという課題です。
その後の公式資料では、アカウントの不正利用を調べるAccount Abuse Protectionや、漏洩認証情報の検出などが案内されています。当初の構想をそのまま現在の製品仕様として扱わず、検出対象、使えるプラン、対応に必要な設定を確認することが大切です。
2023年3月の発表は、早期アクセスに向けた構想だった
Cloudflareは2023年3月15日の公式ブログでFraud Detectionを発表しました。本サイトが紹介したのは同月24日です。発表時点では、同年後半のEarly Accessへの参加希望を受け付ける案内であり、その日にすべての機能が一般提供されたというニュースではありません。
対象として挙げたのは、偽アカウントの大量作成、アカウント乗っ取り、盗難カードの有効性を試す行為や不正購入、通常の操作順序を飛ばして限定商品などを取得する行為でした。単に短時間の大量アクセスを止めるだけでなく、登録や購入の流れの中で起きる不正を見つけようとする構想です。
検出後の対応も一律の遮断だけではありません。当時の説明は、ネットワーク側でのブロックや追加確認のほか、検出情報をアプリケーションに送り、利用できる機能を制限する方法も想定していました。旧記事の「自動的に世界規模でブロックする」という説明には、運営者が対応方法を選ぶという条件を補う必要があります。
WAF、Bot Management、不正検出は何を見ているか
WAFはWebサイトやAPIへのリクエストを調べ、ルールに合う通信を処理する仕組みです。IPアドレス、URL、ヘッダー、本文などを条件にでき、既知の攻撃に対する管理ルールと、サイト固有のルールを組み合わせます。不正検出の結果を使って対処する土台にもなります。
Bot Managementのボットスコアは、通信が自動化されたものかを推定する指標です。公式文書では1〜99で示し、小さいほどボットの可能性が高いと説明しています。精細なスコアの利用にはEnterprise契約とBot Managementが必要です。なお、0は評価していない状態を意味し、安全な通信という判定ではありません。
一方、アカウント不正対策では、人が操作していても特典目的の大量登録や乗っ取りが起きていないかを見ます。逆に検索エンジンの巡回など、正当な自動アクセスもあります。このため「人間らしいから安全」「ボットだから詐欺」とは決められません。自動化の推定、不審な行動の検出、ルールによる対応を組み合わせる設計です。
2026年の提供形態はAccount Abuse Protection
2026年3月12日、CloudflareはAccount Abuse Protectionを発表しました。使い捨てメールの判定、メールのリスク評価、ハッシュ化したユーザーIDなどを組み合わせ、アカウント作成やログイン時の不審な動きを調べる機能群です。メールの形式や利用基盤に関する情報は判断材料になりますが、それだけで登録者の本人性や犯罪行為が確定するわけではありません。
調査日である2026年9月27日にも、公式文書の表記はEarly Accessでした。対象はBot Management Enterpriseの顧客で、一般提供までの限られた期間は追加料金なしと説明され、利用には担当チームへの申請が必要です。無料プランを含む全利用者向けの恒久無料機能と読むことはできません。
3月の発表には同年中のCloudflare Fraud Prevention一般提供への言及がありますが、予告と提供開始は別です。今回確認できた資料からは、その一般提供の完了や正式料金までは確定できません。また、2023年に構想として列挙したカード不正対策などが、現在のアカウント保護機能にすべて含まれるとも判断できません。
ログイン保護では漏洩情報と試行パターンを組み合わせる
漏洩認証情報の検出は、送られたユーザー名やパスワードを既知の漏洩データと照合する機能です。現在の文書では、パスワードの漏洩検出は全プラン、ユーザー名とパスワードの組み合わせの検出はPro以上など、項目ごとに提供範囲が異なります。パスワードの照合時に平文を保存・記録しないと説明されています。
ただし、漏洩したパスワードを使うアクセスには、攻撃者による試行だけでなく、本人が古いパスワードを使い続けている場合もあります。そのため検出しただけで乗っ取りと断定せず、アプリ側で変更を促す対応も可能です。Cloudflareは検出結果をリクエストヘッダーで元のサーバーに渡す仕組みを用意しています。
別の手掛かりが、アカウント乗っ取り向けの検出IDです。ログイン試行の多さや失敗の多さを調べ、カスタムルール、回数制限、Workersなどの処理に利用できます。一般的でないログイン用URLは自動認識されないことがあるため、対象を明示する設定が必要です。契約を追加しただけで独自のログイン処理が漏れなく監視されるとは限りません。
ユーザー単位の分析と端末の手掛かりを混同しない
Account Abuse ProtectionのUser IDは、サイト単位で使うハッシュ化された識別子です。同じ利用者に関係するアクセスを分析するためのもので、他のCloudflare顧客から同じプロフィールを参照する仕組みではありません。有効化は任意であり、実名の本人確認や、異なる事業者間で個人を共通に識別する機能とも異なります。
Turnstileには、IPアドレスを変えながら行う不正のパターンを調べるEphemeral IDsという別の仕組みもあります。公式の導入例では、Enterprise Bot ManagementとEnterprise Turnstileの追加契約、または単独のEnterprise Turnstileを必要としています。通常のTurnstile利用と同じ契約条件だと考えない方がよいでしょう。
このIDも端末ごとの一意性は保証されません。公式文書は、ブラウザーのプライバシー保護によって取得できる情報が限られ、複数の正当な利用者が同じIDになる場合を挙げています。したがって、同じIDから登録が続いたという理由だけで同一人物と決めつけず、IPや行動の情報を併せて大量不正の傾向を調べる用途です。
導入時は検出件数より、正当な利用者への影響を見る
運営側が最初に確かめたいのは、保護したい登録・ログイン用URLが検出対象になっているか、どの判定結果を使える契約か、判定後に何を行うかです。アカウント保護の現行文書には、EU地域のRegional Servicesを使うData Localization Suiteの構成では、アカウント乗っ取り検出を利用できないという制限もあります。ネットワーク全体の宣伝文句だけでは、個別環境の対応範囲は分かりません。
運用例としては、使い捨てメールを検出した登録をすべて拒否する前に、追加確認を求める案と比較できます。漏洩パスワードなら本人への変更案内、大量のログイン失敗なら回数制限など、観測した事象に応じて処理を分けます。これは対応を設計する例で、どのサイトでも同じ条件が最適という意味ではありません。
評価には、不正と見られる通信を止めた数だけでなく、正当な登録が完了した割合、ログインの失敗、問い合わせ、追加確認による離脱も含めるべきです。旧記事の「性能を犠牲にしない」「手間を増やさない」という表現は製品の目標を述べたもので、全環境の遅延ゼロや誤検知ゼロを保証しません。本稿では顧客環境への導入試験を行っておらず、検出精度や実際の損失削減率は確認していません。
よくある質問
Q. 2023年の発表日に一般提供されたのですか？
A. 当時の公式発表は2023年後半の早期アクセスを案内していました。発表時点で全機能が一般提供されたとはいえません。
Q. WAFを使っていればAccount Abuse Protectionも使えますか？
A. 同じ条件ではありません。2026年9月の確認ではBot Management Enterprise顧客向けの早期アクセスで、担当チームへの申請が必要です。
Q. 不正という判定が出れば自動的にすべて遮断されますか？
A. 検出結果と対応は別です。ルールで遮断や追加確認を選んだり、結果をアプリ側に渡したりできます。正当な利用者への影響も確認して運用します。
この記事の出典
- Cloudflare：Fraud Detection発表（2023年3月15日）
- Cloudflare：Account Abuse Protection発表（2026年3月12日）
- Account Abuse Protection：提供条件と設定
- Cloudflare WAFの機能概要
- Bot scores：評価対象と利用条件
- Leaked credentials detection：照合とプラン別条件
- Account takeover detections：検出IDとログイン対象
- Turnstile：Ephemeral IDsによる不正検出
※本記事は公開情報をもとにした一般的な情報提供であり、投資の勧誘や助言ではありません。暗号資産・NFTの価格は大きく変動します。最新の情報は各公式発表をご確認ください。
