从Gitlab误删数据库事件，说一说IT审计的那些事儿

在对生产运维账号权限进行限制时，运维人员将无法直接对一些敏感、高危的操作直接执行，而必须额外的获得更高的权限执行操作，这些特异性的操作方式由于有别于开发、测试环境，将有利于运维人员获得操作危险性提示，这当然是对『人肉运维』的一种改良性的尝试。

而自动化运维，则是更加彻底可以降低这一风险的运维技术发展趋势。除了应急情况下备用的管理员账号，信息系统当中只存在自动化运维工具的账号，这些运维工具被配置特定的权限、执行特定的操作，这将大大的降低『人肉运维』可能带来的风险。

『人肉运维』仍然是绝大多数企业采用的操作方式，很多运维人员甚至认为使用root权限进行生产环境线上操作处理问题是能力高超的表现。单独依靠运维人员的个人能力进行运维，风险不光有人员能力的天花板，企业还不得不面对可能的(有些地方甚至是必然的)运维人员流动带给信息系统的巨大风险。

重点三：备份和恢复测试

笔者在为很多企业进行IT审计服务时，最常提出的风险发现之一就是『未执行备份的恢复测试，无法验证备份数据的有效性』，这也被业内人士自嘲式的称为『最没有营养的IT审计发现之一』，因为这一发现并不会在实质上影响审计结论。然而，在Gitlab事件中，我们看到了令人惊诧的一幕，多重备份机制竟然只有一个可以用于数据恢复。

随着技术的飞速发展，已经有了越来越多的技术手段，帮助企业提高信息系统的可用性和连续性。我们看到了集群式高可用架构，异地多活数据中心，提供数据高完整性保障的云服务。然而在这纷繁缭乱的新技术中，回归到信息系统连续性管理的本源，我们是否对数据做了有效的备份，并且能够在突发情况下可以实际的实现数据的恢复?

我们各种备份机制下，是否设定了合理的RPO，以满足我们对数据恢复时可以容忍的数据损失?我们是否真正的执行过演练，以验证我们设定的RTO，真的能够完成我们的服务恢复?

对于备份和恢复管理，Gitlab事件堪称绝佳的案例，集中的体现出了备份有效性、RPO和RTO未得到验证的问题。这也是为什么，越来越多的领军企业开始关注信息系统的连续性管理和应急响应，越来越多的企业开始真刀真枪的开展数据中心的切换演练、数据恢复测试演练、应急预案演练。

而演练过程中，也确确实实可以发现大量的不可预期的问题，例如交通耗时、备用的设施设备可用性、各类系统的版本和兼容性问题、读写速度和运营商带宽限制问题、介质有效性问题等等，而这些问题在缺少演练的情况下，是很难暴露出来的。

小结

1)前车之鉴，未雨绸缪 

就像互联网金融行业里面一直在讨论的『投资者教育』的问题，在发生实质性违约事件之前，总是有很多人无法理解『责任自担』的含义。

不论是Gitlab事件，还是当年的携程宕机事件，都应当作为自我审视和优化的一个契机。审视一下自己公司的规则是否完备，审视一下规则是否有效的落实，把每一个别人的事故当成自我检查的标准，把每一个预案场景都实实在在的进行一下演练。安全稳定的系统环境，需要我们以前车之鉴，做未雨绸缪。

2)『有风险意识的工程师文化』

笔者在IT风险领域从业多年，尽管在从业过程中一再的强调管理导向的重要性，却也是坚定的工程师文化的追随者。作为技术公司，我们应当更多的相信技术而不是管理。

安全的运维需要规则，但规则的落实要尽可能的依赖技术的力量，而非纸面上的制度、流程、管理活动。而我也相信，重规则、轻流程的技术导向型IT风险管理，可以让企业走的更高更远。

【钛媒体作者介绍：马寅龙(点融黑帮)，点融网信息安全合规专家，2年IT审计和6年信息安全风险咨询服务经验】

（编辑：源码网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!