10 月 20 日，一个叫 FulcrumSec 的组织在自家站点挂出一篇文章，标题写着 THE PINGCAP / TiDB Cloud LEAKS。
同一天，PingCAP 在安全更新页发了一份情况说明，承认部分内部经营数据被未经授权访问。
两边的说法差得很远。
攻击方说拿走 10.6TB 数据、四百九十万个文件、十八万个租户组织、十一万五千个明文 API 密钥。
官方说受影响的是部分销售线索、订单记录，以及一部分需求单，比如 SQL 优化器改进这类通用技术描述。
这两个说法可以同时成立。麻烦也在这儿。
88 次导出
先把攻击方讲的过程摆出来。这些是他们的说法。
据其披露页，入口在代码库里。他们用 PingCAP 仓库里保存的 GCP 服务账号密钥和 Azure 服务主体信息，搭了一套复制管道。
用受害者自己的云凭证，让受害者的基础设施把数据搬出来。
管道跑起来之后，从 9 月 8 日到 9 月 30 日，每六小时自动导出一次控制面的全部数据表，一共 88 次。最后一次在 9 月 30 日 06 点 02 分，UTC。
88 次，没有一次告警。
这件事有一半被官方证实了。PingCAP 后来在英文事件报告里写明，9 月 9 日到 10 月 7 日之间，未授权方使用了被盗的服务账号凭据访问内部系统、复制数据、获取源码，10 月 7 日察觉，当天开始禁用。
入口对得上。时间窗口对得上，攻击方说 9 月 8 日开始，官方说 9 月 9 日，差一天。
对不上的只有那两个数。88 次和零告警，官方一个字没提。
攻击方在文里留了一句话，大意是这家公司可是云服务提供商，投了那么多钱买安全方案，却察觉不到自己所有云服务里的数据在往外走。
这句话难听，但它指向一个真问题。导出用的是合法服务账号，流量走的是自家基础设施，从监控视角看，这就是一次正常的备份任务。
终端防护看不见这种事。能看见它的只有一样东西，异常导出量的告警。
而这一样东西，官方在自己的报告里承认要补。
两份文件
这里有个细节值得停一下。PingCAP 出了两份文件。
中文那份就是开头说的《网络安全事件情况说明公告》，10 月 20 日发。
英文那份挂在 trust-hub 底下，叫 Security Incident Report，发布于 10 月 19 日，比中文公告还早一天，写得细得多。
它确认被导出的记录包括用户名和邮箱、组织与项目关联、SQL 编辑器的文本和报错、组织项目集群的标识、客户联系人、合同条款、订单、定价、付款条件、账单配置，还有加密过的 TiDB Cloud API 密钥。
两份都是官方的，面向的读者不同，颗粒度也不同。但放在一起看，范围差得有点多。
中文公告里那句「不会对客户数据库系统和业务数据安全造成影响」，跟英文报告里承认的「SQL 编辑器文本被导出」，读者自己会对。
还有一处。中文公告说不涉及产品的安全漏洞和缺陷。英文报告的处置表里写着，外部取证公司在 10 月 12 到 13 日报告了四个漏洞，PingCAP 在 10 月 14 日前全部修完，对方复测确认四个都已修复。
四个漏洞在内部系统里，跟 TiDB 产品本身大概不是一回事。但「不涉及漏洞」和「修了四个漏洞」这两句话同时出现，中间缺一段解释。
密钥那块也有分歧。官方说导出的表里是加密值，外部公司拿了一个测试值试过，不能直接当 API 密钥用。其他可用凭据有没有流出去，还在查。
攻击方的口径是十一万五千个明文密钥，其中四万两千个当时还在生效。
这部分得等样本核验。在那之前，两边都不能当结论。
四年前的那张工单
攻击方还引了一张据称是 2022 年 8 月的内部安全工单，编号 SECURITY-22。
工单摘要里写着，集群的 root 密码可以被无条件重置。组织内的所有者、审计管理员、计费管理员、普通成员，任何一个角色都能重置该组织下所有集群的 root 密码。重置之后就能用 root 身份连进集群，改状态，读数据。
工单里还写了一句自评，大意是 root 账户权限极高，这会带来巨大的安全风险。
这张工单的真实性、是否已经修复、跟这次事件有没有关系，官方都没有确认。所以它现在只能算一条指控。
但如果它是真的，时间线就很刺眼。四年前自己写下的风险，四年后被人拿走了控制面。
客户那边怎么说
名单里出现了一串名字。Booking.com、Shopee、CAPCOM、PayPay、Pionex、NFTscan、Chainbase、百度，还有日本的 Mercari、富士通、软银、DMM、永旺、史克威尔艾尼克斯、科乐美、万代南梦宫、ZOZO、Cygames、SBI、LINE。
这份名单本身说明一件事。TiDB Cloud 在海外的游戏和金融行业扎得比很多人想的深。
被点名不等于业务库被读过。目前公开回应最完整的是 Bitget。
其大中华区负责人谢家印确认，Bitget 确实用过 TiDB Cloud，但存放在里面的是公开成交日志，这些数据本来对所有用户可见。而且已经在两个多月前停止使用。内部排查没有发现用户数据或密码之类的敏感信息暴露。
其余多数公司截至发稿没有发布同样详细的说明。
问题换了位置
先说一件确定的事。截至发稿，攻击方的说法还没有经过第三方独立核验。他们放了约 200GB 样本出来，但外部确认还在等。数字、类别、范围，两边各说各的。
所以这篇文章不打算下结论说「10.6TB 客户数据全部被带走」。那是攻击方的宣传口径。
值得看的其实是另一个问题。
两份官方文件里，我觉得分量最重的是「仍在进行」那张表的最后一行。
待办里写着一项，alerts for unusual access and large data exports。
对异常访问和大批量导出的告警。
这句话是官方自己写的。它等于承认，这条路径此前不在告警覆盖范围内。
22 天，88 次导出，没有触发任何东西。监控没坏。问题在于它压根没看这一格。
客户真正该担心的是控制面被看光之后，攻击者手里多了什么。API 密钥、集群 ID、连接日志里的服务器 IP。还有工单里贴过的生产凭据，组织结构和联系人。这些东西没有一样躺在客户的数据库里，每一件都能指向那个数据库。
保险箱没被撬，钥匙清单被抄走了。
托管服务卖的承诺是省事。你把运维交出去，换来不用半夜起来处理告警。但这次事件说明，你交出去的只是数据库这一层，交不出去的是供应商的控制面、对象存储、工单系统、代码仓库和财务系统。
风险没消失。它只是换了个地方，而那个地方你看不见。
而且转移之后，你连审计的资格都没有。88 次导出发生在别人的基础设施上，告警配在别人的监控里，日志存在别人的账号下。你是最后知道的那一批。
对还在用这类服务的团队，眼下能做的其实很朴素。控制台 API Key 全部轮换一遍，集群凭据轮换，迁移任务里存的外部库账号检查一下，过去在工单和聊天里贴过的临时密钥当作已经泄露处理。这几件事不用等官方结论。
还可以多看一样东西。对象存储的访问日志，翻一翻有没有你不认识的复制配置和定时任务。如果那边真建过管道，日志里会留痕迹。
至于第三方核验什么时候出结果，被点名的其他公司会不会发声，那是接下来几天的事。
有一点现在就能确定。这次泄露的东西，绝大部分不在数据库里。它在数据库外面那圈东西上，而那圈东西，从来不在合同的服务范围内。
