# 26、Redis数据库加固 > Redis 缓存数据库等保三级安全加固：bind 收敛监听地址与 protected-mode、requirepass 单口令与 ACL 多用户（6.0+）并行的两套鉴别体系、ACL SETUSER 按命令类别与键模式授权、default 用户收敛、rename-command 已弃用改用 ACL 的官方口径、TLS（tls-port/tls-cert-file/tls-auth-clients/tls-replication）传输加密、slowlog 与主机侧审计补偿、RDB（save/LASTSAVE/redis-check-rdb）与 AOF（appendonly/appendfsync everysec）持久化备份、maxmemory-policy 内存淘汰、masterauth/INFO replication 主从一致性与集群端口收敛，每节附核查命令、加固操作与版本差异速查。 --- LLMS index: [llms.txt](/wikis/llms.txt) --- > 定位：Redis 6.x / 7.x 等保三级安全加固手册：按 00~10 编号分节覆盖版本与补丁管理、监听与暴露面收敛、认证与 ACL、口令治理、危险命令收敛、传输加密、日志与审计补偿、持久化备份、主从与集群安全、内存淘汰与退役清理，每节附核查命令（redis-cli 只读）、加固操作与测评项对照表。 > > 适用版本：Redis 6.0 ~ 7.x（7.4 为本文核验基准；ACL 自 6.0 引入、TLS 自 6.0 编译支持）。Redis 5.x 及更早只有 `requirepass` 单口令，无 ACL/TLS 能力，判定与整改口径见 10 节速查。 > 配套测评：[Redis 缓存数据库测评](../../../gradeProtection/中间件与容器/redis/)。 > > 使用说明： > > - 本文为**加固操作手册**：`CONFIG SET` 类命令即时生效但不落盘，须同步修改 `redis.conf` 并纳入配置管理；`ACL SETUSER`、重启类变更可能断开现有连接，实施前必须完成变更审批、确认业务窗口、备份原 `redis.conf` 与 RDB/AOF 文件，并准备**可执行的回滚预案**。 > - 先在测试环境或灰度实例验证，确认应用连接串（新增用户名/密码/TLS 参数）改造完成后再上线；每完成一项立即用文中「核查方法」复核生效——**配置已写入不等于客户端已切换**，`requirepass` 生效而应用未带 AUTH 时业务会立即报 NOAUTH 错误，属于最高频的加固翻车点。 > - 示例中的口令、地址、路径均为演示值（如 `PleaseChange@123`、`192.168.10.20`），现场须替换为符合本单位口令策略的真实值，**严禁直接沿用文中示例口令**；对外发布或归档时须对内网地址与口令脱敏。 > - 命令回显与本文不一致时，先用 `redis-cli INFO server` 确认版本（ACL 6.0+、多参数 `CONFIG GET` 7.0+），再查阅对应版本文档换用等效命令；**版本差异不得直接作为「无法整改」的结论**，须给出替代措施并评估其实际效果。 > - 涉及监听地址、口令、ACL、TLS 的变更存在锁死自身风险：务必保留一条已验证的恢复通道（本机 `redis-cli -h 127.0.0.1` 会话、另一个管理员 ACL 账户或哨兵/管理平台通道）后再实施。 > - 加固完成后按「16、安全评估加固记录表3.0」逐项留痕（整改前后回显、操作人、时间、验证结论、回退情况），并纳入复测；测评判定口径以 GB/T 28448-2019 与《高风险判定指引》为准，本文的「加固要点」不构成最终测评结论。 > > 不适用标识说明： > > - 使用 `【不适用】` 明确标记现场可判定为不适用的控制点，并写明判定依据与承载该能力的上位组件。 > - 依据 GB/T 28448-2019「按测评对象实际承载功能与数据处理范围判定」原则：控制能力由日志审计系统、堡垒机、云托管 Redis（阿里云 Tair/Redis、AWS ElastiCache）等承载时，应注明测评单元边界后判定不适用或转由上位组件核查，不得机械按缺失判不符合。 > - 产品版本确实不提供该能力（如 5.x 无 ACL/TLS、社区版无企业级审计模块）时，须核查替代措施并按替代措施的实际效果定档，不得直接判不适用；已停止官方支持的版本应同时提出升级或补偿控制建议。 ## 测评项对照表 | 控制点（GB/T 22239-2019 安全计算环境-缓存数据库） | 对应章节 | | --- | --- | | 入侵防范：暴露面收敛、最小安装 | 00、01 | | 身份鉴别：口令复杂度/有效期、失败处理 | 02、03 | | 访问控制：账户唯一、权限最小化 | 02、04 | | 身份鉴别：远程管理防窃听 | 05 | | 安全审计：日志与留存 | 06 | | 数据备份恢复 | 07 | | 剩余信息保护 | 09 | | 入侵防范：主从与集群边界 | 08 | ## 00 关注官方安全更新公告 > **对应控制点**：GB/T 22239-2019 8.1.4.4 入侵防范 a)~f)（最小安装、漏洞与补丁管理） > > **加固要点**：建立版本台账，跟踪 redis.io 官方发布与安全修复；Redis 官方维护「上一主要版本 + 当前主要版本」，长期停留在停止维护的小版本线上须给出升级计划。已被公开披露未授权访问勒索事件（删除数据写入 flushall 警告）与蠕虫利用链的旧版本（以官方与国家漏洞库披露为准，不展开具体 CVE 编号），应作为升级依据留痕。 > > **验证方法**：`INFO server` 版本回显、升级/补丁记录、官方 Release Notes 订阅或跟踪证据。 **核查方法** ```bash redis-cli -h 127.0.0.1 -p 6379 INFO server | grep -E "redis_version|redis_git_sha1|os" redis-server --version ``` - 预期现象：版本在官方支持范围内，且有升级窗口与记录可查。 ## 01 监听地址与暴露面收敛（核心） > **对应控制点**：GB/T 22239-2019 8.1.4.4 入侵防范 b) c)（关闭不需要的服务与端口、限制管理终端接入） > > **加固要点**：官方安全文档明确"Redis is designed to be accessed by trusted clients inside trusted environments"、不建议将实例直接暴露互联网或不受信网络。落地三层：`bind` 仅绑定回环或内网管理/应用网段（默认配置文件给出的形态为 `bind 127.0.0.1 -::1`）；`protected-mode yes`（3.2.0 起默认开启，在「绑定全部接口且无口令」时仅应答回环连接，是兜底而非常态防护）；主机防火墙/云安全组仅放行应用服务器与堡垒机来源。对外（尤其公网）开放 6379 且无认证属高风险。 > > **验证方法**：`CONFIG GET bind/protected-mode/port` 回显、`ss -lntp` 监听截图、防火墙/安全组策略截图、从非授权来源实测连接被拒。 **核查方法** ```bash redis-cli -h 127.0.0.1 INFO server | grep tcp_port redis-cli -h 127.0.0.1 CONFIG GET bind protected-mode port ss -lntp | grep 6379 grep -E "^bind|^protected-mode|^port" /etc/redis/redis.conf ``` **加固操作**（修改 `/etc/redis/redis.conf` 后重启，或 `CONFIG SET` 即时生效 + 同步改配置文件） ```conf bind 127.0.0.1 192.168.10.20 # 仅回环与应用/运维内网地址；多网卡逐个列出 protected-mode yes port 6379 # 业务不依赖默认端口时建议改非默认端口 ``` - 预期现象：`ss -lntp` 仅见指定地址监听；非授权来源 `redis-cli -h <外网地址>` 连接超时或被防火墙拒绝。 ## 02 认证体系：requirepass 与 ACL 多用户 > **对应控制点**：GB/T 22239-2019 8.1.4.1 身份鉴别 a)~d)（标识唯一、复杂度与更换、失败处理、组合鉴别） > > **加固要点**：Redis 6.0 起官方推荐用 ACL 建立实名用户并按最小权限授权（"The recommended authentication method, introduced in Redis 6, is via Access Control Lists"）；`requirepass` 是遗留方式，仅对 default 用户设置单一口令，无法区分账户。生产环境应：应用连接、运维连接、备份账户各自独立 ACL 用户；default 用户不得保留 `nopass`（默认 ACL 为 `user default on nopass ~* &* +@all`，即免密全权限）；口令以 SHA-256 散列（`#`）或受控的 `>` 形式写入 `aclfile`；云托管 Redis 的账户体系由平台承载时注明边界。注意官方配置文件明确：**`requirepass` 与 `aclfile` 不兼容，同时配置时 `requirepass` 会被忽略**——两套体系只能选一套主用。 > > **验证方法**：`ACL LIST`/`ACL GETUSER` 用户与权限回显、default 用户无 `nopass` 标记、无口令连接被拒（NOAUTH）实测、各账户最小权限实测（越权命令返回 NOPERM）。 **核查方法** ```bash redis-cli -h 127.0.0.1 ACL LIST redis-cli -h 127.0.0.1 ACL GETUSER default ls -l /etc/redis/redis.conf /etc/redis/users.acl ```
示例输出（节选）
127.0.0.1:6379> ACL LIST
1) "user default on #2d9c75... resetchannels ~* &* +@all"   # 已设散列口令，无 nopass
2) "user app_rw on #a1b2c3... resetkeys ~app:* &* +@read +@write -flushall -flushdb"   # 应用账户仅读写业务键前缀
3) "user ops_admin on #e4f5a6... resetchannels ~* &* +@all -@dangerous"   # 运维账户剔除危险类命令
127.0.0.1:6379> ACL GETUSER default
 1) "flags"
 2) 1) "on"
 3) "passwords"
 4) 1) "2d9c75273d72b32df726fb545c8a4edc719f0a95a6fd993950b10c474ad9c927"   # SHA-256 散列，非明文
