要約

  • 保守の目的は攻撃が激しくなる時期に対DDoS防御を強化することだったが、DDoS攻撃が障害を引き起こしたわけではない。直接の障害経路は、計画された本番ルーティング変更にあった。
  • OVHcloudによれば、BGPからOSPFへの再配送に関するコマンドをルーターが正しく解釈せず、インターネットの経路表全体が内部のIGPへ広告された。OSPF表が満ち、RAMとCPUが過負荷になり、BGPとOSPFの収束ループによってIPv4ルーティングが機能しなくなった。
  • 詳細な事故記録では、変更開始は09時05分、問題発生は09時20分ごろ、切り戻し失敗の確認は09時30分まで、故障ルーターの電源断は10時18分、最初のサービス復帰は10時20分、技術的危機の終了は10時57分とされる。単一の時間幅だけで語るべき事故ではない。
  • CAB、MOP、ピアレビューは実施されていた。したがって説明責任の中心は「審査がなかった」ことではなく、コマンドの意味、変更前検証、影響範囲の制限、切り戻しの実効性、帯域外アクセス、観測可能性を審査がなぜ十分に保証できなかったかにある。
  • 影響はIPv4の到達性障害であり、IPv6は到達可能なままだった。顧客データの喪失、サーバーやデータセンターの物理的損壊、正確な顧客数や損失額は公表記録からは確認できない。

対DDoSという目的と、障害原因を分ける

事故の発端を正しく捉えるには、保守の目的と技術的な原因を切り分けなければならない。OVHcloudは、攻撃がより激しくなっていた時期に対DDoS保護を強化するため、ネットワーク変更を計画したと説明している。この背景は、なぜ変更が行われたかを示す。しかし、攻撃がルーティング障害を直接起こしたという証拠ではない。

実際にサービスを止めたのは、本番環境で行われたBGPからOSPFへの再配送変更だった。DDoSを原因と呼べば、制御可能だった変更の設計と実行が、外部脅威の影に隠れてしまう。逆に、保守の動機を無視すれば、組織が防御能力を高めようとしていた運用上の文脈を失う。説明責任には、その両方を同時に保持する精度が要る。

この区別は危機広報にも関係する。「攻撃への対策中だった」という説明は、原因の帰属を曖昧にしやすい。経営者と運用責任者は、脅威が変更を必要にしたという判断と、変更が安全に実施されたかという判断を別々に示す必要がある。脅威の深刻さは、変更管理の欠陥を免責しない。

BGPの経路がOSPFの資源限界へ流れ込んだ

BGPは、ネットワーク間で到達可能性を交換するために使われる。OSPFは、組織内部で経路を計算するIGPである。両者の間で経路を再配送する操作は、単なる設定項目ではない。取り込む経路の範囲、属性、フィルター、集約、優先順位を誤れば、外部の巨大な経路状態を内部の制御プレーンへ持ち込むことになる。

OVHcloudの事故記録では、対象ルーターがコマンドを正しく解釈しなかった。その結果、インターネットの経路表全体がIGPへ広告された。正確な経路数や装置モデルは公表されていないが、失敗の型は明確である。OSPF表が満ち、ルーターのRAMとCPUが過負荷となり、BGPとOSPFの間の収束ループがIPv4ルーティングを使えない状態にした。

ここで重要なのは、設定ファイル上の意図と、稼働中の装置が受け入れた状態が異なったことである。変更申請書に「対DDoS強化」と書かれていても、ネットワークの現実は実際に広告され、受理され、計算された経路で決まる。承認された意図は、実行時の経路制御を代替できない。

再配送の安全性を証明するには、コマンドの文法確認だけでは足りない。受け側の最大経路数、フィルターの既定動作、経路の急増率、CPUとメモリーの余裕、隣接関係への影響、ループ形成の可能性まで、事前と実行中に観測できなければならない。検証環境が本番の経路規模や装置挙動を再現できないなら、その差自体が承認時に見えるリスクとして扱われるべきだ。

一つの「障害時間」では説明できない

詳細な事故記録は、変更を09時05分に開始したとしている。09時18分にはBGPの隔離と設定作業が記録され、09時20分にネットワーク設定の問題が発生した。09時21分にはルーター性能の問題が検知され、エスカレーションされた。09時30分までには切り戻しが失敗し、物理的な隔離を選ぶ状況になっていた。

現地で故障ルーターの電源を切ったのは10時18分だった。ネットワークが収束した後、最初のサービスは10時20分に戻った。OVHcloudが技術的な危機の終了を記録したのは10時57分である。したがって、最も強い表現は、IPv4到達性が09時20分ごろから失われ、10時20分に最初のサービスが戻り、その後も10時57分まで安定化が続いた、という段階的な説明である。

同日早い時点の運用者向け更新には、介入開始を09時12分、隔離を10時15分とする粗い時刻もあった。この違いは、どちらかを都合よく選んで分単位の断定を強める理由にはならない。初期の危機通信と、後に整理された詳細な事故記録が異なる粒度を持つことを示す。時系列の精度は、復旧速度の評価や、誰がどの情報をいつ持っていたかを検討する前提になる。

IPv4の停止とIPv6の継続が故障境界を示す

OVHcloudは、ネットワーク全体に混乱が及び、自社サイト向けのIPv4トラフィックを正しく処理できなかったと説明した。独立報道は、OVHcloudのサーバーや顧客サイトが到達不能になり、同社の公開サイトがエラーを返し、ステータスページにもアクセスできない状態を観測している。

一方、IPv6は到達可能なままだった。この差は細部ではない。建物全体の電源や全サーバーが失われたのではなく、特定のアドレスファミリーにおけるルーティング制御が壊れたことを示す重要な故障境界である。利用者から見れば「サイトが落ちた」ように映っても、基盤内部ではIPv4とIPv6の挙動が分かれていた。

