OVHcloud 火災が示したこと：データ所在地は災害分離ではない

要約

• 2021 年 3 月 10 日午前 0 時 35 分、OVHcloud のストラスブールサイトで火災報知器が作動した。火災は SBG2 棟 1 階の電源室で発生し、同棟を全焼させるとともに、SBG1 棟の 12 室中 4 室に損傷を与え、キャンパス全体の電源停止を余儀なくさせた。SBG3 棟と SBG4 棟は初期火災では焼失しなかったが、電気系統の隔離、安全点検、清掃、段階的な再起動が必要となったため、それらのサービスも利用不能となった。死者・負傷者はいなかった。
• フランス産業リスク調査分析局（BEA-RI）の調査では、UPS とその関連鉛蓄電池で観測されたほぼ同時発生の電気障害の正確な原因は特定されなかった。しかし、以下の伝播要因と対応要因が明らかになった。ストラスブールの 5 棟のいずれにも自動消火設備が設置されていなかったこと、SBG2 棟の開放的な冷却設計によって煙が急速に拡散したこと、消火用水の容量が限られていたこと、そしてサイト全体の電力遮断が困難だったことである。一方で、正常に機能した検知器、夜間の常駐スタッフ、SBG3 棟を守った耐火隔壁、さらには独仏共同の大型消防艇の到着が、より深刻な被害を防いだ。
• 可用性の喪失と恒久的なデータ損失は異なる結果である。OVHcloud は約 65,000 の顧客と 120,000 のサービスが影響を受けたと報告したが、Netcraft は約 46 万 4,000 ドメインにまたがる約 360 万のウェブサイトがオフラインになったと観測した。OVHcloud によれば、データを失った顧客の多くはオプションのバックアップを選択していなかったという。しかし、これは説明責任の問題を解決しない。OVHcloud 自身の登録文書には、提供されるバックアップが同一または異なるデータセンターに保存される可能性があると記載されており、後に控訴審で争われた事案では、有料の自動バックアップが本番環境と同じ建物で消失した顧客が存在した。
• この事故は、クラウド調達におけるカテゴリーの誤りを露呈させた。データ主権、法的管轄、レイテンシー、可用性、バックアップ、災害復旧は関連はあるが、互換性はない。データをフランス国内または EU 域内に留めることは所在地ポリシーを満たす一方で、本番用と復旧用のコピーが同一の物理的危険に晒されることを許容し得る。逆に、地理的に離れたコピーを同じ法的領域内に保持して欧州の規制下に置くことも可能である。
• OVHcloud は火災後の大幅な変更を公表した。これには、自動消火設備の拡大、区画化の強化、電源室の分離、遠隔電力遮断装置、サイト監査、消防機関との連携、新たなマルチゾーンおよび遠隔地バックアップオプションが含まれる。ただし、説明責任を果たすには、サービスおよびサイト固有の証拠が必要である。具体的には、全管理区域における実装済みの防火対策、独立した検査の実施、現実的な火災および電源隔離訓練、宣言通りのバックアップ保存場所、復旧テストの成功実績、そして顧客の復旧が被災地域や同一のコントロールプレーンに依存していないことの証明が求められる。

物理的な火災がクラウド説明責任の事象となった

「クラウド上のデータ」という言葉は抽象化を助長する。エンジニアが計算リソースへの標準インターフェースを求める際には便利だが、意思決定者が場所、電力、火災を「誰か他の人の詳細事項」として扱い始めると危険である。すべての仮想サーバーは部屋の中に存在する。すべてのストレージレプリカは電気および冷却システムに接続された機器を占有する。すべての復旧ワークフローは、人、ネットワーク、認証情報、カタログ、そして代替キャパシティを調達できる場所に依存する。

ストラスブールの事故は、その物理的な連鎖を可視化した。2021 年 3 月 10 日未明、OVHcloud の Port du Rhin キャンパスに位置する建物の一つ、SBG2 が火災により破壊された。SBG1 は部分的に破壊された。同サイト内の他の 2 つのデータセンターも、初期の会社発表では無傷とされていたにもかかわらず、停止に追い込まれた。したがって、損失は少なくとも以下の 3 つのメカニズムを通じて伝播した。機器の物理的破壊、隣接建物内の機器が熱・煙・水・不確実性に晒されたこと、そしてサイト全体を電気的に隔離し安全を確保する必要から、正常な機器までもが利用不能になったことである。

これらのメカニズムが重要であるのは、それぞれが異なる対策に対応しているからだ。自動消火と区画化は火災を封じ込め得る。独立した電力ゾーンは、消防隊が遮断を必要とする範囲を縮小できる。マルチサイトのアプリケーションは、1 つのサイトが利用不能の間も継続できる。遠隔地の検証済みバックアップは、データ破壊後の再構築を支える。ステータスページは、顧客がこれらの選択肢を理解する手助けとなる。これら全てを「冗長性」と呼ぶことは、誰が各レイヤーを制御し、どのような事象を生き残れるのかを覆い隠してしまう。

最も信頼できる公的な復元資料は、フランス産業リスク調査分析局（BEA-RI）の2022 年 5 月の調査報告書である。その任務は予防であり、民事上あるいは刑事上の責任の割り当てではない。この境界は重要である。報告書は、観測事項、考えられる原因、増幅要因、安全勧告を提示できるが、特定された全ての弱点が過失であるとか、ある弱点が特定の顧客の損失の法的な原因であると結論づけるものではない。

説明責任分析は、関連しているがより広い問いを投げかける。それは、ある深夜の機器事象が、複数建物に及ぶ停止、長期化する復旧、そして不可逆的な顧客損失へと発展することを許した諸条件に対して、どの行為主体が権限を有していたか、である。OVH は、サイトの設計と運用、提供製品、その説明の正確性、そして対応を管理していた。顧客は、ワークロードの分類、アーキテクチャ、多くのサービス選択、独自のコピーを管理していた。規制当局や専門機関は、最低限の枠組みの一部を管理していた。これらの役割のどれも、他の役割を消し去るものではない。

証拠が確立するもの、しないもの

BEA-RI 報告書は最初の警報を 00 時 35 分としている。警備員が 00 時 37 分に SBG2 の電源室に到着したところ、濃い黒煙を確認した。建物からの避難は 00 時 39 分に行われ、Bas-Rhin 消防救助隊には 00 時 42 分に通報が行われ、最初の隊員は 00 時 59 分に到着した。OVH の公開インシデントページでは発火時刻を 00 時 47 分としていた。この相違は一つのタイムスタンプに強制的に統一するのではなく、保存されるべきである。安全調査は警報や運用記録にアクセスできたのに対し、会社のページは公開インシデントの目印として提示された。

SBG2 への非常用電源は 01 時 13 分に遮断され、SBG1、SBG3、SBG4 は 01 時 28 分に遮断された。消防隊は電気アーク放電を視認しており、リスクを制御できるようになるまで本格的な放水を見合わせた。01 時 42 分までに火災は 1 階全体に広がった。02 時 00 分頃、消防隊は SBG2 が全面的に火炎に包まれたと報告した。大型消防艇 EUROPA は 03 時 00 分頃に到着し、隣接水路を水源として利用した。火災は 10 時 02 分に鎮火し、活動は 18 時 13 分に終了した。

調査では、火元は蓄電池と無停電電源装置（UPS）が設置された部屋であったとしている。監視映像と記録は、UPS ユニット ASI2 とその関連バッテリー（これらは別々の部屋にあった）で、ほぼ同時に発生した電気的故障を示していた。その日の午前中に UPS のメンテナンスが行われ、その日の後半に異常な湿度が計測されていた。調査官は、湿気の影響、メンテナンス関連の誤動作、想定外の条件下での運転など、複数の仮説を列挙したが、正確な発端原因を特定するには証拠が不十分であると明言した。

この制約は、「冷却システムの漏水」や「直近に整備された UPS」が火災を「引き起こした」とする説明の中で失われがちである。公式のフランス ARIA 事故記録は、機械室の設定や対応を裏付ける有用な傍証ではあるが、もっともらしいメカニズムを証明された根本原因に変換するものではない。信頼できる説明は、初期の電気的事象と発生場所が判明していること、そして、それらの事象がなぜ発生したのかは BEA-RI の公表報告書では未解決であることを伝えるべきである。

この区別は対策分析を妨げない。組織は、次にどの構成要素が故障するかを知らなくても、機器の故障に備えなければならない。防火はその不確実性を前提に設計される。説明責任の問いは、単に OVH が特定の電気的シーケンスを予見すべきだったかどうかではない。問題は、検知、自動制御、区画化、消火用水、電気的隔離、建物設計、緊急手順が、何かが発火した後も人々と隣接サービスに十分な独立的保護を与えたかどうかである。

建物は危険を検知したが、封じ込められなかった

ストラスブールのサイトは、一つの人命安全の役割を十分に果たした。光学式および吸引式の煙検知器は機能した。夜間の常駐スタッフにより、迅速な確認と消防への早期通報が可能となった。全員が避難し、負傷者はいなかった。BEA-RI 報告書はこれらの対策を評価している。説明責任は、成功した障壁も失敗した障壁と同様に注意深く保持すべきである。なぜなら、将来の設計は、実際に時間を稼いだものが何かを知ることに依存するからだ。

検知には、自動消火が伴っていなかった。調査の結果、サイト内の 5 棟のいずれにも自動消火設備はなかったことが判明した。SBG2 のバッテリー室と UPS 室は監視されていたが、火災をその極初期段階で消火、制御、または遅延させるための設備はなかった。このような設備があれば、完全な停電前、かつ消防士が活線状態の機器に晒されることなく作動できたはずだ。特に電気室内では消火を保証するものではないが、延焼曲線を変えられた可能性はある。

次に建物は煙と熱の拡散を助長した。SBG2 は、外気を高度に取り込む開放的な塔状の冷却設計を採用していた。初期事象から 15 分以内に、全階の吸引式検知器が作動した。BEA-RI は、検知器の作動タイミングが必ずしも火炎ではなく煙を示す可能性を指摘しつつも、この構造によって煙が急速に広がったと結論づけた。約 90 分以内に SBG2 はほぼ全焼した。隣接する SBG3 との対比は示唆的だった。2 時間耐火の壁と防火扉、さらに消火用水の放水により、SBG3 はより小さく保護の弱い SBG1 よりも損傷が少なかった。

水と電力は、この設計と相互作用した。調査によれば、初期対応で利用可能な公共の消火用水は、発展する事象に対して不十分であり、OVH は自前の貯水槽も、近隣の運河から直接取水する手段も持っていなかった。EUROPA の到着が決定的だった。通常はデータセンターの強みである電気的独立性が、緊急時の隔離を困難にもした。サイトには系統電力、発電機、大規模なバッテリーシステムが組み合わされていた。消防機関は、これらの電源が無力化されるまで、安全に大量の放水を適用できなかった。

これはインフラストラクチャのレジリエンスのパラドックスである。バックアップ電源は通常の停電時には計算処理を維持するが、火災時には管理すべきもう一つのエネルギー源となる。開放的な気流は冷却コストを下げ運用効率を高めるが、煙や熱の閉じ込めを弱める可能性がある。高密度な機器配置と共有のサイトユーティリティはスケールメリットを向上させるが、影響を集中させる。それぞれの最適化は、別の障壁によって制御されなければならないリスクを生み出す。

OVH のBEA-RI 勧告への正式回答は、自動消火設備の欠如が規制要件違反には当たらず、調査が引用した業界ガイダンスは SBG2 の設計以降のものであると主張した。これは法令・コンプライアンス分析に関連する。しかし、それが運用上の説明責任の終わりではない。最低限のコンプライアンスは、ルールが対策を強制したかどうかを問う。レジリエンスは、その対策が想定され得る高影響シナリオに対して必要だったかを問う。火災後に OVH が、未装備だったサイトに自動消火設備を包括的に導入する決定を下したことは、それ自体がリスク処理が変化した証拠である。

建物が 4 つあるからといって、4 つの独立した結果が生じるわけではない