**加固操作**（先建账户验证，再收敛 default；7.0+ 支持子命令级授权如 `+config|get`） ```bash # 1) 建立应用账户：仅读写 app:* 键，剔除全库清空类命令 redis-cli ACL SETUSER app_rw on >PleaseChange@123 ~app:* +@read +@write -flushall -flushdb # 2) 建立运维账户：全部命令但剔除危险类 redis-cli ACL SETUSER ops_admin on >PleaseChange@456 +@all -@dangerous # 3) 为 default 设置强口令并收窄权限（或 off 禁用免密通道，注意保留已验证的管理员会话） redis-cli ACL SETUSER default >PleaseChange@789 +@read +@write -@dangerous # 4) 持久化：用户直接定义在 redis.conf 时用 CONFIG REWRITE；使用 aclfile 时用 ACL SAVE redis-cli CONFIG REWRITE ``` - 预期现象：`ACL LIST` 无 `nopass` 用户；未认证连接返回 `NOAUTH Authentication required`；`app_rw` 执行 `CONFIG GET` 返回 `NOPERM` 实测记录。 ## 03 口令强度与轮换 > **对应控制点**：GB/T 22239-2019 8.1.4.1 身份鉴别 a)（复杂度与定期更换） > > **加固要点**：Redis **无内置口令复杂度与有效期校验**（如实说明，不虚构配置项），官方安全文档的建议是"password should be long enough to prevent brute force"——因为 Redis 查询极快、每秒可被尝试大量口令，且口令以共享密钥形态使用；官方提供 `ACL GENPASS` 基于系统加密随机源生成 256 位口令。落地方式：口令长度不低于 16~32 位随机串（或口令短语）、按制度定期（不超过 90 天）轮换并在 `aclfile` 中同步更新散列、轮换时先加新口令（`>`）验证后删旧口令（`<`）实现无感切换。 > > **验证方法**：`ACL GETUSER` 的 passwords 散列清单、轮换记录与工单、口令强度抽查（不回显明文，查长度台账）。 **核查方法** ```bash redis-cli ACL GETUSER ops_admin | head -6 # passwords 为 SHA-256 散列 redis-cli ACL GENPASS # 官方随机口令生成（64 位字母数字） ```
示例输出（节选）
127.0.0.1:6379> ACL GENPASS
"dd721260bfe1b3d9601e7fbab36de6d04e2e67b0ef1c53de59d45950db0dd3cc"
## 04 危险命令收敛：从 rename-command 到 ACL > **对应控制点**：GB/T 22239-2019 8.1.4.2 访问控制 c) d)（权限最小化、默认账户治理） > > **加固要点**：官方安全文档已将 `rename-command` 标注为 **deprecated（可能在未来版本移除）**，推荐改用 ACL 规则限制命令。需从普通账户剔除的高危能力：`FLUSHALL`/`FLUSHDB`（全库清空）、`CONFIG`（改写运行配置与文件路径，历史利用链核心）、`KEYS`（全键遍历阻塞）、`DEBUG`、`SHUTDOWN`、`SAVE`/`BGSAVE`（可配合 `dir` 写文件）、`MODULE`（加载任意模块）、`EVAL`（脚本）——对应 ACL 命令类别 `@admin`/`@dangerous`。官方 ACL 文档同时提醒：**键模式（`~pattern`）不限制不带键参数的全库命令**（`FLUSHALL`、`FLUSHDB`、`SWAPDB` 不受键模式约束），必须用命令规则显式剔除（官方示例 `+@all -flushall -flushdb -swapdb`）。6.x 旧部署沿用 `rename-command CONFIG ""` 时须在台账注明并列入 ACL 改造计划。 > > **验证方法**：`ACL CAT dangerous`/`ACL CAT admin` 类别命令清单、各用户 `ACL GETUSER` 的 commands 字段、越权执行实测（NOPERM 回显）。 **核查方法** ```bash redis-cli ACL CAT dangerous | head -20 redis-cli ACL GETUSER app_rw | grep -A1 commands grep "^rename-command" /etc/redis/redis.conf # 旧方案存量排查 ```
示例输出（节选）
127.0.0.1:6379> ACL CAT dangerous | head -6
1) "flushall"
2) "migrate"
3) "restore"
4) "sort"
5) "keys"
6) "client"
127.0.0.1:6379> ACL GETUSER app_rw | grep -A1 commands
"commands"
"-@all +@read +@write -flushall -flushdb"      # 应用账户无 CONFIG/KEYS/DEBUG
**加固操作** ```bash # 应用类账户：白名单式（先清空再加所需类别），并显式剔除全库命令 redis-cli ACL SETUSER app_rw reset +@read +@write -flushall -flushdb -sort -keys # 允许应用查看配置但禁止改配置（7.0+ 子命令级授权） redis-cli ACL SETUSER app_rw +config|get ``` - 预期现象：应用账户执行 `CONFIG SET`/`FLUSHALL`/`KEYS *` 均返回 NOPERM；业务功能回归正常。 ## 05 传输加密（TLS） > **对应控制点**：GB/T 22239-2019 8.1.4.1 身份鉴别 c)（远程管理防窃听）、8.1.4.8 数据保密性 a)（传输加密） > > **加固要点**：TLS 为 6.0 起的可选特性（编译期 `BUILD_TLS=yes`，发行版包默认启用；自编译须确认），官方支持客户端连接、复制链路、集群总线全通道 TLS。落地：`tls-port` 开启 TLS 监听，`port 0` 彻底关闭明文端口（官方示例 `port 0` + `tls-port 6379`）；默认为双向 TLS（客户端须持证书），可用 `tls-auth-clients no` 关闭客户端证书校验仅保留加密；复制链路 `tls-replication yes`、集群 `tls-cluster yes`。云托管 Redis 的 TLS 由平台开关承载。未启用 TLS 的内网明文 Redis，若网络路径跨网段/跨机房，判部分符合并给补偿（网络隔离 + 抓包验证）。 > > **验证方法**：`redis-cli --tls --cacert ...` 连接成功、`redis-cli -h -p <明文端口>`（已 `port 0`）连接失败、`CONFIG GET tls-port/port/tls-replication/tls-cluster` 回显、证书有效期核查。 **核查方法** ```bash redis-cli -h 127.0.0.1 CONFIG GET port tls-port tls-cert-file tls-auth-clients tls-replication tls-cluster redis-cli --tls --cacert /etc/redis/tls/ca.crt -h 192.168.10.20 -p 6379 PING ss -lntp | grep redis-server # 确认无明文监听残留 ```
示例输出（节选）
127.0.0.1:6379> CONFIG GET port tls-port tls-auth-clients tls-replication
1) "port"
2) "0"                     # 明文端口已关闭
3) "tls-port"
4) "6379"                  # 仅 TLS 监听
5) "tls-auth-clients"
6) "yes"                   # 双向 TLS
7) "tls-replication"
8) "yes"                   # 复制链路加密
redis-cli --tls --cacert /etc/redis/tls/ca.crt -h 192.168.10.20 PING
PONG
**加固操作**（`/etc/redis/redis.conf`，重启生效；证书可用内部 CA 或商业证书，密钥文件权限 600） ```conf port 0 tls-port 6379 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 tls-replication yes tls-cluster yes ``` - 预期现象：明文端口无监听；客户端须 `--tls` 且持信验 CA/证书方可连接；主从复制抓包为密文。 ## 06 日志与审计补偿 > **对应控制点**：GB/T 22239-2019 8.1.4.3 安全审计 a)~d)（审计启用、覆盖、记录内容、留存保护） > > **加固要点**：Redis 原生审计能力有限，如实按能力判定：`loglevel`（默认 `notice`）与 `logfile`（默认空即 stdout，生产应落盘）提供运行日志；`SLOWLOG` 记录慢命令（默认阈值 `slowlog-log-slower-than 10000` 微秒即 10ms、容量 `slowlog-max-len 128`）；`ACL LOG`（6.0+）记录被 ACL 拒绝的越权尝试——这是身份鉴别失败处理的核心证据来源；`MONITOR` 调试命令会流式输出全部命令但官方警告其性能开销大，**不得作为常态审计手段**。留存不少于 6 个月依赖补偿：日志文件经 rsyslog 外送日志审计系统、主机侧 auditd 对 `redis-server` 进程与 `redis.conf`/`users.acl` 文件配置变更审计、网络侧流量审计。云托管 Redis 的审计由平台模块承载时注明边界。 > > **验证方法**：`SLOWLOG GET`/`ACL LOG` 回显、`loglevel`/`logfile` 配置、rsyslog 外送配置、日志平台中 Redis 日志检索与最早时间戳（≥6 个月）。 **核查方法** ```bash redis-cli CONFIG GET loglevel logfile slowlog-log-slower-than slowlog-max-len redis-cli SLOWLOG GET 5 redis-cli ACL LOG 5 ls -l /var/log/redis/ grep -r "redis" /etc/rsyslog.d/ 2>/dev/null ```
示例输出（节选）
127.0.0.1:6379> ACL LOG 5
1) 1) "count"
   2) (integer) 3
   3) "reason"
   4) "command"          # 越权命令被拒记录：账户、命令、时间戳齐全
   5) "context"
   6) "toplevel"
   7) "object"
   8) "config"
