降低滥用AWS IAM用户访问密钥的风险

50977

本文为翻译文章，原文链接：https://ermetic.com/blog/aws/reducing-the-risk-from-misused-aws-iam-user-access-keys/

当被滥用或以其他方式无法安全使用时，AWS IAM用户访问密钥长期以来一直是在云环境中寻求立足点的攻击者最有效、最底的悬果之一。这些凭证是过去几年报告的一些高度破坏性的违规行为的主要罪魁祸首之一。Christophe Tafani-Dereeper对2021年主要云漏洞的审查强化了一个事实，即访问密钥仍然是主要的初始攻击载体。

这种常见配置的讽刺之处在于，通常存在一种安全、可访问和易于实现的替代方法，而不是使用访问密钥。随着AWS最近发布的IAM Roles Anywhere，这一事实比以往任何时候都更加真实。鉴于重大风险，为什么滥用访问密钥如此普遍，如何避免，IAM用户访问密钥的好处是否超过滥用风险？

在这篇文章中，我们回顾了使用访问密钥的风险，提供了过去漏洞的关键示例，并就如何减少导致风险的滥用提供了实用建议。

需要澄清的是，访问密钥本身不是亚马逊的安全问题或故障。安全问题源于其误用，这种滥用的责任完全在于客户，作为分担责任模式的一部分。所以要小心地使用它们！

背景

访问密钥是一种可以生成的凭证，用于对IAM用户进行身份验证。它们是访问密钥ID（以AKIA开头的字符串）和访问密钥密钥秘密的组合，访问密钥仅在创建访问密钥时显示。在任何时候，IAM用户最多可以有两个访问密钥，这些密钥可以被停用（即它们仍然存在，并且可以重新激活）并最终删除。

除非被适当的控件阻止（我们稍后将介绍其示例），否则活动访问密钥允许任何人，我们指的是绝对任何人，作为IAM用户进行身份验证，并访问授予它的任何权限。访问密钥本质上是永久凭据；如果泄露（例如，通过放置在公共资源中，如代码存储库或公共S3存储桶），它们会产生暴露于AWS环境的风险，因为它们可以使用与密钥关联的用户的所有权限被利用。

不幸的是，正如我们在下一节中显示的那样，访问密钥泄漏经常发生，并可能导致重大损害。

看看一些违规行为

Rami McCarthy的Github档案列出了从2014年6月至今的AWS漏洞（我将于2022年7月撰写本文）。该档案是一个很好的资源，可以随时了解和了解AWS环境的显著漏洞的详细信息——简而言之，可以从他人的错误中学习并避免类似的命运。如果你密切关注，你会发现许多漏洞源于一个访问密钥落入错误的人手中。

让我们看看几个例子，说明这些凭据泄露的不同方式。由于详细信息在上面的Github链接中，我们将仅简要讨论每个示例。

Nature’s Basket（2020）

MGaurav Chib的Medium博客中对这一漏洞的分析报告称，根用户的访问密钥（同样少！）在公共S3存储桶上的文件中被发现。这种曝光不仅允许对AWS帐户的初始访问，还允许对帐户进行完全访问和完全控制。这是一个很好的地方，可以指出，正是出于这个原因，您永远不应该为根用户生成或维护访问密钥，如果您这样做，您应该遵循AWS的建议，正确锁定访问密钥。

在公共S3存储桶等公开资源上托管凭据是相当常见的泄漏渠道。

凭证泄露来源：暴露资源

Animal Jam（2020）

据The Register报道，游戏公司Animal Jam有一个漏洞，由于在被盗的Slack频道上共享的访问密钥，导致泄露了4600万用户的记录。

出于与公共S3存储桶相同的原因，Slack频道是您永远不应该以明文存储或交流敏感信息的地方。Animal Jam漏洞是访问密钥凭据如何获得的又一个例子。即使没有漏洞，当在Slack频道上，凭据最终落入坏人手中的可能性也很大。

凭证泄漏源：Slack通道

Datadog（2016）

正如Datadog报道的那样，2016年，一名攻击者使用其自动配置和发布系统（其CI/CD管道的一部分）使用的访问密钥和SSH私钥来未经授权访问他们在AWS上的资源。具体而言，恶意行为者能够获得Datadog服务的凭据、服务元数据以及与Datadog共享的第三方集成凭据。

