摘要：MySQL数据安全策略（转自：知数堂–老叶茶馆http://t.cn/EfvKeFD）
导读
MySQL被运用于越来越多的业务中，在关键业务中对数据安全性的要求也更高，如何保证MySQL的数据安全？
MySQL被运用于越来越多的业务中，在关键业务中对数据安全性的要求也更高，如何保证MySQL的数据安全。
数据安全如果只靠MySQL应用层面显然是不够的，是需要在多个层面来保护的，包括网络、系统、逻辑应用层、数据库层等。
下面是我们可借鉴的一些安全策略。
网络、系统层面
在这个层面可以做很多的事情，我们可以把这些安全要求作为新系统安装时的标准要求，放到自动化装机方案中。
把运行MySQL的服务器放在内网中，不要启用公网；
迫不得已启用公网的话，修改sshd端口到10000以上；
设置防火墙策略，只允许信任的服务器连接sshd和MySQL端口；
修改idrac/imm密码，设置GRUB密码；
设置密码安全策略，比如要求 PASS_MIN_LEN 不低于8位，其实最好是直接用一个复杂密码做MD5之后再作为正式密码，32位长度的安全程度够高吧；
将操作日志记入syslog并且发送到远程log server上，坚决不能只存储在本地；
除了必须的账号，其他的都设为无登入权限；
尽量把运行MySQL的服务器独立出来，不要和web server、app server放一起。必须放一起的话，也要设置好权限分离，不允许web server、app server进程的属主有直接访问MySQL datadir的权限；
禁用web server层的autoindex配置；
可能的话，采用https代替http；
关键应用保持更新，避免老版本的漏洞风险；
设置nginx、php等应用服务的安全策略，禁用危险函数等；
可以考虑购买运营商提供的一些安全防护、扫描器等产品；
坚决杜绝二逼行为，把关键配置文件上传到公共网络上（如把公司项目代码放在github上作为个人项目，内含内网账号密码信息）。
逻辑应用层
在这个层面，等多的是依赖运营及开发人员的安全意识，很多本可以避免的低级安全漏洞完全可以在这个层面处理掉，比如下面提到的XSS、CSRF、SQL注入等漏洞。
尽量不要在公网上使用开源的cms、blog、论坛等系统，除非做过代码安全审计，或者事先做好安全策略。这类系统一般都是黑客重点研究对象，很容易被搞；
在web server层，可以用一些安全模块，比如nginx的WAF模块；
在app server层，可以做好代码安全审计、安全扫描，防止XSS攻击、CSRF攻击、SQL注入、文件上传攻击、绕过cookie检测等安全漏洞；
应用程序中涉及账号密码的地方例如JDBC连接串配置，尽量把明文密码采用加密方式存储，再利用内部私有的解密工具进行反解密后再使用。或者可以让应用程序先用中间账号连接proxy层，再由proxy连接MySQL，避免应用层直连MySQL；
应用层启用关键日志记录，例如交易日志，方便后续对账什么的。
MySQL数据库层
前面几层如果都做的不够安全的话，在这层也几乎是岌岌可危了。但我们依然可以做些事情的。
启用 safe-update 选项，避免没有 WHERE 条件的全表数据被修改；
将 binlog 的保存周期加长，便于后续的审计、审查；
应用账号只赋予SELECT、UPDATE、INSERT权限，取消DELETE权限。把需要DELETE权限的逻辑改成用UPDATE实现，避免被物理删除；
需要真正删除时，交由DBA先备份后再物理删除；
可以采用Percona的SQL审计插件，据说还有macfee的插件；
还可以采用触发器来做一些辅助功能，比如防止黑客恶意篡改数据。
按外网安全和内网安全分为如下两部分
内部操作安全策略
是否回收DBA全部权限
试想，如果DBA没权限了，日常DB运维的活，以及紧急故障处理，该怎么实施呢？因此，建议在没有成熟的自动化运维平台前，不应该粗暴的回收DBA的太多权限，否则可能会导致工作效率降低的，甚至DBA有一种不被信任的负面情绪。
MySQL层安全策略
业务帐号最多只可以通过内网远程登录，而不能通过公网远程连接。
增加运维平台账号，该账号允许从专用的管理平台服务器远程连接。当然了，要对管理平台部署所在服务器做好安全措施以及必要的安全审计策略。
建议启用数据库审计功能。这需要使用MySQL企业版，或者Percona/MariaDB分支版本，MySQL社区版本不支持该功能。
启用 safe-update 选项，避免没有 WHERE 条件的全表数据被修改；
在应用中尽量不直接DELETE删除数据，而是设置一个标志位就好了。需要真正删除时，交由DBA先备份后再物理删除，避免误操作删除全部数据。
还可以采用触发器来做一些辅助功能，比如防止黑客恶意篡改数据。
MySQL账号权限规则
业务帐号，权限最小化，坚决不允许DROP、TRUNCATE权限。
业务账号默认只授予普通的DML所需权限，也就是select、update、insert、delete、execute等几个权限，其余不给。
MySQL初始化后，先行删除无用账号，删除匿名test数据库
创建备份专用账号，只有SELECT权限，且只允许本机可登入。
设置MySQL账号的密码安全策略，包括长度、复杂性。
关于数据备份
记住，做好数据全量备份是系统崩溃无法修复时的最后一概救命稻草。
备份数据还可以用来做数据审计或是用于数据仓库的数据源拉取之用。
一般来说，备份策略是这样的：每天一次全备，并且定期对binlog做增备，或者直接利用binlog server机制将binlog传输到其他远程主机上。有了全备+binlog，就可以按需恢复到任何时间点。
特别提醒：当采用xtrabackup的流式备份时，考虑采用加密传输，避免备份数据被恶意截取。
外网安全策略
事实上，操作系统安及应用安全要比数据库自身的安全策略更重要。同理，应用程序及其所在的服务器端的系统安全也很重要，很多数据安全事件，都是通过代码漏洞入侵到应用服务器，再去探测数据库，最后成功拖库。
操作系统安全建议
运行MySQL的Linux必须只运行在内部网络，不允许直接对公网暴露，实在有需要从公网连接的话，再通过跳板机做端口转发，并且如上面所述，要严格限制数据库账号权限级别。
系统账号都改成基于ssh key认证，不允许远程密码登入，且ssh key的算法、长度有要求以确保相对安全。这样就没有密码丢失的风险，除非个人的私钥被盗。
进一步的话，甚至可以对全部服务器启用PAM认证，做到账号的统一管理，也更方便、安全。
关闭不必要的系统服务，只开必须的进程，例如 mysqld、sshd、networking、crond、syslogd 等服务，其它的都关闭。
禁止root账号远程登录。
禁止用root账号启动mysqld等普通业务服务进程。
sshd服务的端口号建议修改成10000以上。
在不影响性能的前提下，尽可能启用对MySQL服务端口的防火墙策略（高并发时，采用iptables可能影响性能，建议改用ip route策略）。
GRUB必须设置密码，物理服务器的Idrac/imm/ilo等账号默认密码也要修改。
每个需要登入系统的员工，都使用每个人私有帐号，而不是使用公共账号。
应该启用系统层的操作审计，记录所有ssh日志，或利bash记录相应的操作命令并发送到远程服务器，然后进行相应的安全审计，及时发现不安全操作。
正确设置MySQL及其他数据库服务相关目录权限，不要全是755，一般750就够了。
可以考虑部署堡垒机，所有连接远程服务器都需要先通过堡垒机，堡垒机上就可以实现所有操作记录以及审计功能了。
脚本加密对安全性提升其实没太大帮助。对有经验的黑客来说，只要有系统登入权限，就可以通过提权等方式轻松获得root。
应用安全建议
禁用web server的autoindex配置。
从制度层面，杜绝员工将代码上传到外部github上，因为很可能存在内部IP、账号密码泄露的风险，真的要上传必须先经过安全审核。
尽量不要在公网上使用开源的cms、blog、论坛等系统，除非做过代码安全审计，或者事先做好安全策略。这类系统一般都是黑客重点研究对象，很容易被搞；
在web server层，可以用一些安全模块，比如nginx的WAF模块；
在app server层，可以做好代码安全审计、安全扫描，防止XSS攻击、CSRF攻击、SQL注入、文件上传攻击、绕过cookie检测等安全漏洞；
应用程序中涉及账号密码的地方例如JDBC连接串配置，尽量把明文密码采用加密方式存储，再利用内部私有的解密工具进行反解密后再使用。或者可以让应用程序先用中间账号连接proxy层，再由proxy连接MySQL，避免应用层直连MySQL；
最后我们想说，任何高明的安全策略，都不如内部员工的安全意识来的重要。以前发生过一起案例，公司内有位员工的PC不慎中毒，结果导致内网数据被盗。
安全无小事，每个人都应铭记于心。在数据安全面前，可以适当牺牲一些便利性，当然也不能太过，否则可能得不偿失。