就在两天前，《Gitlab 误删 300GB 数据，备份失效后直播抢救》、《Gitlab 不小心删除了数据库导致网站下线》霸屏了科技新闻的头条。
整个事件的回顾，Gitlab 第一时间放到了 Google Doc 上，并在 Twitter 上对事件的处置状态进行实时更新，后来索性在 Youtube 上开了频道直播恢复进程，目前网站已经恢复了正常，不幸的是，Gitlab 还是丢掉了差不多 6 个小时的数据。
对于事件的前因后果，Gitlab 在 Google Doc 上面已经进行了详细说明，简单来说：
Gitlab 遭受了恶意邮件发送者的 DDoS 攻击，导致数据库写入锁定，网站出现不稳定和宕机，在阻止了恶意邮件发送者之后，运维人员开始修复数据库不同步的问题，在修复过程中，错误的在生产环境上执行了数据库目录删除命令，导致 300GB 数据被删除，Gitlab 被迫下线。
在试图进行数据恢复时，发现只有 db1.staging 的数据库可以用于恢复，其它五种备份机制均无效。db1.staging 是 6 小时前的数据，而且传输速率有限，导致恢复进程缓慢。
作为一个信息系统审计师和信息安全顾问，笔者曾经对数十家企业的信息系统运维工作进行过审计，类似的事件屡见不鲜，其中也不乏国际知名的 IT 巨头和国内顶尖的科技公司，只是传播范围、影响力、事件透明度都没有这个事件这么大。
这次事件，其实是一个非常典型的信息安全风险爆发、信息安全控制措施失效的案例，笔者将从 IT 审计的角度，进行一些简单分析和分享。
1、IT 审计的逻辑是什么
IT 审计是一种针对信息系统的审计方式，不同于财务审计对财务报告真实性、有效性、准确性的验证，IT 审计关注于对信息系统本身的稳定性、准确性、安全性的检查以及围绕信息系统运维管理活动有效性的检查。
直白一点来说，除了要检查信息系统本身能否正确、稳定的进行信息处理，IT 审计还关注是否针对信息系统运维风险的设计了有效的控制措施，并有效执行。
在 IT 审计中，审计的出发点叫做 WCGW (What Could Go Wrong)，说白了就是要识别出哪些场景可以导致信息系统的不稳定、不准确的情况发生。这是一个基于过程的分析方式，用 Gitlab 事件举个例子，其中的一个 WCGW 就可以是『错误的将对备库操作在生产库上执行』。
在大量的 IT 风险事件基础上，IT 审计服务机构识别出了很多的 WCGW，并进行归类和分析，并据此设计出一套方法论和控制措施检查清单。IT 审计服务机构根据这一方法论和检查清单对企业执行 IT 审计，以判断是否有能力应对潜在的 IT 风险。
审计执行过程一般分为两个阶段：
- 制度、流程、控制措施的设计有效性检查阶段
- 制度、流程、控制措施的执行有效性检查阶段
首先，控制设计的有效性主要是检查企业是否建立了制度、流程，以对风险进行控制。
笔者在实际检查过程中，经常发现不完善的企业的 IT 规则严重依赖信息系统管理、维护人员的个人能力和意识，信息系统的维护活动、操作执行对企业管理者来说是完全的黑盒。
而正规一些的 IT 组织，则会建立完整的规则，且不论这些规则是否执行有效，至少在纸面上可以做到『有法可依』。在审计的逻辑里面，有法可依是第一步，如果连基本的管理要求都不存在，也就谈不上执行的有效性了。
其次，控制执行有效性检查，是基于『控制设计是有效的』这一结论。
一般来说，如果设计有效性评价为无效，是不会进行执行有效性检查的，因为那意味着『无法可依』或者『法律无效』。在 Gitlab 这个事件中，有评论分析说，管理员之所以执行了误操作，是因为『迷失在了N多个终端窗口当中』。
这样的场景很常见，很多企业都制定了生产环境操作的规则以防止类似的事情发生，可实际上由于这些控制措施未被执行，还是会导致生产事故的发生。笔者曾听闻了多起类似的由于多窗口不同环境同时操作导致的生产事故，这种情况被称为控制措施执行的失效。
2、IT 审计的三大重点
如前所述，各家 IT 审计服务机构都有一套控制检查清单，其中，最为基础的被称为『一般性 IT 控制措施』，这当中包括了三大审计重点。就笔者实际服务经验来看，这三大重点往往涵盖了绝大多数的生产故障发生的原因。
重点一：变更管理
在 Gitlab 事件中，最为令人惊讶的（其实也没那么惊讶）是运维人员在事件处置过程中，可以不经任何授权、评估、测试，直接在生产环境上进行实验性的操作，而且执行的是删除目录这样高危的操作。
在 ITIL 所描述的变更发布管理优秀实践中，变更管理往往会经过多个控制环节，以确保变更的成功，这些环节包括了变更申请、授权、评估（业务影响、风险、可行性）、测试（单元、集成、用户验收）、审批、发布执行、回滚计划、上线验证等等。
之所以变更流程的优秀实践如此之复杂，是因为生产环境的变更实际上是信息系统安全性最大的隐忧。
在 IT 审计中，变更管理的有效性，也是关注的第一大重点。
作为审计师，我们会关注变更流程中是否有有效的审批授权（以确认变更操作不是个人的、非授权的行为）、是否进行了合理而充分的测试（以确认变更在上线前是否得到质量验证）、是否遵循了不相容职责分离的原则（申请与审批、开发与测试、开发与上线部署等）。
在 Gitlab 事件中，我们明显的看到管理员对生产环境执行的变更操作未能遵循上述基本要求。
虽然 Gitlab 作为一家创业型的科技企业，实际上无需遵守什么样特定的运维流程，但一些通用风险控制的管理方式也是可以借鉴的，毕竟这些控制点和实践是从大量的教训当中积累出来的。
从审计的角度来说，所有的形式、文档、记录都是为了『证明我们确实这么做了』，但从目的来说，更重要的是『即使我们不需要证明什么，我们也会遵循一些要求来提高我们系统的安全性和稳定性』。
重点二：访问控制
在 IT 审计中的第二个重点是访问控制，访问控制一般会关注两大问题：
- 账号合理性的问题
- 权限合理性的问题
直白一点来讲，第一个问题关注哪些人能开哪些门，第二个问题关注这些人进到屋子里面之后能干些什么。
Gitlab 事件当中，我们注意到了很多有趣、有价值的建议，例如生产运维账号权限限制以及自动化运维，这些建议其实都可以看作是访问控制的一种延伸。
在对生产运维账号权限进行限制时，运维人员将无法直接对一些敏感、高危的操作直接执行，而必须额外的获得更高的权限执行操作，这些特异性的操作方式由于有别于开发、测试环境，将有利于运维人员获得操作危险性提示，这当然是对『人肉运维』的一种改良性的尝试。
而自动化运维，则是更加彻底可以降低这一风险的运维技术发展趋势。除了应急情况下备用的管理员账号，信息系统当中只存在自动化运维工具的账号，这些运维工具被配置特定的权限、执行特定的操作，这将大大的降低『人肉运维』可能带来的风险。
『人肉运维』仍然是绝大多数企业采用的操作方式，很多运维人员甚至认为使用 root 权限进行生产环境线上操作处理问题是能力高超的表现。单独依靠运维人员的个人能力进行运维，风险不光有人员能力的天花板，企业还不得不面对可能的（有些地方甚至是必然的）运维人员流动带给信息系统的巨大风险。
重点三：备份和恢复测试
笔者在为很多企业进行 IT 审计服务时，最常提出的风险发现之一就是『未执行备份的恢复测试，无法验证备份数据的有效性』，这也被业内人士自嘲式的称为『最没有营养的 IT 审计发现之一』，因为这一发现并不会在实质上影响审计结论。然而，在 Gitlab 事件中，我们看到了令人惊诧的一幕，多重备份机制竟然只有一个可以用于数据恢复。
随着技术的飞速发展，已经有了越来越多的技术手段，帮助企业提高信息系统的可用性和连续性。我们看到了集群式高可用架构，异地多活数据中心，提供数据高完整性保障的云服务。然而在这纷繁缭乱的新技术中，回归到信息系统连续性管理的本源，我们是否对数据做了有效的备份，并且能够在突发情况下可以实际的实现数据的恢复？
我们各种备份机制下，是否设定了合理的 RPO，以满足我们对数据恢复时可以容忍的数据损失？我们是否真正的执行过演练，以验证我们设定的 RTO，真的能够完成我们的服务恢复？
对于备份和恢复管理，Gitlab 事件堪称绝佳的案例，集中的体现出了备份有效性、RPO 和 RTO 未得到验证的问题。这也是为什么，越来越多的领军企业开始关注信息系统的连续性管理和应急响应，越来越多的企业开始真刀真枪的开展数据中心的切换演练、数据恢复测试演练、应急预案演练。
而演练过程中，也确确实实可以发现大量的不可预期的问题，例如交通耗时、备用的设施设备可用性、各类系统的版本和兼容性问题、读写速度和运营商带宽限制问题、介质有效性问题等等，而这些问题在缺少演练的情况下，是很难暴露出来的。
小结
1）前车之鉴，未雨绸缪
就像互联网金融行业里面一直在讨论的『投资者教育』的问题，在发生实质性违约事件之前，总是有很多人无法理解『责任自担』的含义。
不论是 Gitlab 事件，还是当年的携程宕机事件，都应当作为自我审视和优化的一个契机。审视一下自己公司的规则是否完备，审视一下规则是否有效的落实，把每一个别人的事故当成自我检查的标准，把每一个预案场景都实实在在的进行一下演练。安全稳定的系统环境，需要我们以前车之鉴，做未雨绸缪。
2）『有风险意识的工程师文化』
笔者在 IT 风险领域从业多年，尽管在从业过程中一再的强调管理导向的重要性，却也是坚定的工程师文化的追随者。作为技术公司，我们应当更多的相信技术而不是管理。
安全的运维需要规则，但规则的落实要尽可能的依赖技术的力量，而非纸面上的制度、流程、管理活动。而我也相信，重规则、轻流程的技术导向型 IT 风险管理，可以让企业走的更高更远。
作者介绍：马寅龙（点融黑帮），点融网信息安全合规专家，2 年 IT 审计和 6 年信息安全风险咨询服务经验