如前所述，各家IT审计服务机构都有一套控制检查清单，其中，最为基础的被称为『一般性IT控制措施』，这当中包括了三大审计重点。就笔者实际服务经验来看，这三大重点往往涵盖了绝大多数的生产故障发生的原因。

　　重点一：变更管理

　　在Gitlab事件中，最为令人惊讶的（其实也没那么惊讶）是运维人员在事件处置过程中，可以不经任何授权、评估、测试，直接在生产环境上进行实验性的操作，而且执行的是删除目录这样高危的操作。在ITIL所描述的变更发布管理优秀实践中，变更管理往往会经过多个控制环节，以确保变更的成功，这些环节包括了变更申请、授权、评估（业务影响、风险、可行性）、测试（单元、集成、用户验收）、审批、发布执行、回滚计划、上线验证等等。之所以变更流程的优秀实践如此之复杂，是因为生产环境的变更实际上是信息系统安全性最大的隐忧。

　　在IT审计中，变更管理的有效性，也是关注的第一大重点。作为审计师，我们会关注变更流程中是否有有效的审批授权（以确认变更操作不是个人的、非授权的行为）、是否进行了合理而充分的测试（以确认变更在上线前是否得到质量验证）、是否遵循了不相容职责分离的原则（申请与审批、开发与测试、开发与上线部署等）。在Gitlab事件中，我们明显的看到管理员对生产环境执行的变更操作未能遵循上述基本要求。

　　虽然Gitlab作为一家创业型的科技企业，实际上无需遵守什么样特定的运维流程，但一些通用风险控制的管理方式也是可以借鉴的，毕竟这些控制点和实践是从大量的教训当中积累出来的。从审计的角度来说，所有的形式、文档、记录都是为了『证明我们确实这么做了』，但从目的来说，更重要的是『即使我们不需要证明什么，我们也会遵循一些要求来提高我们系统的安全性和稳定性』。

　　重点二：访问控制

　　在IT审计中的第二个重点是访问控制，访问控制一般会关注两大问题：

账号合理性的问题

权限合理性的问题

　　直白一点来讲，第一个问题关注哪些人能开哪些门，第二个问题关注这些人进到屋子里面之后能干些什么。

　　Gitlab事件当中，我们注意到了很多有趣、有价值的建议，例如生产运维账号权限限制以及自动化运维，这些建议其实都可以看作是访问控制的一种延伸。在对生产运维账号权限进行限制时，运维人员将无法直接对一些敏感、高危的操作直接执行，而必须额外的获得更高的权限执行操作，这些特异性的操作方式由于有别于开发、测试环境，将有利于运维人员获得操作危险性提示，这当然是对『人肉运维』的一种改良性的尝试。而自动化运维，则是更加彻底可以降低这一风险的运维技术发展趋势。除了应急情况下备用的管理员账号，信息系统当中只存在自动化运维工具的账号，这些运维工具被配置特定的权限、执行特定的操作，这将大大的降低『人肉运维』可能带来的风险。

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

　　重点三：备份和恢复测试

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

　　随着技术的飞速发展，已经有了越来越多的技术手段，帮助企业提高信息系统的可用性和连续性。我们看到了集群式高可用架构，异地多活数据中心，提供数据高完整性保障的云服务。然而在这纷繁缭乱的新技术中，回归到信息系统连续性管理的本源，我们是否对数据做了有效的备份，并且能够在突发情况下可以实际的实现数据的恢复？我们各种备份机制下，是否设定了合理的RPO，以满足我们对数据恢复时可以容忍的数据损失？我们是否真正的执行过演练，以验证我们设定的RTO，真的能够完成我们的服务恢复？