使用角色保护您的环境：第1部分

2015年12月15日，星期二

客户经常问我们：“提高整体安全性的最佳方法是什么？”在Trek10，我们开发了一个安全审核框架，用于审核客户环境并提供有关AWS账户可能偏离最佳实践的专业知识。我们首先介绍所有简单明了的情况，例如将仅VPN专用IP地址白名单用于SSH / RDP访问，重新认证旧的和潜在的恶意帐户，删除未使用的访问密钥，锁定对S3存储桶的访问等。

对于了解所有基础知识的客户，我们最好的建议（更好地保护关键IAM环境）是为所有ID和服务的所有访问实施AWS角色。到处利用角色具有许多巨大的安全优势。在这三部分的文章中，我们将介绍AWS角色的常见用例以及它们如何使您的帐户更安全-从将它们用于您的服务（例如EC2实例，Lambda函数等），到将它们用于联合身份验证。从您的身份提供商（例如Active Directory）访问AWS，或将其用于提升的控制台访问权限……这些角色将使您的CISO和审核员满意！

角色介绍

一般来说，您可以将IAM角色视为IAM用户ID。您向角色授予与用户相同的访问AWS资源的权限类型，并且向角色附加与用户ID相同的JSON策略。最大的区别是您不会像登录控制台中的ID那样“登录”角色。一个角色可以由多个不同的用户和服务承担或利用。例如，一个 用户 可以扮演角色或EC2 实例 可以使用角色权限启动（例如，EC2实例将具有访问S3存储桶的权限，而无需任何硬编码到应用程序中的访问密钥）。理解这些用例的最佳方法是深入研究更具体的示例。在本文的第1部分中，我们将以一个示例为例，从AWS管理控制台了解用户ID如何承担不同类型的角色。在 Part 2，我们将回顾跨帐户角色对MSP和咨询合作伙伴的作用。最后，在第3部分中，我们将回顾对SAML提供程序的SSO访问，并讨论AWS服务（例如EC2，Lambda，ECS等）如何利用角色。所有角色用例均允许用户/服务更简单和/或安全地获取访问AWS API的权限。

当用户ID“承担”角色时，它将获得与该角色关联的所有权限。 （当然，基于与用户ID关联的IAM策略，用户首先需要权限来承担此角色-稍后将对此进行详细介绍）。首先，让我们回顾一下可能由用户ID担任角色的每种情况，然后我们将深入研究每个用例。

举例来说，假设您利用OpsWorks进行配置管理。您有几个开发人员都可以在生产前通过OpsWorks部署应用程序，但是您只想向少量人员授予生产OpsWorks堆栈的权限。您可以简单地创建一个IAM组（例如“生产访问用户”），然后在不使用角色的情况下为该组分配适当的权限。另外，我们更喜欢一种利用角色假设来访问生产堆栈的方法。在这种情况下，将要求用户切换到特定角色以访问生产堆栈。

与直接向用户分配权限相比，使用角色具有许多优点：

• 虽然没有简单的复选框要求用户使用MFA登录到具有角色的AWS，但您可以单击复选框要求MFA以便承担角色。
• 角色有助于避免粗心的错误。要求您的用户采取单独的操作（即，扮演一个角色）来更改生产系统，可以帮助防止诸如用户不可避免地编辑生产堆栈而不是进行预生产的粗心大意的错误！
• 利用角色可以带来更强大的审核功能。例如，Trek10利用了第三方服务CloudCheckr，该服务可以在假设角色具有较高权限时生成电子邮件。我们还将SumoLogic用于记录来自CloudTrail的API调用，这使我们能够在承担特定角色时为客户生成支持凭单。
• 最后，简化了故障排除或检查生产变更。您可以只在假定角色的那些API调用中过滤日志，而不必疯狂地在CloudTrail中搜索生产更改。

接下来，我们将在管理控制台中演示其工作方式。

步骤1：建立角色

第一步是创建一个角色，您的用户将使用该角色访问OpsWorks控制台中的生产系统：

1. 导航到IAM> Roles >单击创建新角色。我们将其角色命名为“ production-opsworks-access”。
   
2. 对于“角色类型”，选择“跨账户访问角色”，然后选择“在您拥有的AWS账户之间提供访问权限（从技术上讲，您不会“切换” AWS账户，但这是正确的选择。稍后，我们将介绍实际确实切换AWS帐户的情况）。
3. 输入您的AWS帐号并单击Require MFA（要求MFA是使用角色的主要优势）。
4. 单击“下一步”跳过“附加策略”部分。我们将使用内联策略而不是使用AWS托管策略。
5. 验证您的配置，然后单击“创建角色”。

步骤2：为角色分配适当的权限

下一步是为该角色分配权限，以便所有假定该角色的用户都可以访问生产OpsWorks堆栈：

1. 导航回到IAM的“角色”部分，然后单击刚刚创建的角色。展开“内联策略”部分，然后单击以创建内联策略。选择自定义策略。为了创建策略，您将需要OpsWorks堆栈的Amazon资源名称（ARN）。
2. 要找到ARN，请导航到OpsWorks> Click Stack >单击堆栈设置，然后复制ARN。
   
3. 为所有OpsWorks生产堆栈权限创建策略。

现在，您已经创建了角色，并为其分配了适当的权限。

步骤3：授予用户承担角色的权限

现在，您已经创建了角色，但是您信任的访问生产堆栈的用户必须具有适当的权限才能承担此角色。为了回顾这一过程，我在沙箱中使用ReadOnlyAccess和所有必需的权限创建了“测试用户”，以编辑生产前的OpsWorks堆栈。

1. 目前，测试用户无法访问OpsWorks生产堆栈，因为他/她仅具有与pre-production-opsworks-access-group相关的权限。为了访问生产堆栈，他/他必须切换到production-opsworks-access角色。
2. 为了切换角色，必须给用户适当的权限。让我们为此创建另一个内联策略：
   
3. 现在，测试用户具有必要的权限，可以担任将提供对生产OpsWorks堆栈访问权限的角色。
   
4. 最后，让我们测试一下角色！在担任该角色之前，您可以在下面看到测试用户无权访问生产OpsWorks堆栈。
   
5. 接下来，让我们假设Production-opsworks-access角色。单击测试用户帐户名称中的帐户名称，然后单击“切换角色”。请记住，必须提供MFA！如果您尝试在不设置MFA的情况下切换角色，则访问将被拒绝。
   
   
6. 现在我们已经成功切换了角色，让我们看一下OpsWorks生产堆栈。如您所见，当切换到production-opsworks-access角色时，测试用户现在可以部署应用程序。

从理论上讲，不同的角色可以用于所有类型的访问，这增加了强制的MFA安全性和审核功能层。例如，可以创建一个根本没有任何权限的AWS ID，但允许该ID承担不同角色以访问不同基础架构的策略除外。

OpsWorks确实简化了隔离对不同环境的访问的能力，但是我们的许多客户都利用其他DevOps工具，例如EC2 Container Service上的Docker。在OpsWorks之外，定义对不同环境的访问并不是那么简单。对于这些用例，可以对具有环境标记和资源级别权限的基础结构施加相同类型的限制。然后，可以按照本博客文章中所述的类似方式利用角色。有关资源级权限的更多信息，请查看此内容。 AWS博客文章.

有疑问/意见吗？寻找安全审核？请随时与我们联系 [email protected].

继续到 Part 2.