一文读懂AWS IAM

Concept

IAM是AWS云平台中负责身份认证，和权限控制的服务。AWS云虽然分了很多个区（Region），但IAM是Global，全局的。所以，它的数据和配置的更改，也是Eventually Consistent的。

Best Practices

在讲IAM的权限控制是怎么工作之前，先强调两个最重要的安全理念。

Grant Least Privilege

在AWS里面，每一个用户默认都是没有任何权限的。他甚至不能查看自己的密码或access key，丢失了也只能重新生成。

Lock Away Your AWS Account Root User

AWS账户开通的时候，你的登录邮箱和密码，就成为了这个账户下的超级管理员，它默认是什么都可以干的。所以，和在Linux下不要滥用root一样，不要用这个超级帐号做日常操作，而是创建一个有Full Administrator权限的用户。

How It Works?

权限控制有两个基本概念：

1.Authentication-确认是否为有效用户，是否允许登录/接入

2.Authorization-确认用户当前请求的操作（读写资源），是否合法

所以，IAM最重要就是管理Identity，和控制Resource的操作。

Identity/Principal

从资源访问的角度来看，使用AWS资源的其实不单单是具体的人，还可能是Application。所以，AWS里面的身份，分几种：

·User

·Application

·Federated User

·Role

能在AWS IAM控制台里创建的，只有User和Role。而User在创建的时候，可以指定它的访问类型。是凭借用户名密码在Console登录，还是使用Access Key ID及Secret通过API来访问，还是两者皆可。

要特别注意的是，User是直接操作AWS资源的用户，而不是你自己开发并部署在AWS的系统里面的用户。IAM的User是有数量限制的，最多5000个。

如果你开发的系统需要操作AWS资源，比如说上传文件到S3，那你需要用的是Federated User。通过OpenID Connect（如Google/Facebook）或者SAML 2.0（如Microsoft AD），你的系统用户可以在登录后换取代表某个AWS Role的临时token来访问AWS资源。

Authentication

访问和使用AWS资源有两种方式，一种是通过页面登录，也就是Console。一种是通过AWS API，也就是接口，包括CLI,SDK或HTTPS请求。

IAM User在Console页面登录需要提供AWS帐号名，IAM User名和密码。AWS帐号名是AWS云服务开通时，系统生成的一串数字，或者是你赋予的别名。它其实就是一个多租户系统里面的租户帐号。AWS还会为每个帐号提供一个独特的登录链接，比如我的测试帐号：https://kcawsfree.signin.aws.amazon.com/console。kcawsfree就是我帐号的别名。

而如果是使用API访问AWS，我们是需要用IAM User的Access Key ID及Secret来为这个HTTP请求生成签名的。为请求签名，是大多数的API集成的一种安全性考量。微信，支付宝等平台都这么做。为什么呢？

1.确认请求发起方是合法的，就是确保你就是你。

2.保护数据传输过程的安全，就是确保数据没被篡改。

3.防止重放攻击，就是确保一个请求不被多次使用，滥用或者冒用。

签名需要根据什么信息生成呢？可以说是包含了请求唯一性的所有信息：

请求的接口版本号请求的操作是什么（Action）请求的日期所有请求的参数等

AWS的请求样例：

https://iam.amazonaws.com/?Action=AddUserToGroup

&GroupName=Managers

&UserName=Bob

&Version=2010-05-08

&AUTHPARAMS

其实，如果你是使用AWS SDK或者CLI，它会根据你配置的Access Key自动签名。只有当你自己发起一个HTTP请求的时候，才需要自己实现签名的逻辑。

Authorization

所谓是否有足够的权限，就是验证以下三者在一个请求的场景下，是否被允许：

1.主体（Identity）

2.操作（Action）

3.资源（Resource）

AWS是通过策略（Policy）来定义权限（Permissions）的。最基本的策略有两大类。一种是Identity-based policy，另一种是Resource-based policy。前一种挂在User/Role/Group上面，用以定义这些被挂载的主体，能对什么资源进行怎样的操作。而后一种直接挂载在AWS资源上面，用以定义哪些主体可以对这个资源做什么样的操作。

AWS Policy的Permissions定义，在内部是通过一个JSON格式来表示的。我们来看一个样例：

