上海某特殊部门数据泄露事件分析与启示
王福强
这次数据泄露的数据(2022-07-03)，对于黑产来说，关键元素估计之前都有了，比如常见的三元素（姓名，身份证号，电话），这次估计只能算是一个特征补充，但泄露的数据量(23.88TB)以及发生的部门还是挺有冲击性的，所以，扶墙老师想尝试梳理和分析下过程，并贡献一些七八年前还有点儿用的经验，看对大家有没有帮助；0）
事件始末
Sample数据看起来是ElasticSearch的备份数据，而备份则是放在某云服务的OSS（对象存储服务）上， 估计是负责项目的开发小白为了彰显自己技术“牛逼”或者其它什么不为人知的目的，TA把访问OSS服务的代码贴到了位于CSDN网站的个人博客上， 而贴的代码里明哄哄地把硬编码到代码里的accessKey也一起贴出来了，从而导致别有用心之人拿到了这批备份数据，最终以10个比特币的价格在某个地方销售。 而为了让买家信服，对方也放出来三个文件大约75K的Sample数据供潜在买家查验。
整个事件还原不一定就是真相，但还算说得过去吧？！ 说白了，钥匙随便扔，丢了东西，怪谁呀？！
尝试复盘
如果要故障定级，那肯定P0级安全事故打不住。
如果要追责，那研发团队肯定跑不了，正常来说，从上到下一起追责。
如果安全部门不归技术或者研发团队管，那么安全团队也需要追究次级责任，因为没有做好关键服务和数据的流量监控，以及日常安全巡检。
至于有些人说运维也有责任，这个多少有点儿扯了，估计平常甩锅给运维习惯了吧，其实“正规军”机构里，运维只要保障基础设施的供应与运行平稳就可以了。这个事情，扶墙老师觉得，原则上跟运维没关系。
应对之策
组织人来人往，水平参差不齐，这种事儿其实很难完全杜绝。
真要做点儿事儿，倒是可以很大程度上减少类似事件发生的概率。
首先，研发流程管理需要加强，尤其是基础研发流程管理，mmp，代码审查（Code Review）你起码得做呀，做了也不至于发现不了小白把accessKey硬编码到代码里吧？ 进一步讲，你的CICD pipeline里集成下代码扫描是不是也能发现？
另外，技术管理制度和技术文化建设也得加强，丫的一点儿安全意识都没有，怎么能把accessKey贴到外网博客呢？ 老鸟儿肯定不会这么干啊~
其次， 安全团队的日常工作要做好，异常流量监控、代码扫描、日常巡检，一个都不能少啊！更多措施，比如数据分级管理与防护，能催促上的都要上吧？
最后， 扶墙老师想说，安全是一个持续的过程，如果不能体系化的规划和实施，往往就是“按下葫芦起了瓢”，企业进入成长期或者繁荣期之后，就该找安全的负责人好好搞搞信息安全的事儿了，这个做老板的人得晓得 ；）
欢迎加入「福强私学」
跨越2190个日夜，始终坚持“实践 + 原创”打造的715125字专属知识库，囊括了（但不限于）从职场、技术、管理与商业等多个板块的内容。
- 一个ChatGPT触达不到的地方
- 一个带你超越AI/人工智能的地方
- 一个与你一起成长的地方
开天窗，拉认知，订阅「福报」，即刻拥有自己的全模态人工智能。
