视频
您好，Redis 堆栈
了解更多
速度的未来即将在您所在的城市举办的活动中亮相。
加入我们参加 Redis 发布会
分享
Redis Enterprise 6.2.4 引入了节点间加密。Redis Enterprise 中节点间加密的范围是实现所有节点之间内部 Redis 集群连接的 TLS 加密，包括
Redis Enterprise 使用多种技术来优化性能和可用性。Redis 集群使用无共享架构，这提高了可靠性和可用性，并简化了节点的添加和删除。在处理对所有节点间连接进行加密的要求时，团队重点关注可用性和操作简便性。
Redis Enterprise 等分布式、始终在线的系统为许多关键任务应用程序提供支持。它需要满足最高的操作可用性标准。 Redis 云 由 Redis Enterprise 提供支持，提供 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 集群内建立信任。
