摘要

  • 密钥值不可读，并不自动决定旁边测试动作的访问权限。对正常启用 NACM 的普通会话，调用者须能读取定位动作的全部祖先数据节点实例，并拥有动作执行权限；只有匹配规则未裁定执行请求时，才适用标准值为允许的默认执行设置。RFC 8341
  • 一次布尔匹配可以支持范围明确的本地核验，不能证明实际报文认证、对端接收或轮换完成。旧、新密钥重叠期间，正常流量仍可能依赖旧密钥；调用身份、授权依据与结果所支持的决定，需要各自留下可解释的记录。RFC 8967

一次调用，得到的是比较结果

RFC 9647 第 2.3 节在密钥集合下定义具体密钥对象，其中包括名称 name、发送用途标志 use-send、验证用途标志 use-verify、算法 algorithm 和密钥值 value。密钥值不可读，value 叶节点带有 nacm:default-deny-all。同一密钥对象内还定义了嵌套动作 test：调用者提供二进制 test-string 和候选 mac，实现使用该对象配置的密钥与算法在本地计算，再返回布尔型 indication。输出既没有密钥字节，也没有本地计算出的 MAC。RFC 9647，第 2.3、4 节

这里存在一种具体而有限的使用权。运维人员可以在不知道密钥内容的情况下，请求设备用密钥完成一次比较。他已经提供待比较的候选值，接口只告诉他是否相等。因而，获得调用权意味着可以向这把密钥提出受接口语义限定的问题；这个权限本身值得分配、复核和追溯。

这样的结果必须带着它的条件一起阅读。真值对应的是本次所选对象、当时配置的算法、提交的测试字符串及候选 MAC。它不会自动证明对象符合最初的配置意图，也不会说明准备候选值的流程是否正确。如果测试依据与待检查配置出自同一个未经核验的准备环节，两者相符可能只是共同沿用了同一项错误假设。这是对证据独立性的判断，并非报告某次测试发生了错误。

假值同样有边界。它表明这次比较不匹配，却不能独自确定问题出在密钥、算法、所选实例、测试字符串还是候选值。授权拒绝则说明调用未获准；调用未完成时，不能补写一个比较结果。把这些状态分别记录，才能决定下一步是复核权限、核对测试依据，还是继续验证。

兄弟叶节点的保护，不能代替动作授权

动作调用有自己的准入条件。RFC 8341 第 3.1.3 节 要求调用者对定位该动作的全部祖先数据节点实例具有读取权限，并对动作本身具有 exec 执行权限。这里讨论的是 NACM 正常启用时的普通会话。祖先读取与动作执行须同时成立，任何一个条件不足，都不能仅凭另一个条件认定获准调用。

这一规则落到 Babel 模型上，须沿着动作所属的路由协议实例、Babel 容器、密钥集合和具体密钥实例等祖先节点核验。value 与 test 位于同一密钥对象内，前者是后者的兄弟节点，不在动作的祖先链上。因此，value 的默认拒绝保护本身既不授权，也不拒绝 test。能读取定位对象所需的祖先实例，也不等于必须能够读出该对象内的密钥值。RFC 9647，第 2.3 节；RFC 8341，第 3.1.3 节

接下来才是执行规则如何裁决。RFC 8341 第 3.4.5 节结合会话身份及适用组，按配置顺序查找匹配规则；模块、路径和访问操作都参与匹配，指向上层节点的路径也可能覆盖其后代动作。首个匹配规则决定允许或拒绝。因此，搜不到一条专门写着 test 的规则，不能据此判断该动作没有受到规则约束；看到某处有拒绝规则，也不能跳过顺序与适用范围便认定它会生效。RFC 8341，第 3.4.5 节

只有没有匹配规则裁定这次执行请求时，才进入 exec-default；第 5.1 节列出的标准默认值是 permit，即允许。默认值不会推翻已经匹配的执行拒绝，也不会取消祖先实例的读取条件。由此能够提出的是一项有效权限核验任务：检查具体会话在具体对象上最终获得什么裁决。它不支持“所有人都可以调用”的说法，也没有证明 NACM 被绕过或任何部署存在缺陷。RFC 8341，第 3.4.5、5.1 节

谁决定访问，须落到具体身份与具体对象

组织可以指定某个岗位负责诊断，但岗位名称不能直接回答服务器会不会允许调用。有效权利取决于会话被识别为何种身份、适用哪些本地或启用的外部组、祖先实例是否可读，以及执行规则如何匹配。RFC 8341 第 5.1 节特别关注身份映射的唯一性、正确性以及规则顺序。要回答“谁能测试”，就须把这些条件落到实际请求上。RFC 8341，第 3.4.5、5.1 节

