AWS IAM群组和角色最佳实践

将应用转移到亚马逊Web服务上会引发一些问题，即如何更好地管理云的各种部分，尤其是安全和身份识别。但是一些安全管理问题很难回答。

如何让多个用户访问单一的AWS账户？是否所有的用户应该有相同的访问授权？是否有途径允许应用执行需要额外授权的操作？AWS身份访问管理（IAM）可以通过基于角色和群组的访问控制帮助自动化一些安全操作。然而，在实施这些访问控制之前，你需要理解AWS账户和用户之间的区别。

AWS账户、用户和基于群组和角色访问控制基础

AWS IAM是一个管理AWS用户和用户授权的集中服务；它服务于很多和活动目录（Active Directory）相同的目的。AWS内的一个账户是一个实体，可以创建和管理资源，也负责账单。

一个部门内的所有的云用户可以登录到相同的AWS账户中，会导致两个问题。比如Linux中的根用户，账户所有者实际上可以在AWS云中做任何的支持操作。此外，用户比如共享证书，比如用户名和密码，来访问这个账户。这就限制了执行具体操作的用户的查询能力。

管理员可以创建和AWS账户相关的用户；用户需要有个人的证书和授权来访问AWS资源。

定义群组管理类似的用户

AWS IAM管理员可以分别为每一个用户分配授权，但是这样做也难以管理，尤其是随着用户数不断增加的时候。最好的方法就是用户群组。

群组是共享一套授权的用户集合，通常基于组织内的职能来创建。比如，你可能希望为需要大范围授权的系统管理员创建一个群组，为能够发布AWS资源的开发者创建一个群组，为在应用控制之下访问AWS资源的应用用户创建一个群组。

用户在群组中的增删是根据其职能需求改变而做出的变更。群组中授权增加、删除或者修改时，这些变更都会适用于所有用户。有些时候最好不要将授权直接分配给用户。

定义角色保护应用

角色是分配给AWS实体的一套授权，比如EC2实例，以便他们可以执行其他用户无法执行的任务。

比如，一个用户可能在应用中将数据存储到AWS S3 bucket中。为了保护应用数据的完整性，用户并没有被给予授权来直接对bucket进行编写。在这样的例子中，在运行应用的AWS EC2实例中使用角色将有助于分配授权。

使用角色进行跨账户访问

很多组织使用多种AWS账户管理其云资源。系统管理员可以创建角色，在一个账户中授权给用户，可以在另一个账户中访问资源。工作流有多重不同的分步骤需要多种账户时，这种跨账户的访问很有用。

这样开发者可以使用一个账户，同时测试者使用另一个账户。当代码准备好推送到测试过程时，如果他们有合适的跨账户访问的话，开发者可以编写测试者拥有的账户。

实践最小授权

一个由来已久的信息安全原则就是用户应该且只能拥有他们执行的职责的授权。这也就是最小授权原则，旨在最小化可信用户对于信息系统产生的不利影响。

在授权给群组时，也应该使用最小授权。只授权给有需要的群组的成员。如果一些群组成员需要额外的授权，然后创建额外的群组，并为他们分配额外的授权。需要额外授权的用户可以分配到这两个群组中。IAM群组和角色可以让系统管理员按需为用户和应用授权。