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

概要

• 2021年3月10日午前0時35分、OVHcloud のストラスブール拠点で火災警報が作動。火災は SBG2 の1階のエネルギー室で発生し、同建物を全焼、SBG1 の12室中4室に損傷を与え、キャンパス全体の電源を遮断せざるを得なくなった。SBG3 と SBG4 は初期火災では焼失しなかったが、電気的隔離、安全点検、清掃、段階的な再起動が必要だったため、サービスは利用不能となった。死傷者はいなかった。
• フランスの産業安全調査では、UPS とそれに接続された鉛蓄電池でほぼ同時に発生した電気的故障の正確な原因は特定されなかった。伝播と対応の要因は特定された：ストラスブールの5棟の建物にはいずれも自動消火設備がなく、SBG2 の開放的な冷却設計により煙が急速に広がり、消火用水が不足し、現場全体の電源遮断が困難だったことなどである。一方、作動した検知器、夜間の職員配置、SBG3 を保護した耐火隔壁、そして高能力の仏独共同消防艇の到着が、より深刻な結果を防いだ。
• 可用性の喪失と恒久的なデータ損失は異なる結果だった。OVHcloud は約6万5千の顧客と12万のサービスが影響を受けたと報告し、Netcraft は約464,000のドメインにわたる約360万のウェブサイトがオフラインになったと観測した。OVHcloud は、データを失った顧客の多くがオプションのバックアップを選択していなかったと述べた。これは説明責任の問題を終わらせるものではない。OVHcloud 自身の登録文書では、提供されるバックアップが同じデータセンターまたは異なるデータセンターに保存される可能性があると記載されており、後の控訴審判決では、有料の自動バックアップが本番環境と同じ建物で破壊された顧客に関する判断が下された。
• この事象は、クラウド調達におけるカテゴリーエラーを露呈した。データ主権、法的管轄、レイテンシ、可用性、バックアップ、災害復旧は関連しているが、同じではない。データをフランスまたは EU 内に留めることは、ローカリティポリシーを満たす一方で、本番環境と復旧用コピーが同じ物理的危険を共有することを許容しうる。逆に、地理的に離れたコピーは、同じ法的領域内に留まり、同一の欧州規制の下に置くことができる。
• OVHcloud は火災後の大幅な変更を開示した。これには、より広範な自動消火設備、強化された区画化、独立したエネルギー室、遠隔電気遮断、拠点監査、消防機関との連携、新しいマルチゾーンおよび遠隔バックアップオプションが含まれる。しかし、説明責任のあるクロージャーには、サービスおよび拠点固有のエビデンスが必要である。すなわち、完了した制御のカバレッジ、独立した検査、現実的な火災および電源隔離訓練、宣言されたバックアップ場所、成功したリストアテスト、そして顧客の復旧が被災リージョンや同一のコントロールプレーンに依存しないことの証明である。

物理的な火災がクラウドの説明責任イベントとなった

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

ストラスブールはその物理的な連鎖を可視化した。2021年3月10日未明、火災は OVHcloud のポール・デュ・ランにあるキャンパスの建物の一つである SBG2 を破壊した。SBG1 は部分的に破壊された。現場の他の2つのデータセンターは、当初の会社発表では「無傷」とされていたにもかかわらず、シャットダウンされた。したがって、損失は少なくとも3つの異なるメカニズムを通じて伝播した。機器が物理的に破壊されたこと、隣接する建物の機器が熱、煙、水、または不確実性にさらされたこと、そして健全な機器が現場の電気的隔離と安全確保のために利用できなくなったことである。

これらのメカニズムは、異なる制御に対応するため重要である。自動消火設備と区画化は火災を封じ込めることができる。独立した電力ゾーンは、消防士が遮断を必要とする範囲を縮小できる。マルチサイトアプリケーションは、1つのサイトが利用不能な間も継続できる。リモートの検証済みバックアップは、データ破壊後の再構築をサポートできる。ステータスページは、これらのオプションを通じて顧客を導くことができる。これらすべてを「冗長性」と呼ぶことは、誰が各レイヤーを管理し、どのような事象に耐えられるのかを隠蔽する。

