加密的幻觉
在 2022 年 12 月，LastPass 宣布发生了数据泄露。官方声明中包含了令人安心的措辞：用户密码是“加密的”。保险库数据是“安全的”。
到 2025 年，超过 4.38 亿美元 的资金已从 LastPass 用户那里被盗——直接从他们所谓的加密保险库中被抽走。
怎么做到的？LastPass 持有密钥。
这是每个企业安全团队在选择任何处理敏感数据的云工具（包括 PII 匿名化平台）之前必须理解的关键区别。
服务器端加密与零知识架构
大多数声称“加密您的数据”的云工具使用 服务器端加密（SSE）。这实际上意味着什么：
| 属性 | 服务器端加密 | 零知识架构 |
|---|---|---|
| 加密发生在哪里 | 在供应商的服务器上 | 在您的设备上（浏览器/桌面） |
| 谁持有密钥 | 供应商 | 只有您 |
| 供应商可以读取您的数据 | 是 | 否 |
| 服务器泄露暴露数据 | 是 | 否（仅密文） |
| 供应商可以被迫提供数据 | 是 | 否（他们没有） |
| 监管机构/执法部门访问 | 通过供应商 | 没有您的密钥不可能 |
LastPass 使用了他们控制的服务器端加密密钥。当攻击者侵入他们的基础设施时，他们获得了密文和最终解密它的手段——通过对员工进行社会工程、暴力破解弱主密码以及利用旧账户的元数据。
这对 GDPR 第 25 条的重要性
GDPR 第 25 条（隐私设计）要求数据控制者实施“适当的技术和组织措施”，将数据保护整合到处理过程中“按设计和默认”。
欧洲数据保护委员会（EDPB）已澄清，这包括 密码学数据最小化——这意味着架构本身应该使数据对未经授权的方不可访问，而不仅仅是通过访问控制来保护。
持有您加密密钥的供应商无法在最严格的解释中满足第 25 条，因为：
- 他们基础设施的成功泄露可能会暴露您的数据
- 对供应商发出的法律传票可能会产生您的数据
- 供应商的流氓员工可能会访问您的数据
- 供应商的密钥管理服务的供应链妥协可能会暴露您的数据
德国联邦数据保护专员（BfDI）和奥地利数据保护局均已发布指导，表示零知识架构是高风险处理的首选技术实施。
SaaS 数据泄露现实检查
AppOmni / 云安全联盟 2024 报告记录了从 2022 年到 2024 年 SaaS 数据泄露增加了 300%。攻击的复杂性显著增加：
- 平均泄露时间：9 分钟（从数小时减少）
- 第三方参与泄露：同比翻倍（Verizon DBIR 2025）
- Conduent 泄露：2590 万条记录暴露（社会安全号码、健康保险数据）
- NHS 供应商泄露：900 万名患者暴露
在这种威胁环境中，架构保证已取代政策承诺，成为高风险数据处理的最低可接受标准。
真正的零知识架构是什么样的
真正的零知识架构具有以下可验证的属性：
1. 客户端密钥派生 加密密钥是通过在您的设备上使用内存硬的 KDF（Argon2id、bcrypt 或 scrypt）从您的密码派生的。派生的密钥永远不会离开您的设备。
2. 客户端加密 数据在离开您的浏览器或桌面应用程序之前被加密。服务器仅接收密文——没有密钥就毫无意义。
3. 无服务器端密钥存储 供应商不存储密钥、密钥片段或密钥备份。恢复通过用户控制的恢复短语进行。
4. 密码学可验证性 架构应可记录和可审计——理想情况下，开放给外部审查。没有技术细节的模糊“端到端加密”声明应持怀疑态度。
anonym.legal 如何实现零知识
anonym.legal 的零知识认证使用：
- Argon2id 密钥派生：64MB 内存，3 次迭代——OWASP 推荐的高安全性应用程序参数
- AES-256-GCM 加密：在任何数据传输之前完全在浏览器/桌面中应用
- 24 个单词的 BIP39 恢复短语：恢复访问的唯一方法——不由 anonym.legal 存储
- 零服务器端密钥访问：anonym.legal 服务器仅接收 AES-256-GCM 密文，而没有解密它的密钥
一次完整的 anonym.legal 服务器泄露将产生无法在没有每个用户派生密钥的情况下解密的加密数据块——该密钥仅存在于他们的设备上。
供应商评估检查表
在评估任何处理敏感数据的云工具时，请提出以下问题：
架构问题：
- 加密/解密发生在哪里——在您的设备上还是在供应商的服务器上？
- 谁生成加密密钥？
- 加密密钥存储在哪里？
- 供应商能否在回应传票时提供您的数据的明文副本？
- 如果供应商被收购，您的数据会发生什么？
泄露弹性问题：
- 如果供应商的整个基础设施被攻破，哪些数据会暴露？
- 如果供应商的员工变得不可靠，他们可以访问哪些数据？
- 如果供应链攻击妥协了供应商的基础设施，哪些数据会暴露？
监管问题：
- 供应商能否提供满足 GDPR 第 25 条的文档？
- 该架构是否经过独立安全审计员的审查？
- 是否有覆盖加密实施的 ISO 27001 或 SOC 2 认证？
任何无法清楚回答“零——您的数据在离开您的设备之前已加密”的泄露弹性问题的供应商都依赖于服务器端加密。
用例：德国健康保险公司的尽职调查
一家主要德国健康保险提供商（Krankenkasse）的合规官需要一个云匿名化工具来处理投保人投诉日志。数据保护官的检查表包括：
- 供应商无法访问投保人数据
- 没有在德国以外的基础设施上处理数据
- GDPR 第 32 条技术措施已记录
- DPA 可报告的泄露风险最小化
一家领先的美国匿名化 SaaS 在第一个标准上失败：他们的支持团队可以重置用户保险库，这意味着服务器端密钥访问。第二个工具将处理过的文本存储 30 天以用于“审计跟踪”目的——同样是服务器端访问。
anonym.legal 的零知识架构满足所有四个标准。数据保护官可以记录：“即使供应商的基础设施完全妥协，也不会产生可用的投保人数据——加密密钥仅存在于我们的工作站上。” GDPR 第 32 条文档在四小时内完成。
ICO 执法先例
在 2025 年 12 月，英国信息专员办公室对 LastPass 英国实体处以 120 万英镑 的罚款，原因是“未能实施适当的技术和组织安全措施”。
罚款并不是因为泄露本身——而是因为导致泄露灾难性的架构决策：对旧账户的 KDF 迭代不足、元数据暴露，以及选择将密钥保存在服务器端的根本选择。
监管机构现在不仅在评估是否发生了泄露，还在评估架构是否最小化了泄露影响。零知识架构是这一意图最清晰的技术证明。
结论
“我们加密您的数据”并不是安全保证——这是一种需要质疑的营销声明。
重要的问题是：谁持有密钥，加密发生在哪里，如果供应商的基础设施被攻破，哪些数据会暴露？
对于在 GDPR、HIPAA 或任何可比框架下处理敏感数据的组织，这些问题的架构答案决定了您的监管风险和实际泄露风险。
LastPass 加密了用户的数据。零知识架构本可以使 2022 年的泄露事件不复存在。从用户那里盗取的 4.38 亿美元是架构捷径的代价。
anonym.legal 实现零知识架构以进行 PII 匿名化：Argon2id 密钥派生在您的浏览器或桌面应用程序中运行，AES-256-GCM 加密在数据离开您的设备之前发生，而 anonym.legal 服务器仅存储无法解密的密文。
来源：