使用AWS安全服务最小化密钥暴露的实用步骤

本文详细介绍了如何利用Amazon Q Developer、IAM Access Analyzer、服务控制策略和数据边界等多种AWS安全服务与工具,构建多层防御策略,以检测和最小化长期凭证(如访问密钥)的暴露风险,并提供了具体的配置示例和最佳实践。

Practical steps to minimize key exposure using AWS Security Services

长期凭证暴露仍然是AWS客户事件响应团队(CIRT)观察到的安全事件中,威胁行为者最主要的入口点。威胁行为者对长期凭证或访问密钥的暴露及后续使用,给云环境带来了安全风险。此外,糟糕的密钥轮换实践、在多个用户之间共享访问密钥或未能撤销未使用的凭证,都可能导致系统暴露。

我们强烈不建议使用长期凭证,并鼓励向AWS Identity and Access Management(IAM)角色和联合访问迁移。虽然我们推荐的最佳实践是让客户不再使用长期凭证,但我们认识到这种转变可能并非对所有组织都立即可行。

针对长期凭证的非预期访问构建全面的防御,需要采取战略性的分层方法。该方法旨在弥合理想安全实践与现实操作约束之间的差距,为需要管理遗留AWS工作负载并使用长期凭证的团队提供可行的步骤。

在本文中,您将学习如何构建您的防御体系,从通过诸如Amazon Q Developer和AWS IAM Access Analyzer等服务识别现有风险和潜在暴露开始,以了解整个环境中的凭证风险。然后,通过服务控制策略(SCPs)和数据边界建立严格的边界,来控制凭证的创建和使用方式。在建立了这些机制后,您可以通过网络层面的控制来加强您的防御,这些控制有助于保护可能使用访问密钥的基础设施,例如实施AWS WAF和Amazon Inspector来帮助防范漏洞利用。最后,您将实施操作最佳实践,如自动秘密轮换,以维持持续的安全状态并最小化潜在泄露的影响。

检测当前访问密钥和暴露情况

审计当前访问密钥

为进行全面审计,组织应定期生成凭证报告,以识别IAM用户拥有的长期凭证以及其他相关信息,例如密钥上次轮换时间、上次使用时间、上次使用的服务和上次使用的区域。这些报告提供了对您的凭证状况的必要可见性,使您能够通过关注活动停滞的访问密钥、超出轮换策略的密钥以及来自陌生区域的意外使用模式,来发现未使用或可能已泄露的凭证。

检测暴露的访问密钥

凭证泄露的一个常见来源是无意中提交到公共代码仓库。当开发者意外地将凭证提交到公共仓库时,这些凭证可能会被对手使用的自动化扫描工具获取。代码扫描是一项基础步骤,有助于在敏感凭证被意外提交到代码仓库或部署到可能被利用的生产环境之前,及早发现这些关键安全问题。

Amazon Q Developer可以审查您的代码库,查找安全漏洞和代码质量问题,以在开发生命周期中改善应用程序的安全状况。您可以审查整个代码库,分析本地项目或工作空间中的所有文件,也可以审查单个文件。您还可以启用自动审查,在您编写代码时进行评估。

Amazon Q会审查您的代码是否存在以下问题:

  • SAST扫描 — 检测源代码中的安全漏洞。Amazon Q识别各种安全问题,如资源泄漏、SQL注入和跨站脚本攻击。
  • 秘密检测 — 防止代码中敏感或机密信息的暴露。Amazon Q审查您的代码和文本文件,查找诸如硬编码密码、数据库连接字符串和用户名等秘密信息。秘密发现项包含关于未受保护秘密的信息以及如何保护它。
  • IaC问题 — 评估基础设施文件的安全状况。Amazon Q可以审查您的基础设施即代码(IaC)文件,以检测配置错误、合规性和安全问题。

AWS Trusted Advisor还包含一个暴露访问密钥检查,可以检查流行的代码仓库中是否有已公开暴露的访问密钥,以及是否存在可能由泄露的访问密钥导致的不规则Amazon Elastic Compute Cloud(Amazon EC2)使用情况。

请注意,虽然这些都是有价值的安全工具,但它们无法检测存储在其扫描范围之外(如本地开发机器或外部系统)的秘密或访问密钥。它们应作为更广泛安全策略的一部分使用,而不是作为识别和防止凭证暴露的唯一方法。

在处理可能已泄露的访问密钥时,建议立即轮换密钥。请参阅有关如何为IAM用户轮换访问密钥的说明。

检测未使用的访问

