FIPS 140-2

联邦信息处理标准 (FIPS) 出版物 140-2 (FIPS PUB 140-2)，题为“密码模块的安全要求”，是美国政府用于批准密码模块的计算机安全标准。Elasticsearch 提供符合 FIPS 140-2 的模式，因此可以在配置了 FIPS 140-2 的 JVM 中运行。

符合 FIPS 140-2 的要求需要仅使用 FIPS 批准的/NIST 推荐的加密算法。通常可以通过以下方式完成此操作

有关 FIPS 140-2 合规性所需配置的详细说明超出了本文档的范围。用户有责任确保符合 FIPS 140-2。Elasticsearch 已经使用下面描述的特定配置进行了测试。但是，还有其他配置可以实现合规性。

以下是所需配置的总体概述

有关安装和配置 FIPS 认证的 Java 安全提供程序的详细说明超出了本文档的范围。具体而言，需要一个 FIPS 认证的 JCA 和 JSSE 实现，以便 JVM 使用 FIPS 验证的 NIST 推荐的加密算法实现。

Elasticsearch 已使用 Bouncy Castle 的 bc-fips 1.0.2.5 和 bctls-fips 1.0.19 进行了测试。有关哪些 JVM 和安全提供程序组合在 FIPS 模式下受支持的详细信息，请参阅 Elasticsearch JVM 支持矩阵。Elasticsearch 不附带 FIPS 认证的提供程序。用户有责任安装和配置安全提供程序，以确保符合 FIPS 140-2。使用 FIPS 认证的提供程序将确保仅使用批准的加密算法。

要配置 Elasticsearch 以使用其他安全提供程序，请配置 Elasticsearch 的 JVM 属性 java.security.properties 以指向 Elasticsearch 的 config 目录中的文件（示例）。确保 FIPS 认证的安全提供程序配置为最低顺序。此文件应包含必要的配置，以指示 Java 使用 FIPS 认证的安全提供程序。

在 Elasticsearch 中运行的所有代码都受到 Java 安全管理器强制执行的安全限制。您已安装和配置的安全提供程序可能需要其他权限才能正常工作。您可以通过提供自己的 Java 安全策略来授予这些权限

要配置 Elasticsearch 的安全管理器，请配置 JVM 属性 java.security.policy 以指向 Elasticsearch 的 config 目录中具有所需权限的文件（示例）。此文件应包含 Java 安全管理器授予安全提供程序所需权限的必要配置。

FIPS 140-2（通过 NIST 特别出版物 800-132）规定加密密钥应至少具有 112 位的有效强度。因此，存储节点安全设置的 Elasticsearch 密钥库需要使用满足此要求的密码进行密码保护。这意味着密码需要 14 个字节长，这相当于 14 个字符的 ASCII 编码密码或 7 个字符的 UTF-8 编码密码。您可以使用 elasticsearch-keystore passwd 子命令来更改或设置现有密钥库的密码。请注意，当密钥库受密码保护时，您必须在每次 Elasticsearch 启动时都提供密码。

FIPS 140-2 不允许使用 SSLv2 和 SSLv3，因此不能将 SSLv2Hello 和 SSLv3 用于 ssl.supported_protocols。

密钥库可以在许多通用 TLS 设置中使用，以便方便地存储密钥和信任材料。在配置了 FIPS 140-2 的 JVM 中，既不能使用 JKS，也不能使用 PKCS#12 密钥库。请避免使用这些类型的密钥库。您的 FIPS 140-2 提供程序可以提供可以使用的符合要求的密钥库实现，或者您可以使用 PEM 编码的文件。要使用 PEM 编码的密钥材料，您可以使用相关的 *.key 和 *.certificate 配置选项，对于信任材料，您可以使用 *.certificate_authorities。

FIPS 140-2 合规性规定用于 TLS 的公钥长度必须与 TLS 中使用的对称密钥算法的强度相对应。根据您选择使用的 ssl.cipher_suites 值，TLS 密钥必须具有与下表对应的长度

