本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 修复检测到 GuardDuty 的安全发现
Amazon GuardDuty 生成的[调查](guardduty_findings.md)结果表明了与 GuardDuty 基础威胁检测和专用保护计划相关的潜在安全发现。以下各节介绍了针对这些场景的建议修复步骤。如果有备选修复方案，将在每个调查发现类型的描述中加以说明。您可以从[活动调查发现类型表](guardduty_finding-types-active.md)中选择某一调查发现类型，即可获取该类型的完整信息。
**Topics**
+ [修复可能失陷的 Amazon EC2 实例](compromised-ec2.md)
+ [修复可能失陷的 S3 存储桶](compromised-s3.md)
+ [修复可能有恶意的 S3 对象](compromised-s3object-malware-protection-gdu.md)
+ [修复可能受损的 EBS 快照](compromised-snapshot.md)
+ [修复可能遭到入侵的 EC2 AMI](compromised-ami.md)
+ [修复可能受损的 EC2 恢复点](compromised-ec2-recoverypoint.md)
+ [修复可能受损的 S3 恢复点](compromised-s3-recoverypoint.md)
+ [修复可能失陷的 ECS 集群](compromised-ecs.md)
+ [修复可能被泄露的凭证 AWS](compromised-creds.md)
+ [修复可能失陷的独立容器](remediate-compromised-standalone-container.md)
+ [修复 EKS 防护调查发现](guardduty-remediate-kubernetes.md)
+ [修复运行时监控调查发现](guardduty-remediate-runtime-monitoring.md)
+ [修复可能失陷的数据库](guardduty-remediate-compromised-database-rds.md)
+ [修复可能失陷的 Lambda 函数](remediate-lambda-protection-finding-types.md)
# 修复可能失陷的 Amazon EC2 实例
当 GuardDuty 生成[表明可能受损的 Amazon EC2 资源的查找类型](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-active.html#findings-table)时，您的**资源**将是**实例**。潜在的调查发现类型可能是 [EC2 调查发现类型](guardduty_finding-types-ec2.md)、[GuardDuty 运行时监控查找类型](findings-runtime-monitoring.md) 或 [EC2 恶意软件防护调查发现类型](findings-malware-protection.md)。如果导致该调查发现的行为是环境中的预期行为，则可以考虑使用[抑制规则](findings_suppression-rule.md)。
执行以下步骤来修复可能失陷的 Amazon EC2 实例：
1. **识别可能失陷的 Amazon EC2 实例**
调查可能遭盗用实例中的恶意软件，并清除任何发现的恶意软件。您可以用 [按需扫描恶意软件 GuardDuty](on-demand-malware-scan.md) 来识别可能受攻击的 EC2 实例中的恶意软件，或查看 [AWS Marketplace](https://aws.amazon.com/marketplace) 是否有可提供帮助的合作伙伴产品，来识别和删除恶意软件。
1. **隔离可能失陷的 Amazon EC2 实例**
如果可能，请使用以下步骤隔离可能失陷的实例：
1. 创建专用**隔离**安全组。隔离安全组只允许从特定 IP 地址进行入站和出站访问。确保没有允许 `0.0.0.0/0 (0-65535)` 流量的入站或出站规则。
1. 将**隔离**安全组关联到此实例。
1. 除新创建的**隔离**安全组以外，从可能失陷实例中移除所有安全组关联。
**注意**
现有跟踪的连接不会因安全组的更改而终止，只有未来的流量才会被新安全组有效阻止。
有关阻止来自可疑现有连接的更多流量的信息，请参阅《*事件响应手册*》中的 “[ NACLs 基于网络强制 IoCs 以防止更多流量](https://github.com/aws-samples/aws-customer-playbook-framework/blob/main/docs/Ransom_Response_EC2_Linux.md#enforce-nacls-based-on-network-iocs-to-prevent-further-traffic)”。
1. **确定可疑活动源**
如果检测到恶意软件，则根据您账户中的调查发现类型，识别并阻止 EC2 实例上潜在的未经授权活动。这可能需要执行一些操作，例如，关闭任何打开的端口、更改访问策略以及升级应用程序以修复漏洞。
如果您无法识别和阻止可能失陷 EC2 实例上的未经授权活动，我们建议您终止失陷的 EC2 实例，然后根据需要使用新实例进行替换。以下是可以保护您 EC2 实例的其他资源：
+ [Amazon EC2 最佳实践](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-best-practices.html)中的“安全和网络”部分
+ [适用于 Linux 实例的 Amazon EC2 安全组](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html)。
+ [Amazon EC2 中的安全性](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security.html)
+ [保护 EC2 实例的技巧 (Linux)](https://aws.amazon.com/articles/tips-for-securing-your-ec2-instance/)。
+ [AWS 安全最佳实践](https://aws.amazon.com//architecture/security-identity-compliance/)
+ AWS 《[安全事件响应技术指南》](https://docs.aws.amazon.com/security-ir/latest/userguide/security-incident-response-guide.html)。
1. **浏览 AWS re:Post**
浏览 [AWS re:Post](https://repost.aws/) 以获得更多帮助。
1. **提交技术支持请求**
如果您是 Premium Support 服务包的订阅用户，您可以提交[技术支持](https://console.aws.amazon.com/support/home#/case/create?issueType=technical)请求。
# 修复可能失陷的 S3 存储桶
GuardDuty 生成时[GuardDuty S3 保护查找类型](guardduty_finding-types-s3.md)，它表示您的 Amazon S3 存储桶已被盗用。如果导致该调查发现的行为是环境中的预期行为，则可以考虑创建[抑制规则](findings_suppression-rule.md)。如果预计不会出现这种情况，请按照以下建议步骤修复 AWS 环境中可能遭到入侵的 Amazon S3 存储桶：
1. **识别可能失陷的 S3 资源。**
S3 的 GuardDuty 调查结果将在查找结果详细信息中列出关联的 S3 存储桶、其 Amazon 资源名称 (ARN) 及其所有者。
1. **确定可疑活动源和使用的 API 调用。**
使用的 API 调用将在调查发现详细信息中作为 `API` 列出。源可能是 IAM 主体（IAM 角色、用户或账户），识别信息将在调查发现中列出。根据源类型，提供远程 IP 地址或源域信息，以便您评估源是否已获得授权。如果调查发现涉及来自 Amazon EC2 实例的凭证，则还将包含该资源的详细信息。
1. **确定调用源是否有权访问已识别的资源。**
例如，考虑以下情况：
+ 如果涉及 IAM 用户，其凭证是否可能已经泄露？ 有关更多信息，请参阅 [修复可能被泄露的凭证 AWS](compromised-creds.md)。
+ 如果 API 是从之前没有调用此类 API 历史记录的主体调用的，那么该源是否需要操作的访问权限？ 能否进一步限制存储桶权限？
+ 如果可以从**用户名** `ANONYMOUS_PRINCIPAL` 和**用户类型** `AWSAccount` 看到访问，则表明存储桶是公有的，并已被访问。这个存储桶应该是公有的吗？ 如果不是，请查看下面的安全建议，了解共享 S3 资源的替代解决方案。
+ 如果访问通过来自**用户名** `ANONYMOUS_PRINCIPAL` 和**用户类型** `AWSAccount` 的 `PreflightRequest` 调用成功实现，则表明存储桶已设置跨源资源共享（CORS）策略。这个存储桶是否应该设置 CORS 策略？ 如果不是，请确保存储桶不会无意中公开，并查看下面的安全建议，了解共享 S3 资源的替代解决方案。有关 CORS 的更多信息，请参阅《S3 用户指南》中的[使用跨源资源共享（CORS）](https://docs.aws.amazon.com/AmazonS3/latest/userguide/cors.html)。
1. **确定 S3 存储桶是否包含敏感数据。**
使用 [Amazon Macie](https://docs.aws.amazon.com/macie/latest/user/what-is-macie.html) 确定 S3 存储桶是否包含敏感数据，例如个人身份信息（PII）、财务数据或凭证。如果您的 Macie 账户启用了自动敏感数据发现，请查看 S3 存储桶的详细信息，以便更好地了解 S3 存储桶的内容。如果您的 Macie 账户禁用了此功能，我们建议您将其开启以加快评估速度。或者，您可以创建并运行敏感数据发现作业，以检查 S3 存储桶对象中的敏感数据。有关更多信息，请参阅[使用 Macie 发现敏感数据](https://docs.aws.amazon.com/macie/latest/user/data-classification.html)。
如果访问已获授权，则可以忽略调查发现。[https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/)控制台允许您设置规则来完全禁止单个发现，这样它们就不会再出现。有关更多信息，请参阅 [中的抑制规则 GuardDuty](findings_suppression-rule.md)。
如果您确定自己的 S3 数据已被未授权方公开或访问，请检查下面的 S3 安全建议，以收紧权限并限制访问。适当的修复解决方案取决于特定环境的需求。
## 基于特定 S3 存储桶访问需求的建议
**下表根据特定的 Amazon S3 存储桶访问需求提供了相应的建议：**
+ 要集中限制对您的 S3 数据的公开访问，请使用 S3 阻止公共访问功能。可以通过四种不同的设置为接入点、存储桶和 AWS 账户启用阻止公共访问设置，以控制访问的粒度。有关更多信息，请参阅《Amazon S3 用户指南》**中的[阻止公有访问设置](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html#access-control-block-public-access-options)。
+ AWS 访问策略可用于控制 IAM 用户如何访问您的资源或访问您的存储桶的方式。有关更多信息，请参阅《Amazon S3 用户指南》中的[使用存储桶策略和用户策略](https://docs.aws.amazon.com/AmazonS3/latest/userguide/security_iam_service-with-iam.html)**。
此外，您可以使用具有 S3 存储桶策略的虚拟私有云（VPC）端点来限制对特定 VPC 端点的访问。有关更多信息，请参阅《Amazon S3 用户指南》**中的[使用存储桶策略控制从 VPC 端点的访问](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-bucket-policies-vpc-endpoint.html)
+ 要暂时允许账户外部的可信实体访问您的 S3 对象，您可以通过 S3 创建一个预签名 URL。此访问权限是使用您的账户凭证创建的，根据使用的凭证，可持续 6 小时到 7 天。有关更多信息，请参阅 *Amazon S3 用户指南*中的[使用预签名 URLs下载和上传对象](https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-presigned-url.html)。
+ 对于需要在不同源之间共享 S3 对象的用例，您可以使用 S3 接入点创建权限集，这些权限集仅限于私有网络中的对象。有关更多信息，请参阅《Amazon S3 用户指南》**中的[通过接入点管理对共享数据集的访问](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-points.html)。
+ 要安全地向其他 AWS 账户授予对您的 S3 资源的访问权限，您可以使用访问控制列表 (ACL)，有关更多信息，请参阅 *Amazon S3 用户指南*中的[访问控制列表 (ACL) 概述](https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html)。
有关更多信息，请参阅《Amazon S3 用户指南》中的 [Amazon S3 的安全最佳实践](https://docs.aws.amazon.com/AmazonS3/latest/userguide/security-best-practices.html)。**
# 修复可能有恶意的 S3 对象
GuardDuty 生成时[S3 恶意软件防护调查发现类型](gdu-malware-protection-s3-finding-types.md)，它表示您的 Amazon S3 存储桶中新上传的对象包含恶意软件。资源类型是 **S3Object**。
使用以下建议步骤或能修复生成的调查发现：
1. 通过检查与发现结果ObjectDetails关联的 S3 来识别潜在的恶意的 S **3** 对象。
1. 隔离受影响的 S3 对象。如果您在为关联的 Amazon S3 存储桶启用 S3 恶意软件防护时启用了标记， GuardDuty 则必须为此对象分配了**恶意**标签。使用基于标签的访问控制（TBAC）来限制对此 S3 对象的访问。有关更多信息，请参阅 [使用基于标签的访问控制（TBAC）](tag-based-access-s3-malware-protection.md)。
如果您不再需要此对象，也可以选择将其删除或移至某个隔离的 S3 存储桶。有关删除 S3 对象的注意事项的信息，请参阅《Amazon S3 用户指南》中的[删除对象](https://docs.aws.amazon.com/AmazonS3/latest/userguide/DeletingObjects.html)**。
# 修复可能受损的 EBS 快照
何时 GuardDuty 生成处决:ec2/\$1 MaliciousFile 快照查找类型，它表示已在 Amazon EBS 快照中检测到恶意软件。执行以下步骤来修复可能受损的快照：
1. **识别可能受损的快照**
1. 识别可能受损的快照。EBS 快照的 GuardDuty 发现将在发现详情中列出受影响的快照 ID、其 Amazon 资源名称 (ARN) 和相关的恶意软件扫描详情。
1. 使用以下命令查看恢复点详细信息：
```
aws backup describe-recovery-point —backup-vault-name 021345abcdef6789 —recovery-point-arn "arn:aws:ec2:us-east-1::snapshot/snap-abcdef01234567890"
```
1. **限制访问受感染的快照**
查看和修改备份库访问策略以限制恢复点访问权限并暂停任何可能使用此快照的自动还原作业。
1. 查看当前的共享权限：
```
aws ec2 describe-snapshot-attribute --snapshot-id snap-abcdef01234567890 --attribute createVolumePermission
```
1. 删除特定的账户访问权限：
```
aws ec2 modify-snapshot-attribute --snapshot-id snap-abcdef01234567890 --attribute createVolumePermission --operation-type remove --user-ids 111122223333
```
1. 有关其他 CLI 选项，请参阅 [modify-snapshot-attribute CLI 文档](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-snapshot-attribute.html)。
1. **采取补救措施**
+ 在继续删除之前，请确保已确定所有依赖关系，并在需要时进行适当的备份。
# 修复可能遭到入侵的 EC2 AMI
何时 GuardDuty 生成处决:ec2/\$1 MaliciousFile AMI 查找类型，它表示已在亚马逊系统映像 (AMI) 中检测到恶意软件。执行以下步骤来修复可能受损的 AMI：
1. **识别可能遭到入侵的 AMI**
1. 的调查结果 AMIs 将在 GuardDuty 发现详情中列出受影响的 AMI ID、其 Amazon 资源名称 (ARN) 和相关的恶意软件扫描详情。
1. 查看 AMI 源图片：
```
aws ec2 describe-images --image-ids ami-021345abcdef6789
```
1. **限制对受感染资源的访问**
1. 查看和修改备份库访问策略以限制恢复点访问权限并暂停任何可能使用此恢复点的自动还原作业。
1. 从源 AMI 权限中移除权限
首先查看现有权限：
```
aws ec2 describe-image-attribute --image-id ami-abcdef01234567890 --attribute launchPermission
```
然后移除个人权限：
```
aws ec2 modify-image-attribute --image-id ami-abcdef01234567890 --launch-permission '{"Remove":[{"UserId":"111122223333"}]}'
```
有关其他 CLI 选项，请参阅[与特定账户共享 AMI-亚马逊弹性计算云](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-explicit.html#unsharing-an-ami)
1. 如果来源是 EC2 实例，请参阅：[修复可能遭到入侵的 Amazon EC2 实例](https://docs.aws.amazon.com/guardduty/latest/ug/compromised-ec2.html)。
1. **采取补救措施**
+ 在继续删除之前，请确保已确定所有依赖关系，并在需要时进行适当的备份。
# 修复可能受损的 EC2 恢复点
何时 GuardDuty 生成处决:ec2/\$1 MaliciousFile RecoveryPoint 查找类型，表示已在 EC2 Recovery Point Backup 资源中检测到恶意软件。执行以下步骤来修复可能受损的恢复点：
1. **确定可能受到威胁的 EC2 恢复点**
1. EC2 Recovery Point 的调查结果将在 GuardDuty 发现详情中列出其 Amazon 资源名称 (ARN) 以及相关的恶意软件扫描详情：
```
aws backup describe-recovery-point --backup-vault-name 021345abcdef6789 --recovery-point-arn "arn:aws:backup:us-east-1:111122223333:recovery-point:a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
```
1. 查看恢复详细信息以查找源图像：
```
aws backup get-recovery-point-restore-metadata --backup-vault-name 021345abcdef6789 --recovery-point-arn "arn:aws:backup:us-east-1:111122223333:recovery-point:a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
```
1. **限制对受感染资源的访问**
+ 查看和修改备份库访问策略以限制恢复点访问权限并暂停任何可能使用此恢复点的自动还原作业。如果您的环境使用资源标记，请适当标记恢复点以表明其正在调查中，并在必要时考虑暂停定时备份。
示例：
*aws backup tag-resource -—resource-arn arn:aws:backup:us-east-1:111122223333:recovery-point:a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 -—tags Investigation=Malware,DoNotDelete=True*
1. **采取补救措施**
+ 在继续删除之前，请确保已确定所有依赖关系，并在需要时进行适当的备份。
# 修复可能受损的 S3 恢复点
GuardDuty 生成处决时:S3/\$1 MaliciousFile RecoveryPoint 查找类型，表示已在 S3 Recovery Point Backup 资源中检测到恶意软件。执行以下步骤来修复可能受损的恢复点：
1. **识别可能受到威胁的 S3 恢复点**
1. S3 恢复点的 GuardDuty 发现将在查找结果详细信息中列出受影响的恢复点 ARN、备份保管库名称和相关的恶意软件扫描详细信息。
1. 查看恢复点详细信息：
```
aws backup describe-recovery-point --backup-vault-name 021345abcdef6789 --recovery-point-arn arn:aws:backup:us-east-1:123456789012:recovery-point:abcdef01234567890
```
1. **限制对受感染资源的访问**
+ 查看和修改备份库访问策略以限制恢复点访问权限并暂停任何可能使用此恢复点的自动还原作业。如果您的环境使用资源标记，请适当标记恢复点以表明其正在调查中，并在必要时考虑暂停定时备份。
示例：
```
aws backup tag-resource —resource-arn arn:aws:backup:us-east-1:111122223333:recovery-point:abcdef01234567890 —tags Investigation=Malware,DoNotDelete=True
```
有关更多详细信息，请参阅：[tag-resource CLI 命令](https://docs.aws.amazon.com/cli/latest/reference/backup/tag-resource.html)参考
1. **采取补救措施**
+ 在继续删除之前，请确保已确定所有依赖关系，并在需要时进行适当的备份。
# 修复可能失陷的 ECS 集群
发现可能受损的 ECS 集群表明已在您的 Amazon ECS 环境中检测到可疑或恶意活动。这可能包括未经授权的访问、恶意软件执行或其他使您的容器工作负载面临风险的恶意行为。
请按照以下步骤修复可能遭到入侵的 Amazon ECS 集群：
1. **识别可能受损的 ECS 群集和检测到的威胁（发现）**
受影响的 ECS 集群详细信息列在 GuardDuty 查找结果详细信息面板中。
1. **评估威胁/恶意软件的来源**
检查容器镜像中是否存在恶意软件。如果检测到恶意软件，请查看正在使用的容器镜像。[https://docs.aws.amazon.com//AmazonECS/latest/APIReference/API_ListTasks.html](https://docs.aws.amazon.com//AmazonECS/latest/APIReference/API_ListTasks.html)用于识别使用相同可能受损映像的所有其他正在运行的任务。
1. **隔离受影响的任务**
通过阻止受影响任务的所有网络流量（包括传入和传出）来阻止威胁。这种网络隔离通过切断与受损任务的所有连接来帮助防止任何持续的攻击。
**注意**：如果您确定此发现是由环境中的 expected/legitimate 活动触发的，则可以设置抑制规则以防止出现类似的发现。有关更多信息，请参阅 [中的抑制规则 GuardDuty](findings_suppression-rule.md)。
# 修复可能被泄露的凭证 AWS
GuardDuty 生成时[IAM 调查发现类型](guardduty_finding-types-iam.md)，它表明您的 AWS 凭据已被泄露。可能受损的**资源**类型是**AccessKey**。
要修复 AWS 环境中可能被泄露的凭证，请执行以下步骤：
1. **识别可能泄露的 IAM 实体和使用的 API 调用。**
使用的 API 调用将在调查发现详细信息中作为 `API` 列出。IAM 实体（IAM 角色或用户）及其识别信息将在调查发现详细信息的**资源**部分列出。所涉及的 IAM 实体的类型可由 **User Type (用户类型)** 字段确定，IAM 实体的名称将位于 **User name (用户名)** 字段中。调查发现中涉及的 IAM 实体的类型也可以由使用的 **Access key ID（访问密钥 ID）**确定。
对于以 `AKIA` 开头的密钥：
此类密钥是与 IAM 用户或 AWS 账户根用户关联的长期客户管理凭证。有关管理 IAM 用户的访问密钥的信息，请参阅[管理 IAM 用户的访问密钥](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html)。
对于以 `ASIA` 开头的密钥：
此类型的密钥是由 AWS Security Token Service生成的短期临时凭证。这些密钥仅存在很短的时间，无法在 AWS 管理控制台中查看或管理。IAM 角色将始终使用 AWS STS 证书，但也可以为 IAM 用户生成证书，有关更多信息， AWS STS 请参阅 [IAM：临时安全证书](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html#sts-introduction)。
如果使用了角色，**用户名称**字段将指示所用角色的名称。您可以 AWS CloudTrail 通过检查 CloudTrail 日志条目的`sessionIssuer`元素来确定密钥是如何请求的，有关更多信息，请参阅 [IAM 和中的 AWS STS 信息 CloudTrail](https://docs.aws.amazon.com/IAM/latest/UserGuide/cloudtrail-integration.html#iam-info-in-cloudtrail)。
1. **查看 IAM 实体的权限。**
打开 IAM 控制台。根据所用的实体类型，选择**用户**或**角色**选项卡，然后通过在搜索字段中键入已识别的名称来查找受影响的实体。使用 **Permission (权限)** 和 **Access Advisor (访问顾问)** 选项卡可查看该实体的有效权限。
1. **确定是否合法使用了 IAM 实体凭证。**
请与凭证用户联系以确定活动是否是有意进行的。
例如，确定此用户是否执行了以下操作：
+ 调用了 GuardDuty 调查结果中列出的 API 操作
+ 在 GuardDuty 调查结果中列出的时间调用了 API 操作
+ 从 GuardDuty 调查结果中列出的 IP 地址调用了 API 操作
如果此活动是对 AWS 凭证的合法使用，则可以忽略该 GuardDuty 发现。[https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/)控制台允许您设置规则来完全禁止单个发现，这样它们就不会再出现。有关更多信息，请参阅 [中的抑制规则 GuardDuty](findings_suppression-rule.md)。
如果无法确认此活动是否为合法使用，则可能是由于特定访问密钥、IAM 用户的登录凭证或整个 AWS 账户已被泄露。如果您怀疑自己的凭证已被泄露，请查看 “[我的 AWS 账户 可能已泄露](https://repost.aws/knowledge-center/potential-account-compromise)” 中的信息以解决此问题。
# 修复可能失陷的独立容器
当 GuardDuty 生成[表明容器可能受损的查找类型](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-active.html#findings-table)时，您的**资源类型将为** Conta **iner**。如果导致该调查发现的行为是环境中的预期行为，则可以考虑使用[抑制规则](findings_suppression-rule.md)。
要修复 AWS 环境中可能被泄露的凭证，请执行以下步骤：
1. **隔离可能失陷的容器**
以下步骤有助您识别可能有恶意的容器工作负载：
+ 打开 GuardDuty 控制台，网址为[https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/)。
+ 在**调查发现**页面上，选择相应的调查发现以查看调查发现面板。
+ 在调查发现面板的**受影响的资源**部分，您可以查看容器的 **ID** 和**名称**。
将此容器与其他容器工作负载隔离。
1. **暂停容器**
暂停容器中的所有进程。
有关如何冻结容器的信息，请参阅 [Pause a container](https://docs.docker.com/engine/api/v1.35/#tag/Container/operation/ContainerPause)。
**停止容器**。
如果上述步骤失败，并且容器没有暂停，请停止容器运行。如果您已启用该[快照保留](malware-protection-customizations.md#mp-snapshots-retention)功能， GuardDuty 将保留包含恶意软件的 EBS 卷的快照。
有关如何停止容器的信息，请参阅 [Stop a container](https://docs.docker.com/engine/api/v1.35/#tag/Container)。
1. **评估是否存在恶意软件**
评估恶意软件是否在容器的映像中。
如果访问已获授权，则可以忽略调查发现。[https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/)控制台允许您设置规则来完全禁止单个发现，这样它们就不会再出现。 GuardDuty 控制台允许您设置规则来完全禁止单个发现，这样它们就不会再出现。有关更多信息，请参阅 [中的抑制规则 GuardDuty](findings_suppression-rule.md)。
# 修复 EKS 防护调查发现
当您的账户启用 EKS 保护时，Amazon GuardDuty 会生成[发现](guardduty_findings.md)潜在的 Kubernetes 安全问题。有关更多信息，请参阅 [EKS 保护](kubernetes-protection.md)。以下各节介绍了针对这些场景的建议修复步骤。该特定调查发现类型的条目中描述了具体的修复措施。您可以从[活动调查发现类型](guardduty_finding-types-active.md)表中选择某一调查发现类型，即可获取该类型的完整信息。
如果生成的任何 EKS 防护调查发现类型符合预期，可以考虑添加 [中的抑制规则 GuardDuty](findings_suppression-rule.md)来阻止未来发出警报。
不同类型的攻击和配置问题可能会触发 GuardDuty EKS Protection 发现。本指南可帮助您确定针对您的集群的 GuardDuty 发现的根本原因，并概述了相应的补救指南。以下是导致 GuardDuty Kubernetes 发现的主要根本原因：
+ [可能的配置问题](#compromised-kubernetes-config)
+ [修复可能失陷的 Kubernetes 用户](#compromised-kubernetes-user)
+ [修复可能失陷的 Kubernetes 容器组（pod）](#compromised-kubernetes-pod)
+ [修复可能失陷的 Kubernetes 节点](#compromised-kubernetes-node)
+ [修复可能失陷的容器映像](#compromised-kubernetes-image)
**注意**
在 Kubernetes 版本 1.14 之前，该`system:unauthenticated`群组与默认关联且处于关联状态。`system:discovery` `system:basic-user` **ClusterRoles**此操作可能允许来自匿名用户的意外访问。集群更新不会撤销这些权限，这意味着即使您已将集群更新到 1.14 或更高版本，这些权限可能仍然存在。我们建议您取消这些权限与 `system:unauthenticated` 组的关联。
有关移除这些权限的更多信息，请参阅《Amazon EKS 用户指南》中的 [使用最佳实践保护 Amazon EKS 集群](https://docs.aws.amazon.com/eks/latest/userguide/security-best-practices.html)****。
## 可能的配置问题
如果调查发现表明存在配置问题，请参阅调查发现的修复部分，以获取有关解决该问题的指导。有关更多信息，请参阅以下指示配置问题的调查发现类型：
+ [Policy:Kubernetes/AnonymousAccessGranted](guardduty-finding-types-eks-audit-logs.md#policy-kubernetes-anonymousaccessgranted)
+ [Policy:Kubernetes/ExposedDashboard](guardduty-finding-types-eks-audit-logs.md#policy-kubernetes-exposeddashboard)
+ [Policy:Kubernetes/AdminAccessToDefaultServiceAccount](guardduty-finding-types-eks-audit-logs.md#policy-kubernetes-adminaccesstodefaultserviceaccount)
+ [Policy:Kubernetes/KubeflowDashboardExposed](guardduty-finding-types-eks-audit-logs.md#policy-kubernetes-kubeflowdashboardexposed)
+ 任何以结尾的发现 **SuccessfulAnonymousAccess**
## 修复可能失陷的 Kubernetes 用户
当 GuardDuty 发现中识别的用户执行了意外的 API 操作时，发现可能表明 Kubernetes 用户受到了攻击。您可以在调查发现详细信息的 **Kubernetes 用户详细信息**部分（位于控制台），或调查发现 JSON 的 `resource.kubernetesDetails.kubernetesUserDetails` 中识别用户。这些用户详细信息包括 `user name`、`uid` 和用户所属的 Kubernetes 组。
如果用户使用 IAM 实体访问工作负载，则可以使用 `Access Key details` 部分来识别 IAM 角色或用户的详细信息。请参阅以下用户类型及其修复指南。
**注意**
您可以使用 Amazon Detective，以进一步调查调查发现中识别的 IAM 角色或用户。在 GuardDuty 控制台中查看发现的详细信息时，选择 “在 Det **ective 中进行调查**”。然后从列出的项目中选择 AWS 用户或角色，在 Detective 中进行调查。
**内置 Kubernetes 管理员**：Amazon EKS 分配给创建集群的 IAM 身份的默认用户。此用户类型由用户名 `kubernetes-admin` 标识。
**要撤销内置 Kubernetes 管理员的访问权限：**
+ 从 `Access Key details` 部分中识别 `userType`。
+ 如果 `userType` 是**角色**，并且该角色属于 EC2 实例角色：
+ 识别该实例，然后按照 [修复可能失陷的 Amazon EC2 实例](compromised-ec2.md) 中的说明操作。
+ 如果 `userType` 是**用户**，或者是用户承担的**角色**：
1. [轮换该用户的访问密钥](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey)。
1. 轮换用户有权访问的任何密钥。
1. 查看 “[我的 AWS 账户 可能被泄露](https://repost.aws/knowledge-center/potential-account-compromise)” 中的信息以获取更多详细信息。
**OIDC 验证的用户**：通过 OIDC 提供程序授予访问权限的用户。通常，OIDC 用户使用电子邮件地址作为用户名。您可以使用以下命令查看您的集群是否使用 OIDC：`aws eks list-identity-provider-configs --cluster-name your-cluster-name `
**要撤销 OIDC 验证的用户的访问权限：**
1. 在 OIDC 提供程序中轮换该用户的凭证。
1. 轮换用户有权访问的任何密钥。
**AWS-Auth ConfigMap 定义的用户** — 通过-auth 获得访问权限的 IAM 用户。 AWS ConfigMap有关更多信息，请参阅****《Amazon EKS 用户指南》中的[管理集群的用户或 IAM 角色](https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html)。您可以使用以下命令查看其权限：`kubectl edit configmaps aws-auth --namespace kube-system`
**要撤消 AWS ConfigMap用户的访问权限，请执行以下操作：**
1. 使用以下命令打开 ConfigMap。
```
kubectl edit configmaps aws-auth --namespace kube-system
```
1. 标识 mapRo **les 或 M** **apUsers 部分下的角色或用户**条目，其用户名与调查结果的 Kubernetes 用户详细信息部分中报告的用户名相同。 GuardDuty 参见以下示例，示例显示在调查发现中已识别管理员用户。
```
apiVersion: v1
data:
mapRoles: |
- rolearn: arn:aws:iam::444455556666:role/eksctl-my-cluster-nodegroup-standard-wo-NodeInstanceRole-1WP3NUE3O6UCF
user name: system:node:EC2_PrivateDNSName
groups:
- system:bootstrappers
- system:nodes
mapUsers: |
- userarn: arn:aws:iam::123456789012:user/admin
username: admin
groups:
- system:masters
- userarn: arn:aws:iam::111122223333:user/ops-user
username: ops-user
groups:
- system:masters
```
1. 将该用户从 ConfigMap。参见以下示例，示例显示已识别管理员用户。
```
apiVersion: v1
data:
mapRoles: |
- rolearn: arn:aws:iam::111122223333:role/eksctl-my-cluster-nodegroup-standard-wo-NodeInstanceRole-1WP3NUE3O6UCF
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:bootstrappers
- system:nodes
mapUsers: |
- userarn: arn:aws:iam::111122223333:user/ops-user
username: ops-user
groups:
- system:masters
```
1. 如果 `userType` 是**用户**，或者是用户承担的**角色**：
1. [轮换该用户的访问密钥](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey)。
1. 轮换用户有权访问的任何密钥。
1. 查看 “[我的 AWS 账户可能被泄露](https://aws.amazon.com//premiumsupport/knowledge-center/potential-account-compromise/)” 中的信息，了解更多详情。
如果调查发现没有 `resource.accessKeyDetails` 部分，则用户是 Kubernetes 服务账户。
**服务账户**：服务账户为容器组提供身份，可以通过以下格式的用户名进行识别：`system:serviceaccount:namespace:service_account_name`。
**要撤销对服务账户的访问权限：**
1. 轮换服务账户凭证。
1. 在以下部分查看有关容器组受攻击的指南。
## 修复可能失陷的 Kubernetes 容器组（pod）
当在该`resource.kubernetesDetails.kubernetesWorkloadDetails`部分中 GuardDuty 指定 pod 或工作负载资源的详细信息时，该 pod 或工作负载资源可能已受到威胁。 GuardDuty 发现可能表明单个 Pod 已被入侵，或者多个 Pod 已通过更高级别的资源遭到入侵。有关如何识别已被盗用的一个或多个容器组的指南，请参阅以下盗用场景。
**单个容器组盗用**
如果 `resource.kubernetesDetails.kubernetesWorkloadDetails` 部分中的 `type` 字段是**容器组**，则调查发现将识别单个容器组。名称字段是容器组的 `name`，`namespace` 字段是其命名空间。
有关识别运行容器组（pod）的 Worker 节点的信息，请参阅《Amazon EKS Best Practices Guide》**中的 [Identify the offending pods and worker node](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_identify_the_offending_pod_and_worker_node)。
**容器组通过工作负载资源被盗用**
如果 `resource.kubernetesDetails.kubernetesWorkloadDetails` 部分中的 `type` 字段识别**工作负载资源**（例如 `Deployment`），则该工作负载资源中的所有容器组很可能都已被盗用。
有关识别工作负载资源的所有容器组（pod）及其运行的节点的信息，请参阅《Amazon EKS Best Practices Guide》**中的 [Identify the offending pods and worker nodes using workload name](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_identify_the_offending_pods_and_worker_nodes_using_workload_name)。
**容器组通过服务账户被盗用**
如果调查结果在该`resource.kubernetesDetails.kubernetesUserDetails`部分中 GuardDuty 发现了服务帐户，则使用已识别服务帐户的 pod 很可能遭到入侵。如果调查发现报告的用户名具有以下格式，则该用户名为服务账户：`system:serviceaccount:namespace:service_account_name`。
有关识别使用服务账户的所有容器组（pod）及其运行的节点的信息，请参阅**《Amazon EKS Best Practices Guide》中的 [Identify the offending pods and worker nodes using service account name](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_identify_the_offending_pods_and_worker_nodes_using_service_account_name)。
识别所有遭盗用的容器组（pod）及其运行的节点后，请参阅**《Amazon EKS Best Practices Guide》中的 [Isolate the pod by creating a network policy that denies all ingress and egress traffic to the pod](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_isolate_the_pod_by_creating_a_network_policy_that_denies_all_ingress_and_egress_traffic_to_the_pod)。
**修复可能失陷的容器组：**
1. 识别攻击容器组的漏洞。
1. 实施针对该漏洞的修复程序并启动新的替换容器组。
1. 删除易受攻击的容器组。
有关更多信息，请参阅《Amazon EKS Best Practices Guide》**中的 [Redeploy compromised pod or workload resource](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_redeploy_compromised_pod_or_workload_resource)。
如果已为工作节点分配了一个允许 Pod 访问其他 AWS 资源的 IAM 角色，请将这些角色从实例中移除，以防止攻击造成进一步损害。同样，如果已为容器组分配了 IAM 角色，请评估您是否可以在不影响其他工作负载的情况下，从该角色安全删除 IAM 策略。
## 修复可能失陷的容器映像
当 GuardDuty 发现发现有 pod 受损时，用于启动 pod 的图像可能是恶意的或已被泄露的。 GuardDuty 调查结果可识别`resource.kubernetesDetails.kubernetesWorkloadDetails.containers.image`现场内的容器映像。您可以通过扫描恶意软件来确定映像是否是恶意的。
**修复可能失陷的容器映像：**
1. 立即停止使用该映像，并将其从映像存储库中删除。
1. 识别使用可能失陷的映像的所有容器组。
有关更多信息，请参阅《Amazon EKS Best Practices Guide》**中的 [Identify pods with vulnerable or compromised images and worker nodes](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_identify_pods_with_vulnerable_or_compromised_images_and_worker_nodes)。
1. 隔离可能失陷的容器组、轮换凭证并收集数据进行分析。有关更多信息，请参阅《Amazon EKS Best Practices Guide》中的 [Isolate the pod by creating a network policy that denies all ingress and egress traffic to the pod](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_isolate_the_pod_by_creating_a_network_policy_that_denies_all_ingress_and_egress_traffic_to_the_pod)。**
1. 删除使用可能失陷的映像的所有容器组。
## 修复可能失陷的 Kubernetes 节点
如果 GuardDuty 发现结果中标识的用户代表节点身份，或者发现结果表明使用了特权容器，则发现可能表示节点受损。
如果**用户名**字段具有以下格式，则用户身份是 Worker 节点：`system:node:node name`。例如 `system:node:ip-192-168-3-201.ec2.internal`。这表明攻击者已获得对节点的访问权限，并且正在使用节点的凭证与 Kubernetes API 端点进行通信。
如果调查发现中列出的一个或多个容器的 `resource.kubernetesDetails.kubernetesWorkloadDetails.containers.securityContext.privileged` 调查发现字段设置为 `True`，则调查发现表明使用了特权容器。
**修复可能失陷的节点：**
1. 隔离容器组、轮换凭证并收集数据进行分析。
有关更多信息，请参阅《Amazon EKS Best Practices Guide》中的 [Isolate the pod by creating a network policy that denies all ingress and egress traffic to the pod](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_isolate_the_pod_by_creating_a_network_policy_that_denies_all_ingress_and_egress_traffic_to_the_pod)。**
1. 识别在可能失陷的节点上运行的所有容器组使用的服务账户。查看其权限，并根据需要轮换服务账户。
1. 终止可能失陷的节点。
# 修复运行时监控调查发现
当您为账户启用运行时监控时，Amazon GuardDuty 可能会生成[GuardDuty 运行时监控查找类型](findings-runtime-monitoring.md)指明您的 AWS 环境中存在潜在安全问题的信息。潜在的安全问题表明您的 AWS 环境中的 Amazon EC2 实例、容器工作负载、Amazon EKS 集群或一组凭证遭到入侵。安全代理会监控来自多种资源类型的运行时事件。要识别可能受到威胁的资源，请在 GuardDuty 控制台中生成的查找结果详细信息中查看**资源类型**。以下部分介绍了针对每种资源类型的建议修复步骤。
------
#### [ Instance ]
如果调查发现详细信息中的**资源类型**为 **Instance**，则表示 EC2 实例或 EKS 节点可能受到攻击。
+ 要修复受攻击的 EKS 节点，请参阅 [修复可能失陷的 Kubernetes 节点](guardduty-remediate-kubernetes.md#compromised-kubernetes-node)。
+ 要修复受攻击的 EC2 实例，请参阅 [修复可能失陷的 Amazon EC2 实例](compromised-ec2.md)。
------
#### [ EKSCluster ]
如果调查结果详细信息中的**资源类型**为 **EKSCluster**，则表示 EKS 集群内的 Pod 或容器可能遭到入侵。
+ 要修复受攻击的容器组，请参阅 [修复可能失陷的 Kubernetes 容器组（pod）](guardduty-remediate-kubernetes.md#compromised-kubernetes-pod)。
+ 要修复受攻击的容器映像，请参阅 [修复可能失陷的容器映像](guardduty-remediate-kubernetes.md#compromised-kubernetes-image)。
------
#### [ ECSCluster ]
如果调查结果详细信息中的**资源类型**为 **ECSCluster**，则表示 ECS 任务或 ECS 任务中的容器可能受到威胁。
1. **确定受影响的 ECS 集群**
GuardDuty 运行时监控结果在调查结果的详细信息面板或调查结果 JSON 的`resource.ecsClusterDetails`部分中提供 ECS 集群的详细信息。
1. **确定受影响的 ECS 任务**
GuardDuty 运行时监控结果在查找结果的详细信息面板或调查结果 JSON 的`resource.ecsClusterDetails.taskDetails`部分中提供 ECS 任务的详细信息。
1. **隔离受影响的任务**
通过拒绝该任务的所有入口和出口流量来隔离受影响的任务。拒绝所有流量规则可以切断与任务的所有连接，从而帮助阻止已经开始的攻击。
1. **修复失陷的任务**
1. 识别攻击该任务的漏洞。
1. 实施针对该漏洞的修复程序并启动新的替换任务。
1. 停止易受影响的任务。
------
#### [ Container ]
如果调查发现详细信息中的**资源类型**为 **Container**，则表示独立容器可能受到攻击。
+ 要进行修复，请参阅 [修复可能失陷的独立容器](remediate-compromised-standalone-container.md)。
+ 如果调查发现是使用同一容器映像跨多个容器生成的，请参阅 [修复可能失陷的容器映像](guardduty-remediate-kubernetes.md#compromised-kubernetes-image)。
+ 如果容器访问了底层 EC2 主机，则其关联的实例凭证可能已泄露。有关更多信息，请参阅 [修复可能被泄露的凭证 AWS](compromised-creds.md)。
+ 如果潜在的恶意行为者访问了底层 EKS 节点或 EC2 实例，请参阅*EKSCluster*和*实例*选项卡下的建议补救措施。
------
## 修复被盗用的容器映像
当 GuardDuty 发现发现任务受损时，用于启动任务的图像可能是恶意的或已被泄露的。 GuardDuty 调查结果可识别`resource.ecsClusterDetails.taskDetails.containers.image`现场内的容器映像。您可以通过扫描恶意软件来确定映像是否有恶意。
**修复失陷的容器映像**
1. 立即停止使用该映像，并将其从映像存储库中删除。
1. 确定正在使用此映像的所有任务。
1. 停止使用失陷映像的所有任务。更新其任务定义，以确保停止使用失陷的映像。
# 修复可能失陷的数据库
GuardDuty 在您启用[支持的数据库](rds-protection.md#rds-pro-supported-db)后生成的[RDS 保护调查发现类型](findings-rds-protection.md)，表明您的登录行为可能存在可疑和异常。[RDS 防护](rds-protection.md)使用 RDS 登录活动，通过识别登录尝试中的异常模式来 GuardDuty 分析和描述威胁。
**注意**
您可以从 [GuardDuty 主动查找类型](guardduty_finding-types-active.md#findings-table) 中选择某个调查发现类型来访问其完整信息。
请按照以下建议步骤修复您的 AWS 环境中可能遭到入侵的 Amazon Aurora 数据库。
**Topics**
+ [通过成功登录事件修复可能受攻击的数据库](#gd-compromised-db-successful-attempt)
+ [通过失败登录事件修复可能受攻击的数据库](#gd-compromised-db-failed-attempt)
+ [修复可能遭泄露的凭证](#gd-rds-database-compromised-credentials)
+ [限制网络访问](#gd-rds-database-restrict-network-access)
## 通过成功登录事件修复可能受攻击的数据库
以下建议的步骤可以帮助您修复可能受攻击的 Aurora 数据库，该数据库表现出与成功登录事件相关的异常行为。
1. **确定受影响的数据库和用户。**
生成的 GuardDuty 结果提供了受影响数据库的名称和相应的用户详细信息。有关更多信息，请参阅 [调查发现详细信息](guardduty_findings-summary.md)。
1. **确认这种行为是预期的还是意外的。**
以下列表列出了可能导致生成调查结果 GuardDuty 的潜在场景：
+ 经过很长时间后才登录到其数据库的用户。
+ 偶尔登录数据库的用户，例如，每个季度登录一次的财务分析师。
+ 尝试登录成功的潜在可疑攻击者可能会攻击数据库。
1. **如果行为出乎意料，请开始此步骤。**
1. **限制数据库访问**
限制可疑账户和登录活动源的数据库访问。有关更多信息，请参阅 [修复可能遭泄露的凭证](#gd-rds-database-compromised-credentials) 和 [限制网络访问](#gd-rds-database-restrict-network-access)。
1. **评测影响并确定访问了哪些信息。**
+ 请查看审计日志（如果有），以确定可能被访问的信息片段。有关更多信息，请参阅《Amazon Aurora 用户指南》**中的[监控 Amazon Aurora 数据库集群中的事件、日志和流](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/CHAP_Monitor_Logs_Events.html)。
+ 确定是否访问或修改了任何敏感或受保护信息。
## 通过失败登录事件修复可能受攻击的数据库
以下建议的步骤可以帮助您修复可能受攻击的 Aurora 数据库，该数据库表现出与失败登录事件相关的异常行为。
1. **确定受影响的数据库和用户。**
生成的 GuardDuty 结果提供了受影响数据库的名称和相应的用户详细信息。有关更多信息，请参阅 [调查发现详细信息](guardduty_findings-summary.md)。
1. **确定失败登录尝试源。**
生成的 GuardDuty 调查结果在调查结果面板的 “Acto **r**” 部分下提供 **IP 地址**和 **ASN 组织**（如果是公共连接）。
自治系统（AS）是由一个或多个网络运营商运行的一个或多个 IP 前缀（可在网络上访问的 IP 地址列表）组成的群组，这些运营商维护单一、明确定义的路由策略。网络运营商需要自治系统号 (ASNs) 来控制其网络内的路由，并与其他互联网服务提供商交换路由信息 (ISPs)。
1. **确认这种行为是否是意料之外的。**
检查此活动是否表示试图获得对数据库的其他未经授权的访问，如下所示：
+ 如果源是内部的，请检查应用程序是否配置错误并重复尝试连接。
+ 如果是外部攻击者，则检查相应的数据库是否面向公众或配置错误，从而允许潜在的恶意行为者暴力破解常用用户名。
1. **如果行为出乎意料，请开始此步骤。**
1. **限制数据库访问**
限制可疑账户和登录活动源的数据库访问。有关更多信息，请参阅 [修复可能遭泄露的凭证](#gd-rds-database-compromised-credentials) 和 [限制网络访问](#gd-rds-database-restrict-network-access)。
1. **执行根本原因分析并确定可能导致此活动的步骤。**
设置警报，以便在活动修改网络策略并造成不安全状态时收到通知。有关更多信息，请参阅《AWS Network Firewall 开发人员指南》**中 [AWS Network Firewall的防火墙策略](https://docs.aws.amazon.com/network-firewall/latest/developerguide/firewall-policies.html)。
## 修复可能遭泄露的凭证
GuardDuty 调查结果可能表明，当调查结果中确定的用户执行了意外的数据库操作时，受影响数据库的用户凭据已被泄露。您可以在控制台的调查发现面板中的** RDS DB 用户详细信息**部分或调查发现 JSON 的 `resource.rdsDbUserDetails` 中识别用户。这些用户详细信息包括用户名、使用的应用程序、访问的数据库、SSL 版本和身份验证方法。
+ 要对调查发现中涉及的特定用户撤销访问权限或轮换密码，请参阅《Amazon Aurora 用户指南》**中的 [Amazon Aurora MySQL 的安全性](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Security.html)或 [Amazon Aurora PostgreSQL 的安全性](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Security.html)。
+ 用于 AWS Secrets Manager 安全存储和自动轮换 Amazon Relational Database Service (RDS) 数据库的密钥。有关更多信息，请参阅《AWS Secrets Manager 开发人员指南》**中的 [AWS Secrets Manager 教程](https://docs.aws.amazon.com/secretsmanager/latest/userguide/tutorials.html)。
+ 使用 IAM 数据库身份验证来管理数据库用户的访问权限，无需密码。有关更多信息，请参阅《Amazon Aurora 用户指南》**中的 [IAM 数据库身份验证](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.IAMDBAuth.html)。
有关更多信息，请参阅《Amazon RDS 用户指南》**中的 [Amazon Relational Database Service 安全最佳实践](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_BestPractices.Security.html)。
## 限制网络访问
GuardDuty 调查结果可能表明，除了您的应用程序或虚拟私有云 (VPC) 之外，还可以访问数据库。如果调查发现中的远程 IP 地址是意外的连接源，请对安全组进行审计。附加到数据库的安全组列表可在[https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)控制台**的安全组**下或调查结果 JSON `resource.rdsDbInstanceDetails.dbSecurityGroups` 中找到。有关配置安全组的更多信息，请参阅《Amazon RDS 用户指南》**中的[使用安全组控制访问](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.RDSSecurityGroups.html)。
如果您使用的是防火墙，请通过重新配置网络访问控制列表（NACLs）来限制对数据库的网络访问。有关更多信息，请参阅《AWS Network Firewall 开发人员指南》**中 [AWS Network Firewall的防火墙](https://docs.aws.amazon.com/network-firewall/latest/developerguide/firewalls.html)。
# 修复可能失陷的 Lambda 函数
GuardDuty 生成时[Lambda 保护调查发现类型](lambda-protection-finding-types.md)，您的 Lambda 函数可能会受到损害。如果导致生成此发现 GuardDuty 的活动符合预期，则可以考虑使用[抑制规则](findings_suppression-rule.md)。我们建议完成以下步骤来修复失陷的 Lambda 函数：
**修复 Lambda 保护调查发现**
1. **确定可能失陷的 Lambda 函数版本**。
Lambda Protection 的 GuardDuty 调查结果提供了与调查结果详细信息中列出的 Lambda 函数相关的名称、亚马逊资源名称 (ARN)、函数版本和修订版 ID。
1. **确定潜在可疑活动的来源**。
1. 查看与调查发现中涉及的 Lambda 函数版本相关的代码。
1. 查看调查发现中涉及的 Lambda 函数版本的导入库和层。
1. 如果您已[使用 Amazon Inspector 启用了扫描 AWS Lambda 功能](https://docs.aws.amazon.com/inspector/latest/user/scanning-lambda.html)，请查看与[调查结果中涉及的 Lambda 函数相关的亚马逊检查结果](https://docs.aws.amazon.com/inspector/latest/user/findings-understanding-locating-analyzing.html)。
1. 查看日 AWS CloudTrail 志，确定导致函数更新的主体，并确保该活动已获得授权或预期。
1. **修复可能失陷的 Lambda 函数**。
1. 禁用调查发现中涉及的 Lambda 函数的执行触发器。有关更多信息，请参阅 [DeleteFunctionEventInvokeConfig](https://docs.aws.amazon.com/lambda/latest/dg/API_DeleteFunctionEventInvokeConfig.html)。
1. 查看 Lambda 代码并更新库导入和 Lambda [函数层](https://docs.aws.amazon.com/lambda/latest/dg/chapter-layers.html)，以移除可能可疑的库和层。
1. 缓解与调查发现中涉及的 Lambda 函数相关的 Amazon Inspector 调查发现。