要約

  • RFC 9950 は TACACS+ サーバーごとに TLS、クライアント識別、サーバー認証、SNI の設定面を提供する。
  • 相互認証された接続はその接続の根拠であり、利用者の権限、コマンド実行、組織上の責任を自動的に決めるものではない。

安全な輸送路を持つことは重要だが、それは判断の終点ではない。RFC 9950 は RFC 7317 の /sys:system を拡張し、TACACS+ クライアントがどのサーバーへ、どの保護条件で接続を試みるかを YANG で表す。サーバーごとに、アドレス、ポート、サービス種別に加え、TLS のクライアント識別とサーバー認証、あるいは既存環境向けの共有秘密による選択を置ける。

この選択が扱うのは接続の保護である。RFC 9950 は共有秘密の方式を「暗号化」ではなくオブファスケーションと呼び、意味のある完全性、秘匿性、再送防止を提供しないと明記する。これは導入済み環境への配慮として残され、TLS の利用が推奨される。RFC 9887 は TLS 上の TACACS+ に TLS 1.3 と相互認証を要求し、旧式のオブファスケーションを置き換える。ここで相互に確認されるのは接続相手であり、利用者にどの特権を与えるかという業務上の判断ではない。

RFC 9950 が表すサーバーの名前にも二つの層がある。基になる輸送接続に用いるアドレスまたはホスト名と、TLS の SNI に入れるサーバーのドメイン名は別に設定できる。SNI の有効化にはドメイン名が必要である。この分離は、TLS の名前確認、接続先の解決、そして遠端が後で適用する認可方針を一つの「信頼できる名前」にまとめないための設計である。

資格情報の参照も便利さと権限を分ける。クライアント識別やサーバー認証の資格情報は、上位で定義して特定サーバーから参照することも、サーバーの下で明示することもできる。参照が存在することは、その構成要素を使う予定を表す。参照先が正しく管理されているか、接続時に受け入れられるか、そしてその後の TACACS+ 要求にどんな答えが返るかは、別の観測と別のローカルな決定に属する。

そのため RFC 9950 は管理面も守ろうとする。共有秘密には default-deny-all、クライアント識別とサーバー認証の資格情報には default-deny-write が付く。RFC 8341 の NACM は、NETCONF や RESTCONF の利用者を操作と内容の一部へ制限できる。これらは誰が設定を読んだり変更したりできるかを制御する。NACM が保護した書込みと、TACACS+ サーバーが特定の利用者に認可する行為は、連続して見えても別の制御面である。

運用カウンターも結論を埋めない。接続失敗、タイムアウト、メッセージ数、セッション数、証明書エラーは、設定したサーバー関係に関する手掛かりを示す。証明書エラーは調査のきっかけになるが、ある利用者が拒否されたことや、遠端の組織的な正当性を証明するものではない。接続の証拠と認可の結論を別の記録に保つ必要がある。