02.28 微盟删库是什么原因?你怎么看?

Java修炼者


对于涉事员工,若是情况属实,肯定要吃牢房了,而且还摊上经济赔偿。

对于微盟会:

1若公司内部有完备的应急机制,立即启动应急预案,第一时间确保系统正常,然后逐步恢复数据(要是没有应对机制,只能说明运维部门不够正规,或者领导不重视;另外,这样的事情发生也说明内部管理不严谨)

2若能快速恢复业务,并做好客户安抚工作,应急公关给力的话,相当于爆炸性的推广效应。若是公司没有能力应对此次危机,而且没有出台有力措施留住客户,很可能造成用户大量流失,从此一路下行。对于微盟的友商或者行业:大家正好趁机发力拉用户;大家的运维投入会加大,流程规范会加强。

至于真正的原因呢,就不说了吧,能做出这种破坏级别的行为,要承担什么后果估计自己早就想明白了。


残酷de宠溺


这位删库的员工显然是一时头脑发热的行为,犹如烈性传染病一样,以极快的速度干掉宿主造成的危害其实对人群是较小的。要实现目标可以用更加有策略的方案。


现代大部分企业的运维环境往往是经过这样的步骤来登录和执行操作的:

登录堡垒机,需要堡垒机权限
在堡垒机上登录到线上服务器,需要目标服务器权限
执行操作
这里的核心就是堡垒机是会记录你执行的每一条命令的。执行过的命令会留存日志。

所以想要造成尽量大的危害,需要从三个角度工作:

不删除数据库,而是在数据库里塞满垃圾数据,把原数据修改成垃圾数据,清除垃圾数据比恢复数据库困难很多倍,需要人工审核每一条修改的合理性
在堡垒机一层隐藏自己的行为,难以追查来源
制造垃圾数据的过程溪水长流,让公司发现问题时,可能已经过了几十天甚至几个月,数据库旧备份已经不存在了
删除数据库自然是很激烈的,但很多公司的数据库权限经过配置是不能删除的。而ssh登录数据库服务器又是个很敏感的权限,申请时就会被怀疑。

溪水长流的制造垃圾数据可以选择业务比较重要的库,比如用户余额,库存等等,涉及到钱的最好。在制造垃圾数据时,避免使用过于随机的方式,而是可以用比如给用户增加个20%的余额之类的方法。这样用户没发现自己余额不足时是不会提起警惕的。等到公司发现时,损失就已经很大了。


堡垒机上的审计日志只会记录自己直接输入的命令。而自己编写的脚本再上传是,执行过程是不会留下记录的。如果还是担心,可以加密自己的脚本上传,到了服务器后再解密。脚本本身可以避开shell、python等常用玩法,而用其他冷门一点的。这样都可以增加发现的困难性。

脚本的定期执行,简单的可以用cron,但应该选择不常用用户来执行cron,比如某个服务的账户。如果担心cron被发现,也可以用supervisord,或者自己写个常驻进程等方式来做。

对于修改用户余额之类的操作,一个注意的要点是避免公司每天的对账系统发现异常。尽管大部分公司并没有该系统。通常一个公司对账系统是允许有一定的误差的,即每天的帐算不平。如果知道这个比例,使得自己每天修改账户的总额不超过该阈值最好,如果不知道,也可以尝试用每天0.5%之类的比例。十几年前听过某航空公司每天算不平的帐有20万左右。所以,只要自己修改数据库每天不超过这个额度就可以慢慢的搞死这个公司。

最后,如上的方法原则上用几个月的时间还是可以追查出来责任人,所以跑路还是必要的。

\n

{!-- PGC_VIDEO:{"thumb_height": 544, "vposter": "http://p0.pstatp.com/origin/tos-cn-p-0000/0c852dcf1c6f4eb6a47ebadf2a3f4f98\

微事儿


至于员工删库原因,多的我也就不知道了,这个图也是头条抄来的。据网上流传,不一定准确!


最后还是希望这件事尽早解决,微盟顺利度过难关。



科讯SCI


我们公司就是用的微盟产品,虽然网上传的沸沸扬扬的是程序员被绿,但我觉得可能是疫情导致员工待遇受到不公平遭遇,加之在家办公无法察觉员工心里状态,导致心态失衡的员工一气之下做出的事情


幽城酒客在山城


必须绳之以法

\n

{!-- PGC_VIDEO:{"thumb_height": 808, "vposter": "http://p0.pstatp.com/origin/tos-cn-p-0000/65766c144d9546328b892ef2d8ce986e\

罩一兆


估计没那么简单,维护人员操作失误


分享到:


相關文章: