故意泄漏AWS密钥

“永远不要将秘密检查到源代码管理中”是100％正确的规则之一，直到不正确为止。软件中没有通用的法律，最近我有理由打破这一法律。我将AWS密钥签入了Git存储库。 Ithen将这些提交推送到GitHub上的公共存储库中。我故意这样做，并且活着讲述这个故事。您几乎肯定不应该这样做，所以我想我会分享您这样做时的情况。

我可以想象您在想：“这个人是故意发布他的AWS凭证的？一定是个白痴。”我不同意您的结论，但请让我解释一下！

我的用例非常简单：delta-rs项目需要一个真正的S3bucket来进行一些集成测试。我决定建立一个真正的S3存储桶forour（只读）集成测试。幸运的是，我们的测试仅需要从存储桶中检索对象，以确认S3存储桶正确地将自己呈现为Delta表。如果我们需要在存储桶上进行“写入”操作，我将永远不会这样做。

AWS有一个称为IAM的集成访问控制框架，不要与“ AMI”字谜相混淆，Corey Quinn可以帮助您学习如何发音。 IAM允许以十几种或更多不同的方式针对AWS中的所有内容制定策略和角色。它切成薄片，确保您的水桶安全。它还配置了JSON，该功能非常实用，但是我必须将这些保留的内容保存在另一篇博客文章中。无论如何，这是我为存储桶设置的只读策略：

{＆＃34;版本＆＃34; ：＆＃34; 2012-10-17＆＃34; ，＆＃34;声明＆＃34; ：[{＆＃34; Sid＆＃34; ：＆＃34; VisualEditor0＆＃34; ，＆＃34;效果＆＃34; ：＆＃34;允许＆＃34; ，＆＃34;动作＆＃34; ：[＆＃34; s3：GetLifecycleConfiguration＆＃34; ，＆＃34; s3：GetBucketTagging＆＃34; ，＆＃34; s3：GetInventoryConfiguration＆＃34; ，＆＃34; s3：GetObjectVersionTagging＆＃34; ，＆＃34; s3：ListBucketVersions＆＃34; ，＆＃34; s3：GetBucketLogging＆＃34; ，＆＃34; s3：ListBucket＆＃34; ，＆＃34; s3：GetAccelerateConfiguration＆＃34; ，＆＃34; s3：GetBucketPolicy＆＃34; ，＆＃34; s3：GetObjectVersionTorrent＆＃34; ，＆＃34; s3：GetObjectAcl＆＃34; ，＆＃34; s3：GetEncryptionConfiguration＆＃34; ，＆＃34; s3：GetBucketObjectLockConfiguration＆＃34; ，＆＃34; s3：GetBucketRequestPayment＆＃34; ，＆＃34; s3：GetObjectVersionAcl＆＃34; ，＆＃34; s3：GetObjectTagging＆＃34; ，＆＃34; s3：GetMetricsConfiguration＆＃34; ，＆＃34; s3：GetBucketOwnershipControls＆＃34; ，＆＃34; s3：GetBucketPublicAccessBlock＆＃34; ，＆＃34; s3：GetBucketPolicyStatus＆＃34; ，＆＃34; s3：ListBucketMultipartUploads＆＃34; ，＆＃34; s3：GetObjectRetention＆＃34; ，＆＃34; s3：GetBucketWebsite＆＃34; ，＆＃34; s3：GetBucketVersioning＆＃34; ，＆＃34; s3：GetBucketAcl＆＃34; ，＆＃34; s3：GetObjectLegalHold＆＃34; ，＆＃34; s3：GetBucketNotification＆＃34; ，＆＃34; s3：GetReplicationConfiguration＆＃34; ，＆＃34; s3：ListMultipartUploadParts＆＃34; ，＆＃34; s3：GetObject＆＃34; ，＆＃34; s3：GetObjectTorrent＆＃34; ，＆＃34; s3：GetBucketCORS＆＃34; ，＆＃34; s3：GetAnalyticsConfiguration＆＃34; ，＆＃34; s3：GetObjectVersionForReplication＆＃34; ，＆＃34; s3：GetBucketLocation＆＃34; ，＆＃34; s3：GetObjectVersion＆＃34; ]，＆＃34;资源＆＃34; ：[＆＃34; arn：aws：s3 ::: deltars＆＃34; ，＆＃34; arn：aws：s3 ::: deltars / *＆＃34; ]}]}

我还设置了一个AWSBudget来提醒网购此举是否会花掉真钱。我当前在该AWS账户中的每月费用几乎为1.50美元，因此我的预算设置为，如果/当此开始每月花费我数美元以上时，AWS会向我发送电子邮件，以便我想出办法来节省我的钱钱。

最后，我为集成测试创建了一个IAM用户。此IAM用户已附加上面列出的单个IAM策略。然后，我获取了IAM用户的AWS访问密钥和私钥ID，并将其签入Git。

准备完集成测试后，我在太平洋标准时间13:05提出了我的pullrequest。在将代码推送到GitHub时，世界上的机器人会立即识别出任何类似于AWS访问密钥的东西，其中大多数意图是恶意的，但有些旨在帮助像我这样的开发人员犯下愚蠢的错误。

我们已经知道，属于IAM用户deltars-ro的AWS访问密钥AKIAX7EGEQ7FT6CLQGWH以及相应的密钥在以下网址在线公开可用：https://github.com/rtyler/delta.rs/blob/b3581ee06eee26d971bd3b76bb788c85ecf0c6c0c/rust/ tests / s3_test.rs。

