声明与架构之间的差距
每个处理敏感数据的云供应商都提出某种版本的相同声明：“我们加密您的数据。”这个声明几乎总是正确的——但几乎总是不够。
2022 年的 LastPass 事件是一个决定性的案例研究。LastPass 加密了他们用户的密码保险库。他们使用了加密。这个声明是准确的。然而，2500 万用户的加密保险库被外泄，$438 百万随后在 2025 年通过下游加密货币盗窃被盗，依据 Coinbase Institutional 的研究。
英国信息专员办公室在 2025 年 12 月对 LastPass 的英国实体处以 £1.2 百万 的罚款，原因是“未能实施适当的技术和组织安全措施。”加密是存在的，但安全措施未达到所需标准。
对于评估云隐私工具的企业——包括 PII 匿名化平台——LastPass 的先例改变了采购问题。问题不再是“他们是否加密我们的数据？”而是“他们能否解密我们的数据？”
实际上重要的四个零知识问题
在评估供应商的零知识声明时，有四个问题决定架构是否真实：
1. 密钥派生在哪里发生？
在真正的零知识架构中，密钥派生发生在客户端——在浏览器或桌面应用程序中——在任何数据传输之前。派生的密钥用于本地加密数据。只有加密的密文传输到供应商的服务器。
如果供应商在他们的服务器上派生加密密钥，他们就持有这些密钥。如果他们持有密钥，他们就可以解密。这个声明在技术上是准确的（“我们加密”），但在其含义上具有误导性。
2. 供应商是否有访问明文的权限？
一些工具在静态数据上加密，但在处理时解密——运行 AI 模型、分析、搜索索引或审计日志生成。在处理窗口期间，明文在供应商的基础设施上是可访问的。在该窗口期间的任何泄露都会以未加密的形式暴露数据。
3. 法律程序下会发生什么？
如果政府机构向供应商发出传票，他们能提供什么数据？一个拥有服务器端密钥的供应商可以被迫提供解密内容。一个具有零知识架构的供应商只能提供加密的密文——即使在法律强制下，他们也没有有用的东西可以交出。
4. 完全的服务器妥协会暴露什么？
在真正的零知识实现中，供应商基础设施的完全泄露仅会产生加密的 blob。攻击者获得密文而没有解密的密钥。在一个由供应商控制密钥的实现中，服务器泄露会暴露密钥和数据。
LastPass 实现失败
LastPass 的泄露揭示了一个特定的实现差距：较旧的账户使用 PBKDF2 进行密钥派生，迭代次数少至 1 次，而不是推荐的 600,000 次。较弱的密钥派生使得对外泄保险库的暴力攻击在计算上是可行的。
这说明为什么评估零知识声明需要检查实现细节，而不仅仅是架构描述。一个供应商可以使用零知识设计，但实施得很弱。正确的问题涵盖架构（密钥派生位置）和实施强度（算法和迭代次数）。
Okta 泄露：不同的失败模式
在 2023 年 10 月，Okta 披露在一次泄露中超过 600,000 条客户支持记录被泄露。Okta 是一个身份平台——许多企业用来保护对其他云工具的访问。Okta 的泄露与 LastPass 的失败模式不同：不是零知识实现的弱点，而是支持基础设施的妥协，恰好包含客户数据。
2024 年 SaaS 泄露激增 300%（AppOmni/CSA）反映了这两种失败模式：像 LastPass 的架构弱点和像 Okta 的基础设施妥协。零知识架构解决了架构失败模式。它并不消除所有泄露风险，但确保即使完全的基础设施妥协也不会暴露可解密的客户数据。
真正评估的样子
对于评估零知识声明的采购团队，评估检查清单：
架构审查：
- 请求文件，显示密钥派生发生的位置（客户端 vs. 服务器端）
- 询问加密算法、密钥长度和迭代次数
- 请求确认明文从未传输到供应商服务器
泄露场景测试：
- 请供应商描述完全的服务器妥协会暴露什么
- 如果答案包括“我们无法解密的加密密文”以外的任何内容，则该声明不是零知识的
法律程序审查：
- 询问供应商是否能遵守要求提供客户明文的传票
- 真正的零知识供应商无法提供他们没有的内容
合规文件：
- 请求供应商的 GDPR 第 32 条合规文件
- ISO 27001 认证（特别是附录 A 加密控制）提供了密钥管理实践的外部验证
£1.2 百万的 LastPass ICO 罚款确立了声称加密的供应商必须接受监管评估，以确定这些声明是否符合所需标准。监管机构应用的相同评估框架在泄露发生之前也可供采购团队使用。
来源：