据此进行治理分析，决定权至少有两个层面。业务上，需要有人说明哪些任务有理由调用某把密钥；技术上，需要有人把这个范围落实到访问策略及身份映射，并解释实际裁决。两者之间的交接不能只是一句“给诊断账号权限”。交接应当指出被授权的对象、任务目的，以及授权结束或需要重审的条件。这些是组织设计选择，不是 RFC 为企业指定的岗位安排。

有效权限评估还须区分预期规则和已生效权利。只审阅一份角色说明，无法确认某个服务账号实际使用哪种会话上下文；只看到一次允许响应，也无法判断该响应来自预期的明确许可，还是没有匹配规则后的默认裁决。两种路径都可能符合访问控制程序，但它们对维护责任的含义不同：前者有可指出的授权条目，后者要求组织说明为何接受这项默认设置所覆盖的调用范围。

因此，可审查的结论应当足够具体，例如某类身份在某个密钥实例上是否满足祖先读取和动作执行条件，以及判断依据对应哪个配置时点。将账号称为“只读”或将密钥称为“受保护”，都不能代替这样的结论。读取、写入与执行分别控制什么，需要在该账号真实使用的路径上得到解释。

名称和用途标志，各有自己的证明范围

RFC 9046 第 3.8 节用名称标识无法读取密钥值的对象；use-send 表达是否用该密钥为发出的 Babel 报文计算 MAC，use-verify 表达是否用它验证收到的报文。这些字段提供对象识别和报文用途语义。密钥归谁负责、某个人能否读取数据、某个会话能否执行管理动作，则是另外的问题。RFC 9046，第 3.8 节

下表按决定所需的证据区分这些含义。其用途是防止一项有限观察在流转中被赋予额外证明力。

所见事实 可以支持的判断 仍须另外回答的问题
名称标识了一个密钥对象 本次讨论或请求指向哪个管理对象 谁负责该对象，记录对应哪个配置时点
use-send 或 use-verify 已设置 该对象被配置为何种报文用途 所需的真实报文是否确实使用并通过了相应密钥验证
运维人员无法读取 value 该人员不能经该读取路径取得密钥值 其会话是否能够执行 test
一次测试调用获准 该请求通过了所需访问控制裁决 授权范围是否符合任务目的，谁批准这种范围
一次比较返回真值 此次输入与本地计算相符 候选依据是否可信，下一项决定还需要什么证据
重叠期内流量正常 有与流量状态有关的观察 正常状态是否仍依赖旧密钥，能否批准旧密钥退出

其中，字段及动作语义依据 RFC 9647 和 RFC 9046，重叠轮换依据 RFC 8967；责任归属和决定依据属于本文的治理分析。

合法核验需要可用权限，也需要可信依据

这项动作有合理的配置与轮换用途。RFC 9046 第 3.8 节将测试描述为检查密钥和算法能否产生预期结果的操作。组织可以据此设计一种分工：由受信任的准备环节提供测试字符串与候选 MAC，诊断人员获得针对所需实例的调用权限，核验人员再把返回值与具体任务关联。诊断人员无须为完成这一步而读出设备内的密钥。RFC 9046，第 3.8 节

这种安排的价值，在于把必要的诊断能力交给需要完成任务的人，同时使结果的用途保持明确。例如，本地比较相符可以支持继续后续验证；不相符则可以支持先核对所选对象和测试依据。批准这类下一步时，需要说明已经缩小了哪部分不确定性，以及哪些条件仍然没有被观察。

准备环节也要对比较依据负责。若无法解释候选 MAC 从何而来、对应哪种算法和哪项配置意图，即使返回真值，审查者仍可能只得到一个无法连接到原始要求的结果。让诊断人员重复更多次同样的比较，不能自行补上这个缺口。组织需要保存的是依据与任务的关系，而不只是把“通过”次数累加。

访问过宽的成本同样具体：更多身份可以要求受保护密钥参与运算，授权理由、用途约束和调用归因的范围随之扩大。这个判断不需要假设有人已取得密钥或造成攻击。即便接口严格只返回布尔值，组织仍须能够说明为什么这些身份需要这项能力。

访问过窄则可能使合法验证反复等待少数高权限人员，延误配置核验或轮换调查。若组织不提供可用的受限诊断路径，工作压力还可能使借用高权限账号、要求他人代跑却不留任务关联等做法变得有吸引力。这是可能出现的激励后果，并非对任何团队现状的描述。授权设计需要衡量可完成任务的权限范围与可承担的监督成本。

布尔输出与时间侧信道分别需要处理

