要約

  • 2026年3月にProposed Standardとして公開されたRFC 9950はRFC 9105を廃止し、TACACS+のYANGモデルにTLS 1.3を加えた。順序付きサーバー群、TLSか旧来の難読化かという必須選択、資格情報参照、管理経路、運用カウンターを表現できる。
  • 正しい設定は移行許可ではない。機器群の対応、認証・認可・アカウンティングの結合、独立した緊急経路、ロールバックの実効性、残余リスクを引き受ける責任者までは証明しない。
  • 設定ハッシュ、機器能力、秘密を含まない資格情報の世代、実経路試験、カウンターの連続性、復旧証拠、承認者、非TLS経路の廃止期限を結ぶ「AAA移行記録」が必要だ。これは運用者向けの提案であり、IETFの追加要件ではない。

設定が通った後に、判断が始まる

深夜の変更作業を想像する。二つのTACACS+サーバーは意図した順序で並び、各エントリーはTLSを選択している。クライアント証明書は保管庫への参照で示され、ドメイン名、SNI、ポート、送信元インターフェース、管理VRFも埋まっている。YANGの検証は成功し、先頭のルーターから接続できた。

それでも、移行を完了してよいとは限らない。別機種が同じ参照を解決できるか。夜間担当者は復旧コマンドを実行できるか。アカウンティング記録は新しい装置識別子で検索できるか。ローカルまたはコンソールの入口は、変更中のAAAサービスなしで本当に使えるか。設定検証はこれらを答えない。

RFC 9950に欠陥があるのではない。標準と組織判断の境界が見えている。標準は望ましい状態を共通の意味で記述する。移行承認は、固有の機器、人員、時間、損失を抱えた組織が、不確実な途中状態を通ってよいか判断する。

AAAでは、この違いが特に重い。設定を誤れば、誤りを直すための管理権限まで失う。だからといって旧来の非TLS経路を残し続ければ、より弱い方式へ戻される余地が消えない。安全性と復旧可能性は、一つの緑色ランプでは同時に証明できない。

必要なのは設定項目の追加ではなく、特定の機器群が渡れること、戻れること、古い橋を期限内に上げることを示す記録である。

RFC 9950が機械に教えられること

RFC 9950はIETF標準化過程のProposed Standardで、RFC 9105を置き換える。RFC 9887が定めたTACACS+ over TLS 1.3に沿い、設定と運用状態のモデルを拡張した。

サーバーは利用者が順序を決めるリストに入る。アドレスとポートの組み合わせは重複できない。先頭が応答しないとき次にどこへ進むかは、単なる表示順ではなく冗長化の意味そのものだ。

各サーバーではセキュリティ方式の選択が必須となる。一方はTLSで、クライアントの資格情報とサーバー認証材料を参照できる。もう一方はTACACS+の共有秘密をobfuscationとして残す。RFCはTLSを優先し旧方式を非推奨とするが、既設機器を移行させるために表現自体は維持した。標準発行日に旧機器が消えたふりをしない設計である。

ドメイン名、SNI、ポート、送信元インターフェース、ネットワークインスタンスもモデルに含まれる。これらは一体で実経路を作る。通常の業務ネットワークから証明書を確認しても管理VRFからの検証にはならない。IPアドレスへ到達しても期待したサービス名の確認にはならない。予備サーバーを書いただけでは、タイムアウト後の動作を試したことにならない。

証明書や生の公開鍵に関するエラーを含め、接続状態を示すカウンターもある。discontinuity-timeは、いつ連続性が途切れたかを示す。再起動直後のゼロ件と、一週間連続したゼロ件を区別するために欠かせない。

この構造は自動化と監査を強くする。だが、機械が読める状態と、責任を持って受け入れた判断は別物だ。

資格情報の「参照先」だけでは足りない

秘密鍵、パスワード、共有秘密を装置や変更票へ複製しないため、資格情報を参照にする価値は大きい。更新もしやすい。ただし、参照が存在することは、運用中の信頼関係を証明しない。

同じ参照名が装置ごとに異なる世代へ解決されるかもしれない。クライアント証明書は有効でも、サーバー側で別のポリシー群に割り当てられることがある。サーバー証明書の発行元が正しくても、設定したドメイン名と一致しない場合がある。固定した公開鍵が一世代古いことも、管理VRFから時刻同期へ届かず有効期間判定に失敗することもある。

