Redis安全性

本文从以下几个方面提供了一个关于Redis安全主题的介绍：Redis提供的访问控制机制、代码安全问题以及外部恶意输入触发的攻击等类似的主题。

出于安全考虑的联系人，请在GitHub上打开issue，或者当你觉得保护通信安全非常重要时，可以使用本文末尾提供的GPG密钥。

Redis常规安全模式

Redis被设计成在被信任的环境中被信任的客户端才可以访问。这意味着将Redis实例直接暴露在互联网中或者一个不可信的客户端可以直接访问Redis的TCP端口或者UNIX套接字的环境中并不是一个好主意。

比如说，在一个常规的使用Redis作为数据库、缓存或是消息系统的web应用上下文中，网站前端客户端会查询Redis来生成页面，或者执行所请求的操作，或者是被web应用程序的用户触发。

在这种场景中，web应用程序需要处理处于Redis和不可信客户端(访问web应用程序的用户浏览器)之间的访问请求。

这是一个特殊的例子，但是总体来说，不可信的访问请求应该被实现了ACLs的中间层处理掉，通过校验用户输入来决定可以对Redis实例执行什么操作。

总的来说，Redis没有为了实现最大安全性而进行优化，而是为了最好的性能和易用性。

网络安全

Redis端口不应该对所有人都开放，而应该是只有网络中被信任的客户端才可以访问Redis端口，因此运行着Redis的服务器应该只能被用Redis实现应用程序的计算机直接访问。

一般情况下，一台直接暴露在互联网中的计算机，比如一台虚拟的Linux机器，防火墙应该阻止外部请求访问Redis端口。客户端仍然可以可以使用loopback接口来访问Redis。

通过在redis.conf文件中增加这样一行配置就可以把Redis绑定到单个接口上：

bind 127.0.0.1

由于Redis本身的特性，一旦不能阻止外部不可信的请求，将会产生巨大的安全隐患。比如说，一个简单的FLUSHALL命令就可以被外部攻击者用来删除Redis上的全部数据集。

保护模式

然而不幸的是很多用户都没有保护他们的Redis实例以防止外部网络攻击。很多实例都通过公开的IP被简单暴露在网络中。正式由于这个原因，从Redis3.2.0开始，如果Redis只是使用了默认的配置，不需要密码就可以访问它，那么它将进入一个被称为保护模式的特殊模式。在这个模式中，Redis只会响应loopback接口的查询请求，二队连接至其它地址的客户端返回一个错误，在这个错误信息里会解释需要如何正确地配置Redis。

我们如此迫切地期望这种受保护的模式来减少安全问题，这些问题是由于未被保护的Redis实例执行没有正确管理的请求引起的。然而系统管理员还是会忽视Redis给出的错误提示并且禁用保护模式或者是手动绑定所有接口。

认证特性

虽然Redis没有尝试实现访问控制机制，但是它提供了一个轻量级的认证方式，该认证可以通过编辑redis.conf文件来启用。

开启认证层后，Redis将会拒绝所有未认证客户端的请求。一个客户端可以通过发送AUTH命令和密码来通过认证。

密码是系统管理员在redis.conf文件中以明文形式配置的。密码应该足够的长以便可以防止暴力破解，这样做有两个原因：

• Redis响应请求的速度是很快的。一个外部客户端每秒钟可以测试很多不同的密码。
• Redis密码被存储在客户端内置的配置文件redis.conf中，因此系统管理员不需要记住密码，因此密码可以非常长。

认证层的目标是提供多一层的保护。如果外部攻击者攻破了防火墙或者其它保护Redis的系统，如果没有认证密码，外部客户端还是无法访问Redis实例。

和其它Redis命令一样，AUTH命令发送时也是没有加密的，因此它并不能防止有足够网络访问权限的攻击者进行窃听。

支持数据加密

Redis并不支持加密。

Data encryption support

Redis does not support encryption. In order to implement setups where trusted parties can access a Redis instance over the internet or other untrusted networks, an additional layer of protection should be implemented, such as an SSL proxy. We recommendspiped.