谁也不会想到，数据库跟战争会有什么必然的关系，更不会想到一场战争会因数据库而结束。但是，故事才刚刚开始...

数据库战争

2015年7月14日，经过12年的艰苦谈判，伊朗终于在国际社会的压力下同意将核能研究的用途限定于民生项目。

在此之前，因为《不扩散核武器条约》的限制，伊朗没有办法从任何具备核原料生产能力的国家直接购买高浓度的铀235。为了在经济崩溃前发展出核武器，伊朗不惜代价建设了大量的离心设备用于提纯矿石中的铀235。

另外一面，为了遏制伊朗的核能研究进度，美国和以色列*被曝早于小布什任期内就开始研发和散布Stuxnet蠕虫。该蠕虫能够入侵伊朗离心设备的配置数据库，人为加快离心机的转速，导致应该从矿中提取出来的铀235被加速甩到了离心设备的桶壁上，进而造成大量离心设备损坏，极大阻碍了伊朗的核研究进度。

双方的斗争最终以伊朗的数据库被攻破而结束。

 

自建数据库安全

抛开文中的特例，我们有理由相信并不是所有的数据库漏洞都被用来做好事了。举例来说，最近几年发生的多个知名互联网企业因为数据库漏洞而导致客户数据泄漏，就造成了非常广泛的负面影响。对于普通的数据库用户，我们建议从网络联通性、账号密码强度和备份文件保存几个方面去做改进。

首先，数据库应该尽可能禁止公网访问。自建数据库因为版本落后和管理人员安全意识的原因，多多少少会存在一些可以被黑客利用的数据库漏洞。如果这些漏洞暴露在公网上，数据在不知不觉的情况下被黑客窃取甚至篡改。

其次，数据库账号密码强度需要特别注意。自建数据库初始化后的管理员账号一般都配置了空密码或弱密码，只要具有网络联通性就可以轻松破门而入。高强度、定期修改的密码可以大大降低数据库被暴力破解的概率。建议数据库账号的密码至少三个月修改一次，密码长度至少为8位且包含三种以上的字符类型（数字、小写字母、大写字母、特殊符号）。

最后，数据库备份做到时刻能恢复到最新数据。数据库的全量备份每周至少有一次，而增量的日志备份要以半小时一次的频率进行。所有的备份应该离线保存在另外一个机房，并且要定期做恢复测试来保证备份的可用性。如果可能的话，要对备份文件进行加密，以防数据被人拷走。

 

阿里云RDS数据加密

云数据库RDS除了自动帮用户实现自建数据库上耗时费力的基础安全配置外，还支持网络和存储的数据方面加密，助力用户做好数据库的事前防护工作。其中，应用和RDS之间的网络流量采用安全套接层（SSL）协议进行加密：

 

用户还可以显式指定某些数据库内容在写到存储设备上之前通过透明数据加密（TDE）功能进行加密：

 

除了数据加密外RDS还有很多特性，具体请查看产品详情>>

 

最后衷心建议，先用RDS，再搞核武器。