顧客のダッシュボードからは、SBG1、SBG2、SBG3、SBG4 は複数のインフラ拠点のように見えただろう。しかしインシデント発生中、それらは一つの緊急サイトを形成していた。SBG2 は全焼した。SBG1 と SBG3 は程度の差こそあれ火災の影響を受けた。SBG4 は初期火災による直接的な損傷はなかった。しかし、電力は全 4 棟に対して遮断され、立ち入りが規制され、共有システムの評価が必要となり、生き残ったインフラは清掃、点検、再配線、段階的再起動を必要とした。

OVHcloud の当時のストラスブール更新ログは、復旧の物理的な性格を例外的に可視化している。チームは部屋ごと、通路ごと、ラックごと、サーバーごとに機器の取り出し、清掃、点検、再設置、再起動を行った。煤で汚染されたサーバーは、専門作業のために Croix の工場へ送られた。SBG1 から回収可能なマシンは、他のデータセンターへ移設された。データ復旧の専門家が、損傷した部屋からディスクの取り出しを試みた。

最初の復旧は直線的ではなかった。SBG3 は 3 月 18 日に稼働した。3 月 19 日夜、通電されていない SBG1 のバッテリー室で煙が検知された。OVH は予防措置として SBG1 と SBG4 を再びシャットダウンし、再起動スケジュールを修正した。サービス復旧は 3 月 22 日に再開された。3 月末までに、SBG4 のベアメタルサーバーはアクセス可能となり、SBG3 のサービスは割合ベースで復旧しつつあったが、SBG1 の機器は依然として清掃、修理、移設の途上にあった。

OVH のその後の登録文書によれば、大半の顧客サービスは 3〜4 週間以内に復旧し、約 65,000 の影響を受けた顧客（約 120,000 のサービスを利用）へのサービスは 5 月初頭までに完全に復旧した。ただし、「サービスが復旧した」は「すべてのデータが復旧した」と読むことはできない。顧客の元のディスクや記録が破壊されたままでも、代替サーバーはプロビジョニングされ得る。復旧報告では、インフラの可用性、アプリケーションの起動、データ復元、データの最新性、ビジネスの受容を区別しなければならない。

サイト全体の停止は、「データセンター」という言葉が災害計画にとっては細かすぎる可能性がある理由も示している。障害ドメインとは、一つのハザードが同時に影響を及ぼし得る範囲すべてである。ストラスブールでの火災対応において、関連するドメインには、隣接建物、電力遮断手順、緊急アクセス、消火用水容量、煙、共有オペレーション、再入場を管理する安全当局が含まれていた。複数の建物名があっても、同一の緊急決定によってそれら全てが利用不能になり得るなら、独立した復旧を提供するわけではない。

影響を数えるには、一つの数字だけでは不十分

Netcraft のこの停止に関する外部測定では、約 46 万 4,000 の異なるドメインにわたる約 360 万のウェブサイトがオフラインになり、最近の調査で OVH に帰属する IP アドレスの 18％以上が測定ウィンドウ中に応答しなかったことが判明した。これは、到達可能性の喪失に関するインターネット規模の見解である。ホストされているサブドメインや下流のホスティング契約を捕捉するため、OVH の顧客数を大幅に上回る。

OVH が公表した 65,000 の影響顧客と 120,000 のサービスという数字は、商取引上の関係と製品上の関係を表している。どちらの数字も、何人のエンドユーザーがサービスに到達できなかったか、何社の事業者が収益チャネルを失ったか、あるいは、どれだけのデータセットが回復不能になったかは示さない。当時のReuters の報道は、政府ポータル、銀行、商店、ニュースサイト、その他のオンラインサービスが影響を受けたと特定している。これらの事例は影響の多様性を示すが、完全な集計ではない。

影響は時間の経過によっても変化した。コードを外部リポジトリに置くステートレスなウェブサイトは、数時間で別リージョンに再構築できる。プロバイダーが復旧データを保有するマネージドサービスは、OVH がプラットフォームを復旧させた時点で戻ってくるかもしれない。ベアメタルを利用する顧客で、検査や物理的な移設を待っている場合は、数週間利用できないままでいる可能性がある。本番データとバックアップの唯一のコピーが破壊された顧客は、新しい空のサーバーがどれだけ早く到着しても、恒久的な損失に直面する。

したがって、説明責任を果たすインシデント報告では、複数の分母を使用すべきである。すなわち、顧客数、サービス数、物理サーバー数、ドメイン数、外部から到達不能なアドレス数、停止期間帯、プロバイダーが成功裏に復旧させた件数、顧客が自主再構築した件数、恒久的なデータ損失件数である。そして、バックアップを全く保持していなかった顧客、同一建物内にコピーを保持していた顧客、同一サイト内に保持していた顧客、別の OVH リージョンに保持していた顧客、または独立した管理下にコピーを保持していた顧客の数を特定すべきである。公開情報は、この完全なマトリックスを提供していない。

この欠落は重要である。なぜなら、是正措置は損失のメカニズムに従うべきだからだ。もし顧客が明確に提供されていた遠隔バックアップを選択しなかったのなら、より良い製品教育と安全なデフォルト設定が適切である。もし「バックアップ」と呼ばれる製品が、明確な障害ドメインの開示なしに全コピーを一つの建物内に置いていたのなら、製品設計と契約が中心問題となる。もし遠隔コピーが存在したが、ID、鍵、カタログ、ネットワーク経路がストラスブールに結びついていたために顧客がそれを取り出せなかったのなら、復旧システムの独立性が問題である。これらのケースを「一部の顧客はバックアップを持っていなかった」と一括りにすることは、正確な説明責任を妨げる。

バックアップとは、将来の復旧についての主張である

OVHcloud の2021 年登録文書は、データバックアップサービスは大半の顧客にとって有料のオプションサービスであり、一部の顧客は恒久的なデータ損失を経験したと述べている。また、顧客は、バックアップデータを同一データセンターまたは異なるデータセンターのいずれかに保存する、提供されたオプションを選択できたとしている。メールを含む特定のプロバイダー管理サービスは、軽微な中断のみで、OVH がバックアップを管理していたためデータ損失は発生しなかった。

