等保三级Redis安全测评与整改指南

等保三级复测那天，测评工程师没有先看核心业务系统，而是蹲在一台Redis服务器前翻了大半个小时。回来后拿着一页检查记录问我：端口还是默认的6379？配置文件里没有看到requirepass？日志路径为什么是空的？FLUSHALL怎么还原样挂着？当时现场的负责人脸色就不好看了，一个Redis能牵出四五个整改项，这在等保三级测评里其实非常常见。

这篇文章就是要把等保三级要求下Redis安全测评这件事彻底说清楚：测评机构到底看哪些配置、用什么方法查、每一项为什么被查、整改时应该怎么改。我会把每一次踩坑和客户现场的真实处理方式都写出来，适合正在准备等保三级测评的运维、安全、开发同学参考。不需要你有等保理论基础，只要照着配置和思路走，Redis这块基本不会成为失分重灾区。

1. 测评机构盯Redis时到底在查什么：先看清楚规则再动手

1.1 Redis归属的测评域与对应检查项

知道测评老师为什么问那些问题，比直接抄配置重要得多。等保三级不是按“Redis专项清单”来测的，而是依据GB/T 22239-2019《信息安全技术 网络安全等级保护基本要求》里的通用控制项，把要求落到Redis这个具体组件上。

Redis在一套系统里通常属于“安全计算环境”的范畴，同时还会牵涉到“安全通信网络”里的传输加密要求。落到具体的测评项，主要包括下面这几类：

• 身份鉴别：Redis是否有访问密码？密码强度够不够？是否空口令？是否有账号隔离？
• 访问控制：Redis监听的地址是什么？是否暴露到公网或非受信网段？是否使用默认端口？配置文件的权限是否被改了？
• 安全审计：Redis日志是否落盘？日志内容能否覆盖用户、时间、操作行为？留存时间是否≥6个月？
• 入侵防范：高危命令（FLUSHALL、CONFIG、KEYS等）是否被禁用？Redis进程以什么用户运行？版本是否满足安全要求？
• 数据备份恢复：是否开启RDB/AOF持久化？备份文件是否做了权限控制？
• 资源控制：是否设置maxmemory、maxclients等连接和内存限制？

这些不是Redis特有要求，而是等保三级对关键组件的通用要求。测评机构不会管你用的Redis还是Memcached，只关心这个组件能不能满足这些控制项。

1.2 测评现场最常用的四种检查手段

我参加过多次等保测评和复测，大概率会遇到下面这四种做法，提前有个心理准备：

1. 访谈管理员：问账号几个人在用，密码怎么保存，多久换一次。这个时候你拿不出成文的口令策略，或者回答“大家共用redis-cli直接连”，身份鉴别项就会被记问题。
2. 直接读配置文件：这是核心动作。测评老师会打开redis.conf，重点看bind、protected-mode、port、requirepass、rename-command、logfile、maxmemory这几个参数。Redis的配置集中，反倒好查。
3. 用redis-cli做无害验证：比如直接执行redis-cli -h <ip> -p 6379 ping，看看能不能绕过AUTH连接；或者尝试CONFIG GET requirepass，看能不能直接读到配置。这一步和漏洞验证场景很像，一旦能连上，基本就是高危项。
4. 查运行证据：看进程运行用户（ps aux）、systemd unit文件、日志轮转配置、目录权限。一个Redis以root身份跑，在测评老师眼里就是不正常的。

理解了这个逻辑，你就明白后面所有整改动作都是在给测评老师提供“证据”。现场不需要背话术，配置拿出来、日志打开来，比解释一百句都管用。

2. 未授权访问整改：bind、protected-mode、端口，一个都不能裸奔

2.1 为什么未授权访问是等保测评里的“必考题”

Redis未授权访问在业内已经不算新闻了，很多安全事故就是从这里撕开口子的。默认配置下Redis只监听127.0.0.1，看起来安全，但问题出在很多部署过程中，操作人员会把bind改成0.0.0.0，让所有客户端都能连上，结果Redis就像在公网上裸奔。

