无缝加密

如果你处理任何类型的数据，你就必须担心数据安全。这对跨国银行来说是正确的；对中小企业来说也是正确的。加密不应该是你抵御恶意行为者的唯一防线，但它是最基本的安全最佳实践之一，每个组织都应该将其视为必不可少的。

但是，并非所有加密方案都能提供相同级别的保护。虽然每个主要的存储提供商都提供某种加密，但细节的不同会导致现实世界中安全后果的不同。很容易陷入 分析加密算法（更多内容将在下面介绍），但 高性能加密至少同样重要：如果由于实际或感知的性能下降而关闭了加密，那么加密算法的工作原理就无关紧要了。

如果你关心安全，你需要深入了解数据是否在传输中和静止状态下被加密，而不仅仅是这些。在比较存储选项时，以下是一些需要考虑的与加密相关的细节。

加密管理的透明度

亚马逊网络服务 (AWS) 提供了很少关于 Simple Storage Service (S3) 对象存储中如何处理加密的确切细节。他们声称使用 AES 256 块密码作为核心原语，但除此之外没有关于如何使用此原语来加密数据的任何信息。这些信息不足以评估加密方案的安全性。

作为一个开源项目，透明度是 MinIO 操作的核心。我们不仅有关于我们使用的加密算法的详细文档，而且正在发布可证明的链——这是未来几周值得关注的事情。

没有性能损失

有一种说法是，在高性能用例中不应该启用加密。事实上，某些类型的加密方案会降低性能，这使得用户更有可能在速度很重要的时关闭加密。从安全的角度来看，这是一个糟糕的主意：即使数据是在高性能环境中收集的，也不意味着它不应该受到保护。此外，这些数据会保留在系统中，随着未加密数据的不断积累，会导致一个后勤上的噩梦。

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

我们建议所有客户始终启用加密，以确保所有数据都保持安全。与其他加密解决方案不同，持续加密没有缺点。

对于某些行业，加密是必不可少的。例如，银行不得不接受性能损失，因为加密是强制要求的。有了 MinIO 的高性能加密，即使是监管严格的行业也可以拥有高性能、数据丰富的应用程序，而不会损害安全性。

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

总的来说，像 AES-CBC 或 AES-CTR 这样的加密方案可以确保机密性，但不能提供任何数据完整性保护。带关联数据的认证加密 (AEAD) 方案，如 AES-GCM，除了机密性之外还提供完整性，但前提是将整个数据作为一个连续的块原子地处理。它们不是为将数据作为流处理而设计的，而任何与 S3 兼容的存储解决方案都是这样操作的。

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

MinIO 是唯一提供这种级别的保护的对象存储解决方案，它涵盖数据机密性，同时还防止数据篡改。

确保完整性

使用 AWS 或 Ceph 使用的加密类型，恶意用户可能无法访问数据本身。但是，恶意用户可以更改数据而不被发现。

例如，在你的博客上，你可能会提供一些内容——例如狗的照片——实际上存储在加密的 S3 存储桶中。现在，你可能期望，即使这些照片是公开信息——访问你博客的任何人都可以查看它们——没有人，即使直接访问存储磁盘，也应该能够将内容更改为例如猫的照片。不幸的是，如果你的数据使用 AES-CTR 加密，那么将你心爱的狗换成猫是轻而易举的事情。根据具体细节，在使用 AES-GCM 加密数据时也可以进行交换。 

MinIO 的加密协议不仅确保数据的机密性，还确保数据的完整性。如果数据以任何方式被更改，你将收到警报。虽然数据完整性通常不被认为是加密问题，但它是整体数据安全格局的重要组成部分。

始终开启

加密不是可以通过默认设置完全启用的功能。当客户设置 MinIO 或任何其他对象存储解决方案时，他们需要提供加密密钥。但是，一旦完成此初始步骤，MinIO 的加密将始终开启。由于没有性能损失，因此没有理由在特定用例中禁用它。

安全漏洞通常是人为错误造成的，而不是技术故障。对加密的临时方法，在某些用例中启用加密，而在其他用例中禁用加密，需要更多的手动步骤，也会带来更多出错的机会。另一方面，MinIO 的加密是客户可以设置一次就不用管的，从而极大地降低了人为错误导致敏感数据泄露的可能性。

了解更多

使用 MinIO，你不必“只是相信我们”加密是正确完成的——我们完全透明地说明了它的工作原理。你可以在 GitHub 上或我们的文档中阅读更多内容。此外，你可以在 Slack 上加入讨论，或通过hello@min.io联系我们。