集群内加密

本章不涵盖客户端到服务器通信的安全（例如 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 或证书相关的异常来指示问题。