这一漏洞突出了两个有趣的点；首先，如果维护不正确，配置平台可以成为凭据泄露的来源；其次，您向其提供集成凭据的第三方供应商的数据泄露也可能产生您应该关注的额外风险或威胁载体。在下一节讨论第三方时，请记住后一点。

凭证泄露来源：配置平台和第三方

IAM用户的访问密钥——它们的价值是什么？

要了解如何降低访问密钥造成的风险，我们首先需要了解它们的实用性：为什么它们甚至被生成以及如何使用它们。这样做的最佳方法是查看某些常见用例——绝不是最佳实践——以及它们存在潜在风险的地方。下面，我们提出了这些用例或应用时首选做法的更安全的替代品。

对AWS的程序化访问

访问密钥最常见的实用程序可能是开发人员或DevOps专业人员寻求通过使用AWS命令行接口（CLI）或其他编程访问工具（例如Terraform）。

根据AWS文档，配置CLI会将凭据保存到特定的本地位置。正如我们在分析TeamTNT恶意软件时所描述的，网络犯罪分子并没有忽视这一现实，他们创建了恶意软件来定位这些确切的位置并收集存储在那里的凭据。请注意，为了实现风险，恶意软件需要在受害者的系统上执行，以便它能够收集AWS凭据——这将需要端点安全控制失败（这些控制不是由AWS管理或管理的；相反，是AWS客户的权限）。

同样，用户可以将这些凭据存储在环境变量中，攻击者也知道这些变量。我们看到了漏洞武器化的报告，例如Log4j漏洞和python ctx库中的漏洞，以收集环境变量——假设其意图是泄露存储在那里的凭据。

工作负载

此类凭据的另一个用例是允许工作负载访问AWS中的资源。您可能认为这是一个程序化访问的私人案例，但我们提请您注意，因为由于人类不参与使用访问密钥，缓解措施将有所不同。

第三方

幸运的是，另一个访问密钥用例，对于组织的云安全来说，它变得越来越不常见，即第三方供应商需要访问密钥，以便IAM用户可以访问客户的AWS帐户。

从安全的角度来看，这个用例是最糟糕的，因为根据定义，访问密钥被放置在技术和法律控制更少的地方，以确保它们不会被滥用。

通过停用或限制使用访问密钥来降低风险的三种方法

当前的现实是IAM用户在他们使用的大多数用例中几乎已经过时。IAM和安全从业者可以使用更新、更安全的替代品，这些替代品是推荐的最佳做法。如前所述，最近发布的AWS IAM Roles Anywhere使这一点更加真实。任何地方的组织，特别是云原生公司，都应该考虑他们是否需要IAM用户，特别是IAM用户访问密钥。

本节回顾了三种简单的方法来重新评估，并在可能的情况下清除环境中访问密钥的使用。我们还将讨论如何处理遗留实例，或者在您发现在访问密钥删除时太难使用“冷处理”的其他情况下。

1.使用访问密钥的替代品

最安全的凭据是那些你从未生成的凭据。因此，最好用更安全的方法取代IAM用户访问密钥的任何使用（当然，以后还要应用新方法）。

让我们回顾一下如何做到这一点的最常见和最直接的用例。

为人的程序性访问生成临时凭据

一般来说，在AWS中管理用户而不是使用IAM用户的最佳做法是使用身份提供商（IdP）集中管理您的用户，并为他们提供对不同AWS帐户的访问权限。当IdP是外部的时，您可以在IdP和AWS之间创建一个“联邦”（或用简单地说，信任）。然后，您可以使用SAML等身份验证协议对用户进行IdP身份验证，并从中接收令牌，以便与AWS一起使用以获得访问权限。在SAML的情况下，此令牌称为“SAML断言”。

AWS提供了一个名为AWS IAM身份中心的服务，允许一次性登录身份提供商访问多个服务。AWS IAM身份中心集中管理单点登录访问，从而更容易管理外部IdP、Microsoft Active Directory或在AWS IAM身份中心本身创建的身份中的身份。然后，作为存储永久凭据的替代机制，您可以配置使用AWS IAM身份中心对AWS的CLI进行身份验证的配置文件。AWS在本地缓存临时凭据（例如，在Mac上，在~/.aws/sso/cache文件夹中），您可以通过使用适当的标志指定该配置文件来进行CLI调用。

