0、导读

   MySQL被运用于越来越多的业务中，在关键业务中对数据安全性的要求也更高，如何保证MySQL的数据安全？

   MySQL被运用于越来越多的业务中，在关键业务中对数据安全性的要求也更高，如何保证MySQL的数据安全。

   数据安全如果只靠MySQL应用层面显然是不够的，是需要在多个层面来保护的，包括网络、系统、逻辑应用层、数据库层等。

   下面是我们可借鉴的一些安全策略。

1、网络、系统层面

   在这个层面可以做很多的事情，我们可以把这些安全要求作为新系统安装时的标准要求，放到自动化装机方案中。

• 把运行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上作为个人项目，内含内网账号密码信息）。

2、逻辑应用层

   在这个层面，等多的是依赖运营及开发人员的安全意识，很多本可以避免的低级安全漏洞完全可以在这个层面处理掉，比如下面提到的XSS、CSRF、SQL注入等漏洞。

• 尽量不要在公网上使用开源的cms、blog、论坛等系统，除非做过代码安全审计，或者事先做好安全策略。这类系统一般都是黑客重点研究对象，很容易被搞；

• 在web server层，可以用一些安全模块，比如nginx的WAF模块；

• 在app server层，可以做好代码安全审计、安全扫描，防止XSS攻击、CSRF攻击、SQL注入、文件上传攻击、绕过cookie检测等安全漏洞；

• 应用程序中涉及账号密码的地方例如JDBC连接串配置，尽量把明文密码采用加密方式存储，再利用内部私有的解密工具进行反解密后再使用。或者可以让应用程序先用中间账号连接proxy层，再由proxy连接MySQL，避免应用层直连MySQL；

• 应用层启用关键日志记录，例如交易日志，方便后续对账什么的。

3、MySQL数据库层

   前面几层如果都做的不够安全的话，在这层也几乎是岌岌可危了。但我们依然可以做些事情的。

• 启用 safe-update 选项，避免没有 WHERE 条件的全表数据被修改；

• 将 binlog 的保存周期加长，便于后续的审计、审查；

• 应用账号只赋予SELECT、UPDATE、INSERT权限，取消DELETE权限。把需要DELETE权限的逻辑改成用UPDATE实现，避免被物理删除；

• 需要真正删除时，交由DBA先备份后再物理删除；

• 可以采用Percona的SQL审计插件，据说还有macfee的插件；

• 还可以采用触发器来做一些辅助功能，比如防止黑客恶意篡改数据。

4、后记

   数据安全可以做的事情很多，本文也只是罗列了一些比较简单可快速实施的方案。每个企业应有自己的安全策略规范，每一位参与者都应该心怀敬畏，努力遵守这些必要的规范，不使信息安全成为空谈。

   真正的数据安全，是靠所有人的意识安全作为支撑的，没有这个意识靠机制、制度、工具都是不靠谱。

猜您喜欢

• 2013 年 5 月 15 日 -- MySQL 5.6 新增的两个密码安全策略体验