Certyo/v1
返回博客
安全架构2026年4月28日 · 9 分钟阅读

为什么你的 KMS 选择比你的区块链选择更重要

大多数团队都纠结于哪条链锚定他们的记录。真正的安全边界是 KMS——在记录被哈希之前给它们签名的那个 KMS。如果 KMS 被攻陷了,链救不了你——被锚定的记录已经是错的了。

证据层评估在链上花了过多时间——Polygon vs Ethereum vs 私链、最终性、gas、厂商中立性。这些问题重要,但都不是承重的安全问题。承重的问题是:在记录被哈希和锚定之前,谁控制给它们签名的密钥?KMS——Key Management Service,密钥管理服务——就是替你保管和使用加密密钥的系统,常见的产品是 AWS KMS、Azure Key Vault 和 HashiCorp Vault,回答这个问题的就是它。如果 KMS 被攻陷了,世界上最强的区块链也只会忠实地锚定那些已经错了的记录。链是证人;KMS 是作者。这篇文章是给那些需要清晰思考真正信任边界在哪里的安全架构师的。

01

为什么链不是安全边界

锚定的 Merkle 根的工作是证明特定一批记录在特定时刻存在过、之后没有变过。它在这个工作上很优秀。它做不到的是证明记录在被创建的那一刻是正确的。锚定是时间维度上的完整性,不是来源处的真实性。

来源真实性的问题靠签名来回答——通常一条记录由创建它的系统或人控制的私钥来签名,签好的记录才是被哈希和锚定的对象。如果签名密钥被攻陷,被签的任何东西都可证明地由密钥持有者创建——不管持有者是不是他声称的那个人。链看不到这个区别。链锚定的是给它的东西。

02

链不会捕获的三种故障模式

如果 KMS 是安全边界,问题就变成了哪些和 KMS 相关的故障会导致"被锚定但是错的"记录。安全评审里反复出现三种模式:

  • 密钥被攻陷——攻击者拿到签名密钥,创建看上去合法的记录。链忠实地把它们锚定。取证恢复需要识别出被攻陷的窗口期,并撤销该窗口内所有被签名锚定的记录。完整性锚点证明了它们存在过;它没有证明它们是真实的。
  • 密钥托管迁移——你团队从一个 KMS 切到另一个,或者在云厂商之间迁移,而轮换没有保住把旧密钥和新密钥连起来的认证链。旧密钥下签的记录仍然可以验证,但审计叙事需要明确的密钥血缘文档。没有它,这个缺口在诉讼里会被利用。
  • 内部人员提取密钥——一个有特权的运维人员把密钥材料本身提走了,而不只是签名能力。后续用提走的密钥创建的记录在链层面和真实记录不可区分。防御是用 HSM 撑底、无法被提取的密钥,不是事后检测。
03

为什么自托管搭配你的 KMS 在结构上不一样

托管证据层和自托管证据层之间的架构选择常被框成一个运营问题:谁来跑这个集群。KMS 这层视角把它重新框成一个安全问题:谁控制密钥。在托管证据服务里,厂商的 KMS 代你给记录签名。厂商读不到记录,但厂商被攻陷就是你被攻陷。在自托管部署里,密钥活在你的 KMS 里——你账户里的 AWS KMS、你租户里的 Azure Key Vault、你集群里的 HashiCorp Vault,或你机房里的 HSM。厂商被攻陷不是你被攻陷。

你的 KMS
自托管 Certyo 里签名密钥活在哪
FIPS 140-2
高保证密钥材料的 HSM 标准
0
如果密钥被攻陷,链能识别出多少错误记录

这不是抽象偏好。对于受 HIPAA、PCI-DSS、FedRAMP 或任何把密钥托管定义为控制目标的框架监管的工作负载来说,"用哪个 KMS"这个问题是合规要求的回答,而不是部署偏好。自托管 SKU 之所以存在,是因为审计里"我的密钥在我自己的 KMS 里"这个回答和"我厂商的 KMS 代我签名"这个回答在实质上不同。

04

Certyo 怎么集成你已经在跑的 KMS

运营现实是大多数受监管的组织已经有 KMS 策略,不想再要一个新的。Certyo 的设计就是融入标准选项,而不是引入自己的。无论组织在跑哪个 KMS,集成点都是清晰定义的:

记录被创建
你的 KMS 签名
计算哈希
锚定在 Polygon
可独立验证

AWS KMS、Azure Key Vault、GCP Cloud KMS 和 HashiCorp Vault 都通过标准签名 API 支持。需要物理密钥托管的环境通过 PKCS#11 支持 HSM 撑底的密钥。集成可以按租户配置,所以同一个 Certyo 部署里不同的工作负载可以用不同的签名策略——日常工作流可以用软件密钥,高风险工作流用 HSM 密钥,链对两者一视同仁地锚定。

05

三种 KMS 选择起决定作用的工作负载

KMS 选择对某些工作负载比其他更重要。规律是一致的:对真实性的保证要求越高,KMS 在安全分析里的主导地位就越大:

  • 医疗临床记录当一条临床记录被事后争议——这个过敏是在处方前记录的,还是在不良事件后被回填的——问题是谁创建的、创建身份能不能被冒充。HSM 撑底、硬件证明出处的密钥是最干净的防御。链上锚点证明这条记录在这个时间戳存在过;HSM 签的签名证明身份。
  • 高风险金融交易电汇、清算事件和容易引起纠纷的支付记录,会从在密钥层强制执行的职责分离里得到好处。两把密钥分别独立托管的链来签名,让内部人员攻陷的难度实质性变高。链锚定结果;多密钥签名方案才是让结果可信的东西。
  • 国防和涉密运营无法在密钥托管路径上接受任何厂商的工作负载,需要完全气隙、没有远程管理接口的 HSM。自托管 Certyo 加本地 HSM 是少数支持这种姿态的证据层架构之一。密钥永远不离开运营组织控制的硬件;链上锚点是唯一跨越边界的工件。
06

怎么以 KMS 策略评估一个供应商

评审任何证据层供应商时,正确的问题不在链上。在密钥上。签名密钥默认活在哪里?能不能要求供应商使用买方的 KMS?支不支持 HSM 托管,通过哪个标准?如果一把密钥被攻陷了,已锚定的记录怎么办——能不能把特定记录标记为撤销,又不让其他记录失效?一个清晰回答这些问题的供应商,懂他自己的证据层到底是什么。一个把话题拉回到选哪条链的供应商,是在卖一个没有作者的证人。关于保留 KMS 主权的部署拓扑,见 /zh/about。关于"记录在链上"这个误解,见 /zh/blog/records-not-on-blockchain。关于链层的集中风险,见 /zh/blog/evidence-layer-concentration-risk。

链是证人;KMS 是作者。如果作者被攻陷了,证人仍然忠实地讲故事——而故事是错的。证据层的安全活在 KMS 里,不在链上。

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

想亲眼看到效果?

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

申请演示 → 了解工作原理