摘要

  • RIPE NCC 正在让 RPKI 控制台使用 OpenID Connect，并已开始以接入 RIPE NCC Access 的 OIDC 凭证替换现有 RPKI API 密钥；项目状态仍为“进行中”。
  • 同一份计划披露，RIPE NCC 未部署一项 RPKI 路由信标，因为拟用接口能够编辑其全部地址空间的 ROA。身份是否现代化与权限是否足够窄，是两份不同的证明。

基础设施自动化最危险的误解之一，是把“知道操作者是谁”当成“知道操作者只能做什么”。前者是身份问题，后者还要回答动作、资源、环境和审批边界。

RIPE NCC 的 2026 年第四季度 RPKI 计划给出了一个少见而清晰的现实样本。该页面在 9 月 17 日更新，称 RPKI 控制台将通过 RIPE NCC Access 使用 OpenID Connect；团队也已开始用接入同一单点登录系统的 OIDC 凭证替换现有 RPKI API 密钥。未来控制台会提供管理入口，具体实现和时间安排将在后续 RIPE 会议说明。当前公开状态只是“进行中”，不能写成已经上线。

迁移有明确价值。RIPE NCC Access 已强制使用双因素认证。其公开安全政策还规定，API 密钥绑定具体用户，最长有效期为一年；如果单点登录账户停用，或用户失去相关业务系统的维护者身份，密钥也会被停用。把 RPKI 凭证纳入统一身份生命周期，可能减少遗忘的长期秘密，并使责任归属更清楚。

但 OIDC 的标准定义是 OAuth 2.0 之上的身份层。它用于验证授权服务器完成的认证，并向客户端提供身份声明。这个名称本身并不说明一个自动化主体能否发布 ROA、能否只做预演，也不说明它的权限止于某个 LIR、证书或前缀集合。

OAuth 体系内部也要分层。资源指示符说明令牌准备交给哪个受保护服务，scope 说明申请何种访问。安全最佳实践要求把令牌 audience 限制在特定或少量资源服务器。然而，“只对 RPKI 服务有效”仍不等于“只对这组前缀有效”。后一个边界必须由 RPKI 应用自身建立并留下证据。

同一份季度计划中的路由信标更能说明问题。社区希望建立一项可改变 RPKI 有效状态的已知信标，供研究人员使用。RIPE NCC 表示暂未加入，因为拟使用的 API 可以编辑 RIPE NCC 全部地址空间的 ROA，这种能力不可接受；团队将与 RIS 继续寻找方案。

这里必须保持事实边界。信标接口并不等于即将面向成员的 OIDC 凭证设计，公开资料也没有证明新凭证权限过宽。它所证明的是另一件事：RIPE NCC 已经把“修改范围过大”视为暂停便利功能的充分理由。未来设计最值得检验的，正是这一原则是否被落实为可检查的权限合同。

为什么需要如此谨慎？ROA 不是普通标签。它是经过签名的 RPKI 对象，用来授权某个起源 AS 宣告一个或多个前缀，并可限定最大前缀长度。RIPE NCC 托管服务把每项配置表示为一个起源 AS、一个前缀和一个最大长度，再负责签名、发布和续期。现有 API 的一次发布请求可以同时新增或删除多个 ROA。

现有系统也提供了可以继承的安全结构。对调用方不持有的前缀创建 ROA，文档称会返回 403。控制台可把变更留在待处理状态，展示受影响的 BGP 宣告，并在审核后原子化应用一组变更。API 还可以评估一个尚未创建的 ROA 会如何改变已知宣告。

这些功能应该被理解为一条控制链，而不是一个“登录成功”的结果。先确认人或服务身份，再验证令牌受众、动作权限和资源范围；随后记录服务接受或拒绝了哪项变更；之后分别观察签名对象是否进入仓库、验证器是否获取、网络是否启用 ROV、本地路由策略如何处理，以及 BGP 观测最终出现什么。任何一层都不能替代下一层。

本文采用 Heng Lu 关于最小初始规范、现实层级与互联网治理代理问题的论述作为编辑分析框架。应用到 RPKI，它主张初始权限应足够窄，后续决定应留在受影响资源所在的局部，并把身份、授权、签名对象与网络结果分开。这不是 RIPE NCC 的政策表述。

来源