今天我们来对 AWS 的身份认证和访问管理服务 - Identify and Access Management（IAM）进行一个基本介绍。

IAM 的作用

身份鉴别，即对 AWS 进行访问的实体是否是一个合法用户。

访问管理，即用户对 AWS 进行的操作是否被允许授权

IAM 身份

AWS 中有以下几种 IAM 身份（Identities）

Root user

创建 AWS account 时的用户，拥有该账户的全部权限。最佳实践是用该用户来创建其他的 IAM User 来进行后续的工作，非必要不使用 root user 登录 AWS account。

User

通常就是指人类用户。

Group

Group 是一组通常需要相同访问权限的 User 的集合。比如在一个公司当中的开发部门可以是一个 Group，测试部门可以是另外一个 Group 等。Group 的好处是便于为需要相同访问权限的用户进行管理，因此只需要在 Group 级别进行访问策略的创建和修改等操作，而不用对单个用户进行操作。

Role

Role 可以理解成一个马甲

首先它提供的是一种临时性的访问授权（Temporary Access），这样做可以提高安全性。

其次它非常灵活，可以给不同的合法对象使用，比如 IAM User, AWS services, App 等。下面列出了几种典型的使用场景：

• 有多个 AWS accounts 的组织机构需要进行跨账户的访问

• 运行在 Amazon EC2 上的应用程序

• 一个 AWS service 需要访问其它的 AWS services

• 一个经过了第三方认证的外部用户

AWS 凭证（ credentials）类型

在 AWS 中有三种 credential 类型：

• 用户名和密码，即 username 和 password，最为常见的一种凭证类型。通常由 IAM User 在登录 AWS Management Console 时使用。

• 多因子认证 - Multi-factor Authentication，是在用户名和密码凭证的基础上提供的一种额外的安全机制，可以由硬件或软件生成一个一次性的时效性口令（Token）。

• 访问密钥 - access key，

IAM 策略（IAM Policy）机制基础

IAM 请求的上下文（IAM Request Context）

为了更好地了解 IAM Policy，首先要知道构成一个 IAM Policy 的三要素：请求主体（principal），动作（action）和资源（resource）。IAM 在收到一个访问请求时，就会基于这三要素的内容进行评估。你可以把三要素理解成一个句子的主谓宾 - 主体是谁，要执行什么操作和操作的对象。这三要素组成了一个 IAM 请求的上下文。

主体可以是 IAM User, external user, IAM Role, App 等；

动作可以是创建，读取，删除等操作；

资源就是 AWS 上的 resources。

在定义一个 IAM policy 时，通常需要对这三要素进行适当的描述。Policy 的语法格式时 JSON。以下是一个 policy 的示例：

{  "Version": "2022-09-22",  "Statement": [    {      "Sid": "ListObjectsInBucket",      "Effect": "Allow",      "Action": "s3:ListBucket",      "Resource": ["arn:aws:s3:::mybucket"]    },    {      "Sid": "AllObjectsActions",      "Effect": "Allow",      "Action": "s3:*Object",      "Resource": ["arn:aws:s3:::mybucket/*"]    }]}

还可以在 policy 中增加 Condition 选项，从而指定要完成授权还需要满足哪些额外的条件，例如：

"Condition" : { "StringEquals" : { "aws:username" : "JohnDoe" }}

策略类型（Policy Types）

Identity-based policies

又称为 IAM Policies。基于身份的策略通常关联到 IAM identities，如 IAM User, IAM Group 以及 IAM Role。有三种类型的 Identity-based policies:

• AWS Managed - AWS 预先设定好的一些策略

• Customer Managed - 客户自定义的策略

• Inline - 这种策略通常是 1 对 1 的绑定关系

Resource-based policies

基于资源的策略都是 Inline 类型的，并且直接绑定到 AWS 资源上。最常见的 resource-based policies 是 AWS S3 bucket policies 和 IAM role trust policies。基于资源的策略需要指定被授予权限的主体（principal）。

Permission boundaries

权限边界用于进一步对 identity-based policy 的权限范围进行限制。相关联的实体权限将由 Permission boudaries 和 IAM policy 共同决定。增加 permission boundaries 的方法是定义一个 customer managed policy，并在 IAM policy 中增加相应的 Condition 元素来引用自定义的 policy。

AWS Organization SCPs

AWS SCPs 是一个用来集中管理多个 AWS accounts 的服务。如果一个 organization 的所有特性都被打开，那么就可以对任何或者所有的 accounts 应用 SCP（Service Control Policy）。SCP 可以指定一个 account，或者一组 account（也就是 organization unit，简称 OU）的权限范围（maximum permissions）。该权限范围的设定对于 account 的 root user 也是生效的。

ACLs

使用 ACLs 可以控制其它账户中的主体访问关联到 ACL 的资源的权限设定。ACLs 目前支持 Amazon S3 buckets 和 objects。

Session Policies

Session policy 是一种 inline 策略，用来将实体的 IAM policy 中授予的权限在某个 session 中进一步限制。

上面这几种策略中，Identity-based policy, Resource-based policy 和 ACLs 是 Grant（授权）；而 Permission boundaries, Session policies 和 SCPs 是 Guardrails（护栏）。结合下面的策略评估流程，能更好的理解这个概念。

策略评估流程

从上图可以看出，IAM 对权限评估的原则是：

• 所有操作的默认策略都是隐式的（implicit）拒绝（Deny）

• 只有显示的（explict）允许（Allow）策略才会得到允许授权

• 显式的拒绝策略可以覆盖显式的允许策略

• 基于资源的策略中的显式允许（explicit Allow）可以完成允许授权