最も信頼できる公的な再構築は、フランス産業事故調査局（BEA-RI）の2022年5月の調査報告書である。その任務は民事上または刑事上の責任の割り当てではなく、予防であった。この境界は重要である。報告書は観察事項、考えられる原因、寄与因子、安全勧告を確立することができるが、特定されたあらゆる弱点が過失であったとか、ある弱点が特定の顧客の損失を法的に引き起こしたという裁判所の認定に転用することはできない。

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

証拠が確立していることと、そうでないこと

BEA-RI 報告書は、最初の警報を午前0時35分としている。警備員が0時37分に SBG2 のエネルギー室に到着し、濃い黒煙を発見した。建物からの避難は0時39分、バ＝ラン県消防救助局への通報は0時42分、最初の部隊到着は0時59分だった。OVH の公開インシデントページでは、火災発生時刻を0時47分としていた。この差は一つのタイムスタンプに押し込めるのではなく、保存されるべきである。安全調査は警報と運用記録へのアクセス権を持っていた一方、会社のページは公開用のインシデントマーカーを提供した。

SBG2 への非常用電源は1時13分に遮断され、SBG1、SBG3、SBG4 へは1時28分に遮断された。消防隊は電気アーク放電を目撃しており、危険を制御できるまで大規模な放水を控えた。1時42分までに火災は1階全体に拡大した。午前2時ごろ、消防隊は SBG2 の全面的な炎上を報告した。高能力消防艇 EUROPA が近くの水路を利用して午前3時ごろに到着した。火災は10時2分に鎮火し、対応終了は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 の当時のストラスブール更新ログは、復旧の物理的な性格を異常なほど可視化している。チームは、部屋ごと、通路ごと、ラックごと、サーバーごとに機器を取り外し、清掃、点検、再設置、再起動した。煤塵に汚染されたサーバーは、専門作業のためクロワの工場に移された。SBG1 からの回収可能なマシンは他のデータセンターに移設された。データ復旧の専門家が、損傷した部屋からディスクの回収を試みた。

最初の復旧は一様ではなかった。SBG3 は3月18日に運用可能となった。3月19日夜、接続されていなかった SBG1 の蓄電池室で煙が検知された。OVH は予防措置として SBG1 と SBG4 を再度シャットダウンし、再起動スケジュールを修正した。サービスの復旧は3月22日に再開された。3月下旬までに、SBG4 のベアメタルサーバーはアクセス可能となり、SBG3 のサービスはパーセンテージ単位で復旧しつつあったが、SBG1 の機器は依然として清掃、修理、移設の途上にあった。

OVH の登録文書は後に、ほとんどの顧客サービスが3～4週間以内に復旧し、影響を受けた約6万5千の顧客が利用する約12万のサービスが5月初めまでに完全に復旧したと述べた。「サービス復旧」を「全データ復旧」と読んではならない。代替サーバーはプロビジョニングできるが、顧客のかつてのディスクと記録は破壊されたままかもしれない。復旧報告は、インフラの可用性、アプリケーションの起動、データ復元、データの最新性、ビジネス受け入れを区別しなければならない。

拠点全体のシャットダウンは、「データセンター」という言葉が災害計画にとって粗すぎる理由も示している。障害ドメインとは、ハザードが一緒に影響を及ぼしうるすべてである。ストラスブールでの火災対応にとって、関連するドメインには、隣接建物、電源隔離手順、緊急アクセス、水容量、煙、共有オペレーション、そして再入室を管理する安全当局が含まれた。複数の建物名は、同じ緊急時の決定がそれらすべてを利用不能にしうるのであれば、独立した復旧を生み出さない。

影響を数えるには複数の数字が必要

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

OVH の6万5千の影響顧客と12万のサービスは、商取引および製品の関係を表している。どちらの数字も、何人のエンドユーザーがサービスに到達できなかったか、何社が収益チャネルを失ったか、あるいはどれだけのデータセットが回復不能だったかは示していない。同時代のロイター報道は、政府ポータル、銀行、商店、ニュースサイト、その他のオンラインサービスが混乱に含まれていたと特定した。これらの例は結果の多様性を示すものであり、全数調査ではない。

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