虽然 Elasticsearch 提供了许多用于安全地哈希磁盘上凭据的算法，但只有基于 PBKDF2 的算法系列符合 FIPS 140-2 对于存储密码哈希的要求。但是，由于 PBKDF2 本质上是一个密钥派生函数，您的 JVM 安全提供程序可能会强制执行 112 位密钥强度要求。尽管 FIPS 140-2 没有规定用户密码标准，但此要求可能会影响 Elasticsearch 中的密码哈希。为了满足此要求，同时允许您使用满足您安全策略的密码，Elasticsearch 提供了 pbkdf2_stretch，这是在 FIPS 140-2 环境中运行 Elasticsearch 时建议使用的哈希算法。pbkdf2_stretch 在将用户密码传递给 PBKDF2 实现之前，会对用户密码执行一轮 SHA-512。

您必须将 xpack.security.authc.password_hashing.algorithm 设置为可用的 pbkdf_stretch_* 值之一。启用 FIPS-140 模式后，xpack.security.authc.password_hashing.algorithm 的默认值为 pbkdf2_stretch。请参阅用户缓存和密码哈希算法。

密码哈希配置更改不是追溯性的，因此不会更新磁盘上保留的、本地的和文件领域的现有用户的存储哈希凭据。为了确保符合 FIPS 140-2，请使用文件领域的 elasticsearch-user CLI 工具以及本地和保留领域的创建用户和更改密码 API 重新创建用户或更改其密码。其他类型的领域不受影响，不需要任何更改。

对于缓存哈希，建议使用 ssha256（加盐 sha256）。虽然 PBKDF2 符合 FIPS-140-2 标准，但它的设计使其速度较慢，因此通常不适合作为缓存哈希算法。缓存的凭据永远不会存储在磁盘上，而加盐 sha256 为内存中的凭据哈希提供了足够的安全性，而不会造成过高的性能开销。您可以使用 PBKDF2，但应首先仔细评估性能影响。根据您的部署情况，PBKDF2 的开销可能会抵消使用缓存的大部分性能增益。

要么将所有 cache.hash_algo 设置为 ssha256，要么将其保留为未定义，因为 ssha256 是所有 cache.hash_algo 设置的默认值。请参阅用户缓存和密码哈希算法。

用户缓存在节点重启时将被清空，因此任何使用不合规算法的现有哈希都将被丢弃，并且将使用您选择的算法创建新的哈希。

xpack.security.fips_mode.enabled: true
xpack.security.autoconfiguration.enabled: false
xpack.security.fips_mode.required_providers: ["BCFIPS", "BCJSSE"]
xpack.security.authc.password_hashing.algorithm: "pbkdf2_stretch"

要验证安全提供程序是否已安装并正在使用，您可以使用以下任一步骤

Elasticsearch 8.0+ 需要 Java 17 或更高版本。Elasticsearch 8.13+ 已经过 Bouncy Castle 的 Java 17 认证 FIPS 实现的测试，是在 FIPS 140-2 模式下运行 Elasticsearch 时推荐的 Java 安全提供程序。请注意 - Elasticsearch 不附带 FIPS 认证的安全提供程序，需要显式安装和配置。

或者，考虑使用 FedRAMP 认证的 GovCloud 区域中的 Elasticsearch Service。

如果您计划将现有集群升级到可以在 FIPS 140-2 配置的 JVM 中运行的版本，我们建议首先在现有 JVM 中执行滚动升级到新版本，并执行所有必要的配置更改，为在 FIPS 140-2 模式下运行做准备。然后，您可以执行节点的滚动重启，在 FIPS 140-2 JVM 中启动每个节点。在重启期间，Elasticsearch

如果您的订阅已经支持 FIPS 140-2 模式，您可以选择执行滚动升级，同时在 FIPS 140-2 JVM 中运行每个升级的节点。在这种情况下，除了下面概述的必要配置更改之外，您还需要在启动每个节点之前手动重新生成 elasticsearch.keystore 并将所有安全设置迁移到其中。

由于 FIPS 140-2 合规性强制执行的限制，在 FIPS 140-2 模式下运行时，一小部分功能不可用。列表如下