レジストリ記録が予告なく変わったとき:実務的な対応
予期しないレジストリ変更は、ルーティング、セキュリティ、顧客、管理権の証拠に影響しうる。対応手順に沿って記録の問題と経路の問題を切り分け、実行可能な移行の道を準備する。

記録が変わったら、まず何が変わり、誰がそれを認可したのかを確かめる。稼働中のネットワークは別に確認する。新しい記録だけでは全体像は分からない。
まず、変更を正確に記述する
予期しないレジストリ変更を調べる際には、連絡先の変更、登録記録の編集、IRRオブジェクトの変更、RPKI認可との不整合、経路広告の変更という、異なる事象を区別する必要がある。これらは関連していることがあるが、同じものとして扱うことはできない。
まず、対象となる資源、タイムスタンプ、情報源、観測された差分を正確に押さえる。正確に記述することで、ルーティングの問題を所有権が変わった証拠として扱ったり、記録をめぐる争いをすべての経路が危険である証拠として扱ったりするのを防げる。
最後に正常と確認できた状態を保存する
レジストリからの応答、RDAPまたはWHOISの結果、IRRオブジェクト、RPKI証明書とROA、経路の観測結果、関連する連絡先、契約、社内の変更記録を保存する。それぞれに時刻と情報源を添える。目的は、システムが変化し続けるなかでも、変更前後の比較を可能にすることだ。
後で取得した照会結果で証拠を上書きしてはならない。最新の記録こそが、争われている状態かもしれない。変更がレジストリ、経路、プロバイダーのシステム、社内アカウントのどこから始まったのかを示すには、信頼できる時系列が唯一の手掛かりになることも多い。
権限と影響を別々に確認する
誰が変更を行い、どの機能を実行する権限を与えられていたのか、どのシステムがその結果を利用するのかを確認する。そのうえで、経路、フィルター、セキュリティ上の表明、顧客アクセス、メール、監視、契約、外部の許可リストへの運用上の影響を整理する。
レジストリは記録を維持することができるが、そこから生じるすべての結果を決める権限まで委ねられているわけではない。ここではノート52が参考になる。権力と責任を同じ枠組みで捉えているからだ。記録を変更できる機関と、その費用を負担する機関は、同じとは限らない。
緊急性を恒久的な拒否権に変えずに対応する
インシデントの最中、運用者には、権限のない変更が広がるのを安全に止める方法が必要だ。しかし、あらゆる緊急対応を、将来の移転や商業上の判断を取り締まる恒久的な権力に変えてよいわけではない。証拠を検証し、差し迫った技術的リスクを封じ込め、是正の道筋を見える状態に保つべきだ。
ノート74は、証拠を求める正当な必要性と、無制限の事前承認権を区別する。ノート69は、平穏だった過去に頼ることへの警告を加える。手続きが安定しているように見えても、判断そのものが争われたときには、使える答えが何も用意されていない場合がある。
記録が争われる前に、移行の道を準備する
復旧計画には、適格な代替主体がどのように管理権を検証し、一意性を保ち、公的記録を更新し、ルーティングとセキュリティの変更を調整するかを記すべきだ。その移行を認める必要がある人とシステムも特定する必要がある。また、どの証拠を非公開に保ち、何を他のネットワークに示す必要があるかも定めるべきだ。
ノート72が示す設計原則は、正確な共通記録を保ちつつ、管理者を交代可能にすることである。復旧の道が、現管理者を説得して資源を手放してもらうことしかないなら、企業が見つけたのは一時的なインシデントではなく、構造的な依存関係だ。
チェックリストは文書ではなく、リハーサルである
模擬的な変更を使って、対応を実行してみる。チームは以前の状態を取り出せるか。記録の問題と経路の問題を見分けられるか。意思決定者と実際の権限の範囲を特定できるか。記録を修正する間も、顧客とプロバイダーは業務を続けられるか。元の調整主体が動けなければ、別の調整主体を認めることができるか。
何を証明すべきか、誰に連絡すべきか、どの代替手段があるかを組織があらかじめ理解していれば、レジストリ変更は対処可能になる。だからこそ、急いで行うべき仕事は変更前にある。実行可能な移行の道を築く時間が、まだ組織に残されているうちに取り組むべきなのだ。