资料安全是现在网际互联网安全非常重要一个环节。而且一旦资料出现问题是不可逆的，甚至是灾难性的。
有一些防护措施应该在前面几个博文说过了，就不再赘述。比如通过防火墙控制，通过系统的使用者控制，通过 Web 应用的控制等。
想说的是，任何一个节点都不是单独存在的。
场景
1 、确保应用本身安全。
2 、控制系统使用者对资料库的访问许可权。
3 、控制资料库使用者对资料库的访问许可权。
4 、确保资料库敏感资料的安全。
5 、确保资料库整个资料的完整性。
6 、规范日常运维操作
7 、合理的划分业务。
站群解决方案
应用安全
删除预设的资料库和使用者
mysql 初始化后会自动生成空使用者和 test 库，这会对资料库构成威胁，我们全部删除。
mysql> drop database test;
mysql> use mysql;
mysql> delete from db;
mysql> delete from user where not(host=”localhost” and user=”root”);
mysql> flush privileges;
禁止资料库从本地直接载入内容
在某些情况下，LOCAL INFILE 命令可被用于访问操作系统上的其它档案 (如/etc/passwd)，应使用下现的命令：
mysql> LOAD DATA LOCAL INFILE ‘/etc/passwd’ INTO TABLE table1
# 更简单的方法是：
mysql> SELECT load_file(“/etc/passwd”)
为禁用 LOCAL INFILE 命令，应当在 MySQL 配置档案的 [mysqld] 部分增加下面的引数：
set-variable=local-infile=0
控制使用者的许可权
这里使用者，指的是资料库里的使用者。
控制访问的 ip 。
只允许信任的 ip 访问，其他的 ip 都应该拒绝。
比如：只允许办公互联网，还有业务站群服务器对应的互联网可以访问。
区分角色
区分角色，给不同的许可权。角色的划分需要根据具体的使用场景。
下面简单举例：
1 、角色：view 。许可权：只允许查询资料，不允许做任何修改。场景：业务正确性验证时
2 、角色：update 。许可权：允许修改资料，但是不允许修改资料结构。场景：程式执行
3 、角色：operate 。许可权：允许修改表结构，允许新增和修改表，不允许删除表，不允许删库。场景：产品要释出的时候才可以使用，通过升级 sql 方式执行。
4 、…..
加密敏感资讯
要使用 md5,sha 等演算法加密。这样即使资料丢失，也能减少损失。比如：登入密码，支付密码等。
保证资料的完整性
1 、解决单点故障。主从，主主。
2 、需要备份与还原。
规范日常操作
1 、如果没有特殊需求，应该使用最小的使用者。比如只使用检视的使用者。
2 、有需要修改资料或者结构的操作，可以考虑两人一起。或者可以考虑做成功能，减少人为直接运算元据库。
3 、在测试环境上测试 OK，才往正式环境执行。
业务的划分
少用资料库
可以通过 WordPress 加速缓存，静态化。尽可能少的使用资料库。能不使用资料库是最安全。
分库分表
敏感的资料和常用的资料，最好从表的设计上隔离。比如：使用者的详情资讯和支付资讯最好分开。
优化 sql
这个也非常重要，往往就是因为不重要 sql 的优化，所以资料库对应的站群服务器资源吃满不提供服务。
验证方法
通过不同的账号操作，判断有没有对应的许可权。