等保测评里这也是必查项，因为检查成本太低：一条redis-cli -h IP -p 6379 ping就能判断。如果返回PONG，或者执行CONFIG GET requirepass能拿到内容，那就是未授权访问，测评结论直接提级。这个风险点基本属于“一票否决”级别的。

2.2 三件套整改：bind、protected-mode、port

对未授权访问的整改不是一个参数能搞定的，需要三个配合：

bind参数：只允许Redis监听内网地址或回环地址，绝对不要出现0.0.0.0。比如Redis所在服务器内网IP是192.168.10.10，配置：

code复制bind 127.0.0.1 192.168.10.10

如果你的应用和Redis部署在同一台机器，bind 127.0.0.1就够了。如果应用服务器在另一个网段，就要把Redis所在服务器的内网IP加进去，注意不是加应用服务器的IP，而是本机对应的网卡IP。

protected-mode参数：明确设置为yes。

port参数：默认6379是特征端口，扫描器一认一个准。改成16379或者10179这类冷门端口，至少能降低被批量扫描命中的概率。但端口本身不是安全措施，它只是减少暴露面，真正挡住外部访问靠的是防火墙规则。

这里放一个完整的安全基线配置示例：

code复制bind 127.0.0.1 192.168.10.10
protected-mode yes
port 16379
requirepass "一套足够复杂的强口令"

2.3 常见整改误区：只改bind不等于万事大吉

我在客户现场见过不少“自我感觉良好”的整改方式，最常见的就是只把bind从0.0.0.0改成192.168.10.10，密码不设、端口不改。这就相当于把家门从敞开改成虚掩，等保测评老师一眼就能看出问题。

还有一个很隐蔽的坑：用Docker部署Redis时，容器里bind 127.0.0.1，但宿主机启动命令写的是-p 6379:6379，这在宿主机上就等于监听所有网卡，外部网络是能访问到的。正确写法是：

code复制docker run -d --name redis \
  -v /etc/redis/redis.conf:/usr/local/etc/redis/redis.conf \
  -v /data/redis:/data \
  -p 127.0.0.1:16379:6379 \
  redis:7.4 redis-server /usr/local/etc/redis/redis.conf

-p 127.0.0.1:16379:6379只监听本地网卡，虽然牺牲了一点外网访问的便利性，但这是安全的做法。如果你确实需要让其他服务器访问，就写明具体IP：-p 192.168.10.10:16379:6379，不要写0.0.0.0或者省略IP。

另外，改完bind和port之后，主从集群、客户端的连接配置都要同步更新。这个提醒很重要，因为很多线上事故不是整改改错的，而是改完配置忘了改客户端的Redis地址端口，应用直接连不上，最后只能紧急回滚。

3. 身份鉴别整改：从requirepass到ACL，把“人”和“权限”分开管

3.1 强口令与AUTH：第一步就这么做

设置requirepass是最基本的身份鉴别措施。等保三级对登录口令一般是长度不少于8位，并且由大小写字母、数字、特殊字符中至少三种组成。考虑到Redis口令可以从配置文件中读取，建议直接用16位以上的随机字符，别用什么password123这种。

用openssl生成一个随机口令：

bash复制openssl rand -base64 24

把生成结果写进redis.conf：

code复制requirepass "hQ8#bN2$sLxR4$vKm9@PzFc"

这里有个重要细节：密码一定要写在配置文件里，不要用启动命令行参数传。因为ps命令可以直接看到进程的命令行参数，明文口令等于暴露在所有人面前。

设置密码后，所有客户端连接时必须执行AUTH。验证方法：

bash复制redis-cli -h 127.0.0.1 -p 16379 -a "密码" ping

如果输出PONG，说明身份鉴别配置生效。注意-a参数在命令行里也会留下明文历史，建议加--no-auth-warning参数或者直接用-x从标准输入读密码：

