CrowdStrikeが進める「レジリエント・バイ・デザイン」とは？

2024年7月に発生した全世界的なWindows PCの停止原因となったのが、CrowdStrike社の製品です。この障害は、製品アップデートにおける見落としが原因であり、世界中の約850万台のPCが動作不能となる事態を引き起こしました。

この障害の反省を生かして、CrowdStrikeが進めているのが「レジリエント・バイ・デザイン」の取り組みです。レジリエント・バイ・デザインとはどのような取り組みなのでしょうか。また、企業はレジリエント・バイ・デザインをどのように参考にできるのでしょうか。この記事で解説します。

CrowdStrikeによる全世界的大規模障害の振り返り

まず初めに、CrowdStrikeによる大規模障害の振り返りとして、経緯と影響、障害の原因をまとめます。

経緯と影響

2024年7月、CrowdStrike社の製品を利用しているWindows PCにおいて、原因不明のBSOD（ブルースクリーン・オブ・デス）が一斉に表示され、利用できなくなるという障害が発生しました。このシステム障害は世界中の約850万台のコンピューターが影響を受け、公共機関や交通、インフラなど、あらゆる領域の業務に影響を与えました。

CrowdStrikeは、2012年に設立された米国テキサス州本社のセキュリティソフトウェアベンダーです。年間30億ドルの売り上げを誇り、世界有数のIT企業としてその名を知られています。同社では「Falcon」という名のエンドポイントセキュリティサービスを提供しており、高い市場シェアを有しています。

障害の原因となったのは、この「Falcon」でした。今回の大規模障害は、発覚後約1時間半続きました。MicrosoftとCrowdStrikeは共同でアップデートの取り下げ、復旧ツールの公開、及び最大限のサポートを提供し、迅速に事態の収拾に向けて動きました。

インシデントによるシステム停止は約1時間でしたが、完全な復旧には手動操作が必要であり、その間の損失は莫大なものとなりました。事件の経済的損失は約50億ドル（日本円で7,500億円以上）とされ、エンドユーザーの損失も踏まえるとさらに大きな影響が考えられます。

障害の原因

世界中のWindowsでブルースクリーンエラーを招いたこの事件では、システム障害がWindowsのマシンに限定されていたことから、当初はMicrosoft側に問題があると考えられていました。しかし調査を進めるにつれ、明らかになったのがCrowdStrike社のソフト「Falcon」の存在です。被害が確認されたのは、Falconの最新アップデートが適用された際にオンラインだった端末でした。このアップデートには重大エラーが見過ごされており、パッチを適用したマシン上で障害が発生しました。

当初はサイバー攻撃も疑われた今回の事件でしたが、蓋を開けてみれば配信前の不十分な検証に起因する、セキュリティベンダーの過失による大規模インシデントだったのが顛末です。

CrowdStrikeによる大規模障害の詳細については、こちらの記事で解説しております。併せてご覧ください。

CrowdStrikeによるフレームワーク「レジリエント・バイ・デザイン」

障害の発生原因を踏まえ、CrowdStrike社では「レジリエント・バイ・デザイン」というフレームワークに基づき再発防止策を進めています。レジリエント・バイ・デザインとはいったいどのようなものなのでしょうか。

レジリエント・バイ・デザインはセキュア・バイ・デザインの発展版

レジリエント・バイ・デザインを理解するために前提となるのが、セキュア・バイ・デザインについてです。

セキュア・バイ・デザインとは、システムやソフトウェアの設計段階からセキュリティを組み込むアプローチのことです。従来の「後付け」でセキュリティ対策を行う方法と異なり、初期の設計フェーズから脅威を考慮し、セキュリティ機能を統合することで、より堅牢で安全なシステムの構築を目指します。

近年では、このセキュア・バイ・デザインの考え方が採用されるケースが増えています。たとえば、IPA（独立行政法人情報処理推進機構）では、セキュリティ・バイ・デザイン「システム開発のセキュリティ向上0.0」^※1として、セキュア・バイ・デザインのガイドラインを提供しています。また、デジタル庁では政府情報システムの開発におけるガイドラインとして「セキュリティ・バイ・デザインガイドライン」^※2を作成しました。

