AWS IAM 基本概念

亚马逊访问权限控制（AWS Identity and Access Management ）

IAM用于对AWS资源进行权限控制，这些权限控制既可以应用于一组用户，也可以应用于个别用户。同时，IAM还能和其他的认证系统相结合，比如和Shibboleth, Microsoft ActiveDirectory的结合。同时还可以对访问信息进行Audit（使用AWS CloudTrail）

IAM使您能够安全地控制用户对 AWS 服务和资源的访问。
您可以使用 IAM 来创建和管理 AWS 用户和群组，并使用各种权限来允许或拒绝他们使用 AWS 资源

什么是 IAM？

AWS Identity and Access Management (IAM) 是一种 Web 服务，
可以帮助您安全地控制对 AWS 资源的访问。
您可以使用 IAM 控制对哪个用户进行身份验证 (登录) 和授权 (具有权限) 以使用资源。

当您首次创建 AWS 账户时，最初使用的是一个对账户中所有 AWS 服务和资源有完全访问权限的单点登录身份。此身份称为 AWS 账户根用户，使用您创建账户时所用的电子邮件地址和密码登录，即可获得该身份。强烈建议您不使用 根用户 执行日常任务，即使是管理任务。请遵守使用 根用户 的最佳实践，仅将其用于创建您的首个 IAM 用户。然后请妥善保存 根用户 凭证，仅用它们执行少数账户和服务管理任务。

基本概念

User

您可以在账户中创建与组织中的用户对应的各 IAM 用户，而不是与他人共享您的根账户凭证。IAM 用户不是单独的账户；它们是您账户中的用户。每个用户都可以有自己的密码以用于访问 AWS 管理控制台。您还可以为每个用户创建单独的访问密钥，以便用户可以发出编程请求以使用账户中的资源

每个用户可能有自己的用户名/密码，同时还有访问AWS资源的密钥（Access key ID and Secret access key），可用于在程序中访问AWS资源

Group

IAM组是 IAM 用户的集合。利用组，可为多个用户指定权限，以便更轻松地管理这些用户的权限。例如，您可能有一个名为 Admins 的组，并向该组授予管理员通常需要的权限类型。该组中的任何用户均自动具有分配给该组的权限。如果有新用户加入您的组织，并且需要管理员权限，则可通过将此用户添加到组来分配相应的权限。同样，如果您的组织中有人更换工作，则不必编辑该用户的权限，只需从旧组中将其删除，然后将其添加到合适的新组即可

组代表的是用户的组合，比如admin，manager，customer等等。

Role

IAM 角色 类似于用户，因为它是一个 AWS 实体，该实体具有确定其在 AWS 中可执行和不可执行的操作的权限策略。但是，角色旨在让需要它的任何人代入，而不是唯一地与某个人员关联。此外，角色没有任何关联的凭证（密码或访问密钥）。相反，如果将某个用户分配给角色，则将动态创建访问密钥并将该密钥提供给用户

角色可以理解为是policies的组合，比如：DBOperator可能会有操作DynamoDB数据库的权限。使用Role的可能是一个用户，也可能是一个AWS服务，比如Lambda。

Role就像一顶帽子一样，谁戴上了就具备相应权限，与User的区别:

• user可以在console上登录，有永久的认证信息，比如用户名和密码，但是role是无法登录的，也没有认证凭证
• user一般是给某个人使用，而role可以给任何有需要的人使用，当然也可以给user使用
• role通过临时生成的密钥来访问资源，默认1h，最长12h，在role的传导场景，最长是1h
• user只能存在于某个账号下，role可以跨账号, 但是user可以通过switch到其他role来达到跨账号的目的

Policies(访问策略)

访问策略定义的是对AWS资源的访问权限。它并不定义谁能访问AWS资源，而只是定义对哪个AWS资源能够进行什么样的操作。至于谁能访问什么资源，要取决于用户/组所具备的policy

在使用AWS创建各种策略的时候，可以使用这个工具（需登录）：https://policysim.aws.amazon.com/

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "VisualEditor0",
      "Effect": "Allow",
      "Action": [
        "dynamodb:BatchGetItem",
        "dynamodb:GetItem",
        "dynamodb:Query"
      ],
      "Resource": "arn:aws:dynamodb:eu-west-1:xxxxxxxx:table/ScoreTable>",
    }
  ]
}

上方这四个概念的例子

举一个最为简单的例子：在一个CMS系统中，所有数据都保存在DynamoDB中，系统中分为两类用户：admin和customer。其中admin可以对数据库进行写操作，而customer只能读取数据库。这是就可以这样设计：

Trust Relationships

还有一种可能就是，基于Account1创建了一些资源，想要允许Account2访问这些资源，这时就需要使用Trust Relationships了。其基本步骤包括：

• 在Account1中创建一个Role，具备访问AWS资源的权限
• 在IAM中创建Trust Relationship，这样Account1和Account2之间就具备这种信任关系了。
• Account1允许Account2使用assumeRole来获取Account1中的Role，这样Account2在访问Account1中资源的时候就相当于具备了Account1中的Role，而这个Role是具备访问Account1中AWS相关资源的权限的。

使用IAM的基本原则

避免使用Root账号

就和Linux中的root一样，应避免直接使用Root账号

最小授权原则

一定要尽量赋予用户最小的权限，否则可能存在安全隐患

当更改权限时，一定要进行全面测试

有些时候各种policy的组合会使最终访问权限变得非常复杂，因此一旦变更了policy，一定要注意进行严格的测试

策略发生冲突时

如果策略发生冲突的时候，一定是Deny策略会覆盖Allow策略