要約

  • immutableは読み書き可能データストアを通じてクライアントが変えられないシステム提供設定を表し、サーバー自身の更新能力を封じるものではない。
  • 実効値は明示値、親からの継承、最上位の既定値のいずれかで決まるため、解決済みの真偽だけでは証拠が足りない。
  • 観測スナップショット、インスタンス経路、継承元、サーバーの決定権、編集結果を結ぶ期限付き受領書が必要になる。

不変という言葉の主語

一般に「不変」は、時間が過ぎても同じものを指す。変更不能な記録や固定されたダイジェストが典型だ。draft-ietf-netmod-immutable-flag-14が扱う不変性は別の軸にある。真と注釈されたシステム設定について、サーバーはクライアントが読み書き可能データストアで別の値を設定したり、intendedからシステム提供ノードを取り除いたりすることを認めない。

この表現が必要なのは、YANGのconfig trueだけでは実機の混在した設定木を十分に説明できないからだ。システムが必ず用意するリスト項目の下に、利用者が設定する子ノードがある場合もある。when、must、leafrefがシステム提供ノードを参照することもある。自由記述のdescriptionに拒否理由を書くより、機械が読める注釈の方が自動化に向く。

草案は、この印がサーバーの既存動作を記述するものであり、新しい動作を命じるものではないと明示する。同時に、不変なシステム設定を作成、更新、削除できるのはサーバーだとする。つまり、問われているのは「クライアントがこの経路で変更できるか」であって、「サーバー値が将来も同じか」ではない。

正午の応答が真でも、機器交換後の午後にサーバーが別の値を提供することは両立する。正午の応答は誤りではない。しかし、それを履歴保証として扱えば主語を失う。

注釈は要求しなければ見えない

クライアントはsystem、intended、operationalの読み取り専用データストアを取得するとき、with-immutabilityを明示する。他のデータストアに対する要求は草案上エラーになる。NETCONFではYANG libraryにietf-immutable-annotationモジュールがあるかを確認し、RESTCONFでは定義されたcapability識別子を確認できる。

したがって証拠は、真偽値より前から始まる。サーバーが能力を広告したか、どのデータストアと部分木を要求したか、どの主体が読む権限を持ち、いつ応答を受けたかが必要だ。後から一つの真値を切り出しても、観測条件は復元できない。

旧版との組み合わせは欠落の意味を増やす。古いクライアントは要求しないため注釈を受け取らない。新しいクライアントが古いサーバーへ送ると、未対応パラメーターのエラーになることも、無視されることもある。注釈の省略は継承や既定値、冗長な値の抑制でも起きる。能力と要求を保存しなければ、省略を可変と誤認する。

木を解く過程が証拠になる

子ノードに明示値がなければ親の状態を引き継ぐ。最上位で省略された場合は偽が既定値だ。子孫は継承状態をリセットし、自分の部分木に別の状態を適用できる。データ木の中で不変性が切り替わる回数に上限はない。

通信量を抑える設計だが、監査側は解決経路を残す必要がある。最終的な真偽だけでは、それが明示、継承、既定のどれか分からず、決定した祖先や途中のリセットも失われる。同じ真に見える二つのノードでも、親が変わったときの影響は異なる。

リストではインスタンス性がさらに重要だ。注釈は抽象的なリスト全体ではなく個々の項目に関係し、同じリスト内でも値が異なり得る。RFC 7952の制約により、リスト全体の挙動は親から継承され、特定項目がリセットする形も生じる。追加、削除、変更、並べ替えのどこが禁止されるかはノード種類によって異なる。

受領書にはインスタンス経路、ノード種類、YANGモジュールの版、明示注釈、解決値、継承元とリセットを入れるべきだ。解決値は計算結果であり、入力がなければ再計算できない。

runningに同じ値を書いても権限は移らない

クライアントはシステム提供値と同じ値をrunningへ明示し、その記述を後で削除できる。どちらもintendedのシステム値を変えない。変わるのは読み書き可能データストアでの見え方であり、値の由来ではない。

runningだけを追う変更履歴は「クライアントがノードを作成した」と記録するかもしれない。それを有効設定の起源と解釈すれば誤る。逆に、不変なシステム設定は明示されない限りrunningに現れないことがある。runningだけの資産棚卸しでは、装置を実際に拘束する値が欠ける。

時間的来歴は、クライアントの編集イベントとサーバーのシステム設定イベントを別に持つ。サーバー値がハードウェア検出、起動プロファイル、製品規則のどれから来たかは、ローカル環境が証明できる範囲で記録する。標準注釈は起源を運ばない。分からない場合は「サーバー起源不明」とし、推測で埋めない。

アクセス拒否が先に決まる

NACMを使うサーバーは、アクセス制御を評価してから不変性を確認する。操作権限のない利用者にはaccess deniedが返り、対象が不変であるかを先に知らせない。この順序は情報漏えいを抑えると同時に、障害分析の順序も決める。

編集失敗をすべて「不変性による防御」と数えることはできない。認証主体、操作、対象経路、NACM判定、不変性検査が実行されたか、最終error-tagを保存して初めて分類できる。権限不足、値検証、不変性を一つの件数に混ぜれば運用判断を誤る。

どの設定が固定されているかという情報自体が攻撃の手掛かりになる可能性も草案は認める。そのため、注釈されたノードを読む権限を持つクライアントだけが取得でき、NETCONFやRESTCONFの安全な通信と相互認証も引き続き必要だ。分析基盤へ転送するときは元の読み取り範囲を失わない設計が要る。

観測期限を持つ来歴受領書

標準の真偽値を複雑にする必要はない。横にローカル受領書を置けばよい。サーバーまたは論理ネットワーク要素、ソフトウェア版、データストア、YANGモジュール版、能力発見、取得プロトコルを記す。部分木、インスタンス経路、設定値、解決済み不変状態、明示または継承元、応答時刻を続け、利用可能なら設定リビジョンやスナップショットの識別子、ダイジェストを加える。

次に、証明できるローカル事実だけを書く。システム設定の源、決定権者、最後のサーバー変更と理由だ。不明は不明のままにする。編集を試みた場合は、役割、意図、NACM結果、不変性結果、返されたエラーを添える。

最後に再観測期限を設ける。「不変と観測した」を「永久と認証した」に変えないためだ。後にサーバー値が変われば新しい受領書を作り、以前のものは残す。二つの記録で初めて、当時のクライアント境界と時間変化を同時に示せる。

この履歴をYANGのブール値に詰め込むべきではない。ローカルの人物、工程、履歴まで標準フィールドに持ち込めば相互運用性を損なう。標準は共通境界を狭く表し、運用証拠は観測可能な事実を外側で結ぶのがよい。

導入は組み合わせで測る

調査時点で第14版はIESG承認後のRFC Editorキューにあり、なお有効なInternet-Draftだった。YANG検証はエラー、警告ともゼロだった。これは標準化工程の状態であって、製品導入率ではない。

環境には能力を持つサーバーと持たないサーバー、要求するクライアントと要求しないクライアントが混在する。新しいクライアントと古いサーバーの組み合わせでは拒否または無視が起こり、継承による省略もある。不在を一律に可変と分類する指標は役に立たない。

観測単位は、能力発見、正しい要求、応答、状態解決までの完了経路である。編集があればアクセス制御後の結果分類まで含める。どこで経路が止まったかを見れば、更新、設定、可観測性のどれに投資すべきかが分かる。

情報源