《 “由「微盟删库」事件引发的一些思考” 》 有 4 条评论

1. 微盟数据被删的幕后故事
   https://mp.weixin.qq.com/s/2C_0V9zc3q8pWcRBo6leWQ
   `
   作为一名技术人员，接下来会从技术和技术管理的角度来谈谈他们的改进措施。

   措施一：数据安全管理机制全面加固与整改，加强运维平台治理
   关于这一点，个人认为管理是一项长期工作，包括细粒度权限分级和授权管理短期来说肯定能得到落实，但是时间久了，人也就疲了，最终很容易流入形式，长期而言，是否有效我持怀疑态度。

   措施二：加强灾备体系的建设，做到多云异地冷备
   这一点原则上我认同的，但是有一点我也有疑问，方案中的多云指的是在腾讯云的多个region中做多云异地灾备，那如果腾讯云也挂了呢？反正这也不是没有发生过。(腾讯云的小伙伴不要介意，没有哪一家云服务供应商能提供SLA100%的服务，Google也是一样)。
   我所理解的多云应该是异构多云，这是未来的趋势，多家云厂商多活互联(相关案例可以参考《多云管理，恺英实战之道》)，也许微盟这么选择的主要原因是基于腾讯生态的影响，以及腾讯云的大力支持，投桃送李的考量罢了。

   措施三：基础设施全力上云
   这一点基本等同于措施二，不再复述。

   除了这几点，我觉得还有几点是需要做的，主要如下：
   第一点：权限分离，备份数据的写入权限与删除权限分离，做备份的人或者工具只能追加，不能删除；
   第二点：备份系统和备份数据的可用性校验，需要周期性校验和采样确保备份真正可用，而不是备份了就万事大吉；
   第三点：加强自动化建设，减少人对线上体系的手动干预，通过工具固化流程，隔离风险；
   第四点：chaos monkey，平时不练兵，指望战时打胜仗那是不可能的；

   第五点也是最重要的一点，发生这种事情，归根到底一定是管理问题。很多公司在业务发展停滞的时候，很容易把技术和技术人员当做成本，而不是财富，总希望再多砍点人，再减少一些IT支出，这里需要管理层，特别是CEO和CTO把持好尺度，做好利润和成本的balance，同时确保人员招聘质量，通过一些测试，避免一些思想异常的人员进入公司(对此我有深刻的体验，以后有机会可以和大家聊聊)，严进宽出，适度加大技术投入，建立起人才梯队，避免人员单点，同时加强人文关怀，对技术人员，特别是一线技术人员好一点，多些关心和交流。

   写到这里，基本上完成了此次微盟事件的复盘，希望其他的公司能真正的吸取教训，避免类似的事情再次发生，也希望所有技术的小伙伴能有所收获。
   `

   回复

