扩展阅读：网络安全系统工程与安全防御体系能力的形成资料文件与下载

作为从事网络安全研究和教学21年的老兵，我对微盟充满了同情，也感到非常遗憾，虽然它及时为我们提供了很好的教学案例。事实一次又一次证明，网络安全系统工程、技术和管理并重的重要性。这一次，相信仍然不是最后一次，因为我们在北京理工大学这么多年的课堂教学，几乎每节课都能配有冒着热气最新出炉的惨痛案例。感慨完毕，接下来，元芳该你了。

接下来，请你仔细阅读以下的新闻事件，梳理出跟本课程和网络安全有关的关键词：恶意破坏，服务不可用，VPN ，线上生产环境，监控报警，服务集群无法响应，紧急恢复核心业务，恢复线上生产环境，恢复数据，恢复上线演练，赔付，放弃自建数据库，基础设施全力上云，跨可用区，异地灾备，快照，分级授权。

2020 年 2 月 25 日，微盟发布公告称，公司线上生产环境及数据遭到员工恶意破坏，导致公司系统服务不可用。经过几天的“抢救”，3 月 1 日，微盟再次发布公告称，数据已全部找回，将于 3 月 2 日进行系统上线演练，于 3 月 3 日上午 9 点恢复数据正式上线，同时针对受到影响的商家也给出了赔付计划。

事件回溯

“删库跑路”一直是运维人员常挂在嘴边的戏谑之词，但当现实生活中真的发生了，还是让人震惊不已。相信关于微盟被删库事件，大家多少都有所耳闻，不过，为了照顾不清楚前因后果的同学，这里先为大家梳理一下整个事件的经过。

2020 年 2 月 23 日 18 时 56 分，微盟研发中心运维部核心运维人员通过 VPN 登入服务器，并对线上生产环境进行了恶意破坏；

2020 年 2 月 23 日 19 时，微盟内部系统监控报警，出现大面积服务集群无法响应；

2020 年 2 月 25 日，微盟紧急恢复了核心业务的线上生产环境，保证新用户使用不受影响，并提供老用户临时过渡方案，确保商家在数据暂时没有恢复的情况下可以正常经营；

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

3 月 1 日，微盟发公告称已全面找回数据。

微盟发布的公共中也对接下来的数据恢复工作，做了计划部署。3 月 2 日凌晨 2 点至 8 点，微盟进行数据恢复上线演练，在此期间微盟系统会停止服务，演练完成后系统数据回滚到 3 月 2 日的数据。3 月 2 日晚上 10 点至 3 月 3 日上午 9 点，微盟将正式进行数据恢复上线， 恢复 2 月 23 日之前的数据，同时将 2 月 23 日与 3 月 2 日的数据进行合并，完成所有的数据恢复工作。

微盟事后处理方法

根据公开资料显示，微盟目前的渠道代理商超 1600 家，注册商户超 300 万。此次微盟宕机或导致 300 万商家生意停摆，损失巨大。因此，微盟也公布了商家赔付计划，整体准备了 1.5 亿元人民币赔付拨备金，其中微盟公司承担 1 亿元，管理层承担 5000 万元。

针对商家因系统不可以而造成的不同损失，微盟也制定了不同的赔付方案：

现金赔付计划

针对因系统不可用而造成利润损失的商户，微盟将按照商家边际贡献利润额进行赔付，具体公式计算如下：

边际贡献利润额 = 日均收入×行业平均边际贡献利润率×系统故障时间

流量赔付计划

针对因系统不可用而造成流量损失的商户，微盟将给予腾讯广告 50000 曝光次数的流量补偿，并且提供账户运营服务，同时再延长 SaaS 服务有效期两个月。

放弃自建数据库，基础设施全力上云

以上是经济方面的赔偿，在技术方面，此次核心运维对微盟生产环境和数据造成破坏，使得商家对微盟系统安全和稳定性产生了质疑，同时也给微盟自己敲响了警钟。

微盟在 3 月 1 日发布的公告中称，微盟将会支持基础设施全力上云，逐步放弃自建数据库服务 ，迁移到腾讯云数据库（CDB），增加数据库跨可用区和异地灾备的能力，同时将黑石 1.0 物理机全面升级黑石 2.0，全面使用云主机。

除了之外，微盟还宣布将加强数据安全管理机制和安全灾备体系建设。

据了解，微盟将使用腾讯云 AM 权限系统进行云资源管理，严格执行分级授权和最小集权限制度，对高危险动作执行二次授权制度。针对开发环境、测试环境和生产环境进行严格隔离，使用云堡垒机替换自建堡垒机，进行细粒度权限分级和授权管理，严格审计操作日志，发送安全审计报表。

同时，微盟将在北京、上海、南京等地区建立全备份的冷备系统架构，并建立高可用的同城双活架构，所有云主机启用每天快照策略，保证全量和增量备份，所有非结构化数据库使用腾讯 COS 对象存储系统归档保存，启用多异地复制功能，数据存放多地，COS 冷存储，确保数据只增不减。

删库事件如何避免和补救？

回顾最近几年的删库事件，我们发现并不在少数，删库原因也各种各样，有误删，有介质损坏，也有人为删除的。

2015 年 5 月，携程员工操作失误，删除了生产服务器上的执行代码，导致官方网站和应用程序大面积瘫痪，无法正常使用；2017 年 1 月，开源代码托管平台 GitLab 系统管理员对数据库进行日常维护时，无意中运行了数据库目录删除命令，导致 300GB 的原始数据只保留了 4.5G，GitLab 被迫下线。

微盟被删库事件，引发了运维领域众多技术专家和从业人员的讨论，针对如何预防删库，如何恢复数据，纷纷提出了自己的观点。我们整理了部分技术专家针对此提出的建议：

人肉运维是隐患

“直接在生产环境中敲命令是一种非常不好的习惯。”左耳朵耗子曾表示，一个公司的运维能力的强弱和上线上环境敲命令是有关的，越是喜欢上线敲命令你的运维能力就越弱，越是通过自动化来处理问题，你的运维能力就越强。真正良性的运维能力是——人管代码，代码管机器，而不是人管机器。你敲了什么命令没人知道，但是你写个工具做变更线上系统，这个工具干了什么事，看看工具的源码就知道了。

数据备份系统足够强

系统是需要做数据备份的，但有时就算所有的备份都可以也会避免的出现数据丢失。左耳朵耗子表示：“如果你要让你的备份系统随时都可以用，那么就要让它随时都 Live 着，而随时都 Live 着的多结点系统，基本上就是一个分布式的高可用的系统。因为数据丢失的原因有很多种，比如掉电、磁盘损坏、中病毒等等，而那些流程、规则、人肉检查、权限系统、checklist 等等都只是让人不要误操作，都不管用，这个时候，你不得不用更好的技术去设计出一个高可用的系统！别无它法！”

上云是个好方法

技术专家认为数据放在云端的保险系数还是相对较高的，因为云端有足够多的公共资源作为支撑。其中，快照和异地远程复制灾备服务是云端提供的非常好用的功能，建议大家使用。当发生数据删除时，可以使用快照迅速恢复或者回滚到某个历史时刻，然后再通过其他方法补平到最新数据状态；而云端异地远程复制灾备服务也是比较成熟的技术，相比本地实施的容灾，初期投入更加划算。

建立分级授权机制

即使数据容灾做得再好，也难以避免内部人员的主动破坏，因此建立分级授权机制是很有必要的，高危操作必须多人仲裁表决才能执行。