したがって、説明責任のあるインシデントレポートは、顧客数、サービス数、物理サーバー数、ドメイン数、外部到達不能アドレス数、停止期間帯、プロバイダーによるリストア成功数、顧客主導の再構築数、恒久的データ損失件数といった複数の分母を使用すべきである。また、バックアップなし、同一建物内コピー、同一拠点内コピー、異なる OVH リージョン、または独立した管理下にあるコピーを持っていた顧客の数を特定すべきである。公開されている証拠は、この完全なマトリックスを提供していない。

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

バックアップとは将来のリストアに関する約束である

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

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

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

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

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

フランスのデータ保護当局 CNIL は現在、バックアップセキュリティガイダンスの中で物理的な教訓を明確に述べている：少なくとも1つのコピーを地理的に異なる拠点に保管し、少なくとも1つのコピーをオフラインで隔離し、バックアップを本番環境と同じセキュリティレベルで保護し、整合性と復元をテストすること。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 がバックアップサービスを請け負った場合、約束されたサービスの履行と、生成されたコピーに関する証拠を所有していた。

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

境界はサービスモデルとともに移動する。アンマネージドのベアメタルまたは Infrastructure as a Service（IaaS）では、顧客は通常、アプリケーション整合性のあるバックアップとフェイルオーバーを所有する。マネージドデータベース、ホスティッドメール製品、または明示的なバックアップサービスでは、プロバイダーはコピー、保持、一貫性、リストア経路のより多くを所有する。マーケットプレイスの再販業者やマネージドサービスプロバイダーは、別の層を導入する。すなわち、OVH を選択し、バックアップを構成し、自らのクライアントに対してレジリエンスを表明し、唯一の管理アクセスを保持するかもしれない。エンドカスタマーはその連鎖を知る必要がある。

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

ローカリティはいくつかの異なる質問に答える

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

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

• 法的所在地：どの国のデータ保護、開示、倒産、セクター規則が保存、処理、アクセスを統治するか。
• 企業支配：どの親会社、管理者、サブプロセッサー、外国の法的要求がサービスに影響を与えうるか。
• 物理的所在地：どの建物、氾濫原、送電網、給水、キャンパス、地域的ハザードが各コピーを包含するか。
• 論理的所在地：データを取得したりフェイルオーバーしたりするために、どのリージョン、ゾーン、アカウント、テナント、キーシステム、コントロールプレーンが動作しなければならないか。
• 運用距離：本番環境とそのユーザー、および復旧用コピーを隔てるレイテンシ、帯域幅、人員配置、復旧時間はどれほどか。

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

欧州委員会の国際データ移転に関する説明は、反対の単純化も防いでいる。GDPR は、個人データが欧州経済領域（EEA）を離れてはならないという絶対的なルールを課しているわけではない。移転のための十分性認定、保護措置、限定的な例外を規定している。しかし、一部の組織は、セクター法、公共政策、契約上の約束、外国の管轄権への露出のために、より厳格なローカリティ要件を採用している。

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

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

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

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

この二つの形態は異なる対応を必要とする。規制当局は、少数のクラウドプロバイダーへの体系的な依存を監視できる。調達チームは、部門全体にわたる無審査のプロバイダー集中を避けることができる。アプリケーション所有者は、自身のサービスが復旧可能かどうかを決定する依存関係をマッピングしなければならない。ある企業はポートフォリオ全体で3つのクラウドプロバイダーを使用していても、一つの重要なシステムには依然として独立したコピーがないかもしれない。別の企業は単一のプロバイダーを使い続けながら、真に独立したリージョン、エクスポート可能なバックアップ、独立した DNS、オフラインの復旧資料を使用するかもしれない。

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

DORA の詳細な実施枠組みはさらに進んでいる。2024年の ICT リスク管理に関する委任規則には、施設やデータセンターの部分的または全面的な喪失、サードパーティサービスの障害、冗長キャパシティへの切り替え、広範囲な停電を伴うシナリオが含まれている。ストラスブールはまさに、真剣な演習がモデル化すべき種類の、物理的イベントとサプライヤーイベントが組み合わさったものである。

マルチプロバイダー設計は一部の依存関係を減らすことができるが、自動的に優れているわけではない。ID、ネットワーク、データ一貫性、スキル、可観測性、インシデント調整の複雑さが加わる。正しい目標は、重要な機能のための移植可能でテスト可能な復旧であり、アーキテクチャ上のスローガンではない。それは時に、独立したゾーンにわたるアクティブなサービスを意味する。時に、別のリージョンでのウォームキャパシティを意味する。時に、保護されたバックアップに加え、Infrastructure as Code と訓練された再構築が、はるかに低いコストでビジネスニーズを満たす。

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

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

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

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

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

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

