CrowdStrikeが「想定外の障害」を防げなかった“本当の理由”：CrowdStrikeから学ぶソフトウェアテストの教訓【前編】

システム障害は技術的な問題ではなく、テスト戦略の欠如が原因で発生することがしばしばある。CrowdStrikeによる「Windows」障害もその例だ。現代のシステム運用が抱える、ソフトウェアテストの根本的な課題とは。

[Matt Heusser，TechTarget]

　2024年7月、セキュリティベンダーCrowdStrikeのエンドポイントセキュリティツール「CrowdStrike Falcon」が、MicrosoftのOS「Windows」を搭載した世界各地のデバイスにシステム障害を発生させた。その事件からある程度時間がたった。全てのソフトウェア開発者にとって、このインシデントを振り返ることには意義がある。CrowdStrike事件では何が起きたのか。なぜ起こったのか。そこから得るべき教訓とは何かを考えるために、まずは“事件の真相”に迫る。

CrowdStrikeの障害で何が起きたのか

併せて読みたいお薦め記事

CrowdStrikeの障害から考える

• “社内システム停止”でも慌てない　緊急時コミュニケーション8つの鉄則
• あのWindows障害がもう「CrowdStrikeだけの問題」ではない理由

　「アンチマルウェア」（「アンチウイルス」とも）など、セキュリティソフトウェアは通常、マシンの機能を制限なく利用できる「カーネルモード」で実行する必要がある。通常のアプリケーションのように「ユーザーモード」で実行すると、マルウェアがセキュリティソフトウェアを見つけて上書きしたり、破壊したりする危険性があるからだ。

　今回の問題は、CrowdStrike FalconがOSの中核である「カーネル」で動作することが原因となって発生した。カーネルはOSに対して非常に強い操作権限を持ち、通常の権限では操作できないメモリや記憶領域を操作できる。

　CrowdStrikeのレポートによると、CrowdStrike Falconのクラッシュを引き起こしたのはセンサー（エージェントソフトウェア）本体のソースコードの変更ではなく、センサーの設定更新「Rapid Response Content」だった。Rapid Response Contentはカーネルモードで実行されていたため、Windowsが例外としてキャッチできなかった。CrowdStrike FalconはOS起動時にマルウェアをスキャンするため、単純な再起動では問題を解決できなかった。OSとして「macOS」もしくは「Linux」を搭載するデバイスは、カーネルモードでセキュリティソフトウェアを実行しないため、今回のシステム障害で影響を受けなかった。

CrowdStrikeの障害の影響は？

　世界全体を機能不全に陥れたCrowdStrikeの更新は、Microsoftによれば、影響を受けたのは世界中の全Windows搭載デバイスの1％未満だった。とはいえ2023年の時点で、セキュリティソフトウェア市場におけるCrowdStrikeのシェア率は15％を超えていた。ミッションクリティカルなPCがCrowdStrike Falconを使っていた可能性は否定できない。

　2024年7月19日（現地時間）、米国の主要航空会社、病院、911（警察・消防への緊急通報）、地方政府機関、州政府機関、連邦政府機関において、Windowsを実行するサーバやPCにアクセスできなくなり、大規模な障害が発生した。特に大きな影響を受けたのはDelta Air Lines（デルタ航空）で、システム障害によって5日間に約7000便が欠航、総額5億ドルの損害を被ったという報道がある。

　障害リスク評価ベンダーParametrix Solutionsによると、経済誌Fortuneが発表する企業の売上高ランキング「Fortune 500」に名を連ねる企業の中でMicrosoftを除き、今回の障害の直接的な損害額の見積もりは少なくとも54億ドルだ。これには、企業ブランドへのダメージや、売り上げの機会損失は含まれていない。

レポートと根本原因分析から読み解く教訓

　私から見れば、CrowdStrikeのインシデントレポートは、複数の解釈ができる専門用語を使用しており、多少の曖昧さが残る。とはいえ、以下の点は明確だ。

　CrowdStrikeは、Windowsのカーネルモードで実行されるプログラムの変更と、ソフトウェアの更新プログラムを配信している。更新には2種類ある。1つ目は、重大なセキュリティ脆弱性に緊急対応するためのもので、これがRapid Response Contentに当たる。2つ目は、厳格な品質保証プロセスを踏む定期的な更新だ。Rapid Response Contentは極めて重要なため、通常の段階的な展開プロセスを省いて、一斉配信される。更新の配信プロセスにおいては、事前検証にかかる時間と緊急性のバランスを取るということだ。しかし皮肉なことに、今回のシステム障害は、Rapid Response Contentとして配信されたものだった。

　問題の所在は明白だ。CrowdStrikeは、テストシステムにバグがあったと説明している。同社はレポートで「Content Validator（コンテンツ検証システム）のバグによって、問題のある更新データがあったにもかかわらず検証をクリアした」と述べている。これは奇妙な説明だ。本質的には「テストが更新データの問題を見逃したという問題」を、「テストシステム自体の問題」として表現しているからだ。

　CrowdStrikeが2024年8月に発表した根本原因分析レポートによると、次の技術的問題があった。

• ワイルドカード（不特定の文字列を指定するための記号）を使ったパターンマッチング（データから文字列といったパターンを特定し、似ているパターンを探す方式）は実施したが、完全一致でのテストが不十分だった
• プログラムが想定していた入力値と、実際に送られてきた値に不一致があった。その結果、境界外メモリ状態（プログラムがアクセスを許可されていないメモリ領域にアクセスしようとした状態）が発生した

　レポートを見ると、根本的な原因は1つではなく、一連のエラーが連鎖していることが読み取れる。

1. テストデータそのものに不備があった
2. テストケースに漏れがあった
3. 適切なエラー処理が実装されていなかった

　CrowdStrike Falconの更新プログラムは配信方式が一斉配信のみであり、ユーザー企業は段階的な配信を選択できなかった。今回のような「偶然の重なり」は極めてまれで、そうそう直面しないと考えることはできるが、別の見方もできる。スペースシャトル「チャレンジャー」号の爆発事故の分析によると、システムは優れた保護機能を備え、冗長性があり、厳格な安全基準に従っていた。だがルールが厳格過ぎたため、現場はルールから少し外れた例外を日常的に許容してしまっていた。これは「逸脱の常態化」という現象だ。

　レポートでは改善案として、「ローカル開発者のテスト」や「コンテンツの更新とロールバックのテスト」が挙げられている。これから分かるのは、開発者がテストしていなかったという事実だ。プログラミングできる開発者が、物理PCであれ仮想マシンであれ、更新をテストしていれば、問題に気付き、防ぐことができたはずだ。

---

　次回は、CrowdStrikeのシステム障害を受けて、ソフトウェア開発者が実施すべきことについて考える。

TechTarget発　エンジニア虎の巻

米国TechTargetの豊富な記事の中から、開発のノウハウや技術知識など、ITエンジニアの問題解決に役立つ情報を厳選してお届けします。