摘要

  • IANA 的登记分配与维护系统（RAMS）公开 SOC 3 报告覆盖 2024 年 12 月 1 日至 2025 年 11 月 30 日。审计师认为，ICANN 关于安全性、可用性与处理完整性控制的陈述，在所有重大方面得到恰当呈现。
  • ICANN 另称，同期保密的 RAMS SOC 2 审计于 2025 年 11 月发现一项例外，并已立即采取补救措施。公开材料没有指明是哪项控制；详细报告交给依据 ICANN、IETF 与五个区域互联网注册管理机构相关协议履职的监督方。

一份报告说“通过”，一则公告说“例外”

审计的公共版本很整洁。十二页的 SOC 3 报告列出审计范围、管理层陈述和审计师意见。审计期从 2024 年 12 月 1 日到 2025 年 11 月 30 日；意见签署于 2026 年 5 月 12 日。审计师认为，ICANN 关于 RAMS 控制有效性的陈述，在所有重大方面公允。这里的标准是安全性、可用性和处理完整性，不是一张给互联网全部制度盖章的空白授权书。

一个月后，ICANN 的发布公告多了一行。同期 SOC 2 审计在 2025 年 11 月发现一项例外；ICANN 说发现后立即采取措施补救。这行话并未推翻公开审计意见。意见按重大性评价整套控制与管理层陈述，例外则是更细的审查结果。两件事可以同时成立。问题在于公众读得到例外的数目，却无从辨认例外的地址。

是哪一道访问权限，哪一次审批记录，还是哪项恢复演练？公开材料没说。把它猜成资源错配、根区故障或客户损失，只会把真实的空白换成虚构的事故。审计最需要的下一项公开事实很具体：涉事控制属于哪一类，补救何时完成，复测由谁执行、结果如何。ICANN 已给出“采取措施”的起点，尚未给出公众可核查的终点。

IANA 审计项目说明交代了这道门的设计。SOC 3 公开发布；SOC 2 保密，提供给相关监督机构，以履行 PTI 与 ICANN 的合同、ICANN 与 IETF 的备忘录，以及 ICANN 与五个 RIR 的编号服务协议。细节并非消失，而是被分配给拥有正式监督关系的读者。普通读者得到结论，合同关系中的读者得到更细的检查资料。谁有能力追问例外，因而也由文件分发规则决定。

审计从申请窗口开始

RAMS 不是泛指互联网治理。公开报告把根区管理系统 RZMS 和请求跟踪系统 RT 列为范围内工具。前者支持域名根区变更，后者记录申请、往来与状态；系统服务的对象分为域名、互联网编号资源和协议参数三类。审计覆盖的流程从一份分配或指派独特标识符的申请开始，到获批准的变更出现在公开登记簿结束。

这段流水线有真实价值。公开记录能否与获批申请一致，处理能否按服务约定及时完成，谁能修改系统、谁能批准操作，都会影响互联网共同使用的标识符。一个登记簿再权威，若申请抵达后的传递、审批或发布不可靠，也会制造相互冲突的事实。审计师检查这一层，值得获得相应分量的信任。

但规则在申请抵达之前就已形成。报告明说 PTI 执行 IANA 服务所依据的政策，政策由不同社群制定。ICANN 支持域名与编号领域的政策工作；IETF 制定协议规范和参数管理规则。公众可以凭审计报告判断处理系统是否在既定承诺下运作，却不能把它拿来代替对规则本身的授权追问。某条资源分配条件是否正当，要查政策制定记录；某项已批准申请是否按规则入簿，要查处理链。两本账各有作者。

恰恰因为“ IANA 审计通过”听起来分量十足，这条边界容易被挪走。有人质疑规则的权力来源，机构就拿系统审计作答；有人问一条记录的命运，回应却是整体控制意见。错位的答案并不因审计师签名而变得贴题。2025 年报告的强处在于范围明确：它测试所描述系统的控制，不替上游每一项政策签署授权书。

报告还标明另一道边界：机房托管和管理服务的分包方。ICANN 列出预期由分包方实行的补充控制，审计师明确表示没有检查这些分包方服务及其控制的设计和运行。这里没有任何已发生事故的证据；这里有的是一张清楚的责任地图。整套服务依赖哪些环节，哪一份审计覆盖哪一段，读者可以照图继续要证据。

公开窗口开了两年

RAMS 公开 SOC 3 是新近增加的安排。ICANN 2025 年的公告称，上一轮首次在既有 SOC 2 之外公布 SOC 3。覆盖 2025 年的报告因此是第二份公开版本。这个变化值得肯定：审计师意见、系统范围和主要服务承诺终于能由社会直接阅读，不必只看机构新闻稿复述。

公开窗口的边框也随之露出来。2026 年的公告承认一项例外，公开 SOC 3 却没有提供控制名称和复测结果。保密报告可能包含细节，但普通读者无法据此知道补救是否已经经过独立验证。公开一段有限的关闭记录，便能把“立即处理”的说法变成可复核的时间线：发现时间、控制类别、修补日期、再测试与登记数据是否需要纠正。保护具体账号、设施和安全配置，丝毫不妨碍公布这种粒度的结果。

IANA 的绩效页面提供另一种公开证据：服务水平、根区操作、编号与协议参数处理统计。它们适合追踪某类事务的及时性和处理量。无名的 SOC 2 例外却无法靠一张好看的绩效图定位。没有控制名称，任何把“百分之百按期完成”直接等同于“那项例外已经复测关闭”的推断，都跳过了最关键的接缝。

还要分开两项审计。ICANN 同期宣传根区 DNSSEC 密钥管理连续十六年获得无例外审计结果。那是根密钥 KSK 系统的 SOC 3；这篇所讨论的一项例外，属于 RAMS 的 SOC 2。把两者塞进“ IANA 审计”的大口袋，会让密钥系统的好成绩替登记系统遮住问题。恰当的机构自信应敢于逐个系统报成绩，也逐个系统交代问题。

谁来证明修补完成

详细控制报告保持机密，有可以理解的安全理由。具体访问设计、测试步骤和内部配置不宜随意公开。合同监督方收到 SOC 2，正因为它们拥有审查运营者的正式位置。由此产生的公共责任同样具体：当运营者主动宣布一项例外时，能读细节的人应检查那项补救，并让外界看到不泄密的关闭证据。

这不是把审计文件全部摊上网的要求。控制类别、修补日期、复测状态、公共登记记录是否受影响，四项简明事实就足以让问题有门牌。若没有任何登记项要更正，给出可归属的判断；若复测尚未完成，给出下一次检查的日期。新闻稿里的“立即行动”才能落到系统运行的证据上。

公开意见与私人例外之间的距离，本来可以成为审计制度的成熟之处：敏感细节交给有责任的读者，公众拿到足以评判闭环的摘要。现在公开材料停在半程。它告诉公众有人看见了异常，也有人动手修；谁验证修复的结果，仍被锁在门后。