要約

  • IBMが保存した告知は、外部ネットワーク事業者から大量の不正確な経路情報が流れ込み、深刻な輻輳、つまり通信処理が需要に追いつかず通りにくくなる状態が生じたと説明した。ネットワークプレフィックスとは複数のIPアドレスをまとめた宛先範囲であり、その情報が乱れると到達性、すなわち通信先へ実際に届くかどうかが広く損なわれ得る。
  • 障害時には、管理プレーン、つまり運用者が監視・設定・復旧を行う管理機能の層と、帯域外アクセス・状態通知、つまり本番の通信経路から独立して操作や告知を続ける手段が重要になる。公開情報は障害の波及範囲、つまり一つの不具合が及ぶサービスや利用者の広がりを示すが、IBMの内部構成や判断手順までは示していない。
  • 問うべきなのは単純な責任転嫁ではなく、制御権限の所在、つまり各組織がどの設定、監視、遮断、復旧を自ら決められるかである。テレメトリーとは機器やサービスが出す観測データであり、境界の両側がそのデータを突き合わせられなければ、原因説明も再発防止の検証も弱くなる。

公開記録が示す出来事

TechCrunchの当時の報道によると、2020年6月9日の太平洋時間14時30分ごろから、IBM Cloudのネットワーク障害が広く観測された。ホストされていた複数のサービスが影響を受け、IBMの主要な状態情報ページ自体も内部サーバーエラーを返したと報じられている。

この時刻は、すべての地域、顧客、製品で同時に障害が始まったことを意味しない。公開資料には、世界全体を一つの時計で測った開始時刻や復旧時刻はない。利用者ごとの症状、地域差、復旧の順序を一つの継続時間へ縮めると、記録が持つ限界を越えてしまう。

The RegisterとCRNに残るIBMの説明では、外部ネットワーク事業者が大量の不正確な経路情報をIBM Cloudへ送り、それが深刻な輻輳を起こし、クラウドサービスとデータセンターに影響したとされる。これはIBMによる帰属説明であり、公開されたルーター設定やパケット記録を第三者が検証した結論ではない。

IBMは、サービスが復旧し、軽減策を講じ、原因調査ではデータ損失やサイバーセキュリティ上の問題を特定しなかったとも述べた。ただし、この否定的な説明はIBMの調査範囲に属する。すべての顧客環境を個別に監査した結果と読み替えることはできない。

BGPで何が問題になり得るのか

インターネットでは、一つのネットワークが隣接するネットワークへ経路広告を送り、どのネットワークプレフィックスへ到達できるかを伝える。受信側は複数の情報をルーティングポリシー、つまりどの経路を受け入れ、選び、外へ知らせるかを決める規則に照らして処理する。

不正確な経路情報が大量に届くと、受信側の装置や経路計算に負荷がかかるだけでなく、実際の通信が誤った宛先へ向かう可能性がある。Zelloは事後報告で、多数の経路が注入された結果、IBM Cloud上のサーバーから出るIPv4通信が誤った宛先へ送られたと説明した。IPv4は、32ビットのアドレスで通信先を識別する、現在も広く使われるインターネットプロトコルである。

経路が更新された後、各ネットワークが新しい情報を受け取り、選択を更新し、安定した状態へ落ち着く過程を経路収束という。経路収束は瞬時ではない。ある場所で通信が戻っても、別の場所では古い情報や別経路が残ることがあり、段階的な復旧として見える。

ただし、公開記録は、どの自律システム、つまり一つの運用主体が管理するネットワークのまとまりが発信元だったかを示していない。具体的なプレフィックス、経路選択に使う付加情報である経路属性、機器間で経路情報を交換する接続単位であるセッション、設定コードも不明である。「大量」という表現から、インターネット全体の完全な経路表や特定の設定値を推定することもできない。

顧客側の観測が補うもの

