要約

  • SNMPv3のcontextEngineIDとcontextNameは管理情報の集合を指し、securityNameは主体を表す。VACMは、その主体がどのオブジェクトを読み、書き、通知で受け取れるかを別途判断する。
  • 検証可能な運用記録には、プロトコル上の主体、コンテキスト、アクセスビュー、応答に加え、外部の変更承認と意図した実状態が生じた証拠が必要になる。

同じOIDは多数の機器に存在する。一台の機器の情報が複数コンテキストに現れることもあり、proxyが要求を受けて別のSNMP entityへ転送する場合もある。それでも画面に「SNMP target」と一行だけ表示すれば、有効な応答を誤った資産に結び付けたり、認証済みの技術アカウントを変更を承認した人だと誤認したりできる。

RFC 3411はSTD 62を構成するStandards Track文書として2002年12月に公開された。著者はDavid Harrington、Randy Presuhn、Bert Wijnenの三人であり、共同成果として扱う必要がある。この設計が複数の名前を使うのは冗長だからではない。engine、principal、context、security、access controlが、それぞれ異なる事実を扱うからである。

engineはprincipalではない

SNMP engineはメッセージを送受信し、メッセージ処理モデルを動かし、セキュリティサービスを提供し、アクセス制御を呼び出す。一つの管理ドメイン内では、snmpEngineIDがengineと、それを含むSNMP entityを一意に識別する。ただし一意性はドメイン内に限られる。別のドメインが同じ値を持ち得るため、世界共通の資産番号でも所有者証明でもない。

principalは、サービスが誰または何のために提供されるかを表す主体である。RFC 3411は、特定のSecurity Modelに依存しない可読文字列securityNameでprincipalを表す。モデル固有のIDをこの共通名へ変換するのは各Security Modelの責任だ。可読だからといって人名とは限らない。service account、role、共有運用IDもprincipalになれる。

従って、証拠は三段に分かれる。EngineIDはドメイン内のprotocol engineを示す。securityNameはSecurity Modelが提示したprincipalを示す。実際に端末を操作した人、承認した責任者、組織上の権限は別の記録で示さなければならない。前二者を組み合わせても、人の意思は自動的には生まれない。

contextが名付けるのは管理情報である

SNMP contextは、一つのSNMP entityからアクセスできる管理情報の集合だ。複数機器、一台の一部、複数機器の一部を含むことができるが、定義上は一つのSNMP entityが持つ部分集合である。特定の情報を指すには、contextEngineID、contextName、object type、instanceの四座標が要る。

contextEngineIDとcontextNameの組は、管理ドメイン内で一つのcontextを曖昧なく指す。一方、RFC 3411は異なる複数の組が同じcontextを指すことも認める。つまりaliasが存在し得る。contextは管理情報空間へのlocatorであり、不変の機器シリアルでも、運用者の識別子でもない。

scopedPDUにはcontext engine ID、context name、PDUが入る。これは「どの情報空間か」を運ぶ器である。「どのprincipalのためか」はsecurity parameter側に残る。監査がcontextをactorとして扱えば、access controlが動く前にwhereとwhoを混同してしまう。

message authenticationの次にview authorizationがある

RFC 3414はSNMPv3のUser-based Security Modelを定義する。対象はmessage authentication、privacy、timelinessと限定的なreplay protectionである。完全性、秘匿性、時間窓の確認はいずれも重要だが、そこで証明されるのは設定された鍵関係の下でのメッセージ属性である。

Security Modelは、security model、principalの表現、到達したsecurity levelを後段へ渡す。どの管理viewを許すかは選ばない。認証に成功したprincipalが、指定contextの指定objectにこの操作を行えるかは、まだ答えられていない。

その判断を具体化するのがRFC 3415のView-based Access Control Model、VACMである。VACMはsecurityModelとsecurityNameの組をgroupへ写像する。Access Control moduleはsecurityNameが必要に応じて既に認証されたと仮定し、自身では再認証しない。認証済みという状態を、別の判断の入力として受け取る。

権限はsecurity level、context、view typeによっても変わる。read-view、write-view、notify-viewは別々だ。interface counterを読めてもinterfaceを停止できるとは限らず、一つのsubtreeを書けても全MIBや全notificationへ広がらない。対象OIDも判断材料のままである。

isAccessAllowedの入力にはsecurityModel、securityName、securityLevel、viewType、contextName、variableNameが並ぶ。結果はaccessAllowedだけでなく、noSuchContextやnotInViewなどを区別する。「認証成功」という一行だけを残すと、拒否を説明できる入力と結果が失われる。

proxyは受信場所と情報の場所を離す

RFC 3413が定義するSNMP applicationの一つに、任意実装のProxy Forwarderがある。特定のcontextEngineID/contextNameに対するrequestやnotificationを別のSNMP entityへ転送できる。transport connectionを受けたengineと、管理情報が実在するentityは同一とは限らない。

このindirectionを監査するには、incoming peer、変換後のsecurity principal、受信context、proxy rule、outgoing destinationとcontext、二つのrequestの相関、各区間のerrorを残す必要がある。proxy経由のResponse-PDUは連鎖したprotocol transactionの証拠であり、名指しされていない人が下流機器を直接操作した証拠ではない。

proxyの運営者、資産所有者、viewを設定するteam、自動化を起動した個人が別組織である可能性もある。contextはその経路を指定できるが、複数の責任主体を一人のoperatorへ圧縮しない。

EngineID discoveryは権限発見ではない

RFC 5343は、適切なcontext engine identifierを発見する仕組みをRFC 3411へ追加した。applicationが値をまだ知らないとき、well-knownなlocal値を使い、scoped requestに必要なEngineIDを取得できる。

成功したdiscoveryはprotocol addressingの不明点を解く。しかし、発見したengineが人の意図した資産か、特定組織の所有物か、そのprincipalがcontextを利用できるかは証明しない。identifier discovery、inventory照合、authorizationは別のreceiptである。

EngineIDの変化は、交換、復元、再設定、経路変更、異常のいずれでも起こり得る。調査を始めるsignalではあるが、侵害を断定するresultではない。値が変わらなくても、software、owner、policy、authorized peopleの継続性までは証明できない。

成功応答の後にも現実確認が残る

GETのResponseは、ある時刻にagentが指定contextのobjectについて何を返したかを示す。sensorの鮮度や物理世界との一致には追加観測が要る。SETの成功応答はprotocol acceptanceを示せるが、actuatorの動作、再起動後の保持、依存systemの収束、後続processによるrollbackまでは保証しない。

完全なreceiptは二つのplaneを結ぶ。SNMP側ではendpoint、message-processing model、Security Model、元のsecurity ID、securityName、security level、context pair、OIDとinstance、read/write/notify、VACM groupとview、proxy mapping、responseを記録する。governance側では承認者、許可時間、意図した結果、rollback条件、変更後のstate observationを記録する。

David Harringtonの共同設計が与えたのは、すべての現場が既にこの記録を持つという保証ではない。一つの名前が別の役割を奪わないための語彙である。contextは情報を場所付け、securityNameはprincipalを表し、viewはprotocol accessを決める。人のauthorityと運用上のeffectには、それぞれ独立した証拠が必要だ。

情報源