Amazon Identity and Access Management (IAM) 身份认证服务

⛩️ 前言摘要

帮助您了解 IAM 服务如何进行工作，并且以哪几种方式进行精细权限控制。

此次配置所使用 AWS 账户及演示区域为 Global，中国区请自行设置，操作大同小异
IAM 服务需要在以根账户登陆 AWS Web 控制台，点击右上角 Account 进入账户设置页面，下拉至 IAM User and Role Access to Billing Information，点击 Edit 进行编辑，点击勾选勾选框激活 IAM 服务核心功能。

☁️ AWS 服务介绍

Amazon Identity and Access Management (IAM)

👉🏻 Offcial Doc

Amazon Identity and Access Management (IAM) 是一种 Web 服务，可以帮助您安全地控制对 AWS 资源的访问。可以使用 IAM 来控制谁通过了身份验证（准许登录）并获得授权（拥有权限）来使用资源。

AWS 在零信任网络中设计的身份认证服务，所有 AWS 服务都与 IAM 服务高度集成，可通过相对应的策略对相关联的 AWS 服务或资源进行授权和调用。

本次配置所使用 AWS 账户及演示区域为 Global，中国区请自行设置，操作大同小异。

简单的操作

IAM 服务控制台

1. 登录 AWS 账户
   使用您的 AWS 账户凭证登录 AWS 控制台，并在左上角搜索框输入 IAM ，点击

   IAM Dashboard Screenshot
   

   从截图中可以看到 IAM 面板界面清晰展示了以下几个常规布局：
   🟢 - IAM 服务所有功能。
   🔴 - 展示了基础的安全合规检查项，IAM 服务资源总数，及 IAM 服务更新迭代推送信息。
   🟡 - 展示当前账户相关信息，如 Account ID， Sign-in Link 等，还展示了相关工具推荐。

结果

您已顺利登陆 AWS 账户及完成进入 IAM 服务的操作。

IAM 服务无需选择 AWS Region，此服务为 Global 覆盖。

IAM 服务功能介绍

UserGroup 及 User

1. 👩‍👩‍👧‍👦 UserGroup
   用户组，是 User 的一个 集合。可以将 Policies 直接分配给用户组，以实现多个 IAM 用户拥有相同 Policies。

2. 👷‍♂️ User
   用户是 AWS 中的一个 实体。该实体具有和 AWS 服务和资源 交互的能力，并且该实体可能是 用户 也有可能是 应用程序。

   上述 用户 或 应用程序 解释如下：
   用户即为登陆 AWS Web 控制台进行操作的用户。
   应用程序即为调用 AWS API 进行操作的应用程序，这里可以是一段代码，也可以是完成的应用程序。

   用户 和应用程序 可以同时存在，意思是此 IAM 用户既可以登陆 AWS Web 控制台又可以进行 AWS API 调用。但是，AWS最佳安全实践 不建议采用这样的设置。

3. UserGroup 及 User
   UserGroup 可以为 空集合，也可以在创建时将现已有用户分配至组中。不可直接在组中创建用户，用户需在 🟢 选中 User 进行创建。

特性

• 一 用户组 可以拥有多个 用户，一个 用户 也可以同时分配给多个 用户组。
• 用户组 不能嵌套；其中只能包含 用户，而不能包含其他 用户组。
• 默认情况下，没有可自动包含 AWS 账户 内所有 用户 的 用户组。如果希望有这样的 用户组，则需要创建该组，然后将每个用户分配给它。

Roles 及 Policies

1. 🪖 Roles
   IAM 角色是可在 AWS 账户中创建的一种具有 特定权限 的 IAM 身份。IAM 角色类似于 IAM 用户，因为它是一个 AWS 身份，具有确定其在 AWS 中 可执行 和 不可执行 的操作的权限策略。但是，角色旨在让需要它的任何人代入，而不是唯一地与某个人员关联。此外，角色没有关联的标准长期凭证（如密码或访问密钥）。相反，当您代入角色时，它会为您提供角色会话的 临时安全凭证。

2. 📄 Policies
   IAM 策略分为 AWS 托管策略 和 客户托管策略。

   AWS 托管策略 - 是由 AWS 创建和管理的独立策略。
   客户托管策略 - 是由用户自行创建和管理的独立策略。

   两者之间区别在于 AWS 托管策略 为初始化自动生成，而 客户托管策略 需要用户手动创建并分配。
   AWS 托管策略 会因 AWS 服务或资源更新而引起策略内容变更, AWS 禁止用户修改 AWS 托管策略

作用场景

Roles 为 AWS 服务和资源所分配，而 Policies 则为 IAM 用户所分配。两者都为授权策略，只是收益对象不同。
Roles 更偏向于较少使用的固定的策略集合，在 突发性 情况下，将其代入 AWS 服务及资源，因此获取到 临时安全凭证。 Policies 更偏向于长期稳定使用的固定的策略集合，通常用于 IAM 用户 首次创建时策略分配，即一个人员对应固定的工作职能 (IAM 策略)。

不涉及项

以上是 IAM 服务最基础的介绍，其中包含了 Dashboard、用户组、用户、角色、策略 五个部分，希望通过上述内容可以对 IAM 服务有一些新的认知。

因文章为 入门级，不涉及 IAM 服务一些复杂知识体系。如本文没有介绍，请自行参阅 AWS 官方文档。
👉🏻 AWS IAM 服务介绍

🔍 业务场景及需求分析

那么有了一些认知后，肯定需要动手实践一下，以此来巩固所学习的知识。

🏕️ 业务场景

某一企业将通过 AWS 实施部署新的项目，目前 IT 部门多以小组形式开展工作，并且每个小组都拥有不同的工作职能——系统管理、日志安全审计、数据安全管理、开发测试、技术运维。现企业 CTO 要求解决方案架构顾问对其 IAM 身份体系进行设计。
如果是你，请根据以上参考设计出最符合此业务场景的 IAM 身份体系架构。

📝 需求分析

1. 小组形式 意味着该 IT 部门需要创建多个 IAM UserGroup。
2. 不同的工作职能 意味着需要创建并分配不同的 Roles 或 Policies。
3. 岗位... 意味着给定了具体的职能界限，只需要根据不同的职能界限评估出所需要的 Roles 或 Policies 即可。

🛗 IAM 身份体系架构图

1. 架构图中，一共分为六个部分—— Root Account(根账户)、SysManager Group、LogManager Group、DBManager Group、Developer Group、Operator Group。
   此设计将实现业务场景中多以小组形式开展工作，并且每个小组都拥有不同的工作职能的需求。
2. Root Account 为 AWS 首次创建账户生成的用户，对此 AWS 账户享有完全控制访问权限，优先级高于所有 IAM 用户，包括具有 AdministratorAccess 策略的 IAM 用户。

   AWS 最佳安全实践规定 根用户需谨慎使用，如无特殊需求(部分操作只能由根用户实现)不得使用。

3. SysManager Group 及其他四个 IAM UserGroup 以实现业务场景中系统管理、日志安全审计、数据安全管理、开发测试、技术运维的需求。
4. Policies 直接根据每个 用户组 进行评估并创建，分配至不同的 用户组。再将 用户 直接创建添加至对应 用户组 即可实现上述两个需求的结合。

具体操作

1. 创建用户组及策略
   👉🏻 创建用户组
   👉🏻 创建策略
2. 策略分配至用户组
   👉🏻 策略添加至用户组
3. 创建用户并添加至用户组
   👉🏻 创建用户
   👉🏻 用户加入用户组

结果

通过以上对业务场景的需求分析，我们以成功设计出最符合此业务场景的 IAM 身份体系架构。

在实际项目中，也可以采用相同的思路去设计 IAM 身份体系架构设计，尽量考虑周全，确保因项目发展趋势所引起的 IAM 身份体系复杂度增加，最终导致架构在没有使用稳定就遭遇淘汰的结果。

Learn to fish

“Give a man a fish and you feed him for a day.
Teach him to fish and you feed him for a lifetime.”