CrowdStrikeのシステム障害をIT-BCPコンサルタントの視点で考える
掲載:2025年01月20日
執筆者:シニアコンサルタント 備酒 求
コラム

2024年7月に発生したCrowdStrike社のシステム障害は、世界中の約850万ユーザーのPCを最長10日間にわたって使用不能とし、未曾有の被害(推定8300億円)をもたらしました。更新版プログラム上のエラーにより発生したこの障害は、「IT-BCP」があれば被害を最低限に抑えることができたのか、考察します。
2024年7月19日に、米国のサイバーセキュリティ関連のビジネスを行う、CrowdStrike社が提供するCrowdStrike Falcon(以下、Falcon)の不具合が原因となって発生した障害(以下、 本障害)は、世界中の約850万台のFalconサービスを利用しているWindows PCをブルースクリーンの状態に至らしめ、使用不能に追い込みました。その結果、航空、金融、外食などのサービスが停止し、それら利用者にも影響が広まりました。
Falconを利用している企業視点で捉えると、本障害の特徴は、以下の通り整理できます。
- 自組織のコントロール外の原因で発生した、いわゆる外部委託リスクが顕在化した障害であること
- 多くのユーザーが使用しているWindows OSを搭載したPCに直接影響したことから、各組織の基幹業務に影響を及ぼした障害であること
- 全世界的に同時発生し、最長10日程度と、解消までに時間を要した障害であること
各組織では、こうした障害による影響の未然防止、また、影響低減のためにどのようなことができたのでしょうか。本稿では、「ITサービス停止に備えた対策の一つであるIT-BCPは、こうした世界同時に発生した重大なシステム障害にも有効か」という問いに対して考えます。 この問いについて考えることで、これからの時代に必要な本質的なIT-BCPについても提言します。
本障害の概要
本論に入る前に、今回の世界最大規模のシステム障害について振り返りたいと思います。
本障害は、2024年7月19日午後1時ごろ(日本時間)にCrowdStrike社がリリースした、CrowdStrike Falconの更新プログラムにロジックエラーがあったことが原因で発生しました。
この障害でFortune500に加盟する企業が被った金銭的被害は、米サイバー保険企業のParametrix Solutionsによると、54億USD(約8300億円)に及んだとのことです(※) 。具体的には、以下のような企業やサービスに影響を及ぼしました。
※ Parametrix. CrowdStrike’s Impact on the Fortune 500.
業界 | 企業名 | 影響(概要) |
---|---|---|
航空 | ジェットスター・ジャパン | 約20便が欠航 |
Delta Air Lines | 7月19日には5000便以上が欠航、4万便以上が遅延 7月22日には2200便以上が欠航し、3万便以上が遅延 |
|
金融 | ナショナルオーストラリア銀行やコモンウェルス銀行、ベンディゴ銀行など、特にオーストラリア | オンラインサービスが停止 |
サービス | スターバックス | モバイル注文が数時間にわたり受け付けられない状態が継続 |
本障害は、復旧までにも長い時間を要したことも特徴の一つとして指摘できます。同社の発表によると、障害から10日が経過した2024年7月29日時点で、ようやく障害による影響を受けたPCの約99%が復旧したとのことです。
IT-BCPは本障害にも有効か
利用しているほぼ全てのPCがアプリケーションに起因して立ち上がらなくなることは、多くの民間企業において「そんなことは起きないだろう」という盲点でした。マルウェア感染した際に多数のPCを初期化して設定する、という近い観点はあったと思いますが、アプリケーションそのものに欠陥がある状態だと、さらに対応が困難になります。また、多くの企業のこれまでの対策は、サーバ側の対策に注力してきて、PC側を軽視してきた状況があるのは否定できないでしょう。「PCは代替機に交換すればよい」程度に思っている企業は多いのではないでしょうか。
では、こうした大規模なシステム障害に対して、Falconを利用していた各組織では、どのような対策が可能だったのでしょうか。
残念ながら、被害を完全に食い止めることはできなかったといえますが、IT-BCPの取り組みで、一定程度は影響を最小化することは可能だったでしょう。少し大胆な提言も含まれますが、IT-BCPの本質である、「インシデントを起こさないための対策」と「インシデントが発生した後の対応」の2つの観点に沿ってみていきます。
インシデントを起こさないための対策
通常、インシデントを起こさないための対策として考えられるのが、以下3点になりますが、いずれも今回のシステム障害の対策としては実現性は限りなく低いといえます。
- A)Falconではないセキュリティソフトを活用する
- そもそもセキュリティソフトの稼働継続は、OSとEDRのベンダーに依存するものであり、彼らに発生を抑止する責任があります。したがって、利用ユーザー側で発生可能性を低減するために実行できることは「Falconを利用せず、別のベンダーのセキュリティソフトを活用する」ということになります。しかしながら、当然別のベンダーでトラブルを引き起こす可能性もあり、根本的な対策にはなりません。
- B)テスト環境にて安全性を確認し、本番環境に適用する
- また、テスト環境と本番環境を構築しておき、アップデートファイルを先にテスト環境に適用し問題がないか確認する、という手法も今回は考えにくいといえます。Falconはセキュリティソフトであることから、その更新が自動で、かつ頻繁に行われます。こうした高い頻度で行われる更新に対し、ユーザー側での制御は不可能だったといえます。
- C)シンクライアント環境を用意する
- シンクライアントであっても、VDI等の構成に様々なアプリケーションを搭載することが必要です。本障害はアプリケーションの障害であったため、シンクライアント環境の提供は今回の障害の影響度を下げることにはならないといえるでしょう。
上記を踏まえると、利用ユーザーである企業が事前対策として実施できることは、極力デバイス側に様々なアプリケーションを載せない、また、万が一何かがあっても、すぐに代替可能な設計思想を採用する、ということでしょう。
その一例として、Chromebookの活用が挙げられます。Chromebookはハードからアプリケーションまで同一ベンダーによる提供で、機能をクラウド側に載せる極めてシンプルな作りです。今回のようなアプリケーション起因によってOSが立ち上がらないという問題が発生する可能性は極めて低いでしょう。また、デバイス側に問題が発生した際にも、ブラウザベースのOSということから容易に別OSを搭載したPCやタブレットデバイスで代替が可能です。
とはいえ、クラウド側で問題が発生し、業務停止に追い込まれる懸念があります。その議論については、マルチクラウド対応の範疇であり、既知の課題でもあるため今回は言及しません。
インシデントが発生した後の対応
インシデントが発生した後のユーザー側での対応は、障害への対応策の情報収集から始まりますが、本障害では、その始動が遅れざるを得ない事情がありました。CrowdStrike社から対応策が正式リリースされたのが、インシデント発生から3日後だったからです。
こうした事情を踏まえると、ユーザーはメーカー側から対応策が出ない間に応急処置的な対応をすることを前提としておくことが求められます。例えば、3日間の間に、タブレットなど影響を受けないデバイスで対応をすることを検討することや、障害対応策がリリースされた際に迅速な対応ができるような態勢を構築することなどが考えられます。
また最近では、これまでのような、ハードウェアの冗長化、ネットワークの冗長化、仮想マシンなどOSレベルでの冗長化に加え、アプリケーションレベルで冗長化を行う製品が登場しています。例えば、NeverFail社によるNeverfail Continuity Engine(CE)は、アプリケーションレベルの障害を検知した際に、迅速な切り替えを実現できるとのことです。こうした製品の導入についても、有効であると考えられます。
本障害の教訓および企業が取り組めること
以上のような有事対応を円滑に行うには、平時からの備えが不可欠です。各企業が取り組める備えは、以下3点にあるといえます。
◉リスクアセスメント、BIA(ビジネスインパクト分析)の実施
本障害の教訓の一つには、やはり想定外は発生する、ということが挙げられます。本障害での想定外とは、組織内の全PC自体が同時に使用不可になるという事態の発生です。
これを受け、利用ユーザーは、本障害を具体事例とした、リスクアセスメントや、BIAを実施することが有効だといえます。つまり、PC自体の利用が一定程度不可能になる原因と発生可能性を明らかにし、ChromebookやNaverfail Continuity Engine(CE)などの対策導入要否を、費用対効果などを踏まえ意思決定することです。
◉組織としてのレジリエンスの強化、大規模障害時の運用プロセスの見直し
今回の障害は、極めて想定が難しいインシデントでしたが、本障害以上の長期間にわたる障害やインシデントが発生する可能性もあります。組織においては、こうした事象においても対応できるような、レジリエンスを身に着けることが重要です。
本障害で求められるレジリエンスとは、具体的には以下の内容が挙げられます。
# | 必要なアクション | 概要 |
---|---|---|
1 | インシデントおよび影響範囲の迅速な検知 |
|
2 | インシデントを受けた迅速な社内外コミュニケーション |
|
3 | インシデントへの対応方針の検討~実行 |
|
4 | 復旧~切り戻し | ー |
こうしたレジリエンスは、ビジネス部門による業務の切り替えを含むため、IT部門単独の取り組みでは有効ではないことが明らかです。また、代替策の実行判断には、投資判断やステークホルダーへの甚大な影響も想定されます。したがって、レジリエンスの向上を組織全体の課題として捉え、トップマネジメントの関与を得て、レジリエンス強化を経営戦略の一部として位置づけることが重要だといえます。平時より、トップマネジメントからビジネス部門までを巻き込んで、こうした対応~意思決定への一連の流れを習熟しておくことが、レジリエンス向上につながるといえるでしょう。
加えて、本障害を一事例として、運用プロセスを見直すことも有用といえます。つまり、現行のシステム運用プロセスの不足点について、本障害をシナリオとして検証し、特定することが該当します。
◉BCPとIT-BCPの改訂
ここまでの検討結果を、BCPやIT-BCPに取り込むことで、レジリエンスを強化した対応方針が確立されます。まずはBCP / IT-BCP文書に、見直し結果を反映し、その内容をもとに、継続的な訓練・演習~見直しのプロセスを回すことで、想定外事象へも対応可能なレジリエンスを身につけることが可能になります。
最後に
本障害は、想定外の事象が長期間続いた結果、ビジネス継続に大きな影響が出たという点で、各社の対応が非常に困難だったものといえます。
こうした事象においても重要なのは、やはり組織一体となった、レジリエンスの向上です。ビジネス部門は、各部門が持つBCPで、PCなどの設備が使えないことも想定した対応策を検討し、その結果を踏まえ、情報システム部門が、IT-BCPでPC、基幹システムの予防策や代替策を検討します。これらの検討結果を踏まえ、訓練・演習を継続的に行うことで、想定以上の事象が発生したとしても対応することが可能になります。
対応が多岐にわたるからこそ、現状のBCPやIT-BCPの取り組みと連動させることで、効果的・効率的な取り組みを実現することができるでしょう。