bash复制redis-cli -h 127.0.0.1 -p 16379 --no-auth-warning
> AUTH 密码

3.2 ACL账号隔离：Redis 6.0之后必须用起来

仅仅有一个requirepass，其实还有个等保测评的痛点：所有人都用同一个密码，出问题无法区分是谁的操作。等保三级对身份标识唯一性是有要求的，所以Redis 6.0引入的ACL功能一定要用起来。

ACL的作用就是为不同角色划分不同权限。比如运维账号能执行大部分命令但禁止高危操作，应用账号只能访问指定前缀的键。配置示例：

code复制user default off
user redis_ops on >O1x@2024#Redis ~* +@all -flushall -flushdb -config -shutdown -debug
user app_user on >App#2024!Key ~cache:app:* +get +set +expire +ttl +del

• user default off：禁用默认用户，没有指定用户名的连接直接失败。
• redis_ops：运维专用账号，有全部命令权限，但排除了若干高危命令。
• app_user：应用账号，只能操作cache:app:前缀的键，能执行的命令就那么几个。

这套配置的意义在于：第一，最小权限原则落地了；第二，日志里能够区分是哪个账号做了操作，满足审计溯源要求。很多老工程师习惯只改requirepass，我觉得既然测评要求提出来了，ACL能上就早点上。

3.3 配置文件权限：口令本身也要保护好

口令放在redis.conf里，那配置文件自身的权限就显得非常重要。如果配置文件的权限是644，任何普通用户都能读，口令就等于明文泄露。正确做法：

bash复制chown redis:redis /etc/redis/redis.conf
chmod 600 /etc/redis/redis.conf

同理，Redis的数据目录、日志目录也要控制权限：

bash复制chown -R redis:redis /var/lib/redis
chown -R redis:redis /var/log/redis
chmod 700 /var/lib/redis
chmod 700 /var/log/redis

配合Redis进程不用root用户运行，这样一个完整的身份鉴别闭环才算真正打通。

4. 让日志真正“会说话”：安全审计要求下的Redis日志与留存方案

4.1 默认配置下的“日志沉默”

很多客户觉得Redis日志不需要管，默认在终端输出就行。但这个想法在测评现场会吃大亏。默认配置下logfile是空的，Redis只是把日志打到标准输出，服务器一重启，日志全没了。

等保三级对安全审计有明确要求：审计记录至少要包含事件日期、用户、事件类型、是否成功，并且留存不少于6个月。Redis默认这种“不落盘、不留存”的状态，测评老师打开日志一栏写“空”，审计项直接不合格。

还有一个要让各位管理者提前知道的事实：Redis自带的日志不记录每一条GET/SET操作，它记录的主要是启动、关闭、持久化、主从切换、认证失败这类过程事件。真正的命令级审计，Redis默认做不了，需要靠外部手段补充。这不是配置遗漏，而是Redis自身的设计。测评沟通时把这块说明白，同时用下面几条腿走路。

4.2 落盘、级别、轮转：一个都不能少

先解决落盘问题，redis.conf里加：

code复制logfile "/var/log/redis/redis.log"
loglevel notice

loglevel设成notice是最平衡的选择，info会产生过多日志影响性能，warning又会漏掉很多关键过程信息。

再配logrotate做日志轮转，留存天数按照超过180天来配置：

code复制/var/log/redis/redis.log {
    daily
    rotate 183
    compress
    missingok
    notifempty
    copytruncate
}

用copytruncate是因为Redis进程一直持有日志文件句柄，直接rename再新建文件，Redis还是会写旧文件。copytruncate是先复制再清空，不需要重启Redis。

4.3 审计链路补充：SLOWLOG与auditd

因为Redis日志不记录命令级操作，你需要补充审计链路来应对测评老师的追问。我实践下来比较有效的组合是：

开启慢查询日志，记录执行时间超过阈值的命令：

code复制slowlog-log-slower-than 10000
slowlog-max-len 128

