ボットを飼いならす大いなる挑戦
Developer Relations、Senior Software Engineer, Fastly
今日の Web では、自動化されたスクリプト、すなわちボットが商品購入の多くを占めています。このようなボットによって被害を受けている企業がある一方で、ボットが収益の増加に貢献しているケースもあります。そのため、オンラインビジネスの経営者の間でも、ボットへの対応はさまざまです。どのようなニーズにも対応してスケールアップできる Fastly のエッジクラウドでは、お客様のビジネスに最適なポリシーセットを作成できます。
近年、スニーカーは単なる「運動用の靴」を超えた象徴的なファッションアイテムであり、コレクターからの注目を集める存在になっています。そのため、少しでも早く目当ての商品を手に入れようとテクノロジーを利用する人も出てきました。
熱心なスニーカーマニアや転売屋は「ボット」、すなわち人気の高いスニーカーを可能な限り多数購入することのみを目的に設計されたプログラムを利用しています。人気ブランドがファン待望の新商品をリリースすると、購入サイトでトラフィックの急増が見られますが、注文の多くはボットによるものです。そのため、人間の購買者が商品を入手できない状況が発生することがあります。
このような傾向は他の業界でも見られます。例えば PlayStation や Xbox のような人気の家庭用ゲーム機など、需要の高い玩具や電子機器もボットによって買い占められることがよくあります。特に商戦期には「グリンチボット」と呼ばれるボットが暗躍し、人気の高い商品を独占しようとします。
ロボットとの闘い
オンラインショッピングでボットと競争しなければならない状況は、消費者にとって非常に不快です。ボットの動作は非常に速いため、人間の買い物客が商品をカートに入れる前に、商品が完売となってしまうことがあります。その結果、ボットのせいで目当ての商品を購入できなかった人は、ボットを利用して購入した商品を定価よりも高額で販売する転売屋から購入するか、購入自体を諦めることになります。
一方、企業への影響を見てみると、ボットによってWebサイトへのトラフィックが増加する可能性があります。商品をリリースする際、ボットに狙われたサイトでは何百万件ものページビューが発生しかねません。ボットの目的は商品の購入であり、サイトをダウンさせる意図はありませんが、大量のトラフィックに対応するためにコストがかかり、サイトの障害も起こり得ます。
セキュリティ上の問題？
ボットは一見すると、セキュリティ上の問題と考えられがちです。
たしかに、ボットによって帯域幅が飽和状態になり、膨大な処理負荷が発生する可能性はあります。ボットネットワーク (ボットネット) を利用するボットは、レート制限を回避するためにネットワークリクエストをマスカレードし、数千もの一意の IP アドレスから送信されているように見せかけることもめずらしくありません。また、商品の購入において有利に立つために、ショッピングカートソフトウェアやネットワークアーキテクチャに存在する攻撃ベクトルを悪用するボットも見られます。このように、大量のリクエストを送信して購入を試みるボットには、分散型サービス妨害 (DDoS) 攻撃などのセキュリティ問題と似た特徴があると言えます。
しかし、実際に料金を払って商品を購入しようとするボットの場合、一概にセキュリティリスクとみなすことはできません。
消費者が高いお金を払っても手に入れたい商品があり、在庫が限られている場合、国や場所を問わずその商品を狙うボットが高い確率で存在します。ここで、リテール業界にはさまざまなタイプのビジネスモデルがあることを考慮する必要があります。Walmart、Best Buy、Amazon、Supreme、Coachella、Apple を含め、オンラインストアはボットに対してそれぞれ独自のアプローチを採用しています。
いずれの場合も、最終的な目的は「売ること」です。商品を卸売価格で仕入れ、事前に決められた小売価格で販売する企業は、在庫をさばく手段としてボットを歓迎するかもしれません。同時に、ボットにより商品が手に入りにくい状況が (人工的に) 発生することで、その商品が実際よりも特別に感じられ、プレミア感が増すこともあります。
他方、人間の顧客に対する商品の販売を優先する企業が存在することも事実です。例えば、PlayStation 5s や Xbox を購入したくてあるオンラインショップを訪れた大勢の買い物客が、ボットが原因でそれらを購入できなかった場合、彼らが次にテレビを買い替える際にそのショップを訪れる可能性は低くなります。
問題はそれだけではありません。ボットによって商品の二次流通市場が大きくなりすぎると、ブランドの評判に傷がつく可能性もあります。単に、人間がボットと競わなければならない状況は公正ではないと考える企業もあるでしょう。
このようにショッピングサイトによってビジネスモデルや優先事項が異なるので、必要となるポリシーもさまざまです。実際、私たちのお客様はそれぞれのニーズに合わせて完全に独自のソリューションを採用しているため、例として詳細をここでご紹介することはできません。
商品を自社サイトで購入するボットにどう対応するかは、ビジネス上の決定であることを理解することが重要です。つまり、すべてに効く特効薬はなく、ある企業にとって役立つソリューションが他の企業にとっても最適なソリューションであるとは限らないということです。
ひとつ言えるのは、どの程度の量のボットトラフィックが必要で、どのようにそれを処理したいのかをビジネスの経営者が決められることが大切です。
ユーザーの判別
ボットを識別したいWebサイトはさまざまなメソッドを使用してボットトラフィックを特定しています。シンプルなソリューションとして、短期間に同じ IP アドレスから大量のリクエストを受信していることを検出する手法がありますが、ボットネットはこの戦略の裏をかくことができます。
また、お馴染みの CAPTCHA を使用するケースもあります。CAPTCHA は、サイト訪問者に特定の物体が写っている写真を選択させたり、画像に書かれた読みにくい文字を入力させたりするパズルを解決させることで、訪問者が人間かボットかを見分ける手法です。Developer Hub で、CAPTCHA をエッジで提供して検証する例をご覧いただけます。しかし、最近は人工知能や CAPTCHA ファームを使って CAPTCHA をパスすることが可能になりつつあります。プライベートアクセストークンなど、プライバシーを保護する新しいソリューションも登場していますが、まだ普及しているとは言えません。
より高度な動作検出メソッドは、人間とボットの行動は必ずしも同じではないという前提に基づくヒューリスティクスを使用します。以下は、ボットかどうかを判断するためにサイトが確認する情報の例です。
1回のセッションにおける過度のページ読み込み回数
不自然なページ移動操作
極端に短いページ読み込みの間隔
JavaScript や CSS、広告など依存関係にあるリソースの読み込み失敗
ビューポートの見えない部分にあるリンクのクリック
不自然なスピードでのフォームへの記入
ブラウザーフィンガープリントを利用するメソッドでは、さまざまな手法を使用してデバイスやブラウザ、オペレーティングシステムなど、サイト訪問者に関する情報が収集されます。このようにして生成された「フィンガープリント」は、ヒューリスティック分析によって、既知のボットと一致するか、またはボットであることを隠すための変更が見られるかどうか判断されます。フィンガープリントを生成するメカニズムには、FingerprintJS ライブラリや JA3 など、さまざまなものがあります。JA3 は TLS クライアントのフィンガープリントを生成する方法として広く使用されており、Fastly の VCL と Compute でもサポートされています。
ボットの検出には、多くのコンピューティングリソースが消費されます。検出技術が進化する中、ボットが検出を回避する策略もすぐ (数週間ごと) にアップデートされるため、延々といたちごっこが続いています。
ボットを特定した場合の対応
サイト訪問者がボットと判定された際にどのようなアクションを行うかを決定する必要があります。
ボットを締め出したい場合の最も簡単な対処方法は、ボットであるという理由で (すなわちサイトの利用規約に違反している可能性が高い)、エラーコードを返して追い払うことです。しかし、このようなレスポンスはかえってボット作成者を刺激し、より攻撃的なやり方で検出を回避しようと試みることが分かっています。
そこで、検出されていることをボットが必ずしも気付かない緩和策を講じることも可能です。例えば、「ペナルティボックス」を使用して、単一の IP アドレスから送信されるリクエストをスローダウンさせることができます。
penaltybox origin_response_pb {}
sub vcl_fetch {
if (beresp.status == 429) {
ratelimit.penaltybox_add(origin_response_pb, client.ip, 1m);
}
}
sub vcl_deliver {
if (ratelimit.penaltybox_has(origin_response_pb, client.ip)) {
resp.tarpit(5, 1000);
}
}上記は、Fastly のエッジレート制限機能をペナルティボックスとして使用する例です。このコードによって、サーバーが「429 Too Many Requests」を返してリクエストを拒否した後、1分間にわたって送信元の IP アドレスがペナルティボックスに追加されます。その間、この IP アドレスを持つクライアントはレスポンスの1,000バイトが生成されるごとに5秒間、強制的に待たされます。
また、偽のショッピングカートをボットに表示するなど、より凝った対策も可能です。その場合、ボットは偽の決済プロセスを経て、偽の購入完了ページがボットに送信されます。そうすることで、ボットに商品を販売することなく、ボットを満足させることができます。
さらに、ボットを特定する HUMAN Security のように、Fastly との統合が可能でボット対策に役立つパートナープラットフォームの利用もお勧めです。
別の対処法として、ボットを人間の買い物客と平等な条件下に置くことを可能にするツールを利用する手もあります。ピークトラフィック時に人間の買い物客も順番待ちの列に並んで購入のチャンスを得られるようにする、ウェイティングルームなどのソリューションは広く活用されています。
その一方で、オリジンとショッピングカートが保護されている限り、ボットトラフィックを気にしない企業もあります。このような企業の場合、クレデンシャルスタッフィングを防ぎ、ログでボットトラフィックとオーガニックトラフィックを判別できさえすれば、ボット対策として十分かもしれません。
あらゆるボット対策のニーズに応える Fastly のインフラストラクチャのメリットを以下に挙げてみました。
ビジネスポリシーに適したボット対策をお客様と一緒に構築します。
Comp をはじめとするプラットフォームに加えて、お客様のボット戦略に役立つレート制限などのツールや、ウェイティングルームなど便利なソリューションを提供します。
エッジでスケールアップしてトラフィックを送信することで、お客様のオリジンサーバーを保護します。また、パワフルな Fastly Next-Gen WAF (Powered by Signal Sciences) は、自動化された攻撃や悪用を行うボットからビジネスを保護するのに役立ちます。
ビジネスに適したポリシーの採用
いずれにしても、ボットが世の中から消えることはありません。「ボット対人間」の競争がビジネスの目標にどう影響を与えるかがボット対策のポイントになります。ボットを完全に遮断したい場合でも、人間の買い物客に購入機会を最大限に提供できるポリシーが必要な場合でも、ビジネスのニーズに適したポリシーの実現を Fastly がサポートします。