Zelloの状態記録は、利用者側で見えた症状を具体化する。ログインや再接続が広く失敗し、すでに接続していた利用者も通信を失い、管理コンソールが使えなくなり、四つのサービスが影響を受けたと記録している。

この情報はIBMの説明をそのまま繰り返すものではない。クラウド上のアプリケーションから見た到達性と、運用担当者が使う管理手段が同時に損なわれ得ることを示している。状態ページまで利用できなければ、利用者は障害そのものだけでなく、何が起きているかを知る手段も失う。

一方で、Zelloの記録はIBM Cloud全顧客の完全な影響数ではない。失敗した取引、失われた売上、影響地域、損害額を全体へ外挿する根拠にもならない。顧客の一次観測は重要だが、その射程を限定して読む必要がある。

CRNは、環境、コンソール、状態画面へのアクセスが失われたという報告と、復旧中にIBMのネットワーク運用部門がルーティングポリシーを調整したという説明を伝えた。これも、復旧が単一のスイッチ操作ではなく、経路選択を段階的に整える作業だった可能性を示す。ただし、変更内容の詳細は公開されていない。

事業者境界を責任の空白にしない

外部ネットワーク事業者が不正確な情報を送ったという説明が正しくても、クラウド事業者側の責任が消えるわけではない。IBMが直接管理できるのは、受信する経路の条件、異常な増加を検知する警報、経路を隔離する判断、顧客への状態通知、管理手段の独立性、復旧の手順、そして後から説明できる観測記録である。

外部事業者側には、外へ知らせる経路の妥当性確認、誤った情報の速やかな撤回、境界を越える異常の通知がある。どちらが契約上どこまで担っていたかは公開資料から分からない。それでも、技術的にどちらが操作できたかを分けて考えることで、「外部に原因があった」という一文が説明の終点になるのを防げる。

制御権限の所在を明らかにするには、主体、行為、対象を分ける必要がある。誰が、どの設定を、どの観測に基づいて変更できたのか。誰が、異常な経路を拒否し、誰が顧客向けの状態情報を維持できたのか。契約名ではなく、実際に動く設定と操作権限を中心に据えるべきだ。

最大プレフィックス制限とは、隣接する相手から受け入れる経路数に上限を設け、想定を超える増加を検知または遮断する仕組みである。RFC 7454は、境界での受信・送信プレフィックスの絞り込みや、相手ごとの最大プレフィックス制限を運用上の指針として説明している。

しかし、その文書は2020年当時のIBMや外部事業者の設定を示す証拠ではない。上限が実装されていたか、値が適切だったか、超過時に警告だけだったか接続を止めたかは不明である。一般的な推奨事項を、特定事故の構成や予防保証へ置き換えてはならない。

障害時の観測と管理経路

本番通信と同じ障害に管理プレーンまで巻き込まれると、運用者は状況を確認し、設定を変え、利用者へ知らせる能力を同時に失う。帯域外アクセスと状態通知は、そうした共通障害を避けるため、本番の経路とは独立して操作と告知を続ける設計を指す。

この独立性は、単に別の画面を用意することではない。認証、サービス名を接続先のアドレスへ対応づける名前解決、ネットワーク接続、状態情報の配信が同じ失敗要因を共有していれば、見かけ上別でも同時に止まる。どの依存関係を分離できていたかは公開情報にないため、IBMの実際の構成を断定することはできない。

テレメトリーには、受信経路数の変化、経路更新の速度、機器負荷、到達性の変化、顧客側の失敗などが含まれ得る。重要なのは、数字を集めるだけでなく、異常が事業者境界のどちら側で始まり、どの制御が働き、どの時点で回復したかを後から関連づけられることである。

障害の波及範囲は、影響した製品名や地域数だけでは測れない。管理コンソールや状態通知が同時に使えない場合、復旧作業と顧客判断の遅れが影響を広げる。逆に、一部の経路や顧客が先に戻る段階的復旧を、全体復旧と誤認しない計測も必要になる。

攻撃と断定しない理由