これらの開示は、二つの単純なストーリーを否定する。OVH があらゆるサービスをバックアップしていて、そのすべてのコピーを保全できなかったと言うのは不正確である。同様に、データを失った全ての顧客がバックアップを購入しなかったと言うのも不十分だ。サービスモデルは異なっていた。一部の顧客は唯一の永続コピーに対する責任を保持し、一部は異なる保管場所を持つプロバイダーのオプションを選択し、また一部は OVH が復旧を管理するサービスを利用していた。

バックアップは、単にコピージョブの成功によって定義されるものではない。それは、特定された障害の後に、組織が十分に最新で完全な情報のバージョンを取得し、それを使用して許容される時間内に優先サービスを復元できるという、管理された約束である。この約束は、少なくとも次の 6 つの特性を含む。

1. 範囲：含まれるデータ、システム状態、構成、ID ストア、鍵、ソフトウェア、および意図的に除外された外部依存関係。
2. 目標時点：復元データの最大許容経過時間（通常は目標復旧時点として表される）、および破損や遅延検知に備えた保持履歴。
3. 隔離：すべてのコピーを同時に破壊または改変し得ない、物理的、論理的、管理的、およびプロバイダーの障害。
4. アクセス：危機の際にコピーを取り出すために必要な認証情報、暗号化鍵、カタログ、ツール、ネットワーク経路、および権限を与えられた担当者。
5. 時間：容量の確保、データ転送、依存関係の再構築、トランザクションの調整、ビジネス機能を許容可能な状態に戻すまでにかかる、テスト済みの所要時間。
6. 証拠：バックアップが完了したことの監視、整合性チェック、サンプル復元、完全なサービス演習、および結果を示す保持記録。

ストラスブールは主として物理的な隔離と復旧時間の試金石であったが、6 つの特性すべてを露呈させた。DNS レコード、シークレット、デプロイコード、データベースの整合性を欠いたディスクイメージは、アプリケーションを再起動できないかもしれない。障害が起きたリージョンを通じてのみ利用可能な鍵で暗号化された遠隔コピーは、耐久性がありながら使用不可能かもしれない。数日かかるマルチテラバイトのアーカイブは、12 時間のビジネス目標を逃すかもしれない。同じ電源・火災ドメインに保存されたバックアップは、それがカバーすべき事象が発生するまでは完全に最新かもしれない。

フランスのデータ保護当局 CNIL は現在、そのバックアップセキュリティガイダンスの中で物理的な教訓を明確に述べている。すなわち、少なくとも一つのコピーを地理的に異なるサイトに保持すること、少なくとも一つのコピーをオフラインで隔離すること、バックアップを本番と同等のセキュリティレベルで保護すること、そして整合性と復元テストを行うことである。CNIL のクラウドセキュリティガイダンスは、顧客に対し、クラウドプロバイダーがデータセンターから地理的に離れた場所にバックアップを保有していることを確認するよう求めている。これらの 2024 年の資料は、後のガイダンスであって、2021 年時点のすべての OVH サービスにおける正確な契約上の義務の証明ではない。しかし、現在の実践に対する明確なベンチマークである。

Bati Courtage 事件が製品文言を法的に重要なものとした

ある顧客の紛争は、バックアップの境界に法的な具体性を与えている。France Bati Courtage は、OVH の仮想プライベートサーバーと有料の自動バックアップオプションを利用していた。記録によると、OVH は 2021 年 4 月、バックアップもまた「完全かつ不可逆的に破壊された」と通知した。なぜなら、コピーがプライマリサーバーと同じ建物内にあったからである。同社は、データ損失とそれに起因すると主張される事業上の損害に対して数百万ユーロの損害賠償を求めた。

結果は控訴審で変わった。ドゥエー控訴院は、2025 年 4 月 24 日の判決において、OVH が完了したバックアップへのアクセスを顧客に提供できず、それを復旧のために保全できなかったとして、契約違反を認定した。しかし、OVH がサービスを地理的に隔離された場所に置かなかったことを過失とする、顧客の別途の主張は認めなかった。また、この紛争において OVH に重過失や重大な防火安全違反はなかったとする一審の判断を維持し、OVH の不可抗力の抗弁を認めず、関連する責任制限を有効とし、損害額を 1,800.48 ユーロに減額した。

この判断は、広く報道された一審の巨額賠償よりも狭く、より示唆に富む。これは、あらゆる OVH のバックアップ契約が遠隔データセンターを約束していたと立証するものではない。また、同一サイト内のバックアップが全て法的に不備であるという一般則を確立するものでもない。しかし、「顧客がバックアップポリシーを所有している」と言って責任を逃れられるわけではないことを示している。顧客がプロバイダーにバックアップの実行を委託して対価を支払い、できあがったコピーについてプロバイダーに契約上の義務がある場合である。

この事件はまた、契約上のラベルにはその背後にトポロジーが必要である理由を示している。「物理的に隔離された」「インフラ」「ローカル」「リージョン」「リモート」といった用語は、異なる意味を持ちうる。独立したディスクアレイはサーバー障害から隔離されている。別の部屋はラック火災から隔離されているかもしれない。別の建物は、一部の部屋の事象には耐えられるが、キャンパス全体の停電や周辺封鎖には必ずしも耐えられない。別のリージョンはより強固だが、それはリージョン間で制御やアカウント、鍵、ネットワークの依存関係を共有しておらず、それが復旧を妨げない場合に限る。

顧客がこれらの境界をマーケティング用の形容詞から推測しなければならないのは望ましくない。サービス説明は、そのコピーの障害ドメイン、その場所がデフォルトで選択されるのかオプションで選択されるのか、場所が変更され得るのか、その設計が耐えられることを意図するハザード、復旧目標、および顧客の残存する義務を明記すべきである。プロバイダーは、それらの表明の過去のバージョンを保持すべきである。なぜなら、サービス購入時に利用可能であったインターフェースや文書が、後に中心的な証拠となり得るからである。

契約上の制限と運営上の説明責任もまた、分岐する。控訴審での賠償額が少額だったのは、裁判所が主張と条項を評価した上で合意された制限を適用したからである。賠償上限額があるからといって、恒久的なデータ損失が運営上許容可能になるわけではない。同様に、申し立てられた巨額の損失が、プロバイダーが法的にその額を負担することを証明するわけでもない。契約は財務上のエクスポージャーを配分する。情報を復元したり、対策が適切に設計されていたことを証明したりはしない。

