MinIO 网络加密 - 一切都很好

在保护 IT 基础设施时，加密网络流量是唾手可得的成果。在 TLS 方面，MinIO 遵循务实的方法。它必须安全、高效且简单。

重要的事情

在几乎所有情况下，我们只需要考虑几件事：

• TLS 版本。

• TLS 密码套件。

• TLS 证书。

如果存在网络加密问题，在10 个案例中至少有9 个是由上述一项或多项的次优选择引起的。然而，MinIO 试图让 TLS 成为一种流畅的体验，并且能够正常工作而不是让人头疼。

TLS 版本

MinIO 仅支持 TLS 1.2 和 1.3。两者都默认启用。如果 S3 客户端支持 TLS 1.3，连接将使用 TLS 1.3。不支持旧的 TLS 版本仅仅是因为它们不安全。

简而言之，TLS 1.3 比 TLS 1.2 更快、更安全。例如，TLS 1.3 握手在传输应用程序数据之前需要一次往返而不是两次。此外，TLS 1.3 清理了以前 TLS 版本中的一些设计选择。它仅指定了一小组传输密码，所有这些密码都使用易于理解且快速验证的加密结构并提供前向保密。

长话短说，TLS 1.2 很好，但您需要 TLS 1.3。

密码协商

在 TLS 握手期间，MinIO 和 S3 客户端必须就传输密码达成一致。对于 TLS 1.3，没有“错误的选择”。MinIO 和 S3 客户端将选择在特定硬件上表现最佳的密码。结案。

对于 TLS 1.2，默认情况下，MinIO 仅支持一小组类似于 TLS 1.3 的传输密码。所有这些密码：

• 提供前向保密。他们使用ECHDE，一种基于椭圆曲线的密钥交换，这样即使 MinIO 的私钥被泄露，之前的网络通信仍然是秘密的。

• 在加密网络流量时，使用优化的特定于 CPU 的汇编器实现来花费尽可能少的 CPU 周期。

• 不要通过侧通道泄露秘密，因为所有加密算法都是使用恒定时间构建块实现的。

大多数 S3 客户端将至少支持这些首选密码中的一种。但是，一些年长的客户不会。在这种情况下，您可以通过设置环境变量启用对其他 TLS 1.2 密码的支持：

MINIO_API_SECURE_CIPHERS=off

此选项将简单地启用对仍然被认为是安全但不提供上述所有安全和性能属性的密码的支持。

X.509 证书

在 MinIO 和 S3 客户端可以协商传输密码和交换数据之前，MinIO 服务器必须向客户端证明它实际上是客户端请求的 MinIO 服务器。因此，MinIO 必须生成 RSA 或 ECDSA/EdDSA 签名。此外，MinIO 集群中的每个 MinIO 节点都通过 TLS 与其他节点通信，因此也必须验证此类签名。

最常见的性能问题之一是由 TLS 证书的公钥/私钥对选择不理想引起的。在绝大多数情况下，选择 ECDSA 或 EdDSA 密钥对而不是 RSA。特别是，使用 NIST P-256 或 Ed25519 密钥对。原因是 MinIO 的 TLS 堆栈对这两条曲线使用优化的汇编程序实现，而 RSA 实现使用大整数算法。ECDSA 或 EdDSA 证书通常会在 TLS 握手期间显着降低 CPU 使用率。

FIPS 140-2

对于某些组织，加密算法及其实现必须经过批准和认证才能满足某些合规性要求。因此，我们提供了一个MinIO FIPS 版本。

然而，从正确的角度来看，常规的 MinIO 版本并不比 FIPS 版本更安全或更不安全。FIPS 版本只是限制了加密算法集，并且只使用经过认证的 C 实现。虽然我们提供了 MinIO 的 FIPS 版本，但除非你真的不得不这样做，否则不要陷入 FIPS 的困境。

使用 MinIO 网络加密快速获胜

总而言之，只有几个旋钮可以调整 MinIO 的网络加密设置——您几乎不需要使用它们。为获得最佳性能，请为您的 TLS 证书使用 ECDSA 或 EdDSA 密钥对。如果您的 S3 客户端因为无法就通用传输密码达成一致而无法连接到 MinIO，请启用更大的密码套件集。如果您还没有启用 TLS，那就去做吧——这不是火箭科学，安全性非常重要。

如果您有任何疑问，我们随时为您提供帮助。否则，享受你的时间而不用担心你的 TLS 配置。