日本经济新闻（Nikkei）泄了 183 万条记录，入口不是什么高级漏洞——是它「用于系统开发的云服务」上一批此前就被泄露过的凭证。
时间线很短：2026 年 10 月 7 日上午，攻击者拿着现成的凭证登进了那套开发用云服务。之后统计出 183 万条记录被盗，其中约 168 万条不含可识别个人信息。发现后吊销了被盗凭证，通报了监管；到 10 月 16 日为止，没发现被盗个人信息被滥用。事件范围和数据类型还在查。
老套路：被盗凭证 + 云上环境。没有 0day，没有打洞，拿钥匙开门就行。
但这个案例我建议单独拎出来看，因为它踩的是运维里最普遍的一条偏见——开发、测试环境被当「二等公民」。
现实里，生产环境往往被盯得死死的：有堡垒机、有审计、有权限审批、有加固基线。而开发/测试环境呢？一堆共享账号、长期有效的密钥、为了「方便联调」开放的端口、直接连着生产数据副本的库。名字叫「开发环境」，可它握着的往往是最全的那份数据。
Nikkei 这次的入口恰好是「用于系统开发的云服务」，不是生产系统。攻击者也不傻——哪里门最松、钥匙最好用，就从哪里进。
所以真正要改的不是某一台机器，是这套分级思路：开发和测试环境的凭证，得和生产一样定期轮换；共享账号该拆成个人身份；连生产数据副本的那条路要有单独的审批；云凭证用短期的，别在配置文件里躺成年货。
做批量巡检的时候我也有个感受：生产机器再乱，至少有人天天看；开发机、跳板机、临时拉起来的环境，才是最容易被遗忘的那批。用七亿批量远程管理工具做批量盘点，能顺手把这些「没人管的机器」也拉进清单里——它们往往才是凭证躺平最多的地方。
这类「入口是凭证、不是漏洞」的事，前几天刚写过一堆：7 分钟加密 3.6PB，运维 7 小时还在重启、一行 18 年前的代码，一个请求打崩 Nginx。翻来覆去都是一个理：攻击面画得再漂亮，最后破门的常常是一把没人管的钥匙。官网上关于云主机与凭证管理的一些说明，也可以顺手对照着看：七亿云主机相关说明。
评论