Telstra障害：ネットワークが2006年と判断した夜

Telstra障害：ネットワークが2006年と判断した夜

実際にはその逆です。もし私たちが「今」という共通の理解を持てなければ、当然のことと考えている多くのことが機能しなくなります。

この夏、オーストラリアはこのことを痛感しました。現代社会にとって時間がなぜ重要なのか、この特定のケースで何が起こったのか、そして私たちが得られる主な教訓について例を挙げて説明する機会とさせてください。

2026年7月8日、オーストラリア最大の携帯電話事業者であるTelstraが運営するモバイルネットワークの大部分で、音声通話がつながらず、テキストメッセージが届かないといった障害が発生しました。オーストラリアの緊急通報番号への通話さえもつながらない状況でした。しかし、この障害は列車、決済端末、チケットシステム、EV充電器など、さらに広範囲のシステムにも影響を及ぼしました。

ネットワークへの攻撃はありませんでした。誰かが誤って光ファイバーを切断したわけでもありません。すべてのシステムには電力がありました。原因は何か、とあなたは尋ねるかもしれません。それは、メルボルンにあった単一のシャーシ内の単一のGPS受信機が、定期メンテナンスから復帰した際に年を2006年と誤認し、ネットワーク全体をその誤りを信じ込ませたことでした。

Telstraは、テクノロジー・監査パートナー（TAP）社による独立したレビューを委託しました。このレポートは非常に興味深い読み物です。なぜなら、同じ種類の障害が、人々を生きながらえさせるために依存しているシステムを含む、多くのクリティカルなサービスで発生する可能性があるからです。

これらのシステムの多くが機能するためには、時間が正確であること、少なくともどこでも同じであることが不可欠です。そして、この分野の誰もが知っているように、「正確」は相対的な用語です。絶対的な時間というものは存在せず、基準からの特定の誤差範囲内で保持される時間しかありません。その誤差範囲がどれだけ広いかは、何を行っているか、あるいはどのようなビジネスを行っているかに完全に依存します。

Telstraのようなモバイルネットワークの運用は、ビジネスの中で最も時間に依存するものの一つです。

現代のモバイル通信が時間の重要性を説明する

現代の携帯電話プロトコルは、高精度な時間同期なしには機能しません。モバイルネットワークは、FDD（周波数分割複信）またはTDD（時分割複信）のいずれかを使用して、アップリンクデータとダウンリンクデータを分離します。

FDDは、各方向が独自のスペクトル帯域幅を持つため、衝突することなく両方が連続して実行できます。

TDDは、代わりに単一のスペクトルブロック全体を両方向に使用し、非常に短い間隔で送信と受信を交互に行います。

通常、ダウンリンクのデータ量の方がアップリンクよりも多いため、FDDの固定比率ではアップリンクスペクトル帯域幅の多くがアイドル状態になりますが、TDDは実際のトラフィックに合わせて比率をシフトできます。そのため、ほとんどの最新の5Gスペクトル、スウェーデンの主要な5G帯域である3.5GHzを含む、TDDが使用されています。

そして、これがTDDが正確な時間に依存する理由でもあります。同じ周波数を使用する各セルは、他のすべてのセルと同期して方向を切り替える必要があります。クロックがドリフトするセルは、隣接するセルの受信ウィンドウにデータを送信し、その結果、ネットワークは自己妨害を起こし始めます。

業界は、両方向を分離するためにスペクトルを割り当てるのではなく、時間の精度に依存することを選択し、すべてのセルが「今」がいつであるかについて合意することへのハード依存性を受け入れました。したがって、時間に依存することは設計上の選択です。

しかし、システムが「今」について合意できる能力に私たちがどれほど依存しているかを考えると、時間がそれに値するほど考慮されていないのは、ある程度不可解です。そして、それは公開されたレポートから非常に明確な教訓です。

では、実際に何が起こったのでしょうか？

時間配信のアーキテクチャ

まず、時間配信のアーキテクチャを理解することが不可欠です。

時間配信プロトコルはすべて階層を構築します。Telstraがレポートによると展開していたネットワークタイムプロトコル（NTP）は、その階層をストラタム（stratum）で表現します。

• ストラタム0は、GPS受信機やNetnodの原子時計などの基準自体です。
• ストラタム1は、Netnodが提供するNTPサーバーなど、ストラタム0の基準に直接同期されたマシンです。
• ストラタム2はストラタム1サーバーから同期し、ストラタム3はストラタム2から同期します。

