集群内加密
企业版

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

简介

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

平台对 SSL 的支持在 SSL 框架中有详细记录。本节涵盖了与保障集群安全相关的具体细节。

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

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

部署示例

生成并安装加密对象

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

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

这可以在证书详情中进行验证

openssl x509 -in public.crt -noout -text

您应该看到 X509v3 扩展密钥用法 (Extended Key Usage) 部分列出了这两种用法

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 或证书相关的异常来指示问题。