掌握 Redis 密码配置：从零开始确保数据安全

引言：Redis 的魅力与隐忧

在当今高速发展的数据驱动时代，Redis（Remote Dictionary Server）作为一款高性能的内存键值存储系统，以其卓越的速度、多样化的数据结构和简洁的API，迅速成为缓存、会话管理、实时排行榜、消息队列等场景的明星产品。无数应用程序依赖 Redis 来提升响应速度，处理海量数据。

然而，Redis 的一个“特质”——默认情况下不开启任何认证机制——也为其埋下了巨大的安全隐患。许多开发者在追求速度和便利的同时，往往忽视了其安全性配置。一个未经保护的 Redis 实例，就像一扇洞开的大门，其所有数据都可能被未经授权的访问者随意读取、修改乃至删除。这不仅会导致数据泄露、业务中断，甚至可能被恶意利用，成为勒索软件或挖矿攻击的跳板。

本文旨在为读者提供一份详尽的 Redis 密码配置指南，从最基础的 requirepass 指令，到 Redis 6.0 引入的强大 ACL（访问控制列表）机制，再到传输层安全（TLS/SSL）加密通信，以及网络层面的防护策略。我们将从零开始，一步步构建起一个坚不可摧的 Redis 安全堡垒，确保您的数据万无一失。

第一章：Redis 安全基础：理解默认行为与潜在风险

在深入探讨如何配置密码之前，我们必须理解 Redis 的默认安全状态以及由此带来的潜在风险。

1.1 Redis 的默认安全模式

开箱即用的 Redis 服务器，默认绑定到所有可用网络接口（即 bind 0.0.0.0，在较新版本中已被 protected-mode 限制），且不要求任何密码认证。这意味着，如果您的 Redis 实例部署在公网上，或者其端口（默认 6379）可以通过内网被访问，那么任何知道其 IP 地址和端口的人，都可以不加任何凭证地连接到您的 Redis 实例，执行任何操作，包括：

读取所有数据： 使用 GET, HGETALL, SMEMBERS, LRANGE 等命令获取敏感信息。
修改或删除数据： 使用 SET, DEL, FLUSHALL, FLUSHDB 等命令篡改或清空数据库。
执行危险操作： CONFIG SET 可能会修改服务器配置，SLAVEOF 可能会将其变成恶意服务器的从属，甚至 DEBUG SEGFAULT 可以使服务器崩溃。
成为跳板： 攻击者可能利用 Redis 的 SLAVEOF 命令将您的 Redis 实例变成攻击者的从属，从而进一步扩散攻击。

1.2 `protected-mode`：有限的保护

为了缓解默认配置的风险，Redis 3.2 引入了 protected-mode。当 protected-mode 开启时（默认开启），如果服务器没有配置 bind 地址且没有配置 requirepass，那么它将只允许来自 loopback 地址（如 127.0.0.1）的连接。任何来自非 loopback 地址的连接都将被拒绝。

这在一定程度上阻止了外部未经授权的访问，但它并非万无一失的认证机制。如果您的应用需要从其他服务器连接 Redis，或者您手动禁用了 protected-mode，那么您仍然面临风险。protected-mode 更像是一个紧急刹车，而不是一个完善的认证系统。

1.3 潜在的威胁场景

数据泄露： 存储在 Redis 中的用户个人信息、认证令牌、会话数据等被窃取。
数据篡改与破坏： 恶意分子清空缓存、修改配置、注入有害数据，导致服务不可用或业务逻辑错误。
勒索软件/挖矿攻击： 攻击者通过未受保护的 Redis 写入恶意脚本，进行加密货币挖矿或勒索。
成为僵尸网络的一部分： Redis 服务器被控制，用于发起 DDoS 攻击或扫描其他系统。
合规性问题： 在受监管行业，未受保护的数据库会违反数据隐私和安全法规，导致巨额罚款。

鉴于这些严峻的风险，为 Redis 配置强密码认证是生产环境中不可或缺的第一步。

第二章：核心认证机制：`requirepass` 指令详解

requirepass 是 Redis 提供最基础、最直接的密码认证机制。它要求所有连接到 Redis 服务的客户端在执行任何命令之前，必须先通过 AUTH 命令提供正确的密码。

2.1 `requirepass` 工作原理

当 requirepass 被配置后：

客户端尝试连接到 Redis 服务器。
服务器接受连接，但将该连接标记为“未认证”。
客户端尝试执行任何命令（如 PING, GET key）。
如果客户端尚未认证，服务器将返回 NOAUTH Authentication required. 错误。
客户端必须发送 AUTH <password> 命令。
如果密码正确，连接被标记为“已认证”，客户端可以正常执行命令。
如果密码错误，连接将被关闭。

2.2 如何选择一个强密码

密码是您 Redis 实例的第一道防线，其强度至关重要。一个好的密码应该具备以下特点：

