要約

  • RFC 3871は、現行設定を知らなくてもコンソール通信を既定値へ戻せる手順と、特殊なクライアントを要求しない低依存の管理経路を求めている。
  • プロンプトが見えた事実は復旧証明ではない。対象装置、認証方式、権限、受理された操作、実際の状態変化、外部から観測したサービス結果がそれぞれ必要になる。

障害発生から十一分後、現場担当者はルーターのシリアルポートに接続した。端末には文字化けだけが流れた。台帳にはケーブルの所在はあったが、ボーレート、データ長、パリティを変更した記録がない。候補を順番に試す間、サービスは停止し続けた。

予備ポートは存在していた。復旧能力は存在していなかった。

2004年9月にInformational RFCとして公開されたRFC 3871は、大規模ISPの管理対象ルーターとスイッチに向けた運用セキュリティ要件を整理する。現在の製品を認証する規格でも、導入実態の調査でもない。しかし、非常用経路を「普段の系より前提が少ない機能」として設計する視点は今も有効である。

単純さは装飾ではなく可用性である

インバンド管理は顧客トラフィックとインターフェースや経路を共有する。回線飽和、誤ったルーティング、公開インターフェースの障害が、サービスと修復手段を同時に失わせる。管理トラフィックの優先度を上げても、切断された経路や停止したIPスタックは通れない。

RFC 3871は、forwarding planeとIP control planeから独立して完全な設定・管理ができるコンソールを要求する。さらに、現行の通信パラメーターを知らなくても既定値へ戻す公開手順を求める。接続側に独自装置、独自拡張、特定ソフトウェアを必須にしてはならない。

非常時には、普段なら小さく見える依存が支配的になる。ライセンスサーバー、古いUSBドライバー、専用GUI、担当者しか知らない設定は、どれも故障点である。緊急経路の品質は機能の多さではなく、失敗してもなお残る最小機能で評価すべきだ。

リモート化すると、コンソールの力もネットワークへ移る

シリアルポートをターミナルサーバーへ接続すれば、NOCから現場へ行かずに操作できる。RFCは同時に、その利便性が露出を増やすと警告する。ブート停止、パスワード回復、完全な設定変更といった物理ポート固有の力が、IPで到達可能な装置の背後に置かれるためだ。

そのとき証明すべき対象は、ターミナルサーバーへログインできたことだけではない。論理装置名、サーバーのポート番号、パッチパネル、ケーブル、対象シャーシを結び付ける必要がある。静的なホスト名やbannerは役立つが、設定と一緒にコピーできる。ハードウェア固有値、制御されたchallenge、現地観測などを組み合わせなければ、正しい権限を間違った装置へ行使する危険が残る。

外部AAA障害と拒否は同じではない

コンソールは、機能するIPや外部サービスに依存しない認証を備えるべきだとRFCは述べる。TACACSやRADIUSから応答がない場合にローカルアカウントへ切り替えるのが例である。

ただしfallbackは安全機能であると同時に例外権限でもある。fail openは裏口になり得る。fail closedは修復不能を招く。外部AAAのtimeout、経路断、明示的reject、遅延応答を区別し、どの状態だけがローカル認証を有効にするかを定める必要がある。中央の「拒否」を単なる無応答と扱って上書きしてはならない。

認証後も権限は別である。RFC 3871は権限レベル、ユーザーへの割当て、既定の無権限、昇格時の再認証を個別に要求する。NETCONFの安全なsessionも全操作を許可するわけではなく、NACMは操作とdata nodeごとの権限を扱う。

記録には、どの認証源が使われ、なぜfallbackが発動し、誰の承認でどのroleへ昇格し、どのコマンドが許され、いつ緊急資格情報を閉じたかを残すべきである。

専用管理Ethernetは低レベルconsoleと同じではない

RFC 3871は管理専用IPインターフェースを認め、それと非管理インターフェースの間で転送してはならないとする。隔離は管理網が顧客網への意図しない通路になるのを防ぐ。

しかし同じ節は、そのインターフェースがOS、IPスタック、既知の正しい管理設定に依存すると明記する。顧客トラフィックと別経路でも、装置内部の故障領域は共有し得る。資産台帳で両方を単に「OOB」と記録すれば、IP障害を越えられるかという重要情報を失う。

RFC 8994のAutonomic Control Planeは、通常のdata plane設定とroutingからできるだけ独立するvirtual out-of-bandを構築する。RFC 8368は、in-bandで運ばれる管理面が物理的な別網と同じ分離を完全には得られないと認める。仮想方式が有効でも、enrollment、証明書、secure channel、隣接、経路、endpoint、認可を別々に確認しなければならない。

演習は意図した故障を起こして初めて意味を持つ

正常時にコンソールへ接続するだけでは、平常時の到達性しか示さない。受入試験では、管理対象を明示し、production routeと外部AAAを制御下で利用不能にし、それでも正しい装置へ到達できるかを確かめる。通信パラメーターを未知状態から戻し、fallback認証と最小権限を使い、既知の事前状態に対して承認済み操作を実行する。

次に、装置内部で設定やprocess stateが変化したかを確認し、管理面からproduction面への意図しない転送がないことを検査する。最後は別経路のprobeで顧客トラフィックやapplicationが戻ったかを見る。

CLIのsuccessは、文字列を受理した証拠にすぎない場合がある。プロセスが適用しない、FIBが更新されない、隣接装置が収束しない、診断そのものが誤る可能性がある。逆にサービスが別の要因で戻ることもある。コマンドと結果を同一視せず、時間とidentityを持つ二つの記録として接続する必要がある。

復旧後はローカル秘密をrotationし、一時ACLやrouteを削除し、backupとrunning stateを照合する。信頼できる時刻と元のIP addressを含むlogを遠隔保存しなければ、非常権限の利用を後から検証できない。

限界

資料は特定のoperator、vendor、incident、復旧時間を証明しない。2004年の暗号例は歴史資料であり、現在の推奨ではない。RFCの追加要件は物理securityを範囲外とするが、実運用ではpower、rack access、remote hands、建物の共通障害を調べる必要がある。

一度成功した試験も永続しない。firmware、配線、AAA、ターミナルサーバー、資格情報、人員が変われば再試験が必要である。証明は日付、故障モデル、対象構成と一緒に保存して初めて意味を持つ。

出典