上海某特殊部门数据泄露事件分析与启示

这是王福强的第172篇原创

这次数据泄露的数据(2022-07-03)，对于黑产来说，关键元素估计之前都有了，比如常见的三元素（姓名，身份证号，电话），这次估计只能算是一个特征补充，但泄露的数据量(23.88TB)以及发生的部门还是挺有冲击性的，所以，扶墙老师想尝试梳理和分析下过程，并贡献一些七八年前还有点儿用的经验，看对大家有没有帮助；0）

1 事件始末

Sample数据看起来是ElasticSearch的备份数据，而备份则是放在某云服务的OSS（对象存储服务）上， 估计是负责项目的开发小白为了彰显自己技术“牛逼”或者其它什么不为人知的目的，TA把访问OSS服务的代码贴到了位于CSDN网站的个人博客上， 而贴的代码里明哄哄地把硬编码到代码里的accessKey也一起贴出来了，从而导致别有用心之人拿到了这批备份数据，最终以10个比特币的价格在某个地方销售。而为了让买家信服，对方也放出来三个文件大约75K的Sample数据供潜在买家查验。

整个事件还原不一定就是真相，但还算说得过去吧？！说白了，钥匙随便扔，丢了东西，怪谁呀？！

2 尝试复盘

如果要故障定级，那肯定P0级安全事故打不住。

如果要追责，那研发团队肯定跑不了，正常来说，从上到下一起追责。

如果安全部门不归技术或者研发团队管，那么安全团队也需要追究次级责任，因为没有做好关键服务和数据的流量监控，以及日常安全巡检。

至于有些人说运维也有责任，这个多少有点儿扯了，估计平常甩锅给运维习惯了吧，其实“正规军”机构里，运维只要保障基础设施的供应与运行平稳就可以了。这个事情，扶墙老师觉得，原则上跟运维没关系。

3 应对之策

组织人来人往，水平参差不齐，这种事儿其实很难完全杜绝。

真要做点儿事儿，倒是可以很大程度上减少类似事件发生的概率。

首先，研发流程管理需要加强，尤其是基础研发流程管理，mmp，代码审查（Code Review）你起码得做呀，做了也不至于发现不了小白把accessKey硬编码到代码里吧？进一步讲，你的CICD pipeline里集成下代码扫描是不是也能发现？

另外，技术管理制度和技术文化建设也得加强，丫的一点儿安全意识都没有，怎么能把accessKey贴到外网博客呢？老鸟儿肯定不会这么干啊~

其次， 安全团队的日常工作要做好，异常流量监控、代码扫描、日常巡检，一个都不能少啊！更多措施，比如数据分级管理与防护，能催促上的都要上吧？

最后， 扶墙老师想说，安全是一个持续的过程，如果不能体系化的规划和实施，往往就是“按下葫芦起了瓢”，企业进入成长期或者繁荣期之后，就该找安全的负责人好好搞搞信息安全的事儿了，这个做老板的人得晓得 ；）

朋友们随手“在看”与“分享”就是对我最大的支持！