题头:

2015-05-28日,携程被***,网站APP全面瘫痪。

截至下午14:40左右,网站主页可以打开,但服务仍然不可用。

网传因为数据库遭物理删除导致。

尽管网传不可尽信,后续携程也发文数据库未丢失,但是数据安全一事,不可小觑。加上3月份信用卡信息泄露一事,携程此次可以说是雪上加霜。

其实,关于数据安全一事,也并非携程一家有此问题。之前酒店开房信息泄漏问题,也炒的沸沸扬扬。

提起数据安全,大多策略集中在防止数据泄露和损毁。

设置强密码策略,增加破解成本,防***和防遍历下载,sql双写和定时备份等策略。

这些策略,某种程度上,在技术角度增加了数据安全性和数据完整性。但这只是针对外来***所做的防御性策略。殊不知,碉堡都是从内部毁坏的。

本文大体讨论下,如何从内部管理方面,控制数据安全风险。

一、独立DB Server的root权限

IT公司,尤其是互联网公司,因为需要管理大规模的服务器集群,运维人员很多,二线互联网企业可能二三十人,大型互联网公司可能百余人运维团队负责维护所有服务器。

运维人多手杂,如果有人恶意破坏内部数据,只需要借助工作便利,插入一点恶意脚本,定时N天之后,物理删除某个目录或者写01进去,数据自然被损毁无疑。如果更加彻底一点,所有的主从db都来一次,周期性备份一删,估计神仙都难找回,或者,只能从光盘备份进行恢复了。

但是DBA人数并不多,至少,比运维少一个数量级了。

所以,可以将DB服务器root权限交由DBA管理,运维不再拥有管理这几台服务器的权限。

DBA内部由上至下进行权限分配,由部门领导或主管,持有DB Server的root权限,尽量控制在2~3人范围。

其余DBA员工只拥有DB的权限,或根据等级,进一步剥离权限(根据经验,此条可能根本无法最终落实)。

然而,此处只能用于防范员工对DB进行物理操作,领导的操作,行政范围内不可能限制。及时领导范围内想要做任何破坏性操作,鉴于定位操作者极为容易,相对风险太高的事情,也不会有人做了。

二、运维管理备份数据

DBA团队管理DB,需要对所有数据库进行每日增量备份以及定期的全量备份。

可以挑选访问量最小的时候,对新增数据进行备份。

备份可以由程序定点执行,将所需要备份的数据,同步到DBA管理范围之外的机器中。

该机器由运维部门提供维护。

两个部门相互独立,以保证数据不由单一部门操作,避免任一层面的员工对数据进行破坏性删除。

三、重要数据的日志备份

业务线实时日志可以用于在意外发生时,恢复自备份db时间起,至当前时间为止的新增热数据。对此类数据,业务本身会打印log到当前的日志系统中。

或者有能力可以经由消息总线等机制,将全部操作dump到某一集群,对日志分析之后,将数据相关操作进行单独保存,此处扔由运维控制该权限。

四、数据库代码层面防删除

对于永久性的保留的数据,比如用户发帖信息,注册信息等,可以考虑在DB访问层增加策略,不允许代码直接访问数据库,所有访问db 的delete操作,一律由数据访问层在数据库中置位来保证真实物理数据永不被删除。

对于可删的数据,例如图片访问链接,电商的店铺商品注销等,可以也由数据访问层控制,置为删除,实际后台线程扫描,在删除操作48小时以后仍无任何操作的情况下,进行删除。

代码层面控制,尽量交付程序,而不由人工控制,以免发生内部破坏。

五、备份数据的恢复

如果发生任何意外,真有DBA主管级别删除DB数据,可以查看是否从库可以恢复。

如果从库也已经遭到物理删除,还可以从运维部门的备份服务器中,取出之前的备份数据,及时恢复。此时,数据可能已经丢失从备份时刻到当前这段时间内的数据,但总体效果已经比重建db要强得多了。

未备份的数据,可以从业务日志中进行读取恢复。

结论:

数据安全性方面,技术性安全策略可以用来有效防止***。

但真正的安全,除了技术方向,还有赖于内部行政管理策略以及权限和责任的划分。

不让数据控制在某一部门甚至某一员工手中,独立各部门职责和访问权限。

增加delete的人工可操作性,防止数据丢失。

有关数据安全,责任重大,实际生产中,无法做到100%的安全,只能尽人事,听天命。

 

如果以上暂时都难以执行,那么还有一个终极办法:给运维和DBA涨工资,发妹子,以稳定军心~~~

向携程问好~~~


原文链接:从携程被***看数据安全 - 零度空间