Rackspace Hosted Exchange、メールホスティングを継続性リスクの試金石に変えた

サマリー

• Rackspace は2022年12月、Hosted Exchange 環境に影響を及ぼすランサムウェアインシデントを公表した。12月6日のアップデートでは、このインシデントが Hosted Exchange 顧客のサービス障害を引き起こし、Rackspace は環境を隔離し、顧客の新環境への移行支援を促したとしている。
• Rackspace の12月9日のアップデートと関連するSEC フォーム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 が Rackspace にとって大きな事業ラインではなかったことは明らかだ。12月6日のインシデントアップデートでは、Hosted Exchange 事業は「Apps & Cross Platform」セグメントで年間約3000万ドルの収益を生み出していたとされている。12月9日のアップデートとフォーム8-K では、この事業は Rackspace の総年間収益の約1%を占め、主にこの製品のみを利用する中小企業で構成されていたと説明されている。投資家にとっては、これで財務上の重要性を評価する材料となった。しかし顧客にとっては、依存の実際の規模を見逃すものだった。

中小企業にとってメールは周辺的なアプリケーションではない。発注書が届き、裁判期日のやりとりが行われ、患者の予約が確認され、請求書の催促が行われ、サポートリクエストが処理され、従業員記録が交換され、保険書類が保管され、賃貸交渉が行われ、下請業者が添付ファイルを送り、顧客が回答を期待する場である。カレンダーデータや連絡先データは、しばしばメッセージ本文と同じくらい重要だ。CRM や会計アドオンのアクセスが1日途絶えても、中小企業はその場しのぎで対応できる。しかし、クリーンなバックアップ経路なしにメールとカレンダーを失うことは、ほぼすべての関係を同時に破壊しかねない。

だからこそ、Rackspace のインシデントはクラウドサービス依存と中小企業のサービス継続性の領域に属する。顧客がマネージドプロバイダーを選んだ理由の一部は、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日のアップデートはより明確で、影響を受けた顧客を Microsoft Office 365 へ積極的に移行しており、多くの顧客が既に移行を完了しており、追加の増員スタッフと Rackspace の人員を補完する Microsoft Fast Track チームを含むリソースを利用可能にしたとしている。

この対応により、インシデントは復旧イベントから移行イベントへと変化した。顧客は単にホストサービスの復旧を待っているのではなかった。彼らは異なるプラットフォームへ移行させられていたのだ。緊急時の移行は困難である。管理者は、新しいアカウント、ドメインレコード、DNS 変更、パスワード、デバイス、Outlook プロファイル、モバイルメールの再設定、共有メールボックス、配布リスト、カレンダー、権限、アーカイブ、保持ルール、ユーザーサポートを必要とする。計画された移行では、これらのタスクはすべて管理可能だ。ランサムウェアによる停止中は、危機対応の作業となる。

したがって、重要なアカウンタビリティの問いは、Rackspace がもっと早くスイッチを切り替えるべきだったかどうかではない。より良い問いは、ホストサービスが信頼できる緊急時の出口を備えて設計されていたかどうかだ。ポータブルなメールボックスエクスポート、最新のバックアップ、テスト済みの移行ランブック、十分なサポート人員、顧客固有の所有権記録、DNS 変更ガイダンス、過去のメールがどの程度復旧可能であるかについての明確な期待、などである。

封じ込めは広範な企業を守ったが、顧客は依然としてサービスを失った

Rackspace は封じ込めを強調した。12月9日のアップデートでは、CrowdStrike がネットワーク切断とインシデント対応計画の遵守という迅速な対応によってインシデントが迅速に封じ込められ、Hosted Exchange のみに限定されたことを確認したと述べている。他の Rackspace の製品、プラットフォーム、ソリューション、事業はこのインシデントの影響を受けておらず、ダウンタイムも発生していないとした。SEC フォーム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日には、Rackspace は顧客のメールデータリカバリーの準備を完了し、過去のメールデータをポータル経由で 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月のフォーム10-Qには、Hosted Exchange メール事業は中小企業に提供されるマネージドソリューションであり、年間収益の約1%を占め、迅速に封じ込められ Hosted Exchange に限定されたこと、そして Rackspace がオンプレミスの Hosted Exchange プラットフォームを廃止したと記載されている。