Telstraの場合、その階層は、少なくとも当初は特定の形状をしていました。この2010年の設計では、国の国家時間スケールを維持しているオーストラリア国立測定研究所（NMI）（スウェーデンのスウェーデン研究所（RI）と同様）が最上位のストラタム1ソースでした。Telstraは、それらの外部参照から、それぞれシドニーとメルボルンにある独自の2つのストラタム2サーバーに時間を取り込み、それがさらにシドニー、メルボルン、パースにある3つのストラタム3サーバーに供給されていました。

それらの下にはクライアントが配置されていました。この文脈でのクライアントとは、ラップトップや電話のことではなく、セルサイト間のハンドオーバーを処理するノードなど、モバイルネットワークインフラストラクチャ全体を指します。広大な地理的範囲に何千ものノードがあり、それらすべてが「今」がいつであるかについて、数百万分の1秒以内の同じ認識を持つ必要がありました。

TAPレポートは、このセットアップを「目的に合致している」と記述しており、Telstraに「NMIから非常に信頼性の高い権威ある基準時間ソース」を提供したとしています。

ストラタム自体は、時間が正確かどうかを示すものではなく、サーバーから基準までのステップ数を示すだけです。悪い時間基準を持つストラタム1サーバーは、依然としてストラタム1サーバーです。

悪い時間ソースからの保護

したがって、NTPは悪い時間ソースに対する防御を必要とします。実際には2つの異なる防御策があり、それぞれが異なることを行い、両方とも互いに独立していることを前提としています。

1. 他の同等な候補の中で、より低いストラタムがより大きな重みを持つ。これは、クライアントがどのソースを選択するかを決定するメカニズムです。
2. NTPは複数のソースを比較し、他のソースと一致しないものを破棄します。ありえない時間を主張する単一のソースは、それがどれほど権威を主張していても、多数決によって除外され、ドロップされます。

これらの防御策のいずれも特定の障害に特化したものではありません。これらは連携して、破損した受信機、設定ミスのあるサーバー、または外部攻撃から保護します。しかし、これらの保護措置は、クライアントが監視している時間ソースが互いに真に独立している場合にのみ機能します。

NTPの2つの展開方法

NTPは2つの方法で展開できます。クライアント/サーバーモードでは、関係は宣言され、一方向です。ノードはサーバーから時間を受け取りますが、それ以外は何も行いません。

2010年のTelstraのセットアップは、実際にはこのクライアント/サーバーモデルでした。ピアリングは許可されていましたが、同じストラタムレベルでのみ許可されていました。そして、冒頭で述べたように、TAPレポートはこのセットアップを「目的に合致している」と記述しました。

もう一つの方法は、ノードが相互に時間を交換し、アルゴリズムが現在好むソースに落ち着く対称（ピアリング）モードです。

ピアリングは柔軟性があり、ソースの喪失を円滑に乗り越えます。しかし、それはまた、本番環境でのトポロジーが設計されたものではなく、創発的なものであることを意味します。あなたが文書化したセットアップは、誰も承認しなかった形状に静かに再編成される可能性がありました。

Telstraの2020年のアップグレード

2020年にモバイルコアタイミングシステムがアップグレードされ、新しいNTPタイミングシャーシを含む新しいハードウェアが設置されました。その設置により、いくつかの変更が導入されました。

最初の変更は強制されたものでした。新しいシャーシは、同じボックス内でストラタム2サーバーがストラタム3サーバーに供給することを許可しなかったため、2つは相互に配線する必要がありました。シドニーのストラタム3はメルボルンのストラタム2から、メルボルンのストラタム3はシドニーのストラタム2から時間を受け取るようになりました。

実際には、各サイトは2つのストラタム2ソースを持つ代わりに、それぞれ1つしか持たなくなりました。TAPレポートは、この冗長性の低下が認識され、受け入れられたと指摘しています。2番目の変更は、クライアント/サーバーモデルからピアリングモデルへの移行でした。レポートは動機について明確ではありませんが、この冗長性の喪失を補うために望んだと推測するのは合理的です。各サイトが2つではなく1つのソースしか持たなくなったため、サーバーが自身の代替を見つけることを許可することで、より良い回復力があるという印象を与えることができたかもしれません。

TAPレポートは、回復力の喪失が認識されていたことを明確に述べています。しかし、結果として生じる「タイミングループ」のリスクが特定されたという証拠は見つかっていません。

