Certyo/v1
返回博客
架构与审计2026年4月28日 · 8 分钟阅读

CloudTrail 不是证据:为什么运营日志和完整性证明是不同的类别

云原生销售对话里最常见的反对意见:"我们已经把所有东西都打到 CloudTrail 了"。这个反对意见假设运营日志和防篡改证据是同一类工件。它们不是。同样的数据,结构上不同的信任属性。

几乎每个云原生组织在做证据层评估时都会用同一句开场白:我们已经把所有东西都打到 CloudTrail、Stackdriver 或 Azure Monitor 了——Certyo 能给我们什么是它们给不了的?这是一个公平的问题,值得一个结构性的、而不是营销话术的回答。诚实的回答是:运营日志和完整性证据是不同类别的工件,为不同的工作而设计,具有结构上不兼容的信任属性。同样的数据可以同时存在于两者里,但同样的数据并不会给你同样的可辩护性。

01

运营日志是为了什么而设计的

CloudTrail、Stackdriver 和 Azure Monitor 是为了回答这样的问题而构建的:我们的服务在 03:14 UTC 调了哪个 API、响应是什么、是哪个 IAM 主体发起的。这个工作是运营可见性——调试、告警、容量规划、安全调查。它们对这些工作来说是优秀的工具。

让它们对运营来说优秀的设计约束,也让它们对证据来说不合适。运营日志的设计就是要在某个窗口期内保留、被轮转出去、被重放、被索引、被查询、偶尔被脱敏。这些操作对运营工作没有一个是问题。对证据工作每一个都是问题。

02

审计时三个起决定作用的结构性差异

当审计员、监管者或对方律师挑战一条记录时,对话从运营可见性切换到取证可辩护性。在这个时点上,运营日志和完整性证据之间三个结构性差异变得决定性:

  • 同一信任域——你的 CloudTrail 日志由你 AWS 组织内部的账户写入、保留、读取。审计日志的审计日志活在同一个地方。一个有足够权限的内部人员可以篡改 trail,再篡改篡改记录的 trail。证据需要产生数据的系统之外的信任边界。
  • 策略上对修改友好——日志保留窗口按设计就会让记录到期。生命周期策略会把记录搬到冷存储然后最终删除。这些对运营来说是特性,对证据来说是 bug。审计时不能按需取出的记录不是证据;它是个过去的日志。
  • 没有第三方验证路径——当你把 CloudTrail 导出交给审计员时,审计员只能相信导出对原件是忠实的。没有任何加密原语让监管者在你不配合的情况下、对照一个不可篡改参照来验证导出。运营日志是陈述;证据是可独立验证的论断。
03

完整性被外部锚定后会改变什么

外部锚定——Certyo 在 Polygon 上做的事——不是 CloudTrail 的替代品。它是一个不同的工件,针对上面三个结构性缺口。记录被哈希、累积、批量化,每个批次的 Merkle 根写到公链。三个属性从这个设计里推出来:

同一域
CloudTrail 写入、读取、审计的位置
外部
完整性锚点活在哪里
独立
完整性锚定记录的验证路径

第一,信任边界移到你账户之外:链上 Merkle 根任何人——包括运营 Certyo 的团队——都改不动。第二,锚点不受保留策略约束:它作为链的属性无限期持续,不是作为你订阅的属性。第三,验证不需要你参与:拿着原始记录和链上引用的监管者可以独立确认记录在原始时间戳被锚定过。

04

两个工件如何互补

正确的心智模型不是 CloudTrail 还是 Certyo,而是 CloudTrail 加上 Certyo,每个工件做自己的工作。运营管线继续做它擅长的;证据管线在旁边跑,锚定那些需要熬过审计、纠纷或诉讼的记录:

应用写入记录
CloudTrail 记录 API 调用
Certyo 锚定哈希
两个管线都保留
审计同时引用两者

审计时,CloudTrail 回答"运营上发生了什么",完整性锚点回答"以及那些操作产生的记录没有被改动"。两个工件回答不同的问题,答案是叠加的。只看到 CloudTrail 的审计员有一个故事;看到 CloudTrail 加上一条锚定记录的审计员有一个故事加上一个可验证的论断。

05

三种买家场景里这个区别起决定作用

如果运营日志和证据的差别听起来学院派,它在三个具体场景下会变得紧迫。这些是"CloudTrail 就够了"立场在现场失败的场景:

  • 内部威胁调查当监管者或保险公司在调查可能的内部人员篡改时,活在同一信任域里、和嫌疑行动者同域的日志不能用来反驳篡改。调查人需要一个那个行动者证明性地无法修改的工件。CloudTrail 达不到这条线;外部锚点能。
  • 多年期纠纷当一个三年前记录的纠纷今天浮出水面,问题是这条记录能否以原始形态被取出来。CloudTrail 的保留可能已经让这条目过期了。公链上的完整性锚点没有保留窗口。今天还能对照原始锚点重新哈希的记录仍然可验证。
  • 跨厂商审计当审计员需要把你服务产生的记录和合作方或对手方的记录对照来验证时,审计员不能要求两家组织都分享自己的 CloudTrail。他可以要求两家分享锚定的哈希,对照同一个链上参照来验证。当验证原语独立于任何厂商时,跨厂商审计在结构上更简单。
06

在销售对话里遇到这个反对意见时怎么处理

对"我们已经在用 CloudTrail"的正确回应不是去说 CloudTrail 不好。它在自己的本职上是优秀的。正确的回应是问:在最坏情况下,买家愿意接受三个结构性缺口里的哪一个——一个有决心的内部人员篡改审计日志,一个保留策略让一条争议记录过期,一个审计员在没有你配合的情况下没法验证。如果回答是一个都不接受,那 CloudTrail 单独不是这块工作负载的合适工具。关于 Certyo 怎么和现有日志基础设施并行运行,见 /zh/about。关于验证原语的细节,见 /zh/blog/blockchain-without-crypto。

CloudTrail 告诉你发生了什么。完整性锚点让第三方验证"发生了什么的记录"没有被改过。同样的数据,结构上不同的信任属性。两个工件回答不同的问题,审计时你两个都需要。

2026年4月28日 · 8 分钟阅读

想亲眼看到效果?

申请演示,几分钟内验证你的第一条记录。

申请演示 → 了解工作原理