通用安全模型
旨在由“受信任环境”中的“受信任客户端”访问。Redis不因该由未受信的客户端直接访问，要通过中间层进行ACL控制。
一般而言，Redis没有进行最大的安全性优化，而是为了获得最佳性能和简单性。
网络安全
通过防火墙过滤；
修改配置文件监听指定的IP地址；
认证功能 | 密码 | AUTH
虽然没有提供访问控制，但是Redis提供了认证功能。
启用认证之后，它会拒绝响应未认证的客户端。客户端使用AUTH命令进行认证。
认证密码以明文的方式保存在redis.conf配置文件中。密码应该足够长：
- 由于Redis的响应非常快，短密码及其容易暴力破解；
- 密码不需要被记住，它以明文存储子啊redis.conf中；
认证功能是冗余层。在防火墙或者其他系统保护时效时，密码认证能够提供而外一个保存。
密码认证过程中密码是明文发送的，这无法阻止网络窃听。
使用命令设置密码
redis: set a password for redis
连接Redis之后，执行如下命令设置密码：config set requirepass “password”
！！！注意，在服务重启后，密码会时效。
获取当前密码
连接Redis之后，可以使用如下命令查看密码：
当然，前提是你已经通过了认证。否则是服务查看密码的
持久化设置密码
然后，重启Redis服务。（注意配置文件前不能由空行）
禁用特殊命令
没有访问控制导致客户端可以执行任何命令，有些命令应该被重命名。
在redis.conf中，使用rename-command来覆盖危险指令：
- 重命名指令：rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52
- 或删除指令：rename-command CONFIG ""
诸如此类的命令还有FLUSHALL、DEBUG等等。
保护模式
从3.2.0以后，如果绑定到所有的地址，并且没有设置密码，Redis会进入“保护模式”。
在这种模式下，Redis只会相应回环接口的查询，响应其他地址的其他客户端连接错误，并解释发生了什么，如何修复这个问题。
通过这种方式来避免由错误管理导致的安全问题。但是，管理员已经可以关闭“保护模式”并监听所有的端口。
数据加密传输
它本身不支持数据加密传输，应该考录使用SSL代理，官方推荐「spiped」工具。
请求构造攻击
攻击者构造请求数据插入Redis中，从而触发Redis内部实现的数据结构的病态（最坏情况）算法复杂度。
例如，攻击者可以通过Web表单提供一组字符串，这些字符串已知为同一个桶散列到哈希表中，以便将O（1）预期时间（平均时间）转换为O（N ）最糟糕的情况是，消耗的CPU比预期的多，最终导致拒绝服务。
为防止此特定攻击，Redis对散列函数使用每执行伪随机种子。
Redis使用qsort算法实现SORT命令。 目前，该算法不是随机的，因此可以通过仔细选择正确的输入集来触发二次最坏情况行为。
字符串转义和NoSQL注入
Redis协议没有字符串转义的概念，因此在正常情况下使用普通客户端库无法进行注入。 该协议使用前缀长度字符串，完全是二进制安全的。
由EVAL和EVALSHA命令执行的Lua脚本遵循相同的规则，因此这些命令也是安全的。
虽然这是一个非常奇怪的用例，但应用程序应该避免使用从不受信任的来源中获取的字符串来组成Lua脚本的主体。
代码安全
在经典的Redis设置中，客户端可以执行所有的命令，但这并不会导致宿主机器被控制。
在内部，Redis使用所有众所周知的实践来编写安全代码，防止缓冲区溢出，格式化错误和其他内存损坏问题。 但是，使用CONFIG命令控制服务器配置的能力使客户端能够更改程序的工作目录和转储文件的名称。 这允许客户端在随机路径上编写RDB Redis文件，这是一个安全问题，可能很容易导致破坏系统和/或运行Redis的用户来运行不受信任的代码。
建议以非ROOT用户运行，目前也正在加入CONFIG SET/GET dir的扩展功能，防止客户端强制服务端在任意位置写入文件。
参考文献
Redis Security
A few things about Redis security