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

就在两天前，《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事件当中，我们注意到了很多有趣、有价值的建议，例如生产运维账号权限限制以及自动化运维，这些建议其实都可以看作是访问控制的一种延伸。

（编辑：常州站长网）

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