大量の経路情報という表現は、意図的な攻撃を意味しない。分散型サービス妨害（DDoS）は、多数の送信元から意図的に通信や処理能力を圧迫する攻撃であるが、公開された記録は、この障害がDDoS、悪意ある経路操作、妨害行為、またはサイバー侵害だったとは示していない。

IBMは原因調査でサイバーセキュリティ上の問題を特定しなかったと説明している。これも「何も起き得なかった」という普遍的な証明ではなく、IBMがこの事故について公表した範囲の否定的な結論である。攻撃の物語を加えるより、確認された経路情報の異常と運用上の制御へ焦点を置く方が、説明責任に近づく。

復旧と軽減策の読み方

IBMはサービスの復旧と軽減策を報告し、CRNはネットワーク運用部門によるルーティングポリシーの調整を伝えた。これらは当時の対応を示すが、現在も同じ仕組みが有効であることや、同種障害が再発しないことを保証しない。

復旧の評価には、どの経路をいつ変更したか、顧客ごとの到達性がどう戻ったか、管理機能と状態通知がいつ利用可能になったかを分けて記録する必要がある。公開資料にはその全体がない。したがって、単一の復旧時刻や全顧客共通の継続時間を作るべきではない。

再発防止を評価するなら、軽減策の実装範囲、独立した検証、平常時からの監視、境界の相手と行う試験、現在の有効性が必要になる。これらは公開されていない。報告された措置を尊重しつつ、確認されていない将来の耐性まで主張しないことが重要だ。

なお分からないこと

外部ネットワーク事業者の名称、経路を発信した自律システム、具体的なプレフィックス、経路属性、セッション、設定コードは公開記録から特定できない。推測で企業名や技術構成を埋めると、検証可能な説明から離れてしまう。

IBMと外部事業者の契約主体や、受け入れる経路を条件で絞り込むフィルタリング、警報、撤回、顧客通知の責任配分も不明である。技術的に操作できる範囲と、契約上義務づけられた範囲は同じとは限らない。

完全な顧客数、地域別影響、失敗した取引、損失額、すべての復旧時刻も示されていない。IBM内部のネットワーク構成、警報、意思決定者、管理プレーンの設計も非公開である。

また、報告された軽減策がどこまで実装され、独立に検証され、現在も有効かは分からない。公開資料は、過失、規制違反、サービス水準契約の違反、損害賠償、犯罪、個人責任を確定していない。

説明責任を測るための問い

第一に、境界の両側で、どの経路を受け入れ、どの条件で拒否するかが明文化され、実際の設定と一致していたか。方針書があっても、稼働中の設定が違えば通信は設定どおりに動く。

第二に、異常な経路数や到達性の低下を、顧客からの通報より前に検知できたか。警報が鳴っただけでなく、誰が判断し、何を止め、どの影響を確認したかまで追える必要がある。

第三に、本番経路が混乱しても、管理操作と状態通知を続けられたか。利用者が管理コンソールと状態ページを同時に失うなら、障害の技術的範囲を越えて、復旧判断の遅れと情報不足が広がる。

第四に、IBMと外部事業者が同じ事象を共通の時系列で再構成できたか。境界の両側に観測記録があっても、時刻、対象、経路の識別が結びつかなければ、責任分担は曖昧なまま残る。

第五に、軽減策を「実施した」と言うだけでなく、想定外の経路増加、段階的な復旧、管理経路の喪失を含む試験で確かめたか。公開情報からその答えは分からないため、現在の耐性を断定せず、検証方法の開示を求めるのが妥当である。

画像の公開文案

代替テキスト： 落ち着いた運用室で、ルーティング装置と光ファイバーの接続盤によるクラウドネットワークの境界接続を示す、概念的でブランド表示のない画像。

キャプション： 概念的な編集用画像であり、IBM、名称が公表されていない外部事業者、実在の施設、2020年の障害そのもの、検証済みのネットワーク構成や経路の証拠を描いたものではない。

出典