2. 微盟数据被删后的七天七夜
   https://mp.weixin.qq.com/s/MFhnc4qPpxxxZY1O-uTk1g
   `
   技术团队很快对修复方案达成一致：鉴于数据库服务器上文件数量多，类型复杂，文件的提取和确认难度很大，而备份服务器上文件类型单一，数据集中，且微盟数据被删后，硬盘没有被二次写入，理论上里面可能存在相对完整的备份数据，团队决定从备份服务器入手，尝试恢复数据。

   他们很快面临了第一个艰难的抉择——

   通常来说，数据修复的第一步是对源数据进行镜像拷贝，以避免修复过程中源数据受损的风险。如果采用网络传输进行拷贝，以微盟的数据体量，光是数据拷贝过程就至少需要2天以上，会让数据修复的时间进一步加长。“微盟和商家们都等不起。”

   另一种惯用的处理方式是将原来服务器上的硬盘拆装后挂载到新服务器上，以并行的方式进行“硬盘对拷”。这样可以节约时间，但风险是一旦中途出现故障，源数据可能会因此完全丢失。“对于仅有一次这样修复机会的微盟来说，这样做风险太大。”

   两难之下，在征得微盟同意后，团队做了一个大胆的决定：越过镜像拷贝的步骤，同时不将微盟的数据盘从原有服务器上拔下来，而是将另外一块系统盘安装到原有服务器上，通过新系统盘加载OS和数据恢复软件，直接扫描提取数据盘中的“隐藏”数据。

   这样做的依据是，数据硬盘的健康度良好，且腾讯云技术团队有丰富的硬件处理经验，有较大把握在源数据不损伤的前提下进行扫描。这相当于借助一根体外供血管在体内完成这场手术，通过完美的技术，实现效率与完整性兼顾。

   ==
   徐勇州彻夜未眠。思量再三，决定两条腿走路：一是尝试对磁盘的每一块（block）进行二次扫描；二是让腾讯云的操作系统团队从OS底层入手，制定数据恢复方案PlanB，这需要极其庞大数量的尝试和数据验证，“方案一能成功是最理想的，方案二就意味着数据恢复的时间不确定，业务停摆，继续失血。”

   周四上午，第一台服务器的第一块扫描成功，导回数据库查看是完整的。“方案一可行！大家信心一下子又起来了。”

   从可行到成功，中间仍有艰难险阻。数据公司提取出来的单一的块，从体积来看还是达不到微盟核心文件的大小。这意味着，要获得完整数据，需要进行数据“拼接”。

   就好像整块拼图被打散扔进了大海里，一块一块打捞上来是第一步，拼接是第二步。不同的是，拼图时还能够根据形状来判断哪些可以放在下一块，而拼接数据块，根本无法通过肉眼识别，只能靠一块块去扫描，寻找相似度高的拼接到一起，再重新扫描看断点是否能重合。

   庆幸的是微盟的备份机制较为完备，数据的覆盖度和完整性检查等工作非常细致。徐勇州发现，文件类型只有一种，那么就能很容易判断出哪块是开头，拿着开头去找剩下的块，把工作量从“N*N”降低到“1*N”。

   但“1*N”的工作量也不小。最大的一个文件，由7块碎片组成。找到开头以后，工程师开始扫描其他有相似性的块。运气好的时候，相似度可能只有一块，运气不好的时候 ，有二三十块。每进行一次拼接，都需要把数据块从头到尾扫描一遍，验证是否匹配。这需要大量的计算力。为了加快扫描和验证，腾讯云服务器团队还临时从上海机房调拨了100多台服务器进行算力支持。

   徐勇州已经不记得这样的“打捞、拼接、扫描、验证，重新打捞、拼接、扫描、验证”进行了多少次，只记得每一次都是四五个小时的煎熬。“大家每隔一会儿就在腾讯会议上吼，好了没，好了没，快看看！”

   终于，一块又一块的数据被拼接出来，核心数据逐渐被修复。“太不容易了，心情真的跟过山车一样。”

   2月28日，深夜，数据修复胜利在望。
   `

   回复

3. 链家40岁员工删除公司9T数据，被判7年
   https://www.4hou.com/posts/Yq49
   `
   根据中国裁判文书网的消息，原链家网（北京）科技有限公司数据库管理员韩冰因犯破坏计算机信息系统罪一审被判处有期徒刑七年，二审驳回上诉，维持原判。

   回看 2020 年，删库事件接二连三：

   1、2020 年 2 月 23 日 18 时 56 分许，贺某酒后因生活不如意、无力偿还网贷等个人原因，在其暂住地上海市宝山区逸仙路 XXX 弄 XXX 号 XXX 室，通过电脑连接公司虚拟专用网络、登录公司服务器后执行删除任务，将微盟服务器内数据全部删除。

   导致微盟自 2020 年 2 月 23 日 19 时起瘫痪，300 余万用户（其中付费用户 7 万余户）无法正常使用该公司 SaaS 产品，经抢修于 3 月 3 日 9 时恢复运营（故障时间 8 天 14 个小时）。

   截至 2020 年 4 月 30 日，造成微盟公司支付恢复数据服务费、商户赔付费及员工加班报酬等经济损失共计人民币 2260 余万元。

   最终，贺某犯破坏计算机信息系统罪，判处有期徒刑六年。

   2、2020 年 4 月 13 日，王某因某网络科技有限公司 驳回其开发的 OBS 对象存储服务代码的奖金要求，心怀不满，便产生了报复公司的想法。

   当日 11 时许，王某在该公司使用 root 超级管理员账户登录至华为云服务器的 FTP，修改了其开发的 obs 对象存储服务代码，导致 2020 年 4 月 14 日 8 时至 9 时 35 分，某平台运行异常，该公司代发的政府电子消费劵领取受阻，直至当日 10 时 43 分，11225 名会员才领取完当日电子消费劵，给该平台声誉及会员收益造成严重影响。

   最终，王某被判处拘役五个月、缓刑六个月。

   这些事情告诉所有打工人：删库或许容易，但跑路是不可能的。最后，希望所有公司做好安全方案的同时善待打工人。
   `

   回复

