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

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

首先我们来了解一下事情的经过：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

安全的原则

• 不信任任何个人：人总会犯错，总会有疏忽的时候

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

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

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

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

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

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

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