これが重要なのは、顧客が停止に見舞われ、製品ラインから退出させられたからだ。Microsoft 365 への移行は、技術的にも戦略的にも合理的だった可能性がある。Microsoft 365 は、レガシーなホスト型 Exchange では実現できない最新のクラウドメールレジリエンス、セキュリティコントロール、運用スケールを提供できる。しかし、ランサムウェアのプレッシャーの下での強制移行は、計画されたモダナイゼーションプロジェクトと同じではない。顧客は新たなライセンス、設定、データ所在地、トレーニング、コンプライアンス、管理、請求に関する質問に直面する可能性がある。

アカウンタビリティの問いは、Microsoft 365 が悪い移行先だったかどうかではない。おそらく、メールフローを復旧するための実務的な経路だったのだろう。問われるべきは、古いサービスが事実上終了したときに、顧客に十分な通知、サポート、リカバリー証拠があったかどうかだ。レガシーなホスト製品を販売するプロバイダーは、侵害の前ではなく後に、ライフ終了リスクを管理しなければならない。インシデントがライフ終了の決定を余儀なくしたのであれば、顧客はサービス料金、契約条件、データエクスポート、転送、アーカイブリカバリー、将来の義務について明確さを求める権利がある。

また、移行は責任の境界を変えた。顧客が Microsoft 365 に移行すると、Microsoft が基盤となるメールプラットフォームの多くを管理し、Rackspace はリセラーまたはサポートプロバイダーとして残る可能性があり、顧客には新たな管理上の選択肢が生まれた。これによりセキュリティは向上するかもしれないが、何か問題が起きたときにアカウンタビリティを混乱させる可能性もある。誰がサポートを担当するのか。誰がテナント設定を管理するのか。誰が古い PST ファイルを保持するのか。誰がメールボックスのリカバリーを保証するのか。誰が請求するのか。誰が規制当局の問い合わせに応じるのか。

中小企業は、まさにこうした問いに対応する内部スタッフがいないために、しばしばプロバイダーに依存している。危機時の移行は、動作するアカウントを提供するが、ガバナンスが乱雑なままになる可能性がある。真のリカバリーとは、「メールが戻った」だけでなく、「メールボックス、カレンダー、アーカイブ、転送、保持、サポートの所有権、請求がすべて筋が通っている」ことを意味する。

コミュニケーションの質がインシデントの一部となった

当時の公開報道はコミュニケーションに大きく焦点を当てていた。Axios は、2022年12月の記事において、顧客の不満とランサムウェア後の透明性の難しさを報じた。Rackspace のチーフ・プロダクト・オフィサーは、要約すると、同社が正確さを優先し、言えることに慎重であったと述べた。この緊張関係は現実だ。進行中のランサムウェアイベント中に過剰に共有することは、防御情報を漏らし、交渉や調査を妨害し、法的リスクを生む可能性がある。一方、コミュニケーション不足は顧客の事業運営を不可能にする。

Rackspace の事例は、ビジネスクリティカルなマネージドサービスにおいて、一般的なステータスアップデートでは不十分である理由を示している。顧客は異なる時間に異なる種類の情報を必要とした。初期には、メールフローがダウンしているかどうか、メッセージがキューイングされているか失われているか、代替チャネルを使うべきかどうかを知る必要があった。ランサムウェアが確認されると、移行手順、DNS ガイダンス、サポート連絡先、セキュリティアドバイスが必要だった。リカバリー中は、PST のスケジュール、完全性の期待、ダウンロード手順、アーカイブの取り扱いが必要だった。インシデント後には、保険会社、規制当局、顧客、自身の取締役会やオーナー向けの証拠が必要だった。

Rackspace は、投資家向けリリース、SEC 提出書類、ステータスページを通じてアップデートを公開し、サポートを増強し、Microsoft Fast Track を巻き込んだ。これらは意味のある行動だ。しかし、顧客の不満の存在は、コミュニケーションの負担が Rackspace の通常のチャネルが容易に処理できる範囲を超えていたことを示している。ユーザーがメールの行方を尋ねる何千もの中小企業が、サポートストームを引き起こした。

ここでインシデント計画は徹底的に実務的である必要がある。プロバイダーは、管理者、エンドユーザー、規制対象顧客、MSP パートナー、経営幹部向けのメッセージテンプレートを事前に構築すべきである。メールが利用できない可能性があるため、代替のコミュニケーションチャネルを持つべきである。影響を受ける製品を必要としないセルフサービスのステータスツールを持つべきである。リカバリーファイルを引き渡す前に顧客管理者を検証する方法を持つべきである。レガシー製品が緊急避難を必要とする可能性がある場合、危機の前に主要な移行パートナーと調整すべきである。