如果您不使用AWS IAM身份中心，其他工具允许您使用IdP对AWS CLI进行身份验证，例如saml2aws。此外，新的IAM Roles Anywhere功能允许使用证书颁发机构（CA）颁发的证书来创建临时凭据。这种方法是用户获得AWS资源权限的另一个重要手段，而不是IAM用户。Roles Anywhere主要是为了满足外部工作负载访问AWS资源的需求，但如果您不使用AWS IAM身份中心，您确实可以将其用作替代品。

使用IAM角色处理工作负载

为工作负载提供访问AWS资源的安全方法是使用IAM角色。为此，我们应该以不同的方式看待AWS工作负载和非AWS工作负载。

当您需要提供对AWS工作负载（例如EC2或Lambda函数）的访问权限时，真的没有理由使用静态凭据（如IAM用户访问密钥）手动加载它们，以访问资源。将IAM角色附加到工作负载中，并简单地为该IAM角色提供权限，这是非常简单的。例如，Lambda函数附带了一个已经附加的角色。这也被指定为AWS最佳实践。

从安全角度来看，这种方法确实是无需动脑筋的，因为它不涉及任何要管理的凭据，也不涉及任何可能泄露的凭证——并且IAM角色更容易使用。这种机制在数量级上比手动管理此类访问的IAM用户访问密钥更安全。

非AWS工作负载也可以使用IAM角色通过使用工作负载标识联合来生成临时凭据；实现这种方法的一个例子是spiffe-aws-assume-role。

此外，对于预置工作负载，新的Roles Anywhere是用户访问密钥的绝佳替代品。如前所述，该功能允许在CA和AWS帐户之间建立信任，之后CA签发的私人证书由AWS帐户信任。这些证书可能用于签署STS的临时凭据请求，承担特定的IAM角色。证书是一个更安全的替代方案，因为它们的维护和使用远不如永久明文访问密钥容易出错，通过使用Roles Anywhere，您可以为IAM角色使用短命凭据而不是永久凭据。虽然仍然非常新，但该功能似乎是一个非常有希望的机制，可以允许预机工作负载访问AWS资源。

使用IAM角色进行第三方访问

最后，如前所述，第三方确实没有理由要求IAM用户访问密钥作为获取跨帐户访问的方法。这种方法违反了将IAM角色与外部ID一起使用的常见AWS最佳实践。它还造成了一种令人不安的情况，即您愿意共享永久凭据，并允许组织以外的实体访问您的环境。

如果您被迫（例如出于业务原因）使用要求此类配置的第三方供应商，您应该认真考虑我们在下一节中描述的相关补偿控制，并尽可能应用它们。

2.防止不必要的IAM用户和访问密钥创建

作为一种预防性方法，您可以限制访问密钥的创建，甚至限制IAM用户本身在您的环境中的创建。通过使用拒绝访问iam:CreateAccessKey和iam:CreateUser权限的服务控制策略（SCP），您可以防止除特定身份外的所有身份生成访问密钥，甚至创建新的IAM用户。这种策略不会解决现有IAM用户及其访问密钥的风险——但它是防止创建不必要的IAM用户和访问密钥的有力方法。

阻止从特定管理员角色以外的帐户中的所有主体创建访问密钥的SCP（对于需要它的极端情况）如下所示：

{   
  “Version”: “2012-10-17”,
  “Statement”: [
    {
      “Sid”: “DenyCreateAccessKeyExceptForAdminRole”,
      “Effect”: “Deny”,
      “Action”: [
          “iam:CreateAccessKey”,
          “iam:CreateUser”
      ],
      “Resource”: “*”,
      “Condition”: {
        “StringNotLike”: {
          “aws:PrincipalARN”:”arn:aws:iam::*:role/AdminRole”
        }
      }
    }
  ]
}

3.监控您的环境

一旦您在环境中严格限制了访问密钥的使用，您应该跟踪当前库存和任何新库存的创建，以确保它们不会以某种方式仍然被滥用。

此外，如果您的环境中确实仍然有活动访问密钥，则可以使用以下所述的简单监控控件来保持环境的姿势。

存在更先进的工具和方法，但重点是，您可以通过应用非常简单的工具来有效和轻松地监控您的环境。

