Summary

  • RFC 10011のHTTPリスナーは、前段に外部TLS終端装置がある構成のために用意されている。平文RESTCONFを外部へ公開してよいという意味ではない。
  • RFCはセキュリティ境界が終端装置まで拡張されると明記する。外部アドレス、プロキシ数、証明書転送ヘッダーは構成意図であり、実際の要求経路やIDを証明しない。
  • Daniel Kadeは、外側の認証結果からRESTCONFユーザー名とNACM判断までを相関させる「終端境界レシート」を提案する。

鍵のマークが二つの事実を一つに見せる

監視画面には「TLS正常」と「アクセス許可」が並ぶ。前者はロードバランサーがクライアント証明書を受け入れた結果で、後者はRESTCONFサーバーがあるユーザー名にNACMを適用した結果だ。この二つが同じ要求についての証拠である保証は、表示色からは分からない。

外部終端では、認証したプロセスと操作を許可するプロセスが異なる。途中で証明書やユーザー名はHTTPヘッダーへ写されるかもしれない。別のプロキシを通過するかもしれない。バックエンドへ直接届く保守経路が残っているかもしれない。暗号方式の強さだけを調べても、この継ぎ目は検証できない。

RFC 10011はRESTCONFクライアントとサーバーのYANGモデルを定義し、通常接続とCall Homeを扱う。RESTCONFにHTTPSが必要というRFC 8040の原則を維持したうえで、外部でTLSを終端する場合に限ってHTTPの選択肢をモデル化する。そして、その場合にはセキュリティ境界がTLS終端装置まで広がると述べる。

重要なのはHTTPを選べることではない。信頼の根拠を置く場所が変わることだ。

許された分離には説明責任が伴う

外部終端は珍しい抜け道ではない。証明書更新を一元化し、接続処理を共通基盤へ集約し、サービスごとの負担を減らせる。RFC 10011もこの構成を正面から扱っている。したがって、終端後のHTTPを見ただけで直ちに違反と決めつけるのは正確ではない。

一方、http-listenという機能名だけを根拠に、管理面の平文公開が認められたと解釈するのも誤りだ。前提は外側のTLSである。さらに、終端装置からバックエンドまでが、認証済みの主張を壊さずに運べるよう管理されていなければならない。

「社内経路」という言葉は制御ではない。誰が到達できるのか、ヘッダーを誰が書けるのか、フェイルオーバーで経路が変わるのか、迂回路が遮断されているのかを個別に示す必要がある。

YANGが可視化する三つの論点

サーバーモデルのexternal-endpointには、外部アドレスとポート、trusted-proxy-count、client-cert-varがある。最後の項目は、外部TLS終端装置がクライアント証明書を転送するHTTPヘッダー名で、例としてX-Client-Certが挙げられる。クライアント証明書を使わない認証もあるため必須ではない。

第一の論点は経路だ。設定された外部アドレスは、現在の要求がそこを通った証拠ではない。第二は中継だ。信頼するプロキシ数は期待値であり、実際のホップ数を測った結果ではない。第三はIDだ。ヘッダー名を決めても、外部から同名の値を注入できないことや、終端装置が必ず上書きすることまでは保証されない。

つまり、モデルは監査の質問を鋭くするが、答えを自動生成しない。構成は意図を表す。稼働中のプロセス、経路、ログ、否定テストが実行を表す。この二つを混同しないことが、running codeを重視する統治の出発点になる。

認証名は加工された結果である

TLSをサーバー自身が処理すれば、同じ接続上の相手とRESTCONF要求を直接結び付けやすい。外部終端では、相手を確認した事実を別の媒体に載せ替える。証明書全体、Subject、検証済みユーザー名、限定属性のどれを渡すにしても、そこには変換規則がある。

大文字小文字や文字コードをどう正規化するのか。候補が複数なら拒否するのか。値が欠けたら匿名扱いか失敗か。受信した保護対象ヘッダーを削除してから書き直すのか。再試行した要求を元のTLSセッションへ戻せるのか。これらは暗号プロトコルの外側にあるが、認証結果の意味を決める。

RFC 8341のNACMは、認証済みユーザー名を起点に操作とデータへの権限を判断する。入力名が誤っていれば、NACMは誤った主体に対して正しく規則を実行する。許可結果だけでは上流のID生成を証明できない。