长度： 至少 12 个字符，推荐 16 个或更多。长度是抵御暴力破解最有效的手段。
复杂度： 包含大小写字母、数字和特殊符号（如 !@#$%^&*()-_+=）。
随机性： 避免使用字典词汇、个人信息、常见短语或可预测的模式（如 password123）。
唯一性： 不要与您在其他服务中使用的密码重复。

密码生成工具： 可以使用密码管理器（如 LastPass, 1Password, Bitwarden）自带的密码生成器，或者在线工具。在 Linux/macOS 系统中，您也可以使用 head /dev/urandom | tr -dc A-Za-z0-9\-_@#$! | head -c 32 ; echo 这样的命令来生成随机密码。

2.3 配置 `requirepass` 的步骤

以下是配置 requirepass 的详细步骤：

步骤 1：定位 redis.conf 文件

Redis 的配置文件通常名为 redis.conf。其位置可能因安装方式（源码编译、包管理器、Docker）而异：

源码编译安装： 通常在 /usr/local/etc/redis.conf 或您编译时指定的路径。
包管理器安装（如 apt, yum）： 通常在 /etc/redis/redis.conf 或 /etc/redis.conf。
Docker 容器： 您需要将配置文件挂载到容器内部，或者通过 Dockerfile 构建自定义镜像。

如果您不确定，可以通过 ps -ef | grep redis-server 命令查看 Redis 进程的启动参数，通常会包含 -c /path/to/redis.conf。

步骤 2：编辑 redis.conf 文件

使用您喜欢的文本编辑器（如 vi, nano）打开 redis.conf 文件。

bash sudo vi /etc/redis/redis.conf

在文件中找到 requirepass 指令。它通常会被注释掉（前面有一个 #）。

“`

requirepass foobared

“`

取消注释，并将 foobared 替换为您选择的强密码。

requirepass your_super_strong_password_here

重要提示： 请勿将实际密码直接写在文档中，上述 your_super_strong_password_here 仅为示例。

除了 requirepass，为了进一步加强安全性，您还应该检查并配置 bind 指令。如果 Redis 只需要在本地被访问，将其绑定到本地回环地址：

bind 127.0.0.1

如果您需要从其他服务器访问 Redis（例如在容器化环境中，或应用服务器与 Redis 服务器分离），请将其绑定到 Redis 服务器的私有 IP 地址，而不是 0.0.0.0：

bind 192.168.1.100 # 替换为您的 Redis 服务器的实际私有 IP

同时，确保 protected-mode 处于开启状态（默认是 yes）：

protected-mode yes

保存并关闭文件。

步骤 3：重启 Redis 服务器

为了使配置生效，您需要重启 Redis 服务。具体命令取决于您的操作系统和安装方式。

使用 systemd (大多数 Linux 发行版)：
bash sudo systemctl restart redis-server
或者
bash sudo systemctl restart redis
直接启动/停止 (非 systemd 环境或手动启动)：
bash # 先停止现有进程 sudo killall redis-server # 然后以新配置启动 redis-server /etc/redis/redis.conf # 如果想在后台运行 redis-server /etc/redis/redis.conf --daemonize yes

步骤 4：测试密码配置

重启后，通过 redis-cli 工具测试密码是否生效。

不带密码连接：
bash redis-cli ping # 预期输出：(error) NOAUTH Authentication required.
带密码连接（推荐，直接在命令行指定密码）：
bash redis-cli -a your_super_strong_password_here ping # 预期输出：PONG set mykey "hello" # 预期输出：OK get mykey # 预期输出："hello"
连接后手动认证：
bash redis-cli AUTH your_super_strong_password_here # 预期输出：OK ping # 预期输出：PONG

重要提示： 在生产环境中，应避免在命令行中直接输入密码，这可能会导致密码泄露到历史命令记录或进程列表中。更安全的做法是通过环境变量或配置文件传递密码给客户端程序。

2.4 客户端连接配置

各种编程语言的 Redis 客户端库都支持密码认证。以下是一些常见示例：

Python (使用 redis-py 库):

“`python
import redis

try:
r = redis.Redis(
host=’localhost’,
port=6379,
password=’your_super_strong_password_here’,
decode_responses=True # 自动解码响应为字符串
)
response = r.ping()
print(f”Connected to Redis: {response}”)
r.set(‘python_key’, ‘Hello from Python!’)
print(f”python_key: {r.get(‘python_key’)}”)

except redis.exceptions.ConnectionError as e:
print(f”Could not connect to Redis: {e}”)
except redis.exceptions.AuthenticationError as e:
print(f”Redis authentication failed: {e}”)
“`

Java (使用 Jedis 库):

