CrowdStrike障害で学ぶべきは「テストの見直し」だけではない：「完全に自動化されたシステムであっても発生する可能性がある」

TechTargetは「CrowdStrikeの障害から考えるソフトウェアテストの課題」に関する記事を公開した。2024年7月にCrowdStrikeが引き起こしたような障害を回避するためには「速度、安定性、アクセス、セキュリティの間でバランスを取ることが重要だ」と有識者は指摘している。

[Beth Pariseau，TechTarget]

　TechTargetは2024年7月2日（米国時間）、「CrowdStrikeの障害から考えるソフトウェアテストの課題」に関する記事を公開した。

ソフトウェアテストのジレンマを浮き彫りにしたCrowdStrikeの障害（提供：TechTarget）

　2024年7月中旬、CrowdStrikeのアップデートによって「Windows」を搭載したPCや関連するシステムが大規模に停止したことを受け、CrowdStrikeはソフトウェアテストを改善すると約束した。しかし、「今後発生し得るインシデントを回避するのは容易ではない」と、有識者たちは語る。

問題はソフトウェアテストの手順？　範囲？

　CrowdStrikeは今回のインシデントに関する「予備レビュー」を公開した。それには、アップデートの検証ツールにソフトウェアバグがあり、それが障害を引き起こしたことが詳述されている。また、今回の原因となったアップデートは、メインのコードベースやOSのカーネルドライバーに対するものではなく、「Rapid Response Content」というテンプレート内の構成データに対するアップデートだったと報告されている。

　CrowdStrikeの報告によれば、Rapid Response Contentの役割は、システムに侵入する新たなサイバー脅威を「運用速度」で監視することだ。このファイルはCrowdStrikeのコアアプリケーションよりも頻繁に更新されるため、テストプロセスは限定的なものとなっていた。しかし、CrowdStrikeは今回のインシデントを受け、Rapid Response Contentに対しても「カナリアデプロイメント」を含む、コアアプリケーションと同じテスト手順を適用すると約束した。

　Rapid Release Contentのアップデートは、Windows OSに直接アクセスするにもかかわらず、テストが不十分だった。「こうした、すべきではなかった多くのことを、CrowdStrikeは正しく修正している」と、あるソフトウェアエンジニアは評価している。Veradigmのカイラー・ミドルトン氏（シニアプリンシパルソフトウェアエンジニア）は「こうした問題は、わずか1分間のテストでも発見できただろう。そのために（アップデートが）1分間遅れたとしても、許容範囲だと思う」と述べている。

　IT市場全体において、ソフトウェアテストとその範囲が不十分であることが指摘されている。例えば、米国連邦通信委員会の報告書によると、2024年2月に発生したAT&Tのモバイルネットワーク障害は、ネットワーク構成のアップデートが同社独自の社内テスト手順に従わずに実施されたことが原因だった。

　これはIT業界において特別な事例ではない。調査会社IDCが2024年6月に実施した調査「DevOps Practices, Perceptions, and Tooling」（DevOpsのプラクティス、認識、ツール）では、調査に協力した300社の企業のうち、ソフトウェア品質テストを自動化していたのは44％。DevOpsパイプラインのボトルネックに「テスト」と「品質保証（QA）」を挙げた企業は27.3％だった。

　IDCのアナリスト、ケイティ・ノートン氏は「テストがアプリケーション開発における大きな摩擦点であることに変わりはない。QAスタッフの不足やソフトウェアの複雑化が進む中で品質を確保するには、アジャイルかつ継続的な品質イニシアチブによる自動化が不可欠だ」と述べている。また、IDCが実施した他の調査では生成AI（人工知能）の有望な用途の一つとして、ソフトウェアテストが挙がっているという。

　「今後数年間でこうした統計は改善されると期待している。しかし、そうなったとしても、ポリシーや手順の不備、もしくは『それらに従わない』という問題をAIが解決するわけではない」（ノートン氏）

速度、安定性、セキュリティのバランスを取る

　ミドルトン氏をはじめとする業界関係者は、CrowdStrikeの障害は単にソフトウェアテストに不備があったからとは考えていない。「ソフトウェア開発者がリリースをテストする際に考慮すべき複雑な要素が絡み合ったもの」と指摘している。

　今回の障害は、複数のバグが重なった結果として発生した。まず、Rapid Response Contentの構成テンプレートに欠陥があり、その欠陥を検出すべきだった検証ツール自体にも問題があった。理論上、システムファイル自体のアップデートよりもシステムクラッシュのリスクは低いとされていたが、これがインシデントの原因になった。ESG（Enterprise Strategy Group）のアナリスト、ゲイブ・クヌース氏はそのように説明している。

　「完全に自動化されたシステムでも、開発からリリースに至るプロセスはソフトウェアに依存しているので、このような問題が発生する可能性がある。CI／CD（継続的インテグレーション／継続的デリバリー）パイプラインのどこかにバグがあれば、今回のようなインシデントが起こる可能性がある。テストソフトウェア自体のバグを検出するためには、そのテストソフトウェアをテストする必要がある。だが、そのテストソフトウェアも結局はソフトウェアだ。この関係性には終わりがない」

　ソフトウェアのテスト範囲を決定する際には「リスク評価」が重要な役割を果たす。この評価は、システムの安定性と、急速に出現するセキュリティ脅威に迅速に対応するためのアップデート速度のバランスを取るものだ。

　クヌース氏は「数百万台のエンドポイントをクラッシュさせ、世界的な混乱を引き起こすバグと、知的財産や個人情報、国家機密の漏えいにつながる脆弱（ぜいじゃく）性では、どちらがより深刻かを判断しなければならないということだ」と説明している。

　先のインシデントは航空会社のフライト停止や病院システムに影響を及ぼし、企業は大きな打撃を受けた。だが、ミドルトン氏は「それでも多くの企業にとっては、セキュリティ侵害による脆弱性を放置する方がリスクが大きい」と指摘する。

　「企業は、マルウェアによって機密情報が流出するリスクよりも、セキュリティツールの不適切なアップデートによって可用性に問題が生じるリスクの方を受け入れるだろう。外部から見るとどちらも同じ『サービスが利用不可になる』という状況だが、企業の内部から見ると全く異なる状況だ」（ミドルトン氏）

　同氏によると、サービスの可用性が低下すれば一時的に収益に影響が出るものの、マルウェアによるデータ流出は訴訟や企業イメージの失墜など、さらに重大な影響を及ぼし得る。企業にとっては、アップデートの不備によって可用性が損なわれるとしても「マルウェアに侵害されるよりは、まし」ということだ。

　「ソフトウェアテストの範囲を広げることにはリスクが伴う。そもそも今回のインシデントの原因となったアップデートは、マルウェアの脅威に迅速に対応するためのものだ。（テストの範囲が広がることで）そういった対処がわずかに遅れるだけでも、企業の重要なサーバが感染する可能性がある」（ミドルトン氏）

カナリアデプロイメント以上の対応を求めるIT担当者

　CrowdStrikeが今回のインシデントに対応するために発表した予備報告書によれば、同社は今後、更新頻度の少ないアプリケーションと同様に、Rapid Release Contentファイルにもカナリアデプロイメントを適用する予定だ。カナリアデプロイメントであれば、アップデートに欠陥があったとしても、全てのPCに影響が及ぶことは防げるため、一部の企業に一定の安心感をもたらすと思われる。

　通信ネットワークプロバイダーSPS Commerceのアンディ・ドメイアー氏（シニアディレクター）は次のように述べている。

　「CrowdStrikeは『Rapid Response』（即時対応）を掲げているにもかかわらず、エンドポイントの健全性を確認する段階的なアプローチを用意していなかったことに非常に驚いている。顧客の重要度に応じて優先順位を付けるだけでも、健全性に問題を引き起こすデプロイメントを早い段階で停止できる回路遮断装置（サーキットブレーカー）になる。例えば、航空会社など重要度の高い顧客へのアップデートは、他の顧客のエンドポイントの健全性が確認され、信頼度が向上するまでは実施すべきではない」

　カナリアデプロイメントは有効な手法ではあるが、CrowdStrikeは自社のアプリケーションアーキテクチャ全体を見直すべきだという意見もある。専門家の中には、管理コントローラー、ハイパーバイザー、「eBPF」などの抽象層を設け、迅速なアップデートをOSカーネルから切り離すべきだと考える人もいる。

　WebOpsサービスプロバイダーPantheonのデビッド・シュトラウス氏（共同創設者、CTO＜最高技術責任者＞）は「カーネルモジュールのアップデートをグローバルに自動デプロイしながら、システムの健全性を維持するプロセスや、少なくともコントロールプレーンの下位レベルでの回復手段を持たないのは無責任だ。アップデート後にOSがクラッシュしても機能を維持できる何らかのシステムが必要だ」と指摘している。

　一方でシュトラウス氏は、CrowdStrikeのような高機能なマルウェア検出ソフトウェアを重要度の低いPCで使用していたユーザーにも一定の責任があると付け加えている。

　「航空会社のゲートターミナルのようなエンドポイントでCrowdStrikeのソフトウェアを使用するのは愚かなことだと思う。こうしたエンドポイントは特定の目的でしか使われないため、特権を制限し、整合性を確認すればセキュリティは確保できる。マルウェアの監視が意味を持つのは、特権の制限や整合性の確認ができないときだけだ。その場合でもエンドユーザーPCでのスキャンエージェントよりも『アプリストアを使う』『署名付きリリースをする』『OSを強制サンドボックス化する』などの対策の方が優れている」（シュトラウス氏）

「CrowdStrike障害」関連記事をTechTargetジャパンでもっと読む

米TechTargetや英Computer Weekly発の「CrowdStrike障害」関連記事が、TechTargetジャパンでも読めます。TechTargetジャパンで公開中の関連記事をピックアップして紹介します。

---

Windowsブルスクで世界が騒然――「CrowdStrikeの教訓」をIT運用にどう生かす？

CrowdStrikeの大規模障害は、世界中のユーザー企業やITベンダーに衝撃を与えた。同様の大規模障害が突然やって来る可能性を前にして、ユーザー企業やITベンダーはこの一件から何を学ぶべきか。

---

CrowdStrike、Microsoft 365の同時障害が「来たる試練の前触れ」だった訳

2024年7月にCrowdStrikeのソフトウェアが障害を引き起こすのと同じタイミングで、Microsoft 365にも障害が発生した。これら2つの障害は、今後忘れてはならないある重要な事実を浮き彫りにした。

---

---

TechTargetジャパンの会員登録はお済みですか？　会員登録をすることで、技術資料がそろったホワイトペーパーや興味・関心分野ごとに情報を配信するメールマガジン、特集記事がPDFでまとまって読める電子ブックレットなど、各種サービスを無料で利用できます（TechTargetジャパンサービス利用登録）。