Call Homeでも役割を取り違えてはいけない。RFC 8071が逆転させるのはTCP接続の開始側であり、TLSとRESTCONFのクライアント・サーバー関係ではない。装置から接続してきたという事実は、証明書検証の代わりにならない。

境界を所有するのは一つのチームではない

実務では、TLS終端装置をプラットフォーム部門、経路をネットワーク部門、証明書と名前対応をID部門、RESTCONFをサービス部門、NACMを権限管理者が持つことが多い。一つの部門が全体を検証できないからこそ、証拠の接続方式が必要になる。

RFC 9641とRFC 9642はtruststoreとkeystoreを、RFC 9645はTLSクライアント・サーバーの設定グループを標準化する。共通語彙は依存関係を見えるようにするが、稼働プロセスがどの版をロードしたか、どの外側セッションが特定の変更要求になったかまでは語らない。

形式的に証明書を所有していても、バックエンドへIDを主張できるすべての経路を実質的に制御していなければ、実用上の主権は不完全だ。所有権の一覧より、誰の変更が保証を無効にするかを示す方が重要である。

終端境界レシート

私は外部終端RESTCONFごとに終端境界レシートを残すことを提案する。これはDaniel Kadeによる編集上の統治案で、RFC 10011の追加要件ではない。

レシートはまず、外部endpoint、役割、構成版、想定プロキシ列、責任者を特定する。終端装置の証明書識別子、信頼ポリシー、クライアント認証方式、有効期限とローテーション状態を参照する。秘密鍵、資格情報、完全な構成は保存しない。

次にID転送契約を記す。許可ヘッダー、正規化規則、外来値の削除、信頼終端による強制上書き、欠落や重複時の失敗方法を示す。外側で提示された証明書と、後段へ渡した属性は別々に記録する。

バックエンド部分には到達可能な送信元、適用される保護、想定ホップ数、直接迂回テストの結果を置く。私設アドレスやファイアウォール全文ではなく、ポリシー識別子と限定された結果でよい。

最後に、外側TLS認証イベント、内部HTTP要求、導出RESTCONF名、NACM判断を一つのtrace IDで結ぶ。時刻、ソフトウェア版、ポリシー版、検証結果、ログの限定ハッシュを残し、管理ペイロードは残さない。証明書、proxy、経路、ヘッダー規則、NACM対応が変わればレシートは失効する。

部品ではなく継ぎ目を試験する

有効な試験は境界を横断する。不信な送信元から保護ヘッダーを送り、拒否または上書きを確認する。低権限証明書で接続し、バックエンドの名前が正確かを見る。終端装置を通らずにポートへ到達できないか試す。外側認証を失敗させ、対応する内部要求が存在しないことを確かめる。

主経路だけでなく、待機系ロードバランサー、保守経路、古いlistenerも対象にする。成功した一件は、別の迂回路が閉じている証拠ではない。

報告文も層を保つべきだ。「外側TLSを検証」「承認済み終端からのID転送を受理」「直通経路を拒否」「NACM判断を相関」と書く。「RESTCONFは安全」と一語にまとめるのは、対象経路と鮮度がそろった後だけである。

RFC 10011の価値は、終端を隠さずにモデルへ入れた点にある。暗号化が終わった場所で、説明責任まで終わらせてはならない。

参考資料

  1. Lu Heng — データ主権の技術的現実と実務的現実
  2. Lu Heng — BTW Mediaが存在する理由
  3. Lu Heng — Running-Code Primacy
  4. IANA — YANG Parameters
  5. RFC 10011 — RESTCONFクライアント・サーバーYANGモデル
  6. RFC 8040 — RESTCONF Protocol
  7. RFC 8071 — NETCONF/RESTCONF Call Home
  8. RFC 8341 — Network Configuration Access Control Model
  9. RFC 8342 — Network Management Datastore Architecture
  10. RFC 8446 — TLS 1.3
  11. RFC 9000 — QUIC
  12. RFC 9110 — HTTP Semantics
  13. RFC 9641 — TruststoreのYANGモデル
  14. RFC 9642 — KeystoreのYANGモデル
  15. RFC 9645 — TLSクライアント・サーバーYANGグループ
  16. RFC 10009 — HTTPクライアント・サーバーYANGグループ