如何避免“微盟式删库跑路”重大数据安全事件 ?

发布时间:2020-03-06


近日,又一起“删库跑路”的数据安全事件发生,而且本次事件在国内影响相当重大和广泛,300万商家生意停摆超48小时,截止事件发生第5个交易日,涉事公司股价下跌超22%,股价急速缩水超30亿港币,并初步拟定赔偿1.5亿元,整个行业共震。


这就是刚刚发生的微盟“删库事件”。令人惋惜的是该事件就发生在全国人民纷纷在家躲避疫情的时刻,本来应该是电商行业赶上重大机遇大显身手的时候,然而就在转眼间,公司因该事件进入了“至暗时刻”。


而这一切,一个IT男在家动动键盘就完成了。


据涉事公司微盟通告:2月23日19点,公司收到系统监控报警,服务出现故障,随后立刻召集相关技术人员进行定位,发现大面积服务集群无法响应,生产环境及数据遭受严重破坏。


截止3月1日晚8点,经过了整整7天7夜可以说是“战战兢兢”的努力和度日如年的“祈祷”,微盟集团终于宣布在腾讯云的协助下已全面找回了被删除的数据,并暂定将于3月3日上午9点数据恢复正式上线,真是替他们捏了一大把汗……但问题是尽管数据已恢复,那又如何呢?我们先不去说当事人故意删库的真正原因,我们要说的是,此次“删库”事件对涉事公司造成的损失是极其严重的,对300万商户关键时刻的收入影响也是不可估量的,对用户造成的平台体验和信赖度的负面影响也是短时间无法消除的,这些都不是1.5亿就能挽回的……


作为面向众多企业服务的saas平台提供者,应该尽早搭建一套完善严密的数据安全服务机制,显然当事企业事前没有足够的重视。除了微盟,相信还有很多平台或单位明知道数据安全的重要性,但并没有将数据安全做到位。类似微盟等平台的正确做法是,首先应该分析平台的敏感数据分布情况,再梳理各数据库的各类user使用场景,然后针对不同重要等级的数据库采用不同的数据安全防护手段。


比如针对客户业务数据,首先要防止被泄露和删除,那么就需要部署一个数据库防火墙。数据库防火墙“串联”在数据库访问路径中,可以对数据库访问进行SQL语句级分析和风险阻断。当有人进行此类操作时,含有相关语句的操作请求会先经过数据库防火墙,数据库防火墙则会根据企业事先配置的策略进行实时分析,发现危险行为则立即启动阻断功能,从而阻止类似事件的发生。


中安威士数据库防火墙部署图


如果没有数据库防火墙就相当于对数据库的各种操作敞开了大门,数据库用户可以对数据库数据进行无障碍“透传”访问,即使安装了网络防火墙也无济于事,因为一般网络防火墙主要针对网络层进行防护,会”无视”数据库访问内容,不会对其进行进一步分析。数据库防火墙具有非常细粒度的策略设置条件等功能,可以基于用户账号及IP、操作行为、数据库或表或列、影响行数、操作时间等等,制定灵活多变的数据防护策略,能够覆盖各种具体实际的用户使用场景,做到张弛有度,当特殊情况需要对某用户操作放行时,只需要通过必要的审批确认后由可信管理员更改一下数据库防火墙的策略即可。


以这次微盟事件为例,可以制定一条针对drop、delete、truncate等删除操作的防删除策略,禁止开发人员在生产库上执行删除操作,需要删除时可由高可信度、具有删除权限的人员经过管理者签字或UK授权后代操作,甚至可以要求管理者在场的情况下方可执行。或者根据实际情况设置操作频率和操作行数,比如5分钟删除1行数据,并进行记录,管理者定期通过日志查看操作记录,及时发现删除痕迹立即进行处理;或者按时间段允许某些操作,毕竟大家大白天一起协同工作的时候产生极端情绪的几率会小很多…


同样,对于其它各种场景也应该相应的制定全面的防护措施和相应的管理制度,以防患于未然,在此不做赘述。


作为数据安全从业企业,中安威士再次呼吁对于单位核心业务系统及重要数据,一定要做好数据安全防护工作,控制好高危操作的权限,避免安全事件的发生,千万不要麻痹大意,因小失大。试想如果微盟部署有数据库防火墙系统,事先对生产环境数据库哪怕设置一个简单的阻断批量删除相关的策略,都很难有这样惨痛的事件发生,作为一名数据安全从业者对此真是深感痛心和惋惜。


希望各单位和平台,一定要重视数据安全,谨记!


中安威士十余年来专注于数据安全,提供专业的数据安全落地方案,对数据的全生命周期、数据的存、管、用、销(存储、管理、使用、回收销毁)的全路径实现安全防护。符合网络安全法、数据安全法、等保2.0等法律法规要求,可有效减少核心数据资产被侵犯的可能性,保障正常的业务连续性。

上一条:中安威士多款产品助力疫情安全防控系统 下一条:中安威士获“北京市诚信创建企业”称号