在AWS的世界中，IAM(Identity Access Management)的地位可以说是举足轻重。在使用AWS所有服务的时候，都涉及到权限控制的问题，而IAM就是进行权限控制的根基。
IAM介绍
IAM用于对AWS资源进行权限控制，这些权限控制既可以应用于一组用户，也可以应用于个别用户。同时，IAM还能和其他的认证系统相结合，比如和Shibboleth, Microsoft ActiveDirectory的结合。同时还可以对访问信息进行Audit（使用AWS CloudTrail）。
四个重要的概念
用户（user）
每个用户可能有自己的用户名/密码，同时还有访问AWS资源的密钥（Access key ID and Secret access key），可用于在程序中访问AWS资源。
组（group）
组代表的是用户的组合，比如admin，manager，customer等等。
角色（Role）
角色可以理解为是policies的组合，比如：DBOperator可能会有操作DynamoDB数据库的权限。使用Role的可能是一个用户，也可能是一个AWS服务，比如Lambda。
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只能读取数据库。这是就可以这样设计：
| user | group | Roles | Policies |
|---|---|---|---|
| Luke | admin | DynamoReadWrite | DynamoRead,DynamoWrite |
| Lucy | customer | DynamoReadOnly | DynamoRead |
| Andrew | customer | DynamoReadOnly | DynamoRead |
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策略。
