2019年，互联某大型电商平台的网泄一名运维工程师在GitHub上创建了一个私人仓库，用来备份日常脚本。密案他没想到的互联是，仓库默认是网泄公开的。更没想到的密案是，里面有一个文件叫`config_prod.yaml`，互联明文写着生产环境数据库的网泄账号密码。这个仓库挂了整整八个月才被人发现。密案发现的互联人没有报告平台，而是网泄直接连上了数据库，导走了三百万条用户订单记录，密案挂在暗网上卖了两千美元。互联

这不是网泄孤例，甚至算不上最离谱的密案。

我跟踪过不少公开披露的泄密事件，发现一个规律：大多数事故的起点，都不是什么高级持续性威胁，而是某个员工在某个普通的工作日下午，做了一件他觉得“应该没什么问题”的事。把生产数据复制到测试环境调试bug，用个人邮箱转发一份“就自己看”的报表，在群里发一张截图忘了打码。这些动作单独看都不致命，但它们共同指向一个事实——数据在组织内部是流动的，而流动的路径上，防护往往是最薄弱的。

2021年，国内一家做智慧城市的中型公司出了事。起因是一个后端开发把公司内网的GitLab地址和一组测试账号密码贴在了CSDN的一篇技术博客里，为了“方便同行交流”。那篇博客阅读量不到两百，但爬虫抓到了。攻击者用这组账号进了内网，花了三周时间横向移动，最终拿到了他们给某地方政府做的舆情监控系统的后台权限。系统里存着几十万条市民投诉记录，包含姓名、电话、住址。事情是怎么暴露的？一个市民接到了精准诈骗电话，对方能报出他上个月投诉过什么。他报了警。

你看，泄密这件事的因果链条有时候拉得很长。从一篇无人问津的博客，到一个市民的报警电话，中间隔了几个月、好几层网络、无数个本可以截断的节点。但每一个节点上，都没有人觉得“这是我的责任”。

还有一个案例我印象很深。某银行省分行的科技部员工，离职前把自己参与开发的一个中间件源码打包带走了。他不是为了卖钱，就是觉得“自己写的东西，留个纪念”。半年后他入职了新公司，顺手把这份代码用在了新项目里。新公司的安全审计发现了代码里硬编码的一个内部API密钥，这个密钥居然还能用——银行那边一直没吊销。审计报告写得很克制：“存在未授权访问风险。”翻译过来就是：任何人拿着这个密钥，都能查到该银行部分客户的账户余额和交易流水。

这些事的共同点是什么？不是技术漏洞，是人的判断失误。而人的判断失误之所以能造成这么大破坏，是因为数据本身太集中、权限太宽松、审计太滞后。一个普通员工能接触到的数据量，可能比十年前一个部门能接触到的都多。但对应的管控手段，很多时候还停留在“信任员工”的阶段。

我自己的习惯是，每看到一个泄密案例，就去翻它的判决书或者处罚决定书。看多了会发现，罚款金额往往和企业规模、数据量级完全不成比例。有一家医院因为系统漏洞泄露了十几万患者信息，最后被罚了五万块。五万块，在北京连一平米房子都买不到。这种处罚力度下，安全投入在财务报表上永远是一行可以被压缩的成本。

所以每次有人问我“怎么防止泄密”，我都觉得这个问题问错了。更该问的是：你愿意为“不出事”付多少钱？这个数字如果定得太低，那所有的安全策略都只是贴在墙上的标语。真正有效的防护，是从承认“人一定会犯错”开始的。默认员工会犯错，默认权限会被滥用，默认数据会被带出去。然后在这个前提下，去设计即使犯错也不会造成灾难的系统。

听起来很悲观。但安全这件事，本来就不该建立在乐观假设上。