是时候开启数据库的加密传输了

在当下，几乎所有的站点都已经支 持了https， 那么在使用云数据库的时 候是否应该启用TLS加密传输，启用 TLS 的安全性如何，各家云厂商对 TLS 支持是怎样的？本文将做一个系统性的介绍。 0- 0

概述

• 构建新的数据库时默认应该开启加密传输(通常是TLS)支持， 这 会以极小的代价，大大加固云数据库的安全
• 实际场景中，客户端可以根据所处环境决定是否启用加密传输
• 如果客户端参数指定不使用加密传输，那么对性能没有任何影响
• 如果是跨云、跨公网、跨账号等场景，都应该强制使用加密连接
• 自签名CA的证书安全性虽然有瑕疵，但是用于加密传输已经足够了
• 服务端的证书校验通常是不需要的，安全威胁较大的场景才需要使用
• 客户端的证书校验通常也是不需要的， 极端 安全场景才需要使用
• 启用加密传输，性能损耗约为5%，RT约增加5%
• 事实上，各个数据库厂商，默认都已经推荐开启传输加密了，但是实践中，还是会因为对性能的担忧等原因，关闭了传输加密，这是没有必要的，因为客户端可以根据环境自己决定是否使用传输加密，如果是安全的内网环境，则可以禁用，如果可能是走不安全的网络，则可以启用

0 1 数据流动活跃，加密需求凸显 数据的跨环境传输已经越来越普遍，如果这个过程中没有加密，则可能导致数据泄露风险。传输加密就是大家通常所说的SSL加密或者TLS加密，与https加密原理类似。 0 2 云厂商对TLS加密传输的支持 这里以RDS MySQL为例，先来看看各自对TLS加密的支持现状。

说明：

• 除了少部分厂商，基本都已经支持传输加密
• 国外厂商都是默认开启，相对来说，对数据安全更加看重
• CA（证书颁发机构）证书基本都是自签名的
• 微软是一股清流，使用了第三方签名的证书。微软在中国区使用的是DigiCert Global Root CA签名的证书
• AWS的CA证书则是Region化的，不同的Region使用不同的CA根证书
• 各家CA的根证书基本上都可以在各自官网或者控制台下载：

0 3 自签名、第三方签名哪个更安全？ 简单来说，第三方签名更安全。 但，这是一个较为微弱的区别。 相比第三方签名，自签名多了一次CA证书获取的过程，用户需要从网站上获取该自签名CA的根证书，这个过程如果被污染，则可能会导致安全风险。
而由第三方签名的证书，则其根证书通常已经在OS或环境中安装好了，无需额外安装。
使用第三方签名通常在实现上比较复杂，因为涉及到服务端的证书有效性更新、与CA的交互等问题，通常会非常复杂。只有微软使用了该方法，确实是一股清流，非常不容易。 0 4

何时应该启用TLS加密？

在很多企业中，数据通常会分布在多个云厂商，也可能会有少部分的自建IDC环境。另外，还可能会使用一些SaaS化的数据服务商的产品。典型的数据流通图如下：

在这个环境下，我们看看哪些通常应该尽量使用加密通信：

• 数据通道X、W* 建议强制使用加密传输*
• 这两个通道联通的是两个不同的企业，也可能是不同的云厂商，数据可能会跨区域、云服务商传输，如果没有加密，数据是有较大的泄露风险。
• 数据通道Y 建议使用加密传输 。
• 该通道是在同一个云厂商，不同的区域的数据传输，数据通常是在云服务商的专线内流动，有一定的安全性保障，但是，因为数据链路较长，依旧有一定被获取的风险。
• 数据通道U， 如果使用加密的企业专线，则数据库不再需要加密传输 。
• 数据通道Z 建议强制使用加密传输 。
• 该通路与X、W通道类似，可能会跨区域、跨云厂商，如果没有加密，数据是有较大的泄露风险。
• 应用服务器与数据库之间，如果处于同一个内部网络环境，通常有较高的安全性保障，则无需加密。

0 5

使用TLS传输加密对于性能的影响

在使用sysbench的测试中，使用TLS传输加密对性能影响约为5%，不同的云厂商和不同的数据库版本会有不同，整体约为5%。后续会再将详细的性能测试数据展示出来。
另外，如果服务端开启TLS/SSL支持，但是客户端连接可以选择不使用加密连接，这时，并不会影响性能。 0 6

加密传输真的很安全吗？

简单来说，是的。
通常来说，加密传输的安全性是非常高。如果应用与数据库之前使用了加密传输，则不再需要额外的安全措施，例如ssh隧道、vpn网络或者堡垒机等（当然，出于其他原因考虑可能依旧会使用这些方式）。数据库提供的加密传输，其安全性通常与https、ssh等安全性相同。
不过需要注意的是，除了传输加密本身，因为数据库的端口可能暴露在一个可访问的环境中，依旧需要注意：

• 要有非常强的密码强度
• 使用较新的TLS版本
• 防止其他的类型的端口、网络攻击

另外，除了TLS加密之外，还建议使用如下方式进行加固：

• 访问白名单，限制可以访问应用端口的服务器数量，可以大大降低密码授权被攻击的风险
• 更进一步的，服务端的CA可以向客户端颁发一个X509证书，除了密码之外，额外增加证书认证，可以大大降低单纯的密码认证风险。

如果使用了白名单、密码，再加上证书认证，通道的安全风险就非常非常低了。 0 7

是否要对CA、Client端进行认证？

这里使用“加密传输”一词用来总得概况传输过程中的安全考虑。 实际上，这个安全包括两部分： 传输通道的加密、身份认证。 通道加密可以保障拿到传输数据包的第三方，依旧无法解密信息； 身份认证，则可以避免类似man-in-the-middle的攻击窃取数据。 如果，启用SSL/TLS，则已经可以保障传输通道数据的加密了。 如果进行CA验证，则可以避免类似man-in-the-middle的攻击。

以上的验证都是面向Server端的，也就是确保，我们连接的数据库，就是我们要连接的数据库，而不是第三方冒充。而另一个验证，则是数据库对用户的验证。通常的安全手段包括了白名单控制和用户名密码验证。另一种额外的认证方式则是，使用数字证书进行认证。在MySQL创建用户时，则可以通过REQUIRE子句要求用户必须提供证书认证，这时候，用户在登录的时候除了使用用户名密码之外，还需要提供证明自己身份的数字证书。 这提供了更高的 安全级别， 但是通常只有在涉及到国家安全、金融核心场景才需要。 0 8

最后

就这些吧，可以再回头看看前面的概述部分的几个建议：

• 数据库应该默认开启加密传输支持
• 由客户端根据实际的情况决定是否启用加密传输