2015-05-28日，携程被攻击，网站APP全面瘫痪。
截至下午14：40左右，网站主页可以打开，但服务仍然不可用。
网传因为数据库遭物理删除导致。
尽管网传不可尽信，后续携程也发文数据库未丢失，但是数据安全一事，不可小觑。加上3月份信用卡信息泄露一事，携程此次可以说是雪上加霜。
其实，关于数据安全一事，也并非携程一家有此问题。之前酒店开房信息泄漏问题，也炒的沸沸扬扬。
提起数据安全，大多策略集中在防止数据泄露和损毁。
设置强密码策略，增加破解成本，防入侵和防遍历下载，sql双写和定时备份等策略。
这些策略，某种程度上，在技术角度增加了数据安全性和数据完整性。但这只是针对外来入侵所做的防御性策略。殊不知，碉堡都是从内部毁坏的。
本文大体讨论下，如何从内部管理方面，控制数据安全风险。
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涨工资，发妹子，以稳定军心~~~
向携程问好~~~
原文地址：http://blog.csdn.net/u011650565/article/details/46228341
