要約

  • RFC 10065は2026年10月、Proposed Standardとして公開された。IETFのACL用YANGモデルを拡張し、端末グループによる照合と、一定期間または繰り返し予定に基づくルールの有効化を定める。
  • RADIUSの User-Access-Group-ID 属性により、認証済みユーザーのグループIDをポリシー連携に載せられる。IDをパケット項目や機器側の処理へ結び付ける作業は、各運用に残る。

ネットワーク規則にも営業時間ができる

保守用アカウントが90分の作業時間中だけ管理用サブネットへ接続できる場面を考えよう。従来のアクセス制御リスト（ACL）はアドレスやポートで照合する。RFC 10065は、端末がどのグループに属するか、そしてアクセス制御エントリーをいつ有効にするかを記述する手段を加えた。規則には固定の期間も、繰り返しの予定も設定できる。スケジュールを設定しない場合、そのエントリーは直ちに有効となり、常時適用される。

保守用アカウントなら、90分の作業枠が終わった時点で管理用サブネットへのアクセスも閉じるかが焦点になる。時間を入れずにテンプレートを複製すればACEは直ちに、常時適用される。グループの対応がずれていれば、時刻が正しくても別の端末に管理用アクセスが残り得る。運用側が確かめるのは時計だけではない。

RFC 10065は、IETFの既存ACLモデルを拡張する。User-group-based Control Listモジュールは、送信元または宛先の端末グループIDで照合し、個々のエントリーに日付と時刻の条件を付けられる。時間条件はRFC 9922の二つの形式を使う。特定期間か、繰り返し予定だ。必要に応じ、共通モデルにタイムゾーン識別子も指定できる。

人のアクセスについては、RADIUS属性 User-Access-Group-ID（241.12）を定義した。ユーザー認証後、RADIUSサーバーは Access-Accept で一つ以上のグループIDを返せる。Access-Request に希望値として含めることもできるが、サーバーがその希望を受け入れる義務はない。ログイン要求が自分の権限を選ぶ仕組みにはなっていない。

ラベルの先に、長い連携がある

ログインからパケットまでは複数の段階を通る。ユーザーはNetwork Access Server（NAS）で認証され、認証・認可・課金サーバー（AAA）がグループを割り当てる。その後、コントローラーかポリシー実行点がグループを実際の通信に結び付ける。RFC 10065は大きく二つの方法を示す。コントローラーがグループをIPアドレスや5タプルなどのパケット項目へ対応付け、実行点に従来型のACLを設定する方法。対応するソフトウェアやハードウェアがあれば、機器がグループIDを直接照合する方法だ。

標準は、グループIDとパケット項目の対応付けも、コントローラーへ通知する具体的な手順も定めていない。複数の仕組みが共存する場合、対応付けの一貫性を運用側で確認するよう明記している。分類に使う属性が変われば、ユーザーのグループも変わり得る。正しいRADIUS応答が一度返ったからといって、IDの対応関係が固定されるわけではない。

選択肢は実務に直結する。コントローラーで変換すれば、既存機器は見慣れたアドレス規則を使い続けられるが、ID、アドレス、ポリシーの変化を追う必要がある。機器がグループを直接照合すれば、人やワークロードの移動に伴うコントローラー更新を減らせる可能性がある一方、機器の対応能力が必要で、転送性能に影響することもある。RFC 10065は、一部機器にソフトウェアまたはハードウェアの更新が必要だとする。採用率や性能測定値は示していない。

時間フィールドは管理上の境界も作る。RFC 10065は、権限のない書き込みによってグループ構成、照合条件、スケジュールが変更される危険を挙げる。読み取りから有効時間が分かれば、攻撃者はルールが動く時間を絞り込める。ACLのそばに時計を置くのは便利だが、誰も設定を管理しない時計は別の侵入経路になる。

次に必要なのは、コントローラーや機器が対応するグループ照合・スケジュール機能の宣言と、返されたグループ、設定されたルール、時間帯の開始・終了時における状態を示す追跡記録だ。それまではRFC 10065は、時間付きグループポリシーを記述する共通語彙を提供する。対応付けと適用は運用者の稼働中システムに残る。

出典