当云被打成筛子
内容提要
文章指出，AI大幅加速漏洞挖掘，使云平台补丁窗口成为致命时间差，TiDB Cloud、Zeabur、IDCF等接连被攻破。作者认为开源透明并非问题，公网多租户裸奔才是根源，主张本地优先、物理隔离与收窄攻击面，核心敏感数据应退回内网自建。
延伸解读
补丁窗口为何成为致命时间差
文章指出，开源项目的主干提交和普通修复公开可见，攻击者可据此反向分析利用条件；而云厂商需拉取代码、合入魔改分支、测试灰度，才能推送到客户实例。AI 加速漏洞挖掘后，这个从修复公开到补丁落地的窗口被显著放大，尚未升级的多租户实例便暴露在自动化攻击之下。
开源透明不是原罪，公网裸奔才是
作者反驳“闭源更安全”的说法，认为开源代码被反复审计和修复，反而在收敛漏洞；闭源软件因缺乏公开审视，可能积压大量低级缺陷。问题不在于代码公开，而在于把多租户服务直接暴露在公网，使公开的修复线索能迅速转化为对未打补丁实例的远程攻击。
物理隔离如何改变攻击成本
文章以离线安装和涉密机房为例，说明物理隔离能切断公网远程利用路径，把攻击门槛从脚本自动化提高到供应链、移动介质或内部人员渗透。作者也承认隔离并非绝对安全，内网不可信账号和供应链仍需管理，补丁也不能永远不打，但隔离能显著收窄软件漏洞被直接触达的范围。
分级回退：核心数据与外围收窄
作者并不主张所有业务立刻断网，而是建议分级处理：把最核心、最敏感的数据退回内网自建并筑起物理隔离，其余业务至少配好防火墙、收窄攻击面。这一思路针对的是公网多租户环境下补丁窗口被 AI 利用的风险，而非否定云服务本身的所有场景。
Q&A
为什么最近云平台和数据库被攻破的事件这么多？
AI大幅加速了漏洞挖掘，使漏洞发现速度远超云厂商打补丁的速度，形成致命时间差。同时，开源代码提交公开，攻击者可反向分析利用条件，而云厂商因工程限制无法快速跟进上游修复。
云厂商为什么不能及时给漏洞打补丁？
云厂商需要拉取上游代码、合入自己的魔改分支、做兼容性测试和灰度发布，流程漫长。且不能跟随master主干每日热更新，否则会引入新风险。因此从漏洞公开到补丁落地存在几周甚至几个月的窗口期。
开源软件因为代码公开而更不安全吗？
不是。开源透明并非问题根源，公网多租户裸奔才是。开源软件被AI和全球研究员高强度审计，Bug被逐个修复，稳定分支会越来越安全。闭源软件缺乏外部审计，漏洞可能更多且更隐蔽。
物理隔离为什么能有效防御云上攻击？
物理隔离切断了攻击者利用补丁窗口的远程通路，使自动化脚本和AI攻击失效。攻击者需通过供应链、移动介质或物理渗透等更高成本手段，门槛从“敲回车”提升到“谍战片级别”。
面对当前云安全形势，企业应该采取什么策略？
分级处理：将最核心敏感数据退回内网自建，实现物理隔离；其余业务至少配好防火墙、收窄攻击面。同时倡导本地优先和数据自主，减少对公网多租户云的依赖。
Supabase 数据库裸奔事件暴露了什么问题？
超过1.6万个托管在Supabase上的云数据库因公网端点暴露和行级安全（RLS）配置缺失，可被批量读取。这反映了云端许多事故源于“没有能力做正确配置”，而非单纯的技术漏洞。
