数据平台的安全幻觉，正在被批量打碎

数据平台的安全幻觉，正在被批量打碎

一个用「123456」当管理员密码的公司，替整个国家保管着公民身份编号；一家以技术立身的数据库厂商，被勒索组织一次性拖走 10.6TB 数据和 413 个私有代码仓库。这两件事几乎同时发生，很难说是巧合。它揭示的真相很刺眼：数据平台行业讲了十年的「企业级」「云原生」「可信」，在真实的攻击者面前，可能只隔着一层窗户纸。

更麻烦的是，当所有人都在把 Text-to-SQL Agent 接进生产库时，数据暴露面还在被 AI 主动拉宽。这篇文章不聊概念，只聊三条正在被击穿的战线，以及务实派该做什么。

🩸 两起事故，两种死法

先看第一起。PingCAP 近期确认，其内部系统遭到未授权访问，源代码与客户相关数据被窃取。攻击者是网络勒索组织 FulcrumSec，声称盗走了 10.6TB 数据，内容清单读起来让人脊背发凉：TiDB Cloud 的控制面记录、客户 SQL 语句、API 密钥、连接日志、计费信息、内部文档，外加 413 个私有源码仓库。

注意这份清单的构成。最敏感的不是客户数据本身，而是「客户 SQL 语句」和「API 密钥」——前者意味着客户在数据库里执行过的业务查询被完整记录并带走了，后者意味着攻击者理论上可以直接登录客户实例。这不是单点失窃，这是一次把信任链条整根拔走的事件。

第二起更荒诞。黑客用「123456」这类弱密码，入侵了丹麦 Pays ApS 公司的账户，导致丹麦中央民事登记数据库约 880 万个 CPR 编号泄露。丹麦总人口约 590 万，880 万个编号意味着几乎覆盖全民、且大概率包含历史登记人口。据丹麦公共广播机构 DR 等当地媒体报道，奥胡斯大学信息安全研究者对此事的批评一针见血：这等同于为黑客敞开大门。

两起事故的攻击手法完全不同，但死法是同一种：不是被攻破了什么高深的加密，而是在最基础的环节上没设防。一个栽在凭证管理，一个栽在控制面暴露。用一句话概括现状就是：数据库厂商的安全叙事讲得越漂亮，控制面上的欠账就越显眼。

🧱 控制面，才是数据库厂商的软肋

金句先行：数据面你护得再严，控制面裸奔等于白干。

这些年云数据库的竞争焦点在数据面：存储引擎多快、HTAP 多顺滑、Serverless 多省钱。但此次 PingCAP 事件提醒所有人，云数据库厂商真正独有的攻击面是控制面——那个负责开库、计费、记录连接日志、存放客户 API 密钥的管理系统。

逻辑链条其实很清楚：

控制面一旦失守，后果是级联的：拿走客户 SQL 语句，等于拿到了客户业务逻辑的透视镜；拿走 API 密钥，等于拿到了下一层目标的钥匙；拿走 413 个私有仓库，等于把产品的攻击手册送给了全世界潜在的攻击者。

这不是某一家厂商的问题，而是行业的普遍现象：多数中小数据平台公司功能上敢和大厂对垒，安全工程上却是欠账的。原因不难理解——安全投入不产生可直接演示的 Demo，投资人看不到，客户续约时也不为此加价。这是一个典型的「不出事没价值、出了事要人命」的投入结构。此次事件之后，估计所有云数据库厂商的 SOC 团队明年预算都能松松绑，这大概是行业被劫持着交的一笔学费。

🤖 AI Agent 正在制造新一代「内鬼」

第三条战线还没开打，但弹药已经上膛。业内已经形成一个基本共识：如果数据库用户权限卡得不够死，一个产生幻觉的 LLM 随时可能把 users 表和 transaction_logs 这类不该关联的数据 JOIN 到一起，直接泄露受监管的敏感信息。结论也只有一句：prompt 工程替代不了架构护栏。

