如何保护 MinIO - 第 1 部分

MinIO 作为一个对象存储系统，可以充当任何 S3 应用程序的持久层。所有这些应用程序都依赖 MinIO 来存储和保护其数据免受中断以及数据损坏或丢失。

由于所有数据都将传输到 MinIO，因此它成为基础架构的关键部分，因此从信息安全的角度来看，它是一个有吸引力的目标。

威胁模型

为了保护 MinIO 部署，我们必须涵盖以下部分：

• 数据是如何进来的？如何保护传入连接？

• MinIO 是如何存储数据的？如何保护存储的数据？

• 如何控制访问？我们如何授予用户和应用程序访问权限？

除了这三个主要主题之外，我们还必须关注其他方面，例如审计日志记录、内部攻击预防和合规性。然而，首先我们将专注于做好基础知识，只有在我们确保传入和传出连接的安全并实施访问控制之后，我们才会处理更细微的方面。

保护入口

首先，让我们专注于保护传入的数据流。因此，我们必须配置 MinIO 以通过 TLS 接受和服务请求。

从概念上讲，这很容易做到。所有 MinIO 需要的是一个 TLS 私钥和证书，它们应该安装certs/在 MinIO 的配置目录下。例如：

ls -l ~/.minio/certs
drwx------   - minio 1 Jan 2021 CAs
.rw------- 119 minio 1 Jan 2022 private.key    ⟵ The TLS private key .rw------- 461 minio 1 Jan 2022 public.crt     ⟵ The TLS certificate

当运行分布式 MinIO 集群时，只需将相同的public.crt和复制private.key到所有 MinIO 节点，这样所有节点都有相同的certs/目录。重启 MinIO 集群后，所有传输到 MinIO 的数据都将通过加密连接发送。

虽然将 MinIO 配置为接受 TLS 连接很简单，但获取 TLS 证书可能会让人头疼。

您可以使用 OpenSSL 或其他 TLS CLI 工具生成“自签名”证书。我们确实有一些文档。但是，您的客户端应用程序将无法验证您的证书的真实性，因此拒绝连接到 MinIO。要解决此问题，您可以通过将证书复制到所有客户端来手动建立信任链接 - 但这将很快演变成维护噩梦 - 特别是当您因过期而更新证书时。

因此，大多数人使用由证书颁发机构 (CA) 颁发的 TLS 证书。CA 可能是 Web PKI CA，例如Let's Encrypt。由 Web PKI CA 颁发的证书将受到 Internet 上大多数客户端应用程序的信任。但是，如果您在内部使用 MinIO——例如仅在您的组织内——您可以简单地从您组织的内部 CA 请求 TLS 证书。

除了加密数据入口外，MinIO 可能还需要安全地与其他服务（如审计日志服务）通信。因此，MinIO 必须能够验证这些服务的 TLS 证书，因此需要颁发 CA 的证书。此类 CA 证书应放入该certs/CAs/目录中。例如：

ls -l ~/.minio/certs/CAs 
.rw-------  765 minio 1 Jan 2022 company-ca1.crt
.rw------- 1356 minio 1 Jan 2022 company-ca2.crt

默认情况下，这个certs/CAs/目录是空的，MinIO 将只信任系统 CA。

静态加密

一旦我们保护了数据入口，我们就可以看看保护静态数据。MinIO 支持服务器端加密。特别是，MinIO 可以在对象上传时将对象加密为连续数据流，然后再写入底层磁盘。MinIO 还可以连接到各种 KMS，如 Hashicorp Vault，为每个 S3 对象获取唯一的数据加密密钥。

但是，MinIO 集群本身与其 KMS 是解耦的。相反，MinIO 集群与一个或多个KES 实例对话。KES 是一种用于高性能应用程序的无状态分布式密钥管理系统。KES 充当 MinIO 的 KMS API 抽象，并负责操作方面，如可扩展性和高可用性。

我们为我们支持的每个 KMS 供应商提供指南。但是，我们还运行一个公共 KES 实例，play.min.io:7373每个人都可以在第一步中使用它。

我们可以通过在每个 MinIO 节点上设置与 KES 相关的环境变量来将我们的 MinIO 集群连接到 KES。例如：

export MINIO_KMS_KES_ENDPOINT=https://play.min.io:7373
export MINIO_KMS_KES_CERT_FILE=/tmp/root.cert
export MINIO_KMS_KES_KEY_FILE=/tmp/root.key
export MINIO_KMS_KES_KEY_NAME=my-first-key

您可以下载管理员凭据 ( root.key& root.cert) 以
play.min.io:7373使用以下 curl 命令：

curl -sSL --tlsv1.2 \
 -O 'https://raw.githubusercontent.com/minio/kes/master/root.key' \
 -O 'https://raw.githubusercontent.com/minio/kes/master/root.cert'

