摘要

  • ARIN 表示，具体操作可以追溯到具体 API 密钥；但现行指南同时写明，密钥管理表只通过前缀和创建日期识别每把密钥。
  • ACSP 2023.15 自 2023 年 10 月以来仍为开放状态，ARIN 当时已经认可用户自定义描述有助于管理多把密钥。
  • 描述不是权限边界，不能让密钥过期、证明谁持有它或阻止滥用；它保存的是预期用途，供运营者与实际活动对照。
  • ARIN 应把描述扩展成带版本的“密钥用途回执”，连接非秘密标识、签发主体、活动类别、复核责任人和停用证据。

表里有钥匙，却没有钥匙的工作

密钥管理最棘手的时刻，通常不是创建，而是删除。创建者知道脚本叫什么、服务跑在哪里、哪个 POC 赋予权限，也知道这把密钥是长期生产工具、迁移期间的临时桥梁，还是故障时才启用的备用手段。几个月或几年后，接手者只看到一条记录。他不敢轻易停用，因为停用可能中断业务；也无法证明继续保留是必要的。

ARIN 的文档把这种信息落差写得很具体。完整 API 密钥只在创建时显示一次，之后管理表“只能通过密钥前缀和创建日期”识别它。隐藏完整秘密是正确的安全做法，但隐藏秘密与丢失用途并不是同一件事。前缀可以准确指出是哪一行，日期可以说明它何时产生，却无法说明它被授权去完成哪项工作。

这不是用途单一、生命周期很短的凭证。ARIN 自己列出的使用面包括 Reg-RWS、网络记录修改、DNSSEC、RPKI、反向 DNS、IRR 和受限报告下载。指南还说，同一把密钥可以用于多种交互，用户也可以创建多把密钥来区分不同请求；密钥不会自动到期，但可由用户停用。

于是，ARIN Online 保存了最小的数据库身份，却没有保存运营身份。“API-某前缀、某日创建”回答了“是哪把”，没有回答“为什么有”。后一问题只能交给客户自己的秘密管理器、配置文件、代码仓库、变更工单或团队记忆。如果这些外部线索使用的名称不同，或者在人员交接中丢失，ARIN 侧的记录无法帮助两边重新对齐。

社区早已提出这个缺口。2023 年 10 月 25 日提交的 ACSP 2023.15 要求允许用户为 API 密钥填写描述。提交者还谈到细粒度权限和命名服务角色，但没有把两者混为一谈：描述用于标明预期功能；权限用于限制实际能力。10 月 27 日，ARIN 回应称，这对拥有多把密钥的客户会有帮助，将把功能纳入部署计划并与其他开发事项一起排序，建议在实施前保持开放。

今天，建议页面和 ACSP 索引仍把它列为 Open，追踪记录中没有更晚的公开更新。这不能证明 ARIN 内部没有设计、排期或未发布的试验，也不能证明每个私有界面都绝对没有附加字段。可以验证的结论更窄：公开承诺尚未得到公开处置，现行公开指南仍把密钥的可见身份限定在前缀和日期。

可归因，不等于可解释

ARIN 在面向团队的密钥管理文章中强调，不应多人共享一把个人密钥。共享会把广泛控制权交给他人，也会破坏按人追踪操作的能力。ARIN 建议把 Role POC 与独立密钥结合，并说明密钥继承创建它的 ARIN Online 用户的权限，具体操作可以追溯到具体密钥。

这解决了“哪把密钥做了什么”。它仍没有解决“这件事是否属于密钥原定职责”。

假设一家机构看到某把两年前创建的密钥上周修改了一个 IRR 对象。日志可以指向密钥前缀，也可能指向认证主体。但如果清单没有用途，复核者无法仅凭这两项证据判断：IRR 修改是正常任务，还是一把原本只下载报告的密钥被扩大使用；它是得到批准的工作调整，还是迁移结束后遗留的脚本。实际活动是“发生了什么”的证据，用途描述则是“原本应该发生什么”的声明。治理发生在两者的比较之中。

