要約
- 韓国科学技術情報通信部によれば、KTの通信障害は2021年10月25日の午前11時16分ごろに始まり、復旧措置は午後0時45分ごろに完了した。政府が示した時間幅は約89分である。[1]
- KTは当初DDoSの可能性を示したが、政府の合同調査は攻撃説を退け、釜山での企業向けルーター交換作業中に生じたルーティング設定エラーを原因とした。本件を攻撃や悪意あるBGPハイジャックと呼ぶべきではない。[1][2]
- 政府調査によると、IS-IS設定コンテキストを終了させるはずの
exitが欠けていたため、BGP側で扱う規模の経路情報がIS-IS領域へ入った。公開資料から特定ベンダーの正確なコマンド列を再現することはできない。[1][3][5] - 作業は翌日午前1時から6時までの承認済み保守時間帯ではなく日中に行われ、対象ネットワークは接続されたままだったとされる。協力会社の作業者がKT側の作業管理者不在で変更を実施したことも調査で指摘された。[1][3][4]
- 一次・二次の確認はいずれも手作業に依存し、欠けた境界を発見できなかった。実行前に変更を代表的な隔離環境で検証する仕組みも、地域で発生した異常を全国へ広げない有効な安全機構も確認されなかった。[1][3]
- これはRPKI障害でも、プロトコル仕様そのものの欠陥でも、RFC 7908上の特定類型として立証された経路漏洩でもない。中心にあるのは、稼働中の通信事業者ネットワークで意図したプロトコル境界が守られなかった運用上の失敗である。[12][13][14]
- 高権限のルーティング変更には、実行される構成、パーサーのコンテキスト、機器・ソフトウェアの対応関係、プロトコルごとの想定経路量、代表環境での試験、限定展開、自動停止条件、外部到達性観測、訓練済みロールバックの証拠が必要になる。
- 説明責任は実際の制御能力に従う。KTは変更権限、ネットワーク接続、トポロジー、監視、復旧、顧客説明を制御していた。委託先は付与された権限の範囲で作業を制御した。利用者や加盟店はKT内部のBGP/IS-IS境界を検査する立場にはなかった。
攻撃の物語から、制御の失敗を検証する事件へ
大規模な通信障害が始まった直後、運用者がDDoSを疑うこと自体は不自然ではない。広範な到達不能、急激なトラフィック変化、監視画面上の異常は、外部からの大量通信によっても、制御プレーンの障害によっても現れ得る。しかし、初期仮説は原因認定ではない。KTが当初示したDDoSの可能性は、その後の政府合同調査によって退けられた。[1][2]
科学技術情報通信部の調査は、釜山で企業向けルーターを交換する作業中に生じたルーティング設定エラーを障害原因としている。したがって、本件を「攻撃」と表現し続けると、検証すべき制御を取り違える。DDoSなら、悪性トラフィックの発生源、フィルタリング、容量、緩和措置、攻撃主体の帰属が中心になる。設定障害なら、変更権限、実行された構成、パーサー状態、プロトコル間の境界、波及制御、検知、ロールバックが中心になる。
原因分類は単なる用語の選択ではない。分類を誤れば、組織が保存すべき証拠も変わる。攻撃とみなして外部トラフィックだけを追えば、どの設定が投入され、ルーターがどのコンテキストで解釈し、どの経路状態が他装置へ伝播したのかという内部記録が後回しになる。反対に、初期仮説の変更を時系列で残せば、なぜ対応方針が切り替わったかを後から検証できる。
政府が示した時系列では、障害の開始は午前11時16分ごろ、復旧措置の完了は午後0時45分ごろであり、およそ89分に相当する。[1] この89分は重要な基準だが、全利用者が同じ瞬間に切断され、同じ瞬間に完全復旧したことを意味しない。政府が示したのは、障害とネットワーク側の復旧措置に関する概括的な時間幅である。
当時の報道は、有線・無線インターネットだけでなく、決済、事業活動、そのほか接続性に依存するサービスへの影響を伝えている。[4][6][7][8] そこから、単一オフィスの短時間障害ではなく、全国規模の通信継続性に関わる事件だったと判断できる。一方、公開資料は、全加入者の個別停止時間、全商品の障害率、すべての依存サービスの復旧時刻を提供してはいない。
だからこそ、時刻を一つにまとめてはならない。最初の異常経路が生じた時刻、他地域への波及が止まった時刻、制御プレーンが安定した時刻、外部からの到達性が回復した時刻、決済端末や業務アプリケーションが正常化した時刻は、それぞれ異なり得る。厳密な説明責任には、この層の違いを保った時系列が必要である。
保守時間帯は実行許可であって、安全性の証明ではない
政府調査によると、承認されていた作業時間帯は10月26日午前1時から6時までだったが、実際の作業はその前日の日中に行われた。また、協力会社の作業者がKT側の作業管理者の立ち会いなしに変更を行い、対象ネットワークは稼働状態で接続されていたと報告された。[1][3][5]
この所見は、まず変更権限の問題を生む。特定の時間帯を前提に承認された作業が、どの判断と権限によって別の時間帯に実施されたのか。例外承認があったなら、その対象、理由、責任者、技術的な追加条件は何だったのか。例外がなかったなら、なぜアカウント、セッション、対象機器、作業時間を技術的に制約できなかったのか。公開資料だけでは、これらすべてに答えられない。
ただし、問題を「時間帯違反」だけに縮小すると、本質を見失う。予定どおり深夜に実行しても、不正確な構成は不正確なままである。管理者が立ち会っていても、パーサーが想定外のコンテキストで後続行を解釈すれば、危険な状態は生成される。変更票に正しい目的が記載されていても、ルーターに渡された入力が異なれば、承認された意図と稼働状態は一致しない。
区別すべき対象は少なくとも四つある。第一は、何を行う予定だったかを記す作業計画である。第二は、生成または編集され、実際に投入される構成である。第三は、ルーターが各行を解釈するパーサーのコンテキストである。第四は、装置に導入され、さらにネットワークへ配布された実際の状態である。
作業計画だけを読んだ確認者は、生成後の構成に生じた欠落を見つけられない。構成テキストを読んでも、対象ソフトウェアのパーサー状態を再現しなければ、その効果を誤解する可能性がある。単体装置で正しく見える変更も、他のルーターへ情報が配布された後には別の結果を生むことがある。したがって、承認の対象は抽象的な作業名ではなく、実行可能な入力とその期待状態に結びついていなければならない。
高い権限を持つ変更記録には、作業目的、許可された時間、責任を持つ役割、対象装置、ソフトウェア系列、正規化された構成、構成の同一性を確認する値、開始時のコンテキスト、期待される状態遷移、事前検証、停止条件、ロールバック手順を相互に結びつける必要がある。一つでも変われば、以前の承認は新しい入力の安全性を証明しない。
これは、緊急対応まで重い会議と書類で遅らせるべきだという主張ではない。緊急変更にも、限定された権限、機械的に確認できる対象、明確な期限、独立観測、事後確認を持たせられる。長い承認会議より、実際の入力と結果を結んだ短く改変困難な記録の方が、強い証拠になる場合がある。
一語の欠落ではなく、境界の欠落に全国的な権限が与えられた
政府の技術説明で中心となるのは、exitの欠落である。調査によれば、このコマンドはIS-ISの設定コンテキストを終了させる役割を持っていた。終了境界が欠けた結果、BGP処理に関係する経路情報がIS-IS領域へ入り、内部プロトコルが通常想定しない規模と種類の情報を扱う状態になった。[1][3][5]
公開説明では、内部側で想定される情報量が約一万規模であるのに対し、BGP側には数十万規模の情報があるという対比が示されている。しかし、これは本稿が独自に計測した経路数ではなく、調査報道と政府説明に帰属する概括値である。影響した正確なプレフィックス、各ルーターが受信した件数、地域ごとの隣接関係、最終的なテーブル状態は公開されていない。
完全なコマンドファイルも、ルーターのベンダー、モデル、ソフトウェアリリースも公表資料から確定できない。したがって、特定ベンダーの構文を推測し、実際に入力された正確な文字列として提示することはできない。証拠に沿って言えるのは、終了すべき設定コンテキストが終了せず、後続の情報が意図とは異なるプロトコル範囲で解釈されたという点までである。
この事件を「単純なタイプミス」と呼ぶと、誤りを全国的障害へ変えた制御経路が見えなくなる。人は文字を抜かし、順序を誤り、別のコンテキストにいることを見落とす。成熟した通信事業者の変更管理は、注意深い人だけが作業することを安全策にしてはならない。通常の人為ミスが、検知されないまま全国的なルーティング状態へ昇格できない構造を作る必要がある。
欠落した一語は小さいが、それに権限を与えた経路は大きい。構成生成は境界を証明しなかった。二段階の手動確認は欠落を発見しなかった。作業は接続されたネットワークで実行された。異常状態は導入地点の外へ出た。検知と停止は、利用者への広範な影響が発生する前に作用しなかった。説明責任は、この連鎖全体を対象にしなければならない。
重要な問いは、「注意深い作業者ならexitに気づけたか」ではない。「装置へ投入する前に、ある設定コンテキストがどこで終了し、次の行がどのモードで解釈されるかをシステムが証明できたか」である。パーサーを認識する検査なら未終了のモードを検出できる可能性がある。意味差分なら、BGPに関係する状態がIS-ISへ作用しようとしていることを示せる可能性がある。
さらに、経路量のモデルは、通常範囲から大きく外れる候補状態を拒否できる。代表環境での実行は、構文が受理されるかだけでなく、生成されるプロトコル状態を確認できる。限定的なカナリア展開は、失敗が直ちに全国へ達しない最初の実行点を作る。単一の対策ですべての事故を防ぐことはできなくても、相補的な制御を組み合わせれば、構成を信念ではなく検証対象に変えられる。
BGPとIS-ISを同じ「ルーティング」として曖昧に扱わない
BGPとIS-ISはいずれも経路制御に関係するが、同じ役割を持つわけではない。BGPは、自律システム間で到達性情報を交換し、経路の選択や広告に方針を適用するための主要なプロトコルである。RFC 4271はBGPの基本動作を定義している。[13]
IS-ISはリンクステート型のプロトコルで、通信事業者の内部ネットワークにおいて、トポロジーを記述し内部経路を計算するために利用されることがある。RFC 1195は、TCP/IP環境でIS-ISを利用するための文脈を示している。[12] ただし、これらのRFCはKTの私設ネットワーク構成を開示する資料ではない。
政府説明は、BGP側で扱われる規模の情報がIS-IS領域へ入ったとしている。これは、外部の攻撃者がKTのプレフィックスを偽って生成した証拠ではない。悪意あるBGPハイジャックと認定する根拠もない。ROAが欠けていた、またはRPKIによるオリジン検証に失敗したとする証拠もない。RPKIが本件を確実に防いだと断定することもできない。
中心にあるのは、通信事業者内部で意図されていたプロトコル範囲が、稼働構成によって越えられたことだ。プロトコル仕様が壊れていたと立証されたわけでもない。仕様は各プロトコルが何をするかを説明するが、運用者がどの再配布方針を設定し、どの境界を強制し、装置がどの状態を受理したかは、運用記録によって証明されなければならない。
RFC 7908は、意図した範囲を越える経路伝播について、主にインタードメイン環境で考えるための経路漏洩分類を示している。[14] その語彙はポリシー違反を検討する際に有用だが、政府調査はKT内部の事象をRFC 7908の特定類型として認定していない。本件を「立証済みのRFC 7908型ルートリーク」と呼べば、資料が提供していない確実性を付け加えることになる。
RFC 7454はBGP運用におけるフィルタリング、方針、上限、監視などの実務的な背景を提供する。[15] RFC 4098はBGP収束のベンチマークに関する用語を示す。[16] これらは、どのような制御や測定が考えられるかを説明するための文脈である。KTが2021年10月25日に特定のフィルター、上限、収束試験、復旧手順を使用していたことの証拠ではない。
技術文書と事件証拠を区別する姿勢は、精度のために欠かせない。RFCは設計上の期待を示せる。APNICを含む外部研究は、トポロジー観測やサービス観測によってルーティング障害を検知・分析する方法を説明できる。[9] しかし、KTの内部ログ、完全なトポロジー、投入構成、復旧操作を置き換えることはできない。
二段階の手動確認が、独立した保証にならなかった理由
政府調査は、KTに一次・二次の確認があったものの、いずれも手作業による確認に依存し、欠落したコマンドを発見できなかったとしている。[1][3] これは、人間によるレビューが無価値だという意味ではない。経験豊富な技術者は、ツールが理解できない運用上の前提や、組織間の依存関係、例外的な危険を発見できる。
問題は、同じ不完全な表現を複数人が見るだけでは、独立した保証にならないことである。二人が同じ作業計画を読めば、生成後の構成にある同じ欠陥を二人とも見落とし得る。二つのチームがテキストだけを確認し、対象装置のパーサーで実行しなければ、コンテキストの効果を共有して誤解する可能性がある。
チェックリストに二つの署名があっても、何を確認したのかが不明なら、技術的証拠としては弱い。独立性とは、確認者の名前が異なることだけではない。異なる故障原理で失敗を検出できることを意味する。構文検査、意味検査、代表実行、外部観測は、それぞれ異なる種類の異常を検出する。
より強い確認連鎖では、第一の制御が実際のソフトウェア系列に照らして構文と設定コンテキストを検証する。第二の制御が、どの経路クラスをどのプロトコルへ再配布できるか、想定量はいくらか、どの領域や隣接先へ届き得るかをポリシーと比較する。第三の制御が、代表環境で候補変更を実行する。第四の制御が、対象装置の外側からカナリアの結果を観測する。
その上で、人間は証拠と例外を評価する。人間を自動化で置き換えるのではなく、人間の判断を唯一の検出器にしない構造である。機械的な検査が警告を出し、人間が無視するなら、無視した理由と権限を残す。人間が設計上の危険を見つけ、ツールが合格させたなら、ツールの検出範囲を修正する。
代表環境を作ることは、通信事業者にとって容易ではない。実ネットワークの全隣接関係、全経路、装置挙動、トラフィック負荷を完全に複製することは難しい。しかし、完全再現できないことは、検証を行わない理由にならない。どのソフトウェア、経路集合、プロトコル相互作用、異常条件を再現し、何を省略したかを記録すれば、試験の限界を含めて評価できる。
構成リンターにも限界がある。文法だけを見るツールは、文法的には正しくても危険な再配布を受理するかもしれない。意味ポリシーを見る仕組みは、特定装置のパーサー挙動を再現できないかもしれない。デジタルツインは古い状態を持つことがある。カナリアは本番を代表しないことがある。必要なのは万能の検査器ではなく、各制御が何を検出し、何を検出できないかを示す層状の証拠である。
経路量の不変条件が、異常を自動停止へ変える
政府説明にある、内部プロトコル側の通常規模とBGP側の大きな情報量との対比は、具体的な制御方法を示唆する。通信事業者は、一定の変動を許容しつつ、各プロトコルインスタンス、領域、隣接関係、再配布方針が扱うべき経路量を把握できる。候補変更が通常範囲を大きく超える状態を生成するなら、黙って実ネットワークへ進めるべきではない。[1]
不変条件は単なる警告値ではない。「このIS-IS領域が扱う経路クラスはこれであり、通常量はこの範囲にあり、この再配布点から許可される情報はこれに限る」という期待関係である。装置単体の総数だけでなく、プロトコル、地域、隣接先、経路属性、変更段階ごとに定義できる。
固定された一つの上限には危険もある。ネットワークの成長によって正常値が上がることがある。全体数だけでは局所的異常を隠すことがある。保守中に一時的な増加が正当化されることもある。したがって、基準値、許容差、適用範囲、有効時間、例外権限、自動応答を同時に記録する必要がある。
候補状態が境界を越えたときの既定動作も重要だ。警告だけを出して変更を続けるのか、自動的に投入を止めるのか、カナリア内に隔離するのか、再配布を無効にするのか。全国へ波及した後の警告は診断には役立つが、封じ込めには遅い。制御は異常の導入地点に近いほど効果が高い。
作業票が「小規模な企業向けルーター交換」と説明していても、稼働中の経路カウンターが内部プロトコルへ桁違いの情報が移動していることを示すなら、稼働状態の証拠が作業票の物語に優先しなければならない。承認は異常な状態を正常にはしない。
異常検出には、絶対量だけでなく変化率も必要になる。短時間に経路量が急増する、特定地域から想定外のクラスが現れる、隣接関係の更新が予定範囲を超える、再配布された経路がカナリア境界を越える、といった条件を組み合わせられる。どの条件が停止を発動したかが保存されれば、事後検証にも利用できる。
自動停止は万能ではない。誤検知は正当な変更を止め、復旧を遅らせる可能性がある。しかし、高い波及権限を持つ変更では、誤って止めるコストと、異常を全国へ通すコストを同じ重みで扱うべきではない。例外を認める場合も、異常値を見た上で誰が何を根拠に継続したかを記録する必要がある。
全国的な波及は、ルーティングの宿命ではなく設計結果である
調査に関する報道は、異常が短い時間で他地域へ広がり、一地域のルーティングエラーを全国的障害にしないための有効な安全機構が不足していたと伝えている。[1][3][7] ここに第二の大きな説明責任がある。設定エラーは異常状態が生まれた理由を説明する。ネットワーク設計は、その状態が導入地点を越えた理由を説明する。
大規模ネットワークには情報の配布が不可欠である。障害を回避し、宛先へ到達するため、経路とトポロジーは装置間を移動しなければならない。すべてのルーターを恒久的に孤立させることは解決にならない。必要なのは、通常運用を維持しながら誤った状態を限定する故障領域である。
波及範囲を抑える手段には、再配布点の制約、経路方針フィルター、受信量上限、領域やレベルの境界、段階展開、明示的な方針を持つ反映点、カナリア装置、自動停止条件などがある。ただし、本件の公開資料は、KTがどの製品や具体的設計を採用していたかを示していない。特定の一製品なら確実に防止できたと断定することはできない。
重要なのは、変更前に最大波及範囲を説明できることである。「この候補変更はどの装置、地域、サービス、隣接関係まで届き得るか」「最初の実行点が失敗したとき、全国状態になる前に何が止めるか」「その停止機構自体が失敗した場合、次の境界はどこか」。これらに構成と観測結果を伴って答える必要がある。
名目上の地域区分だけでは故障領域にならない。組織図で地域が分かれていても、経路再配布や共通ポリシーによって異常が直ちに共有されるなら、実際の故障領域は全国規模である。境界は文書に書かれているだけでなく、稼働状態で強制され、試験されなければならない。
カナリアも、単に最初に一台へ投入するだけでは不十分である。その一台が全国へ同じ情報を配布できるなら、実質的なカナリアではない。カナリアの失敗が限定されたトポロジーと利用者範囲にとどまり、独立観測が合格するまで次段階へ進まないことが必要になる。
段階展開では、各段階に明確な成功条件と停止条件を持たせる。装置がコマンドを受理しただけでは成功ではない。想定した経路量、隣接状態、再配布範囲、外部到達性、代表サービスの応答が一定時間安定して初めて次へ進む。時間だけが経過したから展開を継続する設計では、静かに拡大する異常を見逃す可能性がある。
ロールバックは文書ではなく、実行可能な復旧能力である
変更管理では「問題があれば戻す」という表現が頻繁に使われる。しかし、分散したルーティング状態では、元の構成を再投入するだけで直ちに全状態が戻るとは限らない。異常経路が複数装置へ広がり、隣接関係や再配布状態が変化していれば、復旧にも段階と観測が必要になる。
実効的なロールバック証拠には、最後に正常だった構成、復元に使う入力、対象装置、実行順序、発動条件、予想時間、手動で消去すべき状態、各段階の成功条件が含まれる。訓練で測定した時間と、本番で実際に要した時間との差も残すべきである。
復旧中に即興の操作が必要になった場合、その事実は失敗を隠す理由ではなく、次の改善材料である。事前のロールバック手順が実際の状態を扱えなかったのか、観測が不足していたのか、権限が集中しすぎていたのか、複数チームの依存関係が整理されていなかったのかを検証できる。
RFC 4098が提供する収束測定の用語は、回復時間を考える背景になるが、KTの本件について測定済みの収束時間を与えるものではない。[16] 「復旧措置が完了した時刻」と「すべての経路が安定した時刻」と「利用者サービスが正常化した時刻」を同一視してはならない。
ロールバックの成功は、内部装置だけで判定すべきではない。ルーターの設定差分、プロトコル状態、経路量、外部から見た到達性、アクセス網の疎通、代表的な顧客取引を別々に確認する必要がある。内部ダッシュボードが正常でも、外部から到達できないことはあり得る。逆に、一部サービスが戻っていても、制御プレーンに不安定な状態が残ることがある。
最も強い復旧宣言は「サービスは復旧した」という一文ではない。どの層を、どの地点から、何時に、どの期待条件と比較し、何が未確認のまま残ったかを示す限定的な宣言である。
ネットワーク復旧と依存サービスの回復を分離する
通信事業者が中核ネットワークの到達性を回復しても、依存サービスが同時に正常化するとは限らない。決済端末は再接続待ちになることがある。認証セッションは期限切れになることがある。企業拠点のVPN、DNSキャッシュ、業務アプリケーション、メッセージキューは、それぞれ異なる再試行動作を持つ。
当時の報道は、インターネット利用、決済、店舗や事業活動への影響を伝えている。[2][4][6][8] ただし、個々の報道で使われる加入者数、苦情件数、失敗取引、影響サービスは同じ測定単位ではない。加入者総数をそのまま障害利用者数とみなすことはできない。苦情件数を一意の回線数と扱うこともできない。
正確な影響評価では、何を数えたかを定義する必要がある。到達性を失ったアクセス回線、失敗したセッション、障害を観測した地域、継続計画を発動した組織、完了しなかった取引などは別々の指標である。固定、無線、企業向け、卸提供を合計するなら、重複の扱いを明示しなければならない。
公開資料から、完全な顧客影響数や監査済み損失額を導くことはできない。すべての利用者が89分間停止したとも、すべての依存サービスが午後0時45分に回復したとも言えない。これらの限界を明示することは、障害の重大性を弱めるのではなく、確証のある主張と推測を分けるために必要である。
通信継続性の評価では、平均的な利用者だけを見るべきでもない。医療、公共サービス、決済、物流、企業拠点など、接続性への依存度と代替手段が異なる利用者がいる。公開資料は各分野の完全な影響を示さないため、個別の被害を創作してはならないが、ネットワーク回復だけでは社会的回復を説明しきれないという構造は確認できる。
説明責任は、肩書ではなく実際の制御能力に従う
大規模障害の後には、一人の作業者へ原因を集約したくなる圧力が生じる。物語としては単純になるが、再発防止には弱い。公開資料は、個人の雇用関係、指示、訓練、受領した構成、見えた警告、アクセス権限、例外承認の全記録を提供していない。個人の法的責任を推測すべきではない。
KTは、本番ネットワーク、変更用アカウントと手順、承認された保守時間、協力会社との関係、トポロジー、監視、ロールバック能力、顧客への説明経路を制御していた。その実際的な制御の集中により、どのように構成が実行権限を得たのか、なぜ確認が失敗したのか、なぜ波及範囲が広かったのか、何が修正されたのかを説明する主要な責任を負う。
協力会社の作業者は、付与された権限と手順の範囲で、自らが実行した作業を制御した。その作業記録は重要である。どの構成を受け取り、対象環境をどう理解し、どの警告を確認し、誰へ報告したかを調べる必要がある。しかし、実行を外部へ委託したことによって、全国的なルーティング権限に対する通信事業者の責任まで移転するわけではない。
管理者は日程、要員、例外承認を制御する。技術責任者は標準、検証方法、波及制御を制御する。セキュリティと信頼性の担当は監視、分類、初動を制御する。経営層は資源配分と残余リスクの受容を制御する。役割は重なり得るが、公開証拠なしに個人の過失や違法性を断定してはならない。
政府と規制機関は、調査、公開報告、業界要件を制御する。署名の数を増やすだけの規則では、本件と同じ失敗を防げない。二段階確認を要求しても、両方が同じ不完全な表現の目視確認なら、保証は増えない。規制上の問いは、意図的に境界を欠かせた候補構成が拒否されるか、異常な経路量が波及前に止まるか、ロールバックが測定済み目標を満たすかであるべきだ。
利用者、加盟店、公共サービスの運営者は、自らの継続計画を一定程度制御できる。複数回線、代替決済、オフライン手順を持つ組織もある。しかし、小規模利用者には実用的な冗長化手段がない場合も多い。いずれにしても、利用者はKT内部のルーター設定、IS-ISコンテキスト、再配布方針、波及境界を検査も停止もできなかった。依存側の備えは被害を減らせても、通信事業者内部の障害防止責任を置き換えない。
公開ASN記録は権限の手掛かりであり、内部経路の証明ではない
APNICのRDAP記録は、AS4766という公開自律システム資源をKTに関連する対象として確認するために有用である。[11] ASNは、インターネット上で経路の発信主体や運用連絡先を識別し、外部観測と組織上の責任を関連づける基盤の一つになる。
しかし、公開ASN記録からKTの私設IS-ISトポロジー、設定コンテキスト、全ルーター、2021年障害の内部伝播経路を復元することはできない。レジストリは公開ネットワーク資源の割り当てと連絡情報を記録する台帳であり、組織内部のすべての運用状態を保証するものではない。
ネットワークの説明責任は、複数の記録を時間と範囲に結びつけることで成立する。ASN登録は公開資源の組織的な対応関係を示す。外部経路観測は、どの到達性が広告されたかを示す。構成ログは、装置へ何を命令したかを示す。プロトコル状態は、装置が何を受理したかを示す。サービス観測は、利用者が何へ到達できたかを示す。
どれか一つだけでは、事件全体を証明できない。承認済み作業票は、稼働中経路表と矛盾したときに経路表を上書きする証拠にはならない。正しいASN登録も、私設ネットワーク内の経路を証明しない。一地点の内部ダッシュボードも、全国の顧客回復を証明しない。
本件では、行政上の意図と稼働中のプロトコル境界が一致しなかったことが重要である。説明責任ある対応は、承認された意図だけを残すのではなく、投入入力、パーサー状態、導入状態、伝播状態、外部観測を保存し、その差を説明することである。
事業継続の約束と、対策が機能した証拠を分ける
KTの2021年ESG資料は、事業継続や災害管理に関する同社の方針と約束を理解するための資料になる。[10] 事業者が自らの責任をどのように位置づけたかを知る上では有用である。しかし、企業自身の報告であり、発表されたすべての対策が導入され、試験され、現在も有効であることを独立に証明するものではない。
自動構成検証を導入したというなら、対象となる装置、ソフトウェア系列、コマンド種別、検出できない範囲を示す必要がある。仮想試験環境を整備したというなら、本番トポロジーや経路集合をどこまで代表し、何を再現できないかを示す必要がある。波及境界を強化したというなら、強制された境界と試験結果が必要になる。
協力会社の監督を改善したというなら、契約文言だけでは足りない。アカウント、セッション、対象装置、作業時間、実行構成が承認済み作業に技術的に結びつき、逸脱時に停止することを示さなければならない。緊急経路があるなら、通常経路との違い、利用条件、事後確認も必要である。
対策は存在するだけでなく、再発条件に対して機能するかを試験すべきだ。経路量上限があっても高すぎれば止められない。試験環境があっても古い構成なら代表性がない。ロールバック文書があっても、本番の負荷と権限関係で実行できなければ復旧能力にならない。
公開報告で機微なトポロジーやコマンドをすべて開示する必要はない。試験範囲、実施時期、対象となる障害類型、独立確認の有無、未解決の制約を限定的に示すことはできる。規制機関や監査者は、適切な保護の下でより詳細な証拠を確認できる。
約束と検証を分けることは、事業者への敵意ではない。重大障害後に改善した可能性を認めつつ、その改善を反証可能な事実として評価する方法である。どの制御も事故を完全には排除できないが、証拠があれば、測定された改善と安心を与えるだけの声明を区別できる。
高権限ルーティング変更に必要な最小証拠連鎖
KTの事件から導けるのは、すべての通信事業者に一つの設計を強制することではない。異なるネットワークには異なる実装がある。それでも、地域やサービスを越えて影響し得る変更について、最低限保存すべき証拠の関係は整理できる。
| 制御点 | 実行前の証拠 | 実行中の証拠 | 実行後の証拠 |
|---|---|---|---|
| 権限 | 承認済み作業、時間帯、責任役割、対象装置、例外条件 | 認証済み作業者、承認対象に結びついたセッション | 誰が、どの承認済み入力を実行したかを示す改変困難な記録 |
| 構成 | 正規化された実行構成、同一性確認値、パーサーコンテキスト、意味差分 | 装置の受理結果、警告、予期しない出力 | 意図状態、導入状態、直前の正常状態を比較する差分 |
| プロトコル境界 | 許可されたBGP/IGP間の関係、経路クラス、想定量 | 経路数、再配布状態、隣接関係の変化 | 禁止された越境状態が残っていないことの確認 |
| 波及範囲 | 最大トポロジー範囲、サービス範囲、実効的なカナリア境界 | 量、地域、方針の違反による自動停止 | 想定外の地域に状態が残っていないことの独立観測 |
| 復旧 | 版管理されたロールバック、発動条件、訓練済み所要時間 | 発動時刻、段階ごとの進行、失敗記録 | 制御プレーン収束、外部到達性、代表サービスの確認 |
| 通信 | 障害分類基準、責任を持つ連絡経路 | 仮説変更を含む時刻付き更新 | 原因の訂正、限定された影響説明、未解決事項 |
この表で重要なのは、許可から実行入力へ、入力から装置状態へ、装置状態から波及へ、復旧操作から外部サービスへと追跡できることである。作業票の番号だけでは、その後に構成が編集されたかを確認できない。画面写真だけでは、対象装置と時刻へ確実に結びつかない。ダッシュボードの要約だけでは、元になった観測が失われる可能性がある。
詳細な構成やトポロジーには安全上の配慮が必要である。公開、規制、監査、内部運用で閲覧範囲を分けられる。それでも、共通の事件ID、入力の同一性、時刻、対象範囲を持たせれば、機微情報を全面公開せずに証拠連鎖を保てる。
証拠保存の目的は、障害後の責任追及だけではない。障害中にも役立つ。技術者は何が変わり、どこまで広がり、どの復元入力が現在の状態に適用できるかを早く判断できる。証拠は運用速度と説明責任の両方を支える。
通信事業者が実行できる限定的な改善課題
第一に、変更承認を、再現可能で同一性を検証できる実行構成へ結びつけるべきである。承認後の編集は従来の承認を無効にするか、明示的な例外として再承認されなければならない。承認対象が「ルーター交換」のような抽象名だけでは、実行された状態との関係を証明できない。
第二に、検証をパーサー認識型かつ意味認識型にする。終了していないコンテキスト、禁止された再配布、想定経路量からの逸脱を別々に確認する。対象装置とソフトウェア系列を完全に再現できない部分は、検証済みと偽らず、残余リスクとして明示する。
第三に、地域変更が自動的に全国権限を得ない波及境界を設ける。カナリア、方針フィルター、量的上限、自動停止が、名目上ではなく実ネットワーク上の故障領域として機能するかを試験する。境界を越えた安全な試験異常を用い、停止記録を保存する方法も考えられる。
第四に、復旧を複数地点と複数層で測る。内部プロトコルの安定、公開経路の観測、アクセス到達性、代表顧客サービスは異なる信号である。終了宣言では、どの信号が合格し、どれが未確認かを明記する。
第五に、委託先アクセスを技術的に制約する。契約書や作業指示書だけを境界にせず、アカウント、セッション、対象装置、時間、実行入力を承認対象へ結びつける。緊急権限は別経路とし、利用時に追加証拠を残す。
第六に、初期仮説の変更を保存する。DDoSの疑いから設定障害の認定へ移った経過は、隠すべき矛盾ではない。どの観測によって仮説が変わり、対応がどう変化したかを残せば、次回の検知と分類を改善できる。
第七に、規制機関は署名数ではなく制御結果を試験する。境界を欠いた構成が拒否されるか、異常な経路量が全国波及前に停止するか、ロールバックが測定済み目標で機能するかを確認する。形式的な二重承認より、異なる故障原理を持つ検証の方が強い。
第八に、改善の範囲と限界を公表する。機微な構成を公開せずとも、対象装置群、対象障害類型、試験日、独立確認、既知の除外事項は説明できる。これにより、事業継続の約束を測定可能な主張へ変えられる。
公開記録がなお証明できないこと
完全な実行コマンドとスクリプトのバイト列は公開されていない。ルーターのベンダー、モデル、ソフトウェアリリースも本稿の資料から確定できない。影響した全プレフィックス、全経路、全隣接関係、全地域、私設IS-ISトポロジー、正確な再配布方針も不明である。
復旧に使われた正確なコマンド、各段階の時刻、収束測定、手動消去が必要だった状態も公開資料からは分からない。どの内部警告が発生し、誰が確認し、どの判断で停止または継続したかも完全には示されていない。
完全な顧客数、卸提供先を含む全影響、監査済みの経済損失も確定できない。午後0時45分にすべてのサービスが同時に正常化したとする証拠はない。加入者規模、苦情件数、取引失敗、回線障害を一つの数字へ統合すべきではない。
公開記録は、個人の過失、故意、隠蔽、契約違反、ベンダー責任を立証していない。原因となった操作と、それを全国的な結果へ変えた組織・技術制御を区別する必要がある。匿名または特定されていない作業者に法的責任を割り当てることはできない。
RFCは、プロトコルや運用上の比較基準を説明するが、KTがどの制御を配備していたかを証明しない。公開レジストリは内部伝播経路を再現しない。企業の継続性声明は、すべての対策の独立検証ではない。報道は影響と調査結果を理解する助けになるが、一次的なルーターテレメトリーを代替しない。
本稿の事件境界は2021年10月25日のルーティング設定とプロトコル境界の障害に限定される。2018年の阿峴局舎火災は、物理設備、火災、経路多様性に関する別の事件であり、本件の原因連鎖へ混在させない。
不確実性は、検証を止める理由ではない。何が公開されていないかを明示すれば、次の調査で保存すべき証拠が分かる。実行構成、パーサー状態、経路量、トポロジー範囲、停止記録、ロールバック履歴、外部到達性、依存サービスの回復が、その検証課題になる。
結論
KTの2021年障害は、小さな設定境界の欠落が、接続された全国通信網で権限ある稼働状態へ変わった事件である。承認された時間帯、作業票、二段階確認は、意図と手続きを示していた。しかし、ルーターが何を解釈し、どのプロトコル領域へ情報が入り、どこまで伝播するかを証明しなかった。
求めるべきなのは、誤りを一度も犯さない作業者ではない。通常の人為ミスが異常に大きな権限を得ない制御である。正規化された実行構成、パーサーを理解する検証、プロトコル範囲と経路量の不変条件、実効的なカナリア境界、自動停止、訓練済みロールバック、独立した回復観測が、その制御を構成する。
説明責任は実際に制御できた範囲へ配分される。KTは、委託先が作業を行った場合でも、本番ネットワークの変更権限と全国的な波及能力に対する責任を保持する。規制機関は、形式上の承認ではなく、検証と封じ込めが実際に機能するかを評価する責任を持つ。利用者は自らの継続計画を検討できるが、検査も停止もできない通信事業者内部の経路障害を防ぐ責任までは負わない。
ネットワークインフラでは、行政上の説明より稼働状態が優先される。承認記録が価値を持つのは、実際に投入された構成、パーサーのコンテキスト、プロトコルの範囲、波及限界、測定された回復へ結びついている場合だけである。KTの約89分は、変更が許可されたかではなく、実行されたネットワーク状態を誰がどの証拠で制御できたかを問う事件として記憶されるべきである。
出典
- https://www.korea.kr/briefing/policyBriefingView.do?newsId=156477990
- https://www.yna.co.kr/view/AKR20211025104300017
- https://cn.yna.co.kr/view/ACK20211029003600881
- https://cm.asiae.co.kr/en/article/2021102915001993346
- https://zdnet.co.kr/view/?no=20211029152700
- https://tbs.seoul.kr/eFm/newsView.do?idx_800=3452956&seq_800=20445533&typ_800=J
- https://www.khan.co.kr/article/202110291500011
- https://koreajoongangdaily.joins.com/2021/10/29/business/tech/KT-network-failure/20211029184239427.html
- https://conference.apnic.net/53/assets/files/APNT374/detecting-internet-routing-outages-with-topology-and-service-analysis_v2.pdf
- https://m.corp.kt.com/archive/ipgrpt/attach/2021/2021_ENG_Archive.pdf
- https://rdap.apnic.net/autnum/4766
- https://www.rfc-editor.org/info/rfc1195/
- https://www.rfc-editor.org/info/rfc4271/
- https://www.rfc-editor.org/info/rfc7908/
- https://www.rfc-editor.org/info/rfc7454/
- https://www.rfc-editor.org/info/rfc4098/
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加
