要約

  • Microsoftの最終事後レビューによると、マドリードのWAN容量追加手順に含まれたコマンドは、二社のルーターでは局所的に働く一方、第三のメーカーの機器ではデフォルトでIGP接続された全ルーターに作用した。変更済み手順は再試験されず、必要な事前・事後確認も欠けていた。
  • 07:08 UTCの最初の手動操作はIGPトポロジーの再計算とBGPプレフィックスの再広告・検証を引き起こした。警報が変更作業者に伝わらず、33分後に二台目でも同じ操作が行われ、第二の影響波が生じた。これは、初期の外部観測で示唆された自動反復ではない。
  • 影響は経路ごとに異なり、大半の機器・地域・サービスは09:05までに、最後のネットワーク機器は09:25までに回復した。しかし、停止していたWAN健全性監視とトラフィックエンジニアリング機能は手動再起動を要し、全面的な緩和は12:43だった。
  • 公開記録は、Microsoftが高影響コマンドの監査・遮断、未認定作業の可視化、訓練、手順審査を計画したことを示す。ただし、それらが完了し有効に機能したことまでは独立に確認していない。

一つの短い障害ではなく、段階の異なる出来事

Microsoftの最終記録は、顧客影響の時間帯を2023年1月25日07:08から12:43 UTCまでとしている。この区間を「約90分の世界的停止」と短くまとめると、ネットワークが何段階で戻ったかを見失う。大半のネットワーク機器、地域、サービスは09:05までに回復し、最後のネットワーク機器は09:25に回復した。それでも、一部経路では通常を上回るパケット損失が続いた。

全面緩和が12:43になったのは、転送が広く戻った後にも、停止状態に入っていたWAN健全性監視とトラフィックエンジニアリングのシステムを手動で再起動する必要があったためである。この順序は、到達可能性の復旧と、到達可能性を測定し経路を制御する仕組みの復旧が同じではないことを示す。

障害の始点はマドリードでの容量追加作業だった。新しいルーターのIPアドレスを変更し、それらをIGPとBGPのルーティング領域へ統合する作業である。IGPは運用者の内部ネットワークでトポロジーと到達性を共有する仕組みで、BGPは組織や経路領域の間で到達可能なプレフィックスを交換する。両者は別の役割を持つが、内部トポロジーが大きく変われば、外部へ示す経路も再評価を迫られる。

ここで重要なのは作業名ではなく、本番機器上でコマンドが実際に持った範囲である。Microsoftによれば、作業手順にはIGPデータベースを消去するコマンドが追加されていた。二社のルーターでは効果がその機器内に限られたが、第三のメーカーのプラットフォームでは、デフォルトの効果がIGPで接続されたすべてのルーターへ及んだ。メーカー名、機種、ソフトウェア版、正確なコマンド文字列は公開されていない。

許可と実行時の意味が食い違った

Microsoftのコマンド認可システムは、第三のプラットフォームで生じる全域的な作用を遮断対象として分類していなかった。つまり、入力が許可されていることと、その実行効果が変更範囲内に収まることが同じものとして扱われていた。マルチベンダー環境では、同じ名前や似た構文が同じ意味を保証しない。安全性を決めるのは文面ではなく、導入済み機器上で動く意味である。

手順側にも不一致があった。事故前に標準作業手順は変更されていたが、再試験されておらず、求められていた事前確認と事後確認を欠いていた。したがって、問題を匿名の技術者一人の判断へ還元することはできない。公開資料はその人物の氏名、意図、能力、画面上の情報を明らかにしていない。一方で、未試験の手順、不完全なコマンド分類、実効範囲を確認できない認可という組織的な条件は明記している。

07:08の操作によってWANルーターはIGPトポロジーを再計算し、その後BGPルーターがインターネットのプレフィックスを再広告して検証した。この動きの間、転送経路は変化し、遅延、タイムアウト、断続的なパケット損失、特定経路での完全な接続喪失が発生した。

これは悪意あるBGPハイジャックや外部攻撃を示す記録ではない。公開された根本原因は、内部のWAN変更に含まれたIGP作用の広いコマンドと、それを限定できなかった手順・認可にある。BGPの変動は、内部状態の変化が外部到達性へ現れた結果である。

第二波は自動反復ではなく、二回目の手動操作だった

最初の操作から33分後、同じ容量追加作業がマドリードの二台目のルーターでも実施された。Microsoftの最終事後レビューは、変更を行った技術者に発生中の警報が通知されていなかったと説明している。したがって、二回目は自動化が勝手に同じ変更を繰り返したという確定事実ではない。最終記録に基づけば、警報と作業を結ぶ停止経路が不完全なまま、二回目の手動操作が行われた。

この区別は責任の置き場所を変える。早い段階の外部分析は、二つの波を観測したうえで自動反復の可能性を論じた。しかし後に出た最終事後レビューが内部の実行順序を具体化した以上、原因説明ではそれを優先しなければならない。外部観測は波の存在を裏付けても、社内の操作主体を単独で確定できない。

警報が監視基盤に表示されるだけでは、継続中の高リスク作業を守る制御にはならない。警報は、残りの手順を止める、次の操作権限を失効させる、再承認を要求する、またはインシデント指揮者へ決定権を移すことで初めて行動を変えられる。公開資料は、これらのうちどの仕組みが存在し、どこまで作動したかを完全には示していない。ただし、最初の検知後にも同じ仕組みをもう一度実行できた事実は示している。