{

  “Version”: “2012-10-17”,

  “Statement”: [

    {

      “Sid”: “ListAndDescribe”,

      “Effect”: “Allow”,

      “Action”: [

        “dynamodb:List*”,

        “dynamodb:Describe*”

      ],

      “Resource”: “*”

    },

    {

      “Sid”: “SpecificTable”,

      “Effect”: “Allow”,

      “Action”: [

        “dynamodb:BatchGet*”,

        “dynamodb:Get*”,

        “dynamodb:Query”,

        “dynamodb:Scan”,

        “dynamodb:BatchWrite*”,

        “dynamodb:Delete*”,

        “dynamodb:Update*”,

        “dynamodb:PutItem”

      ],

      “Resource”: “arn:aws:dynamodb:*:*:table/MyTable”

    },

    {

      “Sid”: “AllowAllActionsForEC2”,

      “Effect”: “Allow”,

      “Action”: “ec2:*”,

      “Resource”: “*”

    },

    {

      “Sid”: “DenyStopAndTerminateWhenMFAIsNotPresent”,

      “Effect”: “Deny”,

      “Action”: [

        “ec2:StopInstances”,

        “ec2:TerminateInstances”

      ],

      “Resource”: “*”,

      “Condition”: {

        “BoolIfExists”: {

          “aws:MultiFactorAuthPresent”: false

        }

      }

    }

  ]

}

这个策略控制了DynamoDB和EC2的访问权限。它看起来很复杂，但其实结构很清晰。这里面最主要的元素就是Effect，Action和Resource。它们确定了什么资源上的哪些操作，是被允许，还是禁止的。它们是AND的逻辑组合。

Statement里前两个Permission，允许用户获取DynamoDB里面的资源信息，但是只有MyTable这个表能做写操作。而后两部分允许用户对EC2做任何操作，但是停止和结束Instance则必须通过了MFA登录认证后才可以。

Policy Evaluation Logic

一个用户或者角色主体上，可以拥有多个不同的Policy。所以，Policy的权限验证逻辑，可谓相当复杂。在讲验证流程前，我再重复一次AWS权限的设计原则，这对流程的理解很重要。

·如果有显式的Deny，就禁止。

·Grant Least Privilege原则。如果没有显式赋予权限，也就是没有任何Policy为请求的资源和操作定义了Allow权限，那这个主体就没有权限（Implicit Deny）。

AWS对收到的操作请求，会根据以下的流程来判断这个请求的主体是否有操作权限：

1.Deny evaluation

2.AWS Organizations service control policies(SCP)

3.Resource-based policies

4.IAM permissions boundaries

5.Session policies

6.Identity-based policies

第一步，首先把2至6里面的所有policy的显式Deny拿出来。如果当前的请求属于Deny的范围，直接禁止操作。这个就是第一个原则。

第二步到第六步，是具体的policy。如果该主体有这个类型的policy存在，就按照第二个原则处理。如果没有，跳到下一个policy类别的检查。

那么多种的Policy类别，为什么是这个排列顺序呢？我是这么理解的：

1.Organization SCP作为组织级别策略，优先级最高。

2.Resource-based policy可以跨帐号赋予权限，级别比后面的高一些。

3.Permission Boundary的作用是提前为用户定义一个最大的权限范围，避免意外打开了权限的情况，所以比后面的级别要高。

4.Session policies是会话级别，允许临时赋予权限，所以比Identity-based policies高。

5.Identity-based policies是最稳定的，所以检查放在最后。

不过，这里有一个特例，就是Resource-based policy。如果它是Implicit Deny的情况，还是会继续后面的检查，不会阻止。还有一个复杂的情况是关于Session policy的，这个就不在本文解释了。

其实，即便逻辑复杂，判断是否有权限还是可以简单地总结为一句话：

只有具备显式的Allow，并且没有显式的Deny，才有权限。

或者

如果没有显式的Allow，或者有显式的Deny，就没有权限。

相关推荐: 【案例分析】糟糕的跟进邮件 vs. 优秀的跟进邮件

你讨厌跟进吗？你会尽可能地避免发送跟进邮件吗？你的答案很可能是肯定的。 没有什么比一个潜在客户突然变冷淡更糟糕的了，他们不接电话，也不回复邮件，这时你就要写跟进邮件了。 当你不得不跟进的时候，你应该用一个被证明有效果的跟进邮件，而不是用一封平庸甚至糟糕的跟进邮…