共有責任は、運用できるほど具体的でなければならない

「共有責任」という言葉は、しばしば「両当事者にやるべき作業があった」と言う婉曲な表現として使われる。その作業内容が明確にされない限り、このフレーズは失敗した後に非難を分配するものであり、事前に対策を割り当てるものではない。ストラスブールの事例は、より正確な区分を支持する。

OVH は、局所的な電気事象が建物の全焼にまで拡大する確率を所有していた。同社は物理的設計、火災検知と消火、区画化、ユーティリティの隔離、緊急手順、保守の枠組み、用水資源、公共消防機関との関係を選択した。顧客は、SBG2 にスプリンクラーを設置したり、緊急電源遮断装置を作ったりすることはできなかった。これらは、顧客との契約が損害賠償額を制限している場合であっても、プロバイダーの管理策である。

OVH はまた、自社製品についての真実も所有していた。自動バックアップがどこに保存されるのか、どのサービスがデフォルトでバックアップされるのか、どのリージョンがシステムを共有しているのか、ストラスブール喪失時にコントロールプレーンがどう挙動するのかを、唯一知り得たのはプロバイダーである。同社は、顧客がリスク判断を行えるように、これらの特性を十分に正確に説明しなければならなかった。OVH がバックアップサービスを引き受けた範囲では、約束されたサービスの履行と、結果として生じたコピーに関する証拠を所有していた。

顧客は結果モデルを所有していた。特定のマネージドアレンジメントがない限り、プロバイダーは、小さな仮想サーバーが使い捨てのテストサイトを保持しているのか、それとも何年分もの事業記録の唯一のコピーを保持しているのかを知ることはできなかった。顧客はデータを分類し、復旧目標を設定し、影響に見合ったアーキテクチャを選択し、主要な障害ドメインの外にコピーを保存し、再構築をテストする義務があった。インフラの購入は、自身のビジネスがその損失をどの程度許容できるかを判断する顧客の義務を移転するものではない。

境界線はサービスモデルによって移動する。管理対象外のベアメタルやサービスとしてのインフラストラクチャでは、顧客は通常、アプリケーション整合性のあるバックアップとフェイルオーバーを所有する。マネージドデータベース、ホスト型メール製品、あるいは明示的なバックアップサービスでは、プロバイダーがコピー、保持、整合性、復旧パスについてより多くの責任を所有する。マーケットプレイスの再販業者やマネージドサービスプロバイダーは、別のレイヤーを導入する。彼らは OVH を選択し、バックアップを構成し、自らの顧客に対してレジリエンスを表明し、唯一の管理アクセスを保持する可能性がある。エンドユーザーの顧客は、その連鎖を知る必要がある。

フランスのサイバーセキュリティ機関 ANSSI の現在のバックアップの基本原則は、これらの義務を実践的な対策へと変換している。それらは、目標復旧時点と目標復旧時間、3-2-1 パターン、少なくともオフラインまたは適切に保護されたオフサイトのコピー、定期的なリストアテスト、復旧の順序、そしてインストールメディアとアプリケーション構成の保護を求めている。アウトソースされたバックアップについて、ANSSI は EU 域内の保管場所、プロバイダーによるレプリケーションの動作、顧客管理の暗号化、そして復旧時間を重視している。これは、物理的なレジリエンス、サイバー隔離、主権、そして回復可能性が共に設計される必要があることを思い出させる有用なものである。

所在地は、いくつかの異なる疑問に答える

2021 年当時も今も、OVHcloud の欧州的なアイデンティティは重要である。欧州域外のハイパースケーラーに代わる選択肢を求める政府や規制対象組織にとって、欧州のデータセンターを運営するフランスのプロバイダーは、管轄権、経済、運用上の観点から有意義な利点を提供し得る。ストラスブールの火災は、データ主権を無価値にしたわけではない。主権が可用性エンジニアリングの代用にはならないことを示したのである。

「データはどこにあるのか？」という問いは、少なくとも次の 5 つの意味を持ち得る。

• 法的所在地：ストレージ、処理、アクセスに対して、どの国のデータ保護法、情報開示法、破産法、業界規制が適用されるか。
• 企業支配：どの親会社、管理者、サブプロセッサー、外国の法的要請がサービスに影響を与え得るか。
• 物理的所在地：各コピーが、どの建物、氾濫原、電力網、水道、キャンパス、地域的危険の中に存在するか。
• 論理的所在地：データを取り出すかフェイルオーバーするために、どのリージョン、ゾーン、アカウント、テナント、キーシステム、コントロールプレーンが動作しなければならないか。
• 運用上の距離：本番環境とその利用者、および復旧用コピーとの間には、どれほどの遅延、帯域幅、要員体制、復旧時間が存在するか。

「すべてのデータはフランス国内に留めなければならない」というポリシーは、第一の問いの一部に答え、第三の問いを制約するが、本番とバックアップに同じ建物を要求するわけではない。フランスには複数の大都市圏とクラウドリージョンが存在する。EU 域内での保存を要求するポリシーは、EU の法的境界を維持しつつ、さらに大きな地理的多様性を許容する。それが十分かどうかは、組織の準拠法、脅威モデル、データの機密性、復旧目標に依存する。

欧州委員会の国際移転に関する説明は、逆の単純化もまた防いでいる。すなわち、GDPR は、個人データが欧州経済領域（EEA）外に決して持ち出せないという絶対的なルールを課しているわけではない。移転のための十分性認定、セーフガード、および限定的な例外を提供している。一部の組織は、それにもかかわらず、業界法、公共政策、契約上の約束、または外国の管轄権への曝露を理由に、より厳格な所在地要件を採用している。

ANSSI のSecNumCloud 認定ガイダンスは、より豊かな主権モデルを示している。これは、顧客データだけでなく、管理、監督、バックアップ、ディレクトリ、技術データについても EU 域内での所在を要求し、同時に企業支配と EU 法外への曝露を考慮している。この枠組みは、単に一つのディスクの緯度経度ではなく、サービスとデータの支配に関するものである。

