经验教训 – 2020.02.23 微盟花23亿买下一个惨痛教训

释放双眼,带上耳机,听听看~!

经验教训 – 2020.02.23 微盟花23亿买下一个惨痛教训

  2月23日晚7点左右,微盟多个小程序显示出现未知错误,多次刷新仍未恢复正常。

经验教训 – 2020.02.23 微盟花23亿买下一个惨痛教训

  基于微盟的商家小程序也都随之宕机,一度无法打开。从23日晚间起,宕机超过24小时,线上生意基本停摆的商家不在少数。

经验教训 – 2020.02.23 微盟花23亿买下一个惨痛教训

  对此,官方一开始回应称设备物理故障,正在紧急抢修和修复。

  2月25日,微盟集团(2013.HK)发布关于系统故障的公告,称SaaS(软件即服务)业务数据遭到员工人为破坏,并表示已向上海警方报案,该员工已被刑事拘留。

  微盟集团向澎湃新闻记者发来的通告介绍,2月23日19时,微盟收到系统监控报警,服务出现故障,随后召集相关技术人员进行定位,发现大面积服务集群无法响应,生产环境及数据遭受严重破坏。随后公司启动紧急响应机制,并与腾讯云技术团队一起研究制定修复方案。

  微盟称,在事后对恶意破坏生产环境的嫌疑人进行追踪分析,定位到嫌疑人登录账号和IP地址,并于2月24日向宝山区公安局报案,目前犯罪嫌疑人已经承认了犯罪事实。犯罪嫌疑人为微盟研发中心运维部核心运维人员贺某,贺某于2月23日18时56分通过个人VPN登入公司内网跳板机,因个人精神、生活等原因对微盟线上生产环境进行了恶意的破坏。

  截至2月25日7时,微盟称生产环境和数据修复在有序进行,预计2月25日24时前生产环境将修复完成,微盟所有新用户将可恢复服务,老用户由于数据修复时间问题,将提供临时过渡方案,预计老用户数据修复可在2月28日24时前完成。

  微盟集团表示,正在拟定相关赔付方案来补偿此次事故而遭受损失的商家。微盟称:“我们对此次因人为造成的事故灾难无比愧疚,今后将一定吸取这个惨痛的教训,加强对线上运维的治理。”

  微盟还表示:“同时我们也对因远程办公而疏忽对员工的精神状态的关注而深表痛惜!”

  微盟官网显示,微盟集团成立于2013年4月,现有员工超3200人,渠道代理商超1600家,注册商户超300万,为中小企业云端商业及营销解决方案提供商,腾讯社交网络服务平台中小企业精准营销服务提供商。2019年上半年,微盟总收入达到6.57亿元,同比增长97.8%,经调整净利润为0.29亿元。

  根据微盟2019年半年度报告,SaaS产品是微盟两大业务核心之一。在SaaS产品方面,微盟的商业云产品围绕电商、零售、餐饮、本地生活、酒旅等多个垂直行业进行布局,比如为线下门店的连锁型零售商提供数字化解决方案,为商家提供餐饮小程序等。SaaS业务在2019年上半年为微盟带来了2.19亿的收入,同比增长31.1%。

经验教训 – 2020.02.23 微盟花23亿买下一个惨痛教训

  3月1日晚间,微盟官方公众号发布《微盟数据已经全面找回 并公布商家赔付计划》,这距离2月23日晚被员工恶意删库已经过去了七天。

  在微盟的这份解决方案中,除了可以看到微盟公司为此将付出1.5亿元赔偿金外(微盟出1亿,管理层出5000万,其中老板孙涛勇承担3500万元),更重要的是微盟承诺3月2日晚上10点到3月3日上午9点,才能正式进行数据恢复上线。

经验教训 – 2020.02.23 微盟花23亿买下一个惨痛教训

  2月23日删库发生,到3月3日恢复上线,一共需要整整十天时间。数百万商户因此无法营业,造成的损失和影响十分巨大。

  从微盟这份公告,我们也能找到其被员工恶意删库,恢复任务艰巨的根源:未对数据管理权限做分级,同时没有把数据上到云端。

