NTS 能认证 NTP 时间包，但 Agent 审计链还需要证明主机持续同步、事件使用了正确的时间语义，并把每个时间戳绑定到可追溯的运行证据。本文基于 RFC 8915 与 Meta 的生产部署，给出一套四层时间合同。
阅读时间：约 8 分钟 · 全文约 3000 字
先看结论
- 普通 NTP 缺少服务器身份认证和报文完整性保护。
- NTS 把低频的 TLS 密钥协商与高频的认证时间同步拆开，兼顾安全与规模。
- NTS 能证明报文来自已认证的服务端，并且传输中没有被修改。它无法证明服务端时间一定正确，也无法消除延迟攻击。
- Agent 审计需要四层证据：时间源认证、主机校时健康、事件时间语义、审计证据绑定。
- NTS 失败后静默回退普通 NTP，会直接破坏这套控制的意义。
Agent 日志默认信任了一个外部输入
我们设计 Agent 治理时，会认真记录 run ID、工具调用、审批、文件 diff 和最终结果，却很少追问时间戳来自哪里。
这会留下一个基础漏洞。一次 Agent 运行可能跨过编排器、模型网关、工具沙箱、代码仓库、审批系统和部署平台。时间戳决定了动作先后、凭据是否过期、重放是否落在窗口内，以及事故发生时应该相信哪条记录。只要几个系统的时钟发生偏移，一份看似完整的日志就可能拼出一条从未发生过的时间线。
精度解决不了来源问题。一个显示到微秒的时间，如果来自身份未知且可以被中间人伪造的服务器，仍然是一条不可信输入。
Meta 在 2026 年 10 月公开了其 NTS 部署。其描述很直接：传统 NTP 客户端发送 48 字节，收到 48 字节，然后相信答案，过程里没有签名，也没有身份。Meta 现在通过 nts.meta.com 提供 NTS，并把协议、客户端和服务端实现放进了 Meta Time 开源仓库。
这件事对 Agent 系统的价值，在于把时间源从默认正确的隐含前提，变成一个可以检查的安全接口。
NTS 到底认证了什么
RFC 8915 把 NTS 分成两个阶段。
第一阶段是 NTS-KE。客户端通常连接 TCP 4460，通过 TLS 1.3 验证服务端身份，协商 AEAD 算法，派生两个方向的密钥，并取得一组不透明 Cookie。
第二阶段回到 UDP 123。客户端发送带 NTS 扩展字段的 NTPv4 报文。Unique Identifier 负责把响应与具体请求对应起来，Authenticator 保护报文完整性，Cookie 则把服务端需要的会话状态交给客户端携带。服务端因此无需长期保存每个客户端的状态。
这套设计能够提供服务器身份、报文认证、重放检测和请求响应一致性。昂贵的非对称密码主要留在低频的 NTS-KE 阶段，高频校时继续使用对称密码。
它的能力边界同样明确：
- 攻击者仍可丢弃或延迟真实报文。
- 通过认证的服务器仍可能给出错误时间。
- 系统启动时，TLS 证书验证本身也需要一个大致正确的时钟。
- 墙上时间可能因校时发生跳变，无法直接承担耗时测量。
所以，NTS 是时间信任链的入口，不是完整审计链。
四层时间合同
把时间戳升级为审计证据，需要连续通过四层验证。
| 层级 | 验证对象 | 最小证据 | 失败后说明什么 |
|---|---|---|---|
| 1. 时间源认证 | 报文来自批准的服务端，传输中未被篡改 | 证书身份、NTS-KE 状态、AEAD、认证报文计数 | 时间来源或传输路径不可信 |
| 2. 主机校时健康 | 本机时钟持续处于业务误差预算内 | 可用时间源、reach、offset、误差界、上次成功同步、clock step | 来源可能可信，本机时间仍不适合决策 |
| 3. 事件时间语义 | 每个字段使用了正确的时钟 | UTC 墙上时间、monotonic time、精度、序号、不确定度 | 数值都正确，顺序仍可能错误 |
| 4. 审计证据绑定 | 时间状态与 Agent 动作和结果可关联 | run ID、event ID、Agent 与策略版本、审批、工具结果、产物哈希 | 时间戳无法支撑重建与归因 |
第一层：认证时间源
部署 NTS 后，至少要区分三个状态：端点可达、NTS-KE 成功、认证时间包持续到达。把其中任何一个当成全部成功，都会产生虚假的安全感。
本文在北京时间 2026 年 10 月 7 日对 nts.meta.com:4460 做了实时握手检查，成功协商 TLS 1.3 与 ALPN ntske/1，证书链验证通过。这个结果只证明当时的公开密钥协商入口可用。它无法证明某台业务主机之后一直处于同步状态。
第二层：验证主机时钟健康
通过认证的服务端也可能出错，真实报文也可能延迟，本机还可能耗尽 Cookie 或失去全部时间源。因此，认证状态和校时健康必须拆成两个字段。
建议至少采集：当前选中的时间源、独立可用源数量、reach、offset、估计误差、最近一次成功同步、clock step，以及 NTS-KE 失败、Cookie 拒绝和认证报文数量。
每类 Agent 工作负载还要有自己的误差预算。日志归档可以容忍较宽的偏差；短期凭据签发、重放判断和跨主机事故排序需要更严格的门槛。
第三层：分开墙上时间与单调时间
UTC 墙上时间用于回答事件在现实世界何时发生，适合跨系统关联、证书有效期、留存策略和人工事故时间线。monotonic time 用于计算同一运行环境内的耗时、超时、租约和退避。
两者混用会制造隐蔽错误。墙上时间向后校正时，延迟可能变成负数；单调时间在进程或主机重启后又无法直接跨系统比较。
一条高价值 Agent 事件可以同时记录：UTC 时间、单调时间或相对耗时、事件序号，以及当时的校时健康状态。严格顺序依赖事件序号和因果关系，跨系统对齐再参考 UTC 与误差界。
第四层：把时间状态绑定到行为证据
NTS 只保护时间同步报文，不会替 Agent 日志签名，也不会自动生成业务事件 ID。
每个重要动作需要把时间信息绑定到稳定的 run ID 和 event ID，同时记录 Agent 版本、策略版本、审批结果、目标系统回执和产物哈希。需要长期审计时，再把这些记录写入追加式或不可变存储。
这正好补上 Agent 可观测性合同 的基础层：结果、动作、身份和审批要想形成事故证据，必须使用能够复核健康状态的时间基础。
从一行配置推进到可执行验收
Meta 给出的 chrony 配置很短：
pool nts.meta.com nts iburst maxsources 5
这里使用 pool 而非单个 server，目的在于建立多个独立关联，减少单点依赖。Meta 的 NTS-KE 入口可以把不同关联引导到多个响应服务器，每条关联拥有自己的会话密钥。
配置完成后，至少检查三类信息：
chronyc -N authdata
chronyc -N sources
chronyc tracking
Red Hat 的 chrony NTS 文档 用 authdata 检查密钥建立和认证关联，用 sources 检查时间测量是否到达。tracking 则补充本机时钟的同步状态。具体字段与阈值需要按 chrony 版本和业务误差预算确定。
一套有效验收应连续回答六个问题：
- NTS-KE 是否认证了批准的端点？
- 认证时间包是否持续到达？
- 是否有足够多的独立可用时间源？
- offset 与估计误差是否处于业务预算内？
- 是否发生过 clock step，或超过允许的失联时间？
- Agent 事件是否记录了当时的时间健康状态？
只有六项都能回答，时间戳才从一个字段变成可以支撑决策的证据。
失败策略比安装更重要
RFC 8915 专门警告 NTS stripping：攻击者可以故意让 NTS-KE 失败，诱使实现回退到普通 NTP。规范建议，未经用户显式操作，客户端不应从受 NTS 保护的同步自动回退到无保护同步。
Agent 平台需要把它变成业务策略：
- 高影响动作暂停，包括签发凭据、生产部署、破坏性写入和最终事故归因。
- 低影响动作可以在降级模式继续，但事件必须显式标记
time_status=degraded，并保留本地单调顺序。 - 下游系统拒绝使用降级时间完成过期判断、重放判定和责任结论。
- 恢复时要求认证时间源重新可用，在指定稳定期内持续满足误差预算，并生成一条独立恢复事件。
只发出 NTP 不可用告警仍然不够。运维人员需要知道失败发生在哪一层、上次可信时间、当前误差、受影响的 Agent run，以及系统采取了什么限制动作。
用故障演练验收，而不是看配置文件
在测试主机或隔离网络中完成以下演练：
| 演练 | 预期结果 |
|---|---|
| 建立 Cookie 后阻断 TCP 4460 | 已建立的认证同步暂时继续，重新协商风险和 Cookie 状态可观察 |
| 阻断 UDP 123 | reach 下降，失联时间增长，敏感动作在阈值处停止 |
| 破坏证书验证 | NTS-KE 失败，客户端不会静默改用普通 NTP |
| 注入一个通过认证但明显偏离的时间源 | 多源选择与合理性限制阻止单一来源定义本机时间 |
| 人为增加网络延迟 | 误差或不确定度升高，系统不会声称 NTS 已阻止延迟攻击 |
| Agent 运行中调整墙上时间 | 耗时指标继续使用单调时间，墙上时间跳变被记录 |
这些演练检查的是业务闭环。很多团队已经监控时钟偏移，却从未验证 Agent 授权系统在失去时间信心时会怎么做。
常见问题
NTP 和 NTS 有什么区别？
NTP 负责传递时间。NTS 通过 TLS 密钥建立和认证扩展字段，为 NTP 客户端服务端模式增加服务器身份认证、报文完整性与抗重放能力。
NTS 会让时间更准吗？
不会直接提高精度。它让来源和报文可验证。最终精度仍取决于时间源质量、网络延迟、源选择、时钟控制和持续监控。
NTS 能阻止所有时间攻击吗？
不能。它能阻止伪造和修改认证响应，但攻击者仍可以丢包和延迟。通过认证但自身错误的服务器，也可以发出带有完美认证的错误时间。
一个 NTS 服务端够不够？
单个服务端解决该路径上的伪造问题，仍然留下正确性和可用性单点。生产系统需要多个独立来源或网络路径，并定义明确的误差预算和选择规则。
NTS 会给每条 Agent 日志签名吗？
不会。NTS 保护的是 NTP 同步报文。Agent 事件的身份、签名、审批、产物哈希和不可变留存，仍需由上层审计系统完成。
最终原则
信任一个时间戳之前，先让系统回答四个问题：时间由谁提供，本机是否持续同步，这个字段表达什么时间语义，以及它属于哪条可追溯证据。
NTS 回答第一个问题。生产级 Agent 控制面必须回答全部四个。