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

企业继续扩大其云覆盖范围——在更多云中运行更多工作负载——公共、私有和边缘。他们正在寻求成本节约、可扩展性和更好的价值实现时间，但他们可能会因复杂且通常是冗余的云部署和管理策略而失去这些优势。保护云中的资源很快就会变成一堆重叠的实体、权限和策略。  

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

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

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

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

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

MinIO IAM 基础知识

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

MinIO 包括内部身份管理功能，以使用无处不在的访问密钥和秘密密钥凭证框架来实现这一点。MinIO IAM 使用以兼容 AWS IAM 的 JSON 语法编写的细粒度策略来控制对云资源的访问，以定义用户、服务账户和组对资源的访问。MinIO 与每个云的 IAM（谷歌云平台、亚马逊网络服务、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。这通常用于提供对移动或 Web 应用程序的访问，而无需创建自定义登录机制和管理身份。这有助于在提高代码可移植性的同时保持云凭据的安全。

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

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