MySQL服务器访问控制那些事儿，权限设置和安全隐患的乱七八糟分析

主要基于MySQL官方文档和一些常见的运维实践经验,高性能MySQL》这本书里也提过一些，还有网上那些DBA们吵架吵出来的经验帖）

MySQL服务器访问控制那些事儿,权限设置和安全隐患的乱七八糟分析

说到MySQL的访问控制,说白了就是管两件事：第一，谁可以进来（身份）；第二，进来后能干什么（权限），这听起来简单，但里面乱七八糟的坑可多了。

是谁能进来的问题,MySQL认人不光是看用户名，还得看这个用户是从哪里连过来的，同一个用户名，比如app_user，从本地连（localhost）和从168.1.100这个IP地址连，在MySQL眼里完全是两个不同的账号，可以有不同的密码和完全不一样的权限，这个设计一开始很多人会搞懵，为啥我本地用密码登上了，换台机器用同样用户名密码就说不对了？很可能就是因为权限记录里定义的来源主机不一样，创建用户的时候，主机名部分千万不能马虎，用虽然省事，表示可以从任何主机连接，但这也意味着攻击面一下子扩大到了整个网络，安全隐患巨大。

然后就是进来以后能干啥,这才是重头戏，MySQL的权限细得吓人，小到对某个表的查询（SELECT）、插入（INSERT），大到能执行关机命令（SHUTDOWN）、管理复制（REPLICATION SLAVE）的权限，有好几十种，权限是可以给到不同层次的：全局级别（对整个MySQL服务器有效）、数据库级别（对某个数据库有效）、表级别、甚至列级别（限制只能访问某几个列），这种精细度本来是好事，能实现“最小权限原则”，即只给每个账号分派它完成工作所必需的最少权限，但麻烦也在这儿，权限给得太细，管理起来就特别乱，容易出错。

这里就不得不提几个常见的、乱七八糟的权限设置错误，这些往往是安全隐患的源头：

第一个大坑就是乱用GRANT OPTION权限，这个权限太厉害了，它允许一个用户把自己拥有的权限再转授给其他用户，这相当于，你给了某个应用账号一些普通权限，不小心顺手又把GRANT OPTION给了它，结果这个应用万一被黑了，攻击者就能利用这个账号创建一个拥有超级权限的新用户，整个数据库就沦陷了，除非是专门做权限管理的管理员账号，否则绝对不要轻易授予GRANT OPTION。

第二个坑是关于那个ANY权限的，比如CREATE USER、SHUTDOWN这些全局权限，这些权限一旦授予，就不是针对某个数据库了，而是对整个MySQL实例生效，你要是把一个普通应用账号不小心加到了mysql.user表里某个拥有全局权限的管理员账户，那这个应用账号瞬间就“升维”了，能干很多破坏性的事情，很多运维事故就是这么来的，测试账号权限没回收干净，留着全局权限在生产环境，等于埋了颗雷。

第三个乱七八糟的地方是密码管理,老版本的MySQL有时候会有匿名用户（用户名为空的账户），或者一些默认安装的测试数据库和账户，这些账户密码可能很简单甚至是空密码，攻击者首先扫描的就是这些薄弱点，安装完MySQL，第一件事就应该是用mysql_secure_installation脚本，它会帮你处理掉匿名用户、测试数据库，并强化root账户的安全设置。

第四个隐患藏在代码和配置里,很多人为了方便，直接把数据库的连接信息，包括用户名和密码，用明文写在应用的配置文件里，如果这个配置文件又被放到了网站的根目录下，能被直接下载，那数据库基本就等于裸奔了，再就是，有些应用使用的数据库账号权限过高，一个简单的博客程序，可能根本用不着DELETE或DROP的权限，但你却给了它一个数据库的所有权限，一旦程序有SQL注入漏洞，攻击者就能为所欲为。

权限这东西不是设置完就一劳永逸的,人员离职、项目下线、服务变更，对应的账号权限都应该及时回收或删除，但现实中，很多MySQL服务器里都堆满了“僵尸账号”，没人知道是干嘛用的，也不敢删，这些就成了潜在的后门，定期审计权限是非常有必要的，看看每个账号到底都有哪些权限，是不是还真的需要。

MySQL的访问控制是个细致活,不能怕麻烦，核心思想就是“最小权限”，像挤牙膏一样给权限，而不是一开始就给个超级权限然后指望不出事，每多给一个权限，都要想想是不是真的有必要，会不会带来意想不到的风险，这些乱七八糟的细节堆在一起，就决定了你的数据库是铜墙铁壁还是纸糊的窗户。