声明本身不会自动变真。“生产自动化”太宽泛，“不要删除”只是恐惧的标签，“每月报告”也可能早已过期。因此，一个成熟设计不能只增加可随意覆盖的文本框。它应保存描述变更的历史，并把描述与最后使用时间、服务类别或操作类别放在同一条可复核链上。

偏差也不能被自动定罪。标注“RPKI 发布”的密钥偶尔访问另一服务，可能源自合法的运维变化；长期不活跃的密钥可能是废弃物，也可能是应急备用。系统应该把不一致交给有权限的人调查，而不是根据自由文本阻断请求。描述是一项可检验的主张，不是访问控制器。

这条边界必须写在产品里。标注“只读”不会让具备写权限的密钥变成只读；写上“六月到期”不会在六月自动使其失效；写上“IRR”也不会阻止它调用别的获准接口。若界面把文字包装成安全范围，用户得到的将是假保证。

ARIN 的其他公开项目也说明这些层次彼此独立。ACSP 2011.17 请求按操作和 POC 限制每把密钥；ARIN 曾公开评估过其工程成本与复杂度。ACSP 2024.1 请求 MFA、来源网络限制或期限。2024.3 咨询讨论把密钥放进请求头以及按 IP 范围约束。它们改变秘密暴露方式或密钥实际可做之事。用途描述改变的是复核者能知道什么。

周边能力已经向前走了

2026 年 7 月 28 日，ARIN 发布了两项与密钥密切相关的更新。第一项是把 API token 放在授权请求头中，作为优于 URL 参数的推荐方式。第二项是取消账户创建时对非人类服务账户的限制，正式接受这类账户。软件发布页记录了两项变化，相应建议也被关闭；现行 Reg-RWS 快速指南已经明确标出“API Key in Header (Recommended)”，同时仍支持旧 URL 方式。

这两项改进解决了真实问题。请求头减少秘密意外进入 URL 日志、历史和中间系统的机会。服务账户则让长期自动化拥有与员工个人不同的主体，不必假装某个人永远负责机器流程。

但传输位置不说明用途。服务主体也不说明该主体签发的每把密钥分别承担什么任务。一只服务账户可能拥有 RPKI 发布密钥、报告下载密钥和迁移密钥；如果三条记录仍只有前缀与日期，主体层更清楚了，凭证层仍然模糊。

Role POC 也不能代替用途。它影响创建者继承的权限范围，回答“凭什么有权”。用途说明回答“为何要用这项权力”。活动日志回答“实际上用了什么权力”。这三个问题相互支持，却不能互相替换。

这段时间线还提供了一个有用标准：ARIN 有能力用明确发布日期、功能说明、文档更新和建议关闭来证明工作完成。若未来关闭 2023.15，处置记录应说明描述在哪里填写、创建后在哪里显示、谁能修改、是否可搜索与导出、是否保留历史，以及活动记录是否使用同一个非秘密标识。仅写“已实施”会丢掉运营者最需要验证的边界。

从一个字段变成一份用途回执

ARIN 不必成为客户的秘密管理平台，也不需要存储主机名、仓库路径或内部值班表。它需要提供的是可靠接点：让客户声明的用途能够与 ARIN 接受的密钥和观察到的活动对应，而不暴露密钥本身。

一份足够实用的“密钥用途回执”至少应包含：

  1. 密钥前缀或其他稳定、非秘密的标识；
  2. 新密钥必填的用途描述，以及可选的 Reg-RWS、RPKI、IRR、DNSSEC、反向 DNS、报告下载等结构化标签；
  3. 签发密钥的人类或服务主体，以及权限来源的 POC 和机构上下文；
  4. 创建时间、最后使用时间，以及在安全可披露范围内的最近服务或操作类别；
  5. 客户指定的复核责任角色与下一次复核日期；
  6. 描述修改历史，包括操作者和时间；
  7. 停用时间、理由和 ARIN 不再接受该密钥的确认；
  8. 明示“用途文字不授予、不取消，也不限制权限”。

