AWS 小白书 [2] 什么是 IAM ?

什么是 IAM？

IAM aka Identity & Access Management，这个服务是用来管理 AWS 资源访问权限的。简单来说，你可以创建不同的用户和角色，并给他们分配不同的权限，来去实现云上资源的最小化权限管理。

---

补充 ： 最小化权限原则

最小化权限原则 aka PoLP，你可叫做它最小授权原则或者最小特权原则，是一种信息安全概念，即为用户提供执行其工作职责所需的最小权限等级或许可。如此可以减少数据泄露、恶意攻击和误操作的风险。是一种最常使用的安全策略。

用一个现实社会的例子解释给大家听，比如说公司的门禁系统，每个员工只能进入自己需要工作的地方，比如办公室、会议室、茶水间等，而不能随便进入其他人的办公室或者重要的机房。这样做的目的是为了保护公司的资料和设备不被外人或者不负责任的员工窃取、破坏或者误操作。最小化权限原则就是一种类似的信息安全概念，它要求给每个用户或者程序分配最少必要的权限，让他们能够完成自己的任务和工作。这样可以提高信息安全和效率，减少风险和损失。

如果你想要在详细的了解，看这里：

:-: https://www.cyberark.com/zh-hans/what-is/least-privilege/

---

IAM 核心概念

根用户 ( Root User )

大家之前登录的账户就是所谓的根用户。如果你熟悉 linux 那么对 root user 这个概念应该不陌生。其实AWS 的 RootUser 也是如此，拥有所有的权限，而且是自动创建且无法进行权限限制的。你也可以认为 Root User 是这个账户的真正拥有者。虽然使用这个账号，可以畅通无阻，我们可以通过这个账号，进行所有资源的管理。但是就像是我们在使用 Linux 相同的思路，它不应该被进行日常使用。
所以正确的方式，我们需要 IAM 进行管理我们的权限，使用我们在 IAM 中创建的可控制的用户，或者更精确的说法，主体，来去进行日常操作的使用。

IAM 用户和用户组

IAM 用户

IAM 用户就是推荐的主体之一，IAM 帮助我们进行主体的管理和身份验证。当然如果太专业的话，你也可以认为 IAM 用户就是一个账号，可以通过它登录到 AWS 中。

IAM 用户组

而 IAM 用户组，则是 IAM 中的一个管理组件，注意它并不是一个主体，所以也不能登录到 aws 中。一个 IAM 用户可以归属于 0 个或多个用户组，但是用户组中不能包含用户组，也就是说用户组是不能嵌套的。
使用用户组可以帮助我们更方便的管理用户，我们可以把有相同的目标和任务的用户归成一组，同时也可以进行相同规则和限制。

IAM 角色 ( Role )

首先，你需要知道的是，用户和角色在人类社会中的不同概念。打个比喻，你在这个社会中，你是一个人，这个身份是永恒的不会改变的，XD 就是 XD，我就是我。而我在公司里是一个开发工程师，我现在是一名 AWS 讲师。而前一种具有唯一性和不变性，对应的就是用户。后一种是一种责任，一种身份，一种职能，这个东西，是你是我是他都是可以的，其实也就是一个角色，我们在这个世界上其实都是在不断地 cosplay 各种角色。

这样的解释在 IAM 中也是成立的，如果你想要创建的身份是一个长期的不变的身份，这个身份的生老病死，专业一点就是生命周期，都取决于这个人是否还存在，那么在这个时候你应该使用IAM 用户来做映射。

而角色是在特定的情况下用来进行切换的，它不具有特殊性，只不过在某一个情境下，我需要让你切换到这个角色，来做一些事情，所以它具有临时性，所以这种用途的身份主体就应该使用 IAM 角色。所以在这里给大家三个例子帮助大家理解什么情境下用角色：

• 为 AWS 服务授予访问其他 AWS 资源的权限，AWS 的服务也是需要相应的权限来去代替我们去做事的，但是他不是人，所以我们应该使用角色。
• 为外部身份提供临时访问 AWS 资源的权限。你是人，但是你不想在 AWS IAM 中进行映射，而只是想需要的时候，操作一下 AWS 的资源，这样的情况你也应该使用角色。
• 为账户内或跨账户的用户提供临时切换角色的能力。外部的人，不是自己人，所以在你看来你没有必要为他的生老病死负责，所以也要用角色。

