これまでの経緯
これまでの経緯については、ロシア大手Yandexのデータセンターがドローン攻撃で機能停止—クラウドインフラの脆弱性露呈かで詳しく解説しています。
Yandexデータセンター攻撃によるネットワーク障害と憶測
2023年10月7日から11日にかけ、ウクライナからのドローン攻撃がロシアのYandex施設を標的とし、データセンターとネットワークインフラに甚大な被害を与えました。特に10月11日には、Yandexネットワークはほぼ完全に停止し、Yandex Search（AS13238）のトラフィックは基準値から99%減、Yandex.Cloud（AS200350）も90%減を記録しました（Cloudflare）。
一時的なネットワークの機能停止により、悪意あるロシアのボットファームや影響力工作が停止したという憶測が広まりました。
HTTPトラフィックの急激な減少は、この憶測を裏付けるように見えました。しかし、これは単にネットワークがダウンしたことを示すものであり、悪意あるボット活動そのものが停止したわけではないとCloudflareは指摘しています。
Cloudflareが解析したYandexの2つのASの影響
Cloudflareは、Yandexに関連する二つの自律システム番号（ASN）について、Cloudflare RadarとBot Managementのデータを用いて影響を分析しました。この二つのASNはそれぞれ異なる役割を担っており、攻撃による影響も異なりました。
| ASN | 役割 | 攻撃前の自動リクエスト割合 | 攻撃後の主な影響 |
|---|---|---|---|
| AS13238 (Yandex Search) | 検索エンジンのクローリング | 99.5%（ほぼ全て検証済みボット） | 検証済み検索クローラーのトラフィックがほぼ消滅 |
| AS200350 (Yandex.Cloud) | クラウドサービスホスティング | 95.0%（全て未検証ボット） | 脆弱性スキャンなどは減少したが、大規模自動化は他プロバイダーへ移行 |
Yandex Searchのトラフィック減少は、主にWebページや画像のインデックス作成を行う正規の検索クローラーによるものでした。一方、Yandex.Cloudでは脆弱性スキャンなどの悪意ある活動は一時的に減少したものの、大規模な自動化された活動は消滅せず、他のホスティングプロバイダーへ移行したことが確認されています（Cloudflare）。
悪意あるボットは、Yandex.Cloudが使用不能になった後、自動的に他のクラウドホストへと移動したことがデータから示唆されています（Tom's Hardware）。
悪意あるボット活動への限定的な影響
攻撃前のCloudflareネットワーク全体における自動化されたリクエストは全HTTPトラフィックの36.1%、ロシアIPアドレスからのトラフィックでは35.8%を占めていました。Yandexのネットワークが容量を失うにつれてボットリクエストも減少しましたが、これはYandexからのトラフィックのほぼ全てが自動化されていたため当然の結果です。
重要なのは、悪意ある活動が停止したわけではなく、単にその発生源が移動したという点です。
- Yandex.Cloudのボットリクエストはソフトウェアアプリケーションのような挙動を示しており、JavaScript、Python、Goプログラムとして識別されるものが多く見られました。
- これらのボットは、ウェブサイトにデータを送信するリクエストが約3分の2を占めていました。
この分析結果は、悪意ある行為者が単一のプロバイダーに依存しておらず、インフラの冗長性や移行能力を有していることを示唆しています。物理的なインフラ攻撃だけでは、分散された悪意あるネットワークを完全に停止させることは難しい、という現実を突きつけられた形です。
エンジニア目線で見ると：クラウド分散とレジリエンスの重要性
今回のYandexデータセンターへの攻撃と、それに続くボット活動の移行は、クラウドインフラを運用するエンジニアにとって非常に示唆に富む事例だと感じます。物理的な攻撃でデータセンターがダウンしても、悪意あるボットネットワークが活動を継続できるのは、その設計に冗長性や自動移行の仕組みが組み込まれているからでしょう。
これは、SaaSプロバイダーやWebサービス開発者が、自身のサービスを運用する上で考慮すべき「レジリエンス」のレベルを再考させるのではないでしょうか。災害対策やマルチクラウド戦略は、これまで自然災害やサービスプロバイダーの障害に対するものと捉えられがちでしたが、今回の事例はサイバー攻撃や物理的なインフラ攻撃といった地政学的リスクにも対応する必要があることを示しています。
特に、AIを利用した自動化された攻撃や、分散型のアクティビティを設計する際には、今回の事例のような「サービス停止時の自動移行」の挙動を模倣するような仕組みも考えられるかもしれません。私の個人プロダクトでも、特定のクラウドプロバイダーに障害が発生した場合の自動切り替えや、コンテナオーケストレーションにおけるレジリエンス設計の重要性を改めて感じました。
単純なトラフィックの増減だけでなく、リクエストの振る舞いを分析することで、より詳細なインサイトが得られるというCloudflareのアプローチも非常に参考になります。これは、セキュリティ対策だけでなく、アプリケーションのパフォーマンス最適化やコスト管理にも応用できる知見だと考えます。