事件创建时触发通知

AWS允许您轻松配置EventBridge，以便在创建访问密钥时触发通知，例如发送到SNS主题的通知。

在短短几分钟内，我们能够设置EventBridge规则，该规则向SNS主题的所有订阅者发送电子邮件，提醒创建新访问密钥时（遵循CloudTrail事件CreateAccessKey）。

图1-显示创建EventBridge规则以触发SNS主题的屏幕截图，该主题在创建访问密钥时发送电子邮件

这种强大的设置可帮助您密切关注创建的访问密钥，以便您可以及时仔细查看它们，并检测它们是否以不符合您的安全策略的方式创建。

审核凭证报告

一个有效的工具是让您开始减少访问密钥的发生，您也可以定期使用该工具来跟踪其使用情况，您可以轻松地从IAM服务生成。这些报告创建了您环境中所有具有活动访问密钥的IAM用户的排序列表，以及访问密钥生成的时间，甚至最近使用时。

图2和图3展示了它们的使用：

图2-在AWS控制台上创建证书报告的刀片和按钮

显示IAM用户及其访问密钥信息的凭据报告图3 - 显示IAM用户及其访问密钥信息的凭证报告

使用AWS config来监视陈旧的访问密钥

在某些情况下，您需要在环境中使用有效的访问密钥。确保其使用的关键方法之一是在预定的频率上进行适当的旋转。AWS config有一个简单的开箱即用规则，可以找到访问密钥超过指定天数（默认值为90天）的IAM用户。

当你遇到现实时

众所周知，现实并不总是遵守我们的规则。您可能遇到情况迫使您保持访问密钥的使用——即使不是最佳的安全。

例如，一些第三方供应商仍然需要使用访问密钥而不是IAM角色作为他们的最佳实践，您的组织可能出于业务原因使用它们，迫使您遵守供应商的偏好。

或者，您的组织可能会对某些工作负载使用访问密钥，出于运营原因，用安全的替代方案替换它们可能需要时间，迫使您同时应对这一现实。

对于这些情况，我们在下面描述了可用于降低相关风险的某些控制措施。

安全存储

第一项操作是确保访问密钥安全存储。我们将研究一些此类用例——易于获得的常见解决方案，与在环境变量或明文形式中存储访问密钥相比，这些解决方案具有显著改进。（根据您的要求，您可能会找到更先进的解决方案，但此类解决方案超出了本文的范围。）

请记住，政策审查和轮换是下文所述的两种降低风险的方法，也适用于您被迫使用访问密钥的情况。

如果您在prem上运行工作负载，无法使用Roles Anywhere，也无法为其提供另一种可以联合到AWS帐户的身份，那么您有一些安全存储的解决方案，其中最著名的可能是Hashicorp的Vault。

虽然AWS IAM身份中心是推荐的方法，但如果您的组织不使用IdP，并且由于某种原因您无法使用AWS IAM身份中心，您仍然可以使用轻量级开源解决方案，如aws-vault，以更安全的密钥存储。此工具允许您将访问密钥存储在操作系统的密钥存储上（这比本地明文或环境变量安全得多）。当触发执行API调用时，aws-vault将为会话期间的后续调用生成和使用临时会话令牌。（您也可以使用标志指示它简单地使用永久访问密钥进行每次调用。）

政策审查

AWS拥有强大而灵活的机制来控制身份权限。您应该熟悉它们，并在适用的地方应用它们，特别是对于容易出现安全态势问题的身份。通过进行适当的政策审查，您可以降低违反身份的风险（当然，没有完全消除风险）。让我们简要探索一些你可以做的预防性事情。

维护最低特权原则

最小权限原则（POLP）涉及仅授予每个身份执行给定业务功能所需的权限。应用最小权限是此处端到端未涵盖的复杂任务，但请注意一些最小特权的最佳做法：

始终在操作级别和特定模式的特定资源或资源上指定IAM用户权限，并尽可能避免使用“*”
使用AWS托管策略时要小心，最好避免永久性地使用它们，因为它们往往非常宽松
查看Access Analyzer的策略验证器对附加到用户的IAM策略的安全建议

使用条件语句来限制访问