移行記録に必要なのは秘密そのものではない。証明書のフィンガープリント、保管庫の版、発行方針、有効期間、試験した機器群といった非秘密の世代識別子だ。秘密を証拠へ写せば新たな漏えい経路になる。一方、世代のない参照だけでは、当時何を使ったかを後から確かめられない。

相互TLSが成功しても、確認できるのは通信路の両端までだ。装置がサーバーを、サーバーが装置を認めた後、AAAポリシーは人や自動処理を認証し、その権限を決め、行動を記録する。TLS成功をロールの正しさや記録到着の証明にしてはいけない。

三つのAを別々に試す

TACACS+はauthentication、authorization、accountingを分ける。一度ログインできたという試験は、最初の機能と二番目の一部しか見ていない。

移行後も管理者は入れるが、設定を戻すコマンドだけ拒否されるかもしれない。閲覧用ロールに過剰な権限が付くかもしれない。新しいクライアント名で届いた記録が監査側の検索から外れることもある。いずれもTLS接続が正常なまま起こり得る。

試験は結果に合わせて設計する。許可される管理者、意図的に拒否される操作、制限ロール、自動化アカウントを含め、最後にアカウンティング記録を下流で探し出す。将来の全コマンドを保証するためではない。新経路で、本人確認、権限判断、追跡可能性がつながっているか確かめるためだ。

緊急アクセスも同じ試験に入れる。ローカル認証、物理コンソール、帯域外管理が中央AAAに依存せず、代表装置へ到達できることを実行で確かめる。誰が利用でき、例外利用を後でどう監査するかも残す。

通常経路は試しやすく、緊急経路は人手や現地調整が要る。そのため前者を測り、後者を信じる組織が生まれる。しかし通常経路が壊れたときの損失を決めるのは後者である。書類上だけの非常口は、移行停止の理由にすべきだ。

併存期間には終わりが必要だ

RFC 9887はTLSと非TLSの設定を明確に区別し、別ポートを使わせる。方式を推測する機会的な接続ではない。二方式が同時に残る移行期間にはダウングレード余地があり、完了するまで安全ではないため、短くするよう求める。TLS非対応クライアントには、分離した非TLSサーバーを使うべきだとしている。

つまり旧経路は永続的な安心装置ではなく、安全上の費用を伴う借用時間だ。

ロールバックには、直前の設定成果物、適用手順、実行者、利用経路、戻せる最終時刻が要る。「念のため49番ポートを開けておく」だけでは、戻れる証明にならない。所有者も試験も期限もなければ、暫定状態が恒久設計へ変わる。

早く閉じる宣言だけでも不十分だ。開始前に代表機器で復旧を実行し、ロールバック自体が変更中のAAAに依存するなら作業を止める。観測期間は資格情報の有効期間内に収め、最新のdiscontinuity-timeより後から取る。途中でカウンターが初期化されたなら、同じ安定性判断を続けられない。

目標は二重運用の常態化でも、準備なしの即時切断でもない。短く、観測可能で、責任者がいて、最後に閉鎖を証明する移行である。

AAA移行記録の八項目

この記録はYANGモジュールの外に置く。共通標準が各社の承認者や保守日程を決めるべきではない。各社の承認手続をIETFの義務として見せるべきでもない。

  1. 設定の同一性。 モジュール改訂、必要ならベンダー変換、候補・稼働設定のハッシュ、正確なサーバー順を残す。
  2. 機器群の能力。 対象装置、ソフトウェア版、対応TLS版、認証方式を記す。例外を平均値へ隠さない。
  3. 方式と世代。 サーバーごとのTLSまたは旧方式、秘密でない資格情報識別子、名前/SNIの期待値、信頼方針の版を結ぶ。
  4. 実経路の証拠。 本番の管理VRF、送信元、宛先、ポートからサービス同一性まで確かめる。別経路のラボ結果は代用しない。
  5. AAAの証拠。 認証、許可・拒否、ロール、検索可能なアカウンティングを同じ設定・資格情報世代へ結びつける。
  6. 連続観測。 最新のdiscontinuity-time以後に窓を開き、接続・証明書・公開鍵・AAA異常を分母付きで残す。
  7. 復旧と権限。 承認者、受容したリスク、試験済みのローカル/コンソール、復旧成果物、実行者、最終復旧時刻を示す。
  8. 閉鎖。 旧方式の失効時刻と撤去または隔離の証拠を残す。例外には機器群、所有者、次回判断日を付ける。