第二波は、単に停止時間を加えたというだけではない。第一波からの収束が進む最中に新たなルーティング状態の変化を投入した。各波がどれだけ追加被害を生んだかは公表資料から定量化できない。しかし、同じ未認定の操作が二度ルーティング領域へ達し、外部の観測者が二つの異なる変動を見たという範囲までは確認できる。

外部のBGP観測が示すもの、示さないもの

ThousandEyesは、Microsoftのプレフィックスが撤回され再広告される動き、直接ピアリングからトランジット事業者へ移る経路、そして大きなパケット損失を観測した。Kentikも、集約トラフィックの二つの低下、地域やプレフィックスによって異なる影響、ピアリングの喪失とトランジットへの移行を報告した。

これらは、利用者から見えたネットワーク効果を独立に記録する重要な証拠である。特に、二つの波と経路ごとの不均一性はMicrosoftの時間軸と整合する。ただし、外部のBGP更新やフロー観測だけでは、非公開のルーター上でどのコマンドが入力されたかは分からない。Kentikも、公衆BGPの不安定性は内部障害の症状であって、根本原因そのものではない可能性を明示している。

このため、証拠の層を混ぜてはならない。Microsoftの最終事後レビューは内部機構、作業手順、回復時刻の主要な根拠である。ThousandEyesとKentikは外部に現れた経路・トラフィックの変化を示す。同時期の技術報道は顧客が目にしたサービス障害と初期の説明を記録する。それぞれが補い合う一方、一つの層を別の層の代用にはできない。

影響は広域だったが、一様ではなかった

影響対象には、インターネットからAzureへの通信、Azureのリージョン間通信、ExpressRoute、VPN、Virtual WANを利用するオンプレミスとの接続が含まれた。Microsoft 365とPower Platformの依存機能、ならびにパブリックAzureに依存するAzure Governmentのサービスも影響を受けた。

ただし、すべての顧客、サービス、リージョン、インターネット経路が同じように停止したと述べる根拠はない。体験は送信元と宛先によって動的に異なり、遅延や断続的損失で済む経路もあれば、タイムアウトや完全な接続喪失となる経路もあった。インドと北米の一部は回復が長引いた場所に含まれるが、完全な地域別一覧は公開されていない。

公表資料は、影響を受けた顧客数、利用者数、全サービス数、全プレフィックス数、取引数、監査済みの金銭損失を確定していない。顧客データの消失や物理機器の損傷も立証していない。影響を重大に評価するために、存在しない数字や法的判断を補う必要はない。

経路別のばらつきは、復旧判定にも関係する。ネットワーク全体の大きな割合が正常でも、特定の送信元・宛先の組み合わせに損失が残り得る。集約的な可用性指標だけで閉鎖を宣言すれば、利用者が経験する残存障害を隠してしまう。

復旧は収束、機器、支援システムの順に進んだ

監視は07:11までにDNSとWANの症状を検知して警報を出した。DNSは検知された症状の一つであり、この出来事を一般的なDNS障害と呼ぶのは正確ではない。最終的な原因説明の中心は、WAN内のIGP再計算と、それに続くBGP再広告および転送の不安定化にある。

担当者は直近の変更を調べ、08:20までに問題のコマンドを特定した。その間もルーティングの自動収束は進んでいた。09:05までに大半の機器・地域・サービスが回復し、09:25に最後のネットワーク機器が回復した。その後も局所的なパケット損失が残り、停止していたWAN健全性監視とトラフィックエンジニアリング機能を手動で再起動して、12:43に全面緩和となった。

障害発生中の初期説明には、ルーティング変更の撤回に関する記述もあった。それは当時の対応を知るうえで有用だが、復旧全体を単一のロールバックだけに帰属させることはできない。最終事後レビューは、自動収束、最後の機器の回復、支援システムの手動再起動を区別している。

復旧の証明もこの層構造に合わせる必要がある。第一に広い到達性、第二に残る機器と経路、第三に不健全な経路を見つけてトラフィックを誘導する支援機能である。本件の資料は当時の順序を説明するが、Microsoftがその後どのような復旧基準を採用し、それが有効だったかまでは証明しない。

責任は個人ではなく、変更システムに問われる

公開記録から支持できる結論は限定的だが明確である。変更され再試験されていない手順に、メーカーごとに作用範囲の異なるコマンドが含まれていた。認可システムは第三のプラットフォーム上の広域作用を遮断しなかった。実行によりIGPとBGPの状態が変化し、顧客経路へ不均一な障害が現れた。さらに、警報が作業者へ届かないまま同じ手動操作が二度目に実施された。

Microsoftは、ベンダーと役割をまたぐ高影響コマンドの監査と遮断、承認済み・未認定の機器操作を当番対応者へ見せる仕組み、運用訓練と証明、未処理手順の変更諮問審査などを挙げた。これらは事故で露呈した弱点に対応する方向を持つ。しかし、公開された四つの情報源は、各項目が後に完了したことや、同種の操作を実際に防いだことを独立に確認していない。

したがって、改善項目は約束として記述すべきであり、実証済みの成果としては扱えない。有効性を示すには、プラットフォーム別のコマンド作用試験、手順変更時の再認定、意図した機器・隣接・経路領域と実際の変化の比較、停止命令が二回目の実行を防いだ記録、そして転送機能と支援システムの双方についての回復証拠が必要になる。

本件は、法的な過失、契約違反、補償義務を確定するものではない。内部ログもすべての意思決定者も公開されていない。それでも、ルーティング基盤についての責任上の問いは残る。高影響の変更が安全であると言えるのは、許可されたからではなく、実行時の範囲が機種ごとに限定され、観測でき、逸脱時に中断でき、支援機能を含めて回復できると証明された場合である。

情報源