MinIO 网络加密 - 全方位保障

加密网络流量是确保 IT 基础设施安全时的低门槛操作。MinIO 在处理 TLS 时采取了务实的方案。它必须安全，必须高效，也必须简单。

重要事项

在几乎所有情况下，我们只需要考虑以下几个关键因素

• 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 配置而担忧的时光。