10000表示10毫秒。线上如果经常有慢命令，可以通过SLOWLOG GET查看，这也算“能够记录操作行为”的证据之一。

用系统auditd监控Redis配置和进程。在/etc/audit/rules.d/redis.rules里加入：

code复制-w /etc/redis/redis.conf -p wa -k redis_config
-w /usr/local/bin/redis-server -p x -k redis_exec

第一条监控配置文件有没有被修改，第二条监控redis-server可执行文件有没有被执行。这样一旦出现配置篡改或者异常拉起Redis进程，都有系统审计记录。

这些配合起来，你的安全审计证据链就比较完整了：Redis自身日志记录运行过程，慢查询日志记录慢命令，ACL日志记录认证尝试和权限事件，auditd记录配置和进程层面的异常。测评老师要看啥都能拿出来。

ACL日志可以通过ACL LOG命令查看，主要记录的是ACL认证失败和一些权限不足的访问尝试，这也是“登录失败处理”层面的一点补充。

5. 禁命令、限权限、控运行身份：入侵防范不是改一行配置

5.1 哪些危险命令必须动，哪些要看业务

Redis里有几个命令是等保测评的高危点，因为它们要么能清空数据，要么能读取配置，要么能阻塞实例。下面这张表是我整理的高频危险命令及处置建议：

5.2 rename-command的正确姿势和坑

在redis.conf里通过rename-command把危险命令重命名成空字符串，就是彻底禁用：

code复制rename-command FLUSHALL ""
rename-command FLUSHDB ""
rename-command CONFIG ""
rename-command KEYS ""
rename-command SHUTDOWN ""
rename-command DEBUG ""

这样做有个坑：改完之后，所有客户端再调用这些命令都会报错。尤其是KEYS命令，很多业务代码或运维脚本喜欢用KEYS去遍历缓存，一旦禁用，线上直接抛unknown command。所以要提前梳理业务，把遍历逻辑改成SCAN。这个动作一定要在整改前知会开发团队。

如果Redis版本在6.0以上，我更推荐用ACL来控制这些命令而不是一刀切，给运维账号保留权限但排除高危项：

code复制user redis_ops on >O1x@2024#Redis ~* +@all -flushall -flushdb -config -shutdown -debug

这样运维账号平时还能用CONFIG查看运行状态，但FLUSHALL这些操作被彻底禁止。相比rename-command的“全局封禁”，ACL的粒度要细得多。老版本的rename-command方案不是不能用，只是新版本有了更好的替代。

5.3 运行身份、目录权限和Docker部署的补充加固

Redis进程绝对不能以root身份运行。如果排查时发现ps aux里显示redis-server跑在root下，那基本就是踩到测评机构的禁忌了。整改方法：

创建专用用户并调整属主：

bash复制useradd -r -s /sbin/nologin redis
chown -R redis:redis /etc/redis /var/lib/redis /var/log/redis

然后通过systemd管理Redis，unit文件里明确指定运行用户：

code复制[Unit]
Description=Redis Server
After=network.target

[Service]
Type=simple
User=redis
Group=redis
ExecStart=/usr/local/bin/redis-server /etc/redis/redis.conf
ExecReload=/bin/kill -s HUP $MAINPID
ExecStop=/bin/kill -s TERM $MAINPID
Restart=always
PrivateTmp=true
ProtectSystem=full

[Install]
WantedBy=multi-user.target

这里有两个细节值得一提：

• ProtectSystem=full让Redis无法修改系统关键路径下的文件，是进程层面的加固。
• PrivateTmp=true隔离临时目录，避免临时文件被其他进程偷看。

Docker部署的提前排查也别忘了，命令看清楚有没有把端口暴露到所有网卡：

bash复制docker ps

如果看到0.0.0.0:6379->6379/tcp，赶紧改。还有容器内的Redis也要以非root用户运行，Redis官方镜像默认会切换到redis用户，但如果你在Dockerfile里自己写了USER root，就要自己负责整改了。

