1 个自动化脚本搞死公司,是碰瓷么?看后续调查结果
Posted Python开发者
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了1 个自动化脚本搞死公司,是碰瓷么?看后续调查结果相关的知识,希望对你有一定的参考价值。
(给Python开发者加星标,提升Python技能)
原创:Python开发者(id:PythonCoder)
5 月 31 日,1 个法国程序员 Nicolas Beauvais 在推特上控诉 DigitalOcean 搞死他们公司 Raisup。
「Python开发者」之前推文《》中已有详情,DigitalOcean 承诺后续将公布事件调查结果。
6 月 5 日,DO 的 CTO Barry Cooks 在官博发文,梳理了事件经过和调查结果。
「Python开发者」翻译并整理如下:
第 1 次被封
5 月 29 日,Raisup 账号第 1 次被封。Nicolas 给出的理由:「DO 认为那个 Python 自动化脚本可能是恶意程序」。
Barry 的解释:
DO 有 1 个自动化服务,用于监控加密货币挖矿行为,比如:虚拟机的 CPU 负载和创建虚拟机的行为。除了这些因素外,还考虑了一些账号级的因素(包括付款历史记录和当前运行速度与总付款的比较)。目的是最小化潜在的高 CPU 负载欺诈对其他客户的影响。
在对账号采取任何操作之前,会检查自动安全性,以避免对信誉良好而没有任何警告的客户采取操作。
不幸的是,在这种情况下,安全性不足以阻止自动化操作。此外,由于客户是赊账运行的,所以他们没有清晰的付款历史记录,这意味着没有触发一个主要的安全性(付款历史)。自动化服务代表客户创建一个支持 ticket,以便就操作进行快速通信。
悲催的是,
Nicolas 在多个虚拟机上并行启动了他的 Python 自动化脚本高,导致 CPU 高负载;
Nicolas 是赊账(on credit),没有清晰的付款历史记录。
这 2 个因素触发了第 1 次封禁。
第 1 次解封
Nicolas 回应了 DO 发出了 ticket 后,经过多次沟通。
DO 的一位滥用操作(Abuse Operations)代理在 Raisup 宕机 12 小时后重新启用了他们的账号 。然而,这个代理同时还犯了一个错误,没有把 Raisup 的 CPU 高密集活动标记成「已批准」,这就给第 2 次封禁埋下了祸根。
第 2 次被封
上面已提到,因为 DO 代理的失误,没有把 Raisup 标记成「已批准」。而 Nicolas 在账号第 1 次解封后又搞了一回 CPU 高密集操作……
这又被另外一个滥用操作代理发现了(不是第一次封号的代理),于是 Raisup 账号又悲剧了,Nicolas 收到了拒绝解封的自动回复邮件。
最终解封
后来 Nicolas 持续在推特发帖,引起大量开发者围观,事件发酵后,引起 DO 官方和 CTO 的关注。
经过后续沟通,DO 最终解封 Raisup 的账号,重启了他们的虚拟机,并且标注了合适的安全标识,
DO 领导层出面道歉,Raisup 接受。Nicolas 可以继续愉快地在葡萄牙度假了。
DO 未来的改进
Barry Cooks 表示,这是一起跨技术、人员、流程引发的事故。
技术
旨在防止欺诈和滥用算法对健康、非滥用的客户采取自动操作的安全措施,但这那些对于没有支付历史记录的客户来说,是不够的。
流程
对客户的响应时间框架是 12 小时,然后是 29 小时,因为后续锁的响应时间太长了。
从 ticket 管理的角度来看,对帐户被锁的响应的优先级设置低了。
DO 第一次在推特上的回应没有认识到已经造成的潜在危害,也没有对客户的情况表示同情。
帐户被封后的自动回复邮件,没有解释原因,行文给客户造成一种无助感,需要纠正。
人员
没有遵循添加「Allow High Cpu Usage」标志的过程。
对报告的假阳性作出判断的准则并不明确,结果导致拒绝访问。
要改进的,就是上面这些出问题的地方,Barry 还在文中提到,为了防止再次出现类似情况,以后封锁客户账号,会改成两个代理一起审核。
详细改进,见:
https://blog.digitalocean.com/an-update-on-last-weeks-customer-shutdown-incident/
,看完这个后续,你还坚持碰瓷说法么?
推荐阅读
(点击标题可跳转阅读)
觉得本文对你有帮助?请分享给更多人
关注「Python开发者」加星标,提升Python技能
好文章,我在看❤️
以上是关于1 个自动化脚本搞死公司,是碰瓷么?看后续调查结果的主要内容,如果未能解决你的问题,请参考以下文章