Error message here!

Hide Error message here!

忘记密码?

Error message here!

请输入正确邮箱

Hide Error message here!

密码丢失?请输入您的电子邮件地址。您将收到一个重设密码链接。

Error message here!

返回登录

Close

从微盟被删库谈企业安全管理

思否编辑部 2020-02-25 19:32:50 阅读数:93 评论数:0 点赞数:0 收藏数:0

作者:易阳
治学教育信息科技 CTO&联合创始人

早上爆出一条企业安全的大新闻,微盟被删库了.......大家先来看看新闻:

很震惊!很震撼!吓得我赶紧召集全公司服务端小伙伴Review了我们所有的安全部署!!!

彻底检查完之后,我放心了,我们即便被删库也可以快速恢复!

解决完隐忧之后,作为一个在业内安全大厂360工作五年的伪安全人士,今天跟广大做技术的小伙伴聊聊企业安全那点事:


01 事件复盘

公告透露出两个重大信息!我们来看看:

第一,恢复时间长,公告是这么说的:「和您一样,我们度过了漫长的36小时,我们预计此次故障还会持续一段」。

那么为什么需要这么久的时间来恢复?

以我的经验推测,一定是生产环境的主备数据库都被删库了!并且大概率应该是做了rm -rf类型的极端操作。不用怀疑就是传说中的删库跑路!当然影响是产生了,人肯定跑不了!

大家可能要问了,那数据库恢复下不就好了吗?没这么简单!

第二,更重要的信息!大家看看这句:「犯罪嫌疑人乃微盟研发中心运维部核心工作人员贺某」。原来是内部人员!

那为什么一个普通运维人员有如此大能量?

很简单,不少互联网的运维人员基本都会有root权限。基本就是公司业务上帝级别的存在。说实话,我做管理这么多年,对运维岗位一直是小心翼翼。当然是大厂可以做的更完善,权限分层分级,就很难出现这种情况。

现实是很多中小公司,运维就那么几个人,甚至一个人。


02 防删库指南

除了微盟这次安全事故,关于删库跑路,一直是互联网的黑传说。

IT界有一个老梗,某论坛的数据库管理员抱怨自己老板一直虐待他,结果他一气之下就删库跑路了……

再假设一种情况,如果在服务器维护的时候不小心执行了 rm -rf 命令……现在整台服务器被删光了肿么办???

对于中小公司来说,想把权限做完善做复杂,基本没有可能!想依赖运维人员本身素质和心理状态,那就是靠天吃饭!

中小公司防删库真正的答案是:做好备份!做好最小程度权限管理!**

1. 数据库备份很重要

先来看看一个标准的数据库架构图:

从上图中大家可以分析一下关键点:

主库:对应线上实时的业务,如果出现故障,整个系统和网站的访问将受到影响。从库:一般用于查询和主从切换之用。备份数据:备份方式常用全量备份和增量备份的方式。备份的策略包括跨机器、跨机房、跨区备份。数据是企业第一生产力,数据备份尤其重要。

存在数据备份问题的公司也有2个层次。最低层次的,有些公司压根就没有做备份,那出问题一定很麻烦,只能从磁盘做恢复,这个过程非常漫长!

不做数据备份的公司,长点心吧!特别是CTO或者技术负责人,淘汰的就是您这种呐!

高点层次的,有备份但只有全量备份没有增量备份。全量备份当然不能天天做,每个公司有自己的策略,可能是一个月一次也可能是一周一次。如果是这种情况,那这中间的一个月或者一周的备份数据还得从磁盘做恢复,一样很慢!

微盟虽然不是大厂,也算有一定规模了,备份肯定是做了。根据公告的信息,恢复需要这么久,我推断要么是全量是很久前做的,增量数据丢失了,要么是删除者做了极端操作都给干掉了!

2. 做好最小程度权限管理

BAT级别的权限管理,咱就不谈了,其实咱也不懂。懂了也没资源做。我谈谈中小厂怎么做好最小程度权限管理。 

数据库操作权限和备份权限分离