IAM 策略 ( Policy )

搞明白认证这件事情，之后我们来看一下，怎么样在 IAM 中做授权。简单来说，你想让 IAM 中的身份主体，真正发挥作用，你就必须告诉 IAM 这个主体，你想让它：

:-: 在何种情况下，谁可以或者不可以对什么AWS资源做什么操作。

而声明这件事情的 IAM 组件就是 IAM 策略. 而这个策略你需要用 Json 的方式进行编写。那我们来就来分析一下这个声明中应该有哪些元素吧。还是来看这句话。

:-: 在何种「情况」下，「谁」「可以或者不可以对」什么AWS「资源」做什么「操作」。

解析完这句话，你应该就能猜出来，应该有的元素了吧。

• 「谁」 aka 主体 ( Principal ) ：指定策略适用于哪个用户或角色。
• 「操作」( Action ) : 声明主体的操作范围，如读取、写入、删除等。
• 「资源」( Resource ) ： 指定主体可以访问的资源，如 S3 存储桶、EC2 实例等。
• 「可以或者不可以对」 aka 效果「Effect」 ： 允许还是拒绝。
• 「情况」 aka 条件 ( Condition ) : 指定请求必须满足的附加条件，如时间、地点、IP 地址等。

可能这样还不直观，那么我们就来举个栗子，我想声明某个 IAM 用户，在某一些 IP 地址段发起操作，来创建以 “tmp-” 开头的用户，策略如下：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCreateUser",
      "Effect": "Allow",
      "Action": [
        "iam:CreateUser"
      ],
      "Resource": [
        "arn:aws:iam::*:user/tmp-*"
      ],
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": [
            "192.0.2.0/24",
            "203.0.113.0/24"
          ]
        }
      }
    }
  ]
}

你会发现，在这个json中，statement 是一个列表，所以其实在一个策略文档中可以有多个声明。
你也应该会发现，在这个 json 中，并没有发现pricipal 的存在，那是因为，这个策略呢，是给到我们用户使用的，所以谁拥有这个策略，那么 principal 就自然就是谁了。

但是问题来了，那主体又有何种意义呢？要知道这个就需要了解，在 IAM 中有不同种类的 Policy。

基于身份的策略和基于资源的策略

基于身份的策略

所谓的基于身份的策略是指，我们将策略直接附加到用户、组或角色上，以控制这些身份可以访问哪些 AWS 资源。这种策略通常用于控制用户或角色可以进行的操作，例如允许用户访问某些 AWS 服务或执行某些 API 操作。基于身份的策略适用于需要将授权直接分配给特定用户、组或角色的情况。

基于资源的策略

而基于资源的策略则是指，我们将策略直接附加到资源上，以控制哪些身份可以访问该资源。这种策略通常用于控制对某些特定资源的访问，例如允许特定用户访问特定的 S3 存储桶或 RDS 数据库。基于资源的策略适用于需要限制特定资源的访问权限的情况。

并且，两者可以配合使用，以便在 AWS 中实现更细粒度的访问控制。这样，我们可以确保身份可以访问到其需要的资源，而其他身份则不能访问这些资源。

配合使用

用一个现实社会中的例子对照的话，你可以这样认为：
假设已有一台智能摄像头，首先，您可以创建一个基于身份的策略，授权您和您的家庭成员使用他们的身份验证访问摄像头。这意味着只有得到授权的用户可以通过其身份验证访问摄像头。
接着，您可以创建一个基于资源的策略，规定只有在特定时间段内访问摄像头才会被允许。这意味着即使您和您的家庭成员都可以访问摄像头，他们也只能在被授权的时间段内访问，而在其他时间则不能访问。

这样，您可以使用基于身份和基于资源的策略来实现细粒度的访问控制，确保只有得到授权的用户可以访问您的智能摄像头，并且只能在被授权的时间段内进行访问。这可以帮助您更好地保护您的家庭安全和隐私。

而例子中的摄像头，就可以是 AWS 云上的资源，比如说后边会提到 S3 桶甚至是S3对象。

那么现在是不是就很简单就可以理解，为什么上边这个例子中为什么没有主体了吧。因为谁被附加了这个策略，谁不就是哪个 policy 中的主体了吗？