要約

  • RFC 10065は、YANGで表すアクセス制御リストにグループ照合と時間条件を加え、ユーザーグループIDを運ぶRADIUS属性を定義する。
  • そのIDだけでは、誰がグループを割り当てたか、パケットの条件にどう対応するか、各実行点が正しいルールを受け取ったかは分からない。

分析

モバイル端末、VPN、仮想マシンの移行、一時IPv6アドレスがある環境では、IPアドレスは人や端末、ワークロードの役割を長く表し続けない。アドレスや5タプルに基づくACLは引き続き使えるが、端末の移動に合わせた更新が必要になる。RFC 10065は、同じポリシーを適用するエンドポイントをグループとして扱い、この更新負荷を抑える方法を示す。

同RFCはRFC 8519のYANG ACLモデルを拡張する。ietf-ucl-aclモジュールでは、ユーザー、デバイス、アプリケーションのグループを定義し、そのIDをACLの送信元または宛先の照合条件にできる。また、effective-scheduleで期間または繰り返しを表し、RFC 9922の共通スケジュールモデルを利用する。見落としやすい既定動作がある。スケジュールを設定しなければ、ACLエントリーはただちに適用され、その後も常時有効になる。

ユーザーの認証経路では、新しいRADIUS属性User-Access-Group-IDがグループIDを運ぶ。RFC 10065は拡張属性241.12を割り当て、値を文字列とし、グループIDは最大64オクテットと定める。認証後のAccess-Acceptには一つ以上のIDを含められる。Access-Requestで希望するIDを示すこともできるが、サーバーはその希望を受け入れる義務を負わない。属性はChange-of-Authorization要求やAccounting-Requestにも現れ得る。後者は、NASが属性を受け取り、ポリシーを適用中であることを確認する用途に使える。

そのRADIUSメッセージは、長い制御経路の一部分にすぎない。AAAサーバーがローカル設定の基準でユーザーを分類する。コントローラーはグループIDをパケットフィールドへ対応づけ、従来型のアドレスACLや5タプルACLをポリシー実行点へ配布できる。別の構成では、装置自身がグループIDを照合する。コントローラーを使えば、各装置に専用のグループ処理を求めずに済む一方、更新をすべての装置へ間に合うよう届ける必要がある。装置側で処理すればコントローラーとの頻繁なやり取りを減らせる可能性があるが、ソフトウェアやハードウェアの対応が必要になることもある。NASが直接実行点になる構成では、転送性能への影響も評価対象になる。

ここで境界を混同してはならない。RFCが定義するのはインターフェースであり、企業のID管理権限ではない。認証方式、グループに登録する根拠、カプセル化環境でグループIDをパケットフィールドへ写す方法は規定しない。RFCは適切なマッピング設定を求め、RADIUSなど複数の仕組みを使う場合に一貫性を保つよう注意を促す。したがって、グループ名そのものは身元や権限の独立した証明にはならない。その意味は、割当側と解釈側のローカルな仕組みに依存する。

設定面も重要な管理対象だ。グループ一覧、ACLの照合条件、スケジュールはいずれも変更可能なYANGデータである。無権限の変更で存在しないグループが作られたり、必要なグループが削除されたりすれば、許可すべき通信を拒否し、拒否すべき通信を通すおそれがある。スケジュールの改変はサービス停止を招き、読み取り権限の漏えいはルールの適用時刻を明らかにする。RFC 10065はNETCONFまたはRESTCONFの安全な通信と相互認証を求め、NACMを使って操作者ごとの操作権限を制限する方法を示す。RADIUSについては、クライアントとサーバーの信頼関係を前提とし、IPsecやTLSは任意の保護として説明している。

RFC 10065の位置づけはProposed Standardであり、導入済みであることを示す証拠ではない。移動する端末や時間依存のルールを扱う共通の制御語彙は整った。今後の運用評価では、認証、グループ割当、ポリシーへの対応づけ、ルール配布、実際の通信確認が一続きになっているかが焦点となる。

出典