DBA负责日常主从库的管理和维护。运维负责备份数据的保存。采用全量和增量备份的方式。如果DBA删除主库,主从同步,则重库数据被删除。业务系统受到影响,运维能马上收到业务报警,运维同事接管数据库,进行备份恢复。

权限申请、权限审批和操作执行分离

开发人员做数据库表的删除或修改操作需要申请。技术主管或负责人审批,生成审批密码。开发人员根据密码登录特定服务器,进行相关的操作。

增加隔离层

关掉DBA操作数据库终端权限,通过yearning等审计平台执行数据库命令,高风险命令直接拒绝执行,并发出报警。技术总监或CTO确认没问题之后,才能执行。

以上三点,用最小资源去做,完全可行。如果还做不到,那就采用云解决方案,基本上用好云的方案,问题不大。

技术管理这件事,不能完全依赖人。看公告怎么说的:「因个人工作、生活等原因」。具体什么原因咱也不知道,反正人是不可控的!技术管理要有抓手!合理结合公司资源做一些限制是很有必要的!


03 关于云方案

先说下一点个人经历:

虽然没经历过删库跑路的情况,但是身边的程序员update语句不加where条件的情况发生过2次。

第一次,所在的公司是自建机房,由DBA团队管理数据库集群。某程序员把所有账户的积分字段改了,当时直接吓尿了。

当即停止账户操作的所有业务,DBA全量回复0点的数据,再找到binlog的update语句的执行点,重放binlog。检查数据恢复正常,重启开始账户相关的业务。耗时三个小时。

第二次,所在的公司使用云服务,数据库使用RDS。某程序员把跟进记录表的用户留言字段全部更改了,导致主从延时报警,销售人员没办法看用户留言的真实数据。

事情发生后,停止该表的业务,DBA通过云服务的工具直接恢复到发生问题前1秒的数据,从发现问题到解决问题也就是5分钟。

以上两个案例与删库跑路类似,都是数据丢失或数据污染之后的解决办法。但是处理起来,耗时不同。关键点在备份上!

给个建议!自建机房的方式需要有完备的dba和运维团队,对技术要求高,中小厂商没能力自建机房的,云方案还是要用起来。另外要关注云提供厂商提供的全套解决方案,千万别只把云方案当服务器使用。

微盟这次事故,我估计就没有采用云数据库,而是把云方案当服务器在用。云方案真正的价值在于容灾、快速扩容、紧急救火。这些能力中小公司要建立起来,不是说不可能而是难度极大。业务高速跑起来,压根没时间没资源去弄!

如果微盟用的是云数据库,云数据库一般都会保留binlog日志,先全量恢复再重放增量。这个恢复速度非常快,不会需要36小时还没弄完,产生这么大损失!

当然微盟也是受害者,说实话中国互联网发展太快,往往即便很努力也没法在很多方面考虑周全。好的是,有了云方案让一些中小公司的确会更高速的发展。看看公告:云厂商也在积极的帮助微盟做数据恢复!


写在最后的话:

技术人一定是保护用户数据的最后防线。最近几年,由于技术人员无意或者有意造成的事故不计其数。如果代码对世界的影响不大,那么这也许就不成问题。

打个比方,如果你写了一个危害几个人的代码,影响是极为有限的。但是如果你在拥有几亿用户的平台上做同样的事情,结果一定是惨烈的!

技术人一定要遵守职业道德底线,同时关注IT安全,尤其是技术管理者。希望我们一起让技术世界更安全更精彩!


作者简介:

易洋,治学教育信息科技 CTO&联合创始人。

前腾讯 QQGAME 高级工程师,前人人网游戏大厅技术经理,前 360 技术总监,前哒哒技术 VP,现担任土豆教育 CTO & 联创。在游戏领域、直播领域、安全领域都有深厚的积累。带领过超过 100 人的团队,有较强的团队管理能力。同时对产品和运营有一定的操盘能力。

图片描述

版权声明
本文为[思否编辑部]所创,转载请带上原文链接,感谢
https://segmentfault.com/a/1190000021837627