异常教程

Redis 安全（保姆级教程）

更新时间:

💡一则或许对你有用的小广告

欢迎加入小哈的星球 ，你将获得：专属的项目实战 / 1v1 提问 / Java 学习路线 / 学习打卡 / 每月赠书 / 社群讨论

截止目前， 星球 内专栏累计输出 90w+ 字，讲解图 3441+ 张，还在持续爆肝中.. 后续还会上新更多项目，目标是将 Java 领域典型的项目都整一波，如秒杀系统, 在线商城, IM 即时通讯，权限管理，Spring Cloud Alibaba 微服务等等，已有 3100+ 小伙伴加入学习 ，欢迎点击围观

前言

在现代互联网应用中，Redis 作为高性能的内存数据库，因其快速读写和丰富的数据结构支持，被广泛应用于缓存、消息队列、实时计数器等场景。然而，Redis 的默认配置和使用中的安全疏漏，可能导致数据泄露、服务中断甚至被恶意利用。本文将从 Redis 安全 的核心问题出发，通过实际案例和代码示例，为编程初学者和中级开发者提供系统性指导，帮助读者构建更安全的 Redis 环境。

默认配置的安全隐患

Redis 在安装后默认采用 无密码验证模式，且监听所有网络接口。这种设计虽然方便了快速测试，但也为攻击者提供了可乘之机。

比喻：未上锁的仓库

想象 Redis 是一个存放重要货物的仓库，而默认配置相当于仓库大门未上锁。攻击者只需知道仓库的位置（IP 地址），就能自由进出并操作货物（数据）。

典型案例

2016 年，全球范围内大量 Redis 服务器因未配置密码，导致数据被恶意删除或加密勒索。攻击者利用 Shodan 等工具扫描开放的 Redis 端口（默认 6379），直接执行 FLUSHALL 命令清空数据库。

解决方案：基础安全配置

通过修改配置文件 redis.conf，设置以下参数：

requirepass your_secure_password  

bind 127.0.0.1  

protected-mode no

验证配置

重启 Redis 后，尝试未授权连接会返回错误：

$ redis-cli  
127.0.0.1:6379> keys *  
(error) NOAUTH Authentication required.

访问控制：从粗放转向精细

随着 Redis 版本的迭代（如 Redis 6.0 引入 ACL 功能），访问控制从“全局密码”升级为“基于用户的角色权限管理”。

ACL：为不同角色“分配钥匙”

比喻：仓库管理员、普通员工和访客需要不同的钥匙权限。管理员可操作所有区域，而访客只能查看特定区域。

示例：创建不同权限用户

user admin on ~* +@all password admin_password  

user guest on ~guest: +get +set password guest_password

代码验证

$ redis-cli -a admin_password  
127.0.0.1:6379> ACL LIST  
1) "user admin on >0 <0 ~* &* +@all password [...] flags:~[...]  
2) "user guest on >0 <0 ~guest: &* +get +set password [...] flags:~[...]

数据加密：传输与存储的双重保护

传输加密：SSL/TLS 的“密码锁”

Redis 从 6.2 版本开始支持 SSL/TLS，确保客户端与服务器之间的通信数据被加密。

配置步骤

  1. 生成 SSL 证书（示例使用 OpenSSL）： 
    openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365 -nodes
  2. 修改配置文件启用 SSL： 
    port 6379  
tls-port 6380  
tls-cert-file cert.pem  
tls-key-file key.pem

客户端连接示例

import redis  
client = redis.Redis(  
    host='localhost',  
    port=6380,  
    ssl=True,  
    ssl_certfile='cert.pem',  
    ssl_keyfile='key.pem'  
)

存储加密：敏感数据的“保险箱”

对于存储在 Redis 中的敏感数据（如密码、令牌），建议在应用层加密后再存储。例如：

from cryptography.fernet import Fernet  

key = Fernet.generate_key()  
cipher = Fernet(key)  

encrypted = cipher.encrypt(b"Sensitive Data")  
redis.set("secret_key", encrypted)  

encrypted_data = redis.get("secret_key")  
decrypted = cipher.decrypt(encrypted_data)

日志与审计：追踪操作的“监控摄像头”

配置日志记录

通过修改 redis.conf 开启日志功能：

appendonly yes  

loglevel notice

审计实践：检测异常行为

定期分析日志文件，寻找以下可疑模式：

  • 频繁的 FLUSHDB 或 DEL 命令
  • 非工作时间的高频率写入
  • 未授权用户的登录尝试

日志示例片段

2023-10-05T14:22:33.321568* Connecting to ::1:6379  
2023-10-05T14:22:33.322010* Connection accepted  
2023-10-05T14:22:33.322037* Client returned cleanup: 10  
2023-10-05T14:22:33.322041* Connection closing on forced user abort

常见攻击与防御策略

未授权访问攻击

攻击者利用开放的 Redis 端口执行恶意命令，例如：

redis-cli CONFIG SET dir /tmp  
redis-cli CONFIG SET dbfilename "exploit.sh"  
redis-cli save

防御方法：严格配置 bind 和 requirepass，并限制文件系统权限。

资源耗尽攻击

攻击者通过大量创建键值对（如 SET key_{1..1000000} value），导致内存溢出。
防御方法：

  • 设置最大内存限制 maxmemory 1gb
  • 启用淘汰策略 maxmemory-policy allkeys-lru

最佳实践与工具推荐

安全检查清单

检查项操作步骤
密码验证确保 requirepass 已配置，且密码复杂度符合规范
网络隔离使用 bind 绑定内网 IP，避免暴露在公网
版本更新升级到 Redis 6.x 以上，利用新特性（如 ACL、SSL）
定期审计每月检查日志，扫描未授权访问记录

工具辅助

  • Redis-benchmarks-suite：自动化安全测试工具
  • Redis-trib.rb：集群模式下的配置与监控辅助工具

结论

Redis 安全 是一个系统性工程，需要从配置加固、访问控制、数据加密到日志审计全方位考虑。对于开发者而言，养成“安全第一”的编码习惯至关重要：例如在设计缓存方案时，优先验证用户身份；在存储敏感数据时，优先加密后再写入。通过本文的实践指南和案例分析，读者可以逐步构建一个抵御常见攻击的 Redis 环境，为业务的稳定运行提供保障。

提示：本文内容可作为 Redis 安全配置的参考手册，建议读者根据实际业务场景调整具体参数。

最新发布

查看更多文章