连数据库厂商都被拖库了

一周内两条新闻放在一起看，颇有些黑色幽默：一家以『数据』为生的数据库公司，被勒索组织宣称偷走了 10.6TB 数据和 413 个私有代码仓；而一个北欧国家的全国公民身份登记库，据说倒在了六个字符——'123456'——上。再叠加 AI 浪潮下越来越多 Text-to-SQL 智能体直连生产库，数据基础设施的攻击面，正被从三个方向同时撕开。

本文的判断很直接：AI 时代数据平台的竞争，正在从『谁的查询更快、谁的湖仓更统一』，转向『谁先把安全底座补齐』。这不是合规部门的事，这是产品力本身。

三起事件，三个不同的入口，指向的却是同一种结构性缺陷：护栏建在了错误的层上。

🔓 卖数据库的，最不能丢的就是数据

先看最扎心的一起。PingCAP 近日确认其内部系统遭到未授权访问，源代码与客户相关数据被盗。勒索组织 FulcrumSec 宣称拿走了 10.6TB 数据，清单读起来令人头皮发麻：TiDB Cloud 控制面记录、客户 SQL 语句、API 密钥、连接日志、计费信息、内部文档，以及 413 个私有源码仓库。

业内人士私下流传一句话：『卖数据库的，最不能丢的就是数据。』这次丢的不只是数据，是信任本身。

为什么这份清单如此致命？拆开看三层：

第一，控制面是新的皇冠宝石。 过去大家盯着数据面——库里的行和列。但云数据库的控制面里躺着的是租户拓扑、连接配置、计费关系，等于一张完整的客户地图。拿到控制面，等于拿到了所有客户的大门钥匙串。

第二，SQL 语句本身就是商业机密。 很多企业没意识到，一条条查询语句背后是业务逻辑：谁在看哪些数据、报表口径怎么算、哪些表关联了哪些表。对竞对或者攻击者而言，这是一份免费的『业务逆向工程报告』。

第三，413 个私有代码仓意味着供应链风险整体抬升。 数据库内核、云管平台的代码一旦外流，攻击者可以慢慢审计、批量找洞。这不是一次性泄露，而是一份长期有效的『漏洞订阅服务』。

对整个产业而言，这起事件划出了一条新红线：B2B 数据服务的安全事件，外溢半径等于客户总数。 厂商被打穿，等于所有客户的信任同时被打穿。采购 TiDB Cloud 这类托管服务的企业，未来评估清单里『控制面安全架构』的权重，恐怕要排到性能参数前面。

🔑 一个全国级系统，倒在了六个字符上

如果说 PingCAP 的事件还算『高级对抗』，丹麦这件事则荒诞得像段子。

黑客利用 '123456' 等弱密码，入侵了丹麦支付服务商 Pays ApS 的账户，进而导致丹麦中央民事登记数据库约 880 万个 CPR 编号泄露。丹麦全国人口约 590 万，880 万这个数字意味着几乎覆盖了所有在册公民，含历史记录。奥胡斯大学 的教授批评称，这等同于为黑客敞开大门。

这条链路最讽刺的地方在于：丹麦 CPR 系统本身是全世界数字化程度最高的民事登记体系之一，但整条防线被一个外包环节的管理员密码击穿。

这揭示了政务与大型数据工程的一个残酷规律——安全强度等于供应链上最弱的一环，而最弱的一环往往不在你自己的机房里。 政府机构、大型平台把数据访问权授予第三方服务商时，本质上是在为自己的安全背书做担保，却往往连对方有没有强制 MFA 都不知道。

另一个更冷的判断是：身份编号这类数据泄露是『不可轮换』的。 密码泄露可以改，银行卡可以挂失，但 CPR 编号跟人一辈子。这意味着它的泄露成本不是一次性结算的，而是像一笔永续负债，在未来每一次身份核验、每一次反欺诈校验中持续计息。

对国内正在推进数据要素流通的从业者，这条经验可以直接抄进制度设计：凡是涉及不可变更标识符（身份证号、统一社会信用代码等）的数据授权，代理机构必须纳入同等强度的基线管控——强制 MFA、密码策略、最小权限、定期审计，一个都不能少。花哨的零信任方案救不了 '123456'。

