Cloudflareの障害はセキュリティのロードマップとなるかもしれない

Cloudflareで火曜日に発生した断続的な障害により、インターネット上の多くの主要なサイトが一時的にオフラインになりました。一部のCloudflareの顧客は、訪問者が引き続き自社サイトにアクセスできるよう、一時的にプラットフォームから切り替えることができました。しかし、セキュリティ専門家によれば、これによりCloudflareに頼って多くの種類の悪質なトラフィックをブロックしていた組織に対して、思いがけないネットワーク侵入テストが発生した可能性もあるとのことです。

11月18日午前6時30分EST／11時30分UTC頃、Cloudflareのステータスページは「内部サービスの劣化」が発生していることを認めました。数時間にわたりCloudflareのサービスが復旧と停止を繰り返す中、多くのCloudflare利用サイトは、Cloudflareのポータルにアクセスできなかったり、DNSサービスもCloudflareから提供されていたため、同社のサービスから移行できない状況に陥りました。

しかし、一部の顧客は障害発生中に自社ドメインをCloudflareから切り離すことに成功しました。そして、そうした組織の多くは、その期間中のWebアプリケーションファイアウォール（WAF）のログを詳しく調べる必要があると、IANS Researchの教員であるAaron Turner氏は述べています。

Turner氏によれば、CloudflareのWAFは、アプリケーション層攻撃のトップ10（クレデンシャルスタッフィング、クロスサイトスクリプティング、SQLインジェクション、ボット攻撃、APIの悪用など）に該当する悪質なトラフィックをうまくフィルタリングします。しかし、今回の障害は、Cloudflareの助けなしで自社アプリやWebサイトの防御がどのように機能していないかを理解する良い機会かもしれないと述べています。

「開発者が過去にSQLインジェクション対策を怠っていたとしても、Cloudflareがエッジでそれらを止めてくれていました」とTurner氏は言います。「特定の項目について最高のセキュリティQA（品質保証）を行っていなかったかもしれませんが、Cloudflareがその補完的なコントロールレイヤーだったのです。」

Turner氏によれば、彼が関わっているある企業ではログの量が大幅に増加し、「本当に悪意のあるもの」と「ただのノイズ」とをまだ見分けようとしている最中だそうです。

「高い注目度のサイトが可用性のためにCloudflareをバイパスすることを決めた約8時間のウィンドウがあったようです」とTurner氏は述べています。「多くの企業は実質的にOWASP Top Ten（Webアプリケーション脆弱性）やボットブロックの多くをCloudflareに依存しています。そのウィンドウでどれだけ悪いことが起こり得たでしょうか？その決断をした組織は、Cloudflareの保護に戻した後も誰かが残っていないか、さらされたインフラを注意深く調べる必要があります。」

Turner氏は、サイバー犯罪グループの中には、普段監視しているオンラインショップが障害中にCloudflareのサービスを停止したことに気づいた可能性が高いと述べています。

「仮にあなたが攻撃者で、ターゲットに侵入しようとしていたが、これまでCloudflareが邪魔だったとしましょう」と彼は言います。「DNSの変更を通じて、障害のためにターゲットがWebスタックからCloudflareを外したことが分かれば、保護レイヤーがなくなったので新たな攻撃を大量に仕掛けるでしょう。」

バージニア州マクリーンに拠点を置くReplica Cyberのシニアプロダクトマーケティングマネージャー、Nicole Scott氏は、昨日の障害を「意図せずとも実施された無料のテーブルトップ演習」と表現しました。

「数時間のウィンドウは、組織が自らのコントロールプレーンをどう迂回し、シャドーITが時間的プレッシャーの下でどのように拡大するかのライブストレステストでした」とScott氏はLinkedInの投稿で述べています。「はい、防御が弱まった間に受けたトラフィックを確認してください。しかし、組織内部の行動もよく見てください。」

Scott氏は、Cloudflareの障害からセキュリティの洞察を得ようとする組織は、以下の問いを自問すべきだと述べています：

1. 何がオフまたはバイパスされたか（WAF、ボット保護、ジオブロックなど）、そしてどれくらいの時間だったか？
2. どのような緊急DNSやルーティングの変更が行われ、誰がそれを承認したか？
3. 障害を回避するために、個人デバイスや自宅のWi-Fi、非公認のSaaSプロバイダーに作業を移した人はいたか？
4. 「今だけ」として新しいサービス、トンネル、ベンダーアカウントを立ち上げた人はいたか？
5. それらの変更を元に戻す計画はあるか、それとも恒久的な回避策になってしまっているか？
6. 次回のインシデントに備え、分散的な即興対応ではなく、意図的なフォールバックプランがあるか？

火曜日の夜に公開された事後分析で、Cloudflareは今回の障害がサイバー攻撃や悪意ある活動によるものではなかったと述べています。

「代わりに、データベースシステムの権限に対する変更が引き金となり、当社のBot Managementシステムで使用される『フィーチャーファイル』に複数のエントリが出力されました」とCloudflareのCEO、Matthew Prince氏は書いています。「そのフィーチャーファイルが結果的に2倍のサイズになり、予想以上に大きくなったファイルがネットワークを構成するすべてのマシンに配布されました。」

Cloudflareは、全ウェブサイトのおよそ20％が自社サービスを利用していると推定しており、現代のウェブの多くがAWSやAzureなど少数のクラウドプロバイダーに大きく依存しているため、これらのプラットフォームの一時的な障害であっても、多くの組織にとって単一障害点となり得るとしています。

ITコンサルタントQuod OrbisのCEO、Martin Greenfield氏は、火曜日の障害は多くの組織が「卵を一つのカゴに入れすぎている」ことを改めて思い出させるものだと述べています。

「実用的かつ遅すぎた修正策はいくつかあります」とGreenfield氏はアドバイスしています。「資産を分割しましょう。WAFやDDoS対策を複数のゾーンに分散しましょう。マルチベンダーDNSを利用しましょう。アプリケーションをセグメント化して、単一プロバイダーの障害が連鎖しないようにしましょう。そして、単一ベンダー依存を検出するためにコントロールを継続的に監視しましょう。」