内容摘要：6月12日凌晨两点，安全运营中心值班同事被一条告警炸醒：某台Web服务器在十分钟内向境外IP传输了约3.2GB压缩数据。溯源后发现，攻击者利用的是一个三年前就该下线的测试接口，接口里硬编码了数据库账号

6月12日凌晨两点，信息泄露安全运营中心值班同事被一条告警炸醒：某台Web服务器在十分钟内向境外IP传输了约3.2GB压缩数据。安全溯源后发现，整改攻击者利用的报告是一个三年前就该下线的测试接口，接口里硬编码了数据库账号密码。信息泄露更离谱的安全是，这个账号拥有读写全库的整改权限。

问题摆在这里，报告没什么好绕的信息泄露。这次泄露的安全根本原因不是黑客技术有多高明，而是整改我们自己在资产管理和权限控制上留了后门。测试接口长期未下线，报告账号密码明文写在代码里，信息泄露权限没有做最小化限制。安全三件事只要有一件做到位，整改这次事故就不会发生。

一、已经做了什么

发现告警后四十分钟内，我们切断了该服务器的外网访问，封禁了涉事账号，并对全量数据库做了快照备份。当天上午十点，临时补丁上线，所有硬编码凭据被移除，改走密钥管理服务。下午三点，安全团队完成了对近三十天数据库访问日志的排查，确认除该IP外没有其他异常访问源。受影响数据集中在用户订单表的手机号字段，约七万条记录，已按法规要求向监管部门提交初步报告。

说实话，这个响应速度不算差，但属于亡羊补牢。真正该做的是让这种接口根本不存在。

二、接下来要堵的窟窿

第一件事，把所有历史遗留接口和测试端点做一次地毯式排查。不光是Web层，包括内部RPC、定时任务脚本、运维工具里的临时通道。每个接口必须有明确的责任人和下线时间，没有例外的“先留着”。

第二件事，凭据管理全面切换到Vault。代码仓库里禁止出现任何形式的明文密码、密钥、Token。CI流水线加一道扫描，检出即阻断合并。这事之前提过两次，都被“影响开发效率”挡回去了。现在看，效率再高也抵不过一次泄露的代价。

第三件事，数据库权限按服务拆分。每个微服务只能访问自己那张表，不允许跨库查询。运维人员的生产库权限改为临时申请、限时生效、操作录屏。这套流程实施起来麻烦，但必须做。

三、关于责任和反思

这次事件暴露的不只是技术债。安全团队半年前就提交过测试接口清理计划，排期被压到了Q4。开发团队觉得“内网接口没人知道”，运维团队觉得“账号权限大点方便排查”。每个环节都觉得自己那点妥协无关紧要，叠在一起就是这次的结果。

我不打算写什么“高度重视、深刻反思”之类的话。实际点说，安全不是靠一次整改运动能解决的。下周开始，每周三上午十点，安全、开发、运维三方开三十分钟站会，过一遍新增接口和权限变更。谁没来，谁负责的接口就默认冻结。这个规则先跑三个月，看效果再调。

另外，这次泄露的用户手机号虽然不涉及密码和支付信息，但足以支撑精准诈骗。我们已经给受影响用户发了短信提醒，客服那边也加了话术。如果后续出现仿冒客服的诈骗案例，法务会配合用户追责。该承担的我们不躲。

整改报告写到这里，没有总结陈词。漏洞已经堵上，流程正在改，监控规则加了十七条。下一次如果还出问题，那说明这套机制本身有毛病，到时候再改。