共计 5743 个字符，预计需要花费 15 分钟才能阅读完成。
线上业务为了保证数据安全，一般只允许本地或者内网访问 MySQL。但一些特殊情况下，需要通过外网访问 MySQL。此时为了保证权限最小化开放，首先要做两方面措施：
一方面需要配置防火墙白名单
iptables -A INPUT -s 1.2.3.4 -p tcp -m tcp –dport 3306 -j ACCEPT另一方面创建 MySQL 用户时限制访问 IP
mysql> CREATE USER‘testuser’@’1.2.3.4’IDENTIFIED BY‘testpass’;那么，做到这一步就可以高枕无忧了吗？如果是的话，文章到此就可以结束了。但是很遗憾，实际上仍然存在安全隐患。MySQL 的访问默认是明文的，与明文的 HTTP 的容易受到监听、劫持类似，暴露在外网的 MySQL 通信也有可能受到监听、中间人攻击等。下面以一个具体例子进行说明。
实现监听的方案有多种，我们采用了交换机端口镜像的方式进行旁路监听。
准备监听的机器为 xxx.xxx.xxx.83，发起攻击的机器为 xxx.xxx.xxx.109。
实施 MySQL 主从通信的监听时，无论是监听主库还是从库效果都类似，这里测试监听主库的情况。
如果不知道这两台机器对应交换机哪个端口，可以先登录交换机，ping 然后通过 arp 缓存查看。
ping 之后就能通过 arp 缓存确定端口
最后，确定 xxx.xxx.xxx.83 即镜像源端口为 g0/15，xxx.xxx.xxx.109 即镜像目标端口为 g0/1。
登录交换机，开始没有配置镜像
<H3C>dis mir
The monitor port has not been configured! <H3C>sys
Password: ************
Enter system view, return to user view with Ctrl+Z.分别配置镜像目标和镜像源端口
[H3C]monitor-port g0/1
Succeed! the monitor port has been specified to be Trunk port and the pvid
changed.
[H3C]mirroring-port g0/15
[H3C]
[H3C]dis mir
Monitor-port:
GigabitEthernet0/1
Mirroring-port:
GigabitEthernet0/15
[H3C]q
<H3C>save
This will save the configuration in the EEPROM memory
Are you sure?[Y/N]y
Now saving current configuration to EEPROM memory
Please wait for a while...
Current configuration saved to EEPROM memory successfully在主动监听的机器 xxx.xxx.xxx.109 执行
tcpdump host xxx.xxx.xxx.83 -i eth0 -w hello.dump
xxx.xxx.xxx.83 配置了 MySQL 主库，另外的一台外网机器 xxx.xxx.xxx.104 配置了 MySQL 从库。并且该主从并未配置 SSL 加密。测试中利用 xxx.xxx.xxx.109 成功监听到 MySQL 主从的通信。
下图为监听到的 MySQL 帐号登录，可以得到用户名和加密后的密码：
对于不复杂的 MySQL 密码，可以很容易通过 cmd5 等网站解密出明文：
下图为监听到的主从数据：
可以看到，在 MySQL 主从明文通信的情况下，可以实现有效的窃听。
这里采用的交换机端口镜像需要获得交换机权限，有一定的实施难度。但在外网通信中，实际的网络环境非常复杂且不受我们控制，明文通信仍然有潜在的安全风险。
那么如何在服务器之间的外网通信中确保 MySQL 的安全访问呢？这里介绍几种常用方案。
加密隧道可以将客户端的网络数据进行加密，然后安全地传输到服务端后进行解密还原。以 stunnel 为例：
首先在客户端监听 3306 端口，并建立加密通信，连接到远程的 1.2.4.5:8000
/usr/local/stunnel/etc/stunnelclient.confsslVersion = TLSv1
CAfile = /usr/local/stunnel/etc/ca-cert.pem
cert = /usr/local/stunnel/etc/clientcert.pem
key = /usr/local/stunnel/etc/clientkey.pem
[mysql]
accept = 127.0.0.1:3306
connect =1.2.4.5:8000服务端监听 8000 端口，并将数据解密后转发到本机的 3306 端口
/usr/local/stunnel/etc/stunnelserver.confsslVersion = TLSv1
CAfile = /usr/local/stunnel/etc/ca-cert.pem
cert = /usr/local/stunnel/etc/servercert.pem
key = /usr/local/stunnel/etc/serverkey.pem
[mysql]
accept=8000
connect=127.0.0.1:3306
这样，客户端访问本地 3306 端口实际会访问到远程 1.2.4.5 机器的 3306 端口，实现了通过加密隧道访问远程的 MySQL。
优点：无需单独创建外网的 MySQL 帐号，对本地访问透明。
缺点：只能实现从客户端到服务端的加密访问，需要额外维护加密隧道服务。
VPN 可以将外网通信转化为虚拟的内网通信，直接解决外网访问的安全问题。以 OPENVPN 为例：
在其中一边的服务器搭建服务端，配置内网网段
/etc/openvpn/server.confport 1194
proto tcp-server
dev tap
#证书相关
ca /etc/openvpn/ca-cert.pem
cert /etc/openvpn/server.pem
key /etc/openvpn/server.key
dh /etc/openvpn/dh.pem
#指定 Server 端使用的地址
ifconfig 192.168.10.1 255.255.255.0
#指定客户端的 IP
client-config-dir /etc/openvpn/ccd在另一边的服务器搭建客户端，发起 VPN 链接
/etc/openvpn/client.conf
client
dev tap
proto tcp-client
remote 1.2.3.4 1194
#证书相关
ca /etc/openvpn/ca-cert.pem
cert /etc/openvpn/client1-cert.pem
key /etc/openvpn/client1-key.pem这样，两边的服务器就建立起虚拟的内网，可以访问相互的 MySQL 或者其他服务。
优点：两边都可以相互访问，且不限于访问某个端口，特别适合异地机房间的内网互通。
缺点：需要额外维护 VPN 服务。
除了建立加密隧道、加密虚拟网络，还可以直接使用 SSL 进行 MySQL 的访问加密。
2.3.1 SSL 证书的生成
首先检查 MySQL 是否支持 SSL。
mysql> SHOW VARIABLES LIKE‘have_ssl’;
+—————+———-+ | Variable_name | Value
| +—————+———-+ | have_ssl | DISABLED |
+—————+———-+ 1 row in set (0.00 sec)如果输出如上，说明 MySQL 支持 SSL 但未启用。
SSL 证书分多种类型，实际中要根据不同用途来使用服务端或客户端的证书。
[mysqld]
# 服务端类型 SSL 证书，用于服务端，或者主从关系中的主库
ssl-ca=/home/mysql/certs/ca-cert.pem ssl-cert=/home/mysql/certs/server-cert.pem
ssl-key=/home/mysql/certs/server-key.pem
[client]
# 客户端类型 SSL 证书，用于客户端（如命令行工具），或者主从关系中的从库
ssl-ca=/home/mysql/certs/ca-cert.pem
ssl-cert=/home/mysql/certs/client-cert.pem
ssl-key=/home/mysql/certs/client-key.pem
此外，为了方便统一管理，在同一台机器可以使用同时支持服务端和客户端类型的单一 SSL 证书。只需要生成 SSL 证书时指定两种类型的用法或者直接不指定任一种用法。
配置完毕后，检查下 SSL 是否已启用
mysql> SHOW VARIABLES LIKE‘%ssl%’;
+—————+———————–+
| Variable_name | Value |
+—————+———————–+
| have_openssl | YES |
| have_ssl | YES |
| ssl_ca | /home/mysql/certs/ca-cert.pem |
| ssl_capath | |
| ssl_cert | /home/mysql/certs/mysql-cert.pem |
| ssl_cipher | |
| ssl_key | /home/mysql/certs/mysql-key.pem |
+—————+———————–+
5 rows in set (0.00 sec)如果输出如上，说明 SSL 已正常启用
2.3.2 require SSL 与 require X509
为了确保外网访问的 MySQL 用户使用了 SSL 加密，在生成用户时可以强制要求 REQUIRE SSL 或 REQUIRE X509：
mysql> CREATE USER‘testuser’@’1.2.3.4’IDENTIFIED BY‘testpass’REQUIRE SSL;
mysql> CREATE USER‘testuser’@’1.2.3.4’IDENTIFIED BY‘testpass’REQUIRE X509;两者的区别在于，REQUIRE SSL 只要求客户端使用指定 ca 证书对服务端证书进行验证，而 REQUIRE X509 还要求服务端对客户端证书进行验证。为了避免中间人攻击，确保更安全的通信，一般建议使用 REQUIRE X509。
2.3.3 OpenSSL 与 yaSSL
MySQL 可以使用自带的 yaSSL 库进行加密通信，也可以使用 OpenSSL 进行加密通信。具体使用哪种，需要在编译时指定 WITH_SSL:STRING 的参数：
bundled (use yassl), yes (prefer os library if present, otherwise use bundled), system
(use os library), </path/to/custom/installation>为了更好的安全性，可以使用系统自带的 OpenSSL，并及时做好 yum/apt 更新。
如果考虑不同版本的兼容性，那么建议使用自带的 yaSSL。
比如 OpenSSL 曾针对 CVE-2015-4000 的漏洞将 DH key 的最小值提高到 768 bits，而一些旧版本 MySQL 的 DH key 使用了 512 bits。因为 MySQL 的默认 SSL 加密算法是 DHE-RSA-AES256-SHA，如果使用了 OpenSSL 的 MySQL，在不同版本间的访问可能会出现 ERROR 2026 的错误提示。
2.3.4 监听基于 SSL 的主从通信
配置了 SSL 加密之后，我们再次尝试抓取 MySQL 主从通信。
发现无法获取到 MySQL 主从的登录帐号：
此外截取到的 MySQL 主从数据也是乱码：
可以看到，在 MySQL 主从经过 SSL 加密的情况下，无法实现有效窃听。
一般我们都需要 SSH 方式从本地访问远程服务器，这时可以建立 SSH 隧道来访问远程服务器的特定端口。
如使用 SecureCRT 的端口转发功能（Putty 也类似），将本地 3306 端口转发到服务器的 3306 端口：
如果习惯使用 navicat 这类工具，可以使用自带的 SSH 隧道功能（注意旧版可能要将私钥转换成 ppk 格式）：
如果习惯使用 phpmyadmin 的 web 方式访问 MySQL，那么只需要将访问方式统一为 HTTPS：
server
{
listen 80;
server_name phpmyadmin.example.com;
#使用 HSTS 强制把 HTTP 跳转到 HTTPS
add_header Strict-Transport-Security“max-age=31536000“;
……
}
server
{
listen 443 ssl http2;
server_name phpmyadmin.example.com;
#配置服务端 SSL 证书
ssl on;
ssl_certificate /etc/letsencrypt/live/phpmyadmin.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/ phpmyadmin.example.com/privkey.pem;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
……
}MySQL 的数据安全是一个非常大的课题，其中外网间的安全通信往往容易被忽略。而当前随着 HTTPS /SMTPS/POP3S/IMAPS 的逐步流行，各种基于 TCP、UDP 的加密通信方案也会越来越多地应用到线上业务中。本文针对服务器间 / 本地到服务器的一些访问 MySQL 的场景介绍了几种加密通信方案，希望能给到大家一些思路，并结合自己实际需要来使用 MySQL 的加密访问。