OVHcloud の是正は物理的連鎖に対処した

OVH の BEA-RI への回答は、「ハイパーレジリエンス」プログラムと呼ばれる大規模な取り組みを説明している。同社は、検知の強化、未装備箇所への自動消火の一般化、ゾーンと区画化の再設計、通常の耐火性能を60分から120分への引き上げ、新設拠点および既存拠点で可能な場合にはエネルギー室と蓄電池室をデータセンター建屋の外に配置することを述べた。影響を受けていないエリアを不必要に無効化することなく、消防隊が危険を隔離できるよう、ゾーンごとの遠隔電気遮断も計画された。

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

これらの措置は、調査の原因および伝播の連鎖によく対応している。消火設備は初期の成長に対処する。強化された防火区画は垂直方向および建物間の延焼に対処する。外部のエネルギー室は発火源をサーバー室から分離する。ゾーン別の遮断は、電気的隔離の遅延と影響範囲に対処する。貯水は初動対応能力に対処する。消防訪問と訓練は、不慣れ、計画、指揮決定に対処する。

OVHcloud の2025年ユニバーサル登録文書は、グループが2025年中も継続して拠点リスクマッピングを実施し、ハイパーレジリエンスがデータセンターの安全性を規制や保険会社の推奨を上回る水準に強化していると述べている。また、責任訴訟を含むストラスブール火災の影響に対する継続的な引当金も計上している。これは継続的なプログラムと財務処理の証拠ではあるが、拠点ごとの独立した完了証明書ではない。

説明責任のあるクロージャーは、管理マトリックスを公表するか、資格を有する顧客や監査人に提供することである。すなわち、どの拠点がすべての該当するエネルギー室と IT 室に自動消火設備を備えているか、どれが120分区画を備えているか、どの蓄電池室が外部にあるか、どのゾーンに遠隔操作の隔離装置があるか、どの水流要件がテストされたか、どの消防訓練が実施されたか、どの未解決の所見が残っているか、そしてどの独立機関が運用を検証したかである。方針のコミットメントは是正の始まりに過ぎない。カバレッジと敵対的演習が機能するかどうかを示す。

同社はまた、困難な復旧中に詳細な公開更新ログを維持し、専門の清掃・復旧能力を動員し、インフラを交換し、製品固有の進捗を伝達し、安全勧告に対する公式回答を公表したことについて、評価されるべきである。更新が頻繁であるというだけで透明性が完全になるわけではないが、これらの記録により、顧客や調査官はそうでなければ消えてしまう決定を再構築することができる。

製品設計は進んだが、構成が依然として復旧力を決定する

OVHcloud の現在の文書は、Bati Courtage 紛争で見られた火災前の文言よりも、障害ドメインについてより明示的である。デプロイメントモードガイドは、単一アベイラビリティゾーンのリージョン、3ゾーンのリージョン、ローカルゾーンを区別している。1-AZ リージョンは、データセンター全体に影響する障害に対して依然として脆弱である一方、3-AZ アーキテクチャは、より要求の厳しい本番環境や災害復旧のケースに独立したゾーンを使用すると述べている。

同社のリージョンとアベイラビリティゾーンの概要も同様に、より高い復旧力を求める顧客は、サポートされているマルチゾーンリージョンを選択し、複数ゾーン向けに構築するべきだと述べている。動詞が重要である。プロバイダーがゾーンを供給し、顧客がリソースとアプリケーション状態をそれらに分散させなければならない。単に3-AZ リージョンで起動したからといって、1つの仮想マシン、1つのデータベース、あるいは手動で配置された1つのボリュームがゾーンにまたがることを保証するわけではない。

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

現在の文書は、2021年3月に各顧客に何が提供されていたかを再構成するために用いられるべきではない。これは、市場がローカリティと復旧力を別々に開示することを学習したかという、現在の説明責任の質問に関連する。OVHcloud は現在、これらの製品ガイドでそうしている。次の保証ステップは、この区別を製品ページ、契約、コントロールパネルのデフォルト、API、請求書、サポート応答にわたって一貫させ、プロバイダー管理のバックアップが異なるルールに従う製品を含めることである。

