一文读懂AWS IAM

小提示：您能找到这篇{一文读懂AWS IAM}绝对不是偶然，我们能帮您找到潜在客户，解决您的困扰。如果您对本页介绍的一文读懂AWS IAM内容感兴趣，有相关需求意向欢迎拨打我们的服务热线，或留言咨询，我们将第一时间联系您！

< ">< font-size: 18px;">Concept

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

< ">< font-size: 18px;">Best Practices

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

< ">Grant Least Privilege

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

< ">Lock Away Your AWS Account Root User

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

< ">< font-size: 18px;">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还会为每个帐号提供一个独特的登录链接，比如我的测试帐号：< color: rgb(127, 127, 127);">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的访问权限。它看起来很复杂，但其实结构很清晰。这里面最主要的元素就是< background-color: rgb(242, 242, 242);">Effect，< background-color: rgb(242, 242, 242);">Action和< background-color: rgb(242, 242, 242);">Resource。它们确定了什么资源上的哪些操作，是被允许，还是禁止的。它们是AND的逻辑组合。

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

< ">Policy Evaluation Logic

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

< ">如果有显式的Deny，就禁止。

< ">Grant Least Privilege原则。如果没有显式赋予权限，也就是企业危机公关ppt没有任何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，就没有权限。