最后，为了进一步限制IAM用户的操作范围，您可以应用IAM策略（内联或客户管理），该策略拒绝IAM用户访问敏感的资源和/或操作（您也可以使用权限边界来实现这一点）。

除此之外，您还可以应用限制，设置有关IAM用户何时以及如何访问资源的条件。AWS有各种各样的条件键，可以在这种情况下使用。例如，让我们看看以下IAM政策：

{
  "Version":"2012-10-17",
  "Id":"ExampleIpConditionStatement",
  "Statement":[
     {
        "Sid":"networkdataperimeter",
        "Effect":"Deny",
        "Action": "*",
        "Resource":"*",
        "Condition":{
           "NotIpAddress":{
              "aws:SourceIp":[
                 "<WORKLOAD_IP>"
              ]
           },
           "Bool":{
              "aws:ViaAWSService":"false"
           }
        }
     }
  ]
}

（如果您想知道此处出现的aws:ViaAWSService密钥，我们邀请您阅读我们关于AWS条件密钥的博客文章。）

应用此IAM策略将限制IAM用户（以及访问密钥）仅允许从特定IP发送呼叫。如果您为工作负载生成此访问密钥，您可以指定您知道工作流应该从中运行的IP。这样做应该会让恶意行为者更难使用访问密钥，即使他们泄露，因为他们必须从指定工作流拨打电话的网络拨打电话。

回转

在IAM用户访问密钥的情况下，旋转意味着替换访问密钥（通过禁用并稍后删除它），并创建和使用新密钥。

这个过程的安全好处是显而易见的：即使它泄露，访问密钥也只能有效且可用于破坏环境，直到轮换发生。推荐的频率是90天，但您进行轮换的频率越高，您的曝光率就越低。

请注意，此过程容易出错，很可能导致访问密钥泄露或使用它们的服务中断。IAM角色的优势在于，使用它们可能被视为一个类似的过程（创建寿命短命且很快就会变得毫无意义的凭据），但您可以开箱即用，失败的风险很小。这使得IAM角色成为实现的首选选项，除非您被迫不要这样做。

当轮岗适用于工作负载时，请考虑投入时间来自动化轮岗流程。如果您已经在使用访问密钥授予对环境的工作负载访问权限，它可以（授予适当的权限）执行自己的密钥轮换，在安全存储位置创建和存储新访问密钥，并停用和删除以前的访问密钥。

自动化轮岗过程，您可以：

更频繁地进行轮岗
相信轮换已经进行，因为自动化比负责手动操作的人更可靠
尽量减少人类对明文凭据的暴露（只要您确保工作负载不会做任何粗心大意的事情，例如记录凭据）

小心保护生成和删除访问密钥的权限。在实现流程自动化时，请务必非常注意保护工作负载。

最后的话

IAM用户正在过时。在大多数情况下，AWS帐户根本不需要它们。如果您遇到业务需求取代此安全选择的情况，并且您被迫使用访问密钥，请记住，您可以采取措施保护它们，并降低使用它们所产生的风险。然而，您的重中之重应该是尽可能消除IAM用户访问密钥的使用，也许还有IAM用户的一般使用。

请记住：最安全的访问密钥是那些从未创建过的密钥！

如本文所述，对于大多数有人想使用IAM用户和访问密钥的用例，您有可靠而强大的替代方案，从安全角度来看要优越得多。这些替代方案利用IAM角色创建临时凭据，而不是像用户访问密钥这样的长寿命凭据。随着AWS IAM Roles Anywhere的发布，情况尤其如此。熟悉这些替代方案，并将其提供给组织中的开发人员。

如果您的AWS帐户与我们遇到的许多帐户一样，则由于遗留原因或缺乏最佳实践，访问密钥仍然被广泛使用。您必须有一个“负责任地”退役现有密钥的计划。为此，您需要能够查询CloudTrail日志，以了解访问密钥的使用方式和时间，以及调用来自哪里，以便您可以检测可能在本地存储此类密钥的工作负载。

了解追求“access key hygiene”是一个项目。除了这篇博客文章中提供的见解外，要与您的开发团队进行富有成效的对话，您需要对环境中的IAM用户活动拥有无可挑剔的控制——这说起来容易做起来难。这种可见性和控制深度对于流程的有效性至关重要，对于您不仅要确保当前对组织中开发人员的信任，而且要增强信任至关重要。