RFC 9647 第 4 节指出，应当控制对测试动作的访问，并提醒响应耗时等侧信道可能间接透露信息。它使用的规范强度是 SHOULD：实现应采用常量时间方式，比较调用者提交的 MAC 与本地生成的 MAC。这项建议针对比较步骤，不能被扩大为整个管理请求的处理时间恒定，也不能被当作已经观察到信息泄漏的证据。RFC 9647，第 4 节

授权与实现防护因此需要各自给出依据。调用范围得到批准，不能证明比较实现符合常量时间建议；实现说明采用了常量时间比较，也不能替组织决定谁应当拥有调用权。两项判断都重要，但它们回答的对象不同。缺少某项核验材料时，准确的表述应当保留这项未知，而不是从另一项已经成立的条件推导出完整保证。

同样，测试频率、任务窗口或额外的调用约束可以成为组织的管理选择；是否需要、如何实施，应由相应使用场景决定。不能把这些选择写成该动作已经定义的功能，更不能用它们替代 RFC 提出的访问控制和比较实现问题。

新密钥测试通过，旧密钥仍可能支撑流量

管理动作在本地完成比较。真实 Babel 报文认证有另外的处理上下文：RFC 8967 第 4 节规定 MAC 计算覆盖相应伪首部及 Babel 报文内容，接收处理还涉及计数器、索引和适用的挑战处理。测试字符串与候选值的一次相等，没有提供报文发送、对端收到或完整接受报文的观察。RFC 8967，第 4 节

由此可以明确划定结论范围：本地真值不能证明实际 Babel 报文认证成功、对端接收成功、路由状态符合预期、切换已经准备就绪，或网络健康。即使测试输入被设计得与某项后续验证有关，它仍然只提供该动作输出的比较证据。要支持更远的决定，需要与该决定相称的独立观察。

轮换尤其容易使这条边界变得模糊。RFC 8967 第 5 节允许旧、新密钥重叠：新密钥逐步加入，过渡期间可以使用两把密钥对应的 MAC，之后再移除旧密钥。线上携带的是 MAC，不是秘密密钥字节。重叠使接收方仍有可能通过旧密钥对应的 MAC 接受报文；因此，流量正常完全可能与新密钥尚未获得所需运行证据同时成立。RFC 8967，第 4—6 节

从证据角度推论，新密钥的本地测试通过，加上重叠期的正常流量，仍然没有单独排除对旧密钥的依赖。前一项说明一次本地比较相符，后一项描述观察到的流量状态。将二者放在同一份报告里，不会自动生成“可以移除旧密钥”的第三项证明。

管理名称也不能填补这一缺口。RFC 8967 第 6.1 节定义的 MAC 信息并不携带本地管理密钥名称。给测试记录标上一个新密钥名称，可以帮助定位管理对象，却不能仅凭这个标签把已接受的线上报文归因到该密钥。RFC 8967，第 6.1 节

合理的决定可以是：本地核验已达到本阶段目标，继续取得支持下一阶段的报文证据。至于何时批准旧密钥退出，组织需要预先说明哪些观察足以支持这个决定，并明确谁对仍然存在的不确定性负责。RFC 提供轮换机制，具体的组织验收证据与批准职责仍须另行制定。

审计要能解释谁使用了秘密，以及结果支持了什么

一份有用的测试记录，需要让后来者重建这次调用的含义。作为治理建议，记录应能关联调用身份与会话、当时有效的授权依据、目标密钥实例及配置时点、算法与测试依据、比较结果或未完成状态，以及该记录支持的下一项决定。可以使用受控引用和版本关联保存这些关系，无须把密钥明文写入日志。

服务账号使归因多了一层。服务器侧的账号名能够说明请求以哪种身份接受访问裁决；如果多个任务都通过同一账号运行，还需要上游任务记录解释是谁发起、谁批准、为何调用这个对象。否则，“自动化执行成功”可能留下一个技术上可识别、责任上却难以继续追查的终点。这是对审计充分性的分析，不是断言 NACM 已经规定逐次测试须记录这些业务字段。

留存结果也要保留其用途限制。若记录只写“新密钥测试通过”，后续读者可能无法知道它指本地比较相符，还是已经取得报文层面的证据。将测试结果与随后批准的步骤分别写清，能使审查者检查推论是否超过证据，而不必重新猜测当时的术语。

本文依据的是四份公开标准，能够说明模型、访问控制及报文机制；没有据此确认任何具体系统的账户权限、实现耗时或网络表现。对一个实际环境，最终需要回答的仍是：这个身份为什么有权调用这把密钥，以及批准下一步的人手中究竟有什么证据。密钥值不可读之后，这两个问题仍然存在，并且可以分别核验。

来源