无摩擦加密

如果处理任何类型的数据，您都必须担心数据安全性。跨国银行是这样。对于中小型企业也是如此。加密永远都不应该是抵御恶意行为者的唯一防线，但它是每个组织都应考虑的最基本的安全最佳实践之一。

但是，并非所有的加密方案都提供相同级别的保护。尽管每个主要的存储提供商都提供某种类型的加密，但是细节差异很大，足以导致现实世界的安全后果。在分析加密算法时很容易陷入困境（有关更多信息，请参见下文），但是高性能加密至少同样重要：如果由于实际或感知的性能下降而关闭了加密，那么加密的程度如何都无关紧要算法有效。

如果您关心安全性，则需要深入研究，而不仅仅是在传输过程中和静止时是否对数据进行加密。在比较存储选项时，以下是一些与加密有关的详细信息。

透明的加密管理方式

Amazon Web Services（AWS）几乎没有提供有关在简单存储服务（S3）对象存储中如何正确处理加密的详细信息。他们声称使用AES 256分组密码作为核心原语，但除此之外，没有有关此原语如何用于加密数据的信息。这些信息不足以评估加密方案的真正安全性。

作为一个开源项目，透明度是MinIO运行方式的核心。我们不仅拥有广泛的文档，不仅关于我们使用哪种加密算法，而且还在发布可证明的链-在接下来的几周中需要注意。

没有性能下降

有一个神话，即在高性能用例中不应该启用加密。实际上，某些类型的加密方案会拖累性能，这使用户更有可能在速度很重要时关闭加密功能。从安全角度来看，这是一个可怕的想法：仅仅因为在高性能设置中收集数据并不意味着就不应对其进行保护。此外，此数据仍保留在系统中，由于未加密的数据继续累积，这将带来后勤上的噩梦。

MinIO的加密方案实际上比系统的其他部分运行得更快，因此启用加密后，性能没有差异。可以在我们的NVMe和HDD基准测试中找到证据，在这些基准测试中，我们在启用和禁用加密的情况下运行它们。

我们建议所有客户始终简单地启用加密，以确保所有数据均保持安全。与其他加密解决方案不同，一致加密没有不利之处。

对于某些行业，加密不是可选的。例如，由于必须进行加密，因此银行仅需承担性能损失。利用MinIO的高性能加密，即使是受到严格监管的行业也可以拥有高性能，数据丰富的应用程序，而不会影响安全性。

安全通道可确保机密性和完整性

通常，加密方案（例如AES-CBC或AES-CTR）可确保机密性，但不提供任何数据完整性保护。像AES-GCM这样的带有关联数据的认证加密（AEAD）方案确实提供了完整性，除了机密性外，但仅当将整个数据作为原子连续地处理时才提供。它们不是为将数据作为流处理而设计的，这是任何与S3兼容的存储解决方案的工作方式。

在MinIO，我们使用AEAD（AES-256-GCM或ChaCha20-Poly1305）作为安全通道的基础，该通道可确保流数据的机密性和完整性。特别是，我们依赖于经过分析且易于理解的设计。  

MinIO是唯一提供此级别保护的对象存储解决方案，既涵盖数据机密性，又防止数据篡改。

确保诚信

利用AWS或Ceph使用的加密类型，恶意用户可能无法访问数据本身。但是，恶意用户可能会更改未检测到的数据。

例如，在您的博客上，您可能会提供一些内容（例如狗的照片），这些内容实际上存储在加密的S3存储桶中。现在，您可能希望，即使这些照片是公开信息（访问您博客的任何人都可以看到它们），即使直接访问存储磁盘，也没有人应该能够将内容更改为例如猫的照片。不幸的是，如果您的数据使用AES-CTR加密，那么将您心爱的狗换成猫是微不足道的。根据确切的细节，当使用AES-GCM加密数据时，也可以进行交换。  

MinIO的加密协议不仅可以确保数据的机密性，还可以确保完整性。如果数据有任何更改，将向您发出警报。尽管通常不将数据完整性视为加密问题，但它是整个数据安全领域的重要组成部分。

永远在线

默认情况下，不能完全启用加密功能。当客户设置MinIO或任何其他对象存储解决方案时，他或她需要提供加密密钥。但是，一旦完成此初始步骤，MinIO的加密将始终处于打开状态。因为没有性能影响，所以没有理由针对个别用例禁用它。

安全漏洞通常是由人为错误而非技术故障引起的。临时加密方法（在某些用例中启用了加密，而在其他用例中禁用了加密），则需要更多的手动步骤和更多的出错机会。另一方面，MinIO的加密是客户可以设置和忘记的东西，从而大大降低了人为错误会使敏感数据暴露的可能性。