記録や参照成果物のハッシュは、後日の比較を可能にするが、判断を真実に変える魔法ではない。価値は、試験した設定、使った世代、連続した計数、決定者、実際の閉鎖が一つにつながることにある。

サーバー一覧、資格情報、ソフトウェア、信頼アンカー、経路が変われば、記録の一部は失効する。その範囲だけ新たに確認すればよい。永久安全証明やIETF適合証ではない。

書き込み権限を持つ者を、より厳密に扱う

RFC 9950は、書き込み可能なノードを機微なものと位置付ける。サーバー一覧を不正に変えれば、攻撃者が装置を完全に支配し得る。認証先、権限判断、行動記録の送付先を変えられるためだ。

NACMはYANGデータを読んだり変更したりできる主体を制限する。しかし、技術的な書き込み権限は、個別変更が有効な判断に基づくことまでは示さない。正規アカウントでも、時間外に、承認と異なる設定を適用できる。

作成、承認、適用を分け、承認を設定ハッシュと証拠へ結び、作業窓とともに失効させる。緊急例外も記録する。恒久的な「ネットワーク管理者」権限で個別取引の承認を代用してはならない。

ここで実装は政策の鏡になる。旧方式の終了を延ばせる者が実際の期限を支配し、アカウンティング不足を受け入れられる者が実際の証拠水準を決める。規程と実行系が食い違えば、実行系の方が権力構造を正直に映す。

ローカル判断を残すことは、標準の弱さではない

RFC 9950に各組織の承認オブジェクトを求めるのは、役割を取り違えている。再利用可能な標準は相互運用のための最小の意味を定め、将来の具体的判断を現場へ残す。運用者はプロトコルを分岐させずに移行記録を加えられる。

標準の採用が任意でも、採用後の判断が軽いわけではない。TACACS+を管理統制に選んだ組織には、契約、雇用規程、顧客への約束、監査統制がある。移行の権威はそれらのローカルな制度と責任者から生じ、RFC番号から自動的には生じない。

また、今回の資料には、名指しできるネットワークがRFC 9950移行でロックアウトやダウングレードを経験したという事実はない。ここで扱うのは検証すべき仕組み上の危険であり、作られた事件ではない。現実を記録するための仕組みに、架空の実績は要らない。

古い経路を閉じて初めて完了する

変更後は、稼働設定を承認ハッシュと照合し、観測期間中のカウンター連続性を確認し、期待したアカウンティングを探し、非TLS接続を実際に試す。非TLSは失敗するか、明示的に分離した旧機器群だけへ到達すべきだ。

閉鎖証拠は開始承認と同じくらい見える場所に置く。そうしなければ、新しいTLS経路を祝う一方で、古い入口を開けたまま忘れる。

RFC 9950は目的地を記述する言葉を改善し、RFC 9887は混在期間を終わらせる理由を示す。どちらも運用者の代わりに署名はできない。何が渡り、どの資格情報を使い、三つのAがどうつながり、誰が戻せて、誰が危険を引き受け、旧橋をいつ上げたか。その署名を支えるのが移行記録である。

出典

  1. Heng Lu — The Policy Mirror
  2. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  3. Heng Lu — Why BTW Media Exists and Why Reality, Not Advocacy, Is the Product
  4. RFC Editor — RFC 9950情報
  5. RFC 9950 — TACACS+のYANGデータモデル
  6. RFC Editor — RFC 9887情報
  7. RFC 9887 — TLS 1.3上のTACACS+
  8. RFC Editor — RFC 9105情報
  9. RFC 9105 — TACACS+のYANGデータモデル
  10. RFC 8907 — TACACS+プロトコル
  11. RFC 8341 — ネットワーク設定アクセス制御モデル
  12. RFC 9645 — TLS・DTLS用YANGデータモデル
  13. RFC 9525 — TLSにおけるサービス識別