从微盟删库事件,看安全的本质

简介: 从微盟删库事件,看安全的本质

2月23日,国内领先的SaaS服务商微盟遭遇了恶性的删库事件,直到3月1号才将数据全面找回,各项业务逐步恢复正常。该事件暴露了中国企业长期以来在IT建设方面重业务支持和实现,而在安全运维、灾备容灾等支撑体系重视和投入不足的问题,对业界造成了极大的震撼。

image.png

image.png

2 月 23 日,因公司员工恶意破坏公司线上生产环境及数据,导致公司系统服务不可用。目前,该犯罪嫌疑人已被公安机关刑事拘留。


2 月 25 日,紧急恢复了核心业务的线上生产环境,新用户使用不受影响,并提供老用户临时过渡案。


2 月 28 日,恢复了所有业务的线上生产环境,并且开放了老用户登录,以及恢复了微站产品的所有数据。


截止到 3 月 1 日晚 8 点,在腾讯云团队的协助下,全面找回数据。


3月2日,进行数据恢复上线演练,在此期间系统会停止服务。


删库事件很多,微盟是影响最大的一次

从2月23号晚6:58分发生删库操作,到3月1日晚间发布公告宣布数据全面找回,整个过程历时1周。这次事件对微盟公司、微盟的300万客户及微盟管理团队个人都造成了严重的损失,是今年来最严重的删库事件,而这次删库的事件也带来了巨大的影响。


image.png

其实在IT行业删库事件频繁发生,大多数属于工程师在运维工作时的误操作,也有类似微盟这次主动删库的恶意攻击行为

image.png

此次微盟事件本质上是一个网络安全事件

微盟事件本质上是一个网络安全事件。网络安全从概念上来说是分层的,主要分为事件、威胁和风险三个层级,分别对应的是对抗、预防和控制:事件是网络安全里面最直接的,其内涵在于对抗,发生安全事件的时候,应急、响应、处置等都是在第一时间采取的行动;第二个层级——威胁,其内涵是预防,如果系统存在潜在的安全漏洞可能被利用,就形成了威胁。一旦发现了威胁,要马上采取办法消除漏洞。在安全行业中常常提到的漏洞扫描、风险加固、风险评估,这些都是发现威胁的手段和方法;最广泛的是风险,其内涵是控制。风险是不可避免的,但是资源是有限的,所以一般要将风险控制在可接受的范围内。为了控制风险,对于生产系统来说,业务连续性、灾难备份就是基础的技术手段。


微盟事件所暴露出来的问题


image.png

这次的删库事件暴漏了微盟在管理运维体系中的权限分配方面存在很大的漏洞,对风险的意识也比较淡薄,在业务连续性、灾难备份部分都没有做好,在事件、威胁、风险三个层面都有问题。


其实在安全行业里面,最重要的是预防,预防意识高于一切。现在中国的网络安全市场规模是600多亿人民币,每年有20%多的增长率,但是网络安全的投入占IT投入的比例,全球是3.74%,美国是4.78%,而中国只有1.84%,说明中国的企业对于安全风险的防范意识不足。微盟删库事件给国内所有的IT服务商,尤其是往SaaS和企业服务转型的这些服务商敲响了一个警钟,一定会大幅提高他们的安全意识。


网络安全行业本质上是一个以服务为核心的行业,它的复杂性在于任何一个安全体系的构成都是工具(技术)、管理制度和人三方面的结合,要符合组织的工作流程、管理制度、业务流程才能真正发挥作用。安全是攻防的过程,不能靠产品一蹴而就解决所有安全问题,还需要安全服务团队的持续投入,才能保持整个体系的安全。


安全的原则

不信任任何个人:人总会犯错,总会有疏忽的时候


只信任流程和制度:通过固化下来的流程和制度来约束


通过审计不断的迭代: 外界环境总是在变化的,需要不断的迭代流程和制度


技术人自觉才是保护用户数据的最后防线

最近几年,由于技术人员故意或者有意造成的事故不计其数。2018 年 3 月,Stack Overflow 发布了他们的开发者调查报告,并首次提出了有关道德的问题。对于“开发人员是否有义务考虑代码的道德影响”这个问题,有近 80%的人回答“是”。不过,只有 20%的人认为他们最终在为不道德的代码负责,40%的人会在被要求的情况下写不道德的代码,只有 50%的人表示在发现不道德的代码时会举报。