这正是当前 AI for Data 浪潮里最危险的幻觉：团队相信一个聪明的系统提示词加几个 few-shot 示例，就足以把 Text-to-SQL Agent 放到业务分析师面前。而 Agent 一旦接上生产元数据目录，一句随口的「我们有多少用户」就可能触发一次全表扫描级别的重查询，轻则拖挂数仓，重则带出无权限可见的数据。

问题的根源在于一个架构层面的错误：把 LLM 当成授权用户接入。当 Agent 用一个高权限连接串挂在 Snowflake 或 Databricks 集群上时，它本质上是一个「对提示词极度敏感、偶尔幻觉、且永远不觉得累」的超级内鬼。你给它什么权限，它就替所有提问题的人行使什么权限。

而这场运动的规模还在扩大。LangChain 教程满天飞，向量化的 Schema 定义成了标配，每个数据团队都想在季度汇报里放一张「自然语言问数」的截图。而不少团队的普遍做法是图省事——Agent 的数据库账号权限直接给到管理员，和当年丹麦那家公司如出一辙。

对数据库和数仓厂商来说，这反而是个产品机会：谁能把「权限随人走」「查询行数熔断」「只读 Schema 硬隔离」做成 Agent 接入的默认能力，谁就在下一轮竞争中握住了真正稀缺的东西——信任。

💰 安全不是成本项，是资产负债表项

金句先行：没出事时安全是费用，出了事安全就是负债。

把三起信号放在一起看，产业逻辑已经变了。丹麦事件证明，社会对数据泄露的容忍度与数据类型强相关——880 万个公民身份编号泄露，涉及的是国民级敏感数据，后续的监管追责和信任修复成本会远超一次技术事故。PingCAP 事件证明，B 端客户评估数据平台供应商的标准必须升级：一份 SOC 2 报告已经不够，客户会开始问你的控制面架构、你的源码仓库权限模型、你的密钥轮换策略。

而 Text-to-SQL 的普及意味着，攻击面从「外部黑客 + 内部员工」两类，扩展到了「不可预测的 AI 中间层」第三类。传统的审计和防火墙模型，对这一类几乎无效——因为每一次查询都是由一条自然语言触发的，动机和边界都在模型手里。

务实的应对，与其指望某项黑科技，不如把四道防线一层层砌扎实：

对应到具体的高频痛点，可以拆成一张问题-方案卡：

值得强调的是，这些措施没有一项依赖前沿技术，全部是十年前安全教科书里的常识。真正的门槛不在技术，在于组织愿不愿意把安全从「事后消防」变成「架构评审的一票否决项」。多数团队不是不知道怎么做，而是排期永远排不上——直到勒索信出现在邮箱里。

📋 两面镜子，照出行业真实水位

把两起事件并列，行业水位一目了然：

一个处在技术链上游，一个处在治理链下游；一个拥有大量高价值企业客户，一个几乎覆盖一个国家的全部人口。两家的安全水位，却在同一年、以同样的方式被证明不堪一击。这给整个数据基础设施行业敲的警钟是一致的：客户买你的产品，本质是把最珍贵的资产托付给你，而托付的兑现物不是功能清单，是灾难发生时的最后一道墙。

结语：窗户纸要自己捅破，别等黑客来捅

回头盘一下：第一，控制面和源码仓库是云数据库厂商最被低估的攻击面，值得单独立项加固；第二，凭证治理的缺失可以把「国家级数据托管」变成一场笑话，MFA 和弱口令清理是零成本高回报的动作；第三，AI Agent 直连数据库正在批量复制「超级内鬼」，权限架构必须先于 Agent 上线重构。

往前看，随着数据要素流通和 Agent 应用铺开，数据平台的攻击面只会继续扩大，而监管对泄露事件的追责也会越来越重。安全能力的差距，正在从「合规扣分项」变成客户选型的决定性因素。对从业者而言，与其幻想着等一个万能安全产品，不如先把这层窗户纸自己捅破——在攻击者动手之前，把四道防线一砖一砖砌起来。这才是数据平台行业接下来真正的护城河。