系统底层的重要、核心数据文件时常面临着更新和传输,仅仅依靠防止拷贝数据文件是无法避免事故的发生,也无法快速定位事故原因,更加无法及时恢复灾难。 那么“快速定位事故原因、及时恢复数据文件,将经济损失降至最低”就成为了我们应时刻紧绷的一根弦。
安全事件随时可能发生
[2016/06/20 11:44] 事故反馈
运维部门负责人接到前端业务人员反馈某个业务系统的某些页面无法访问,致使产品订单无法进行正常交易。
[2016/06/20 11:45] 事故分析
经过系统开发人员检查,发现是业务系统里的某个文件在11点43分更新过,很有可能是文件更新导致系统无法访问。部门负责人责令尽快恢复业务系统和追查事故原因。
[2016/06/20 11:46] 事故定位
基于“文件名”和“业务系统的地址”进行全局检索,很快定位到某人在11点40分登录过此业务系统的后台,在11点41分先使用sz命令下载了此文件,又在11点43分使用rz -y命令上传了此文件,直接覆盖了原来的文件,致使业务系统的某个页面无法正常访问。
[2016/06/20 11:49] 危机解除
在堡垒机中导出下载的文件和上传的文件,将2个文件内容进行对比分析,发现2个文件的部分代码不一致。开发人员及时修复文件后,很快将业务系统恢复正常。
模拟事故经过程
模拟整个事件过程:
下载文件:
上传文件:
更多风险等着我们
传输文件的方式多种多样,如SCP、SFTP、FTP、RDP(磁盘映射和剪贴板)、zmodem等,如果未能及时做到事前预防、事中控制、事后审计,那后果不堪设想。可能存在的风险有:
......
风险最小化
本次危机能及时、顺利处理,得益于前期规范整个运维管理,特别是在文件传输方面进行了严格的管控和审计: