一转眼，已经是鸡年的第一个工作日了，祝各位看官开年大吉。

　　就在两天前，《Gitlab误删300GB数据，备份失效后直播抢救》、《Gitlab不小心删除了数据库导致网站下线》霸屏了科技新闻的头条。

　　整个事件的回顾，Gitlab 第一时间放到了 Google Doc 上，并在 Twitter 上对事件的处置状态进行实时更新，后来索性在 Youtube上 开了频道直播恢复进程，目前网站已经恢复了正常，不幸的是，gitlab 还是丢掉了差不多6个小时的数据。

　　对于事件的前因后果，Gitlab 在 Google Doc 上面已经进行了详细说明，简单来说：

　　Gitlab 遭受了恶意邮件发送者的 DDoS 攻击，导致数据库写入锁定，网站出现不稳定和宕机，在阻止了恶意邮件发送者之后，运维人员开始修复数据库不同步的问题，在修复过程中，错误的在生产环境上执行了数据库目录删除命令，导致300GB数据被删除，Gitlab 被迫下线。在试图进行数据恢复时，发现只有 db1.staging 的数据库可以用于恢复，其它五种备份机制均无效。db1.staging 是6小时前的数据，而且传输速率有限，导致恢复进程缓慢。

　　作为一个信息系统审计师和信息安全顾问，笔者曾经对数十家企业的信息系统运维工作进行过审计，类似的事件屡见不鲜，atv直播，其中也不乏国际知名的IT巨头和国内顶尖的科技公司，只是传播范围、影响力、事件透明度都没有这个事件这么大。这次事件，其实是一个非常典型的信息安全风险爆发、信息安全控制措施失效的案例，笔者将从 IT 审计的角度，进行一些简单分析和分享。

　　1IT审计的逻辑是什么

　　IT 审计是一种针对信息系统的审计方式，不同于财务审计对财务报告真实性、有效性、准确性的验证，IT 审计关注于对信息系统本身的稳定性、准确性、安全性的检查以及围绕信息系统运维管理活动有效性的检查。直白一点来说，除了要检查信息系统本身能否正确、稳定的进行信息处理，IT 审计还关注是否针对信息系统运维风险的设计了有效的控制措施，并有效执行。

　　在 IT 审计中，审计的出发点叫做 WCGW (What Could Go Wrong)，说白了就是要识别出哪些场景可以导致信息系统的不稳定、不准确的情况发生。这是一个基于过程的分析方式，用 Gitlab 事件举个例子，其中的一个 WCGW 就可以是『错误的将对备库操作在生产库上执行』。在大量的IT风险事件基础上，IT审计服务机构识别出了很多的WCGW，并进行归类和分析，并据此设计出一套方法论和控制措施检查清单。IT审计服务机构根据这一方法论和检查清单对企业执行IT审计，以判断是否有能力应对潜在的IT风险。

　　审计执行过程一般分为两个阶段：

制度、流程、控制措施的设计有效性检查阶段

制度、流程、控制措施的执行有效性检查阶段

　　首先，控制设计的有效性主要是检查企业是否建立了制度、流程，以对风险进行控制。

　　笔者在实际检查过程中，经常发现不完善的企业的IT规则严重依赖信息系统管理、维护人员的个人能力和意识，信息系统的维护活动、操作执行对企业管理者来说是完全的黑盒。而正规一些的IT组织，则会建立完整的规则，且不论这些规则是否执行有效，至少在纸面上可以做到『有法可依』。在审计的逻辑里面，有法可依是第一步，如果连基本的管理要求都不存在，也就谈不上执行的有效性了。

　　其次，控制执行有效性检查，是基于『控制设计是有效的』这一结论。

　　一般来说，如果设计有效性评价为无效，是不会进行执行有效性检查的，因为那意味着『无法可依』或者『法律无效』。在Gitlab这个事件中，有评论分析说，管理员之所以执行了误操作，是因为『迷失在了N多个终端窗口当中』。这样的场景很常见，很多企业都制定了生产环境操作的规则以防止类似的事情发生，可实际上由于这些控制措施未被执行，还是会导致生产事故的发生。笔者曾听闻了多起类似的由于多窗口不同环境同时操作导致的生产事故，这种情况被称为控制措施执行的失效。

　　2IT审计的三大重点