要約

  • RFC 1447 のアクセス行は、対象パーティー、主体パーティー、資源コンテキストの三つで索引され、許可する PDU クラスを別の値で示した。
  • 既知の送信元や認証済みメッセージは、受信側が行うローカルな認可判断の入力にすぎず、広域に持ち運べる権限ではなかった。
  • 後継の VACM は構造を変えたが、主体、コンテキスト、セキュリティ条件、ビュー種別、個別オブジェクトを分ける規律を残した。

決定は受信側に残された

Party MIB は 1993 年 4 月に公開された初期 SNMPv2 文書群の一つだった。ここでいうパーティーは、人名や組織名の別名ではない。SNMPv2 エンティティが持つ操作のうち、管理上定められた一部だけを実行できる概念的な実行環境である。

一つのエンティティは、権限範囲が重なる複数のパーティーも、互いに分離したパーティーも実現できた。また、リモートのパーティーをローカルに記録しながら、自分では実現しないこともできた。識別子が選ぶのは管理レコードであり、どこでも通用する「管理者」の身分ではなかった。

RFC 1447 の aclTable は、この考えを関係として保存した。行の索引は aclTarget、aclSubject、aclResources である。target は操作を実行するよう求められる側、subject は要求する側、resources は要求対象の SNMPv2 コンテキストを指す。

三つが一致した後で、aclPrivileges が許可された通信クラスを示す。権限は主体だけの属性ではない。誰が、誰に、どの資源世界で、どの動詞を求めるかという有向関係だった。

数字は役職ではなく動詞集合だった

Get は 1、GetNext は 2、Response は 4、Set は 8、GetBulk は 32、Inform は 64、SNMPv2-Trap は 128 とされた。複数を許可する場合は値を加算し、ゼロは空集合を表した。既定値 35 は Get、GetNext、GetBulk の合計である。

35 は権限レベルの中段ではない。43 なら同じ読み取り集合に Set が加わり、4 なら Response だけになる。整数を分解せずに「信頼済み」と表示すれば、方向、コンテキスト、対象、操作の違いが消える。

初期設定例では、管理側の主体からエージェント側の対象へ読み取り要求を許す行と、逆方向に Response や Trap を許す行が別に置かれた。質問できることは回答できることを自動的に意味せず、Set は明示的に含まれなければならなかった。

同じ二者が登場しても、向きを逆にすれば別の政策である。これは通信の往復を一つの漠然とした信頼関係にまとめない設計だった。

送れたことは許されたことではない

RFC 1445 はアクセス制御を受信時に適用し、送信時には適用しないとした。送信側は source party、destination party、context、PDU を組み立てて送れる。しかし、それによって遠隔側の現在のアクセス表が照会されたわけではない。

受信側は段階を踏んだ。宛先パーティーが既知でローカルに実現されているか。送信元パーティーが既知か。設定された方式で認証が成立するか。コンテキストが存在するか。送信元、宛先、コンテキストに対応するアクセス行があり、その PDU クラスを含むか。

構文が正しいメッセージでも宛先が未知かもしれない。既知の宛先でも送信元が未知かもしれない。認証済みの送信元でも存在しないコンテキストを要求できる。コンテキストがあっても ACL がなく、ACL があっても Set を含まないことがある。

したがって認証と認可は一語に圧縮できない。同じ主体を知る二つの受信機が、異なる対象、コンテキスト、ビュー、行を持ち、正当に異なる判断を下すこともできる。

コンテキストが資源の境界を保持した

SNMPv2 コンテキストは、管理対象オブジェクトの集合を識別した。ローカル資源なら MIB ビューを参照し、リモート資源ならプロキシ関係を表せた。同じ subject と target でも、コンテキストが違えば許可は違い得た。

「読める」という文は、どの対象のどのコンテキストを、どのビューで読むかが決まるまで完成しない。PDU クラスが許可されても、コンテキストのビューが個々のオブジェクト範囲を制限した。

あるコンテキストでオブジェクトが見えないことは、物理的不存在の証明ではない。他のコンテキストでも見えないことや、別の主体にも権限がないことも証明しない。一つの受信側、一つの管理状態、一つの関係についての結果にとどまる。

アクセス行そのものにも寿命があった

ACL 行には aclStorageType と aclStatus があった。保存方式は volatile、nonVolatile、permanent を区別し、状態は RowStatus で表した。表に見える行が有効であること、再起動後も残ること、変更可能であることは別の事実だった。

RowStatus の一般史は既存記事の領域である。RFC 1447 に固有の意味は、将来の管理通信を裁く政策自体が管理状態だった点にある。SNMP は、次の SNMP 要求の可否を決めるオブジェクトを変更し得た。

ACL への Set が成功しても、意図した関係で次の要求が許可される証明にはならない。書き込んだ値、応答、行状態、依存するコンテキストとビューの活動状態を保存し、受信側で新しい要求を試す必要がある。永続性なら再起動後の確認も別に要る。

VACM は別の構造で関係を引き継いだ

初期の party ベース枠組みは Historic になった。RFC 2575 と、その後継 RFC 3415 は、モジュール化された SNMP 向けに VACM を定義した。security model と securityName を group に写し、group、contextName、security model、security level でアクセス行を選ぶ。read、write、notify がビューを選び、最後に個別 variableName をそのビューで判定する。

VACM は noSuchContext、noGroupName、noAccessEntry、noSuchView、notInView を区別した。結果がすべて拒否に見えても、欠けた結合点は違う。資格情報の問題と決めつければ、正しい修復先を失う。

Party MIB と VACM は同じ表ではなく、同じ保証も与えない。継承されたのは、主体名だけで権限を完成させない態度である。場所、保護条件、操作の種類、対象オブジェクトが、なお判断の座標だった。

政策の記号と実行結果を分ける

Lu Heng の running-code primacy は、仕様、実装、検証、配備、利用を別々の段階として扱う。reality layers の議論は、象徴的権威と実行可能な効果を区別する。RFC 1447 は、その見方を適用できる小さな歴史例である。

パーティー識別子は名称の層にある。ACL 行はローカル政策を表す。受信処理が政策を実行する。応答はプロトコル上の結果を残す。インターフェース、カウンター、経路が本当に変わったかは、さらに別の観測である。

既知の名前は認可の証明ではない。存在する行は active の証明ではない。受理された Set は効果や永続性の証明ではない。返された値は意味上の正しさを証明しない。各記録の射程を守ることで、初めて監査可能になる。

Party MIB 自体は歴史になった。残った教訓は、権限を人物の肩書にするより、再現可能な関係として保存した方が現実に近いということだ。

出典