你删的数据，正在四大洲流浪

近日，Cloudflare 披露了一起发生在 Containers 与 Sandboxes 产品上的跨租户数据暴露漏洞：精简配置（thin-provisioned）存储池被配置为跳过对复用块的清零，研究人员据此在四个大洲恢复出目录结构、数据库页，甚至完整的 SQLite 数据库。Cloudflare 已完成修复，并表示未发现被利用的证据。

我的核心判断是：这不是一次孤立的低级失误，而是多租户架构的集体盲区——那些为了性能做出的默认取舍，正在悄悄变成数据安全的隐性欠账。

💬 事故还原：一次“没删干净”的全球巡展

安全圈有句老话：数据不会消失，只会换一个主人。

先还原事故的样子。据InfoQ报道，研究人员在 Cloudflare 的 Containers 与 Sandboxes 环境里，从本应属于“新租户”的存储空间中，陆续挖出了前租户留下的目录结构、数据库页，以及完整的 SQLite 数据库文件——而且不是集中在一个区域，是横跨四个大洲。

换句话说，你以为早已销毁的沙箱，它的“遗体”还躺在共享存储池里，等着下一位住户来签收。

技术根因并不复杂，甚至可以说是教科书级的问题。存储系统常用精简配置来提高利用率：块按需分配，用多少占多少。而“跳过清零”（skip zeroing）指的是，块被释放后再分配时，不做写前擦除，直接复用。这在单租户世界里是标准的性能优化——反正都是你自己的数据，擦不擦无所谓。

但在多租户世界里，这一句“无所谓”，就是隔离边界的断裂。

值得注意的是 Cloudflare 的处置姿势：主动披露、快速修复、排查后确认未发现被利用证据。据多位接近公有云存储团队的人士说，这类问题在厂商内部通常被列为“信任事件”而非普通漏洞——因为用户买云，买的从来不只是算力，而是隔离本身。

产业逻辑也很清晰：单租户时代的性能优化，放进多租户语境会自动变成安全漏洞。这是所有共享池架构都绕不开、也都必须补的一课。

🤖 为什么偏偏是沙箱：AI 时代的高危放大器

沙箱生得快，死得更快——而数据死得不够快。

Sandboxes 这类产品的业务形态，决定了它的风险等级。它不是传统虚机那种“一租一年”的形态，而是临时计算环境：AI Agent 要跑一段代码、执行一个任务，系统就现场拉起一个沙箱，用完即毁。

创建、销毁、再创建、再销毁。这意味着底层存储块的复用频率，远高于任何传统租户场景；块复用得越频繁，“跳过清零”暴露出来的数据窗口就越多、越大。

更要命的是落在沙箱里的数据类型。AI Agent 的执行环境里，往往有用户上传的数据集、中间产物、连接配置，乃至完整的数据库文件——这次被恢复出的 SQLite 完整库，就是最直观的例子。

圈内流传一种说法：Serverless 程度越高，存储层的“卫生问题”越尖锐，因为它把过去按年计的介质复用，压缩成了按分钟计。

由此得出一个产业判断：当沙箱成为 AI 应用的标准底座，租户生命周期从“月”缩短到“分钟”，任何在存储层偷的懒都会被指数级放大。这不是 Cloudflare 一家的考题，而是所有做 Serverless、做 AI 基础设施的厂商，共同的下一次大考。

🕰️ 老问题的新皮肤：介质卫生的又一次翻译

云计算没有新漏洞，只有旧漏洞搬进了新房子。

数据残留（data remanence）是存储安全里最古老的命题之一：退役硬盘不清零就流入二手市场、共享 SAN 上的精简配置池复用未擦除块、快照与休眠镜像带着前一个租户的数据流转——同族问题在行业里反复出现了几十年。

每一次基础设施的代际更替，都会把这个老问题重新“翻译”一遍：物理机时代，它叫“硬盘退役流程”；虚拟化时代，它叫“镜像与快照管理”；容器时代，它叫“存储驱动与块池策略”；到了 AI 沙箱时代，它又翻译成了“Agent 执行环境的租户间隔离”。

为什么总也翻不完？因为每一层新抽象都会把旧介质藏得更深。工程师眼里的世界是新接口，而数据眼里的世界还是那块盘。抽象层越厚，介质离开发者越远，“记得擦干净”这件事就越没有主人。

这次 Cloudflare 事件的完整生命周期，可以用一条时间线概括：

所以，把这类问题简单归因为“低级失误”，是一种误读。它真正的教训在于：安全属性如果依赖于某位工程师记得去配置，它就注定会失效。 行业需要的不是“下次小心”，而是让安全成为架构中不可跳过的默认值。

🛠️ 工程防御：把安全做成默认值，而不是选项

凡是靠人记得去配的安全，最终都会被一次图省事干掉。

落到工程上，防御手段并不神秘，真正的难点在成本与习惯。

这里要替工程师说句公道话：跳过清零从来不是拍脑袋的决定。清零有真实的性能与成本代价，存储团队在“利用率、时延、安全”三者之间做取舍是日常。问题在于，这类取舍往往以性能优化的名义做出，安全团队甚至不在评审链路上。

据多位做过公有云存储架构的人士复盘，业界的共识正在收敛于一点：多租户共享存储的默认态应该是加密的。 每租户独立密钥，租户销毁即销毁密钥，块复用时残留的只是密文——加密擦除的运行成本接近于零，却把“介质卫生”从流程问题变成了数学问题。

清零策略则应当被列为“变更必审项”：任何跳过清零的配置调整，都必须经过安全评审，而不是存储团队内部拍板。

Cloudflare 此次在披露与修复上的表现值得肯定，但行业的进步不该只靠厂商自觉。对采购方而言，更务实的做法是把“块复用与清零策略”直接写进尽调清单与合同条款——让它成为可审计的承诺，而不是一句官网文案。

🧭 产业判断：信任是多租户的底层协议

用户买的不是算力，是“隔壁看不见我”。

多租户是云计算商业模型的根基——正因为介质共享、资源混部，云才能把成本摊薄到今天的水平。但硬币的另一面是，每一次隔离失效，打击的都是这个商业模型的信用根基。据多位接近云厂商安全团队的人士观察，这类介质卫生问题在内网的优先级，往往取决于最近一次有没有出事——出了事就是最高级，没出事就是待办。

在数据要素流通与 AI 训练数据的语境下，这件事的分量还在加重。过去跨租户泄露或许被归类为“尴尬事故”，而当租户间流转的是训练数据集、企业私域数据时，它就是合规事故，性质完全不同。

给数据平台建设者三条务实的检查建议：

• 🔒 盘点自家架构里所有“共享介质”环节——块池、对象存储、缓存、快照，逐个确认释放策略；
• 把加密擦除做成默认能力，密钥生命周期与租户生命周期严格绑定；
• 性能优化类配置变更强制引入安全侧评审，把“跳过清零”这类决策从存储团队的自由裁量权里拿走。

小结

Cloudflare 这次跨租户数据暴露，技术上是个老故事，产业上是个新警示：当沙箱成为 AI 应用的标准底座，租户生命周期被压缩到分钟级，存储层的隔离短板会以前所未有的速度被放大。可以预见，“块复用策略”将出现在越来越多企业的云安全审计清单里。真正的分水岭不在于谁不会犯错，而在于谁先把安全做成不可绕过的默认值。