“`java
import redis.clients.jedis.Jedis;
import redis.clients.jedis.exceptions.JedisConnectionException;
import redis.clients.jedis.exceptions.JedisDataException;

public class RedisAuthExample {
public static void main(String[] args) {
Jedis jedis = null;
try {
jedis = new Jedis(“localhost”, 6379);
jedis.auth(“your_super_strong_password_here”); // 认证
System.out.println(“Connected to Redis!”);
System.out.println(“Server is running: ” + jedis.ping());

        jedis.set("java_key", "Hello from Java!");
        System.out.println("java_key: " + jedis.get("java_key"));

    } catch (JedisConnectionException e) {
        System.err.println("Could not connect to Redis: " + e.getMessage());
    } catch (JedisDataException e) {
        System.err.println("Redis data error (e.g., authentication failed): " + e.getMessage());
    } finally {
        if (jedis != null) {
            jedis.close();
        }
    }
}

}
“`

Node.js (使用 ioredis 库):

“`javascript
const Redis = require(‘ioredis’);

const redis = new Redis({
host: ‘localhost’,
port: 6379,
password: ‘your_super_strong_password_here’
});

redis.on(‘connect’, () => {
console.log(‘Connected to Redis!’);
});

redis.on(‘error’, (err) => {
console.error(‘Redis connection error:’, err);
});

async function runRedisCommands() {
try {
await redis.set(‘nodejs_key’, ‘Hello from Node.js!’);
const value = await redis.get(‘nodejs_key’);
console.log(‘nodejs_key:’, value);
await redis.quit();
} catch (err) {
console.error(‘Error executing Redis commands:’, err);
}
}

runRedisCommands();
“`

通过以上配置和测试，您已经为 Redis 实例设置了基本的密码保护。然而，requirepass 存在一个限制：所有客户端都使用同一个密码，没有细粒度的权限控制。这对于简单的应用来说可能足够，但对于复杂的、多租户或多服务环境，您需要更高级的解决方案——Redis 6.0 引入的 ACL。

第三章：超越 `requirepass`：Redis 6+ 的访问控制列表 (ACL)

Redis 6.0 引入了强大的访问控制列表（ACL），它提供了比 requirepass 更精细、更安全的权限管理机制。通过 ACL，您可以定义多个用户，并为每个用户分配不同的密码和权限，精确控制他们可以执行哪些命令、访问哪些键。

3.1 为什么需要 ACL？

requirepass 的局限性：
* 单一共享密码： 所有连接都使用同一个密码。一旦密码泄露，整个 Redis 实例的安全性都会受到威胁。
* 无细粒度权限： 无法区分用户（例如，一个应用可能只需要读取某些键，而另一个管理工具需要完全控制）。
* 审计困难： 无法知道是哪个用户执行了特定操作。

ACL 解决了这些问题，实现了：
* 多用户： 可以创建多个用户，每个用户有独立的密码。
* 最小权限原则： 为每个用户只授予其完成工作所需的最小权限。
* 键级别控制： 可以指定用户可以访问哪些键（通过模式匹配）。
* 命令级别控制： 可以指定用户可以执行哪些命令（允许/禁止）。
* 连接行为控制： 例如，用户是否可以执行危险命令。

3.2 ACL 的核心概念与语法

ACL 通过定义用户 (user) 来工作，每个用户都有一系列属性：

