保护 Redis：密码设置详解 – wiki基地

作者： /

保护 Redis：密码设置详解

Redis 作为一个高性能的键值存储数据库，广泛应用于缓存、会话存储、消息队列等场景。然而，由于其速度和灵活性，Redis 也很容易成为攻击目标，尤其是当它未经适当保护而暴露在不可信网络中时。数据泄露、服务中断或数据篡改都可能带来严重后果。因此，对 Redis 实例进行安全加固是部署和维护 Redis 的首要任务之一，其中最基础也是最关键的一步就是设置密码。

本文将详细探讨 Redis 的密码设置方法，包括传统的 requirepass 指令、客户端认证的 AUTH 命令，以及 Redis 6.0 引入的更强大的 ACLs（访问控制列表），并提供一些密码安全最佳实践。

1. requirepass：传统密码保护

requirepass 是 Redis 早期版本以及当前版本中仍然支持的一种密码认证机制。它通过在 Redis 配置文件中设置一个全局密码，要求所有连接的客户端在执行任何命令之前必须提供此密码进行认证。

如何配置 requirepass

  1. 定位 redis.conf 文件
    Redis 的配置文件通常名为 redis.conf。在 Linux 系统上，它可能位于 /etc/redis/redis.conf 或 Redis 安装目录下。

  2. 编辑 redis.conf 文件
    使用文本编辑器打开 redis.conf 文件。搜索 requirepass 关键字。默认情况下，这一行通常被注释掉，并且可能包含一个示例值，例如 requirepass foobared。

  3. 设置您的密码
    取消 requirepass 行的注释，并将其后的 foobared（或任何占位符）替换为您选择的强密码。

    “`ini

    requirepass foobared

    requirepass your_very_strong_and_secret_password
    “`

    请务必将 your_very_strong_and_secret_password 替换为实际的复杂密码。

  4. 重启 Redis 服务器
    保存 redis.conf 文件后，您需要重启 Redis 服务器，以使配置更改生效。
    例如（根据您的系统和 Redis 安装方式可能有所不同）：

    “`bash
    sudo systemctl restart redis # For systemd-based systems

    或者

    redis-cli shutdown
    redis-server /path/to/redis.conf
    “`

动态设置 requirepass (不推荐用于持久化)

您也可以通过 redis-cli 客户端动态设置密码，无需重启服务器：

bash
redis-cli
127.0.0.1:6379> CONFIG SET requirepass "new_strong_password"
OK

重要提示： 使用 CONFIG SET 命令设置的密码不会持久化到 redis.conf 文件中。这意味着，如果 Redis 服务器重启，您通过 CONFIG SET 设置的密码将丢失，除非您手动将其添加到 redis.conf 并保存。为了确保密码的持久性，强烈建议通过编辑 redis.conf 文件来设置 requirepass。

requirepass 的局限性

requirepass 的主要局限性在于它提供了一个全局的、单一的密码。所有客户端都使用相同的密码进行连接，这在以下情况下会带来不便和安全风险：

  • 权限管理缺失： 无法为不同的应用程序或用户分配不同的访问权限。所有通过认证的客户端都拥有对 Redis 实例的完全访问权限。
  • 密码轮换困难： 如果需要更改密码，所有连接的应用程序都需要同时更新其配置，否则会导致服务中断。
  • 安全审计： 难以追踪特定操作是由哪个客户端执行的。

鉴于这些局限性，从 Redis 6.0 版本开始，引入了更强大的 ACLs。

2. AUTH 命令：客户端认证

当 Redis 实例配置了密码保护后，客户端在连接到服务器后，需要使用 AUTH 命令提供正确的密码才能执行其他操作。

AUTH 命令的使用

一旦客户端连接到 Redis 服务器，但尚未认证，它尝试执行任何命令（除了 AUTH 本身）都将收到一个错误，例如 (error) NOAUTH Authentication required.。

要进行认证，客户端应发送 AUTH 命令，后跟配置的密码：

AUTH your_password

如果密码正确，服务器会回复 OK，客户端便可以开始正常执行 Redis 命令。如果密码不正确，服务器会回复错误，并且客户端将无法执行任何命令。

示例 (redis-cli)：

假设您的 Redis 实例密码设置为 mysecretpassword。

  1. 连接到 Redis (未认证)
    bash
    redis-cli
    127.0.0.1:6379> PING
    (error) NOAUTH Authentication required.

  2. 使用 AUTH 命令认证
    bash
    127.0.0.1:6379> AUTH mysecretpassword
    OK

  3. 认证成功后执行命令
    bash
    127.0.0.1:6379> PING
    PONG
    127.0.0.1:6379> SET mykey "hello"
    OK
    127.0.0.1:6379> GET mykey
    "hello"

3. Redis 6.0 及更高版本：ACLs (Access Control Lists)

