Redis消息传输安全那点事儿，聊聊怎么做到更靠谱更安心

说到Redis的消息传输安全，咱们今天就来聊点实在的，怎么让它更靠谱、更让人安心，Redis这东西，因为速度快、用起来简单，在很多系统里都扮演着重要的角色，比如当缓存、当消息队列，或者存一些会话信息，但正因为用得多，它的安全问题就更不能马虎，万一消息被偷看、被篡改,那麻烦可就大了。

第一道防线：别让“外人”连上你的Redis（来源：Redis官方文档安全章节）

这听起来像是句大白话，但却是最最重要、也最容易出问题的一点，很多为了图省事，安装完Redis后直接用默认配置就上线了，这可是大忌，Redis的默认设置是为了方便开发调试，它默认是没有密码的，而且默认只允许本机（127.0.0.1）连接，如果你需要让其他服务器也能访问，千万别简单地把它绑定到0.0.0.0（意思是允许所有IP连接）就完事了。

• 设置一个强密码：在Redis的配置文件redis.conf里，找到requirepass这个配置项，给它设上一个又长又复杂的密码，这就好比给你家的Redis大门加了一把结实的锁，设置了密码之后，任何客户端连接时都必须先通过AUTH命令输入正确的密码才能执行操作。
• 限制访问的IP地址：通过配置bind指令，只允许你信任的、特定的服务器IP地址来连接Redis实例，如果你的应用服务器IP是192.168.1.10和192.168.1.11，那就只绑定这两个IP,这样其他不相关的机器就连不上了。
• 改掉默认端口：Redis默认使用6379端口，这几乎是尽人皆知的，就像小偷总喜欢先试试你家门是不是没锁一样，网络上的自动攻击脚本也会首先扫描这个端口，把它改成一个不常用的端口号（比如6380）,能挡住一大批漫无目的的自动化攻击。

第二道防线：给传输中的消息“穿盔甲”——使用SSL/TLS加密（来源：网络通信安全通用实践及Redis 6.0对TLS的支持）

光有密码锁门还不够，万一有人在你家门外（网络线路上）装了个“窃听器”呢？数据在网络上传送的时候，如果都是明文的，那黑客很容易就能截获这些数据包，看到里面具体的内容,甚至还能篡改。

这时候就需要SSL/TLS加密了（咱们平时上网用的HTTPS，就是HTTP over SSL/TLS），这相当于在客户端和Redis服务器之间建立了一条加密的“隧道”，所有数据在进入隧道前被加密，出来后再解密，这样一来，即使数据被截获，黑客看到的也是一堆乱码,无法理解。

从Redis 6.0版本开始，官方正式支持了TLS加密传输，你需要为服务器配置好TLS证书，然后客户端也使用TLS方式来连接，虽然这会让连接建立的过程稍微复杂一点点，性能有极其微小的损耗，但对于传输敏感信息（比如含有用户个人资料、身份令牌的消息）这点代价是完全值得的,它能给你带来极大的安心。

第三道防线：管好自家“钥匙”——访问权限控制（来源：Redis访问控制列表ACL功能）

就算进了大门，也不能让来客在家里为所欲为吧？Redis从4.0版本引入了ACL（访问控制列表），到了6.0更是大大增强,这个功能可以让你进行更精细化的权限管理。

你可以：

• 创建一个只能读取特定几个key的账号,给监控系统用。
• 创建一个只能执行发布（publish）命令，不能执行订阅（subscribe）或删除（del）命令的账号,给某个特定的消息生产者用。
• 创建一个只能操作以user_session:开头的所有key的账号,给会话管理服务用。

通过ACL，你可以遵循“最小权限原则”，即每个应用或服务只拥有它完成本职工作所必需的最低权限，这样，即使某个客户端的密码不小心泄露了，黑客能造成的破坏也被限制在了很小的范围内,不会导致整个Redis数据库沦陷。

怎么更靠谱更安心？

1. 基础保障不能省：坚决不用默认配置，设置强密码、绑定可信IP、修改默认端口,这是成本的底线。
2. 敏感数据要加密：如果消息内容敏感，或者网络环境不可控（比如跨机房、跨公有云传输），务必启用Redis的TLS加密功能，给数据穿上“盔甲”。
3. 权限管理要精细：活用ACL功能，给不同的使用者分配合适的“钥匙”，避免一把钥匙开所有门,降低局部风险扩散成全局灾难的可能性。
4. 保持更新：及时关注Redis的版本更新，新版本通常会修复已知的安全漏洞，保持软件的最新状态,也是安全的重要一环。

Redis的消息传输安全不是一个单点问题，而是一个从网络暴露、身份认证、传输加密到内部权限管理的立体防御体系，多花一点心思把这些措施做到位，就能让你的Redis用得更踏实、更安心。