4. 如何防止数据库管理员DBA的删库操作，一次windows电脑木马误报分析，某企业勒索事件处理讨论 | 总第168周
   https://mp.weixin.qq.com/s/mKGMHBwkDZeb_Uy9UcnLoA
   `
   话题1：咨询一个问题，像dba和虚拟化管理员这样的人员，靠技术能管住吗？
   A1:通过运维管理系统设置强复核管控，A录入，由B确认操作。
   A2:这是个有意思的问题，谁能删库的问题。
   A3:那安全不得背下所有的效率低下和成本高昂的锅。
   A4:这不叫背锅吧，这个是监管要求，也是风险管控措施，**安全是采取合适的方式满足监管要求，防控风险。**

   Q:他们真想干坏事，这系统有用吗？写脚本、通过逃生通道进入、加个定时任务等等。你能管得住他的动机吗？

   A5：我觉得可能管不了，最多能审计追查，还得靠人性和运气。
   A6:**实际上，什么叫管得住，这是个问题，一个角度看，不出事儿，换个角度看，说得清，我觉得就算管住了，不能搞绝对，世事无绝对。成本效益原则。分级分类上手段砸银子。**

   Q:在这里，管的住的定义是“想干的坏事的人干不了”。在这个背景下，这个原则的具体表述应该是什么，才比较合适呢？

   A7:只能具体情况具体问题。不计较，没太大所谓的情况，和不计成本非常绝对的情况，不一样。
   A8:对，难道你家怕被偷，也装一套金库用的安防系统嘛。
   A9:数据宿主是研发团队，不是DBA。我系统解释下。
   * 数据宿主是研发团队，不是DBA。所以发起方不能是dba。
   * 现在都是靠数据库变更系统进行变更操作的，杜绝人工操作的风险。
   * dba要做的事情是复核开发写的sql脚本，通过后，进行变更操作。
   * 正常dba规范里面是禁止删字段的。数据也是一样，主要是做修改，数据修改前置条件是，业务方发起，运营团队审批通过，开发编写脚本，dba执行。
   * 做的好点的，db账号都是特权管理平台管控的。安全运营会赋权给dba做人工操作。
   堡垒机也是，但是原则上来说，这些账号信息绕不过dba负责人，dba负责人要搞事，还是有办法的。

   A10:所以可以默认dba是自己人，可以信任的人了。信任是安全的基础及出发点。安全是九门提督，dba是大内侍卫，可以对dba提点要求，但是想管估计管不住。

   Q:GitOps能应用到这种场景么？把手工命令改成脚本，脚本提交到git ，git审批发布后，后台系统执行脚本。

   A11:可以审计。堡垒机和数审。
   A12:安全不是东厂吗。以前在老东家抓了几个内鬼，然后CEO内部会议对我们评价，也不知道是褒是贬。

   Q:内鬼是要干啥呢？抓内鬼的思路分享下如何?

   A13:和黑产相关。可以找时间私下交流，不太适合在外讲哈。
   A14:感觉在鉴定是不是“内鬼”上有点麻烦。
   A15:嗯，送到ga局有一个关键环节是，是否获利，如果有获利行为基本可以认定，但这个确实是最难处理的。
   A16:**特别对于业务数据，隐私现在有法律保护，业务没人管需要自己举证这些数据值多少，为什么值，又很难被认可。**
   A17:如果真是拿了隐私数据倒是好事，这个很好定量。也是风头上，ga更愿意打击。
   A18:DBA全部要求必须党员，家庭背调，根正苗红。拉征信，无犯罪记录。无犯罪证明是目前入职的基本要求吧。尤其是金融业。
   A19:不一定吧，不过背调公司可能能调查过了。我们公司入职体检要求都没有。按照这个角度来讲，SRE也得是党员了，SRE不能背研发的锅，研发也得有个高身份…研发出来的东西给运营来搞，运营的要求不怎么高，至少怎么也得是个团员吧。
   A20:确实，记得有次和一SRE哥们访谈操作风险，他信誓旦旦和我说他是多年老党员，还有多年优秀党员奖状做证明。他老板招人也会主动考虑有党员背景和考察人品。
   `

   回复