要約

  • RFC 9899 では、親 ACL を書き換えずに参照先の defined set を更新できる。親ルールの不変性は、有効な照合範囲の不変性を意味しない。
  • 事故時点を再現するには、変更主体、集合の完全なメンバー、装置別の intended/operational、attachment point、カウンターと後段結果を別々に結ぶ必要がある。

三台の装置には、同じ名前の ACL が配られていた。管理画面では、いずれも同じ緑色だった。ところが調査対象のアドレスは、一台では拒否集合に入り、一台ではまだ入らず、残る一台については operational の取得時刻が欠けていた。

親ルールを比較しても差分はない。差分があったのは、そのルールが名前で参照していた prefix set だった。運用上は便利な抽象化が、監査上は別の保存単位を要求していた。

RFC 8519 の基本モデルでは、ACL は順序を持つ ACE の集合である。各 ACE はパケットヘッダーやメタデータの照合条件と、accept、drop、reject、count、police などの動作を組み合わせる。ACL は interface などの attachment point に適用されて初めて、通過する通信の照合に使われる。

RFC 9899 は、このモデルに再利用可能な defined set を加える。IPv4/IPv6 prefix、port、protocol、ICMP type を名前付き集合として管理でき、alias では prefix、protocol、port、VLAN など複数の要素を束ねられる。さらに payload、MPLS、VLAN、I-SID、fragment、TCP flags、rate-limit といった面も拡張する。

重要なのは仕様が示す運用理由である。名前付きリストはルール作成と集合管理を切り離すため、親 ACL を再定義せずにメンバーを追加・削除できる。ACL と set は管理ドメインで定義し、複数の装置へ関連付けることもできる。重複入力は減るが、一つの集合変更が何台、何ルールへ届くかは、親ルールの diff から見えなくなる。

したがって「ルールが変わっていない」という文は不完全である。必要なのは、ある時刻に名前が何へ解決されたかである。親 ACL、ACE の順序、参照された set と alias の全メンバー、YANG module revision、対象装置、attachment point を一つの再現可能な記録にしなければならない。

配布の時間差も意味を変える。集合が 10 時に更新され、管理サーバーが 10 時 2 分に成功を返し、一台目が 10 時 3 分、二台目が 10 時 8 分に適用したとする。10 時 5 分のパケットに対する答えは装置ごとに異なる。中央の成功時刻だけでは、どちらも証明できない。

RFC 8342 は、この差を datastore の構造として扱う。<intended> は変換後にシステムが適用しようとする構成であり、<operational> の構成部分との比較により、どこまで実際に使われているかを調べられる。inactive configuration、remnant configuration、内部伝播の遅れ、適用失敗も同じ世界に存在する。

中央テンプレートが正しくても、装置の feature、既定値、augmentation、停止中の枝によって operational は変わり得る。desired state は重要な管理証拠だが、稼働状態そのものではない。

通信管理プロトコルの応答にも範囲がある。RFC 6241 の NETCONF <ok> は、RPC 処理中に error や warning がなく、返すデータがない場合の応答である。RFC 8040 の RESTCONF では、resource の作成・変更成功に 201 や 204 が使われる。どちらも管理取引の証拠であり、後に到着したパケットの ACE match やサービス完了を表すものではない。

RFC 8341 の NACM は、YANG data と operation に対する read、write、execute を制御する。RFC 9899 が defined set に nacm:default-deny-write を付けるのは、無権限変更が不正な許可や拒否を生み得るからだ。しかし「その利用者は変更を許された」と「そのパケットは ACL で処理された」は別の命題である。

RFC 8519 の read-only counter は、構成より一歩先の証拠になる。ACE や、対応する場合は interface 単位で matched-packets と matched-octets を取得できる。増分は装置が通信を ACE に帰属させたことを示す。ただし reset epoch、収集範囲、時刻、attachment、解決済み集合がなければ、事故時点の意味は定まらない。カウンターは通常、利用者の身元やアプリケーションの成功まで証明しない。

ゼロも結論ではない。非対応、別 interface、直前の reset、収集欠落、未 attachment、古い set の残存があり得る。negative evidence として使うなら、観測できた範囲と、観測できなかった経路を同時に残す必要がある。

payload match には別の限界がある。RFC 9899 は offset、length、binary pattern、operator をモデル化する一方、暗号化されていないデータでは決定的でも、暗号化通信では不変の可視 pattern があるかに効率が左右されると述べる。表現可能なルールが、すべての通信で有効な可視性を持つとは限らない。

RFC 7950 の YANG 1.1 は configuration、state data、RPC、notification の形を厳密にする。schema 検証が保証するのは表現の整合性である。装置への適用、パケット照合、後段結果は、それぞれ別の実行証拠を必要とする。

監査用の保存物は、上位オブジェクトの画面コピーでは足りない。認証された actor と session、NACM decision、request body、target datastore、response を保存する。親 ACL と ACE、すべての参照メンバー、module revision、device capability、association、attachment、intended と operational を同じ時計軸に置く。必要なら counter、log、packet/flow observation を続け、最後は application 自身の結果へ接続する。

rollback も参照グラフを戻さなければならない。親ルールだけを復元し、set を新しいままにすれば、意味は戻らない。controller 上の復元だけで各装置を確認しなければ、実行状態は不明なままである。last-known-good にはメンバー、module、対象装置、attachment と verification probe が必要だ。

Heng Lu のRunning-Code Primacyは、一つの画面を万能の権威にする考えではない。管理サービスは処理した取引、装置は operational と counter、sensor は観測した packet、application は確定した結果について、それぞれ限定的な証人になる。

Reality Layersに従えば、不変のルール名を、変化する実体の代用品にしてはならない。Data Sovereigntyは技術的制御と広い権限主張を分ける。Minimum Initial Specificationは共通モデルを薄く保ち、配布、保持、rollback の判断を観測可能な現場へ残す。

経営判断で問うべきなのは ACL 名ではない。「この装置はその瞬間にどの完全な集合を解決し、どの通信を match と報告し、その後をどの独立記録が証明するか」である。

Sources