题头：

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涨工资，发妹子，以稳定军心~~~

向携程问好~~~


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