要約

  • RIPE NCCはRPKIダッシュボードをOpenID Connect対応にし、現行APIキーをRIPE NCC Accessと統合したOIDCベースの鍵へ置き換える作業を始めた。公開上の状態はまだ「進行中」である。
  • 別のRPKIビーコン案では、利用予定のAPIがRIPE NCCの全アドレス空間のROAを編集できるため導入を止めた。認証された主体と、許された資源範囲は別々に証明しなければならない。

優れたアクセス制御は、入口だけを強くしない。誰が入ったかを確かめた後、その主体がどのサービスで、どの操作を、どの資源に対して実行できるかを狭く定義する。

RIPE NCCが9月17日に更新した2026年第4四半期のRPKI計画は、入口の近代化を示す。RPKIダッシュボードはRIPE NCC Accessが提供するOpenID Connectを利用する方向で更新されている。現行のRPKI APIキーをSSO統合型のOIDCベースの鍵に置き換える作業も始まり、管理用画面を追加する予定だ。実装と日程の詳細は今後のRIPE Meetingで示すとしており、完成した機能ではない。

この変更には実益がある。RIPE NCC Accessでは二要素認証が必須だ。公開されているセキュリティ方針では、APIキーは特定利用者のアカウントに結び付けられ、有効期間は最長1年で、アカウント停止や該当システムのメンテナー権限喪失に伴って無効化される。RPKIの資格情報を共通のID管理に載せれば、所有者不明の長期シークレットを減らせる可能性がある。

ただし、OIDCはOAuth 2.0上のID層である。認可サーバーで行われた認証をクライアントが確認し、属性を受け取るための枠組みであって、単独ではROAの読み取りと公開を分離せず、特定のLIR、証明書、プレフィックス集合に権限を限定しない。

OAuth側にも複数の境界がある。resourceはトークンを受け取る保護対象サービスを示し、scopeは求めるアクセスの種類を示す。近年の安全指針は、アクセストークンのaudienceを特定または少数のリソースサーバーに限定するよう求める。それでも「RPKIサービスだけで有効」と「このプレフィックスだけを変更できる」は同義ではない。後者はサービス固有の認可である。

この差を具体化するのが、同じ計画ページにあるルーティングビーコンの記述だ。研究用にRPKIの有効性を変化させる既知のビーコンが要望されたが、RIPE NCCは導入できなかった。使用するAPIがRIPE NCCの全空間に対するROA編集を許すため、それを受け入れられないと判断したからだ。今後はRISチームと別の方法を検討する。

この事例を、未公開部分の多い新しいOIDC設計への批判にすり替えてはならない。ビーコン用APIと会員向け資格情報の将来設計が同一だという資料はない。確認できるのは、RIPE NCC自身が過大な変更範囲を機能停止の理由にしたということだ。

ROAの性質を考えれば妥当な判断である。ROAは、ある起点ASがプレフィックスを広告することを暗号学的に認可し、必要なら最大長も指定する。RIPE NCCのホステッドサービスは、一つの起点AS、一つのプレフィックス、一つの最大長からなる設定を基に、オブジェクトの署名、公開、更新を担う。現在のAPIは一回の公開呼び出しで複数ROAを追加・削除できる。

既存機能には今後も活用すべき境界がある。保有していないプレフィックスへの作成は403で拒否される。ダッシュボードでは変更を保留し、影響を受けるBGP広告を確認してから一括適用できる。APIには、まだ作成していないROAの影響を調べる呼び出しもある。

必要なのは、これらを一連の別個の証跡として扱うことだ。主体の認証、トークンの受け手、操作権限、資源範囲、変更の受理、署名オブジェクトの公開、バリデーターの取得、ルーターの方針、実際のBGP観測は九つの異なる段階である。ログイン成功を経路変化の証明にしてはならない。

本稿は、Heng Luによる最小初期仕様、現実の層、インターネットガバナンスの代理問題を編集上の分析枠として用いる。RPKIに当てはめれば、初期権限を狭くし、将来判断を影響を受ける資源の局所に残すという考え方になる。RIPE NCCの公式見解を代弁するものではない。

出典