#网络安全#从微盟删库事件,看安全的本质和IT转型方向( 七 )


#网络安全#从微盟删库事件,看安全的本质和IT转型方向
本文插图
此次微盟事件 , 如果建立了业务连续性体系之后 , 应对此次事件能够提升和改善的地方有哪些呢?
首先事前应该建立BCM体系以及业务连续性计划 , 要做持续的风险分析 , 定期的真实演练 。 在业务中断事件发生之后 , 管理层接到报告 , 就应该快速启动业务连续性计划 , 遵循预案完成相关的人员召集、灾难的会商、决策 。 在恢复和重启阶段 , 技术团队需要做分钟级应用系统的恢复 , 快速恢复客户的业务 , 其次是数据的恢复和补录 。 在事后要考虑持续提升自身业务连续性 , 更新完善BCP , 微盟作为B2B2C最重要的中间2B的一环 , 要向下优化整个IaaS服务商的能力 , 把业务连续性能力再次提升 , 可以面向商户提供不同等级的业务连续性服务 。 下图这是我们给微盟做提升思路的建议 。
#网络安全#从微盟删库事件,看安全的本质和IT转型方向
本文插图
6、精鲲科技CTO葛丁佳:缺少流程管控的运维体系存在大量漏洞和风险 随着科技的发展 , 越来越多的互联网企业强调用户战略 , 通过快速迭代换来足够的市场竞争力和吸引力 , 也给运维领域带来了一个新的名词DevOps 。 DevOps是透过自动化“软件交付”和“架构变更”的流程 , 来使得构建、测试、发布软件能够更加地快捷、频繁和可靠 。 DevOps由“Development(开发)”和“Operation(运维)”二者合体 , 不少企业在实际操作中只片面看到了Dev所提倡的自动化 , 却忽略了Ops这个名词背后的“流程”和“可靠”原则 。 在微盟事件中 , 运维人员通过VPN账户进入其内部网络 , 短短几分钟内的操作就影响了大批业务系统 , 这就是没有管理体系约束所带来的问题:一个运维人员可以执行同时影响数千台 , 甚至上万台服务器的操作 , 这种流程的设计本身就是致命的隐患 。
从之前分享的微盟运维架构来看 , 基本的运维工具都具备了 , 包括监控、CI/CD、CMDB、权限管理等 , 但是仔细观察后会发现工具间彼此的管理范围都有局限性且各自分散 , 我们认为有效可行的方式是通过统一的流程管控起来 。
在ITOM领域里 , 用来处理设计和管理运维流程的工具叫做ITSM (IT Service Management) 。 ITSM可以规避由运维人员直接操作服务器的设备带来的隐患 , 而把操作抽象成代码 , 通过关键节点人为审批后 , 由系统去执行剩下的操作 , 这样不仅保障了必要的审批合规性 , 也规避了人为蓄意或失误的风险 。 2015年的携程事件也是因为误操作导致的业务宕机 , 事件之后携程开始大量投入流程工具的研发 。
下面我们来看看自动化和流程是怎么结合的 , 第一层是ITSM工作流引擎、自动化作业平台、以及监控系统 , 现在我们需要把运维软件以工作流的方式串联起来 , 用流程、审计、自愈等方式从前、中、后三个阶段防御微盟可能产生的问题 。
在事前阶段 , 用流程实现分而治之 。 操作人员在ITSM申请数据库变更的流程 , 这时会经由对应审核人员批准 , 审核通过之后再由自动化平台做执行 , 二次审核可以保证执行动作的合规性 , 避免操作人员直接登录平台对数据库的操作 。
在事中阶段 , 执行审计和阻断 , 当操作人执行高危命令 , 即触发ITSM阻断流程 。 比如有运维权限的人员通过VPN帐号登录自动化作业平台后 , 一旦执行符合高危操作定义的操作 , 就会触发ITSM的阻断流程 , 命令被拦截 , 并通知相应的管理员 。
在事后阶段 , 自愈流程会对故障状况进行恢复 。 如果监控到数据库存在异常 , ITSM会收到告警并触发恢复流程 , 由被关联的第三方工具对数据库进行恢复 。 所以我们在这里讲的并不是单个工具的作用 , 而是将各个运维工具打通之后 , 更加全面地帮客户解决管理流程和体系的问题 。


推荐阅读