タイミングループとは何か？

タイミングループは、ネットワークにおける「3人が互いに聞いた噂を真実だと信じる」状況に相当します。それぞれが同意するので、それは真実でなければなりません。NTPは基本的に同じように機能します。複数のソースを比較し、他のソースと一致しないものを破棄します。

前述したように、NTPには悪い時間ソースに対する2つの防御策があります。2番目の防御策は、ソースが互いに独立している場合にのみ、タイミングループから保護します。そのようなループでは、独立しているように見えるソースは、実際には共有された基準をたどって、直接的または間接的に互いに時間を取得しています。

誤った値が循環し始めると、ソースは互いに同意し始め、多数派の意見を支持する多数決が行われます。たとえその値が間違っていてもです。

プロトコルは機能した。アーキテクチャは機能しなかった。

NTPの2つの防御策は、メルボルンで無効化されましたが、5年間の間隔を置いていました。意図的ではなく、それぞれの選択はそれ自体で正当化できるものでした。ハードウェアの制限に対処する必要があり、その後、繰り返し発生する障害を停止する必要がありました。各決定は、目の前の問題を解決しました。誰も、すべての行動の合計を見るように求められませんでした。

2番目の防御策が最初に無効化されました。2020年のピアリングの導入によりタイミングループが可能になり、5年後、そのようなループが出現しました。メルボルンでは、サーバーが自身の階層の下位にあるノードから時間を取り始めました。それは警報を発するべきでした。しかし、正確な時間が他の経路でネットワークに到達していたため、実際には損害はありませんでした。根本的な問題である循環的な依存関係は存在していましたが、誰もそれについてチケットを発行しませんでした。

実際の問題は非常に明白でした。メルボルンは、シドニーにある唯一のストラタム2ソースとの連絡を失い続けていました。フォールバック構成がないため、サーバーはピアリングを使用して代替を見つけました。時には、階層の下位にあるノードを使用することもありました。

2025年10月、エンジニアは2020年からメルボルンシャーシ内に未使用のままだったGPS受信機を起動し、信頼性の低いシドニーソースの代替として、ストラタム3サーバーに接続しました。

見た目上はすべてうまくいったように見えました。メルボルンは独自の信頼できるソースを持ち、アラームは停止しました。しかし、この修正は根本原因ではなく、症状に対処したにすぎませんでした。メルボルンがシドニーソースとの接続を失い続けた理由を誰も確立しませんでした。根本的な問題は、2026年7月になってもネットワーク内に存在していました。

さらに悪いことに、誰もGPSカードを起動したことがアーキテクチャに何をもたらしたかを理解していなかったようです。GPSカードを追加したことで、メルボルンサーバーはストラタム3サーバーからストラタム1に昇格しました。エンジニアは他のソースの隣にソースを追加したわけではありません。サーバーを国家基準と同じランクに昇格させることで、階層の最上位に新しいソースが作成されました。NTPに関しては、それらは同じ重みを持つと見なされます。

突然、このメルボルンシャーシ内のGPSカードは、回避策としてインストールされ、誰もレビューしていなかったにもかかわらず、オーストラリア最大のモバイルネットワークにとって階層内で最も権威あるサーバーになりました。

言うまでもなく、2010年の設計のほとんど何も残っていませんでした。

2026年7月までに、ネットワークは最も権威ある候補であり、かつ反対意見がない単一のソースを持っていました。なぜなら、それに矛盾する可能性のあるソースはすべて、その下流にあったからです。

この動作は非常に見つけにくいものでした。ネットワークは長年、毎日正確な時間を供給していました。このようなアーキテクチャは通常、徐々に劣化することはありません。機能し、機能し続け、そして突然停止します。

GPS週番号ロールオーバー

2番目の要素は、GPSのよく知られた特性です。

GPSは、1980年初頭に始まったエポックからカウントされる週番号と週内の秒数として時間をブロードキャストします。主要な民生用GPS信号では、週番号フィールドは10ビット、つまり最大1,023週です。1,024週ごと、つまり19.6年ごとに、カウンターはリセットされます。これは1999年8月と2019年4月に2回発生しました。

どのエポック番号であるかを計算し、1,024週の適切な倍数を加えるのは受信機の仕事です。そして、その情報はファームウェアに含まれている必要があります。