公開記録は、Rackspace がこれらの義務を無視したことを証明していない。しかし、ライブコミュニケーションがインシデントの一面となったことは示している。ホスト型メールにおけるランサムウェアイベントは、暗号化やエクスプロイトだけの問題ではない。何千もの企業が突然、同じプロバイダーから同時に運用上の指示を必要とする状況なのだ。

財務諸表はコストの一部しか捉えていなかった

Rackspace の財務開示は、インシデントの企業にとってのコストを示している。12月6日のアップデートでは、インシデントが Hosted Exchange の収益を中断させ、追加の対応コストを生む可能性があると警告した。2022年通年決算リリースでは、第4四半期に、主に Hosted Exchange ランサムウェア攻撃後の時価総額の下落による「Apps & Cross Platform」セグメントののれん減損を含む、多額の非現金減損費用を計上したと述べている。2023年の10-Q では、Rackspace は2023年9月30日までの9か月間に、Hosted Exchange インシデントに関連して、調査・修復費用、法務・専門サービス費用、追加人員コストを含む5.0百万ドルの費用を計上し、一方で予想または受領した保険金を計上したと述べている。

これらの数字は重要だが、顧客の損害総額ではない。中小企業の請求漏れ、期限超過、緊急コンサルタント費用、スタッフの残業、顧客離れ、代替サービス費用、コンプライアンス作業は、必ずしも Rackspace の費用には現れない。プロバイダーの収益比率は、顧客の依存度を一桁過小評価し得る。プロバイダーの収益の1%を占める製品が、顧客にとってはメールの100%を占める可能性があるのだ。

この非対称性が、サービスプロバイダーのアカウンタビリティを形作るべきである。プロバイダーにとっての財務的重要性は、顧客にとってのオペレーション上の重要性と同じではない。証券申告書は投資家の質問に答えるが、法律事務所が秘匿特権通信を逃したかどうか、診療所が予約を再調整したかどうか、請負業者が入札の通信を失ったかどうか、会計士がクライアント記録を回収できたかどうかという問いに完全には答えない。

また、申告書には法的な余波も示されている。2023年9月の10-Q では、Rackspace は2022年12月のランサムウェアインシデントに関連していくつかの訴訟で被告となっており、衡平法上の救済や補償的救済を求めており、Rackspace はこれらの事案について積極的に防御していると述べている。これらの訴訟は申し立てであり、認定事実ではない。しかし、その存在は予想可能だ。マネージドメールを購入し、メールアクセスとデータリカバリーの確実性を失った顧客は、契約、不法行為、消費者保護、事業損失の理論を通じてアカウンタビリティを求めるだろう。

正しい記事の境界は慎重であるべきだ。裁判所が判断しない限り、Rackspace が法的に責任があると宣言すべきではない。公開記録が示しているのは、サービス停止、強制移行、データリカバリーの制限、インシデント費用、保険回収、訴訟、製品のサンセットである。これらは、法を誇張することなくガバナンスを分析するのに十分である。

顧客データの露出は停止影響より小規模だが、無関係ではない

Rackspace のインシデントはしばしば可用性の障害として記憶されるが、公開報道では一部の顧客のデータアクセスについても説明されている。SecurityWeek はRackspace completes investigation into ransomware attackの中で、Rackspace が約30,000の Hosted Exchange 顧客のうち27顧客について、攻撃者が Personal Storage Table ファイルにアクセスしたことを発見したが、その報告では実際のデータ窃取の証拠はないと述べたと報じた。Cybersecurity Dive は、Rackspace が Play ランサムウェアの関与と、攻撃者が CVE-2022-41080 に関連するエクスプロイトを使用したことを確認し、Hosted Exchange 顧客のごく一部がデータアクセスの影響を受けたと2023年1月の報道で報じた。

当記事では、これらのサードパーティ報道を有用だが、Rackspace の公式リリースや提出書類に次ぐものとして扱うべきである。Rackspace の主要な公開投資家向けリリースは、ランサムウェア、封じ込め、隔離、移行、事業影響に焦点を当てていた。技術ベンダーのブログのような完全なフォレンジックレポートは公開しなかった。それでも、メールボックスアーカイブへのアクセスの可能性は損害モデルを変える。メールアーカイブには、個人データ、添付ファイル、契約書、税務書類、医療情報、法律アドバイス、資格情報、機密事業情報が含まれ得る。

