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

王福强

2022-07-05



这次数据泄露的数据(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贴到外网博客呢? 老鸟儿肯定不会这么干啊~

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

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


>>>>>> 更多阅读 <<<<<<


©王福强个人版权所有, All Rights Reserved.