実際的な結論は建設的である。主権と災害分離は互いに強化し合うことができる。フランスの公的機関は、機密性の高い本番環境を一つの認定済み欧州環境に保持し、地理的に異なる EU 域内の復旧用コピーを保持し、顧客管理の暗号化と鍵を使用し、別の承認済み環境へのテスト済みの移行手順を保持することができる。このアーキテクチャはコストがかかり、慎重な法的レビューを必要とするかもしれない。トレードオフは、「ローカル」という言葉の背後に隠すのではなく、明示的であるべきだ。

集中は、市場の特性であると同時にアプリケーションの特性でもある

この停止は、政府のポータル、商業、メディア、ゲーム、公共向けサービスに影響を及ぼした。なぜなら、多くの組織が一つのプロバイダーを選択したか、サプライヤーを通じてそれを継承していたからである。これは市場レベルでのクラウド集中である。同時に、個々のアプリケーションの内部にも集中があった。すなわち、本番、バックアップ、DNS、メール、管理、デプロイメントツールが、別々の製品に見えても、OVH あるいはストラスブールを共有し得たのである。

この二つの形態は、異なる対処を必要とする。規制当局は、少数のクラウドプロバイダーに対するシステム全体の依存を監視できる。調達チームは、省庁横断的なプロバイダー集中を精査しないままにしておくことを避けられる。アプリケーションの所有者は、自身のサービスが復旧できるかどうかを決定づける依存関係をマッピングしなければならない。ある会社はポートフォリオ全体で三つのクラウドプロバイダーを使用しながら、依然として一つの重要なシステムに独立したコピーがないかもしれない。別の会社は一つのプロバイダーに留まりながら、真に分離されたリージョン、エクスポート可能なバックアップ、独立した DNS、オフラインの復旧用資料を使用するかもしれない。

金融規制は、このような保持されるべき顧客責任をますます明確に表現するようになっている。欧州銀行監督機構（EBA）の2019 年のアウトソーシングガイドラインは、対象となる金融機関に対し、アウトソーシングのリスクを管理し、単なる抜け殻になるのではなく、監督能力を維持し続けることを求めている。その後の EU デジタルオペレーショナルレジリエンス法（DORA）は、対象となる金融事業体に対し、バックアップ、復元、復旧の取り決めを維持し、定期的にテストすることを求めている。その第 12 条の要件には、事業体が自身のシステムを用いてバックアップデータを復元する場合の物理的および論理的な分離が含まれる。これらのルールには定義された適用範囲があり、2021 年の OVH の全顧客に遡及して投影されるべきではない。しかし、それらは説明責任ある実践の方向性を示している。すなわち、アウトソーシングは、統治機関の継続性に対する責任を外部委託するものではないということだ。

DORA の詳細な実施枠組みはさらに踏み込んでいる。2024 年の ICT リスク管理に関する委任規則は、事業所やデータセンターの部分的または全面的な喪失、サードパーティサービス障害、冗長キャパシティへの切り替え、広範囲な停電を含むシナリオを盛り込んでいる。ストラスブールはまさに、本格的な演習がモデル化すべき、物理的リスクとサプライヤーリスクの複合的な事象の類例である。

マルチプロバイダー設計は、一部の依存を減少させ得るが、自動的に優れているわけではない。それは、ID、ネットワーキング、データ整合性、スキル、可観測性、インシデント調整の複雑性を付加する。正しい目的は、重要な機能についての可搬性があり、テスト可能な復旧であり、アーキテクチャ上のスローガンではない。時には、それは独立したゾーンにまたがるアクティブなサービスを意味する。時には、別リージョンのウォームスタンバイ容量を意味する。時には、保護されたバックアップに加えて Infrastructure-as-Code とテスト済みの再構築が、はるかに低コストでビジネス要件を満たす場合もある。

復旧は顧客側から証明されなければならない

プロバイダーによる復旧と顧客の復旧は、同じ時計で進むわけではない。OVH は、電力、ネットワーク、大部分のサーバーが利用可能になった時点でデータセンターの運用再開を宣言できた。しかし顧客は、ファイルシステム、データベース、キュー、証明書、DNS、統合機能、ビジネストランザクションを検証する必要があった。元のサーバーが破壊された場合、顧客は代替サーバーをプロビジョニングし、データを取得し、アプリケーションを再構築し、最後の使用可能なコピー以降に発生した全てを調整する必要があった。

成熟した復旧演習は、便利なエクスポートではなく、想定される喪失から始まる。チームは、プライマリリージョンがアクセス不能であり、通常の管理者がその ID 経路を通じてログインできず、プロバイダーサポートが飽和状態にあると想定すべきである。障害が発生した環境の外部に保存された認証情報と鍵を使用してバックアップを取得し、承認された移行先でクリーンなキャパシティを構築し、文書化された順序で依存関係を復元し、データの整合性を検証し、ユーザーをリダイレクトし、ビジネス成果を測定すべきである。

証拠は実践的な問いに答えなければならない。復元されたデータベースのタイムスタンプはいつか？どの書き込みが失われたか？すべてのオブジェクトストアのバージョンが含まれていたか？アクセス制御を弱めることなく鍵を復旧できたか？DNS は想定時間内に変更されたか？外部の決済、メール、ID プロバイダーは新しいアドレスを受け入れたか？最初の安全なトランザクションまでどのくらいかかり、完全なキャパシティに戻るまでどのくらいかかったか？誰が復帰を承認し、どのような調整作業が残ったのか？

バックアップの監視だけでは、これらの問いに答えられない。ジョブの成功は、ソフトウェアが何かをターゲットに書き込んだことを証明する。整合性テストは、選択されたデータが読み取り可能であることを証明する。技術的な復旧は、システムが再構築可能であることを証明する。サービス演習は、想定された障害のもとで組織が優先機能を提供できることを証明する。それぞれが有用であるが、どれも次の段階の代理として表現されるべきではない。

これは、小規模な組織にとって特に重要である。彼らは、アクティブ-アクティブのインフラや専用のセカンドクラウドを必要としないかもしれない。比例的な脱出経路は必要である。小規模事業者は、データベースと重要な文書を、別のアカウントの下の暗号化された保存先にエクスポートし、ドメインとデプロイメント資格情報を独立して保持し、クリーンな再構築手順を文書化し、サンプル復元をテストできる。対策は、サーバーの月額料金ではなく、記録を喪失するコストに見合うべきである。