「27」という数字は、もし使うにしても、インシデントを矮小化すべきではない。一部の顧客にとってデータアクセスはプライバシーと機密性の問題であり、何千もの顧客にとってのサービス利用不可は広範な層の継続性の問題である。両方とも真実であり得る。PST がアクセスされた顧客は潜在的な開示リスクに直面する。PST がアクセスされなかった顧客でも、数日から数週間の業務を失った可能性がある。

この分裂はランサムウェアのケースに共通する。可用性の影響範囲は、流出の影響範囲よりもはるかに大きくなり得る。公の議論ではしばしばそれらが一つの数字にまとめられるが、顧客は異なる損害を経験する。したがって、インシデント対応は顧客固有の判断を提供すべきである：サービスは停止したか、メールボックスデータはリカバリーされたか、データがアクセスされたかどうか、影響を受けた期間はいつか、どの記録が関与したか、必要な通知は何か、そしてこれらの回答を裏付ける証拠は何か。

顧客固有の証拠がなければ、企業は推測に頼らざるを得ない。推測は高くつく。過剰通知、過少通知、不要なやり直し、規制義務の見落とし、回避可能な不信につながる。

サービス料金は継続性を回復しない

マネージドサービス契約には、しばしば停止に対する料金クレジットが含まれる。クレジットは有用であり得るが、重大な継続性イベントに対しては構造的に不十分である。中小企業がクリティカルな期間にメールアクセスを失った場合、将来のサービス料金に対するクレジットは、失われたメッセージを復元せず、顧客の信頼を再構築せず、法的期限を回復せず、スタッフの残業代を支払わず、コンサルティングコストを置き換えない。

Rackspace の公開インシデント資料と提出書類は、詳細な公開サービス料金分析ではなく、移行サポート、データリカバリー、事業影響に重点を置いていた。それはインシデント記事として適切である。なぜなら、より深い問題は正確なクレジット計算式ではなく、サブスクリプション価格と依存の価値のミスマッチだからだ。ホスト型メールはメールボックス単位月額で料金設定されるかもしれないが、その中断は収益全体に影響し得る。

このミスマッチが、クリティカルな SaaS の顧客がベンダーの SLA を超えた継続性計画を必要とする理由である。中小企業は、ホスト型メールが故障した場合に顧客に連絡する方法、ドメイン DNS へのアクセス方法、緊急メールボックスの設定方法、古い MX レコードの保持方法、メール以外の手段でスタッフに連絡する方法、停止中に送信されたメッセージを収集する方法、リカバリーに優先順位を付ける方法を知るべきである。MSP はクライアントを迅速に支援できるよう、ドメインとテナントのドキュメンテーションを保持すべきである。ベンダーは緊急移行ランブックを提供し、テストすべきである。

しかし、すべての負担を中小企業に課すのは不公平だ。プロバイダーは自らをマネージドの専門知識としてマーケティングしている。顧客が Exchange の専門家ではないという現実に合わせて設計すべきである。それには、明確なバックアップ／エクスポートオプション、透明なリカバリー目標、テスト済みのランサムウェア隔離、影響を受ける製品に依存しない顧客通知チャネル、プロバイダーがリカバリーできる範囲についての平易な言葉による制限が含まれる。

クレジットはインシデント後の会計メカニズムである。継続性はインシデント前のエンジニアリングとガバナンスのメカニズムである。Rackspace のインシデントは、顧客がどちらをより必要としていたかを示した。

レガシー製品には誠実なライフ終了リスクガバナンスが必要である

Hosted Exchange は、Microsoft 365 やその他のクラウドネイティブメールサービスへ移行する市場に存在していた。レガシー製品は、特定の好み、コスト構造、管理モデル、移行制約を持つ顧客にとって価値があり続ける可能性がある。しかし、レガシーインフラストラクチャは累積したリスクを抱え得る。古いアーキテクチャ、複雑なパッチ依存関係、縮小するエンジニアリングフォーカス、縮小する収益シェア、大規模なレジリエンス投資への意欲低下などである。

