深入了解 IAM 概念并通过实践动手掌握

Source: Dev.to

Introduction

在最近的面试中，我遇到了许多与 IAM 相关的问题，包括情景式的提问，例如：

“一名 IAM 用户拥有对 AWS 账户的 FullAdmin 权限，但仍然无法访问 S3 桶。可能的原因是什么？”

下面提供了 IAM 概念的简要概览以及实操要点。

IAM User

• 代表需要访问 AWS 的个人、服务或应用程序。
• 为了授予访问权限，可将 IAM 策略 直接附加到该用户，或附加到该用户所属的组。

IAM Groups

• 一组共享相同权限和角色的用户。
• 附加到组的策略会被该组的所有成员继承。

IAM Roles

• 为用户、应用程序或 AWS 服务提供 临时 访问权限。
• 通过限制权限的持续时间和范围来提升安全性。
• 角色的权限通过将 IAM 策略附加到角色来定义。

Principle of Least Privilege

只给用户执行其工作所需的权限，并移除任何不必要的访问。

IAM Policies and Permissions

• 策略对 AWS 资源的操作进行细粒度控制。
• 它们由声明组成，声明指定 哪些资源 可以被访问以及 可以执行哪些操作。

AWS Identity‑Based Policy

• 附加到 IAM 用户、组或角色。
• 从身份的角度控制权限。

AWS Resource‑Based Policy

• 直接附加到 AWS 资源（例如 S3 桶、RDS 实例）。
• 指定哪些主体（用户、角色、服务）可以访问该资源。

示例： 一个名为 accounting 的组被拒绝删除 S3 桶及其对象的权限。

IAM Permission Boundaries

• 用于限制 IAM 实体能够拥有的最大权限，即使已附加更宽泛的策略。
• 适用于新实习生或初级员工，防止他们获得过于宽松的权限。

情景： 实习生拥有授予完全控制的策略，但权限边界将其访问限制在仅能管理的资源上。

IAM Session Policy

• 为用户或角色提供临时、会话特定的权限。
• 适用于向 AWS 资源授予短期访问的场景。

Inline Policy

• 直接嵌入在用户、组或角色内部。
• 不能被其他实体复用。
• 示例： 为 DevOps 工程师授予临时 S3 访问权限，并在定义的时间后自动失效。

Managed Policy

• 由 AWS（AWS‑managed）或您的组织（customer‑managed）创建和维护。
• 可以附加到多个用户、组或角色，跨账户使用。
• 支持条件，以进一步细化权限的适用时间和方式。

Tags: AWS, IAM, Security, Cloud