オーストラリアで発生した問題は、これらのGPSロールオーバーのいずれかの遅延した結果ではありませんでした。メルボルンのカードは、2019年の2回目のロールオーバーを問題なく通過しました。なぜなら、稼働し続ける受信機はカウントを続行するからです。新しい週は前の週に追加されるだけで、どのエポックに属するかという問題は決して提起されません。

しかし、一度電源を切ると、その知識は失われます。再度電源を入れると、受信機は最初からエポックを計算し直す必要があり、そのすべてはファームウェアが想定するものに依存します。メルボルンカードのファームウェアは更新されていませんでした。起動時に、それは以前のエポックに戻り、日付を1,024週過去に設定しました。

次に起こったことは、最も必要とされているときに2つの防御策が無効化されたと理解するのが最善です。

最初の防御策である、より低いストラタムがより大きな重みを持つという点は、メルボルンサーバーがストラタム1サーバーに昇格したため、最も高いランク付けをしました。これはNTPプロトコルに従っており、クライアントを1,024週間違った単一ソースに誘導しました。

2番目の防御策である、外れ値が却下されるという点は、メルボルンを外れ値として特定できるものが何も残っていなかったため、決して起動しませんでした。NTPは日付が妥当かどうかを尋ねるのではなく、ソースが他のソースと一致しないかどうかを尋ねます。2010年のセットアップには2つのストラタム2サーバーがありました。それらのうちの1つが2006年の年を発表し始めた場合、もう1つは2026年のままで、コンセンサスは達成されなかったでしょう。それは理想的ではなかったでしょうが、少なくとも間違った日付が広がることはなかったでしょう。

しかし、メルボルンのストラタム2の対抗サーバーは、同じシャーシ交換によってシャットダウンされており、残りのソースはメルボルンの下流にありました。間違った日付が広がるにつれて、それらはそれを報告し始めました。合意は成長し、合意はアルゴリズムが探しているものです。

そのため、クライアントは構築されたとおりに動作しました。クライアントのソースの過半数が2006年11月に合意すると、クライアントはその日付を受け入れ、日付が広がるほど、それはより説得力のあるものになりました。

どちらの防御策も誤動作しませんでした。どちらも、依存していたものを単に奪われていただけでした。一方は最も高いランク付けに値するソースを必要とし、もう一方は矛盾できるソースを必要としていました。5年離れた2つの決定が、それぞれを順番に取り除きました。

インシデントからの主な教訓

時間と周波数の配信をクリティカルインフラストラクチャとして優先し、分類する。それに応じて管理する

ネットワーク全体を停止させる可能性のあるすべての機能を文書化し、タイミングをそのリストに含めてください。分類は書類作成ではありません。それは、変更リスクカテゴリ、レビューの深さ、人員レベル、監視範囲、予算の優先順位を決定するものです。Telstraのレポートは、根本的には、そのリストから1つのエントリが欠落していたこと、そしてそれに続くすべてについての物語です。

インフラストラクチャ全体と、それに対するすべての変更を文書化する

NTP構成の中央リポジトリ、ゴールデン構成、またはデバイス自体以外のサーバーの文書化された記録はありませんでした。記録がなければ、意味のある事前チェックを実行できず、影響を評価できず、インシデント中に「正しい」がどのように見えるかを知ることができません。

能力における冗長性を構築する

2人のエンジニアが変更を実施しましたが、GPSカードの再起動の結果が理解される前に、両方とも義務的なスタンドダウンに入りました。専門知識の深さは、冗長な電源供給と同様の回復力プロパティです。単一の専門家、またはペアは、セカンドオピニオンがなく、通常メンテナンスが行われる深夜に尋ねる人もいないことを意味します。

時間と周波数のインフラストラクチャのセキュリティ分析を実行する

タイミングを他の攻撃対象と同様に扱い、それに応じて分析してください。組織に時間が入ってくる場所から始めてください。宇宙から到着するGNSS信号は弱く、認証されておらず、安価な機器によって妨害またはスプーフィングされる可能性があります。その信号が唯一の基準である場合、あなたの建物の外にいる誰かがあなたが何時だと考えているかを決定できます。

次に、それがどのように伝わるかを見てください。共有ネットワーク上で配信される時間は、クライアントへの途中で傍受および操作される可能性があります。

次に、誰が話すことが許可されているかを見てください。クライアントはどのサーバーから時間を受け入れることができますか？そして、それを誰が決定しましたか？許可されていないソースは、誰もチェックしていないソースです。