※1：IPA「セキュリティ・バイ・デザイン「システム開発のセキュリティ向上0.0」」
※2：デジタル庁「政府情報システムにおけるセキュリティ・バイ・デザインガイドライン」

CrowdStrikeが考えるレジリエンス

レジリエント・バイ・デザインはこのセキュア・バイ・デザインの発展形ととらえると理解しやすくなります。

そもそもレジリエンスとは、回復力を示す言葉です。障害が発生した際に迅速に復旧し、システムの稼働を維持する能力を高めることで、システムの停止やサイバー攻撃を受けた際にも、迅速に復旧を行い、影響を最小化します。

レジリエント・バイ・デザインでは、セキュア・バイ・デザインにおけるソフトウェアの設計段階からのセキュリティ強化に加えて、レジリエンスの強化も考慮します。これにより、今後同様の障害を発生させないことだけでなく、障害発生時の復旧速度を高められるようにします。

レジリエント・バイ・デザインの3つの柱

CrowdStrike社によれば、レジリエント・バイ・デザインの考え方は大きく3つの柱で構成されます^※3。

※3：CrowdStrike Blog「Recognizing the Resilience of the CrowdStrike Community」

レジリエンスを基盤的要素と位置づける

CrowdStrike社では、レジリエンスをプロダクト開発の基礎要素として位置づけています。同社では、プロダクト開発のあらゆる場面においてレジリエンスの強化に焦点を当てています。障害発生後、プロダクトのコードや展開、構成、運用サポートまで、あらゆる側面でレジリエンスを強化する取り組みを続けています。

顧客ごとに適応させる

レジリエンスの強化にあたっては、顧客のニーズに合わせた対応が重要です。このとき、すべての顧客に同じ対応ができないことを認識する必要があります。業界・業種ごとに、顧客は多様なニーズを持ちます。たとえば、金融業界は製造業とは異なるニーズを持ち、ヘルスケア業界は公共事業と異なります。

CrowdStrike社では、この多様性に対処するためにレジリエンス強化の取り組みを顧客ごとに調整し、顧客のニーズに合ったセキュリティソリューションと成果を提供することを重要視しています。

持続的な取り組みとする

レジリエンスを強化するためには、継続的な学習と改善を可能にするフィードバックの取り組みが必要です。顧客や業界から学んだことを、自社の製品開発に取り入れるようにします。CrowdStrike社では常にプロダクトの動作環境を監視し、進化するサイバー脅威を観察し、悪意のある攻撃者の戦術とテクニックを理解し、技術から学び、適応することを重要視しています。

開発から運用まで、すべてのプロセスにわたって継続的な改善を重視することで、レジリエンス強化の取り組みを一時的なものとせず、変化するサイバー脅威に適用することができます。

このように、CrowdStrike社ではレジリエント・バイ・デザインの考え方をあらゆるプロセスとあらゆる活動に組み込むこととしています。これにより、同社では最も回復力のあるソリューションを作成することを目指しています。

レジリエント・バイ・デザインの考え方は企業も参考にすべき

近年では、耐障害性のみならず、ITシステムのレジリエンスが意識されるようになりました。CrowdStrike社のレジリエント・バイ・デザインという考え方は、ITシステムの提供企業のみならず、ITシステムのユーザー企業にとっても有用だと考えられます。以下では、レジリエント・バイ・デザインを企業に取り込む際のポイントを「システム開発フェーズ」「運用設計フェーズ」「運用フェーズ」のそれぞれに分けてご紹介します。

システム開発フェーズ

システム開発フェーズでは、障害が起きにくい構成にすることはもちろん、障害発生時の復旧力を高めるための取り組みを行います。

〇リスクコントロールの実施

