使用 MinIO IAM 保护混合云对象存储

企业不断扩展其云足迹 - 在更多云（公共云、私有云和边缘云）上运行更多工作负载。他们正在寻求成本节约、可扩展性和更快的价值实现时间，但他们冒着因复杂且通常冗余的云部署和管理策略而失去这些益处的风险。保护云中的资源很快就会变成实体、权限和策略的重叠混乱。 

希望在。现有的企业安全范式正在适应，以应对将 IT 足迹扩展到云的挑战。虽然全面的纵深防御策略包含许多层，但这篇博文重点介绍了身份访问管理 (IAM) 的作用，IAM 是控制用户和服务对资源的权限和访问的关键机制，用于保护云资源和数据。

根据 Verizon 的 2021 年数据泄露调查报告，85% 的泄露事件都涉及某种人为因素。特权滥用是泄露事件中最常见的一种滥用类型。虽然尚不清楚这些泄露事件是发生在云中还是其他企业环境中，但很明显 IAM 可以对缓解这些风险产生积极影响。企业长期以来都知道，围绕身份构建的明确且可执行的访问策略可以防止数据和服务被泄露，并在发生泄露时限制其范围。

IAM 在控制谁或什么可以访问哪些数据以及提供和管理存储这些数据的底层应用程序方面尤其重要。无论内部还是外部，无论已知还是未知，任何人都不得查看、更改或访问数据，除非他们被明确授予权限。在 IT 拥有完全控制权的环境中，这是一个艰巨的任务，而且在基于多个提供商解决方案的庞大混合云或多云环境中几乎不可能实现。依靠多个界面来管理多个提供商和多个对象存储简直是噩梦。 

相反，MinIO 可以在任何地方运行，并与每个云提供商和 Kubernetes 发行版深度集成，从而简化对对象存储的访问管理，无论其位置如何。MinIO 包含内部身份管理功能，并支持领先的第三方外部身份提供商 (IDP)，为访问对象和 MinIO 控制台本身启用 SSO。  

MinIO IAM 完全兼容 AWS IAM，并依赖于标准来支持外部身份提供商，例如 ActiveDirectory/LDAP、Okta 和 Keycloak。这使得基于身份的访问控制能够提供相同的功能，例如针对服务和用户的 SSO，跨越不同的公共云、私有云、多云、混合云和边缘云。

MinIO IAM 基础

一般来说，IAM 与身份和访问控制有关。实现细节和功能因云提供商、基于云的服务和本地服务而异。基本上，IAM 将身份映射到访问策略，以定义谁（在用户的情况下）或什么（在服务的情况下）可以访问哪些应用程序、服务、数据和基础设施组件。

MinIO 包含内部身份管理功能，使用无处不在的访问密钥和密钥凭据框架来实现这一点。MinIO IAM 使用用 AWS IAM 兼容的 JSON 语法编写的细粒度策略来控制对云资源的访问，以定义用户、服务帐户和组对资源的访问权限。MinIO 与每个云的 IAM (Google Cloud Platform、Amazon Web Services、Azure) 以及 Microsoft ActiveDirectory 和 LDAP 等身份提供商进行互操作，以将企业的用户帐户映射到特定的访问角色。例如，MinIO 可以使用为与 AWS S3 或 S3 兼容服务一起使用而设计的 IAM 策略。

建立基于身份的安全控制的一般过程是管理员创建单个用户和服务帐户，每个帐户都有自己的凭据。企业通常将多个用户的权限一起管理为一个组。组可以对应于部门或职位功能（或两者兼而有之），以简化权限和帐户的添加、更改和删除操作。这比单独管理用户更有效，并且减少了人为错误的可能性。 在创建策略时，它们会被分配给组。当用户被添加到这些组时，他们会继承组访问策略。我可能不需要说，但是可能有人需要阅读：不要将组织的云提供商帐户的 root 访问权限授予任何人。 

一个 MinIO 访问控制策略 是一个 JSON 文档，它明确列出了允许或拒绝的操作。策略的细粒度可以细化到对特定存储桶上的特定操作。 默认情况下，用户和服务无法访问任何资源，除非它们已应用策略。对于每个服务和用户请求，MinIO 都应用访问控制策略来规范对存储桶和对象的访问。   

在 MinIO 中，服务帐户简化了为新应用程序配置帐户。开发人员可以创建服务帐户，这些帐户是简单的身份，继承了创建它们的用户的权限。 

使用 MinIO IAM 的最直接方法是创建静态凭据。在创建服务和用户身份时，MinIO 会提供访问密钥和密钥凭据。在 MinIO 中创建的大多数身份都是为服务，而不是为用户创建的。应用程序必须使用这些凭据进行身份验证，才能在每次对 MinIO 集群执行操作时进行身份验证。由于服务凭据通常是长期存在的，因此我们建议为每个应用程序创建一个身份，以降低泄露凭据的潜在风险。 

但是，静态机制只能获得有限的操作规模。MinIO IAM 可以动态地提供临时凭据并应用访问控制，利用内部安全令牌服务 (STS) 和角色的组合，角色是具有特定权限和分配给它们的临时凭据的身份。IAM 角色用于临时将 IAM 策略应用于用户和服务。当用户或服务临时承担角色时，他们的初始权限将被撤销，而他们将接管角色的权限。

动态凭据颁发可以防止不必要地授予凭据。最佳实践是不在应用程序代码中嵌入凭据，因为它们可能会被泄露。如果嵌入，更改或轮换凭据将需要代码更新。相反，应用程序或 VM 实例可以承担 IAM 角色，并在请求访问（例如，存储桶）时接收必要的临时凭据，然后访问符合 IAM 角色权限的存储桶。通过这种方式管理权限，消除了每次需要更改时编辑用户、服务或组策略的需要。    

MinIO 支持 OpenID Connect 兼容提供商，以启用针对用户、服务和应用程序的 SSO。在这种情况下，应用程序必须实现 MinIO STS 以请求针对 MinIO 资源的临时凭据。临时凭据是短暂的，并在请求时动态生成，从而无需将它们嵌入代码中或重复使用凭据来提供对数据存储的访问权限。

企业通常在集中式系统中管理 IAM，该系统依赖于身份联合来跨应用程序和云共享身份。例如，许多企业在自己的网络上对用户进行身份验证，然后使用单点登录 (SSO) 提供对云资源的访问权限。一个典型的方法是，用户登录 Microsoft Active Directory，Active Directory 联合服务和 AWS STS 的组合会授予临时用户凭据，而无需 IT 为这些用户创建 AWS 帐户。

用户还可以使用与 OpenID Connect (OIDC) 兼容的第三方身份提供商 (IDP) 登录。用户登录到 IDP，IDP 请求临时权限以使用云资源。这通常用于在无需创建自定义登录机制和管理身份的情况下，提供对移动应用程序或 Web 应用程序的访问权限。这有助于保护云凭据安全，同时提高代码可移植性。

MinIO IAM 支持安全的混合云对象存储

MinIO IAM 规范对云资源（包括对象存储）的访问。根据使用的对象存储解决方案、云提供商、IDP 和 IAM 提供商，跨多个云管理用户、组、角色和访问权限可能会非常快地变得非常复杂。MinIO 提供强大的基于身份的控制，这些控制具有互操作性和标准兼容性，以保护对象存储，对象存储是任何云基础设施的关键组件。

下载 MinIO 开始使用，如果您有任何问题，请加入我们的 Slack 频道，给我们发送电子邮件至 hello@min.io 或使用“咨询专家”按钮。无论您选择哪种界面选项，我们都将竭诚为您提供帮助。