您的安全性对我们很重要，并且您帐户的IAM凭证的暴露给您的AWS帐户带来安全风险，可能导致未经授权的活动产生过多费用，并违反AWS客户协议或与我们有关管理您对我们服务使用的其他协议。

为了保护您的帐户免遭过多的费用和未经授权的活动，我们已将“ AWSCompromisedKeyQuarantine” AWS托管策略（“隔离策略”）应用于上述IAM用户。应用于用户的隔离策略通过限制高风险AWS服务的权限来保护您的账户。您可以通过以下网址查看该策略：https://console.aws.amazon.com/iam/home#policies/arn:aws： iam :: aws：policy / AWSCompromisedKeyQuarantine $ jsonEditor？section = permissions。

为了安全起见，在遵循以下说明之前，请勿删除隔离策略。如果隔离策略导致生产问题，则可以将策略与用户分离。注意：只有具有管理员权限或有权访问iam：DetachUserPolicy的用户才能删除该策略。有关如何删除托管策略的说明，请访问：https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html#remove-policies-console。如果未经授权使用您的AWS账户，我们可以全权酌情为您提供让步。但是，不遵循以下说明可能会损害您获得让步的能力。

如果您认为自己收到的此说明有误，请立即通过支持案例与我们联系。

步骤1：删除或旋转公开的AWS访问密钥AKIAX7EGEQ7FT6CLQGWH。要删除IAM用户密钥，请转到此处的AWS管理控制台：https://console.aws.amazon.com/iam/home#users。要删除根用户密钥，请访问：https://console.aws.amazon.com/iam/home#security_credential。

如果您的应用程序使用公开的访问密钥，则需要更换密钥。要替换密钥，请先创建第二个密钥（届时两个密钥都将处于活动状态），然后修改您的应用程序以使用新密钥。然后，通过单击“使无效”来禁用（但不要删除）公开的密钥。控制台中的选项。如果您的应用程序有任何问题，您可以重新激活公开的密钥。当您的应用程序使用新密钥完全正常运行时，请删除公开的密钥。

注意：仅旋转或删除外露的钥匙可能不足以保护您的帐户，请参阅步骤2。

步骤2：检查您的CloudTrail日志中是否存在未经批准的活动，例如创建未经授权的IAM用户，策略，角色或临时安全凭证。为了保护您的帐户，请删除所有未经授权的IAM用户，角色和策略，并撤消所有临时凭据。

要删除未经授权的IAM用户，请导航至https://console.aws.amazon.com/iam/home#users。要删除未经授权的策略，请访问：https：//console.aws.amazon.com/iam/home#/policies。要删除未经授权的角色，请访问：https://console.aws.amazon.com/iam/home#/roles。

可能已使用公开的AWS访问密钥AKIAX7EGEQ7FT6CLQGWH为IAM用户deltars-ro创建了未经授权的临时凭证。您可以按照此处概述的说明撤消临时凭证：https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_control-access_disable-perms.html#denying-access-to-credentials-issue-time 。也可以通过删除IAM用户来撤销临时凭据。注意：删除IAM用户可能会影响生产工作负载，因此应谨慎进行。

步骤3：检查CloudTrail日志以查看您的AWS账户是否有未经授权的AWS使用，例如未经授权的EC2实例，Lambda函数或EC2竞标价。您还可以通过登录AWS管理控制台并查看每个服务页面来检查使用情况。还可以检查计费控制台中的“计费”页面，以防意外使用。 https://console.aws.amazon.com/billing/home#/bill

请记住，任何区域都可能发生未经授权的使用，并且您的控制台一次只能向您显示一个区域。要在区域之间切换，可以使用控制台屏幕右上角的下拉菜单。

请采取措施以防止任何新的凭据公开暴露。请参阅http://docs.aws.amazon.com/general/latest/gr/aws-access-keys-best-practices.html上的“管理访问密钥的最佳做法”。

Amazon GuardDuty是一项AWS威胁检测服务，可帮助您持续监控和保护您的AWS账户和工作负载。在您的账户上启用Amazon GuardDuty可以使您进一步了解恶意或未经授权的活动，提醒您采取措施以减少受到伤害的风险。要了解更多信息，请访问：https://aws.amazon.com/guardduty。

如果您有任何疑问，可以通过访问帐户支持中心中新创建的支持案例与我们联系。如果看不到新案例，则可以从以下支持中心创建案例：https://console.aws.amazon.com/support/home?#/

我还在太平洋标准时间13:09收到了来自两个第三方服务GitGuardian的电子邮件，而太平洋标准时间14:56也收到了泄漏.io的电子邮件。伙计们，可以尝试一下，但是在我执行git push的几秒钟内，AWS已经在它之上。

我忽略了第三方服务，并回复了AWS支持案例，让他们知道我的披露实际上是故意的。支持人员一定会翻过双眼，然后提醒我负责该帐户的收费，但仍建议我：

通常这个故事结局不好。我是有目的地并按计划进行的。我个人知道（我的一个朋友的朋友！）GitHub上有泄露AWS密钥的事件（我发誓！）。发生错误的git将本地凭证文件添加到个人但公共存储库中。由于未定期检查链接到AWS账户的电子邮件账户，因此在撤销密钥之前，滥用该密钥在AWS账单上累积了数百美元。

如果您将类似于AWS密钥的内容添加到公共存储库，网站或互联网上的任何内容，恶意参与者将下载密钥并尝试在您的AWS账户中启动服务。通常是加密货币矿工或垃圾邮件网关，任何花费大量金钱的东西，他们很高兴您自愿支付。