レジリエンスを高めつつ、開発コストが無尽蔵に費やされることを防ぐために、要件定義フェーズなど上流工程にてリスク分析を行い対応すべきリスクを特定します。障害発生時の影響度合いに加えて、障害発生時にどのように復旧を行うことができるか、またその時間はどの程度必要かまで考慮したうえで、優先順位を決定します。

〇保守性の向上

システム内におけるバグの発生は可能な限り避けなければなりません。特に注意すべきなのが、システムの保守性です。当初開発時は十分に時間をかけてテストを行い、またリリース当初は運用体制も手厚く設定しますが、システムの改修時にはどうしても手厚い対応は難しくなります。この時、人的なミスにより障害が発生しやすくなります。

これを防ぐためには、プログラムの保守性を高め、プログラム起因によるバグを減らすことが重要です。

運用設計フェーズ

運用設計フェーズにおいて、システムのレジリエンスを高めるために有効な取り組み例は以下のとおりです。

〇対外調整

システム内部ではなく、連携先のシステムなどに起因して障害が発生するケースもあります。如何にシステムの品質を高めても、このような外的要因は防ぎきれません。

外的要因に起因する障害は完全に防止できないため、障害が発生することを前提に、できる限り復旧速度を高めることがポイントとなります。システムの連携先との事前調整や、連携先も含めた障害発生時の対応訓練の実施などが有効な対応となります。

〇リスクの事前予測

いざ障害が発生すると、対応に追われ最適な行動をとることは難しくなります。運用設計段階で十分にシナリオ分析を実施し、起きうる障害とそれに対する最良の結果、最悪の結果、最も可能性の高い結果を整理し、各結果に応じた対応計画を作成します。

〇自動化の活用

運用手順書の作成時には、どうしてもリスクに対する対処が重視されない傾向があります。また、既存のツールに依存し、自動化が進まないというケースも見られます。

運用設計時には、リスクとコンプライアンスを意識しつつ、可能な限り自動化を進めることがポイントです。

運用フェーズ

実際に運用を行うフェーズにおいては、障害の早期検知と早期復旧がポイントとなります。

〇モニタリングによる早期検知

システム運用時には一般的に運用監視ツールによりモニタリングを行いますが、近年ではより迅速に対応を行うことができる機能を持った運用監視ツールも登場しています。たとえば、AIOpsとしてAI機能を活用した運用の効率化や、アラートの高精度化といった取り組みも有効でしょう。

運用監視ツールのアップデートにより、障害発生時の早期検知を実現できる可能性が高まります。

〇対応と復旧

障害が発生してから対処するのは最悪の方法です。関係者間の連携不足や不正確な情報によって、誤った対応につながるおそれがあります。

障害発生時に冷静に対応するためにも、事前に作成した対応手順に基づき、できるだけ手順に沿った対応を行うようにします。

継続的な改善

レジリエンスを高めるためには、障害発生後の振り返りも含め、継続的な改善が有効です。

〇振り返りの実施

システム障害から復帰した後は、その経験を次回の対応に生かすべく、振り返りを行います。振り返りミーティングにてシステム障害において得られた知見を共有し、対応計画を改善することで、次回の障害に対処しやすくなります。

〇障害内容の分析とリスクの再評価

次回も同じ障害が起きるとは限りませんが、障害発生時の事象からは多くの教訓を得ることができます。障害内容の分析を踏まえ、システムの運用における主要なリスクを再評価し、想定される回避策を実施することで、今後の障害を発生させない、もしくは障害発生時の対応速度を向上させることを目指します。

まとめ

この記事では、CrowdStrikeが進める「レジリエント・バイ・デザイン」の取り組みについてご紹介しました。記事中でご紹介した通り、レジリエント・バイ・デザインの考え方は、企業において非常に参考になるものです。デジタル技術が重要視される現代において、システムの安定稼動は何より重要な要素となります。レジリエント・バイ・デザインの考え方を参考に、自社のシステムのレジリエンス向上について考えてみてはいかがでしょうか。