经验教训 – 2020.02.23 微盟花23亿买下一个惨痛教训

  微盟的市值因此蒸发掉21.5亿,再加上1.5亿的赔款,损失了23亿。微盟用23亿元证明:数据全面上云要比不上云和部分上云更安全。

  这场”人祸”的根源到底是什么?

  如果说疫情是天灾,那么微盟的删库事件,则是一场典型的人祸。从微盟公布的细节,我们可以看到这家公司在数据安全方面到底犯下了哪些大错。

  第一,在思维上,没有对数据安全引起高度重视。

  没有对数据安全保障方案进行深入的评估和审查,没有聘请外部专家顾问团队对数据安全进行评估和测试,没有把数据安全管理纳入到日常管理范围。

  第二,在行动上,没有对运维人员的权限进行分级。

  这是技术部门在管理上的严重漏洞,一个小小的运维人员就能通过VPN进入公司服务器把数据全都删除。这对于一家服务数百万企业的SaaS运营商来说,真的是太不可思议。

  他们缺乏数据安全技术体系的建设,更没有前瞻性的安全设计,这着实非常不该。

  第三,在数据存储上,使用自建数据库,未执行数据全面上云。

  显然,微盟并未把所有数据都放在腾讯云上,而是放在自己的机房内。由于自己缺乏多地备份,安全防护,分级管理等安全方面的统筹,导致了严重的删库后果。

  由于没有云端数据库的快照恢复功能,导致恢复起来,十分费时费力。

  目前,许多企业在上云的过程中,和微盟一样把业务放在云上,把数据放在自己的服务器上,美其名曰:”数据资产自己掌控”。

  但是,公司又没有数据安全防护的战略思维和能力,早晚会出现类似的数据恶意删除、丢失、数据误删、黑客盗取的”人祸”事件。

  所以,微盟删库事件的”人祸”并不在于那个”精神有问题”的员工,而在于企业在数据安全上的不作为以及数据全量上云的延误。

  数据全量上云刻不容缓

  目前,产业互联网时代,几乎所有企业都与互联网相关,都面临着业务上云,还是自建服务器的双重选择。

经验教训 – 2020.02.23 微盟花23亿买下一个惨痛教训

  一些企业认为,数据是核心资产,放在自己的手里更安全。于是,在上云的过程中,就出现三种类型的企业:

  第一种:不上云。自己买服务器,自己管理硬件、软件和数据。这种企业就需要有强大的DBA团队和运维团队来进行数据库高可用性,容量扩展,数据备份。

  第二种:部分上云。这包括两类,一类是把数据中心放在自己的机房里,把业务部分上到云端,搞个类似混合云的模式。

  另一类是,把云方案当做虚拟机来使用,把数据中心的机器转到云端,但是不用云计算厂商提供的容灾、备份和扩容等服务。这两种方案,都无法享受数据上云带来的安全保障。

  第三种:全面上云。企业把所有的业务、数据全放在云端,使用云数据库,享受云计算厂商提供整套的数据安全解决方案。

经验教训 – 2020.02.23 微盟花23亿买下一个惨痛教训

  这也正是删库事件发生后,微盟数据管理变革的方向:使用腾讯云CAM权限管理系统对云资源进行管理、使用腾讯云的IAAS底层服务能力和快照策略、COS对象存储、复制等。

经验教训 – 2020.02.23 微盟花23亿买下一个惨痛教训

  另外,就是全面使用腾讯云数据库MySQL,逐步放弃自建数据库,全面迁移到腾讯云数据库。

  这样做有什么好处呢?

  首先,数据丢失可赔付。一旦客户把数据放到云上,云计算厂商就承担客户数据的安全风险,并把安全写进协议里,如果发生损失将进行赔付。

  假如微盟删库是发生在云端,相信也不用自己掏1.5亿了,甚至包括股价下跌的所有损失,都可以由云计算企业赔付。

  其次,实时快照,秒级恢复。微盟的数据库恢复花了将近10天时间,工程量之大可想而知。但是如果微盟把数据全都上到云端,则可以实现秒级的恢复。

经验教训 – 2020.02.23 微盟花23亿买下一个惨痛教训

  因为腾讯云硬盘采用分布式块存储架构,每个数据块在可用区都有3副本,可以规避物理磁盘,宕机故障导致的数据损坏。另外,通过云硬盘的快照技术,可以实现数据”秒级”恢复到一小时内的状态。

  此外,实现增量数据,快速恢复。

  如果是磁盘被删除了,还未被写入,是可以进行恢复的。但是由于数据量太大、太杂,恢复之后还要进行数据的交叉检验,以确保数据的一致性。

  一旦某些增量数据丢失,还需要人工介入重写,难度和工作量十分庞大。所以微盟要在3月2日进行数据上线演练,3月3日才能真正做恢复。

经验教训 – 2020.02.23 微盟花23亿买下一个惨痛教训

  而存储在云端的数据,通过对象存储COS可以访问指定版本号的数据,可实现数据的回滚操作,解决数据误删和覆盖的风险。云数据库CDB还能确保数据可回滚到任意时间线。

  也就是说,你想要恢复到哪里,就立即恢复到哪里。省去了数据交叉验证、匹配、跑通的大量复杂工作,大大提高了恢复的效率。

  所以,微盟花了23亿买了个惨痛教训:数据上云更安全可靠!

  笔者也相信,微盟删库事件将成为云计算行业的标志性事件,会推动越来越多的企业选择业务和数据全量上云。

给TA打赏
共{{data.count}}人
人已打赏
安全运维

安全运维之道:发现、解决问题的有效闭环

2024-4-14 20:59:36

安全运维

稳定性建设 – 架构优化的关键策略

2025-2-11 17:15:56

个人中心
购物车
优惠劵
今日签到
有新私信 私信列表
搜索