Ywc's blog

2020年安全事件以及后续整改的反思

Word count: 1.4k / Reading time: 4 min
2020/12/31 Share

by 磊哥

本次故障及事件简要回顾(来自公开渠道推文)

  • 2020年2月23日,18:56分,微盟研发中心运维部核心运维人员通过VPN登入服务器,并对线上生产环境进行了恶意破坏;
  • 2月23日 19 时,微盟内部系统监控报警,出现大面积服务集群无法响应;
  • 2月25日7 时,生产环境和数据部分恢复,预计25日晚24点完成生产环境修复,新用户恢复业务。老用户预计到2月28日晚上才能恢复。
  • 微盟事后对恶意破坏生产环境的嫌疑人进行追踪分析,成功定位到嫌疑人登录账号及IP地址,并于24日向宝山公安局报案。目前犯罪嫌疑人已被宝山区公安局刑事拘留,犯罪承认了犯罪事实。

外界的观点描述

1、需要说明怎样的权限来约束运维?或者往外拓宽至每一个核心研发人员,如:测试,研发,DBA 这些角色中拥有高权限的人员。

-  例如:rm、mv、alias等危险命令应该受到严格的制约; 
  • 一个良好的运维输出能力应该是:人管代码,代码管机器,而非人管机器。
  • 当约束过多,照成的流程审批过多,如何不增加额外的人力物力和财力

2、备份该如何做?

  • 例如:备份事件的问题,全量备份和增量备份的校验,主从备份、异地备份等的制度
  • 恢复的验证,要常演练,因为会遇到各种问题导致的恢复失败,比如:介质问题、数据问题、操作问题等

反思和总结

遇到问题,只有面对问题,解决问题,才是根本,而非甩锅。

在事出第一刻,通过排除,确定问题,也验证了安全工作的一些不足,对部分权限还未考虑到位。 后续的蛇鬼牛神全员出动,各种目的的人员,只能说感谢他们的关心。

安全圈,依靠着事件来驱动企业成长的太多,每次的事件,都是给行业带来一定的波动,也锤炼着领导,更锤炼着躺枪的负责人员,后续也就无非惩罚多少来以儆效尤了。

  • 简单罗列几点思考:
    • 1、工程师或者内部员工的职业道德,如加强安全意识以及法律法规教育;
      • 如何避免:内部员工账号密码泄露、内部代码泄露(如上传github、码云等三方平台)、或者邮件钓鱼攻击等各种情况 安全意识培训不能少,并且要定期执行,对研发,测试,运维,产品等,乃至于拓展到全员,以及新员工入职的培训。 更高的要求:对于管理者来说,或许员工的心里建设也是一个可指引的方向吧。毕竟人是企业的核心资产。
    • 2、服务器厂商的选择以及监控报警完善
      • 是自建IDC,还是混合云,还是全部上云,所带来的技术支持是截然不同的,涉及的服务恢复以及数据恢复。 监控报警体系的完善,对于敏感操作的监控以及报警及时性。当然根据本次事件,监控报警也就只能起到查原因的作用了,但依然不能否认他存在的价值。要不然为啥要ELK。
    • 3、梳理全网的站点,把控隔离情况
      • 及时梳理所有的网站,通过内部上报,运维外网开放host解析,IP探测,等多种方式,梳理内网外开放情况,
      • 严格把控QA、DEV、PL、Oline 环境的相互隔离,以及非必要外网开放项目的回归内网
    • 4、权限以及角色的梳理
      • 对于运维、DBA、安全实现三权分立,运维管执行,DBA管数据,安全管审计,对于执行/使用备份和存储备份的人员进行分开
      • 对于角色这一块,进行最小权限执行的规定,以及同时启动角色系统平台开发,解决多平台的角色设置冗余
      • 对于权限的申请,要执行多方审核,解决很多误操作,比如删数据,删文件等有意无意的操作
    • 5、全盘恢复后的安全复检
      • 近期三方提交了一些安全漏洞上来,发现很多漏洞都是之前没出现的功能,或者说之前已修复的,哪也就说明,恢复后的代码,出现了部分代码的回滚现象,或者说是业务迭代的时候,并没有同步安全部门。
      • 哪如何去解决这样的问题呢?
        • 需要多个人互相校验平台,每个人都有各自的漏洞挖掘思路; 把安全加到更多环节中,如新业务上线、重点项目发版、核心项目每月安测等,把SDLC闭环; 专项的成立以及推进,可拉动多岗位人员参与,如敏感数据加密专项,账号体系专项等等
    • 6、其他安全平台想法
      • 漏洞平台的总结,搭建漏洞管理平台,以及后续对接其他平台的二次开发 靶场平台的搭建,配合着安全培训,提高企业内部技术团队的演练效果
CATALOG
  1. 1. 本次故障及事件简要回顾(来自公开渠道推文)
  2. 2. 外界的观点描述
  3. 3. 反思和总结