より安全な設計は、段階的なデフォルトを使用することもできる。低コストの開発サービスは、インスタンス障害からの保護であり、リージョン災害からではないとインターフェースがラベル付けしている場合、合理的にローカルバックアップをデフォルトとすることができる。本番データベースやバックアップブランドの製品は、顧客に障害ドメインを確認させ、すべてのコピーが1つの拠点を共有している場合に警告を表示し、同じ法的リージョン内で遠隔の宛先を提供することを要求できる。目的は、すべてのワークロードを最も高価なアーキテクチャに強制することではなく、情報に基づいたリスク受容である。

取締役会は二つのコントロールプレーンにわたるエビデンスを必要とする

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

施設レイヤーについては、リーダーシップは、機器の冗長性だけでなく、各拠点における最大予想損失を知るべきである。報告書は、消火設備のカバレッジ、区画の完全性、エネルギー室の分離、検知性能、緊急用水、電源隔離時間、消防の習熟度、メンテナンス例外、期限超過の是正作業を示すべきである。演習は、通常の制御が失敗し、消防士がエネルギーを隔離するために即座に正確な権限を必要とすることを想定すべきである。

サービスレイヤーについては、リーダーシップは、製品の障害ドメインがどのように表現されテストされているかを知るべきである。報告書は、バックアップや高可用性の文言で販売されているサービスのうち、どれだけがすべてのコピーを1つの拠点またはリージョンに保存しているか、どれだけの顧客が遠隔保護を選択したか、製品別および規模別のリストア成功率、キーと ID の依存関係、復旧時間の分布、文書のずれ、顧客が場所を誤解していることを示す苦情を示すべきである。

取締役会はまた、平均値だけでなく例外も受け取るべきである。99.99%のバックアップジョブ成功率は、1つの物理ドメインに何千ものコピーが存在することと共存しうる。グローバルな消火設備の普及率は、1つの古い高密度建物を隠しうる。平均復旧時間は、最大かつ最も重要なデータセットを隠しうる。ストラスブールは影響が集中したテールイベントであったため、テールエクスポージャーはガバナンスに属する。

独立したチャレンジは、顧客への約束をずっと下まで追跡すべきである。バックアップ付きとして販売されているサービスを選択する。インターフェースと契約が何と言っているかを記録する。各コピーとその管理メタデータを特定する。プライマリ拠点を演習から除外する。通常の ID およびサポート経路を拒否する。顧客のローカリティルールを満たす宛先で復旧する。測定された結果を約束された復旧目標と比較する。いかなる断絶も、製品、インフラ、サポート、または顧客のいずれが所有するにせよ、対応可能なギャップである。

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

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

回答は正確な製品に結び付けられるべきである。プロバイダーの企業レジリエンスレポートは、購入されている低予算の VPS、ローカルスナップショット、マネージドデータベースを説明していないかもしれない。認証は有用な管理を確立しうるが、範囲除外があるかもしれない。可用性 SLA は、しきい値を超えた後の救済策を提供するが、それ自体はデータの耐久性を説明したり、復旧を保証したりするものではない。

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

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

永続的なシグナル

ストラスブールの火災は、単なる不幸な発火とそれに続くバックアップを取るよう促す教訓ではなかった。それは、物理的なストレスの下で抽象化がどのように破綻するかの実証であった。別々の建物が一つの緊急事態サイトを形成した。健全なサーバーが損傷したものとともに利用不能になった。完了したバックアップが本番環境とともに消えうることが示された。主権とレイテンシに資する欧州の所在地が、火災リスクの集中点になりうることが示された。代替サーバーは、顧客のビジネスを復旧することなく、インフラを復旧できた。

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

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

いかなるクラウドプロバイダーも、建物が決して燃えないと約束することはできない。いかなる顧客も、すべての依存関係を排除することはできない。信頼できる約束はより狭い。すなわち、一つの予見可能な物理的イベントが、本番環境、復旧手段、そして何が失われたかを理解する手段を黙って消費しないこと、ローカリティの選択が管轄権とハザードの両方について明示的であること、そして「バックアップ」という言葉が、最終的に重要な唯一の証拠、すなわちそのコピーが購入された条件の下での成功したリストアによって裏付けられることである。