Redis是一个高性能的key-value数据库，它追求的是高效和简洁，在安全设计方面相对比较薄弱，Redis的安全设计主要从三个方面，具体如下：
一、运行在可信环境
Redis的安全设计是在"Redis运行在可信环境"这个前提下做出的，在生产环境运行时不能允许外界直接连接到Redis服务器上，即Redis服务必须跟APP在同一个区域，而不是跟WEB在同一个区域。
Redis的默认配置会接受来自任何地址发送来的请求，即在任何一个服务器上启动Redis服务，可以访问这个主机的任何机器都可以通过IP和PORT来访问。若要更改这一设置，在配置文件中修改bind参数，如只允许本机应用连接Redis，可以将bind参数改成： bind 127.0.0.1
二、Redis设置密码
Redis的密码是在配置文件（redis.conf）中的参数requirepass来配置，也可以在客户端通过config set requirepass **** 来修改；若为redis设置了密码，则客户端每次连接到Redis时都需要发送密码，否则Redis会拒绝执行客户端发来的命令；由于Redis的性能极高，并且输入错误密码后Redis并不会进行主动延迟（考虑到Redis的单线程模型），所以攻击者可以通过穷举法破解Redis的密码（1秒内能够尝试十几万个密码），因此在设置时一定要选择复杂的密码。
三、命令重命名
在配置文件（redis.conf）中还提供了一些高危命令（flushall ,flushdb,shutdown,config 等）的重命名的设置，来避免误操作。
随着Redis的推广使用，目前已经有近2000个实例，涉及到团队比较多，运营，DBA，开发等，这么多人共同使用一个密码，并且密码的设置和高危命令的屏蔽都是通过修改配置文件（redis.conf）的，而配置文件也是没有加密的,存在很大的安全隐患，故运维好这些Redis实例就需要做到不同的团队在访问它时，要有不同用户及不同权限，就像访问关系型数据库一样。参照关系型数据库的用户和角色的权限管理，可以使用PostgreSQL的外部表访问Redis，通过PostgreSQL权限管理方式对Redis进行后台管理。
PostgreSQL是通过角色来管理数据库访问权限的，我们可以将一个角色看成是一个数据库用户，或者一组数据库用户。角色可以拥有数据库对象，如表、索引，也可以把这些对象上的权限赋予其它角色，以控制哪些用户对哪些对象拥有哪些权限。
了解了PostgreSQL的权限管理方式，首先确认后台管理有哪些用户需要访问Redis和其需要的权限，具体如下表：
用户 权限 | 读 | 写 | 管理 |
开发 | Y | N | N |
运营 | Y | Y | N |
DBA | Y | Y | Y |
对于的用户和需要权限映射到PostgreSQL，具体如下表：
对象 用户 | 开发 | 运营 | DBA |
Table | select | select/dml | select/dml/create/drop/alter/grant |
User/role | -- | -- | create/drop/grant/alter |
Database | -- | -- | create/drop |
下面以Redis实例RTOC【127.0.0.1：6379】为例，假设Redis后台管理的PostgreSQL实例已经搭建完成：
1. DBA需要在搭建好的PostgreSQL实例做下面操作：
1）使用超级用户创建dba用户dbatest
2）创建database：redis
3）使用dbatest用户登录redis 【database】创建外server并授权
4）创建外部表（r_6379，r_6379_hash, r_6379_list, r_6379_set, r_6379_zset）
5）创建开发用户devtest和运营用户montest，并授权相应的权限
2. 开发使用用户devtest访问PostgreSQL的redis database下面的table就可以查询到Redis【172.0.0.1:6379】对应的数据了
1) 使用devuser用户登陆PG查询redis的数据【可以查询】：
2) 使用devuser用户登陆PG修改redis的数据【不允许修改】
3. 运营使用montest用户访问PostgreSQL的redis database对Redis【172.0.0.1:6379】进行增删改查了
4. DBA用户访问PG
1）除了增删改查之外还可以对外部做drop和create操作
2）truncate 操作还是不可以，故对于一些高危的命令，比如shutdown，config及flushall等操作还是需要在redis server 后台服务器上面操作
总结：
这样既可以做到开发使用开发自己的用户devtest用户访问Redis，运营使用montest用户访问Redis，避免了多个用户共用一个密码的可能出现的误操作，也可以使用我们熟悉的SQL语法对Redis的数据进行访问。
访问流程具体参照下图：
