by lei.tang
本次故障及事件简要回顾（来自公开渠道推文）
- 2020年2月23日，18:56分，微盟研发中心运维部核心运维人员通过VPN登入服务器，并对线上生产环境进行了恶意破坏；
- 2月23日 19 时，微盟内部系统监控报警，出现大面积服务集群无法响应；
- 2月25日7 时，生产环境和数据部分恢复，预计25日晚24点完成生产环境修复，新用户恢复业务。老用户预计到2月28日晚上才能恢复。
- 微盟事后对恶意破坏生产环境的嫌疑人进行追踪分析，成功定位到嫌疑人登录账号及IP地址，并于24日向宝山公安局报案。目前犯罪嫌疑人已被宝山区公安局刑事拘留，犯罪承认了犯罪事实。
外界的观点描述
1、需要说明怎样的权限来约束运维？或者往外拓宽至每一个核心研发人员，如：测试，研发，DBA 这些角色中拥有高权限的人员。
1 | - 例如：rm、mv、alias等危险命令应该受到严格的制约； |
- 一个良好的运维输出能力应该是：人管代码，代码管机器，而非人管机器。
- 当约束过多，照成的流程审批过多，如何不增加额外的人力物力和财力
2、备份该如何做？
- 例如：备份事件的问题，全量备份和增量备份的校验，主从备份、异地备份等的制度
- 恢复的验证，要常演练，因为会遇到各种问题导致的恢复失败，比如：介质问题、数据问题、操作问题等
反思和总结
遇到问题，只有面对问题，解决问题，才是根本，而非甩锅。
在事出第一刻，通过排除，确定问题，也验证了安全工作的一些不足，对部分权限还未考虑到位。 后续的蛇鬼牛神全员出动，各种目的的人员，只能说感谢他们的关心。
安全圈，依靠着事件来驱动企业成长的太多，每次的事件，都是给行业带来一定的波动，也锤炼着领导，更锤炼着躺枪的负责人员，后续也就无非惩罚多少来以儆效尤了。
- 简单罗列几点思考：
- 1、工程师或者内部员工的职业道德，如加强安全意识以及法律法规教育；
- 如何避免：内部员工账号密码泄露、内部代码泄露（如上传github、码云等三方平台）、或者邮件钓鱼攻击等各种情况 安全意识培训不能少，并且要定期执行，对研发，测试，运维，产品等，乃至于拓展到全员，以及新员工入职的培训。 更高的要求：对于管理者来说，或许员工的心里建设也是一个可指引的方向吧。毕竟人是企业的核心资产。
- 2、服务器厂商的选择以及监控报警完善
- 是自建IDC，还是混合云，还是全部上云，所带来的技术支持是截然不同的，涉及的服务恢复以及数据恢复。 监控报警体系的完善，对于敏感操作的监控以及报警及时性。当然根据本次事件，监控报警也就只能起到查原因的作用了，但依然不能否认他存在的价值。要不然为啥要ELK。
- 3、梳理全网的站点，把控隔离情况
- 及时梳理所有的网站，通过内部上报，运维外网开放host解析，IP探测，等多种方式，梳理内网外开放情况，
- 严格把控QA、DEV、PL、Oline 环境的相互隔离，以及非必要外网开放项目的回归内网
- 4、权限以及角色的梳理
- 对于运维、DBA、安全实现三权分立，运维管执行，DBA管数据，安全管审计，对于执行/使用备份和存储备份的人员进行分开
- 对于角色这一块，进行最小权限执行的规定，以及同时启动角色系统平台开发，解决多平台的角色设置冗余
- 对于权限的申请，要执行多方审核，解决很多误操作，比如删数据，删文件等有意无意的操作
- 5、全盘恢复后的安全复检
- 近期三方提交了一些安全漏洞上来，发现很多漏洞都是之前没出现的功能，或者说之前已修复的，哪也就说明，恢复后的代码，出现了部分代码的回滚现象，或者说是业务迭代的时候，并没有同步安全部门。
- 哪如何去解决这样的问题呢？
- 需要多个人互相校验平台，每个人都有各自的漏洞挖掘思路； 把安全加到更多环节中，如新业务上线、重点项目发版、核心项目每月安测等，把SDLC闭环； 专项的成立以及推进，可拉动多岗位人员参与，如敏感数据加密专项，账号体系专项等等
- 6、其他安全平台想法
- 漏洞平台的总结，搭建漏洞管理平台，以及后续对接其他平台的二次开发 靶场平台的搭建，配合着安全培训，提高企业内部技术团队的演练效果
- 1、工程师或者内部员工的职业道德，如加强安全意识以及法律法规教育；