後に Rackspace がオンプレミスの Hosted Exchange プラットフォームを廃止したという声明は、ガバナンスのシグナルだ。インシデント後に製品を廃止できたのであれば、顧客とプロバイダーの双方が、ライフ終了がもっと早く、より計画的に、あるいはより強力な移行インセンティブをもって起こるべきだったかどうかを問う必要がある。これは後知恵による非難ではない。レガシー製品が活発な攻撃の下で故障した後の標準的な問いである。

成熟したライフ終了プログラムは、単に廃止を発表するだけではない。顧客をマッピングし、リスクを分類し、移行ウィンドウを提供し、金銭的インセンティブを提供し、移行ツールをテストし、データエクスポートを文書化し、規制上のニーズに対処し、サポートスタッフを訓練し、迅速に移行できない顧客のためのエスカレーションパスを作成する。また、残留リスクを明示する。レガシー製品が引き続き利用可能であれば、顧客はプロバイダーが依然として安全でレジリエントにするために十分な投資をしていると考えるかもしれない。

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、緊急移行ツール、パートナーランブック、証拠パッケージ、そして誠実なライフ終了計画である。

Rackspace 後に何が変わるべきか

顧客にとって、Rackspace のインシデントは基本的だがしばしば無視される継続性コントロールを主張する。ドメインレジストラと DNS 認証情報を所有すること。メールボックス、エイリアス、配布グループ、共有メールボックス、管理者の最新リストを保持すること。誰が MX レコードを変更できるかを把握すること。従業員と重要な顧客のアウトオブバンド連絡先リストを維持すること。法的および事業上の要件に従ってクリティカルなメールをエクスポートまたはアーカイブすること。緊急メール設定をテストすること。ベンダーの契約書とサポート連絡先を影響を受けるメールボックスの外に保持すること。ホスト型メールプラットフォームがセキュリティ上の理由でシャットダウンされた場合にどうなるかをプロバイダーに尋ねること。

プロバイダーにとって、教訓はより要求が厳しい。信頼できる故障ストーリーなしにマネージドレガシーサービスを販売してはならない。ランサムウェアがシャットダウンを強制した場合、数時間以内に顧客はどのようにメールフローを得るのか。数日以内に過去のメールを得るのか。データがアクセスされたかどうかをどうやって知るのか。規制対象顧客はどのように通知義務を果たすのか。パートナーはどのようにバルクの指示を受け取るのか。サポート増強はどのように資金調達され、人員配置されるのか。サービス料金は実際のリカバリー義務とどのように関係するのか。移行が難しいためにまだプラットフォーム上にいる顧客は誰か、そして彼らが安全に離れるための計画は何か。

ソフトウェアベンダーにとって、特にこの文脈では Microsoft にとって、脆弱性ガイダンスは、マネージドプロバイダーが大規模なマルチテナントまたは多数の顧客向け Exchange エステートを運用していることを想定しなければならない。単一の企業向けに機能するガイダンスは、多くの顧客依存関係を持つプロバイダーにとって運用上単純でないかもしれない。明確な悪用可能性の声明、パッチ優先度、緩和限界、検出ガイダンスが重要なのは、下流の顧客が脆弱なサーバーを見ることができないからだ。

規制当局や裁判所にとって、このインシデントはよくある疑問を提起する：法的システムは、影響を受ける製品が財務的に小さいが顧客にとってクリティカルであるプロバイダーをどのように評価すべきか。従来の重要性や損害賠償の枠組みは、分散した中小企業の損害に苦戦し得る。何千もの小さな損失は集約、文書化、訴訟が困難であるが、それらは現実の経済的・社会的混乱を表し得る。

Rackspace Hosted Exchange は、これらの問いを一つのイベントに圧縮したために教訓的な記録となった。マネージドサービスがダウンした。顧客は移行せざるを得なかった。過去データのリカバリーは段階的かつ限定的だった。レガシー製品が終了した。訴訟が続いた。費用と保険回収が提出書類に現れた。プロバイダーは生き残ったが、顧客は「ホストされている」が「自分の条件でリカバリー可能」を意味しないことを学んだ。

Rackspace 後のアカウンタビリティ標準はシンプルであるべきだ。クラウドプロバイダーが顧客の運営記録を復旧できる唯一の当事者であるなら、プロバイダーは通常のアップタイムの約束以上のものを負っている。テストされた継続性、ポータブルな証拠、明確なコミュニケーション、そして顧客がそれを必死に必要とする日の前に機能する出口パスを負っている。