除了识别暴露的凭证外,检测未使用的访问密钥有助于最小化攻击面。IAM Access Analyzer包含一个未使用访问分析器,用于查找过于宽松或已不再使用的访问权限,包括未使用的IAM角色、IAM用户的访问密钥、IAM用户的密码,以及活跃IAM角色和用户的服务与操作。在审查了由组织范围或账户特定分析器生成的结果后,您可以删除或修改不需要的权限。通过识别和撤销未使用的凭证和访问权限,如果凭证已被威胁行为者获取,您可以限制其影响。

通过实施这些工具,您可以深入了解整个环境中的凭证风险。这些功能的结合有助于发现嵌入的秘密、暴露的访问密钥以及需要删除的凭证。

预防性防护:建立数据边界

现在您已经了解了如何识别暴露或未使用的凭证,接下来让我们探讨如何使用SCP和资源控制策略(RCPs)来创建数据边界,并帮助确保只有受信任的身份才能从预期的网络访问受信任的资源。围绕您的AWS环境实施预防性防护,对于帮助防止未经授权的访问和潜在的访问密钥泄露至关重要。有关数据边界是什么以及如何建立的更多信息,请参阅《在AWS上建立数据边界》博客系列文章。

以下SCP拒绝IAM用户凭证在预期网络(企业无类别域间路由(CIDR)或特定虚拟私有云(VPC))之外被使用。该策略包含几个NotAction元素中的操作,如果不豁免,会影响服务访问。SCP和RCP的示例可以在data-perimeter-policy-examples中找到,该库是新修订策略的真相来源。以下示例已更新,以处理用户凭证在预期网络之外被使用的情况。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "EnforceNetworkPerimeterOnIAMUsers",
            "Effect": "Deny",
            "NotAction": [
                "es:ES*",
                "dax:GetItem",
                "dax:BatchGetItem",
                "dax:Query",
                "dax:Scan",
                "dax:PutItem",
                "dax:UpdateItem",
                "dax:DeleteItem",
                "dax:BatchWriteItem",
                "dax:ConditionCheckItem",
                "neptune-db:*",
                "kafka-cluster:*",
                "elasticfilesystem:client*",
                "rds-db:connect"
            ],
            "Resource": "*",
            "Condition": {
                "BoolIfExists": {
                    "aws:ViaAWSService": "false"
                },
                "NotIpAddressIfExists": {
                    "aws:SourceIp": [
                        "<my-corporate-cidr>"
                    ]
                },
                "StringNotEqualsIfExists": {
                    "aws:SourceVpc": [
                        "<my-vpc>"
                    ]
                },
                "ArnLike": {
                    "aws:PrincipalArn": [
                        "arn:aws:iam::*:user/*"
                    ]
                }
            }
        }
    ]
}

通过实施此网络边界,您可以降低凭证泄露导致未经授权访问和数据暴露的风险。威胁行为者试图从咖啡店或家庭网络使用窃取的凭证将被阻止,有助于限制非预期凭证访问的影响。

为了进一步增强纵深防御,您可以使用RCP来帮助保护您的数据,例如使用它们来控制哪些身份可以访问您的资源。例如,您可能希望允许组织内的身份访问组织内的资源。您可能还希望防止组织外部的身份访问您的资源。您可以使用RCP来强制执行此控制。您可以使用RCP来限制对资源的最大可用访问,并指定哪些主体(包括组织内部和外部的)可以访问您的资源。SCP只能影响您AWS组织内主体的有效权限。

通过实施以下RCP,您可以帮助确保,如果长期凭证意外暴露,组织外部的未授权用户将被阻止使用它们来访问您的关键数据和资源。该策略将拒绝Amazon Simple Storage Service(Amazon S3)操作,除非请求来自您的企业CIDR范围(带有aws:SourceIpNotIpAddressIfExists),或来自您的VPC(带有aws:SourceVpcStringNotEqualsIfExists)。请参阅支持RCP的AWS服务列表。SCP和RCP的示例可以在此GitHub存储库中找到,该库是新修订策略的真相来源。以下示例已更新,以处理本文讨论的用例。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EnforceNetworkPerimeter",
      "Effect": "Deny",
      "Principal": "*",
      "Action": [
        "s3:*",
        "sqs:*",
        "kms:*",
        "secretsmanager:*",
        "sts:AssumeRole",
        "sts:DecodeAuthorizationMessage",
        "sts:GetAccessKeyInfo",
        "sts:GetFederationToken",
        "sts:GetServiceBearerToken",
        "sts:GetSessionToken",
        "sts:SetContext",
        "aoss:*",
        "ecr:*"
      ],
      "Resource": "*",
      "Condition": {
        "NotIpAddressIfExists": {
          "aws:SourceIp": "<0.0.0.0/1>"
        },
        "StringNotEqualsIfExists": {
          "aws:SourceVpc": "<my-vpc>"
        },
        "BoolIfExists": {
          "aws:PrincipalIsAWSService": "false",
          "aws:ViaAWSService": "false"
        }
      }
    }
  ]
}

