集群内加密

本章不涵盖客户端到服务器通信的安全（例如 Bolt、HTTPS、备份）。

简介

集群通信的安全解决方案基于标准的 SSL/TLS 技术（统称为 SSL）。加密只是安全的一个方面，其他基石是认证和完整性。一个安全的解决方案基于一个密钥基础设施，该基础设施与认证要求一起部署。

平台中对 SSL 的支持在 SSL 框架 中有详细文档。本节涵盖与保护集群相关的具体内容。

在 SSL 下，端点可以使用由 公钥基础设施 (PKI) 管理的证书进行身份验证。

安全密钥管理基础设施的部署超出了本手册的范围，应委托给经验丰富的安全专业人员。下面所示的示例部署仅供参考。

示例部署

生成和安装加密对象

加密对象的生成在很大程度上超出了本手册的范围。它通常需要组织内部有一个带有 证书颁发机构 (CA) 的 PKI，他们应该能够在此处提供建议。请注意，本手册中与 PKI 相关的信息主要用于说明目的。

如果在集群配置中设置集群内加密，请确保集群端点上使用的证书支持服务器和客户端使用。这是因为当 Neo4j 服务器之间进行集群连接时，每个服务器都使用自己的证书作为客户端在连接到另一个服务器时进行身份验证。

这可以在证书详细信息中进行验证

openssl x509 -in public.crt -noout -text

我们应该看到 X509v3 扩展密钥用法部分显示了列出的两种用法

X509v3 Extended Key Usage:
    TLS Web Server Authentication, TLS Web Client Authentication

获得证书和私钥后，可以将其安装在每台服务器上。每台服务器都有自己的证书，由 CA 签名，以及相应的私钥。CA 的证书安装在 trusted 目录中，任何由 CA 签名的证书因此都受到信任。这意味着服务器现在能够与其他服务器建立信任。

在使用 trusted 目录中的 CA 证书时务必小心，因为任何由该 CA 签名的证书都将被信任加入集群。切勿使用公共 CA 或内部根 CA 为您的集群签署证书。相反，请使用源自并受您组织控制的中间证书或 CA 证书，并且仅用于该特定集群。

在此示例中，部署了相互认证设置，这意味着通道的两端都必须进行认证。要启用相互认证，SSL 策略的 client_auth 必须设置为 REQUIRE（这是默认值）。服务器默认需要进行身份验证，因此没有相应的服务器设置。

如果某个服务器的证书受到威胁，可以通过在 revoked 目录中安装 证书吊销列表 (CRL) 来吊销它。也可以使用新的 CA 重新部署。为了应急，建议为集群专门设置一个独立的中间 CA，以便在必要时可以完全替换它。这种方法比处理吊销并确保其传播要容易得多。

示例 1. 生成和安装加密对象

在此示例中，假设私钥和证书文件分别名为 private.key 和 public.crt。如果需要不同的名称，可以覆盖密钥和证书名称/位置的策略配置。对于此服务器，使用默认配置，创建适当的目录结构，并安装证书

$NEO4J_HOME> mkdir certificates/cluster
$NEO4J_HOME> mkdir certificates/cluster/trusted
$NEO4J_HOME> mkdir certificates/cluster/revoked

$NEO4J_HOME> cp $some-dir/private.key certificates/cluster
$NEO4J_HOME> cp $some-dir/public.crt certificates/cluster

配置集群 SSL 策略

默认情况下，集群通信是未加密的。要配置集群以加密其集群内通信，请将 dbms.ssl.policy.cluster.enabled 设置为 true。

SSL 策略利用已安装的加密对象，并允许配置参数。使用以下配置之一中的参数

以下示例假设已根据 示例部署 创建并配置了 SSL 策略，并使用默认的 TLSv1.2。

将以下内容添加到 neo4j.conf 文件中

dbms.ssl.policy.cluster.enabled=true
dbms.ssl.policy.cluster.tls_versions=TLSv1.2 \ (1)
dbms.ssl.policy.cluster.ciphers=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 \ (2)
dbms.ssl.policy.cluster.client_auth=REQUIRE (3)
1 通过对整个集群的控制，可以在不考虑向后兼容性的情况下强制执行默认的 TLS 标准。它没有已知的安全漏洞，并使用最现代的算法进行密钥交换等操作。
2 可以强制执行特定的单一强密码，从而消除对协商和选择哪个密码的任何疑虑。所选密码提供完美前向保密 (PFS)，并使用高级加密标准 (AES) 进行对称加密。AES 对硬件加速有很好的支持，因此通常对性能影响可以忽略不计。
3 将集群客户端认证设置为 REQUIRE 可启用相互认证，这意味着通道的两端都必须进行认证。

以下示例假设已根据 示例部署 创建并配置了 SSL 策略，并同时使用 TLSv1.2 和 TLSv1.3。

将以下内容添加到 neo4j.conf 文件中

dbms.ssl.policy.cluster.enabled=true
dbms.ssl.policy.cluster.tls_versions=TLSv1.3,TLSv1.2 \ (1)
dbms.ssl.policy.cluster.ciphers=TLS_AES_256_GCM_SHA384,TLS_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA \ (2)
dbms.ssl.policy.cluster.client_auth=REQUIRE \(3)
1 通过对整个集群的控制，可以在不考虑向后兼容性的情况下强制执行默认的 TLS 标准。它没有已知的安全漏洞，并使用最现代的算法进行密钥交换等操作。
2 如果要为两个支持的 TLS 版本指定密码，则必须为每个 TLS 版本指定密码，以免获得比预期更多的密码。所选密码提供完美前向保密 (PFS)，并使用高级加密标准 (AES) 进行对称加密。AES 对硬件加速有很好的支持，因此通常对性能影响可以忽略不计。
3 将集群客户端认证设置为 REQUIRE 可启用相互认证，这意味着通道的两端都必须进行认证。它们没有已知的安全漏洞，并使用最现代的算法进行密钥交换等操作。

现在，服务器之间通信的任何用户数据都已得到保护。请注意，未正确设置的服务器无法与其他服务器通信。

必须在每台服务器上配置相同的策略设置。实际安装的加密对象大多不同，因为它们不共享相同的私钥和相应的证书。但是，受信任的 CA 证书是共享的。

验证集群的安全运行

为了确保一切都按预期得到保护，使用外部工具进行验证是有意义的，例如开源评估工具 nmap 或 OpenSSL。

示例 2. 验证集群的安全运行

此示例使用 nmap 工具验证集群的安全运行。一个简单的测试是使用以下命令进行密码枚举

nmap --script ssl-enum-ciphers -p <port> <hostname>

必须根据示例配置调整主机名和端口。这可以证明 TLS 确实已启用，并且只启用了预期的密码套件。应测试所有服务器和所有适用的端口。

出于测试目的，也可以利用一个单独的 Neo4j 测试实例，例如，该实例安装了不受信任的证书。预期结果是测试服务器无法参与用户数据的复制。调试日志通常通过打印 SSL 或证书相关异常来指示问题。

© . All rights reserved.