如果代码对世界的影响不大,那么这也许就不成问题。打个比方,如果你写了一个对 100 个人不利的算法,虽然这事不怎么光彩,但产生的影响也是有限的。但是,如果你在拥有数亿用户的 Facebook、Google、微信上做同样的事情,结果就会很严重。


对于开发者来说,光是每天写业务代码就已经让人心力交瘁了。更何况不管在国内还是国外,技术在大部分时候都是为业务服务,开发者的话语权是拗不过盈利这条大腿的。但是,遵守职业道德是最后的底线,如果技术人员做不到这一点,那保护用户数据的最后一道防线就会崩塌。


所以,技术人的自我修养,在纷繁复杂科技产物的当下显得更加关键。


相关文章
|
3月前
|
运维 Serverless 数据处理
函数计算产品使用问题之遇到生成没有反应、中止也不行,以及刷新后队列积累的问题,该怎么办
函数计算产品作为一种事件驱动的全托管计算服务,让用户能够专注于业务逻辑的编写,而无需关心底层服务器的管理与运维。你可以有效地利用函数计算产品来支撑各类应用场景,从简单的数据处理到复杂的业务逻辑,实现快速、高效、低成本的云上部署与运维。以下是一些关于使用函数计算产品的合集和要点,帮助你更好地理解和应用这一服务。
|
2月前
|
存储 Windows
删除的视频怎样才能恢复?详尽指南
误删视频别慌,本文概览实用恢复技巧。首要行动:停用涉事存储以防数据覆盖。探索回收站,检索近期删除。备份是宝藏,搜寻云或外置硬盘。软件救星谨慎付费,试用验证。极端情况,专家服务可开盘恢复,代价高昂需权衡。
删除的视频怎样才能恢复?详尽指南
|
2月前
|
安全
线程操纵术并行策略问题之ForkJoinTask提交任务的问题如何解决
线程操纵术并行策略问题之ForkJoinTask提交任务的问题如何解决
|
架构师 Java Spring
追逐影子的人,最终只会是影子
追逐影子的人,最终只会是影子
138 0
追逐影子的人,最终只会是影子
|
SQL
SQL基础【十八、事物】(sql事物慎用,还是写业务逻辑代码好一些,入伙涉及到更换数据啥的很麻烦!)(二)
SQL基础【十八、事物】(sql事物慎用,还是写业务逻辑代码好一些,入伙涉及到更换数据啥的很麻烦!)(二)
145 0
SQL基础【十八、事物】(sql事物慎用,还是写业务逻辑代码好一些,入伙涉及到更换数据啥的很麻烦!)(二)
|
SQL 数据库
SQL基础【十八、事物】(sql事物慎用,还是写业务逻辑代码好一些,入伙涉及到更换数据啥的很麻烦!)(三)
SQL基础【十八、事物】(sql事物慎用,还是写业务逻辑代码好一些,入伙涉及到更换数据啥的很麻烦!)(三)
128 0
SQL基础【十八、事物】(sql事物慎用,还是写业务逻辑代码好一些,入伙涉及到更换数据啥的很麻烦!)(三)
|
SQL 安全 数据处理
SQL基础【十八、事物】(sql事物慎用,还是写业务逻辑代码好一些,入伙涉及到更换数据啥的很麻烦!)(一)
SQL基础【十八、事物】(sql事物慎用,还是写业务逻辑代码好一些,入伙涉及到更换数据啥的很麻烦!)(一)
123 0
SQL基础【十八、事物】(sql事物慎用,还是写业务逻辑代码好一些,入伙涉及到更换数据啥的很麻烦!)(一)
|
运维 程序员 安全
如何有效避免“删库跑路”、“误操作”等事件的发生
为什么会频繁出现“删库跑路”、“误操作”等风险?究其原因,主要是因为当前企业内部的IT运维管理现状普遍存在这样的问题:很多时候企业的运维操作过程类似一个“黑盒”,运维人员的操作不受控,运维操作过程缺乏必要的监督和审核,高危甚至违规操作时有发生。
1802 0