微盟“删库”背后的经验教训

大多数成熟 SaaS 企业都会建立科学的部署架构,内部分工和运维规范。如果没有这些规范存在,组织无法获得任何第三方的质量认证。

 

任向晖在文章中,用“易懂的文字”来说明了真正的“规范”应该做到三个方面:

 

1)高可用的架构。

 

通过几乎实时同步的主从服务关系(应用和数据都可以实现),让单一服务出现问题的时候可以瞬间切换到其他镜像服务。这个架构也可以用来均衡不同访问路由的负载。

 

 2)在异地增加冷备份。

 

这个冷备份虽然有一定的延时,但是可以起到关键的数据保全作用。为了足够的安全,冷备份应该不止一份。为防范服务商系统性故障,冷备份最好分布在不同的云主机服务商。明道云的数据备份分布在UCloud、阿里云和腾讯云三个服务商。虽然冷备份非常偶然地被使用,但SaaS公司都在支付这些冗余存储的成本。

 

 3)最关键的管理分权。

 

原则上,生产服务器的运维管理权只限于极少数人即可,因为研发团队并不需要访问真实的生产环境,他们在模拟的研发环境中调试即可。计算机安全体系允许将主机运维、数据库管理和其他系统管理的权限全部分开,分别授予不同的人员,并且所有的访问行为均会保存日志,就连日志数据也是可以分权管理的,这使得单个人破坏全部服务的可能性为0。微盟事件的主要原因肯定是疏忽在这个环节。

 

在通俗一些说,上述问题1与2属于技术范畴,而问题3则属于公司内部管理问题。任何一环出现问题,都会增加SaaS平台的数据风险和安全风险,而安全事件的根源,往往在于管理。

 

另一篇评论文章基于微盟事件声称,“99%的SaaS都有安全隐患”。但显然,业内人士大多并不认同这样的说法。

 

对此说法,任向晖认为,“这是偷换了一般安全隐患和安全灾难的区别。计算机网络和软件的漏洞的确是常见的,但它们的破坏力非常有限,即使是严重的D0级(需要当天立刻修复)缺陷,也不至于造成完全的数据灭失后果。”

 

同样向电商行业提供SaaS服务的有赞平台,也在微盟事件后第一时间,收到了来自多家客户、投资人方面的疑虑和咨询。

 

CTO 崔玉松在接受钛媒体(微信ID:taimeiti)采访时说,“为了逼自己重视,2013年我们给自己列了第一信条‘系统稳定高于一切’,2017年1我们推出‘有赞护航’计划,如果出现微商城核心服务不可用,影响了客户的生意,就按照不可用时间给予对应102.4倍的补偿。这是整个信息服务行业里没有的最高规格的‘承诺’。我们有严格的访问控制,做了角色分离、权限隔离,杜绝少数人就能进行高危操作,制定了严重宕机的处理预案。”

 

崔玉松也告诉钛媒体(微信ID:taimeiti),有赞的CTO和CEO都没有可能用一台电脑、一套账号密码完成彻底删库动作。

 

在IaaS云的层面,有赞的主要的服务商有腾讯云、Ucloud两个,而且在两家平台上相互备份。

 

“(我们的数据)在每个服务商的不同的机房里有备份。退1万步讲,即使一个云服务商出现问题,我们在技术上都可以自动切换到另一个云服务上,并且从技术的角度、从数据的角度,我们可以在5分钟之内基本上恢复95%的流量。”

 

崔玉松对有赞平台抗风险能力的预估是,“遇到非常极限的灾难的时候,我们可能最长的时间——按我们现在预估——大概30分钟可以完全恢复。”

 

管理问题是根源

对微盟事件的归因,业界主流声音是:没有施行管理分权。

 

钛媒体(微信ID:taimeiti)查阅公开资料发现,微盟的确存在这种权限管理过松的可能。微盟 CTO 黄骏伟曾在一次公开分享中提到,微盟正处于高速成长期,微盟的技术团队从最初的三四十人已经扩充到了六七百人。

 

为了应对研发管理的繁杂,让技术研发跟上公司快速扩张的脚步,微盟施行了项目负责人制度。在这一制度下,每个项目汇总到一个负责人,并使得该负责人能够调动尽量多的资源来协同他做事。“每个团队事事都还要汇报到CTO这里,那无疑是非常低效的。”黄骏伟说。

 

而身为核心人员的贺某,或许恰是某个项目具有高权限的负责人。

 

“删库”事件影响下,百万级的平台商户均陷入了网店关闭、无法登陆和交易瘫痪的窘境,对于微盟提出的“6天才能恢复数据库”,6天(甚至还不确定的周期),对于任何一家平台商户而言,损失惨重。

 

针对“至少6天”来完成数据恢复的公告,一种说法是,微盟没有做数据双活方案/异地备份,才导致删除一个主库之后,多天无法恢复;也有人认为,微盟使用了便宜好用的MySQL,没有用商业级别的Oracle或DB2

 

更确切的消息,据《中国经营报》报道,微盟的底层架构采用的是混合云模式,部分自建部分上云,而微盟被删的数据恰好是没有上云的自建部分,这种做法会导致没有上云部分的数据在被删除之后无法及时恢复。

 

“如果在云上,云数据库的备份功能能够保证哪怕是删了数据,也能回滚到之前的某个时刻,把损失降到最低。”一位云计算业内人士表示。

 

针对这一问题,@腾讯云 在官方账号中也对云数据库这一问题进行了回复。腾讯云称,”在微盟事件中,微盟使用的云数据库在这次事故中没有受到影响”。这一声明或侧面证实,事故中实际上出问题的是微盟本地化部署的数据。

 

当下,混合云模式是云计算界较为青睐的资源部署模式。但钛媒体(微信ID:taimeiti)呼吁,采用本地化部署以及混合部署的企业,一定要做好本地部署数据的备份和防护,降低类似事故风险。

 

有赞CTO崔玉松针对中小商家的经营数据安全,提出了如下建议

 

1)要注意店铺管理员的角色分离、权限隔离,定期查看后台的操作日志;

 

2)需要高级管理员的验证码来做二次验证的,一定要搞清楚员工在做什么重要操作;

 

3)通过API授权的方式,从有赞云调取店铺数据到其他第三方应用,应注意调取的接口类型。和安卓手机权限一样,多余的权限不要授予。

 

4)严格控制有表格数据导出权限的高级管理员的数量,密切监控数据导出的用途。

 

5)离职员工要第一时间删除管理员权限。

原文地址:https://www.cnblogs.com/bluestorm/p/12501124.html