Gitlab事件→IT审计 & 简要回顾[编辑完毕]
本帖最后由 pgain2004 于 2017-2-4 22:50 编辑原文：http://36kr.com/p/5062982.html
https://pic.36krcnd.com/avatar/201702/04132833/qvmlwsqm9i4j2axv.png
就在两天前，《Gitlab误删300GB数据，备份失效后直播抢救》、《Gitlab不小心删除了数据库导致网站下线》霸屏了科技新闻的头条。
https://pic.36krcnd.com/201702/04071437/6fyj2qdsgcxzrikz%211200
Gitlab 第一时间将整个事件回顾放到 Google Doc 上，并在 Twitter 上对事件的处置状态进行实时更新，后来索性在 Youtube直播修复，目前网站已恢复正常，但仍不幸丢掉了约6小时的数据。
对于事件的前因后果，Gitlab 在 Google Doc 上面已经进行了详细说明，简单来说：
Gitlab 遭受了恶意邮件发送者的 DDoS 攻击，导致数据库写入锁定，网站出现不稳定和宕机。在阻止了恶意邮件发送者之后，运维人员开始修复数据库不同步的问题。修复过程中，错误的在生产环境上执行了数据库目录删除命令，导致300GB数据被删除，Gitlab 被迫下线。试图进行数据恢复时，发现只有 db1.staging 的数据库可以用于恢复，其它五种备份机制均无效。db1.staging 是6小时前的数据，而且传输速率有限，导致恢复进程缓慢。
作为一个信息系统审计师和信息安全顾问，笔者曾经对数十家企业的信息系统运维工作进行过审计，类似事件屡见不鲜，其中不乏国际知名IT巨头和国内顶尖科企，只是传播范围、影响力、事件透明度都没这件事大。这次事件，其实是一个非常典型的信息安全风险爆发、信息安全控制措施失效的案例，笔者将从 IT 审计的角度，进行一些简单分析和分享。
1、IT审计的逻辑是什么
IT 审计是一种针对信息系统的审计方式，不同于财务审计对财务报告真实性、有效性、准确性的验证，IT 审计关注于对信息系统本身的稳定性、准确性、安全性的检查以及围绕信息系统运维管理活动有效性的检查。直白一点来说，除了要检查信息系统本身能否正确、稳定的进行信息处理，IT 审计还关注是否针对信息系统运维风险的设计了有效的控制措施，并有效执行。
https://pic.36krcnd.com/201702/04071437/05d4mgm5m76wzlos%211200
在 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事件当中，我们注意到了很多有趣、有价值的建议，例如生产运维账号权限限制以及自动化运维，这些建议其实都可以看作是访问控制的一种延伸。在对生产运维账号权限进行限制时，运维人员将无法直接对一些敏感、高危的操作直接执行，而必须额外的获得更高的权限执行操作，这些特异性的操作方式由于有别于开发、测试环境，将有利于运维人员获得操作危险性提示，这当然是对『人肉运维』的一种改良性的尝试。而自动化运维，则是更加彻底可以降低这一风险的运维技术发展趋势。除了应急情况下备用的管理员账号，信息系统当中只存在自动化运维工具的账号，这些运维工具被配置特定的权限、执行特定的操作，这将大大的降低『人肉运维』可能带来的风险。
https://pic.36krcnd.com/201702/04071437/c6nw5o52m2pexenw%211200
『人肉运维』仍然是绝大多数企业采用的操作方式，很多运维人员甚至认为使用root权限进行生产环境线上操作处理问题是能力高超的表现。单独依靠运维人员的个人能力进行运维，风险不光有人员能力的天花板，企业还不得不面对可能的（有些地方甚至是必然的）运维人员流动带给信息系统的巨大风险。
重点三：备份和恢复测试
笔者在为很多企业进行IT审计服务时，最常提出的风险发现之一就是『未执行备份的恢复测试，无法验证备份数据的有效性』，这也被业内人士自嘲式的称为『最没有营养的IT审计发现之一』，因为这一发现并不会在实质上影响审计结论。然而，在Gitlab事件中，我们看到了令人惊诧的一幕，多重备份机制竟然只有一个可以用于数据恢复。
随着技术的飞速发展，已经有了越来越多的技术手段，帮助企业提高信息系统的可用性和连续性。我们看到了集群式高可用架构，异地多活数据中心，提供数据高完整性保障的云服务。然而在这纷繁缭乱的新技术中，回归到信息系统连续性管理的本源，我们是否对数据做了有效的备份，并且能够在突发情况下可以实际的实现数据的恢复？我们各种备份机制下，是否设定了合理的RPO，以满足我们对数据恢复时可以容忍的数据损失？我们是否真正的执行过演练，以验证我们设定的RTO，真的能够完成我们的服务恢复？
对于备份和恢复管理，Gitlab事件堪称绝佳的案例，集中的体现出了备份有效性、RPO和RTO未得到验证的问题。这也是为什么，越来越多的领军企业开始关注信息系统的连续性管理和应急响应，越来越多的企业开始真刀真枪的开展数据中心的切换演练、数据恢复测试演练、应急预案演练。而演练过程中，也确确实实可以发现大量的不可预期的问题，例如交通耗时、备用的设施设备可用性、各类系统的版本和兼容性问题、读写速度和运营商带宽限制问题、介质有效性问题等等，而这些问题在缺少演练的情况下，是很难暴露出来的。
文末小结
1）前车之鉴，未雨绸缪
就像互联网金融行业里面一直在讨论的『投资者教育』的问题，在发生实质性违约事件之前，总是有很多人无法理解『责任自担』的含义。
不论是Gitlab事件，还是当年的携程宕机事件，都应当作为自我审视和优化的一个契机。审视一下自己公司的规则是否完备，审视一下规则是否有效的落实，把每一个别人的事故当成自我检查的标准，把每一个预案场景都实实在在的进行一下演练。安全稳定的系统环境，需要我们以前车之鉴，做未雨绸缪。
2）『有风险意识的工程师文化』
笔者在IT风险领域从业多年，尽管在从业过程中一再的强调管理导向的重要性，却也是坚定的工程师文化的追随者。作为技术公司，我们应当更多的相信技术而不是管理。
安全的运维需要规则，但规则的落实要尽可能的依赖技术的力量，而非纸面上的制度、流程、管理活动。而我也相信，重规则、轻流程的技术导向型IT风险管理，可以让企业走的更高更远。
本文作者：马寅龙（点融黑帮），点融网信息安全合规专家，2年IT审计和6年信息安全风险咨询服务经验，擅长信息科技战略规划、信息安全体系建设、IT风险管理与治理，崇尚以务实的方式践行企业的信息安全风险管理。
本文由@点融黑帮（ID：DianrongMafia）原创发布于36Kr，未经许可，禁止转载。
原文：https://about.gitlab.com/2017/02/01/gitlab-dot-com-database-incident/
渣翻译：http://www.oschina.net/news/81494/gitlab-dot-com-database-incident/
昨天，我们（Gitlab）网站的一个数据库发生了严重事故。我们（GitLab.com）丢失了 6 小时的数据库数据（问题，合并请求，用户，评论，片段等）。Git / wiki 存储库和自托管安装不受影响。丢失生产数据是不可接受的。未来几天内，我们将会发布此次事故发生的原因及一系列措施的落实情况。
更新 18:14 UTC：GitLab.com 重新上线
截至撰写本文时，我们正在从 6 小时前的数据库备份中恢复数据。这意味着在 GitLab.com 再次生效的时候，17:20 UTC和 23:25UTC 之间数据库丢失的任何数据都将恢复。
Git数据（存储库和维基）和 GitLab的自托管实例不受影响。
以下是本次事件的简要摘要，详细内容请查阅文档
事件一
2017/01/31 18:00 UTC，我们检测到垃圾邮件发送者通过创建片段来攻击数据库，使其不稳定。然后，我们开始了解发生了什么问题进行故障排除，以及如何防范。
https://static.oschina.net/uploads/space/2017/0202/102910_8Obj_2886655.png
2017/01/31 21:00 UTC，问题升级，导致在数据库上的写入锁定，令网站偶有宕机。
https://static.oschina.net/uploads/space/2017/0202/102927_HZr2_2886655.png
措施：
[*]根据IP地址阻止了垃圾邮件发送者
[*]删除使用存储库作为某种形式的CDN导致47000个IP使用同一个帐户登录（导致高DB负载）的用户
[*]已移除用户发送垃圾邮件（通过创建代码段）
事件二
2017/01/31 22:00 UTC，因无法有效阻止 DB 复制的严重滞后，我们被分页。发生这种情况是因为在辅助数据库没有及时处理写入。
https://static.oschina.net/uploads/space/2017/0202/102944_FIAH_2886655.png
https://static.oschina.net/uploads/space/2017/0202/103008_uASX_2886655.png
措施：
[*]尝试修复 db2 ，此时丢失数据约4 GB
[*] db2.cluster 拒绝复制， /var/opt/gitlab/postgresql/data 擦拭以保证复制
[*] db2.cluster 拒绝连接到 db1 ， max_wal_senders 太低。此设置是用来限制数量 WAL (= replication) 的客户端
[*]团队成员1调整 max_wal_senders 到 32 上 db1 ，重启 PostgreSQL 。
[*]PostgreSQL 因同时打开信号量太多而拒绝重启。
[*]团队成员1将 max_connections 从 8000 调到 2000 。PostgreSQL 重启成功（尽管 8000 已经使用了近一年）
[*] db2.cluster 可以链接，但仍然复制失败，只是挂在那里没有执行任何的操作。今晚 23:00 左右（当地时间），团队成员1明确提到他要签字，并未想到会突然出现复制问题。
事件三
2017年1月31日23:00左右，团队成员1认为， pg_basebackup 拒绝执行是因为 PostgreSQL 的数据目录存在（尽管是空的），于是决定删除该目录。经过一两秒钟，他注意到他运行在 db1.cluster.gitlab.com ，而不是 db2.cluster.gitlab.com 。
2017年1月31日23:27，团队成员1 终止删除操作，但为时已晚。大约300 GB左右的数据只剩下约4.5 GB
我们不得不把 GitLab.com 下线，并在 Twitter 上公布信息。
我们正在执行紧急数据库维护，https://t.co/r11UmmDLDE 将脱机
GitLab.com 状态（@gitlabstatus）2017年1月31日
遇到的问题
[*]默认情况下，LVM 快照每 24 小时采取一次。为了数据库的工作负载平衡，团队成员 1 在停电前 6小时手动操作过。
[*]定期备份似乎也只能每24小时执行一次，虽然团队成员1目前仍未能找出它们的存储位置。团队成员2表示 ，这些似乎没有奏效，产生的文件大小只有几个字节。
[*]团队成员3：看起来 pg_dump 可能会失败，因为 PostgreSQL 的 9.2 二进制文件正在运行，而不是 9.6 的二进制文件。这是因为 omnibus 只使用 Pg 9.6 ，如果 data / PG_VERSION 设置为 9.6，但在 workers 上这个文件不存在。因此，它默认为 9.2，静默失败。因此没有做出 SQL 转储。Fog gem 可能已清理旧备份。
[*]为Azure 服务器启用 Azure 中的磁盘快照，而不是 DB 服务器。
[*]同步过程在 Webhooks 数据同步到暂存后删除。我们只能从过去24小时的定期备份中提取内容，否则将丢失
[*]复制过程是超级脆弱，容易出错，依赖少数随机 shell 脚本并记录
[*]我们的备份到 S3 显然也不运行：bucket 是空的
[*]因此，换句话说，部署的 5 个备份/复制技术中没有一个可靠地运行或设置。我们最终还原了6 小时前的备份。
[*]pg_basebackup 将等待主机启动复制进程，据另一个生产工程师称，这可能需要 10 分钟。这可能导致进程被卡住。使用 “strace” 运行进程没有提供的有用信息。
恢复
我们正在使用临时数据库中的数据库备份来立即恢复。
我们不小心删除了生产数据，可能必须从备份中还原。谷歌文档与现场笔记 https://t.co/EVRbHzYlk8
GitLab.com 状态（@gitlabstatus）2017年2月1日
[*]2017年2月1日00:36 - 备份 db1.staging.gitlab.com 数据
[*]2017年2月1日00:55 - 在 db1.cluster.gitlab.com 安装 db1.staging.gitlab.com
[*]从分段复制数据 /var/opt/gitlab/postgresql/data/ 到生成 /var/opt/gitlab/postgresql/data/
[*]2017年2月1日01:05 - nfs-share01 服务器 征用临时存储 /var/opt/gitlab/db-meltdown
[*]2017年2月1日01:18 - 复制剩余的生成数据，包括 pg_xlog ，升级为 20170131-db-meltodwn-backup.tar.gz
下图显示删除的时间和后续的数据复制。
https://static.oschina.net/uploads/space/2017/0202/103133_NwsE_2886655.png
此外，我们要感谢#hugops通过Twitter 和其他渠道给予的绝赞支援 2楼的总结有点渣翻，总之我看到的都顺手修了修，非专业，修错勿怪。 IT安全从业人员看得百感交集 如果搞得这么麻烦，还真不如不做
像这次的事件实在是太小概率了，事后补救的成本都比平时防微杜渐的管理成本低吧 那么那个手贱的倒霉蛋真的看了10小时的小马吗？
—— 来自 samsung SM-A5108, Android 5.1.1上的 S1Next-鹅版 最后恢复了没?
youtube上直播真是太好玩了,无形中一次完美的危机公关? Scrummble 发表于 2017-2-4 23:08
如果搞得这么麻烦，还真不如不做
像这次的事件实在是太小概率了，事后补救的成本都比平时防微杜渐的管理成 ...
还得算算隐性成本。正如文中说的，类似事件一直有，只不过这次比较抢眼球，而有效论证和改善也是一直在做嘛。 nihse 发表于 2017-2-4 23:12
那么那个手贱的倒霉蛋真的看了10小时的小马吗？
—— 来自 samsung SM-A5108, Android 5.1.1上的 S1Next- ...
不对好像是彩虹猫
—— 来自 samsung SM-A5108, Android 5.1.1上的 S1Next-鹅版 这文里有不少胡扯的内容，比如要求运维工程师在应急处理生产环境中存在的问题的时候做到“变更申请、授权、评估（业务影响、风险、可行性）、测试（单元、集成、用户验收）、审批、发布执行、回滚计划、上线验证”，简直是胡闹。 258921 发表于 2017-2-4 23:46
这文里有不少胡扯的内容，比如要求运维工程师在应急处理生产环境中存在的问题的时候做到“变更申请、授权、 ...
通过收拾屋子节省的时间，往往不如收拾屋子本身花费的时间多 Scrummble 发表于 2017-2-4 23:59
通过收拾屋子节省的时间，往往不如收拾屋子本身花费的时间多
这和业务的规模有关，小规模是成本不合算，但规模大到一定程度就是成本合算的了
很多事情都是一样的，要根据现实业务做实际考虑，不能一味信任规则 当年考ITIL时候的
看到审计，作为一个开发人员到架构出身的和11楼是一样的
不过最终反正boss认，那你也得认呗 用过一段时间的gitlab pages，还好换成了gitcafe 那么麻烦谁会去照做 确实审计那里有点扯，应急的时候恢复时第一位，哪有时间还去走流程（我们这里事后会补变更流程），应该是根据应急预案来做，如果应急预案没有覆盖到，就要有专家团队处置，领导拍板了，不是一个人能处置的。 IT运维的傻逼事例看得太多了，之前见过十八摸给必和必拓维护的邮件归档系统直接失踪了几个mapping drive而且三年里从来没备份过你能信 258921 发表于 2017-2-4 23:46
这文里有不少胡扯的内容，比如要求运维工程师在应急处理生产环境中存在的问题的时候做到“变更申请、授权、 ...
这个作者对于ITIL有点一知半解，这次是典型的突发事件，应该走IM流程，跟变更管理没半毛钱关系～
—— 来自 Xiaomi MI 5s Plus, Android 6.0.1 引用第9楼258921于2017-02-04 23:46发表的:
这文里有不少胡扯的内容，比如要求运维工程师在应急处理生产环境中存在的问题的时候做到“变更申请、授权、......
@258921
我们订购三叉戟，是为了让英国人民以为受到了保护，而不是为了保护人民的。
----发送自 samsung SC-01F,Android 5.0 “懒”是一个难以解决的问题
页:
[1]