数字主权的幻觉：为何供应商更换不是合规策略

Source: Dev.to

加密表层

要明确一点，存储层的技术实现是可靠的。Schwarz Digits 正在使用外部密钥管理结合客户端加密。从架构上看，将加密密钥保存在他们自己的 STACKIT 环境中，而仅使用 Google 进行加密存储，是减轻美国《云法案》对静止数据影响的正确做法——Google 只会看到加密的二进制块。

然而，仅加密负载只是治理方程式的一小部分。

架构盲点 1：执行上下文

根本缺陷在于执行层。数据在终端上被加密，但到底是谁提供执行这段加密的应用代码？如果用户通过网页浏览器访问 Workspace，Google 正在提供 JavaScript 负载。

如果美国情报法院发出秘密传票，它可以合法强制供应商向特定目标提供修改后的代码负载。在这种情况下，本地加密在数据到达 STACKIT 密钥管理库之前就已被破坏。如果外国实体控制了软件的执行环境，你就无法宣称主权。

架构盲点 2：元数据现实

仅加密文档内容完全忽视了元数据的价值。Google 仍然处理身份验证请求、IP 地址、时间戳以及协作网络。在国家层面的监视或企业间谍活动中，准确知道谁在何时与谁交流，往往比实际文件内容更有价值。超大规模云服务商仍然拥有这些遥测数据。

架构盲点 3：结构性依赖

最后一点是原始的运营治理。当供应商更改服务条款、调整定价模型或面临极端政治压力时会怎样？加密架构并不能改变整个企业完全依赖美国软件平台的事实。

真正的主权需要对软件本身拥有绝对控制权，而不仅仅是加密密钥。仅为运行美国软件而在欧洲数据中心投入巨额资源，并不等同于数字独立。

治理现实

业界需要停止把供应商迁移项目包装成“主权架构”。真正的 IT 安全与合规要求你必须控制代码、执行环境以及数据的边界。企业架构的未来属于那些投资拥有自己的系统，而不是仅仅租用新系统的组织。

Sources

• justice.gov/dag/cloudact (Official U.S. Department of Justice CLOUD Act mandate)
• (Google Workspace Security and Client‑Side Encryption architecture)
• (STACKIT Cloud Security and Compliance documentation)
• (European Data Protection Board guidelines on supplementary measures for data transfers)
• (National Institute of Standards and Technology Zero Trust Architecture outlining execution‑context risks)
• (European Union Agency for Cybersecurity guidelines on data sovereignty and engineering)