

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 修復偵測到的 GuardDuty 安全性問題清單
<a name="guardduty_remediate"></a>

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 執行個體
<a name="compromised-ec2"></a>

當 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. 從可能遭到入侵的執行個體中移除新建立**的隔離**安全群組以外的所有安全群組關聯。
**注意**  
現有的追蹤連線不會因為變更安全群組而終止 - 只有未來的流量會被新的安全群組有效封鎖。  
如需有關封鎖來自可疑現有連線之進一步流量的資訊，請參閱《*事件回應手冊*[》中的根據網路 IoCs 強制執行 NACLs，以防止進一步流量](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. **提交技術支援請求**

   如果您是付費支援套件訂閱用戶，則可以提交[技術支援](https://console.aws.amazon.com/support/home#/case/create?issueType=technical)請求。

# 修復可能遭到入侵的 S3 儲存貯體
<a name="compromised-s3"></a>

當 GuardDuty 產生 時[GuardDuty S3 保護調查結果類型](guardduty_finding-types-s3.md)，表示您的 Amazon S3 儲存貯體已遭入侵。如果您的環境中預期造成問題清單的行為，請考慮建立 [隱藏規則](findings_suppression-rule.md)。如果未預期此行為，請依照這些建議步驟來修復 AWS 環境中可能遭到入侵的 Amazon S3 儲存貯體：

1. **識別可能遭到入侵的 S3 資源。**

   S3 的 GuardDuty 調查結果會在調查結果詳細資訊中列出相關聯的 S3 儲存貯體、其 Amazon Resource Name (ARN) 及其擁有者。

1. **識別可疑活動的來源和使用的 API 呼叫。**

   使用的 API 呼叫會在調查結果詳細資訊中列為 `API`。來源將是 IAM 主體 (IAM 角色、使用者或帳戶)，而識別詳細資訊將列在調查結果中。視來源類型而定，遠端 IP 地址或來源網域資訊將可供使用，並可協助您評估來源是否已獲得授權。如果調查結果涉及來自 Amazon EC2 執行個體的登入資料，則也會包含該資源的詳細資訊。

1. **判斷呼叫來源是否已獲得授權可存取已識別的資源。**

   如需範例，請考慮以下內容：
   + 如果涉及 IAM 使用者，他們的登入資料是否可能遭到入侵？ 如需詳細資訊，請參閱[修復可能遭到入侵的 AWS 登入資料](compromised-creds.md)。
   + 如果從先前沒有調用此類型 API 之歷史記錄的主體調用 API，此來源是否需要此操作的存取權限？ 是否可以進一步限制儲存貯體許可？
   + 如果從**使用者類型**為 `AWSAccount` 的**使用者名稱** `ANONYMOUS_PRINCIPAL` 中看到存取，則表示該儲存貯體為公有且已存取。這個儲存貯體是否應該為公有？ 如果不是，請檢閱以下安全建議，了解共用 S3 資源的替代解決方案。
   + 如果是從**使用者類型**為 `AWSAccount` 的**使用者名稱** `ANONYMOUS_PRINCIPAL` 中看到成功 `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 儲存貯體的物件是否存在敏感資料。如需詳細資訊，請參閱 [Discovering sensitive data with 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 儲存貯體存取需求的建議
<a name="guardduty-compromised-s3-recommendations"></a>

**以下清單根據特定 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)。

  此外，您可以將虛擬私有雲端 (VPC) 端點與 S3 儲存貯體政策搭配使用，以限制對特定 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)。 *Amazon S3 *
+ 若要安全地將 S3 資源的存取權授予其他 AWS 帳戶，您可以使用存取控制清單 (ACL)，如需詳細資訊，請參閱《*Amazon S3 使用者指南*》中的[存取控制清單 (ACL) 概觀](https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html)。

如需 S3 安全選項的詳細資訊，請參閱《[Amazon S3 使用者指南》中的 Amazon S3 的安全最佳實務](https://docs.aws.amazon.com/AmazonS3/latest/userguide/security-best-practices.html)。 *Amazon S3 *

# 修復潛在的惡意 S3 物件
<a name="compromised-s3object-malware-protection-gdu"></a>

當 GuardDuty 產生 時[S3 調查結果類型的惡意軟體防護](gdu-malware-protection-s3-finding-types.md)，表示 Amazon S3 儲存貯體中新上傳的物件包含惡意軟體。資源類型是 **S3Object**。

使用下列建議步驟，可能修復產生的調查結果：

1. 檢查與調查結果相關聯的 S3**S3ObjectDetails** 物件。

1. 隔離受影響的 S3 物件。如果您在為關聯的 Amazon 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 快照
<a name="compromised-snapshot"></a>

當 GuardDuty 產生 Execution：EC2/MaliciousFile！Snapshot 調查結果類型時，表示已在 Amazon EBS 快照中偵測到惡意軟體。執行下列步驟來修復可能遭到入侵的快照：

1. **識別可能遭到入侵的快照**

   1. 識別可能遭到入侵的快照。EBS 快照的 GuardDuty 調查結果會在調查結果詳細資訊中列出受影響的快照 ID、其 Amazon Resource Name (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
<a name="compromised-ami"></a>

當 GuardDuty 產生 Execution：EC2/MaliciousFile！AMI 調查結果類型時，表示已在 Amazon Machine Image (AMI) 中偵測到惡意軟體。執行下列步驟來修復可能遭到入侵的 AMI：

1. **識別可能遭到入侵的 AMI**

   1. AMIs 的 GuardDuty 調查結果會在調查結果詳細資訊中列出受影響的 AMI ID、其 Amazon Resource Name (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 - Amazon Elastic Compute Cloud](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 復原點
<a name="compromised-ec2-recoverypoint"></a>

當 GuardDuty 產生 Execution：EC2/MaliciousFile！RecoveryPoint 調查結果類型時，表示已在 EC2 Recovery Point Backup 資源中偵測到惡意軟體。執行下列步驟來修復可能遭到入侵的復原點：

1. **識別可能遭到入侵的 EC2 復原點**

   1. EC2 復原點的 GuardDuty 調查結果會在調查結果詳細資訊中列出其 Amazon Resource Name (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 備份標籤-resource -—resource-arn arn：aws：backup：us-east-1：111122223333：recovery-point：a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 -—tags Investigation=Malware，DoNotDelete=True*

1. **採取修復動作**
   + 在繼續刪除之前，請確定您已識別所有相依性，並視需要擁有適當的備份。

# 修復可能遭到入侵的 S3 復原點
<a name="compromised-s3-recoverypoint"></a>

當 GuardDuty 產生 Execution：S3/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 叢集
<a name="compromised-ecs"></a>

可能遭到入侵的 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. **隔離受影響的任務**

   封鎖受影響任務的所有網路流量 （傳入和傳出），以停止威脅。此網路隔離可透過中斷與遭入侵任務的所有連線，協助防止任何持續的攻擊。

**注意**：如果您判斷此調查結果是由環境中的預期/合法活動觸發，您可以設定抑制規則以防止類似調查結果出現。如需其他資訊，請參閱 [GuardDuty 中的隱藏規則](findings_suppression-rule.md)。

# 修復可能遭到入侵的 AWS 登入資料
<a name="compromised-creds"></a>

當 GuardDuty 產生 時[IAM 調查結果類型](guardduty_finding-types-iam.md)，表示您的 AWS 登入資料已遭到入侵。可能遭到入侵**的資源**類型為 **AccessKey**。

若要修復 AWS 環境中可能遭到入侵的登入資料，請執行下列步驟：

1. **識別可能遭到入侵的 IAM 實體和使用的 API 呼叫。**

   使用的 API 呼叫會在調查結果詳細資訊中列為 `API`。IAM 實體 (IAM 角色或使用者） 及其識別資訊將列在調查結果詳細資訊**的資源**區段中。涉及的 IAM 實體類型可由**使用者類型**欄位決定，IAM 實體名稱將位於**使用者名稱** 欄位中。調查結果中涉及的 IAM 實體類型也可由使用的**存取金鑰 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)資料。  
如果已使用角色，**使用者名稱**欄位將顯示所使用角色的名稱。您可以透過檢查 CloudTrail 日誌項目的 `sessionIssuer`元素 AWS CloudTrail 來判斷如何使用 請求金鑰，如需詳細資訊，請參閱 [ CloudTrail 中的 IAM 和 AWS STS 資訊](https://docs.aws.amazon.com/IAM/latest/UserGuide/cloudtrail-integration.html#iam-info-in-cloudtrail)。

1. **檢閱 IAM 實體的許可。**

   開啟 IAM 主控台。根據使用的實體類型，選擇**使用者**或**角色**索引標籤，然後在搜尋欄位中輸入識別的名稱來尋找受影響的實體。使用**許可**和**存取顧問**索引標籤，以檢閱該實體的有效許可。

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 帳戶。如果您懷疑登入資料已洩露，請檢閱 [My 中的資訊 AWS 帳戶 ，](https://repost.aws/knowledge-center/potential-account-compromise)以修復此問題。

# 修復可能遭到入侵的獨立容器
<a name="remediate-compromised-standalone-container"></a>

當 GuardDuty 產生[指出可能洩露容器的調查結果類型](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-active.html#findings-table)時，您的**資源類型**將為**容器**。如果您的環境中預期造成問題清單的行為，請考慮使用 [隱藏規則](findings_suppression-rule.md)。

若要修復 AWS 環境中可能遭到入侵的登入資料，請執行下列步驟：

1. **隔離可能遭到入侵的容器**

   下列步驟可協助您識別潛在的惡意容器工作負載：
   + 前往 [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/) 開啟 GuardDuty 主控台。
   + 在**調查結果**頁面上，選擇對應的調查結果以檢視調查結果面板。
   + 在調查結果面板的**受影響資源**區段下，您可以檢視容器的 **ID** 和**名稱**。

   將此容器與其他容器工作負載隔離。

1. **暫停容器**

   暫停容器中的所有程序。

   如需有關凍結容器的資訊，請參閱[暫停容器](https://docs.docker.com/engine/api/v1.35/#tag/Container/operation/ContainerPause)。

   **停止容器**。

   如果上述步驟失敗，且容器沒有暫停，請停止執行容器。如果您已啟用 [快照保留](malware-protection-customizations.md#mp-snapshots-retention) 功能，GuardDuty 將保留包含惡意軟體之 EBS 磁碟區的快照。

   如需停止容器的資訊，請參閱[停止容器](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 保護調查結果
<a name="guardduty-remediate-kubernetes"></a>

當您的帳戶啟用 EKS 保護時，Amazon GuardDuty 會產生問題[清單](guardduty_findings.md)，指出潛在的 Kubernetes 安全問題。如需詳細資訊，請參閱[EKS 保護](kubernetes-protection.md)。以下各節說明這些情況下的建議修復步驟。特定修復動作會在該特定調查結果類型的項目中說明。您可以從[作用中調查結果類型表格](guardduty_finding-types-active.md)中選取調查結果類型，以存取該類型的相關完整資訊。

如果預期會產生任何 EKS 保護調查結果類型，您可以考慮新增 [GuardDuty 中的隱藏規則](findings_suppression-rule.md)以防止未來的提醒。

不同類型的攻擊和組態問題可能會觸發 GuardDuty EKS 保護調查結果。本指南可協助您針對叢集識別 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)。 ****

## 潛在的組態問題
<a name="compromised-kubernetes-config"></a>

如果調查結果指出組態問題，請參閱該調查結果的「修復」區段，以取得有關解決該特定問題的指引。如需詳細資訊，請參閱下列指出組態問題的調查結果類型：
+ [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 使用者
<a name="compromised-kubernetes-user"></a>

GuardDuty 調查結果可表示當調查結果中識別的使用者執行非預期的 API 動作時，Kubernetes 使用者已遭到入侵。您可以在主控台中調查結果詳細資訊的 **Kubernetes 使用者詳細資訊**區段中，或在調查結果 JSON 的 `resource.kubernetesDetails.kubernetesUserDetails` 中識別使用者。這些使用者詳細資訊包括 `user name`、`uid` 和使用者所屬的 Kubernetes 群組。

如果使用者使用 IAM 實體存取工作負載，您可以使用 `Access Key details` 區段來識別 IAM 角色或使用者的詳細資訊。請參閱下列使用者類型及其修复指引。

**注意**  
您可以使用 Amazon Detective 進一步調查調查結果中識別的 IAM 角色或使用者。在 GuardDuty 主控台中檢視調查結果詳細資訊時，請選擇**在 Detective 中調查**。然後從列出的項目中選取 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. 檢閱 [My 中的資訊 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 定義的使用者** – 透過 AWS身分驗證 ConfigMap 授予存取權的 IAM 使用者。如需詳細資訊，請參閱《**Amazon EKS 使用者指南*》中的*[管理叢集的使用者或 IAM 角色](https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html)。您可以使用以下命令檢視其許可：`kubectl edit configmaps aws-auth --namespace kube-system`  
**若要撤銷 an AWS ConfigMap 使用者的存取權：**  

1. 使用下列命令開啟 ConfigMap。

   ```
   kubectl edit configmaps aws-auth --namespace kube-system
   ```

1. 使用與 GuardDuty 調查結果的 Kubernetes 使用者詳細資訊區段中報告的使用者名稱相同的使用者名稱，在 **mapRoles** 或 **mapUsers** 區段下識別角色或使用者項目。請參閱下列範例，其中已在調查結果中識別管理員使用者。

   ```
   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 服務帳戶。

**服務帳戶**：服務帳戶提供 Pod 的身分，並可使用下列格式的使用者名稱進行識別：`system:serviceaccount:namespace:service_account_name`。  
**撤銷對服務帳戶的存取權限：**  

1. 輪換服務帳戶憑證。

1. 檢閱下一節中有關 Pod 入侵的指引。

## 修復可能遭到入侵的 Kubernetes Pod
<a name="compromised-kubernetes-pod"></a>

當 GuardDuty 在 `resource.kubernetesDetails.kubernetesWorkloadDetails`區段中指定 Pod 或工作負載資源的詳細資訊時，該 Pod 或工作負載資源可能會遭到入侵。GuardDuty 調查結果可表示單一 Pod 已遭到入侵，或是多個 Pod 已透過較高層級的資源遭到入侵。如需有關如何識別遭到入侵的 Pod 的指引，請參閱下列入侵情況。

**單一 Pod 入侵**  
如果 `resource.kubernetesDetails.kubernetesWorkloadDetails` 區段內的 `type` 欄位是 **Pod**，則調查結果會識別單一 Pod。名稱欄位是 Pod 的 `name`，而 `namespace` 欄位則是其命名空間。  
如需識別執行 Pod 的工作者節點的相關資訊，請參閱《*Amazon EKS 最佳實務指南*》中的[識別違規的 Pod 和工作者節點](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_identify_the_offending_pod_and_worker_node)。

**Pod 透過工作負載資源遭到入侵**  
如果 `resource.kubernetesDetails.kubernetesWorkloadDetails` 區段內的 `type` 欄位識別出**工作負載資源** (例如 `Deployment`)，則該工作負載資源中的所有 Pod 很可能都已遭到入侵。  
如需有關識別工作負載資源的所有 Pod 及其執行節點的資訊，請參閱《*Amazon EKS 最佳實務指南*》中的[使用工作負載名稱識別違規的 Pod 和工作者節點](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_identify_the_offending_pods_and_worker_nodes_using_workload_name)。

**透過服務帳戶入侵的 Pod**  
如果 GuardDuty 調查結果在 `resource.kubernetesDetails.kubernetesUserDetails` 區段中識別出服務帳戶，則使用已識別服務帳戶的 Pod 很可能遭到入侵。如果調查結果報告的使用者名稱具有以下格式，則該使用者名稱是服務帳戶：`system:serviceaccount:namespace:service_account_name`。  
如需使用服務帳戶及其執行節點識別所有 Pod 的資訊，請參閱《*Amazon EKS 最佳實務指南*》中的[使用服務帳戶名稱識別違規的 Pod 和工作者節點](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 最佳實務指南*》中的[建立拒絕所有傳入和傳出流量的網路政策來隔離 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)。

**若要修復可能遭到入侵的 Pod：**

1. 識別入侵 Pod 的漏洞。

1. 實作該漏洞的修正程式，並啟動新的替換 Pod。

1. 刪除易遭受攻擊的 Pod。

   如需詳細資訊，請參閱《*Amazon EKS 最佳實務指南*》中的[重新部署遭入侵的 Pod 或工作負載資源](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_redeploy_compromised_pod_or_workload_resource)。

如果工作者節點已指派允許 Pod 存取其他 AWS 資源的 IAM 角色，請從執行個體中移除這些角色，以防止進一步受到攻擊。同樣地，如果已為 Pod 指派 IAM 角色，請評估您是否可以安全地從該角色中移除 IAM 政策，而不會影響其他工作負載。

## 修復可能遭到入侵的容器映像
<a name="compromised-kubernetes-image"></a>

當 GuardDuty 調查結果指出 Pod 入侵時，用於啟動 Pod 的映像可能是惡意或入侵。GuardDuty 調查結果可識別 `resource.kubernetesDetails.kubernetesWorkloadDetails.containers.image` 欄位內的容器映像。您可以掃描映像是否含有惡意軟體，判斷該映像是否為惡意的。

**若要修復可能遭到入侵的容器映像：**

1. 立即停止使用該映像，並將其從映像儲存庫中移除。

1. 使用可能遭到入侵的映像來識別所有 Pod。

   如需詳細資訊，請參閱《*Amazon EKS 最佳實務指南*》中的[識別具有易受攻擊或受損影像的 Pod 和工作者節點](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. 隔離可能遭到入侵的 Pod、輪換登入資料，以及收集資料進行分析。如需詳細資訊，請參閱《*Amazon EKS 最佳實務指南*[》中的建立拒絕所有輸入和輸出流量至 Pod 的網路政策來隔離 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. 使用可能遭到入侵的映像刪除所有 Pod。

## 修復可能遭到入侵的 Kubernetes 節點
<a name="compromised-kubernetes-node"></a>

如果 GuardDuty 調查結果中識別的使用者代表節點身分，或該調查結果表示使用了有權限的容器，則該調查結果可表示節點遭到入侵。

如果**使用者名稱**欄位具有以下格式，則使用者身分為工作節點：`system:node:node name`。例如 `system:node:ip-192-168-3-201.ec2.internal`。這表示對手已取得節點的存取權，而且正在使用節點的憑證與 Kubernetes API 端點通訊。

如果調查結果中列出的一個或多個容器的 `resource.kubernetesDetails.kubernetesWorkloadDetails.containers.securityContext.privileged` 調查結果欄位設定為 `True`，則該調查結果表示使用了有權限的容器。

**若要修復可能遭到入侵的節點：**

1. 隔離 Pod、輪換其登入資料，並收集資料以進行鑑識分析。

   如需詳細資訊，請參閱《*Amazon EKS 最佳實務指南*[》中的建立拒絕所有輸入和輸出流量至 Pod 的網路政策來隔離 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. 識別在可能遭到入侵的節點上執行的所有 Pod 所使用的服務帳戶。檢閱其許可，並視需要輪換服務帳戶。

1. 終止可能遭到入侵的節點。

# 修復執行時期監控調查結果
<a name="guardduty-remediate-runtime-monitoring"></a>

當您為帳戶啟用執行期監控時，Amazon GuardDuty 可能會產生 [GuardDuty 執行期監控調查結果類型](findings-runtime-monitoring.md)，指出 AWS 環境中的潛在安全問題。潛在的安全問題表示您 AWS 環境中的 Amazon EC2 執行個體、容器工作負載、Amazon EKS 叢集或一組遭入侵的登入資料。安全代理程式會監控來自多種資源類型的執行時間事件。若要識別可能遭到入侵的資源，請在 GuardDuty 主控台中檢視產生的調查結果詳細資訊中的**資源類型**。下節說明各種資源類型的建議修復步驟。

------
#### [ Instance ]

如果調查結果詳細資訊中的**資源類型**是**執行個體**，則表示 EC2 執行個體或 EKS 節點可能遭到入侵。
+ 若要修復遭到入侵的 EKS 節點，請參閱[修復可能遭到入侵的 Kubernetes 節點](guardduty-remediate-kubernetes.md#compromised-kubernetes-node)。
+ 若要修復遭到入侵的 EC2 執行個體，請參閱[修復可能遭到入侵的 Amazon EC2 執行個體](compromised-ec2.md)。

------
#### [ EKSCluster ]

如果調查結果詳細資訊中的**資源類型**為 **EKSCluster**，則表示 EKS 叢集內的 Pod 或容器可能遭到入侵。
+ 若要修復遭到入侵的 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 ]

如果調查結果詳細資訊中的**資源類型**為**容器**，則表示獨立容器可能遭到入侵。
+ 若要修復，請參閱[修復可能遭到入侵的獨立容器](remediate-compromised-standalone-container.md)。
+ 如果使用相同容器映像跨多個容器產生調查結果，請參閱[修復可能遭到入侵的容器映像](guardduty-remediate-kubernetes.md#compromised-kubernetes-image)。
+ 如果容器已存取基礎 EC2 主機，則其關聯的執行個體憑證可能已遭到入侵。如需詳細資訊，請參閱[修復可能遭到入侵的 AWS 登入資料](compromised-creds.md)。
+ 如果潛在惡意執行者存取了基礎 EKS 節點或 EC2 執行個體，請參閱 *EKSCluster* 和*執行個體*索引標籤下建議的修復措施。

------

## 修復遭到入侵的容器映像
<a name="gdu-remediate-compromised-container-images"></a>

當 GuardDuty 調查結果指出任務遭到入侵時，用來啟動任務的映像可能是惡意或遭到入侵。GuardDuty 調查結果可識別 `resource.ecsClusterDetails.taskDetails.containers.image` 欄位內的容器映像。您可以掃描映像是否有惡意軟體，以判斷映像是否為惡意。

**修復遭入侵的容器映像**

1. 立即停止使用該映像，並將其從映像儲存庫中移除。

1. 識別使用此映像的所有任務。

1. 停止所有使用遭入侵映像的任務。更新其任務定義，使其停止使用遭到入侵的映像。

# 修復可能遭到入侵的資料庫
<a name="guardduty-remediate-compromised-database-rds"></a>

啟用 [RDS 保護](rds-protection.md) 後，GuardDuty 會產生 [RDS 保護調查結果類型](findings-rds-protection.md)，表示您的 [支援的資料庫](rds-protection.md#rds-pro-supported-db) 中可能存在可疑和異常的登入行為。GuardDuty 使用 RDS 登入活動，透過識別登入嘗試中的異常模式來分析和剖析威脅。

**注意**  
您可以從 [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)

## 修復可能遭到入侵且含有成功登入事件的資料庫
<a name="gd-compromised-db-successful-attempt"></a>

下列建議步驟可協助您修復可能遭到入侵的 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)。
      + 判斷是否存取或修改了任何敏感或受保護的資訊。

## 修復可能遭到入侵且含有失敗登入事件的資料庫
<a name="gd-compromised-db-failed-attempt"></a>

下列建議步驟可協助您修復可能遭到入侵的 Aurora 資料庫，且該資料庫會出現與失敗登入事件相關的異常行為。

1. **識別受影響的資料庫和使用者。**

   產生的 GuardDuty 調查結果會提供受影響資料庫的名稱和對應的使用者詳細資訊。如需詳細資訊，請參閱[調查結果詳細資訊](guardduty_findings-summary.md)。

1. **識別失敗登入嘗試的來源。**

   產生的 GuardDuty 調查結果會在調查結果面板的**執行者**區段下提供 **IP 地址**和 **ASN 組織** (如果是公有連線)。

   自治系統 (AS) 是由一個或多個網路業者執行的一個或多個 IP 字首 (可在網路上存取的 IP 地址清單) 的群組，而這些網路業者維護單一且明確定義的路由政策。網路業者需要自治系統編號 (ASN) 來控制其網路內的路由，並與其他網際網路服務供應商 (ISP) 交換路由資訊。

1. **確認此行為是意外行為。**

   檢查此活動是否表示嘗試獲得對資料庫的其他未經授權的存取權限，如下所示：
   + 如果來源是內部來源，請檢查應用程式是否設定錯誤，並重複嘗試連線。
   + 如果這是外部執行者，請檢查對應的資料庫是否設定為公有或設定錯誤，進而允許潛在惡意動作者暴力破解常見使用者名稱。

1. **如果是意外行為，請開始此步驟。**

   1. **限制資料庫存取權限**

      限制可疑帳戶的資料庫存取權限，以及此登入活動的來源。如需詳細資訊，請參閱[修復可能遭到入侵的憑證](#gd-rds-database-compromised-credentials)及[限制網路存取權限](#gd-rds-database-restrict-network-access)。

   1. **執行根本原因分析，並確定可能導致此活動的步驟。**

      設定提醒以在活動修改網路政策並建立不安全狀態時收到通知。如需詳細資訊，請參閱 *AWS Network Firewall Developer Guide* 中的 [Firewall policies in AWS Network Firewall](https://docs.aws.amazon.com/network-firewall/latest/developerguide/firewall-policies.html)。

## 修復可能遭到入侵的憑證
<a name="gd-rds-database-compromised-credentials"></a>

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)。

## 限制網路存取權限
<a name="gd-rds-database-restrict-network-access"></a>

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)。

如果您使用防火牆，請重新設定網路存取控制清單 (NACL) 以限制對資料庫的網路存取權限。如需詳細資訊，請參閱 *AWS Network Firewall Developer Guide* 中的 [Firewalls in AWS Network Firewall](https://docs.aws.amazon.com/network-firewall/latest/developerguide/firewalls.html)。

# 修復可能遭到入侵的 Lambda 函數
<a name="remediate-lambda-protection-finding-types"></a>

當 GuardDuty 產生 時[Lambda 保護調查結果類型](lambda-protection-finding-types.md)，您的 Lambda 函數可能會遭到入侵。如果預期導致 GuardDuty 產生此調查結果的活動，您可以考慮使用 [隱藏規則](findings_suppression-rule.md)。建議您完成下列步驟，以修復遭入侵的 Lambda 函數：

**修復 Lambda 保護調查結果**

1. **識別可能遭到入侵的 Lambda 函數版本**。

   來自 Lambda 保護的 GuardDuty 調查結果提供與調查結果詳細資訊中列出的 Lambda 函數相關聯的名稱、Amazon Resource Name (ARN)、函數版本及修訂 ID。

1. **識別潛在可疑活動的來源**。

   1. 檢閱與調查結果相關的 Lambda 函數版本相關聯的程式碼。

   1. 檢閱與調查結果相關之 Lambda 函數版本的匯入程式庫和層。

   1. 如果您已[使用 Amazon Inspector 啟用掃描 AWS Lambda 函數](https://docs.aws.amazon.com/inspector/latest/user/scanning-lambda.html)，請檢閱與問題[清單所涉及 Lambda 函數相關聯的 Amazon Inspector ](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 調查結果。