MySQL安全问题（防范必知）

近期看帖子看到有人的数据库被攻破，大多表现为需要给攻击者支付一定数额的比特币才给你恢复，这种情况如果有开启binlog日志的话，可以尝试尝试下自行恢复。攻击者大多数的情况是直接Drop掉所有表，本身没有备份数据，只是创建了一个新表让你能看到勒索信息，要回数据的可能性不大。而且往黑暗一点想，你给了钱，那证明数据对你很重要，可能又会要求更多金额。所以在数据库的安全使用上，各位且行且珍惜。

以MySQL为例子，下面分享下个人关于数据库使用上的一些安全措施，主要说的是思路和方法，具体操作大部分网上可以直接找到。

防火墙

防火墙的必要性

• 这个大家估计都不陌生，有些开发者为了贪方便直接关了，没开等于裸奔，没特殊情况建议开启。
• 很多攻击者经常暴力破解SSH登录，可以给防火墙配一条规则，一分钟之内超过3次的SSH连接就给拒掉。

端口的开放

• 目前大多数服务的端口都是众所周知的，网上大多数攻击者也是扫描这些端口，所以类似MySQL不建议用3306，可以改为其它端口。
• 端口有需要再开放，在公司建议走审批流程，避免背锅。并另外针对Redis、MySQL这些数据库，要做好上层应用程序的校验，避免被注入，本人就有因程序没做好过滤，导致Redis被注入脚本，服务器被当作矿机的经历。

用户

运行服务的服务器用户

以CentOS系统为例子，所有服务都建议创建对应的新用户，例如MySQL，不要用root用户直接去运行，权限太大了。

服务的root用户

• MySQL安装完毕后，root默认口令为空，需要马上修改口令，也可以把root用户的名称改为其它的。
• 运维人员不要随意把root用户给到开发，没运维人员做统一权限管理的情况，开发人员平时尽量用对应的子账号。

密码设定

• 密码一定要足够长、足够复杂，要包含大写字母、小写字母、特殊符号、数字四种规则。不要嫌麻烦，顶多自己用记事本记录一下，好过被猜到出事故，另外建议如果是公司数据库的话，不要所有密码都一个样或者有规律可循。
• 在应用层面，账号密码可以考虑不要使用明文的方式配置在配置文件中，加密后配置在配置文件中。

用户登录IP（远程访问控制）

• 不要！不要！不要为了方便设置不限制登录IP的账号。
• 如果不是单机服务的话，每个账号限制对应的登录IP。

用户权限

• 对于每个系统单独创建对应的账号并分配权限，不要所有系统都用同一个账号或者root连接数据库。
• 像阿里云的RDS数据库还好些，有控制台可以直接配置账号权限，自建数据库的话可以找找有没有相关管理工具，没合适的话就老老实实一个一个配置。

错误次数

记得MySQL默认的账号错误次数是100，可以设置低一点，例如5次或者更少次数错误后直接锁定。

应用系统

常见攻击

常见的WEB应用漏洞跨站脚本攻击（XSS）、SQL注入攻击、跨站请求伪造（CSRF）、文件上传漏洞、目录遍历漏洞等。现在大多数框架都有预防和过滤，开发人员日常开发中做接收数据的过滤和校验即可避免。

错误信息

有些程序的开发框架，是可以开启详细错误信息的，出现数据库问题时很容易被猜到表结构或者连接信息，生产环境不要开启，有问题去排查程序的错误日志。

备份

主从备份

主从复制，是用来建立一个和主数据库完全一样的数据库环境，称为从数据库；主数据库一般是准实时的业务数据库。主从的主要应用场景为：

• 数据热备份，出故障时可切换到从库继续工作。
• 读写分离，降低主服务器的压力。
• 架构扩展，实际上跟读写分离差不多，业务量大单机顶不住可以分摊到多个服务器。

另外主从复制要关闭防火墙，所以大多数是直接关了外网访问，只允许内网连接。

定时备份

对于数据量大的表，可以考虑定时备份或者切割保留一部分数据，做冷热数据，避免影响查询性能。

日志

二进制日志（Binlog）

Binlog是记录所有修改数据的语句，用于主从复制和数据恢复，支持数据的一致性和灾难恢复。这个默认应该是没开启的，需要手动开启一下。

查询日志‌

记录所有数据库操作语句，包括增删改查，但默认关闭以避免影响性能，有需要的可以开启。

慢日志

慢日志是记录执行时间超过设定阈值的SQL语句，建议开启，主要用来做优化，比如一些数据表一开始数据量不大没问题，后面数据量一多会造成查询缓慢甚至导致接口响应超时。

写在最后

数据千万条，安全第一条。在大数据时代，数据的安全是重中之重。大家若有好的建议，欢迎交流。