开关 (on/off)： 启用或禁用用户。
认证凭证 (nopass, >password, #password_hash)： 定义用户的密码。
命令权限 (+command, -command, +@category, -@category)： 允许或禁止执行特定命令或命令类别（如 @read, @write, @admin）。
键权限 (~key_pattern)： 允许用户访问与指定模式匹配的键。
通道权限 (&channel_pattern)： 允许用户订阅/发布与指定模式匹配的通道（用于 Pub/Sub）。

ACL 文件配置 (aclfile)

最推荐的方式是将 ACL 配置写入一个独立的 ACL 文件。

步骤 1：在 redis.conf 中启用 aclfile

打开 redis.conf 文件，找到 aclfile 指令（通常被注释掉）。

“`

aclfile /etc/redis/users.acl

“`

取消注释，并指定一个 ACL 文件的路径。请确保 Redis 用户对该文件有读取权限。

aclfile /etc/redis/users.acl

同时，如果您之前配置了 requirepass，建议将其注释掉或删除。当 aclfile 启用时，requirepass 将仅影响 default 用户（如果 default 用户没有在 aclfile 中明确定义密码）。为了避免混淆，最好在启用 ACL 后移除 requirepass。

步骤 2：创建 users.acl 文件

使用文本编辑器创建 /etc/redis/users.acl 文件。

bash sudo vi /etc/redis/users.acl

示例 ACL 文件内容：

“`acl

这是一个示例 ACL 文件

1. 配置默认用户 (default)

默认用户在 Redis 6.0 中默认是存在的。

默认用户是关闭的，并且没有密码。如果启用，建议设置一个密码。

如果不希望任何人使用 default 用户，可以保持其 off 状态。

user default off >default_secure_password +@all ~*

如果您希望 default 用户只能读取，并且只能访问特定键

user default on >default_read_only_pass +@read ~read: ~cache:

2. 创建一个管理员用户

用户名：admin_user

状态：开启 (on)

密码：使用 SHA-256 哈希值表示，更安全。或者直接使用明文密码（不推荐）。

权限：允许所有命令 (+@all)

键权限：允许访问所有键 (~*)

>admin_password 表示明文密码，如果需要哈希，可以使用 ACL SETUSER 命令生成，然后复制过来。

或者，手动生成哈希（例如：echo -n “your_admin_password” | sha256sum）

这里为了演示方便，先用明文密码。但在生产中，请用哈希。

user admin_user on >your_strong_admin_password +@all ~*

3. 创建一个应用程序用户 (只能读写某些键)

用户名：app_service_user

状态：开启 (on)

密码：>your_app_password

权限：

+@read：允许所有读取命令

+@write：允许所有写入命令

-FLUSHALL -FLUSHDB：禁止执行清空数据库的危险命令

键权限：只能访问以 “app:” 或 “cache:” 开头的键

user app_service_user on >your_app_password +@read +@write -FLUSHALL -FLUSHDB ~app: ~cache:

4. 创建一个只读用户

用户名：read_only_user

状态：开启 (on)

密码：>your_readonly_password

权限：只允许读取命令 (+@read)

键权限：可以读取所有键 (~*)

user read_only_user on >your_readonly_password +@read ~*

5. 创建一个 Pub/Sub 用户

用户名：pubsub_user

状态：开启 (on)

密码：>your_pubsub_password

权限：只允许 PUBLISH, SUBSCRIBE, PSUBSCRIBE 等 Pub/Sub 相关命令

键权限：不能直接访问键，但可以通过 &channel_pattern 访问通道

user pubsub_user on >your_pubsub_password +PUBLISH +SUBSCRIBE +PSUBSCRIBE &events:*
“`

关于密码哈希：
为了更安全，不应直接在 aclfile 中存储明文密码。您可以使用 ACL SETUSER 命令来生成密码哈希，然后将其复制到 aclfile 中。
例如，先用一个临时管理员用户连接 Redis，然后执行：
“`
ACL SETUSER admin_user >new_secure_password

这会输出类似 “OK” 的结果。

此时，您可以通过 `ACL GETUSER admin_user` 或 `ACL LIST` 查看该用户的配置，

找到 `~<hash_algorithm>:<hash_value>` 形式的密码，并将其粘贴到 `aclfile` 中。

比如 `user admin_user on #c7a40... +@all ~*`

`` 在aclfile中，#` 前缀表示密码是哈希值。

步骤 3：重启 Redis 服务器

bash sudo systemctl restart redis-server

步骤 4：测试 ACL 配置

使用 redis-cli 测试不同的用户：

使用管理员用户连接：
bash redis-cli -u admin_user -a your_strong_admin_password ping # 预期输出：PONG set admin_key "admin_value" # 预期输出：OK flushall # 预期输出：OK (管理员可以清空数据库)
使用应用程序用户连接：
bash redis-cli -u app_service_user -a your_app_password ping # 预期输出：PONG set app:data "app_value" # 预期输出：OK get app:data # 预期输出："app_value" set other:data "should_fail" # 预期输出：(error) ERR no key permission for 'other:data' flushall # 预期输出：(error) ERR NOPERM this user has no permissions to run the 'flushall' command
使用只读用户连接：
bash redis-cli -u read_only_user -a your_readonly_password ping # 预期输出：PONG get app:data # 预期输出："app_value" set read_key "should_fail" # 预期输出：(error) ERR command 'set' is not allowed for this user

3.3 动态管理 ACL (不推荐用于生产配置)

除了通过 aclfile 进行配置，您也可以在运行时使用 ACL SETUSER, ACL DELUSER, ACL CAT, ACL LIST 等命令来动态管理用户。然而，这些更改在 Redis 重启后会丢失，除非您使用 ACL SAVE 命令将其写入 ACL 文件。为了持久性和可维护性，强烈建议通过 aclfile 进行管理。

通过 ACL SAVE 持久化动态更改：
如果您确实需要动态修改，记得执行 ACL SAVE 将当前内存中的 ACL 配置写入 aclfile。

bash redis-cli -u admin_user -a your_strong_admin_password ACL SETUSER new_user on >new_user_password +GET ~foo:* ACL SAVE
这样，new_user 的配置就会被写入到 /etc/redis/users.acl 文件中。

第四章：通信加密：TLS/SSL (传输层安全)

密码认证解决了“谁可以连接”的问题，但数据在网络传输过程中仍然可能被监听（中间人攻击）。TLS/SSL（传输层安全，SSL 的继承者）通过加密网络通信，解决了这一问题。

4.1 为什么需要 TLS？

数据保密性： 防止敏感数据在传输过程中被窃听。
数据完整性： 确保数据在传输过程中不被篡改。
身份认证： 通过证书验证客户端和服务器的身份，防止中间人攻击。

从 Redis 6.0 开始，官方原生支持 TLS。

4.2 TLS 配置原理

TLS 配置涉及证书和密钥。通常需要：
* 服务器证书 (tls-cert-file)： 包含服务器的公钥和身份信息。
* 服务器私钥 (tls-key-file)： 服务器用于解密通信和签署数据。
* CA 证书 (tls-ca-cert-file)： 客户端用于验证服务器证书的颁发机构。

您可以选择使用自签名证书（适用于测试或内部网络），或由受信任的证书颁发机构（CA）签发的证书（生产环境推荐）。

4.3 配置 TLS 的步骤

步骤 1：生成 TLS 证书和私钥

这里以自签名证书为例。在生产环境中，您应该从可信 CA 获取证书。

“`bash

1. 创建一个目录用于存放证书

mkdir -p /etc/redis/tls
cd /etc/redis/tls

2. 生成 CA 私钥

openssl genrsa -out ca.key 2048

3. 生成 CA 证书 (用于签发服务器和客户端证书)

openssl req -x509 -new -nodes -key ca.key -sha256 -days 365 -out ca.crt -subj “/C=CN/ST=Guangdong/L=Shenzhen/O=MyOrg/OU=RedisCA/CN=Redis-CA”

4. 生成 Redis 服务器私钥

openssl genrsa -out redis-server.key 2048

5. 生成 Redis 服务器证书签名请求 (CSR)

openssl req -new -key redis-server.key -out redis-server.csr -subj “/C=CN/ST=Guangdong/L=Shenzhen/O=MyOrg/OU=RedisServer/CN=redis.example.com” -addext “subjectAltName=DNS:redis.example.com,IP:127.0.0.1”

6. 使用 CA 证书签署服务器证书

openssl x509 -req -in redis-server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out redis-server.crt -days 365 -sha256 -extfile <(printf “subjectAltName=DNS:redis.example.com,IP:127.0.0.1\nextendedKeyUsage = serverAuth”)

7. (可选) 生成客户端私钥和证书 (如果需要客户端认证)

openssl genrsa -out redis-client.key 2048
openssl req -new -key redis-client.key -out redis-client.csr -subj “/C=CN/ST=Guangdong/L=Shenzhen/O=MyOrg/OU=RedisClient/CN=redis.client.com”
openssl x509 -req -in redis-client.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out redis-client.crt -days 365 -sha256 -extfile <(printf “extendedKeyUsage = clientAuth”)

确保证书和私钥权限设置正确，只有 Redis 用户可读

sudo chmod 600 ca.key redis-server.key redis-client.key
“`

步骤 2：在 redis.conf 中配置 TLS

打开 redis.conf 文件，添加或修改以下配置：

“`conf

开启 TLS 端口 (默认是 6379，TLS 端口可以是另一个)

tls-port 默认与 port 相同，如果您希望 Redis 同时监听明文和 TLS 端口，

可以设置 port 为 6379，tls-port 为 6380

port 0 # 禁用明文端口，只启用 TLS 端口
tls-port 6379 # 或者 6380, 推荐使用单独的端口

tls-cert-file /etc/redis/tls/redis-server.crt
tls-key-file /etc/redis/tls/redis-server.key
tls-ca-cert-file /etc/redis/tls/ca.crt

是否要求客户端也提供证书进行认证

yes：双向认证，客户端必须提供由 CA 签名的证书

no：单向认证，客户端不需要证书，但仍会加密通信

tls-auth-clients yes # 生产环境推荐

允许的 TLS 版本

tls-protocols “TLSv1.2 TLSv1.3”

密码套件 (推荐使用强密码套件)

tls-ciphers “HIGH:!aNULL:!MD5”
“`

如果您希望同时支持明文和 TLS 连接，可以将 port 设置为 6379，并设置 tls-port 为一个不同的端口，例如 6380。

步骤 3：重启 Redis 服务器

bash sudo systemctl restart redis-server

步骤 4：测试 TLS 连接

使用 redis-cli 测试 (需要 Redis 6.0+):
“`bash
# 如果是单向认证 (tls-auth-clients no):
redis-cli –tls –cacert /etc/redis/tls/ca.crt -h 127.0.0.1 -p 6379 -u admin_user -a your_strong_admin_password
ping
# 预期输出：PONG

如果是双向认证 (tls-auth-clients yes):

redis-cli –tls \
–cacert /etc/redis/tls/ca.crt \
–cert /etc/redis/tls/redis-client.crt \
–key /etc/redis/tls/redis-client.key \
-h 127.0.0.1 -p 6379 -u admin_user -a your_strong_admin_password
ping

预期输出：PONG

“`
使用 openssl 客户端测试 (验证 TLS 握手):
“`bash
# 如果是单向认证：
openssl s_client -connect 127.0.0.1:6379 -CAfile /etc/redis/tls/ca.crt
# 如果握手成功，会看到证书信息，然后可以手动输入 Redis 命令
# AUTH admin_user your_strong_admin_password
# PING

如果是双向认证：

openssl s_client -connect 127.0.0.1:6379 \
-CAfile /etc/redis/tls/ca.crt \
-cert /etc/redis/tls/redis-client.crt \
-key /etc/redis/tls/redis-client.key

同样，握手成功后可以输入 Redis 命令

“`

4.4 客户端连接 TLS 配置

Python (使用 redis-py 库):

“`python
import redis

try:
r = redis.Redis(
host=’localhost’,
port=6379,
password=’your_strong_admin_password’,
username=’admin_user’, # Redis 6.0 ACL 用户名
ssl=True,
ssl_ca_certs=’/etc/redis/tls/ca.crt’, # CA 证书
# 如果是双向认证，还需要提供客户端证书和私钥
ssl_certfile=’/etc/redis/tls/redis-client.crt’,
ssl_keyfile=’/etc/redis/tls/redis-client.key’,
decode_responses=True
)
response = r.ping()
print(f”Connected to Redis via TLS: {response}”)
r.set(‘tls_key’, ‘Hello from TLS Python!’)
print(f”tls_key: {r.get(‘tls_key’)}”)

except redis.exceptions.ConnectionError as e:
print(f”Could not connect to Redis: {e}”)
except redis.exceptions.AuthenticationError as e:
print(f”Redis authentication failed: {e}”)
except Exception as e:
print(f”An unexpected error occurred: {e}”)
“`

第五章：网络安全与最佳实践

除了 Redis 自身的认证和加密机制，网络层面的安全防护同样至关重要，它构成了 Redis 安全的最后一道防线。

5.1 防火墙配置

作用： 限制只有受信任的 IP 地址才能访问 Redis 端口。
实践：
* Linux (UFW/iptables):
bash # 假设 Redis 监听 6379 端口，并且应用服务器 IP 是 192.168.1.10 sudo ufw allow from 192.168.1.10 to any port 6379 sudo ufw enable # 或者对于 iptables sudo iptables -A INPUT -p tcp --dport 6379 -s 192.168.1.10 -j ACCEPT sudo iptables -A INPUT -p tcp --dport 6379 -j DROP # 拒绝其他所有连接
* 云服务商安全组/网络 ACL： 在 AWS Security Groups, Azure Network Security Groups, Google Cloud Firewall Rules 中，配置只允许特定来源 IP 地址（例如应用服务器的 IP）访问 Redis 实例的端口。

5.2 `bind` 指令与网络隔离

bind 127.0.0.1： 如果 Redis 只需在本地服务器上被访问，这是最安全的配置。
bind <private_ip_address>： 如果 Redis 需要被同一私有网络中的其他服务器访问，将其绑定到 Redis 服务器的私有 IP 地址。
避免 bind 0.0.0.0： 在没有强大认证和防火墙规则的情况下，永远不要将 Redis 绑定到 0.0.0.0，这会使它监听所有网络接口，包括公网。
网络隔离： 将 Redis 实例部署在独立的私有子网中，并通过严格的网络策略限制其与外界的通信。

5.3 `protected-mode` 再强调

即使您配置了密码，也请确保 protected-mode yes。它作为额外的安全层，可以在某些配置错误的情况下提供基础保护。

5.4 操作系统安全

及时更新： 保持操作系统和 Redis 软件包的最新版本，修补已知的安全漏洞。
最小化安装： 在 Redis 服务器上只安装必要的软件，减少攻击面。
非 root 用户运行 Redis： 以低权限用户运行 Redis 服务，即使被攻破，也能限制攻击者的破坏范围。
禁用不必要的服务： 关闭服务器上所有不必要的服务和端口。
日志监控： 启用 Redis 和操作系统的日志记录，并定期审计，检查异常访问或错误。

5.5 密码管理与轮换

密码管理器： 使用专业的密码管理器存储和管理 Redis 密码。
定期轮换： 定期（例如每 3-6 个月）更改 Redis 密码和 ACL 用户密码。
保密： 绝不将密码硬编码在代码中，使用环境变量、配置文件或秘密管理服务（如 HashiCorp Vault, AWS Secrets Manager）来存储和获取密码。

5.6 审计与监控

Redis 日志： 配置 Redis 日志级别，记录认证失败、危险命令执行等事件。
慢日志 (Slow Log)： 记录执行时间超过阈值的命令，可能有助于发现异常行为。
安全信息和事件管理 (SIEM)： 将 Redis 日志集成到 SIEM 系统，进行集中分析和异常检测。

第六章：Redis 架构中的安全考量 (集群/哨兵)

在复杂的 Redis 部署（如 Redis Sentinel 高可用架构或 Redis Cluster 分布式集群）中，安全配置需要考虑所有组件。

6.1 Redis Sentinel 高可用架构

在 Sentinel 架构中，您有多个 Redis Master/Slave 实例和多个 Sentinel 实例。

所有 Redis 实例： 每个 Master 和 Slave 都必须独立配置 requirepass (或 ACL) 和 TLS。Sentinel 在连接这些 Redis 实例时需要提供正确的密码。
所有 Sentinel 实例：
- sentinel auth-pass <master-name> <password>：Sentinel 在连接 Master 和 Slave 实例时使用的密码。
- sentinel requirepass <password>：如果需要保护 Sentinel 自身的 API（虽然不常用，但如果 Sentinel 端口暴露，可以考虑）。
一致性： 确保所有 Redis 实例和所有 Sentinel 实例的密码配置保持一致。如果 Master 的密码改变，所有 Slave 和 Sentinel 都需要更新配置。

6.2 Redis Cluster 分布式集群

在 Redis Cluster 中，所有节点都是 Master，共同分担数据。

所有集群节点： 每个节点都必须配置 requirepass (或 ACL) 和 TLS。redis-cli -c 在连接集群时，如果遇到重定向，会自动连接到新的节点，因此所有节点都需要相同的认证凭证。
集群总线 (Cluster Bus)： 集群节点之间通过 Cluster Bus 进行通信。在 Redis 6.0+ 中，Cluster Bus 也可以通过 TLS 进行加密 (cluster-announce-tls-port 等指令)。如果您的集群部署在不安全的网络中，强烈建议为 Cluster Bus 启用 TLS。

第七章：故障排除与常见问题

在配置 Redis 密码时，可能会遇到一些常见问题。

7.1 `(error) NOAUTH Authentication required.`

原因： 客户端尝试执行命令而未进行认证。
解决方案：
- 确保客户端在连接后立即发送 AUTH <password>。
- 使用 redis-cli -a <password> 或在客户端库中配置密码。
- 如果使用 ACL，确保提供了正确的用户名和密码 (redis-cli -u <user> -a <password>)。

7.2 Redis 服务器无法启动

原因： redis.conf 文件中存在语法错误，或者证书/密钥文件权限问题。
解决方案：
- 检查 Redis 启动日志 (通常在 /var/log/redis/redis-server.log 或 journalctl -u redis-server)，查找具体的错误信息。
- 仔细检查 redis.conf 和 users.acl 文件中的拼写、语法和格式。
- 确保 Redis 运行用户对证书和密钥文件有读取权限，且权限设置正确 (例如 chmod 600)。

7.3 客户端无法连接 (`Connection refused` / `timeout`)

原因：
1. 防火墙阻止了连接。
2. Redis 没有绑定到正确的 IP 地址或端口。
3. Redis 服务未运行。
4. TLS 配置问题。
解决方案：
- 检查防火墙规则，确保客户端 IP 地址被允许访问 Redis 端口。
- 检查 redis.conf 中的 bind 和 port/tls-port 配置。
- 确认 Redis 服务正在运行 (sudo systemctl status redis-server)。
- 如果启用了 TLS，确认客户端和服务器的 TLS 配置（证书、CA 证书、客户端认证）匹配。

7.4 `(error) ERR unknown user or wrong password` (ACL 相关)

原因：
1. 提供的用户名或密码错误。
2. ACL 文件中的用户配置有误。
3. Redis 没有正确加载 ACL 文件。
解决方案：
- 仔细检查客户端连接时使用的用户名和密码。
- 检查 aclfile 路径是否正确，Redis 用户是否有读取权限。
- 查看 Redis 日志，确认 ACL 文件是否成功加载。
- 使用 ACL LIST 命令查看当前 Redis 实例中所有用户的配置。

7.5 `(error) NOPERM` 或 `ERR command is not allowed for this user` (ACL 相关)

原因： 当前用户没有执行该命令或访问该键的权限。
解决方案：
- 检查 users.acl 文件中该用户的命令权限 (+command, -command, +@category) 和键权限 (~key_pattern)。
- 遵循最小权限原则，只授予用户所需的最少权限。

结论：持续的安全旅程

掌握 Redis 密码配置，从 requirepass 到 ACL，再到 TLS 加密，是我们确保数据安全的重要基石。然而，安全是一个持续不断的过程，需要多层次的防护和警惕。

总结关键点：

绝不裸奔： 永远不要让 Redis 在没有认证的情况下暴露。
强密码： 使用复杂、随机且足够长的密码。
ACL 优先： 对于 Redis 6.0+，优先使用 ACL 实现细粒度的权限控制和最小权限原则。
TLS 加密： 在任何跨网络通信的场景下，务必启用 TLS 加密，保护数据在传输中的安全。
网络隔离： 配合防火墙和 bind 指令，限制 Redis 的网络可达性。
系统级安全： 及时更新、非 root 运行、日志审计等操作系统层面的安全实践不可忽视。
一致性： 在 Redis Sentinel 或 Cluster 架构中，确保所有组件的安全配置一致。

通过将这些技术和实践结合起来，您将能够为您的 Redis 实例构建一个强大、多层次的安全防护体系，从而确保数据安全，为您的应用程序提供稳定可靠的后端支持。记住，安全防护永远不是一劳永逸的事情，持续的审查和改进是确保数据资产安全的唯一途径。

掌握 Redis 密码配置：从零开始确保数据安全

引言：Redis 的魅力与隐忧

第一章：Redis 安全基础：理解默认行为与潜在风险

1.1 Redis 的默认安全模式

1.2 protected-mode：有限的保护

1.3 潜在的威胁场景

第二章：核心认证机制：requirepass 指令详解

2.1 requirepass 工作原理

2.2 如何选择一个强密码

2.3 配置 requirepass 的步骤

requirepass foobared

2.4 客户端连接配置

第三章：超越 requirepass：Redis 6+ 的访问控制列表 (ACL)

3.1 为什么需要 ACL？

3.2 ACL 的核心概念与语法

aclfile /etc/redis/users.acl

这是一个示例 ACL 文件

1. 配置默认用户 (default)

默认用户在 Redis 6.0 中默认是存在的。

默认用户是关闭的，并且没有密码。如果启用，建议设置一个密码。

如果不希望任何人使用 default 用户，可以保持其 off 状态。

如果您希望 default 用户只能读取，并且只能访问特定键

user default on >default_read_only_pass +@read ~read: ~cache:

2. 创建一个管理员用户

用户名：admin_user

状态：开启 (on)

密码：使用 SHA-256 哈希值表示，更安全。或者直接使用明文密码（不推荐）。

权限：允许所有命令 (+@all)

键权限：允许访问所有键 (~*)

>admin_password 表示明文密码，如果需要哈希，可以使用 ACL SETUSER 命令生成，然后复制过来。

或者，手动生成哈希（例如：echo -n “your_admin_password” | sha256sum）

这里为了演示方便，先用明文密码。但在生产中，请用哈希。

3. 创建一个应用程序用户 (只能读写某些键)

用户名：app_service_user

状态：开启 (on)

密码：>your_app_password

权限：

+@read：允许所有读取命令

+@write：允许所有写入命令

-FLUSHALL -FLUSHDB：禁止执行清空数据库的危险命令

键权限：只能访问以 “app:” 或 “cache:” 开头的键

4. 创建一个只读用户

用户名：read_only_user

状态：开启 (on)

密码：>your_readonly_password

权限：只允许读取命令 (+@read)

键权限：可以读取所有键 (~*)

5. 创建一个 Pub/Sub 用户

用户名：pubsub_user

状态：开启 (on)

密码：>your_pubsub_password

权限：只允许 PUBLISH, SUBSCRIBE, PSUBSCRIBE 等 Pub/Sub 相关命令

键权限：不能直接访问键，但可以通过 &channel_pattern 访问通道

这会输出类似 “OK” 的结果。

此时，您可以通过 ACL GETUSER admin_user 或 ACL LIST 查看该用户的配置，

找到 ~<hash_algorithm>:<hash_value> 形式的密码，并将其粘贴到 aclfile 中。

比如 user admin_user on #c7a40... +@all ~*

3.3 动态管理 ACL (不推荐用于生产配置)

第四章：通信加密：TLS/SSL (传输层安全)

4.1 为什么需要 TLS？

4.2 TLS 配置原理

4.3 配置 TLS 的步骤

1. 创建一个目录用于存放证书

2. 生成 CA 私钥

3. 生成 CA 证书 (用于签发服务器和客户端证书)

4. 生成 Redis 服务器私钥

5. 生成 Redis 服务器证书签名请求 (CSR)

6. 使用 CA 证书签署服务器证书

7. (可选) 生成客户端私钥和证书 (如果需要客户端认证)

确保证书和私钥权限设置正确，只有 Redis 用户可读

开启 TLS 端口 (默认是 6379，TLS 端口可以是另一个)

tls-port 默认与 port 相同，如果您希望 Redis 同时监听明文和 TLS 端口，

可以设置 port 为 6379，tls-port 为 6380

是否要求客户端也提供证书进行认证

yes：双向认证，客户端必须提供由 CA 签名的证书

no：单向认证，客户端不需要证书，但仍会加密通信

允许的 TLS 版本

密码套件 (推荐使用强密码套件)

如果是双向认证 (tls-auth-clients yes):

预期输出：PONG

1.2 `protected-mode`：有限的保护

第二章：核心认证机制：`requirepass` 指令详解

2.1 `requirepass` 工作原理

2.3 配置 `requirepass` 的步骤

第三章：超越 `requirepass`：Redis 6+ 的访问控制列表 (ACL)

此时，您可以通过 `ACL GETUSER admin_user` 或 `ACL LIST` 查看该用户的配置，

找到 `~<hash_algorithm>:<hash_value>` 形式的密码，并将其粘贴到 `aclfile` 中。

比如 `user admin_user on #c7a40... +@all ~*`

5.2 `bind` 指令与网络隔离

5.3 `protected-mode` 再强调

7.1 `(error) NOAUTH Authentication required.`

7.3 客户端无法连接 (`Connection refused` / `timeout`)

7.4 `(error) ERR unknown user or wrong password` (ACL 相关)

7.5 `(error) NOPERM` 或 `ERR command is not allowed for this user` (ACL 相关)

发表评论取消回复