数据泄露的案例
2023年3月，数据丰田汽车承认其云环境配置错误，泄露导致约215万用户的数据车辆位置信息、车辆识别码等数据在近十年间处于可被外部访问的泄露状态。这不是数据什么黑客攻破防火墙的“高智商犯罪”——就是一个存储桶权限设成了公开，谁都能看。泄露我翻过当时的数据安全报告，发现最早一次未授权访问发生在2013年，泄露而丰田直到2023年才发现。数据十年，泄露没人去查那个配置。数据
这种事在圈子里叫“配置漂移”。泄露开发人员临时开个端口测试，数据测完忘了关；运维给某个服务开了公网读写权限，泄露想着“下周就收回来”，数据然后下周来了又走，权限还在。数据泄露的案例里，真正靠0day漏洞打进去的不到两成。剩下的，全是这种“忘了”。
再说一个。2021年，一个叫“ShinyHunters”的团伙在黑客论坛上叫卖一组数据：7000万AT&T用户的姓名、地址、社会安全号码。AT&T一开始否认，说“不是我们系统泄露的”。后来安全研究员发现，这批数据的格式和AT&T内部API返回的完全一致。再查下去，问题出在一个第三方供应商——AT&T把用户数据同步给了一家做营销分析的公司，那家公司的测试环境没设密码。整个链条上，AT&T觉得自己“没泄露”，供应商觉得自己“只是测试”。7000万人夹在中间，没人问过他们。
我印象最深的一个细节来自2022年Optus（澳大利亚电信运营商）的泄露事件。攻击者后来在采访里说，他一开始只是想试试能不能访问一个公开的API端点，结果那个端点直接返回了用户数据库的查询接口。他写了个循环，从100万开始递增用户ID，每敲一次回车，屏幕上就跳出一个新用户的驾照号、护照号、医保号。他说自己“花了大概两小时，就拿到了980万条记录”。两小时。Optus的工程师后来复盘，那个API是2017年为了一个内部项目临时开放的，项目黄了，API没关。
这些案例串起来看，有个共同点：泄露的源头往往不是“被攻破”，而是“被暴露”。暴露的东西可能是一个S3存储桶、一个Elasticsearch实例、一个没加认证的API、甚至是一份被误传到公开代码仓库的配置文件。安全团队每天盯着防火墙日志、入侵检测系统、终端防护软件，但那些东西对“配置错误”基本无感——因为从系统角度看，这些访问是“合法”的，用的是正确的凭证，走的是正常的端口。
更麻烦的是，很多公司根本不知道自己有哪些数据、存在哪里。2020年Marriott（万豪）第二次泄露，涉及520万客人信息。调查发现，他们收购喜达屋之后，两边的IT系统一直没完全合并，喜达屋那边有个老数据库，万豪的安全团队压根不知道它还在跑。攻击者就是从那个“被遗忘的角落”进去的。你没法保护你不知道存在的东西。
我自己的判断是，数据泄露的案例看多了，会发现技术问题其实好修——打个补丁、加个认证、关个端口，半天的事。难的是“知道该修哪里”。这需要有人去梳理数据流、做资产盘点、定期扫描暴露面。这些活不酷，不出彩，预算申请的时候永远排在“买下一代防火墙”后面。但丰田那215万人、Optus那980万人、AT&T那7000万人，他们需要的不是更厚的防火墙，是有人记得把那个测试端口关上。
写这些不是要嘲讽谁。我见过太多团队，一个人当三个人用，上线压力大得喘不过气，配置管理全靠自觉。但数据泄露这件事，后果从来不是“自觉”能承担的。一个端口没关，可能就是几百万人的驾照号在暗网上打包出售。这中间的落差，值得每个碰数据的人停下来想一想。
```