2026年10月8日から11日までの間に、ヤンデックスは3つのデータセンターを失いました：サソボとウラジミールは完全に停止し、カリューガは劣化した状態で稼働していました。Yandex Cloudは緊急モードに移行し、顧客に自分自身の災害復旧計画を実行するよう直接アドバイスしました。その後、最も興味深いことが起こりました。Cloudflareは、このクラウドに住んでいたボットがどうなったのかを分析し、彼らが消えたのではなく、24時間以内に他のホスティング業者に移動したことを確認しました。そして、彼らは同じTLSフィンガープリンティングJA4によって認識され続けました。パースや自動化に関わるすべての人にとって、これはインフラが崩壊したときに何をすべきか、IPとホスティングの変更がボットの「アイデンティティ」を変えない理由についての2つの質問に対する珍しい実験です。
ヤンデックスに何が起こったのか
BleepingComputerによると、ヤンデックスは無人機による攻撃で3つのデータセンターが損傷したと報告しました。ヤンデックス自体は加害者を特定していませんが、BBCを引用したメディアはウクライナとの関連を示唆しています。時系列は以下の通りです：
- 10月8日 — サソボ（リャザン州）：火災、サイトは完全に停止；
- 10月9日 — カリューガ：劣化した状態で稼働、完全な停止ではない；
- 10月11日 — ウラジミール：完全に停止。
Yandex Cloudのステータスページでは、一部のサービス（コンソール、API、IAM、データベース、S3、Kubernetes）がパフォーマンスの問題を抱えつつも利用可能でした。コンピュートとAIスタジオは部分的に稼働していました。会社は、信頼できる復旧のタイムラインを示すことができず、残されたリソースの構成が不安定であると考え、顧客に代替の災害復旧計画を使用することを推奨しました。BleepingComputerが発表した時点（10月12日）では、復旧のタイムラインやデータ損失の可能性に関する明確な情報はありませんでした。
Cloudflareが見たこと：トラフィックは減少、ボットは減少せず
10月14日、Cloudflareは自社ネットワークの事故分析を発表しました。重要な数字は以下の通りです：
- 10月11日、ヤンデックス検索ネットワーク（AS13238）からのトラフィックは通常の99％減少し、Yandex.Cloud（AS200350）からは90％減少しました；
- AS13238からの99.5％のリクエストは自動的なものであり、そのうち93.6％はヤンデックスの検証済みクローラーでした。このネットワークはロシアのIPからの全ボットリクエストの約7％を提供していました；
- Yandex.Cloudでは、評価されたリクエストの約95％がボットであり、その中で検証済みのものはありませんでした。これはロシアのボットトラフィックの約2％に相当します；
- Yandex.Cloudからのボットトラフィックは約40％減少し、このネットワークからのWordPressプラグインのスキャンは90％減少しました。
そして、重要なことが続きます。Yandex.Cloudからのほぼすべてのボットリクエストは、Cloudflareのクライアントアカウントの一つであるギャンブル業界に向けられていました。10月8日の障害直後、Yandex.Cloudからのリクエストはゼロに減少し、すぐに他のロシアのホスティング業者、RadistとSelectelから同一のリクエストが現れました。同じJA4フィンガープリンティング、同じ珍しいパスとヘッダー、同じ非標準のUser-Agent文字列を持っていました。1週間の結果：ロシアのボットトラフィックはギャンブルアカウントに対して減少せず、167.7百万から170.1百万リクエストに増加しました（+1.4％）。
Cloudflareの結論は厳格に述べられています：物理的インフラは静的であり、悪意のある自動化は移動するように構築されています。HTTPトラフィックの減少は事故を示していますが、ボットが停止したことを意味するわけではありません。
大きな声とデータ：なぜ「ボットが沈黙した」は誇張だったのか
同時に、ウクライナのデジタル情報対策センター（ЦПД）は、サソボへの攻撃後、FacebookとTelegramでの疑わしいアカウントの報告数が1日で83.6％減少したと発表しました—4,032から660に。しかし、TechRadarが分析したところ、10月10日には活動が4,585件に戻り、10月11日には攻撃前のレベルを超えました。Cloudflareは顕著な変化を見つけませんでした：ロシアのIPから「投稿、返信、いいね」のエンドポイントへのボットトラフィックはわずか5.7％減少しました。Graphikaも追跡されたコミュニティでのアクティブアカウントの喪失を確認しませんでした。研究者のレネ・ディレスタはLawfareでこの話を美しいが、事実よりもフィクションに近いと述べました。
アナリストへの別の教訓：10月8日、ロシア全土で銀行、小売業者、オペレーター、メディアが障害を起こしたため、この日の「活動」の減少をボットに無条件に帰することはできません。集約されたトラフィックは簡単に誤解を招きます。
教訓その1：IPとホスティングはボットのアイデンティティではない
Cloudflareは「Yandex.Cloud → Radist/Selectel」の関連性をアドレスではなく、行動とクライアントのフィンガープリンティングによって認識しました：
- JA4 — TLS ClientHelloのハッシュ：暗号スイート、拡張、プロトコルのバージョンのセット。これはプログラムを説明し、ネットワークを説明するものではありません。同じPythonスクリプトが新しいサーバーで実行されても同じJA4が得られます；
- 珍しいパスとヘッダー — 通常のブラウザでは見られないHTTPヘッダーの順序とセット；
- 独自のUser-Agent — 自体がラベルとして機能するユニークな文字列。
合法的なパースのための実用的な結論：データセンターやIPプールの変更は、クライアントスタックが変わらない限り、アンチボットにとって「新しい」存在にはなりません。逆に、クローラーが誠実に自己を表現し、慎重に行動し、敏感なエンドポイントを攻撃しない場合、安定したフィンガープリンティングは問題ではありません。問題は、スタックが実際のユーザーには存在しない何かのように見えるときに発生します：TLSフィンガープリンティングライブラリのリクエストでのChrome、エキゾチックなUA、非標準のヘッダー。これらの検出層の仕組みについては、JA4とTLSフィンガープリンティングのスクリーピングに関する分析で詳しく説明しています。
もう一つの詳細に注意してください：ボットはあるデータセンターから他のデータセンターに移動しました。Cloudflareにとって、これは依然として多くのサイトに対して事前に高い不信感を持つホスティングASNのカテゴリーです。ネットワークは異なりますが、リスクプロファイルは同じです。
教訓その2：インフラは数時間で移動できるようにすべき
悪意のある者たちは1日で移動しましたが、それは彼らの自動化が元々移植可能であったからです。価格を収集したり、出力を監視したり、分析を行ったりする正直なチームにとって、そのような移植性は同様に必要です。ヤンデックスクラウドの「代替の災害復旧計画を使用してください」という推奨は、そのような計画がすでに存在する場合にのみ有効です。最小限のチェックリスト：
- コードと設定はクラウドの外に。 リポジトリ、コンテナイメージ、環境変数は、他のホスティング業者でパーサーを展開できるように配置する必要があります。
- 事前に別のホスティング業者。 別の法域と地域における代替プロバイダーでのアカウント、支払い、テストサーバー。事故の日に登録して検証を受けるのは遅すぎます。
- 出力層は計算から分離。 ターゲットサイトへのリクエストがプロキシプロバイダーを経由して行われる場合、計算の移動は地理やIPのタイプ、セッションの履歴を変更しません。サーバーは移動できますが、サイトにとっては同じクライアントのままです。
- データとキューはレプリケーション付き。 パースの結果とタスクの状態は別のストレージにコピーされ、そうでなければ事故後に再度回る必要があります。
- バックアッププロバイダーは本当に異なる。 バックアップホスティングやプロキシプロバイダーは、別のブランドの下で同じインフラであってはなりません。プロキシの確認方法については、バックアッププロキシプロバイダーが同じプールである可能性についての資料で説明しました。
- 訓練用アラーム。 四半期ごとにバックアップサイトでパーサーを立ち上げ、実際のタスクを実行します。一度も実行したことのない計画は、実際には通常機能しません。
この状況で各種プロキシが解決すること
プロキシは悪いフィンガープリンティングから守ることはできません—これはCloudflareの分析の例から明らかです。しかし、彼らはあなたのリクエストの「顔」を、コードが物理的にどこで動いているかから切り離します：
- レジデンシャルプロキシ — ホスティングASNが事前に制限されるか、キャプチャを受けるサイト向け。サーバーを移動する際、出口は必要な国の家庭用IPに残ります。
- データセンタープロキシ — APIや親切なサイト向け、速度と価格が重要です。これらもあなたのクラウドとは独立したプロバイダーに保持するべきで、ホスティングの事故が出口IPを奪うことがないようにします。
この時、プロキシはただの一層です。TLSスタック、ヘッダー、クライアントの行動が際立っている場合、彼らはどのIPでも認識されます。RadistとSelectelに移動したボットが認識されたように。
これはサイト所有者にとって何を意味するのか
Cloudflareは逆の結論も出しています：ASNとトラフィック量はボットの信頼できない指標です。「悪い」ネットワークをブロックすることは、最初の移動まで機能します。行動を見る方が信頼性があります：異なるネットワーク間の共通のJA4フィンガープリンティング、異常なリクエスト頻度、感度の高いエンドポイントに対するWAFのルールは、リクエストがどこから来たかに関係なく重要です。裏側にも問題があります：Cloudflareの顧客の40.5％がヤンデックスのクローラーに対して403コードを返し、ヤンデックスからニュースサイトへのトラフィックは事故の間に44％減少しました—つまり、主に合法的なインデックス作成が影響を受けました。
結論
ヤンデックスの事故は、2つの単純な真実の生きた検証となりました。第一に、インフラは1日で消失する可能性があり、数時間で移動できる人が勝つ—クラウドの外にコードを持ち、別のホスティング業者とサーバーに依存しない出口層を持つことが重要です。第二に、アンチボットにとってあなたはクライアントスタックであり、IPではありません。同じJA4と同じUser-Agentを持つ新しいデータセンターは、新しい住所の同じボットです。パースを構築する際には、プラットフォームの変更を耐えられるようにし、どのIPでも同じように見えるようにしてください。