转载

AWS安全最优最优实践#7：使用IAM角色和STS AssumeRole

我们已经讨论过了十大最优实践中的大部分，所以在跳到AWS配置领域的一些最优实践前，让我们总结一下关于IAM的讨论。这篇帖子将会总结关于控制个人的讨论。对个人的控制利用了IAM服务，而IAM服务则是通过利用角色来简化和创建一个更加安全的环境来实现。

但是首先，让我简单概括一下：

关闭根API访问金钥和密码金钥
在各处启动MFA令牌
减少拥有Admin权限的IAM用户数
为EC2使用各种角色
最低权限：限制IAM实体使用强有力/明确策略所能实现的功能
定期重置所有的密钥
在可能的地方使用IAM角色和STS AssumeRole
使用AutoScaling抑制DDoS影响
除非你是认真的，否则不要在任何EC2/ELB安全组中允许0.0.0.0/0网站
观察全局可读/列表可列示的S3桶策略

在这一系列帖子的前面一些帖子中，我们讲到了如何以及为什么你的EC2实例应该使用各种角色。它的前提是利用 AWS Security Token Service （安全令牌服务），使你的资源安全沟通和减轻管理负担变得更轻松。你既能够保证安全又能简化管理的频率是多少？虽然它们听起来像相互矛盾的两个方面，但是它们实际上是我们奋斗的目标。任何时候只要你能使用户安全变得更简单，你的方法就越可能得到采纳。反之，如果你使安全变得太复杂，它可能实际上在实践中会导致更加不安全。例如，如果你强迫所有用户使用它们根本不可能记住的随机产生的24位字符构成的密码，又有多少用户会将回归到写下密码或者将它存储在一个可能不符合安全规则的地方呢？当然，密码本身可能看起来增强了安全性，但是实际上，它可能导致了坏习惯，降低了安全性。

今天，我们将要为EC2扩展角色，讨论对IAM用户使用各种角色。这同样是为了使安全维护变得更安全，更简单。在本示例中，我将使用 Evident.io Demo AWS账户。Evident刚开始打算作为一个公司运行时，只有一个AWS账户，该账户被用来展示Evident Security Platform（ESP，Evident安全平台）和它创建自定义验证，安全检查和集成的能力。两个工程师使用一个账户，那确保完全安全会是很简单的吗？我们关闭了根API访问确保没有秘密金钥。然后，我们为两个管理员启动了MFA令牌。我们甚至为一些销售人员创建了拥有只读权限和特定策略的IAM用户，所以他们不会惹上麻烦。利用内置的ESP IAM Credential Rotation（ESP IAM证书重置）安全检查，我们预先找到需要重置的密钥。

现在，ESP被设计成一个企业平台，支持客户拥有成百上千甚至成千上万个账户（有一篇博客是关于SEP平台上职责划分的）。为了扩展我们的演示，我们添加了一小部分AWS账户，到现在，访问该演示账户的人数正在增加。我们可以像一开始做的那样，浏览每一个AWS账户，创建新用户，生成密码，限制那个用户的权限，但是那看起来像很多重复性的手工操作的步骤。更好的选择是利用我们已创建和保护的用户，只是使他们能够访问这些追加的账户。这听起来相当简单，实际上，它也是相当简单的。

AWS提供快速的演练，帮助你开始授权另一个账户中IAM用户对AWS账户的访问权限。现在，在很多情况下，你甚至可以拥有一个AWS主账户，该账户中没有资源运行，只是用于管理控制和计费访问。在我们的案例中，我们扩展了一个AWS账户，允许工程师和销售人员在控制台上通过轻点鼠标就可以对其他账户拥有相同的访问权限。

如果你有不止一个AWS账户，你就值得花费时间去浏览AWS概括的步骤，深入了解利用IAM用户和角色你可以实现的目标。

原文链接： http://blog.evident.io/blog/2015/9/4/aws-security-best-practice-7-use-iam-roles-with-sts-assumerole

活动推荐：Amazon CloudFormation 简介

（翻译/吕冬梅责编/王鑫贺）

订阅“AWS中文技术社区”微信公众号，实时掌握AWS技术及产品消息！

AWS中文技术社区为广大开发者提供了一个Amazon Web Service技术交流平台 ，推送AWS最新资讯、技术视频、技术文档、精彩技术博文等相关精彩内容，更有AWS社区专家与您直接沟通交流！快加入AWS中文技术社区，更快更好的了解AWS云计算技术。

正文到此结束