OVHcloud の改善策は物理的連鎖に対処した

OVH の BEA-RI への回答は、大規模な「Hyper Resilience」プログラムを説明した。同社は、検知を強化し、未装備の場所には自動消火設備を包括的に導入し、ゾーンと区画を再設計し、通常の耐火時間を 60 分から 120 分に引き上げ、新設サイトおよび既存サイトで可能な場所では電源室とバッテリー室をデータセンター建屋の外部に配置すると述べた。また、ゾーンごとの遠隔電力遮断を計画し、対応者が不必要に影響を受けていないエリアを無効化することなく危険を隔離できるようにした。

また、同回答によれば、インシデントから 4 か月以内に地元の消防隊が OVH の全サイトを訪問し、緊急文書と電力遮断手順が改訂され、新たな産業リスク部門が創設された。ストラスブールでは、OVH は SIS67 と協力して 120 立方メートルの自家用水槽を設置した。全サイトで火災リスク分析が実施され、作業完了時には脆弱性調査を通じて有効性が測定される予定である。2022 年 7 月に開設された SBG5 は、新基準の例として提示された。

これらの施策は、調査で明らかになった原因と伝播の連鎖によく対応している。消火設備は初期の延焼を抑える。より強力な耐火区画は垂直方向および建物間の延焼を抑える。外部電源室は発火源をサーバールームから隔離する。ゾーン別の遮断装置は、電気的隔離に伴う遅延と影響範囲の問題に対処する。水槽は初期対応能力に対処する。消防隊の訪問と訓練は、不慣れ、計画、指揮命令の課題に対処する。

OVHcloud の2025 年普通登録文書は、グループが 2025 年中もサイトのリスクマッピングを継続し、Hyper Resilience を規制上および保険会社の勧告を上回るデータセンターの安全性強化として説明している。また、ストラスブール火災の影響に対する引当金（賠償責任訴訟を含む）を引き続き計上している。これは、持続的なプログラムと財務上の取り扱いの証拠ではあるが、サイトごとの独立した完了証明書ではない。

説明責任を果たすためのクロージングとしては、適格な顧客や監査人に対して、以下の管理マトリックスを公開または提供すべきである。すなわち、どのサイトにおいて、関連する全ての電源室と IT 室に自動消火設備が設置されているか、どのサイトが 120 分耐火区画を有しているか、どのバッテリー室が建屋外部にあるか、どのゾーンが遠隔操作による遮断が可能か、どの用水流量要件がテストされたか、どの消防訓練が実施されたか、どの指摘事項が未解決か、そしてどの独立した第三者が動作を検証したか、である。ポリシーへのコミットメントは、改善の始まりに過ぎない。カバレッジと逆境を想定した演習が、それが機能するかどうかを示す。

同社はまた、困難な復旧作業中に詳細な公開更新ログを保存し、専門の清掃・復旧能力を動員し、インフラを交換し、製品固有の進捗を伝達し、安全勧告に対する正式な回答を公表した点でも、称賛に値する。透明性は、更新が頻繁であるというだけで完全になるわけではないが、これらの記録がなければ消えてしまう意思決定を、顧客や調査者が再構築することを可能にする。

製品設計は進歩したが、それでも構成がレジリエンスを決める

OVHcloud の現在のドキュメントは、Bati Courtage 事件で見られた火災前の文言よりも、障害ドメインについてずっと明確である。そのデプロイメントモードガイドでは、1 可用性ゾーン（AZ）リージョン、3AZ リージョン、ローカルゾーンを区別している。1AZ リージョンはデータセンター全体に影響する障害に対して脆弱なままであるが、3AZ アーキテクチャは、より要求の厳しい本番環境やディザスタリカバリのケースのために独立したゾーンを使用する、と述べている。

同社のリージョンおよび可用性ゾーンの概要も同様に、より高いレジリエンスを求める顧客は、サポートされているマルチゾーンリージョンを選択し、複数のゾーンにまたがる構成を構築すべきだとしている。ここで動詞が重要である。プロバイダーはゾーンを提供し、顧客がリソースとアプリケーションの状態をそれらに分散させなければならない。3AZ リージョンで起動するだけでは、1 台の仮想マシン、1 つのデータベース、手動で配置されたボリュームがゾーンにまたがることを保証しない。

現在のインスタンスバックアップのドキュメントでは、ローカルバックアップと遠隔バックアップを区別している。ローカルバックアップは同じリージョンに留まる。遠隔バックアップは、選択した別のリージョンにコピーを作成し、別途課金される。これは、はるかに明確な障害ドメインの表現である。同時に、明示的な顧客の選択を保持しており、これは調達と構成が依然として管理の一部であることを意味する。

現在のドキュメントを、2021 年 3 月にすべての顧客に何が提供されていたかを再構築するために使用すべきではない。それは、現在の説明責任の問いに関連する。すなわち、市場は所在地とレジリエンスを別々に提示することを学んだか？OVHcloud は現在、これらの製品ガイドの中でそうしている。次の保証ステップは、製品ページ、契約、コントロールパネルのデフォルト設定、API、請求書、サポート応答に至るまで、この区別を一貫させることである。これには、プロバイダー管理のバックアップが異なるルールに従う製品も含まれる。

より安全な設計は、段階的なデフォルト設定によっても実現できる。低コストの開発用サービスでは、インスタンス障害からの保護としてラベルが付けられており、地域災害からではないことがインターフェースに明示されていれば、ローカルバックアップをデフォルトとすることは合理的かもしれない。本番データベースや「バックアップ」と銘打った製品では、顧客に障害ドメインの確認を求め、すべてのコピーが単一のサイトを共有している場合に警告を表示し、同一法域内の遠隔地を提供することが考えられる。目的は、すべてのワークロードを最も高価なアーキテクチャに強制することではなく、情報に基づいたリスク受容である。

取締役会は、二つのコントロールプレーンにわたる証拠を必要とする

ストラスブール火災は、施設のコントロールプレーンと顧客の復旧のコントロールプレーンを横断した。OVH の取締役会とリスク管理責任者は、この両方について保証を必要とする。防火工学は不動産の脚注として扱われるべきではなく、バックアップ製品は単なるストレージの収益としてのみ扱われるべきではない。