6. 容易被忽略的三件事：传输加密、备份保护与资源控制

6.1 传输加密：Redis 6.0之后终于可以原生开TLS

等保三级对通信传输有完整性、保密性要求。Redis默认是明文协议，如果它和应用服务器之间的链路跨越了非受信网络，测评老师大概率会揪着这个问题不放。

Redis 6.0以后原生支持TLS，配置方法不算复杂。先用openssl生成CA和服务端证书：

bash复制openssl req -x509 -newkey rsa:2048 -days 3650 -nodes \
  -keyout /etc/redis/tls/ca.key -out /etc/redis/tls/ca.crt \
  -subj "/CN=redis-ca"

openssl req -newkey rsa:2048 -nodes \
  -keyout /etc/redis/tls/redis.key -out /etc/redis/tls/redis.csr \
  -subj "/CN=redis-server"

openssl x509 -req -in /etc/redis/tls/redis.csr \
  -CA /etc/redis/tls/ca.crt -CAkey /etc/redis/tls/ca.key \
  -CAcreateserial -out /etc/redis/tls/redis.crt -days 3650

在redis.conf里启用：

code复制port 0
tls-port 6380
tls-cert-file /etc/redis/tls/redis.crt
tls-key-file /etc/redis/tls/redis.key
tls-ca-cert-file /etc/redis/tls/ca.crt
tls-auth-clients yes

客户端连接的时候：

bash复制redis-cli --tls --cacert /etc/redis/tls/ca.crt \
  -h redis.example.local -p 6380

开启TLS对性能会有一定影响，量级大概在5%-15%之间，取决于QPS和证书套件，生产环境建议在业务低峰期灰度切换。如果你的Redis和应用服务器都在同一个受控内网，并且有网络层加密机制或专线，那也可以在测评时说明情况，不一定非要开TLS。但“三级的系统跨网段通信且完全明文”，大概率会被记问题。

6.2 备份保护：RDB/AOF不只是“开没开”这么简单

等保三级的数据备份恢复要求很容易被忽视，测评老师会先看Redis是否开启了持久化。配置如下：

code复制save 900 1
save 300 10
save 60 10000
appendonly yes
appendfilename "appendonly.aof"

开启不等于安全，备份文件里的数据是完整的键值对，如果权限控制不到位，等于给攻击者送一份敏感数据。我习惯用下面这套权限策略：

bash复制chown -R redis:redis /data/redis
chmod 700 /data/redis

同时，备份策略还要落到制度层面：每天至少一次全量备份，备份文件要异地保存或离线保存。测评时拿出备份记录、异地备份管理制度，比单纯修改配置更能加分。

6.3 资源控制：maxmemory和maxclients怎么配才合理

资源控制项不是每个测评老师都会深挖，但它属于安全计算环境的通用要求，配置了总归是有益。

生产环境建议先估算业务峰值所需内存，再设置maxmemory。比如业务预计缓存用量3GB，机器内存8GB，建议设置：

code复制maxmemory 4gb
maxmemory-policy allkeys-lru
maxclients 10240
timeout 300

maxmemory不能超过物理内存的80%左右，要给操作系统和Redis自身留出余量，否则很容易触发OOM被内核杀掉。maxmemory-policy要看业务情况：有明确淘汰需求的用allkeys-lru，只淘汰过期键的用volatile-lru，不要在生产上配置noeviction，因为内存写满之后会直接拒绝写入。

timeout=300适合短连接场景。如果业务使用连接池且连接复用频繁，这个值要适当调大或者设成0，否则客户端拿到的连接被服务端断开，反而产生一堆连接报错。

7. 测评前自测清单：照着一项项核对，Redis这块基本就能稳

整理一下这些年做Redis安全整改的经验，我把它沉淀成一张自测清单。建议在测评进场前一周，照着清单逐项过一遍，每项都截图留档。

| 序号 | 检查项 | 过关标准 |