如果您已准备好开始迁移不再使用长期凭证,可以使用SCP来拒绝访问密钥的创建和拒绝更新现有密钥,以强制使用更安全的身份验证方法,如IAM角色和联合访问。该策略拒绝主体创建或更新AWS访问密钥。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": [
                "iam:CreateAccessKey",
                "iam:UpdateAccessKey"
            ],
            "Resource": "*"
        }
    ]
}

除了建立这些数据边界控制之外,让我们研究网络控制如何保护访问密钥操作的运行时环境。

网络控制:保护访问密钥的运行时环境

除了构建数据边界和使用SCP及RCP之外,保护使用这些访问密钥的计算和网络基础设施也至关重要。凭证通过受损的运行时环境暴露的风险使得基础设施保护成为访问密钥安全的关键组成部分,因为不良行为者经常以这些环境为目标来获得未经授权的访问。

安全组和网络ACL(NACLs)

使用在不同级别(如实例级别或子网级别)充当防火墙的网络级安全保护,以帮助防止未经授权的访问。

限制关键端口,如SSH(端口22)和RDP(端口3306),至关重要,因为它们是寻求未授权系统访问的不良行为者的主要目标。在您的安全组中开放管理端口会增加您的攻击面和安全性风险。使用AWS Systems Manager Session Manager有助于提供安全的远程访问,而无需暴露入站端口,从而减轻对堡垒主机或SSH密钥管理的需求。

NACLs通过在子网边界充当无状态数据包过滤器,有效阻止子网级别的访问。与保护单个实例的安全组不同,NACLs通过明确的允许/拒绝规则保护整个子网的入站和出站流量。它们在流量到达您的实例之前创建了一个关键的边界防御层。当作为纵深防御方法的一部分部署时,NACLs在应用程序层之间提供子网级别的隔离,在网络边缘阻止恶意流量模式,并在其他安全层受损时保持保护,有助于通过多个独立的控制点实现全面的网络安全。

对于超越NACLs的增强网络保护,AWS Network Firewall通过全面的VPC保护实现企业级边界防御。它结合了入侵防御系统、域名过滤、深度数据包检查和地理IP控制,同时利用Amazon收集的全球威胁情报自动保护您的云环境免受新出现的威胁。通过使用Network Firewall和AWS Transit Gateway集成,您可以在VPC和可用区之间实施一致的安全策略,并进行集中管理。

为了在组织范围内自动化和扩展网络安全,AWS Firewall Manager提供对Network Firewall规则和安全组策略的集中管理。随着组织的发展,Firewall Manager通过跨多个账户和组织单位自动部署通用安全组策略、清理未使用的组以及修复过于宽松的规则,来帮助维护安全性。

Amazon Inspector

为了帮助大规模识别非预期的网络暴露,请考虑使用Amazon Inspector。Amazon Inspector持续扫描AWS工作负载中的软件漏洞和非预期的网络暴露,帮助您在安全漏洞被利用之前识别和修复它们。

关键功能包括:

  • 软件包漏洞:软件包漏洞发现项识别您AWS环境中暴露于常见漏洞和暴露(CVE)的软件包。不良行为者可以利用这些未修补的漏洞来破坏数据的机密性、完整性或可用性,或访问其他系统。
  • 代码漏洞:代码漏洞发现项帮助识别可能被利用的代码行。代码漏洞包括缺少加密、数据泄漏、注入漏洞和弱加密。Amazon Inspector通过Lambda函数扫描及其代码安全功能生成发现项。它根据与Amazon Q合作开发的内部检测器来识别策略违规和漏洞。
  • 网络可达性:网络可达性发现项显示您的端口是否可通过互联网网关(包括位于Application Load Balancers或Classic Load Balancers后面的实例)、VPC对等连接或通过虚拟网关的VPN从互联网访问。这些发现项突出显示可能过于宽松的网络配置,例如管理不当的安全组、NACL或互联网网关,或者可能允许潜在恶意访问的配置。它可以帮助识别实例安全组上开放的SSH端口。

AWS WAF

作为对您的网络安全控制和漏洞管理的补充,AWS WAF通过过滤可能导致凭证暴露的恶意网络流量,提供了一个额外的防御层。

