概要
- Rackspace は 2022 年 12 月、自社の Hosted Exchange 環境に影響するランサムウェアインシデントを開示した。12 月 6 日の更新では、このインシデントによって Hosted Exchange 顧客のサービスが停止し、Rackspace は環境を隔離し、顧客の新環境への移行支援を開始したと述べられている。
- Rackspace の12 月 9 日の更新と関連するSEC Form 8-Kでは、CrowdStrike がこのインシデントは迅速に封じ込められ、ホスト型メールソリューションである Hosted Exchange（主に中小企業が利用し、Rackspace の収益の約 1％を占める）に限定されていたことを確認したと述べられている。
- 顧客への被害は、その収益シェアが示すよりも大きかった。メールは中小企業にとってオペレーティングシステムとも言える存在だ。顧客獲得、請求書、法的期限、患者の予約管理、サプライヤーの承認、給与に関する連絡、カレンダーの予定、添付ファイル、顧客記録など、すべてがホスト型メールボックスの中に存在している。
- Rackspace は顧客に対し Microsoft 365 への移行を促し、サポートスタッフを増強し、後日 PST ファイルによる段階的なデータ復旧を提供した。ステータス更新では、復旧は 2022 年 12 月 2 日以前の過去の Hosted Exchange メールデータに限られており、一部のメールやその他のデータが引き続き利用できない可能性があると警告された。
- その後の Rackspace の SEC 提出書類では、Hosted Exchange 事業がサンセット（終了）され、多くの顧客が Microsoft 365 に移行し、訴訟が提起され、Rackspace はインシデント費用、保険による回収、継続する法務・専門家費用を計上したことが明らかになった。したがって、このインシデントは単なる 12 月の停止ではなく、継続性責任の記録となった。
- Microsoft Exchange の脆弱性に関する文脈は重要だが、プロバイダーとしての説明責任を免れるものではない。Microsoft はCVE-2022-41040 および CVE-2022-41082を含む Exchange の脆弱性に関するガイダンスと更新を公開しており、その後の公開レポートやベンダー分析では OWASSRF や CVE-2022-41080 について議論された。Rackspace は依然としてホスト環境、パッチの判断、緩和策、バックアップ設計、顧客復旧プロセスを管理していた。
メールホスティング：小さな収益と大きな依存
Rackspace の公開情報から明らかなのは、Hosted Exchange が同社にとって大きな事業ラインではなかったという事実だ。12 月 6 日のインシデント更新では、Hosted Exchange 事業が Apps & Cross Platform セグメントで年間約 3,000 万ドルの収益を生み出していたと述べられている。12 月 9 日の更新と Form 8-K では、この事業が Rackspace の総年間収益の約 1％を占め、主に同製品のみを利用する中小企業で構成されていたと述べられている。投資家にとって、これは財務上の重要性を評価する材料となった。しかし顧客にとっては、依存の実質的な規模を見逃すものだった。
メールは、小規模企業にとって周辺的なアプリケーションではない。そこは、発注書が届き、法廷期日が議論され、患者の予約が確認され、請求書の処理が行われ、サポート依頼が処理され、従業員記録が交換され、保険書類が保存され、賃貸交渉が行われ、下請業者が添付ファイルを送信し、顧客が回答を期待する場である。カレンダーデータや連絡先データは、メッセージ本体と同じくらい重要であることが多い。中小企業は CRM や会計アドオンに 1 日アクセスできなくても、即席の対応が可能かもしれない。しかし、クリーンなバックアップ経路なしにメールとカレンダーを失えば、ほぼすべての関係が一度に混乱する可能性がある。
だからこそ、Rackspace のインシデントはクラウドサービス依存と SME サービス継続性の範疇に属するのだ。顧客がマネージドプロバイダーを選ぶ理由の一部は、Exchange を安全に運用することが難しいからだ。Microsoft Exchange Server は長年にわたり標的にされてきた歴史があり、小規模組織にとってセキュリティメンテナンスは容易ではない。ホスティングプロバイダーは、パッチ適用、監視、バックアップ、可用性、サポート、移行、インシデント対応といった運用負荷を引き受けると約束する。そのプロバイダーの環境がダウンした場合、顧客は自分で復旧させるための管理者アクセス権を持たない。
Rackspace の12 月 6 日の更新では、同社が主要なサイバー防御企業を関与させ、Hosted Exchange 環境を隔離し、この事象は Hosted Exchange に限定されていると考え、可能な限り迅速に顧客が新環境に移行できるよう、顧客とのコミュニケーションを開始したと述べられている。また、Rackspace はサポートスタッフを増強し、顧客をプロセスに導くための追加措置を講じるとしている。
これらの措置は必要だったかもしれない。しかし同時に、力関係の不均衡も示している。プロバイダーは環境を管理し、顧客は回避策しか管理できない。顧客は、指示があれば転送を設定し、サポートがあれば移行し、利用可能になれば復旧した PST ファイルをダウンロードし、代替チャネルを通じて連絡することができる。しかし、共有ホスト環境を復旧させたり、ランサムウェアの経路を調査したり、プロバイダーの証拠なしにメールボックスの完全性を証明したりすることはできない。
停止からランサムウェア、そして強制移行へと至った時系列
公開されたステータスの時系列が重要なのは、顧客が完全な説明を受ける前に不確実性を経験したからだ。Rackspace のシステムステータスページには、後に初期の更新が保存された。Hosted Exchange Issues ステータスページによると、Rackspace は 2022 年 12 月 2 日（金）に Hosted Exchange に影響する問題を認識し、重大度を評価しながら環境を予防的にシャットダウンして切断し、後にそれがセキュリティインシデントであると判断した。12 月 6 日までに、Rackspace はランサムウェアを公表した。
この一連の流れは、インシデント対応において珍しいことではない。初期の技術チームは、安全にランサムウェアと断定できる前に、ログイン障害、サービスの低下、不審な活動、システムの破損などを目にすることがある。しかし顧客にとっては、曖昧さの 1 時間 1 時間が重要である。裁判所の連絡を見逃す法律事務所、患者のメッセージを見逃す診療所、入札の質問を見逃す請負業者、ホリデーシーズンの注文を見逃す小売業者は、メールが復旧するかどうか、メッセージが安全かどうか、新しいサービスを有効化すべきかどうかを知る必要がある。
Rackspace の 12 月 6 日のプレスリリースでは、Hosted Exchange の顧客と継続的にコミュニケーションを取り、可能な限り迅速に新環境への移行を支援していると述べられていた。12 月 9 日の更新では、より明確に、Rackspace が影響を受けた顧客を Microsoft Office 365 に積極的に移行させており、既に多くの顧客が移行を完了していること、追加の増員スタッフや Rackspace の人員を補完する Microsoft Fast Track チームを含むリソースを提供していることが述べられた。
この対応により、インシデントは復旧イベントから移行イベントへと変化した。顧客は単にホストサービスの復旧を待っているのではなかった。彼らは異なるプラットフォームに移行させられたのだ。緊急時の移行は困難である。管理者は、新しいアカウント、ドメインレコード、DNS の変更、パスワード、デバイス、Outlook プロファイル、モバイルメールの再設定、共有メールボックス、配布リスト、カレンダー、アクセス許可、アーカイブ、保持ルール、ユーザーサポートを必要とする。計画的な移行であれば、すべてのタスクは管理可能である。ランサムウェアによる停止中は、それが危機対応となる。
したがって、重要な説明責任の問いは、Rackspace がより早くスイッチを切り替えるべきだったかどうかではない。むしろ、ホストサービスが信頼できる緊急脱出手段を備えて設計されていたかどうかである。ポータブルなメールボックスエクスポート、最新のバックアップ、テスト済みの移行ランブック、適切なサポート人員、顧客固有の所有権記録、DNS 変更ガイダンス、そして復旧可能な過去のメールに関する明確な期待値などである。
封じ込めは会社全体を守ったが、顧客は依然としてサービスを失った
Rackspace は封じ込めを強調した。12 月 9 日の更新では、CrowdStrike が、ネットワーク切断とインシデント対応計画に従った迅速な対応により、インシデントが迅速に封じ込められ、Hosted Exchange のみに限定されたことを確認したと述べている。他の Rackspace 製品、プラットフォーム、ソリューション、事業は影響を受けておらず、このインシデントによるダウンタイムも発生していないとされた。SEC Form 8-K でも同様のメッセージが伝えられている。
この区別は重要だ。ランサムウェアに直面したプロバイダーは、拡散を阻止するためにシステムを積極的に隔離する必要があるかもしれない。封じ込めは、影響を受けた顧客の可用性を悪化させる場合でも、セキュリティ上正しい判断となり得る。アップタイムを維持するために隔離を遅らせるプロバイダーは、侵害を悪化させる可能性がある。迅速に隔離するプロバイダーは、環境の残りの部分を救うことができるが、顧客を見捨てることになる。
説明責任の問題は、Rackspace が環境を隔離したことではない。問題は、その隔離によって、顧客が Rackspace 管理の復旧に依存していることが明らかになったことだ。Hosted Exchange の顧客は、移行するか、復旧作業を待つように言われた。彼らは、異なるバックアップスナップショットを選択したり、自分たちのデータベースをマウントしたり、Exchange サーバーを直接検査したりすることはできなかった。多くの顧客にとって、最も重要な運用資産は、プロバイダー管理のインシデントプロセス内に閉じ込められていたのだ。
これはクラウドサービスの中核的な教訓である。プロバイダーの封じ込めと顧客の継続性は、相反する方向を指し示す可能性がある。プロバイダーは攻撃者を阻止し、証拠を保全する必要がある。顧客は、コミュニケーション、メッセージフロー、過去のメール、カレンダー、連絡先、そして見積もりを必要とする。インシデント対応計画は、両方の目標に貢献しなければならない。もし計画がプロバイダーの企業だけを保護し、顧客の事業継続能力を保護しないなら、プロバイダーはセキュリティイベントを封じ込めたかもしれないが、事業中断を輸出したことになる。
Rackspace のステータス更新は、将来のメールのための Microsoft 365 移行、過去のメールのためのデータ復旧、そしてサポートリソースという並行パスを構築しようとしたことを示している。この分離は理にかなっていた。しかし同時に、当初の設計の限界も示した。将来のメールは、顧客が移行または転送した場合にのみ継続できた。過去のメールの復旧には、Hosted Exchange 環境からの入念な抽出と、段階的な PST の提供が必要だった。一部のデータは復旧できないままだった。これらの事実は、この製品がすべての顧客メールボックスに対してクリーンで即時のフェイルオーバーモデルを備えていなかったことを示唆している。
レガシーなホスト型メール製品であれば、それほど驚くべきことではないかもしれない。しかし、マネージドプロバイダーの顧客は、危機の前に継続性のトレードオフを理解する権利がある。製品が現代的な回復力を欠いているために安価なのであれば、顧客は知るべきである。バックアップが顧客のセルフサービスでないなら、知るべきである。ランサムウェアイベントが復旧ではなく移行を強いる可能性があるなら、知るべきである。
Microsoft Exchange の脆弱性に関する文脈は存在するが、限定的である
Exchange の脆弱性に関する文脈は、Rackspace のインシデントに不可欠である。Microsoft は 2022 年 9 月、Exchange Server の報告されたゼロデイ脆弱性に関するガイダンスを公開した。MSRC ブログでは、CVE-2022-41040 および CVE-2022-41082 を使用した限定的な標的型攻撃を認識しており、認証済みアクセスが必要であり、Exchange Online の顧客は措置を取る必要がないと述べた。Microsoft はその後、これらの脆弱性に対する Exchange Server の更新プログラムを適用することを強く推奨した。同社のセキュリティブログの分析では、SSRF とリモートコード実行の連鎖について説明し、初期の標的型攻撃に言及した。
Microsoft の2022 年 11 月 8 日の Exchange セキュリティ更新プログラム KB5019758は、CVE-2022-41040、CVE-2022-41082、CVE-2022-41080 を含む複数の Exchange 脆弱性を解決した。CVE-2022-41080 の NVD ページでは、これを Microsoft Exchange Server の特権昇格の脆弱性と特定しており、CVE-2022-41082 の NVDではリモートコード実行の脆弱性と特定し、CISA の既知の悪用された脆弱性カタログに含まれていることを指摘している。CISA の既知の悪用された脆弱性カタログは、組織が悪用された脆弱性に十分迅速に優先順位を付けるのに苦労しているからこそ存在する。
その後のサードパーティ分析では、関連するエクスプロイト経路である OWASSRF が、CVE-2022-41080 および CVE-2022-41082 に関連付けられた。Unit 42 のOWASSRF 脅威ブリーフでは、このエクスプロイト手法が OWA を使用し、ProxyNotShell に関連する以前の緩和策を回避するものだと説明された。CrowdStrike 自身の公開分析も公開技術記録の一部となったが、Rackspace に関する記事では、Rackspace の公式声明や信頼できる報道以上のことを主張するのは避けるべきである。
この文脈が重要なのは、パッチのタイミング、緩和策、脆弱性の曖昧さが難しいからだ。ホスティングプロバイダーは、互換性のリスク、顧客への混乱、不完全な初期緩和ガイダンスに直面する可能性がある。しかし、困難であることが説明責任の免除にはならない。Rackspace はマネージドメールを販売していた。同社は、Exchange サーバーが公開され、パッチが適用され、緩和され、監視され、セグメント化され、バックアップされ、隔離されるかどうかを管理していた。顧客はそうではなかった。
したがって、成熟した結論はバランスの取れたものとなる。Microsoft は Exchange 製品とセキュリティ更新を管理していた。攻撃者は悪意のあるエクスプロイトとランサムウェアの展開を管理していた。Rackspace はホスト環境と顧客の継続性を管理していた。顧客はその環境内でほとんど何も管理していなかった。Microsoft だけ、あるいは Rackspace だけを非難する説明責任分析は大雑把すぎる。真の記録は、ベンダーのパッチガイダンス、プロバイダーの実装、そして顧客の依存関係にわたって存在する。
バックアップの可用性が実際の被害ラインとなった
メールサービスが復旧または移行された後、次の問題は過去のメールである。Rackspace のステータスページは、この点について異例なほど明らかにしている。12 月 21 日、同社は顧客のメールデータ復旧の準備が完了し、ポータルを通じて過去のメールデータを PST ファイルとして利用可能にすると述べた。12 月 22 日には、メールボックスの 50％以上が復旧された顧客に対して PST ファイルが利用可能であり、ファイルはカスタマーポータルを通じて 30 日間利用可能であると述べた。12 月 27 日には、復旧は 2022 年 12 月 2 日以前の過去の Hosted Exchange メールデータに限定されており、特定のメールやその他のデータが引き続き利用できない可能性があることを再確認した。
これらの更新が被害ラインを定義している。迅速に移行した顧客は新しいメールを再開できたかもしれないが、過去のメッセージ、添付ファイル、カレンダーの項目、連絡先は必ずしもすぐに利用できなかった。12 月 2 日以降のデータは、移行、転送、代替サービス、アーカイブの選択に依存した。過去のデータ復旧は別途進行した。一部の要素は復旧できないままになる可能性もあった。PST ファイルには、ダウンロード、ストレージ、アーカイブのロード、ユーザーサポートが必要だった。
個人ユーザーにとって、PST は単なるアーカイブファイルである。企業にとって、PST 復旧は数週間規模の運用プロジェクトになり得る。どのメールボックスバージョンが完全か？どの共有メールボックスがどの部門に属しているか？カレンダーはどこに行くのか？重複はどのように処理されるのか？法的ホールドと保持義務はどのように維持されるのか？インシデント中に退職した従業員がいたらどうするのか？顧客が 30 日以内にダウンロードできない場合は？従業員がアーカイブを誤ったテナントにロードしたら？特権的または規制対象のメールが緊急復旧中に安全でない形で保存されたら？
これが、バックアップ設計が説明責任の問題であり、技術的な注釈ではない理由である。マネージドプロバイダーは、顧客がメールボックスを独立して復旧できるかどうか、バックアップがどのくらいの頻度でテストされているか、ランサムウェアがバックアップの整合性にどのように影響するか、顧客固有のエクスポートがどのように認証されるか、復旧ファイルがどのくらいの期間利用可能か、コンプライアンス義務を負う顧客向けのサポートが存在するかどうかを把握しておくべきである。顧客は、メールボックスがオフラインの間にバックアップの制限を発見すべきではない。
Rackspace のステータス文言は慎重だった。すべてが復旧されるとは約束しなかった。入念なプロセスを説明し、限界について警告した。その率直さは重要である。しかし同時に、一部の顧客が、自分の履歴が戻るかどうかについて不確実性に直面したことも確認された。メールに法律、医療、会計、カスタマーサービスの記録が含まれている企業にとって、その不確実性は初期の停止と同じくらい損害を与える可能性がある。
移行パスは救済であると同時に製品の終了でもあった
Rackspace は顧客を単に同じ製品に復旧させたわけではない。その後の SEC 提出書類には、同社がオンプレミスの Hosted Exchange プラットフォームをサンセットし、Microsoft とのリセラー契約を通じて多くの顧客を Microsoft 365 に移行させたと記載されている。2023 年 9 月の Form 10-Qには、Hosted Exchange メール事業は中小企業に提供されるマネージドソリューションであり、年間収益の約 1％を占め、迅速に封じ込められて Hosted Exchange に限定され、Rackspace がオンプレミスの Hosted Exchange プラットフォームをサンセットしたと記載されている。
これは重要である。なぜなら、顧客は停止に見舞われ、製品ラインを後にしたからだ。Microsoft 365 への移行は、技術的にも戦略的にも合理的だったかもしれない。Microsoft 365 は、レガシーなホスト型 Exchange では敵わない、最新のクラウドメールの回復力、セキュリティ管理、運用スケールを提供できる。しかし、ランサムウェアの圧力下での強制移行は、計画された最新化プロジェクトとは異なる。顧客は、新たなライセンス、設定、データ所在地、トレーニング、コンプライアンス、管理、請求に関する問題に直面する可能性がある。
説明責任の問題は、Microsoft 365 が悪い移行先だったかどうかではない。それはおそらく、メールフローを回復するための実用的な道筋だったのだ。問題は、古いサービスが事実上終了した際に、顧客が十分な通知、サポート、復旧証拠を得ていたかどうかである。レガシーなホスト製品を販売するプロバイダーは、侵害の前ではなく、侵害の前に EOL（End of Life）リスクを管理しなければならない。もしインシデントが EOL の決定を強いたのであれば、顧客はサービスクレジット、契約条件、データエクスポート、転送、アーカイブ復旧、将来の義務について明確さを求める権利がある。
移行はまた、責任の境界を変えた。顧客が Microsoft 365 に移行すると、Microsoft が基盤となるメールプラットフォームの大部分を管理し、Rackspace はリセラーまたはサポートプロバイダーであり続ける可能性があり、顧客は新たな管理上の選択肢を得た。これはセキュリティを向上させ得るが、何か問題が発生した場合に説明責任を混乱させる可能性もある。誰がサポートを担当するのか？誰がテナント設定を管理するのか？誰が古い PST ファイルを保持するのか？誰がメールボックス復旧を保証するのか？誰が請求するのか？誰が規制当局に回答するのか？
中小企業は、まさにこれらの質問に対応する内部スタッフがいないために、プロバイダーに依存することが多い。危機的な移行は、機能するアカウントを残すかもしれないが、ガバナンスは混乱したままになる可能性がある。真の復旧とは、「メールが戻った」というだけでなく、「メールボックス、カレンダー、アーカイブ、転送、保持、サポート所有者、請求がすべて筋道が通っている」ことを意味する。
コミュニケーションの質がインシデントの一部となった
当時の公開報道はコミュニケーションに大きく焦点を当てた。Axios は、2022 年 12 月の記事で、顧客の不満とランサムウェア後の透明性の難しさについて報じた。Rackspace の最高製品責任者は、要旨として、同社が正確性を優先し、言えることについて慎重だったと述べた。この緊張は現実のものだ。進行中のランサムウェアイベント中に過剰に情報を共有すると、防御情報が明らかになったり、交渉や調査を妨害したり、法的リスクを生じさせたりする可能性がある。情報が不足すれば、顧客は事業を継続できなくなる。
Rackspace の事例は、ビジネスクリティカルなマネージドサービスにとって、一般的なステータス更新では不十分である理由を示している。顧客は異なる時点で異なる種類の情報を必要としていた。初期には、メールフローがダウンしているかどうか、メッセージがキューに入れられているか失われているか、代替チャネルを使用すべきかどうかを知る必要があった。ランサムウェアが確認されると、移行手順、DNS ガイダンス、サポート連絡先、セキュリティアドバイスが必要になった。復旧中は、PST のタイムライン、完全性の期待値、ダウンロード手順、アーカイブの取り扱いが必要だった。インシデント後は、保険会社、規制当局、顧客、自身の取締役会やオーナー向けの証拠が必要だった。
Rackspace は、投資家向けリリース、SEC 提出書類、ステータスページを通じて更新を公開した。サポートを増強し、Microsoft Fast Track を関与させた。これらは意味のある行動である。しかし、顧客の不満が存在したという事実は、通常のチャネルが容易に処理できる以上のコミュニケーション負荷がかかったことを示している。数千の SME が、それぞれのユーザーが「メールはどこにいったのか」と尋ねることで、サポートの嵐が発生する。
ここで、インシデント計画は極めて実践的である必要がある。プロバイダーは、管理者、エンドユーザー、規制対象顧客、MSP パートナー、経営幹部向けのメッセージテンプレートを事前に構築すべきである。メールが利用できない可能性があるため、代替通信チャネルを用意すべきである。影響を受けた製品を必要としないセルフサービスのステータスツールを用意すべきである。復旧ファイルを渡す前に顧客管理者を検証する方法を用意すべきである。レガシー製品が緊急避難を必要とする可能性がある場合、危機の前に主要な移行パートナーと調整すべきである。
公開記録は、Rackspace がこれらの義務を無視したことを証明してはいない。しかし、ライブコミュニケーションがインシデントの一面となったことは示している。ホスト型メールにおけるランサムウェアイベントは、暗号化やエクスプロイトだけの問題ではない。それは、何千もの企業が同時に同じプロバイダーからの運用指示を突然必要とすることなのだ。
財務諸表はコストの一部しか捉えていなかった
Rackspace の財務開示は、インシデントの企業コストを示している。12 月 6 日の更新では、インシデントが Hosted Exchange の収益を中断させ、増分的な対応コストを生み出す可能性があると警告した。2022 年通期の業績発表では、同社が 2022 年第 4 四半期に多額の非現金性減損費用を計上し、その中には主に Hosted Exchange ランサムウェア攻撃後の時価総額の低下に起因する Apps & Cross Platform セグメントののれん減損が含まれていたと述べている。2023 年の 10-Q では、Rackspace が 2023 年 9 月 30 日に終了した 9 ヶ月間において、Hosted Exchange インシデントに関連する費用として 500 万ドルを計上し、調査・改善費用、法務・専門家サービス、補充スタッフ費用が含まれ、一方で予想または受領した保険回収を計上していると記載されている。
これらの数字は重要だが、顧客の被害総額ではない。中小企業の失われた請求、逃した期限、緊急コンサルタント費用、従業員の残業、顧客離れ、代替サービス費用、コンプライアンス作業などは、必ずしも Rackspace の費用には現れない。プロバイダーの収益シェアは、顧客の依存度を一桁過小評価する可能性がある。プロバイダーの収益の 1％を占める製品が、顧客のメールの 100％を占めることもあるのだ。
この非対称性が、サービスプロバイダーの説明責任を形作るべきである。プロバイダーにとっての財務上の重要性は、顧客にとっての運用上の重要性と同じではない。証券提出書類は投資家の質問に答える。それらは、法律事務所が特権的な通信を見逃したかどうか、診療所が予約を再調整したかどうか、請負業者が入札のやり取りを失ったかどうか、会計士がクライアントの記録を取り出せたかどうかといった疑問に完全に答えるものではない。
提出書類はまた、法的な残滓も示している。2023 年 9 月の 10-Q では、Rackspace が 2022 年 12 月のランサムウェアインシデントに関連していくつかの訴訟で指名され、衡平法上の救済と補償的救済を求めており、Rackspace がこれらの訴訟を積極的に防御していると述べられている。これらの訴訟は申し立てであり、認定事実ではない。しかし、その存在は予想通りである。マネージドメールを購入し、その後メールとデータ復旧の確実性へのアクセスを失った顧客は、契約、不法行為、消費者、または事業損失の理論を通じて説明責任を求めるだろう。
適切な記事の境界線は慎重であるべきである。裁判所がそう判断しない限り、Rackspace が法的責任を負うと宣言すべきではない。公開記録が、サービスの中断、強制移行、データ復旧の制限、インシデント費用、保険回収、訴訟、製品のサンセットを示していることは言える。それは、法律を誇張することなくガバナンスを分析するのに十分である。
顧客データの露出は停止の影響より小さかったが、無関係ではない
Rackspace のインシデントは時に可用性の障害として記憶されるが、公開報道では一部の顧客に対するデータアクセスも説明されていた。SecurityWeek は、Rackspace がランサムウェア攻撃の調査を完了という記事で、Rackspace が約 3 万の Hosted Exchange 顧客のうち 27 の顧客の Personal Storage Table ファイルに攻撃者がアクセスしたことを発見したが、そのアカウントでは実際のデータ窃取の証拠はなかったと報じた。Cybersecurity Dive は、Rackspace が Play ランサムウェアの関与を確認し、攻撃者が CVE-2022-41080 に関連するエクスプロイトを使用し、2023 年 1 月の記事で Hosted Exchange 顧客のごく一部がデータアクセスの影響を受けたと報じた。
この記事は、これらのサードパーティの報道を有用だが、Rackspace の公式リリースや提出書類に従属するものとして扱うべきである。主な Rackspace の投資家向けリリースは、ランサムウェア、封じ込め、隔離、移行、事業への影響に焦点を当てていた。それらは、テクニカルベンダーのブログのような完全なフォレンジックレポートを公開していない。それでも、メールボックスアーカイブへのアクセスの可能性は、被害モデルを変える。メールアーカイブには、個人データ、添付ファイル、契約書、税務書類、健康情報、法的助言、資格情報、機密ビジネス情報が含まれ得る。
もし使用するのであれば、27 という数字はインシデントを矮小化すべきではない。一部の顧客に対するデータアクセスは、それらの顧客にとってプライバシーと機密性の問題である。より広い人口にとってのサービス停止は、継続性の問題である。どちらも真実であり得る。PST にアクセスされた顧客は、潜在的な開示リスクに直面する。PST にアクセスされなかった顧客も、数日から数週間の業務を失った可能性がある。
この分裂は、ランサムウェアの事例でよく見られる。可用性の影響範囲は、しばしば Exfiltration の影響範囲よりもはるかに大きい。公の議論ではよくこれらが 1 つの数字にまとめられるが、顧客は異なる被害を経験する。したがって、インシデント対応は、顧客固有の判断を提供すべきである。サービスが中断されたか、メールボックスデータは復旧されたか、データがアクセスされたか、影響を受けた期間はいつか、どの記録が関与したか、どの通知が必要か、そしてこれらの回答を裏付ける証拠は何か。
顧客固有の証拠がなければ、企業は推測に委ねられる。推測にはコストがかかる。それは、過剰通知、過少通知、不必要な再作業、規制義務の見逃し、回避可能な不信につながる。
サービスクレジットは継続性を回復しない
マネージドサービス契約には、しばしば停止に対するクレジットが含まれている。クレジットは有用であり得る。しかし、深刻な継続性イベントに対しては構造的に不十分である。中小企業が重要な期間にメールアクセスを失った場合、将来のサービス料金に対するクレジットは、逃したメッセージを復元したり、顧客の信頼を再構築したり、法的期限を復旧したり、従業員の残業代を支払ったり、コンサルティング費用を置き換えたりすることはできない。
Rackspace の公開インシデント資料や提出書類は、詳細なサービスクレジット分析ではなく、移行サポート、データ復旧、事業影響に焦点を当てていた。それはインシデント記事としては適切である。なぜなら、より深い問題は正確なクレジット計算式ではないからだ。それは、サブスクリプション価格と依存価値のミスマッチである。ホスト型メールは月額メールボックス単位で課金されるかもしれない。その中断は、収益全体に影響を及ぼし得る。
このミスマッチこそが、重要な SaaS の顧客がベンダーの SLA を超えた継続性計画を必要とする理由である。SME は、ホスト型メールが失敗した場合に顧客に連絡する方法、ドメイン DNS にアクセスする方法、緊急メールボックスを設定する方法、古い MX レコードを保存する方法、メール外でスタッフに連絡する方法、停止中に送信されたメッセージを収集する方法、復旧の優先順位を付ける方法を知っておくべきである。MSP は、顧客を迅速に支援できるよう、ドメインとテナントの文書を維持すべきである。ベンダーは、緊急移行ランブックを提供し、テストすべきである。
しかし、すべての負担を SME に負わせるのは不公平であろう。プロバイダーは自身をマネージドエキスパートとして市場に売り込んでいる。顧客が Exchange の専門家ではないという現実を念頭に設計すべきである。これには、明確なバックアップ/エクスポートオプション、透明性のある復旧目標、テスト済みのランサムウェア隔離、影響を受けた製品に依存しない顧客通知チャネル、そしてプロバイダーが復旧できる範囲についての平易な言葉での制限が含まれる。
クレジットはインシデント後の会計メカニズムである。継続性はインシデント前のエンジニアリングとガバナンスのメカニズムである。Rackspace のインシデントは、顧客がどちらをより必要としていたかを示した。
レガシー製品には正直な EOL リスクガバナンスが必要である
Hosted Exchange は、Microsoft 365 や他のクラウドネイティブなメールサービスに移行しつつある市場に存在していた。レガシー製品は、特定の好み、コスト構造、管理モデル、移行制約を持つ顧客にとって、依然として価値があり得る。しかし、レガシーインフラは、古いアーキテクチャ、複雑なパッチ依存関係、縮小するエンジニアリングフォーカス、縮小する収益シェア、大規模な回復力投資への意欲の低下といった累積リスクを抱えている可能性がある。
Rackspace が後に、オンプレミスの Hosted Exchange プラットフォームをサンセットしたという声明は、ガバナンスのシグナルである。もしインシデント後に製品がサンセットされるのであれば、顧客とプロバイダーの双方は、EOL がもっと早く、より計画的に、あるいはより強力な移行インセンティブとともに行われるべきだったかどうかを問う必要がある。それは後知恵による非難ではない。それは、アクティブな攻撃下でレガシー製品が失敗した後の標準的な質問である。
成熟した EOL プログラムは、単にリタイアを発表するだけではない。それは顧客をマッピングし、リスクを分類し、移行期間を提供し、金銭的インセンティブを提供し、移行ツールをテストし、データエクスポートを文書化し、規制上のニーズに対処し、サポートスタッフをトレーニングし、迅速に移行できない顧客のためのエスカレーションパスを作成する。また、残ることの残留リスクについても明示する。レガシー製品が引き続き利用可能であれば、顧客はプロバイダーが依然として安全で回復力のある状態を保つために十分な投資を行っていると想定するかもしれない。
Rackspace のインシデントは、プロバイダー内部において「小さな収益」が危険であり得る理由を示している。小さな製品は、それに深く依存する集中した顧客基盤を持つ可能性がある。それは、成長製品と同じ最新化投資を受けないかもしれない。しかし、もしそれが失敗すれば、風評および法的な結果は収益ラインを超える可能性がある。その製品は、プロバイダーの会計上の見方から見て小さいだけなのだ。
取締役会や経営幹部にとって、これはポートフォリオリスクの教訓である。顧客データを保存し、顧客の業務を運用するすべてのレガシー製品には、回復力とサンセットのドシエが必要である。もしそれが 2 週間ダウンしたらどうなるか？何人の顧客が自己エクスポートできるか？何人の顧客が代替手段を持たないか？どのようなサポート増強が必要か？ランサムウェアが即時停止を強いた場合、プロバイダーは何と言うか？これらの答えが心地よくないなら、リタイアまたは再設計は任意の戦略作業ではない。それは説明責任の作業なのだ。
MSP とパートナーは復旧チェーンの一部だった
多くの中小企業は、仲介業者を通じて、またはマネージドサービスプロバイダーの助けを借りてホスト型メールを利用している。Rackspace のインシデントの間、MSP と IT コンサルタントは、翻訳者、移行作業員、DNS オペレーター、顧客カウンセラーとなった。MSP コミュニティでの公の議論は、待つべきか、移行すべきか、転送すべきか、それともサービスを放棄すべきかを決定するストレスを反映していた。その議論は主要な証拠ではないが、現実の依存連鎖を示している。
Rackspace は影響を受けたプラットフォームを管理していた。Microsoft は移行先プラットフォームと Exchange 製品の更新を管理していた。MSP は、多くの場合、ローカルの顧客管理、DNS アクセス、デバイスサポート、ユーザートレーニングを管理していた。エンドカスタマーは、ビジネス上の意思決定と、自身の顧客へのコミュニケーションを管理していた。復旧の成功は、これらのアクターがどれだけうまく連携したかにかかっていた。
緊急移行は、大きな影響を伴う小さなミスを生み出す。MSP が全ユーザーの準備が整う前に MX レコードを更新するかもしれない。顧客が共有メールボックスを忘れるかもしれない。ユーザーがモバイルメールを失うかもしれない。アーカイブされたメールのロードが遅いかもしれない。カレンダーの許可が壊れるかもしれない。法的ホールドがクリーンに移行されないかもしれない。配布グループが見落とされるかもしれない。ユーザーの古いパスワードが再利用されるかもしれない。これらのミスのどれも元々のランサムウェアインシデントではないが、すべてがインシデントの結果である。
これが、マネージドプロバイダーがパートナーを第一級のインシデントオーディエンスとして扱うべき理由である。MSP は、技術的なランブック、バルク顧客ステータス、確認済みの管理者連絡先、DNS ガイダンス、移行スクリプト、アーカイブ復旧手順、エスカレーション連絡先を必要とする。プロバイダーが個々のアカウント所有者にのみコミュニケーションを行うなら、パートナーエコシステムは噂のチャネルとなる。パートナーを適切に準備させれば、パートナーエコシステムは復旧の乗数となる。
Rackspace の公開リリースでは、Microsoft Fast Track と増員スタッフについて言及されている。それは作業の規模の表れだった。将来のインシデントでは、パートナーの役割と緊急時の認証経路を事前に定義することで、さらに前進すべきである。メール停止において、DNS を変更し、移行先テナントを設定できる当事者は、名目上の契約所有者よりも重要かもしれない。
説明責任マップは共有されるが、平等ではない
最もクリーンな割り当ては層状である。犯罪行為者は悪意ある活動に責任を負う。Microsoft は、Exchange 製品のセキュリティ更新、脆弱性ガイダンス、Exchange および Exchange Online のセキュリティアーキテクチャに責任を負う。Rackspace は、運用する Hosted Exchange 環境に責任を負い、これにはパッチ適用、緩和策、露出管理、監視、セグメンテーション、バックアップと復旧、顧客コミュニケーション、移行サポート、データ復旧、製品戦略が含まれる。顧客は、自身の継続性計画、ドメインアクセス、エンドポイント設定、ユーザーコミュニケーション、移行後のガバナンスに責任を負う。MSP とパートナーは、顧客が彼らに依存する部分について、ローカルな実行に責任を負う。
これらの責任は共有されているが、平等ではない。顧客は Exchange サーバーを管理していなかったためにマネージドメールを購入した。Rackspace は、失敗した環境とその後の復旧プロセスを管理していた。それは、Rackspace がランサムウェアを引き起こしたことを意味しない。それは、プロバイダーが予防、封じ込め、復旧、証拠の実用的なレバーを握っていたことを意味する。
このインシデントはまた、クラウドの説明責任が移行後のアップタイムだけで測れない理由を示している。新しいメールを取り戻したが過去のカレンダーデータを失い、アーカイブを何週間も待ち、データがアクセスされたかどうかを証明できず、緊急コンサルタントに支払わなければならない顧客は、完全には回復していない。復旧には複数の状態がある。メールフロー、メールボックスの履歴、カレンダーの継続性、アーカイブの完全性、ユーザーデバイス、セキュリティ体制、法的証拠、そして顧客の信頼である。
Rackspace の対応には良い要素が含まれていた。封じ込め、サイバー防御企業の関与、公開投資家開示、Microsoft 365 移行サポート、サポート増強、ステータス更新、データ復旧作業である。公開記録は、厳しい限界も示している。深刻なサービス中断、緊急移行、過去のデータ復旧の制約、製品のサンセット、訴訟、コスト、そして残存する顧客の不確実性である。両方が評価に含まれるべきだ。
あらゆるマネージドクラウドプロバイダーにとってのより広い教訓は、心地よくないものだ。中小企業向けのレガシープラットフォームを運用しているなら、あなたはサーバー以上のものを所有している。あなたは、サーバーが信頼できなくなったときの顧客の継続性オプションを所有しているのだ。その所有権は、攻撃前にアーキテクチャで可視化されるべきである。テスト済みのバックアップ、セルフサービスのエクスポート、明確な RTO/RPO、緊急移行ツール、パートナー向けランブック、証拠パッケージ、そして正直な EOL 計画の中に。
Rackspace の後で変わるべきこと
顧客にとって、Rackspace のインシデントは、基本的だがしばしば見過ごされる継続性管理を主張している。ドメインレジストラと DNS の認証情報を所有すること。メールボックス、エイリアス、配布グループ、共有メールボックス、管理者の最新リストを保持すること。誰が MX レコードを変更できるかを把握すること。従業員や重要な顧客向けのアウトオブバンドの連絡先リストを維持すること。法的およびビジネス要件に従って重要なメールをエクスポートまたはアーカイブすること。緊急時のメール設定をテストすること。影響を受けるメールボックスの外にベンダー契約やサポート連絡先を保管すること。プロバイダーに、ホスト型メールプラットフォームがセキュリティ上の理由でシャットダウンされた場合に何が起こるかを尋ねること。
プロバイダーにとっての教訓は、より厳しいものである。信頼できる障害ストーリーなしにマネージドレガシーサービスを販売してはならない。ランサムウェアがシャットダウンを強いた場合、顧客はどのようにして数時間以内にメールフローを回復するのか？数日以内に過去のメールをどうやって取り戻すのか？データがアクセスされたかどうかをどうやって知るのか？規制対象の顧客はどのようにして通知義務を果たすのか？パートナーはどのようにして一括指示を受け取るのか？サポート増強はどのように資金提供され、人員が配置されるのか？サービスクレジットは実際の復旧義務とどのように関連するのか？移行が難しいためにまだプラットフォーム上にいる顧客は誰で、彼らが安全に離れるのを助ける計画は何か？
ソフトウェアベンダー、特にこの文脈では Microsoft にとって、脆弱性ガイダンスは、大規模なマルチテナントまたはマルチカスタマーの Exchange エステートを運用するマネージドプロバイダーを含む顧客を想定しなければならない。単一の企業向けに機能するガイダンスは、多くの顧客依存関係を持つプロバイダーにとって運用上シンプルではないかもしれない。明確な悪用可能性の声明、パッチの優先順位、緩和の限界、検出ガイダンスは重要である。なぜなら、下流の顧客は脆弱なサーバーを見ることができないからだ。
規制当局や裁判所にとって、このインシデントは馴染みのある問題を提起する。影響を受けた製品が財務的に小さいが顧客にとってクリティカルであるプロバイダーを、法制度はどのように評価すべきか？従来の重要性や損害賠償の枠組みは、分散した SME の被害に苦戦する可能性がある。数千の小さな損失は集計、文書化、訴訟が難しいが、それらは実際の経済的および市民的混乱を表し得る。
Rackspace Hosted Exchange は、これらの問題を一つのイベントに圧縮したために、警告的な記録となった。マネージドサービスがダウンした。顧客は移行しなければならなかった。過去のデータ復旧は段階的で限定的だった。レガシー製品が終了した。訴訟が続いた。費用と保険回収が提出書類に現れた。プロバイダーは生き残ったが、顧客は「ホストされている」が「自分の条件で復旧可能」を意味しないことを学んだ。
Rackspace 後の説明責任基準はシンプルであるべきだ。クラウドプロバイダーが顧客の運用記録を復旧できる唯一の当事者である場合、プロバイダーは通常のアップタイムの約束以上のものを負う。それは、テスト済みの継続性、ポータブルな証拠、明確なコミュニケーション、そして顧客がそれを必死に必要とする日の前に機能する出口経路を負うのだ。