この境界を無視すると、別の2021年事故であるストラスブールのデータセンター火災と混同しやすい。10月の事故について、設備が焼損した、サーバーが破壊された、顧客データが失われたとする根拠はない。支えられる説明は、ルーティング到達性の障害である。物理資産の損壊と論理制御プレーンの失敗を分けることは、復旧策を正しく評価するためにも不可欠だ。

広い影響を認めても、架空の総数は作らない

独立報道は、OVHcloudの顧客サイト、自社の公開サイト、ステータスページが利用できなくなった状況を記録した。フランスの報道は、多数のサイトへの影響を伝え、公的サイトと商用サイトの例を挙げた。これは、影響が単一の管理画面や一部の内部利用者に閉じなかったことを示す。

ただし、その例示は完全な監査済み一覧ではない。公式記録は、影響を受けた顧客、サービス、地域、収益の正確な数を公表していない。「数千」という報道上の規模感を、契約単位の顧客数、消失したデータ量、確定した金銭損失へ変換することはできない。

到達不能も、データ喪失と同義ではない。利用者がサービスへ接続できなかった事実は重大だが、基盤上のデータが消えたことを証明しない。説明責任を強くするのは数字を大きくすることではなく、観測された影響と確認できない結果の境界を明示することである。

審査が存在しても、実効的な封じ込めは証明されなかった

OVHcloudによれば、変更はCAB、MOP、ピアレビューを経て準備された。したがって、「誰も見ていなかった」「手順がなかった」と結論づけるのは記録に反する。むしろ難しい問いは、複数の審査を通過した変更が、なぜインターネットの経路表全体をIGPへ流し込める状態を残したのかである。

CABは変更の必要性、影響、時間帯、責任者を確認できる。MOPは実行の順序、確認点、切り戻しを定められる。ピアレビューはコマンドや設計の誤りを探せる。しかし、それらの成果は、危険な状態が実行時に拒否されるか、直ちに検知されるか、狭い範囲に封じ込められるかで評価されるべきだ。

承認の件数は制御の強さではない。レビュー担当者が同じ前提を共有し、装置固有の解釈差を見落とせば、複数承認は一つの誤りを複製する。テストが小さな経路集合だけを使えば、経路表全体が入ったときの資源枯渇を検出できない。切り戻し手順が記載されていても、制御プレーンが飽和した後に実行できなければ、復旧能力としては不十分である。

切り戻しの失敗が物理隔離を必要にした

09時30分までに、ソフトウェア上の切り戻しは成功していなかった。最終的に、現地で対象ルーターを物理的に隔離し、電源を切る必要があった。10時18分の電源断後にネットワークが収束し、10時20分から最初のサービスが戻った。

この順序は、障害時の管理経路と隔離能力について重要な問いを残す。通常の制御経路が、障害を起こしている同じルーティング状態に依存していれば、最も必要なときに遠隔操作を失う。オンサイト対応が最後の安全策になること自体は異常とは限らないが、その所要時間と発動条件は、復旧設計の一部として測られるべきだ。

切り戻しは「逆のコマンドを書くこと」ではない。危険な広告が停止し、隣接装置が安定し、CPUとメモリーが回復し、経路が期待する集合へ戻り、顧客到達性が改善したことまで確認して初めて成立する。制御プレーンが自らを維持できない状態では、論理的な切り戻しより物理的な切断のほうが確実になる場合がある。その選択肢を事前に設計し、権限と連絡先を明確にすることが継続性の条件となる。

記録が確定していないことも、説明責任の一部である

公開情報は、装置ベンダー、ファームウェア、コマンドパーサー、正確な機種を明らかにしていない。判断の所有者も、会社または経営レベルより細かく特定されていない。「ヒューマンエラー」という同日説明は残っているが、詳細記録は個人を名指しせず、コマンド解釈とルーティング状態の結果を示している。

削除された投稿をめぐる報道には、コピー・アンド・ペーストの誤りを示唆するものがあった。しかし、後の公式事故記録はそれを最終的な根本原因として確定していない。魅力的で単純な説明だからという理由で、未確定の説を事実へ昇格させてはならない。

個人の操作ミスだけに焦点を当てると、承認、検証、ガードレール、資源上限、観測、隔離という組織の責任が見えなくなる。人が誤ることを前提にしても、危険な経路再配送がネットワーク全体へ広がらない仕組みを設計できたかが、本件の説明責任を測る中心となる。

運用者が証明すべき変更管理

この事故から求められるのは、一般的な「レビューを増やす」という結論ではない。BGPからIGPへの再配送には、許容するプレフィックス集合、経路数の上限、増加率の警告、明示的な拒否条件が必要である。入力が想定を超えたとき、装置は制御プレーンを守る側へ失敗しなければならない。

変更前には、本番に近い経路規模での検証、装置とソフトウェアの組み合わせに固有のコマンド挙動、IPv4とIPv6の双方の到達性、管理経路の独立性を確認する必要がある。変更中には、OSPFのLSAや経路数、BGP更新、隣接関係、CPU、メモリー、収束時間、サービス到達性を一つの判断画面に結び付けるべきだ。

さらに、停止条件を曖昧にしてはならない。経路数が予測範囲を外れた、CPUやメモリーが閾値を超えた、隣接関係が不安定になった、外部プローブがIPv4到達性を失った、といった条件が出れば、次の手順へ進むのではなく変更を止める。切り戻し不能になった場合の物理隔離、帯域外アクセス、現地要員の権限も、MOPの補足ではなく主要な復旧経路として扱う必要がある。

出典