AWS WAF提供了几个托管规则组来防止未经授权的访问和常见漏洞:

  • AWS WAF欺诈控制账户创建欺诈防护(ACFP)规则组:ACFP使用请求令牌来收集有关客户端浏览器以及账户创建请求中人类交互程度的信息。该规则组通过按IP地址和客户端会话聚合请求,并按提供的账户信息(如物理地址和电话号码)聚合,来检测和管理批量账户创建尝试。此外,该规则组检测并阻止使用已被盗用的凭证创建新账户,有助于保护您的应用程序和新用户的安全状况。
  • AWS WAF欺诈控制账户接管防护(ATP)规则组:为了帮助防止可能导致欺诈活动的账户接管,ATP为您提供了对异常登录尝试和使用被盗凭证的登录尝试的可见性和控制。对于Amazon CloudFront分发,除了检查传入的登录请求外,ATP规则组还检查您的应用程序对登录尝试的响应,以跟踪成功和失败率。ATP根据其被盗凭证数据库检查电子邮件和密码组合,该数据库会随着在暗网上发现新的泄露凭证而定期更新。

操作最佳实践

为了补充这些保护层并维持持续的安全状况,请通过Secrets Manager实施自动凭证管理,以帮助促进整个环境中访问密钥的正确轮换和生命周期管理。这种自动化减少了人为错误,有助于促进及时的凭证更新,并在凭证泄露时限制暴露窗口。

建议至少每90天轮换一次密钥。Secrets Manager通过在计划上自动轮换秘密来提供帮助,确保凭证在没有人工干预的情况下定期更新。它还集中存储秘密,减少了多个用户之间共享访问密钥的可能性。使用Secrets Manager,您可以使用Lambda集成配置自动密钥轮换。

还有一个现有的解决方案可以部署,以实现大规模的自动访问密钥轮换。此模式通过使用AWS CloudFormation模板(在GitHub IAM密钥轮换存储库中提供)帮助您自动轮换IAM访问密钥。

如果您无法实施自动轮换,并且需要一种更快的方法来识别需要轮换的访问密钥,AWS Trusted Advisor有一个IAM访问密钥轮换的安全检查,用于检查在过去90天内未轮换的活跃IAM访问密钥。如果您需要执行手动轮换,可以使用该安全检查来深入了解环境中哪些访问密钥需要轮换。

检测异常IAM活动

最后,虽然保护IAM基础设施的主动措施至关重要,但拥有强大的检测和警报机制同样重要。无论您的努力多么细致,仍然存在不可预见的威胁或未经授权活动的可能性。这就是为什么一个全面的纵深防御策略应包括快速识别和响应异常IAM相关事件的能力。Amazon GuardDuty结合机器学习和集成的威胁情报,帮助保护AWS账户、工作负载和数据免受威胁。

GuardDuty扩展威胁检测自动关联不同数据源的多个事件,以识别AWS环境中的潜在威胁。当扩展威胁检测到可疑的活动序列时,它会生成全面的攻击序列发现项。该系统将单个API活动分析为弱信号,这些信号本身可能不指示风险,但当以特定模式一起观察到时,可以揭示潜在的安全问题。

此功能在AWS账户中激活GuardDuty时默认启用,无需额外配置即可提供保护。

与泄露凭证相关的特定攻击序列发现项是AttackSequence:IAM/CompromisedCredentials,其严重性标记为“关键”。该发现项告知您,GuardDuty检测到使用AWS凭证进行的一系列可疑操作,这些操作影响了您环境中的一个或多个资源。相同的凭证观察到多个可疑和异常威胁行为,导致更高的置信度表明这些凭证正在被滥用。

结论

本文概述的安全最佳实践提供了一种全面的多层方法,以减轻与长期凭证相关的风险。通过实施主动的代码扫描、自动密钥轮换、网络级控制、数据边界限制和威胁检测,您可以显著减少攻击面,并在完全迁移到临时凭证可行之前更好地保护组织的AWS资源。

虽然本文中提供的建议代表了一组充足的控制措施,可以使组织处于良好的安全状态,但根据每个环境的具体需求和风险状况,可能还需要采取额外的安全措施。关键在于采用整体、分层的凭证管理和保护方法。通过这样做,您可以弥合差距,直到完全过渡到临时凭证成为可能。

实施这些安全措施可以帮助降低风险,但长期凭证本质上带有安全风险。即使有严格的最佳实践和全面的安全控制,凭证泄露的可能性也无法完全消除。您应该考虑评估组织的安全状况,并尽可能优先考虑通过IAM角色和联合使用临时凭证。如果您有任何疑问或需要帮助,AWS随时为您提供支持。

comments powered by Disqus
使用 Hugo 构建
主题 StackJimmy 设计