Redis 6.0 引入了访问控制列表（ACLs），这是一个革命性的改进，它提供了比 requirepass 更加精细和灵活的权限管理功能。ACLs 允许您：

  • 创建多个用户： 每个用户都可以有独立的用户名和密码。
  • 分配特定权限： 可以控制每个用户可以执行哪些命令、访问哪些键模式。
  • 禁用或重命名命令： 可以针对特定用户禁用或重命名危险命令。

通过 ACLs，您可以为不同的应用程序或微服务创建具有最小必要权限的用户，从而大大增强 Redis 实例的安全性。例如，您可以创建一个只允许读取特定键的用户，或者一个只能执行 LPUSH 和 RPOP 命令的用户用于队列操作。

虽然本文主要聚焦于密码设置，但对于新部署的 Redis 6.0 及更高版本，强烈建议使用 ACLs 来取代或补充 requirepass，以实现更强大的安全策略。ACLs 的配置涉及 aclfile 和 ACL 命令，这超出了本文的范围，但它是现代 Redis 安全的最佳实践。

4. 密码安全最佳实践

无论您是使用 requirepass 还是 ACLs，以下密码安全最佳实践都至关重要：

  • 使用强密码：

    • 长度： 密码应足够长，至少 12-16 个字符，最好更长。
    • 复杂度： 包含大小写字母、数字和特殊字符。
    • 随机性： 避免使用字典词汇、个人信息或常见的序列。使用密码管理器生成随机密码是最佳选择。
    • 唯一性： 不要将 Redis 密码与任何其他服务的密码重复使用。

  • 避免硬编码敏感信息：
    不要将 Redis 密码直接硬编码在应用程序代码中。应将其存储在：

    • 环境变量中： 在部署环境中通过环境变量注入密码。
    • 秘密管理服务中： 使用 HashiCorp Vault、AWS Secrets Manager、Azure Key Vault 等专业秘密管理工具。
    • 安全的配置文件中： 确保配置文件受到严格的权限控制，并且不被版本控制系统追踪。

  • 定期更换密码：
    建立密码轮换策略，定期更新 Redis 密码，即使没有发现安全事件。这有助于降低因长期使用同一密码而产生的风险。

5. 其他重要的安全措施 (超越密码)

虽然密码保护是基础，但它只是 Redis 安全策略的一部分。为了全面保护您的 Redis 实例，您还应该考虑以下措施：

  • 网络限制 (bind 指令与防火墙)：

    • bind 指令： 在 redis.conf 中，使用 bind 127.0.0.1（仅允许本地连接）或 bind your_server_ip（仅允许指定 IP 连接）来限制 Redis 监听的网络接口。永远不要将 Redis 绑定到 0.0.0.0 并将其直接暴露在公网中。
    • 防火墙： 配置服务器防火墙（如 iptables、firewalld 或云服务商的安全组）只允许来自可信 IP 地址的连接访问 Redis 端口（默认为 6379）。

  • 保护模式 (Protected Mode)：
    Redis 3.2 及更高版本默认启用“保护模式”。如果 Redis 绑定到所有接口 (0.0.0.0) 且没有设置密码，它将只响应来自本地回环接口 (127.0.0.1) 的请求。这是一种安全机制，旨在防止未经保护的 Redis 实例意外暴露在网络中。如果您明确知道自己在做什么，并且已经采取了其他安全措施，可以禁用此模式，但默认开启是更安全的。

  • 重命名或禁用危险命令：
    某些 Redis 命令（如 FLUSHALL、FLUSHDB、CONFIG、KEYS 等）在生产环境中可能非常危险，因为它们可能导致数据丢失或信息泄露。您可以在 redis.conf 中使用 rename-command 或直接禁用这些命令。
    例如：
    ini
    rename-command CONFIG "" # 禁用 CONFIG 命令
    rename-command FLUSHALL "VERYDANGEROUS_FLUSHALL" # 重命名 FLUSHALL

  • TLS/SSL 加密：
    对于传输敏感数据的场景，应启用 TLS/SSL 来加密客户端与 Redis 服务器之间的数据传输，防止中间人攻击和数据窃听。Redis 6.0 及更高版本原生支持 TLS。

  • 最小权限原则：
    运行 Redis 服务器的操作系统用户应该是一个非特权用户，并且只拥有执行 Redis 进程所需的最小文件系统权限。

  • 日志与监控：
    配置详细的 Redis 日志，并集成到集中式日志系统进行监控。异常的连接尝试、认证失败或不寻常的命令模式都可能是安全事件的预警。

结论

保护 Redis 实例的安全性是一个多层面的任务，而密码设置是其中最基础且不可或缺的一环。通过正确配置 requirepass 或更先进的 ACLs，并结合强大的密码策略，您可以显著降低 Redis 实例面临的风险。然而，请记住，密码只是防线的一部分；结合网络限制、传输加密和最小权限原则等其他安全措施，才能构建一个健壮且安全的 Redis 环境。在任何生产环境中，请务必投入足够的时间和精力来规划和实施全面的 Redis 安全策略。

滚动至顶部