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 配置 Elasticsearch编辑

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

以下是所需配置的高级概述

Java 安全提供程序编辑

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

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

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

Java 安全管理器编辑

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

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

Elasticsearch 密钥库编辑

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

TLS编辑

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

TLS 密钥库和密钥编辑

密钥库可以在许多 通用 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 设置的默认值。请参阅 用户缓存和密码哈希算法。

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

配置 Elasticsearch elasticsearch.yml编辑

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 模式下运行时，一些功能不可用。列表如下