视频
你好，Redis Stack
了解更多
Redis 8 已发布——并且是开源的
了解更多
分享
Redis Enterprise 6.2.4 引入了节点间加密。 Redis Enterprise 中节点间加密的范围是实现所有内部 Redis 集群节点之间连接的 TLS 加密，包括
Redis Enterprise 使用多种技术来优化性能和可用性。 Redis 集群使用共享无关架构，从而提高了可靠性和可用性，并使其易于添加和删除节点。 当接近加密所有节点间连接的要求时，该团队专注于可用性和操作简便性。
诸如 Redis Enterprise 之类的分布式、始终在线的系统为许多关键任务应用程序提供支持。 需要满足运营可用性的最高标准。 由 Redis Enterprise 提供支持的 Redis Cloud 提供 99.999% 的可用性，这意味着一年中只能停机几分钟。 节点间集群通信对于维护仲裁（控制路径操作）和启用 Redis 复制（数据路径操作）至关重要。 因此，必须具有高可用性才能始终保持节点间通信的可靠性。
私有证书颁发机构 (CA) 是一个特定于集群的证书颁发机构，其功能类似于公共信任的 CA。 Redis 集群创建其自己的私有根证书，该证书可以为每个节点颁发其他私有证书。 由私有 CA 颁发的私有证书不受公共信任。 私有 CA 不会暴露在集群之外。 私有 CA 不在 Redis 集群之间共享，也不与任何外部客户端或服务共享。 由私有 CA 签名的证书（最终实体证书）是节点专有的。
Redis Enterprise 中使用的私有 CA 提供无缝的内部自轮换机制。 证书轮换将在到期之前自动完成。 也可以通过 REST API 请求完成证书轮换。 应用程序、数据库和安全团队还将提供警报以进行监视。 私有 CA 消除了对外部 CA 可用性的依赖以进行证书轮换，从而消除了潜在的故障点并提高了集群的整体可用性。
Redis Enterprise 通过使用私有证书颁发机构 (CA) 来管理节点间加密所需的证书来实现这一点。 客户通常对使用私有 CA 有以下主要关注点。
第一个担忧实际上并不是安全问题。 这是一个合规性要求。 许多组织编写了全面的策略，完全禁止自签名证书，而没有考虑自签名证书是最佳选择的有效用例。 此要求对于许多实例都是有意义的，但并非全部有意义，并且导致这些组织需要深入的过程来批准不符合全面策略的实例的例外情况。 一个例子是 Redis Enterprise 节点间加密。 在此特定示例中，私有 CA 具有特定用途。
首先，让我们定义一个自签名证书。 自签名证书是指未由公共信任的第三方 CA 签名的证书。 这种类型的证书由负责为其颁发证书的网站或应用程序的组织创建、颁发和签名。 这些证书可以免费颁发和使用与受信任的第三方 CA 颁发的证书相同的密码。
您可能会问自己：“如果一个组织不允许使用自签名证书，那么有什么替代方案？” 典型的替代方案是使用由受信任的第三方 CA 颁发的证书。 组织可以从许多不同的受信任的第三方 CA 购买这些证书，然后将证书颁发给其网站或应用程序。 就安全性而言，由受信任的第三方 CA 颁发的证书与自签名证书相同。
我们应该问的下一个问题是 - 自签名证书和由受信任的第三方 CA 颁发的证书之间有什么区别（如果有）？ 每个证书都支持相同的密码。 每个证书都包含根证书、中间证书和叶证书。 每个证书也可以根据需要过期或吊销。 唯一的区别是自签名证书和由受信任的第三方 CA 颁发的证书之间的功能差异。 该功能就是信任。 受信任的第三方 CA 可以颁发可用于在两个无关实体之间建立信任的证书。
何时需要信任？ 当两个无关实体进行通信时，信任是解决方案的必需部分。 一个很好的例子是 Web 浏览器和 Web 应用程序之间的通信。 使用第三方信任的 CA 颁发的证书允许加密通信，但也让 Web 浏览器知道 Web 应用程序确实是他们自己展示的身份。 因此，如果用户信任 Web 应用程序并希望继续通信，浏览器将提示用户。
何时不需要信任？ 当两个相关实体进行通信时，信任不是解决方案的必需部分。 Redis Enterprise 的节点间加密是这种通信类型的一个很好的例子。 Redis Enterprise 由一个集群组成，单个集群可以包含多个节点。 一个节点上也可以有单个或多个数据库。 因为每个节点都属于同一个集群，所以不需要第三方来建立信任。 每个节点已经信任所有其他节点，因为它们属于同一个集群。
Redis Enterprise 缓解了这些合规性和安全问题，因为私有 CA 生成的证书仅在集群内使用。 因为每个节点都为同一集群中的所有其他节点所知且信任，所以第三方信任的 CA 不会添加任何内容，并且不需要在 Redis 集群中建立信任。