最后使用时间的价值，不是自动判断密钥“陈旧”。它把一项模糊担忧变成带日期的问题。操作类别也无须暴露每个对象的细节；只要能区分报告读取、Reg-RWS 写入、RPKI 管理或 IRR 变更，就足以帮助复核者发现预期与实际之间的缝隙。

版本历史则防止现在重写过去。迁移密钥可能后来变成生产依赖。机构可以选择签发一把新的长期密钥，也可以明确批准用途变化。无论采取哪条路，都不应直接把“迁移”覆盖为“生产”，仿佛原始决策从未存在。历史记录让复核者看见职责何时变化、由谁变化。

停用结果同样需要闭环。ARIN 已经提供停用操作。回执应记录何时停止接受密钥，以及被终止的原定用途。它不能证明客户删除了世界上每一份秘密副本，却能证明注册机构一侧的权限已经结束。客户随后可以把这个事件与保险库、程序和运行手册中的移除证据对齐。

若 ARIN 认为详细用途必须只留在客户系统，也存在可行方案：提供不可变的非秘密 ID，并让客户导出包含同一 ID 的完整活动记录。用途在客户一侧，活动在 ARIN 一侧，双方仍能可靠连接。把责任交给客户却不给连接键，只会让证据碎片化。

不需要先发生事故

现有资料没有统计 ARIN 客户有多少把闲置密钥，没有证明谁因不敢停用未知密钥而遭受损失，也没有披露泄漏、越权、停机或攻击。文章不能把可能机制写成已经发生的事实。

但制度问题不需要等待事故才能成立。ARIN 的文档已经说明三件事：密钥可以长期存在，可以服务多类工作，可以把操作追溯到具体密钥。与此同时，公开管理表没有记录用途。这样一来，判断保留或停用所需的解释成本被推给客户，而且越晚越昂贵。

关键问题因此不是“描述能否防住攻击者”。它不能。问题是：当注册机构接受自动化权力时，是否也应保存一份足以复核该权力的用途声明。ARIN 管理的是依靠准确性与持续性产生公共价值的号码资源记录。它的凭证治理也应让权限不仅能工作，而且在多年后仍能被解释。

旧密钥如何进入新制度也需要明确。若描述只对新创建的密钥必填，最老、最容易失去上下文的权限仍会空白；若系统根据历史操作自动猜测用途，又会把推断伪装成签发时的事实。更诚实的办法是把旧行标成“用途未确认”，要求客户在调查后记录当前用途、确认人和确认日期。这不声称恢复了最初意图，只是为今天继续保留权限建立一项新的、可追责的决定。

结构化标签也不能单独承担解释。RPKI、IRR、报告或网络管理便于搜索与汇总，却不能区分生产、测试、应急和迁移。最佳组合应是少量可复用类别加一段简短自定义说明；不愿披露内部系统名称的客户，可以填写责任角色或内部控制编号。目标不是让 ARIN 收集客户架构，而是让下一位复核者有一条能验证的入口。

如果 ARIN 最终决定不实现描述，公开处置同样有价值。它可以明确由客户外部清单承担用途，并说明固定 ID 与活动导出怎样支持连接。一个边界清楚的否决，有时比长期 Open 更能指导运营。状态记录的责任不是永久保存期待，而是说明由谁保存哪一种证据。

用途信息也需要恰当的可见范围。它不必进入公开 Whois，但不能只让有权停用密钥的人查看，否则审计者和交接团队仍无法使用。把查看、编辑与停用权限分开，并保存修改者身份，可以在保护内部项目名称的同时维持可验证性。用途证据可以是私密的，却不能对承担责任的人不可见。

描述质量也不应按字数判断。如果必填要求只产生“生产”“自动化”之类套话，清单依然无法支持决定。更有效的标准是：复核者能否据此找到责任角色、预期服务和退出条件，并把它与观察到的操作比较。好描述不必长，但必须把人带到下一项可验证证据。

来源