施設レイヤーについて、経営陣は、単なる機器の冗長性ではなく、各サイトにおける想定最大損失額を知るべきである。報告には、消火設備のカバレッジ、区画の完全性、電源室の分離状況、検知性能、緊急用水、電力遮断所要時間、消防隊の習熟度、保守に関する例外事項、期限を過ぎた是正作業を含めるべきである。演習では、通常の対策が機能せず、消防士がエネルギー源を隔離するために即座かつ正確な権限を必要とする状況を想定すべきである。

サービスレイヤーについて、経営陣は、製品の障害ドメインがどのように表現され、テストされているかを知るべきである。報告には、「バックアップ」や「高可用性」といった表現で販売されているサービスのうち、どれだけが全コピーを単一のサイトまたはリージョンに保存しているか、何人の顧客が遠隔保護を選択したか、製品とデータ規模ごとの復旧成功率、鍵と ID の依存関係、復旧時間の分布、ドキュメントの乖離、そして顧客が所在地を誤解していたことを示す苦情を含めるべきである。

取締役会はまた、平均値ではなく例外の報告も受けるべきである。バックアップジョブの成功率が 99.99%であっても、何千ものコピーが一つの物理的ドメイン内に存在し得る。全体的な消火設備の導入率は、一つの古い高密度の建物を隠し得る。平均復旧時間は、最も大規模で影響の大きいデータセットを覆い隠し得る。テールリスクのエクスポージャーはガバナンスに属する。なぜなら、ストラスブールは、影響が集中したテールイベントだったからだ。

独立した立場からの検証は、一つの顧客への約束を最初から最後まで追跡すべきである。バックアップ済みと謳われているサービスを一つ選ぶ。インターフェースと契約に何と記載されているかを記録する。それぞれのコピーとその管理メタデータの所在を突き止める。演習からプライマリサイトを取り除く。通常の ID およびサポート経路を拒否する。顧客の所在地ルールを満たす移行先で復旧する。測定結果を約束された復旧目標と比較する。いかなる断絶も、それが製品、インフラ、サポート、あるいは顧客のいずれに帰属するものであれ、対処可能なギャップである。

サービスを「レジリエント」と呼ぶ前に顧客が要求すべきこと

組織は、すべてのデータセンターの設計図にプライベートにアクセスする必要はない。しかし、サービスが障害の結果に見合うかどうかを判断するのに十分な詳細な回答を必要とする。以下の質問は、ストラスブールの教訓を調達の証拠に変えるものである。

回答は、対象製品に厳密に結びつけられなければならない。プロバイダーの企業レジリエンスレポートは、購入される低価格 VPS やローカルスナップショット、マネージドデータベースを説明していないかもしれない。認証は有用な管理策を確立し得るが、適用範囲の除外があるかもしれない。可用性 SLA は、基準を下回った場合の救済策を提供するが、それ自体がデータの耐久性を説明するわけでも復旧を保証するわけでもない。

顧客はまた、再販業者名の背後にある依存の集中も検証すべきである。マネージドバックアップベンダーが、そのリポジトリを本番と同一の OVH リージョンに保存しているかもしれない。セカンダリのホスティングブランドが、その基盤として OVH を使用しているかもしれない。DNS、メール、ソースコード、シークレット、インシデントコミュニケーションがすべて同一のプロバイダーを共有しているかもしれない。多様性は、生き残る経路の数によって測られるのであって、請求書の数によってではない。

最後に、顧客は、どれだけの損失が許容可能かを決定しなければならない。リージョン災害全体にわたってデータ損失ゼロとほぼゼロのダウンタイムを達成するには、継続的なレプリケーション、アプリケーション設計、キャパシティ、および高価になり得る運用テストが必要である。週次のオフラインコピーは、静的なアーカイブには十分かもしれないが、トランザクションデータには破滅的である。説明責任は、すべてに同じ対策を要求するのではない。それは、結果、約束された復旧、アーキテクチャ、証拠の間に、意識的な関係を要求するのである。

永続的なシグナル

ストラスブールの火災は、単に不幸な発火とそれに続くバックアップの重要性を再認識させる出来事ではなかった。それは、抽象的思考が物理的ストレスの下でどのように機能不全に陥るかを示す実例であった。別々の建物が単一の緊急サイトを形成した。損傷していないサーバーが、損傷したサーバーと共に利用不能になった。完了していたバックアップが本番と共に消失し得た。主権とレイテンシのために機能していた欧州のロケーションが、火災リスクの集中点となり得た。代替サーバーは、顧客のビジネスを復旧させることなく、インフラを復旧させることができた。

公開記録はまた、意味のある改善も含んでいる。検知と夜間スタッフは人命を守った。消防隊と消防艇 EUROPA は延焼を抑えた。OVH は、困難で透明性のある復旧を実施し、BEA-RI の勧告を運用面で受け入れ、広範な物理的レジリエンスプログラムを開始した。現在の製品文書は、ローカルバックアップと遠隔バックアップ、シングルゾーンとマルチゾーンのデプロイメントを、以前より明確に区別している。これらは表面的な変更ではない。

残る説明責任の基準は、長期にわたる証拠である。OVH は、火災後に特定された物理的対策が、関連サイト全体で導入、維持、訓練されていること、製品文言が実際の障害ドメインにマッピングされていること、そして、あるリージョンとその通常の制御経路が存在しない場合に、管理された復旧が機能することを示せなければならない。顧客は、重要なデータが主要なハザードの外側に、承認された法的境界内に使用可能なコピーを有し、自らの担当者が事業目標の時間枠内でそれを復元できることを示せなければならない。

どのクラウドプロバイダーも、建物が決して燃えないとは約束できない。いかなる顧客も、すべての依存を排除できない。信頼に足る約束は、より狭いものである。すなわち、一つの予見可能な物理的事象が、本番、復旧手段、失われたものを理解する手段を音もなく飲み込むことがないようにすること、所在地の選択は管轄権とハザードの両方について明示的であること、そして「バックアップ」という言葉が、最終的に唯一重要な証拠、つまり、そのコピーが購入された条件の下での復旧の成功によって裏付けられることである。