配置并重启 MinIO 后，我们可以使用 CLI 检查它是否可以访问 KMS mc：

mc admin kms key status <minio-alias>

现在，我们可以上传静态加密的对象。因此，我们配置一个桶来使用从 KMS 获取的密钥来加密新进入的数据：

mc encrypt set sse-kms my-first-key <minio-alias>/<my-bucket>

放入此存储桶中的任何数据都将使用my-first-keyKMS 中的密钥进行加密。这可以通过获取对象元数据来验证。例如，通过mc：

mc stat <minio-alias>/<my-bucket>/<my-object>
Name      : <my-object>
...
Encrypted :
  X-Amz-Server-Side-Encryption               : aws:kms 
  X-Amz-Server-Side-Encryption-Aws-Kms-Key-Id: arn:aws:kms:my-first-key

在 S3 存储桶上设置 KMS 配置只会影响新传入的对象。现有对象将保持未加密状态。因此，从一开始就实施静态加密非常重要。

访问控制

到目前为止，我们已经介绍了加密传输中和静态数据的基础知识。然而，加密本身不允许细粒度的访问控制。相反，MinIO 使用基于S3 固定策略的基于角色的访问控制 (RBAC) 系统。

例如，每个 MinIO 部署writeonly默认包含一个策略：

mc admin policy info <minio-alias> writeonly 
{
 "Version": "2012-10-17",
 "Statement": [
  {
   "Effect": "Allow",
   "Action": [
    "s3:PutObject"
   ],
   "Resource": [
    "arn:aws:s3:::*"
   ]
  }
 ]
}

每项政策由一个或多个声明组成。每个语句明确允许或拒绝对一组资源应用一组操作。在上面的示例中，我们允许将操作应用于任何资源；即。writeonlyPutObject*

访问策略分配给单个用户或用户组。这些用户可以是内部用户，也可以是外部用户。内部用户是特定于 MinIO 的，可以在 MinIO 本身中创建和删除。外部用户是存在于外部 IDP 上的用户帐户——例如 OpenID Connect 提供商或 LDAP 服务器/Active Directory。现在，让我们坚持为内部用户管理策略，稍后再覆盖外部 IDP。

假设我们要创建一个新用户alice并授予她对集群中所有资源的读取权限。我们可以通过首先创建一个新用户来做到这一点：

mc admin user add <minio-alias> alice 
Enter Secret Key:

我们被要求输入 alice 的 S3 密钥。它的长度至少应为 8 个
字符。

一旦我们添加alice，我们就可以为她分配一个策略。在这种情况下，让我们使用预定义的readonly策略：

mc admin policy set <minio-alias> readonly user=alice

此时，alice她将能够读取我们 MinIO 集群上的任何对象，但她将无法创建或删除对象。从这里，我们可以为我们所有的应用程序创建新的用户帐户并调整它们的策略权限。但是，还有另一个特别有用的访问控制概念：服务帐户。

服务帐户

服务帐户是属于用户的静态帐户。因为alice我们可以通过以下方式创建一个新的服务帐户：

mc admin user svcacct add <minio-alias> alice
Access Key: NLJOKS0YFVAXO9XBJ1W3
Secret Key: DZrtGnRKXu++J5IreLmD+BiHsd1sJ9fxy883xWEY

当我们创建这个服务账户时，我们获得了一个新的访问密钥/秘密密钥对。默认情况下，服务帐户继承用户的策略权限。但是，服务帐户的权限可以减少到所需的最小权限集。因此，服务帐户非常适合由 S3 用户管理的应用程序。

例如，alice可能会运行多个想要从我们的 MinIO 集群中获取数据的应用程序。她不应使用她自己的 S3 凭据配置这些应用程序，而应该为她的每个应用程序生成/请求一个新的服务帐户。此外，她可以减少特定服务帐户的权限——例如，当应用程序只需要访问一个存储桶而不是整个集群时。

一旦应用程序不再使用，或者在凭据受损的情况下，alice可以简单地禁用或删除服务帐户：

mc admin user svcacct rm <minio-alias> <service-account-access-key>

总结一下：MinIO 通过应用与用户、组或服务帐户关联的策略来控制数据访问。建议普通 S3 用户使用人类。建议为应用程序使用服务帐户。

结论

这篇文章探讨了如何保护 MinIO 的基础知识。从概念上讲，我们必须保护数据入口、静态数据并定义数据访问规则。然而，我们并没有详述每个主题的所有细节，而是专注于一些关键方面。如果您想深入了解，请查看我们的文档或加入我们的 slack 频道以向我们的全球社区学习。

在本系列的下一篇文章中，我们将探讨一些更高级的主题，例如审计日志记录和外部 IDP。