127.0.0.1:6379> SLOWLOG GET 2
1) 1) (integer) 14
   2) (integer) 1664000000      # Unix 时间戳
   3) (integer) 13245            # 耗时（微秒）
   4) 1) "KEYS"  2) "*"          # 慢命令样例：全键遍历，印证 04 节收敛必要性
**加固操作**（`/etc/redis/redis.conf` + 主机侧，重启生效；阈值与容量按业务调整） ```conf loglevel notice logfile /var/log/redis/redis-server.log slowlog-log-slower-than 10000 slowlog-max-len 256 ``` ```bash # rsyslog 外送（示意，目标为日志审计系统） echo 'programname.contains("redis-server") @@192.168.20.10:6514' > /etc/rsyslog.d/30-redis.conf && systemctl restart rsyslog ``` - 预期现象：日志文件仅 redis 运行账户可写；日志平台可检索 6 个月以上 Redis 事件；`ACL LOG` 有越权拒绝记录。 ## 07 持久化与备份恢复 > **对应控制点**：GB/T 22239-2019 8.1.4.9 数据备份恢复 a) b) c)（备份、异地、恢复演练） > > **加固要点**：两种持久化机制按业务选配并留痕：RDB 快照（`save ` 触发，官方示例 `save 3600 1 300 100 60 10000`，适合容灾快照）与 AOF 追加（`appendonly no` 为默认，开启后 `appendfsync everysec` 为官方默认落盘策略，`always` 最安全、`no` 交给系统）。缓存场景可接受重建时，备份恢复可【不适用】并写明依据（数据源在数据库、Redis 仅缓存）；作为权威数据源时必须：RDB/AOF 文件定期异地备份（`LASTSAVE` 核查最近快照时间戳、`redis-check-rdb` 校验文件完整性）、备份文件权限与属主最小化、每半年至少一次恢复演练记录。 > > **验证方法**：`CONFIG GET save/appendonly/appendfsync` 回显、`LASTSAVE` 时间戳、`INFO persistence` 的 RDB/AOF 状态、备份文件清单与恢复演练记录。 **核查方法** ```bash redis-cli CONFIG GET save appendonly appendfsync dir dbfilename redis-cli LASTSAVE redis-cli INFO persistence | grep -E "rdb_last_save_time|rdb_last_bgsave_status|aof_enabled|aof_last_write_status" ls -l /var/lib/redis/dump.rdb /var/lib/redis/appendonlydir/ 2>/dev/null redis-check-rdb /var/lib/redis/dump.rdb 2>/dev/null | tail -n 3 ```
示例输出（节选）
127.0.0.1:6379> CONFIG GET appendonly appendfsync save
1) "appendonly" 2) "yes"
3) "appendfsync" 4) "everysec"
5) "save"       6) "3600 1 300 100 60 10000"
127.0.0.1:6379> LASTSAVE
(integer) 1772524800        # 最近 RDB 快照 Unix 时间戳
redis-check-rdb /var/lib/redis/dump.rdb | tail -n 2
[offset] RDB check done!    # 文件完整
**加固操作**（`/etc/redis/redis.conf`，重启生效；`bgsave`/`bgrewriteaof` 属变更类运维命令，按窗口执行） ```conf save 3600 1 300 100 60 10000 appendonly yes appendfsync everysec dir /var/lib/redis dbfilename dump.rdb ``` - 预期现象：`INFO persistence` 显示 `rdb_last_bgsave_status:ok`、`aof_last_write_status:ok`；异地有 RDB/AOF 备份且可 `redis-check-rdb` 校验通过。 ## 08 主从复制与集群安全 > **对应控制点**：GB/T 22239-2019 8.1.4.2 访问控制、8.1.2 安全区域边界（服务边界与接入限制联动） > > **加固要点**：主从/哨兵/集群的全部节点同权加固（只加固主库、从库裸奔是常见失分点）：从库 `masterauth` 与主库口令/ACL 对应账户一致；复制链路启用 `tls-replication yes`；`replica-read-only yes`（默认开启）保持从库只读；集群模式 `tls-cluster yes` 并在防火墙收敛集群总线端口（默认 `port+10000`，即 16379）与各节点数据端口；官方 ACL 文档给出从库所需最小命令集（主库侧放行 `+psync +replconf +ping`）与哨兵所需命令集（`+multi +slaveof +ping +exec +subscribe +config|rewrite +role +publish +info +client|setname +client|kill +script|kill`，详见官方 ACL 页 Sentinel and Replicas 一节）。`INFO replication` 确认拓扑与主从角色和资产台账一致。 > > **验证方法**：`INFO replication` 主从角色与连接数回显、`CONFIG GET masterauth/tls-replication`、从库写命令被拒（READONLY）实测、集群总线端口仅在节点间互通的策略截图。 **核查方法** ```bash redis-cli INFO replication redis-cli CONFIG GET masterauth replica-read-only tls-replication redis-cli -h <从库地址> SET testkey x # 预期 READONLY You can't write against a read only replica ss -lntp | grep -E "6379|16379" ```
示例输出（节选）
127.0.0.1:6379> INFO replication
# Replication
role:master
connected_slaves:2
slave0:ip=192.168.10.21,port=6379,state=online,offset=1827,lag=0
slave1:ip=192.168.10.22,port=6379,state=online,offset=1827,lag=0
master_failover_state:no-failover
**加固操作** ```conf # 主库与从库 redis.conf 同步配置（口令经 ACL 账户或 masterauth，二选一并与主库一致） masterauth PleaseChange@123 replica-read-only yes tls-replication yes ``` - 预期现象：主从复制状态 `online` 且 lag 正常；从库写入返回 READONLY；抓包复制流量为 TLS 密文。 ## 09 剩余信息保护与退役清理 > **对应控制点**：GB/T 22239-2019 8.1.4.10 剩余信息保护 a)b)（存储空间释放前完全清除） > > **加固要点**：内存淘汰与容量治理：`maxmemory` 设上限、`maxmemory-policy`（默认 `noeviction`）按业务在 8 种策略中选择（`volatile-lru`/`allkeys-lru`/`volatile-lfu`/`allkeys-lfu`/`volatile-random`/`allkeys-random`/`volatile-ttl`/`noeviction`），缓存业务常用 `allkeys-lru`/`allkeys-lfu`，注意官方提示无合适键可淘汰时写命令将报错。退役与下线：退役实例的 RDB/AOF 文件与 `users.acl`/`redis.conf`（内含口令散列）须安全删除或归档加密；口令轮换后旧散列从 aclfile 移除；`FLUSHDB`/`FLUSHALL` 属变更类命令，退役清库须走审批并在记录表留痕。 > > **验证方法**：`CONFIG GET maxmemory/maxmemory-policy` 回显、退役清单与文件删除/加密归档记录、aclfile 无历史残留口令散列。 **核查方法** ```bash redis-cli CONFIG GET maxmemory maxmemory-policy redis-cli INFO memory | grep -E "used_memory_human|maxmemory_human|maxmemory_policy" grep -c "^user" /etc/redis/users.acl 2>/dev/null find /var/lib/redis -name "*.rdb" -o -name "*.aof" | xargs ls -l 2>/dev/null ```
示例输出（节选）
127.0.0.1:6379> CONFIG GET maxmemory maxmemory-policy
1) "maxmemory"         2) "4294967296"     # 4 GiB 上限
3) "maxmemory-policy"  4) "allkeys-lru"
127.0.0.1:6379> INFO memory | grep maxmemory_policy
maxmemory_policy:allkeys-lru
## 10 版本差异速查与低版本处置 > **对应控制点**：GB/T 22239-2019 8.1.4.1 / 8.1.4.4（身份鉴别、入侵防范——版本能力差异处置） | 事项 | 5.x 及更早 | 6.0 / 6.2 | 7.x（本文基准） | | --- | --- | --- | --- | | 认证 | 仅 `requirepass` 单口令 | 引入 ACL；6.2 增加频道模式管理 | 推荐 ACL；`acl-pubsub-default` 默认 `resetchannels` | | 命令限制 | `rename-command` | ACL 全量可用 | `rename-command` 官方标注 deprecated；子命令级授权（`+config\|get`）；键权限 `%R~`/`%W~` | | TLS | 无 | 6.0 起编译期支持 | 同；8.0 起 TLS 支持 I/O 线程 | | `CONFIG GET` 参数 | 单/成对模式 | 同 | 7.0 起支持一次多参数（命令页 syntax `CONFIG GET parameter [parameter ...]`） | | AOF | 单文件 | 单文件 | 多文件（`appendonlydir/`） | | 空闲超时 | `timeout` 默认 0（不断开） | 同 | 同（官方客户端文档：默认不关闭空闲连接） | - 低版本处置：5.x 无 ACL/TLS 时，不得直接判不适用——核查替代措施（网络隔离 + `requirepass` 强口令 + `rename-command` 收敛 + 主机/网络侧审计）并按实际效果定档，同时列入升级计划；官方对旧版本的支持窗口以 redis.io 发布说明为准。 ## 参考依据 - GB/T 22239-2019《信息安全技术 网络安全等级保护基本要求》（8.1.4 安全计算环境各控制点）：[http://openstd.samr.gov.cn/bzgk/gb/newGbInfo?hcno=BAFB47E8874764186BDB7865E8344DAF](http://openstd.samr.gov.cn/bzgk/gb/newGbInfo?hcno=BAFB47E8874764186BDB7865E8344DAF) - GB/T 28448-2019《信息安全技术 网络安全等级保护测评要求》（测评对象边界认定、单元测评实施与结果判定）：[http://openstd.samr.gov.cn/bzgk/gb/newGbInfo?hcno=7E736CDF4502B6FF1258DD250AA3EC8C](http://openstd.samr.gov.cn/bzgk/gb/newGbInfo?hcno=7E736CDF4502B6FF1258DD250AA3EC8C) - Redis 官方安全文档（security model 原文、protected mode 3.2.0 起默认、requirepass 明文与 AUTH 未加密、rename-command deprecated、以非特权 redis 用户运行）：[https://redis.io/docs/latest/operate/oss_and_stack/management/security/](https://redis.io/docs/latest/operate/oss_and_stack/management/security/) - Redis 官方 ACL 文档（默认 `user default on nopass ~* &* +@all`、`ACL SETUSER/GETUSER/LIST/GENPASS` 语法、命令类别清单、`aclfile` 与 `requirepass` 互斥、键模式不约束 FLUSHALL、Sentinel/Replica 最小命令集、口令 SHA-256 存储）：[https://redis.io/docs/latest/operate/oss_and_stack/management/security/acl/](https://redis.io/docs/latest/operate/oss_and_stack/management/security/acl/) - Redis 官方 TLS 文档（`port 0`+`tls-port` 示例、双向 TLS 默认与 `tls-auth-clients no`、`tls-replication`/`tls-cluster`、redis-cli `--tls --cert --key --cacert`）：[https://redis.io/docs/latest/operate/oss_and_stack/management/security/encryption/](https://redis.io/docs/latest/operate/oss_and_stack/management/security/encryption/) - Redis 官方 7.4 自述配置文件（`bind 127.0.0.1 -::1`、`protected-mode yes`、`replica-read-only yes`、`maxmemory-policy noeviction` 及 8 种取值、`appendonly no`/`appendfsync everysec`、`save 3600 1 300 100 60 10000`、`slowlog-log-slower-than 10000`/`slowlog-max-len 128`、`aclfile`、`loglevel notice`）：[https://raw.githubusercontent.com/redis/redis/7.4/redis.conf](https://raw.githubusercontent.com/redis/redis/7.4/redis.conf) - Redis 官方命令参考（`CONFIG GET parameter [parameter ...]` 多参数语法、`ACL LOG`、`SLOWLOG GET`、`INFO replication`、`LASTSAVE`、`CLIENT LIST`）：[https://redis.io/docs/latest/commands/](https://redis.io/docs/latest/commands/) - Redis 官方客户端管理文档（`timeout` 默认不断开空闲连接、`maxclients` 默认 10000、TCP keepalive 300 秒）：[https://redis.io/docs/latest/develop/reference/clients/](https://redis.io/docs/latest/develop/reference/clients/) - 《网络安全等级保护测评高风险判定指引》（中关村信息安全测评联盟团体标准），站内对照表：[22、高风险判定指引与加固对照表](../../其他系统或设备/22高风险判定指引与加固对照表/) - 命令核验说明：本文命令已于 2026-09 对照 redis.io 官方文档（security/ACL/TLS 页、`CONFIG GET`/`ACL`/`SLOWLOG` 命令页）与官方 7.4 版自述 `redis.conf` 逐项核验；四处须留意：① `requirepass` 与 `aclfile` 互斥（官方配置文件原文：同时配置时 requirepass 被忽略），启用 ACL 时不要再用 requirepass；② 键模式 `~pattern` 不限制 `FLUSHALL`/`FLUSHDB` 等无键参数命令，必须用命令规则显式剔除；③ `ACL SETUSER` 对已存在用户是增量修改不是重置（重置须显式 `reset` 规则），先后顺序影响最终权限；④ TLS 为编译期特性（`BUILD_TLS=yes`），自编译部署先用 `redis-server --tls-port 6379 --port 0` 验证支持性，报错 `unknown directive` 即未编译 TLS。`CONFIG SET` 即时生效不落盘，改完必须 `CONFIG REWRITE` 或手工同步 `redis.conf`。 ## 关联文章 - 配套测评：[Redis 缓存数据库测评](../../../gradeProtection/中间件与容器/redis/)、[Memcached 缓存服务测评](../../../gradeProtection/中间件与容器/memcached/)、[Docker 容器运行平台测评](../../../gradeProtection/中间件与容器/docker/)、[Kubernetes 容器编排平台测评](../../../gradeProtection/中间件与容器/kubernetes/) - 同目录：[12、MySQL数据库加固](../12mysql数据库加固/)、[14、PostgreSQL数据库加固](../14postgresql数据库加固/)、[24、Oracle数据库加固](../24oracle数据库加固/)、[25、SQLServer数据库加固](../25sqlserver数据库加固/) - 中间件加固：[21、Web中间件安全加固](../21web中间件安全加固/) - 通用加固方案：[17、加固方案总纲](../../其他系统或设备/17网络设备安全设备服务器数据库和应用系统的加固方案/) - 取证记录：[16、安全评估加固记录表3.0](../../其他系统或设备/16安全评估加固记录表3.0/) - 高风险口径：[22、高风险判定指引与加固对照表](../../其他系统或设备/22高风险判定指引与加固对照表/) - 板块目录：[系统管理软件·平台](../)