🤖 你亲手给 AI 开了个根账号

第三条战线最前沿，也最容易被低估：Text-to-SQL 智能体。

一位在一线做了三个月 Text-to-SQL 落地的工程师描述了这样一个场景：他眼看着一个 LLM『热心地』试图把 users 表和 transaction_logs 做 JOIN——如果没有库级权限卡得足够死，那几乎就是一次 HIPAA 监管数据的泄露。他所在的另一个团队，智能体在被问到『我们有多少用户』时，对整个元数据目录执行了 SELECT ，差点把数仓直接打挂。

他的结论很尖锐：当前 AI 炒作周期里最危险的迷思，就是认为一个 RAG 架构的 Text-to-SQL 智能体『聪明到』能分清只读报表 schema 和客户 PII 表。它分不清，也不在乎。

业内已经开始出现更直白的说法：把提示词工程当成安全护栏，等于把保险柜密码写在保险柜上。

问题的根源不在模型层，而在架构层——多数团队把 LLM 当成了一个『授权用户』来接入数据库。 一个没有入职背调、没有权限评审、没有离职交接、却拿着生产库连接串的『员工』，在任何一家正规公司的 IT 治理流程里都是不可接受的。但过去两年，成千上万个这样的『员工』通过 LangChain 等框架，被批量塞进了 Snowflake、Databricks 集群。

看这张定位图就明白了：AI 数据代理目前整体处在『隐患区』向『重灾区』迁移的路径上——防护普遍不成熟，而它触碰的数据价值却在快速上升。治理动作必须前置。

🛡️ 护栏不是提示词，是架构

把三起事件摆在一起，会发现一个反直觉的事实：没有一起靠 0day 漏洞完成突破。 弱口令、控制面失守、权限缺位——全是基线问题。

这才是最值得产业警惕的地方：大量安全预算被花在对抗高级持续性威胁上，而真正的失血点是最朴素的密码策略、密钥管理和权限设计。安全预算的错配，比攻击本身更致命。

落到工程层面，数据平台团队需要把三件事从『待办』提升为『红线』：

其一，控制面与数据面物理隔离。 管理通道独立认证、独立网络、独立审计，控制面密钥定期强制轮转。云数据库厂商尤其如此——你守的不是自己的数据，是所有客户的数据。

其二，给 AI 智能体发『工牌』，而不是『万能钥匙』。 独立最小权限账号、只连只读副本、行列级安全与动态脱敏、查询超时与成本熔断、全量审计日志。一句话：让智能体在数据库层就跑不出格，而不是指望它『自觉』。

其三，供应链纳入同等基线。 凡是能触达你数据的外部机构和工具，都按内部系统标准审计。丹麦的教训已经足够清楚。

`infographic

{"type":"problemsolution","title":"AI数据链路的安全解法","items":[{"problem":"把LLM当授权用户直连生产库","solution":"独立最小权限账号，只连只读副本"},{\"problem\":\"拿提示词当安全护栏\",\"solution\":\"行列级权限、动态脱敏与审计日志\"},{\"problem\":\"失控查询拖垮数仓\",\"solution\":\"查询超时、限流与成本熔断\"},{\"problem\":\"控制面与数据面混用\",\"solution\":\"控制面隔离、密钥轮转、全链路审计\"},{\"problem\":\"供应链环节基线缺失\",\"solution\":\"外部接入方按内部标准强制审计\"}]}\n`\n\n对数据基础设施厂商来说，接下来两年的分化会很残酷：功能清单上的差距越来越小，而一次安全事故足以让客户名单清零。安全，正在从成本中心变成数据平台的准入门槛和卖点。\n\n---

三条战线，一个结论。PingCAP 的 10.6TB、丹麦的 880 万、以及那些正在悄悄连上生产库的 Text-to-SQL 智能体，共同宣告了一个旧时代的终结——靠性能参数和功能清单卖数据平台的日子，正在过去。\n\n接下来的分水岭是安全底座：控制面是否隔离、密钥是否轮转、AI 代理是否被当成了受限用户。对数据团队，把这三件事当作 2026 年的第一优先级；对厂商，把安全能力写进产品手册而不是合规附录。数据要素流通越活跃，攻击面越大——先补底座的人，才拿得到下一轮船票。"}