そして、意図的な攻撃で止まらないでください。タイミングループは、成功したスプーフィング攻撃とほぼ同じ効果を生み出します。ネットワークが信頼するソースが、誰も矛盾できない値を配信します。

ポイントツーポイント接続を使用する

ピアリングの魅力は容易に理解できます。ソースが互いにバックアップし、ノードが消えても自己修復するネットワークのように、回復力があるように感じられます。しかし、自己組織化する冗長性は、信頼できる冗長性ではありません。より安全な方法で同様のレベルの堅牢性を達成できます。Netnodは専用のポイントツーポイント接続を実行しています。すべての関係は知られており、文書化されています。すべてのソースは知られており、トポロジーは設計どおりに維持されます。冗長性は、ノードが互いに交渉するのではなく、意図的に構成された複数の独立したソースから来ます。

効果的なアラーム組織を構築する

タイミングプラットフォームからのアラームは標準的な監視ツールにはなく、営業時間中に少数の人々によってのみレビューされていました。クライアント側のアラームは、即時のアクションを促すほどの重大性も詳細も持っていませんでした。これを正しく行うことは、技術的な問題であると同時に組織的な問題でもあります。アラームは24x7監視に到達し、重大度は実際の結果を反映し、各アラームには対処方法の説明が含まれ、誰かが応答を所有します。オンコール担当者がいないアラームは、せいぜい文書であり、検出ではありません。

ゴールデンインストールを使用する

すべての種類のタイミングデバイスについて、バージョン管理された既知の良い基準ビルドと構成を保持し、展開されているものがそれに一致するかどうかを定期的に自動的にチェックしてください。ポイントは、「このシャーシは正しく構成され、パッチが適用されていますか？」という質問を、専門家だけが遅くとも答えられるものから、誰でも数秒で実行できる比較に変えることです。Telstraにはそのようなものはありませんでした。TAPレポートは、そのような構成や、サーバー自体以外のサーバーがどのようになるべきかの記録を見つけられませんでした。メルボルンGPSカードの欠落していたファームウェアアップデートは6年間そこにあり、公然の秘密でした。それを誰かにフラグを立てる自動化されたプロセスはまったくありませんでした。

ソフトウェアを継続的にアップグレードおよび評価する

ロールオーバー動作のファームウェア修正は存在し、ベンダーはそれに関する通知を発行していました。ベンダー通知には、定義された所有者とアクションへの追跡パスが必要であり、アップデートは、何かが問題を強制したときではなく、スケジュールで適用する必要があります。展開前に、実際に依存している動作に対してラボで評価してください。その後、検証することを忘れないでください。Telstraの変更は、シャーシが正しい日付を供給していることを誰も確認せずに完了しました。

冗長性

タイミングにおける冗長性とは、複数のソースだけでなく、共通のエラーに収束できない独立したソースを意味します。同じGNSS受信機から供給される2つのサーバーは、依然として1つのソースですが、2回カウントされます。Netnod自身のサービスは、独立した原子時計と、スウェーデン国立時間実現UTC（SP）に追跡可能な冗長サーバーを持つ、複数の自律ノードの原則に基づいて構築されています。

機器を継続的に交換する

タイミングインフラストラクチャは通常、静かに古くなります。それは機能し続け、めったに文句を言わないため、予算が削減された場合に自然な候補となります。失敗の結果がより目に見える他のコンポーネントは常に存在するため、それらが優先されます。代わりに、ローリングサイクルで交換を計画し、新しいハードウェアインストールがあなたに課すものを許容するのではなく、ターゲットアーキテクチャを最初に設計してください。既存のインフラストラクチャを健全に保つことは、新しいプロジェクトと並行して資金提供されるべきであり、残りで支払われるべきではありません。

結論

Telstraが事後処理をどのように扱ったかは称賛に値します。独立したレビューを委託し、公開したことは称賛に値します。Netnodを含むすべてのクリティカルサービスのプロバイダーは、これのおかげでより良くなりました。

最も落ち着かない部分は、おそらくNTPが意図したとおりに機能していたにもかかわらず、障害が発生したことでしょう。

問題は、その周りのすべてでした。アーキテクチャの選択、予算削減、人員不足、適切な監視、所有権、または文書化の欠如。すべては、誰も時間サービスがどれほど重要であるかを本当に理解していなかったために起こりました。

それを変えようではありませんか、どうでしょう？