节点间加密

描述节点间加密，它提高了传输中数据的安全性。

Redis 企业软件

从 v6.2.4 开始，Redis Enterprise Software 支持节点间加密，即对节点之间的内部通信进行加密。这提高了数据在集群内传输时的安全性。

为管理集群及其数据库的控制层面启用了节点间加密。

数据层面支持节点间加密，该数据层面对用于在节点之间复制分片的通信以及与位于不同节点上的分片的代理通信进行加密。

下图显示了其工作原理。

显示数据节点间加密、控制平面加密和集群各种元素之间交互的图表。

默认情况下，单个数据库的数据节点间加密处于禁用状态，以便优化性能。加密会增加延迟和开销;影响是可衡量的，并且根据数据库、其字段类型以及底层使用案例的详细信息而有所不同。

您可以通过更改数据库配置设置来为数据库启用数据节点间加密。这使您可以选择何时优先使用性能以及何时加密数据。

先决条件

节点间加密需要某些先决条件。

您需要：

  • 将集群中的所有节点升级到 v6.2.4 或更高版本。

  • 为用于加密通信的 TLS 通道打开端口 3342。

启用数据节点间加密

要为数据库启用节点间加密（也称为数据节点间加密），您需要为要加密的每个数据库启用适当的设置。为此，您可以：

  • 使用集群管理器 UI 从数据库 Security 屏幕启用 Internode Encryption 设置。

  • 使用rladmin命令行实用程序来设置数据库的 data_internode_encryption 设置：

    rladmin tune db <database_id> data_internode_encryption enabled

  • Use the Redis Enterprise Software REST API to set the data_internode_encryption setting for the database.

    put /v1/bdbs/${database_id}
{ “data_internode_encryption” : true }

When you change the data internode encryption setting for a database, all active remote client connections are disconnected. This restarts the internal (DMC) proxy and disconnects all client connections.

Change cluster policy

To enable internode encryption for new databases by default, use one of the following methods:

  • Cluster Manager UI

    1. On the Databases screen, select Toggle actions button to open a list of additional actions.

    2. Select Database defaults.

    3. Go to Internode Encryption and click Change.

    4. Select Enabled to enable internode encryption for new databases by default.

    5. Click Change.

    6. Select Save.

  • rladmin tune cluster:

    rladmin tune cluster data_internode_encryption enabled

  • Update cluster policy REST API request:

    PUT /v1/cluster/policy 
{ "data_internode_encryption": true }

Encryption ciphers and settings

To encrypt internode communications, Redis Enterprise Software uses TLS 1.2 and the following cipher suites:

  • ECDHE-RSA-AES256-GCM-SHA384
  • ECDHE-RSA-AES128-GCM-SHA256

As of Redis Enterprise Software v7.4, internode encryption also supports TLS 1.3 with the following cipher suites:

  • TLS_AES_128_GCM_SHA256
  • TLS_AES_256_GCM_SHA384

The TLS layer determines which TLS version to use.

No configurable settings are exposed; internode encryption is used internally within a cluster and not exposed to any outside service.

Certificate authority and rotation

Starting with v6.2.4, internode communication is managed, in part, by two certificates: one for the control plane and one for the data plane. These certificates are signed by a private certificate authority (CA). The CA is not exposed outside of the cluster, so it cannot be accessed by external processes or services. In addition, each cluster generates a unique CA that is not used anywhere else.

The private CA is generated when a cluster is created or upgraded to 6.2.4.

When nodes join the cluster, the cluster CA is used to generate certificates for the new node, one for each plane. Certificates signed by the private CA are not shared between clusters and they're not exposed outside the cluster.

All certificates signed by the internal CA expire after ninety (90) days and automatically rotate every thirty (30) days. Alerts also monitor certificate expiration and trigger when certificate expiration falls below 45 days. If you receive such an alert, contact support.

You can use the Redis Enterprise Software REST API to rotate certificates manually:

POST /v1/cluster/certificates/rotate
RATE THIS PAGE
Back to top ↑