Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Correzione dei risultati della protezione EKS
Amazon GuardDuty genera [risultati](guardduty_findings.md) che indicano potenziali problemi di sicurezza di Kubernetes quando EKS Protection è abilitato per il tuo account. Per ulteriori informazioni, consulta [Protezione EKS](kubernetes-protection.md). Le sezioni seguenti descrivono le operazioni di correzione consigliate per questi scenari. Le operazioni correttive sono descritte nella voce relativa al tipo di esito specifico. Puoi accedere alle informazioni complete su un tipo di esito selezionandolo dalla [tabella relativa ai tipi di esiti attivi](guardduty_finding-types-active.md).
Se uno qualsiasi dei tipi di risultati di EKS Protection è stato generato in modo prevedibile, puoi prendere in considerazione l'aggiunta [Regole di soppressione in GuardDuty](findings_suppression-rule.md) per prevenire avvisi futuri.
Diversi tipi di attacchi e problemi di configurazione possono attivare i risultati di GuardDuty EKS Protection. Questa guida aiuta a identificare le cause principali delle GuardDuty rilevazioni relative al cluster e delinea le linee guida appropriate per la correzione. Le seguenti sono le cause principali che hanno portato ai risultati di GuardDuty Kubernetes:
+ [Potenziali problemi di configurazione](#compromised-kubernetes-config)
+ [Riparare gli utenti Kubernetes potenzialmente compromessi](#compromised-kubernetes-user)
+ [Riparazione dei pod Kubernetes potenzialmente compromessi](#compromised-kubernetes-pod)
+ [Riparazione dei nodi Kubernetes potenzialmente compromessi](#compromised-kubernetes-node)
+ [Riparazione delle immagini dei container potenzialmente compromesse](#compromised-kubernetes-image)
**Nota**
Prima della versione 1.14 di Kubernetes, il `system:unauthenticated` gruppo era associato a e per impostazione predefinita. `system:discovery` `system:basic-user` **ClusterRoles** Ciò potrebbe consentire l'accesso non intenzionale a utenti anonimi. Gli aggiornamenti del cluster non revocano le autorizzazioni, quindi potrebbero essere ancora valide anche se hai aggiornato il cluster alla versione 1.14 o successiva. Ti consigliamo di disassociare queste autorizzazioni dal gruppo `system:unauthenticated`.
Per ulteriori informazioni sulla rimozione di queste autorizzazioni, consulta [Proteggi i cluster Amazon EKS con le migliori pratiche](https://docs.aws.amazon.com/eks/latest/userguide/security-best-practices.html) nella Guida per **l'utente di Amazon EKS**.
## Potenziali problemi di configurazione
Se un esito indica un problema di configurazione, consulta la sezione sulla correzione di tale esito per indicazioni su come risolvere il problema. Per ulteriori informazioni, consulta i seguenti tipi di esiti che indicano problemi di configurazione:
+ [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)
+ Qualsiasi scoperta che finisce con **SuccessfulAnonymousAccess**
## Riparare gli utenti Kubernetes potenzialmente compromessi
Un GuardDuty risultato può indicare un utente Kubernetes compromesso quando un utente identificato nel risultato ha eseguito un'azione API inaspettata. Puoi identificare l'utente nella sezione **Dettagli utente Kubernetes** dei dettagli di un esito nella console o nei `resource.kubernetesDetails.kubernetesUserDetails` del file JSON degli esiti. Questi dettagli utente includono `user name`, `uid` e i gruppi Kubernetes a cui appartiene l'utente.
Se l'utente accedeva al carico di lavoro utilizzando un'entità IAM, puoi utilizzare la sezione `Access Key details` per identificare i dettagli di un ruolo o di un utente IAM. Consulta i seguenti tipi di utente e le linee guida per la correzione.
**Nota**
Puoi utilizzare Amazon Detective per esaminare ulteriormente il ruolo o l'utente IAM identificato nell'esito. Mentre visualizzi i dettagli del ritrovamento GuardDuty sulla console, scegli **Investiga in Detective**. Quindi seleziona AWS l'utente o il ruolo dagli elementi elencati per esaminarlo in Detective.
**Amministratore Kubernetes integrato**: l'utente predefinito assegnato da Amazon EKS all'identità IAM che ha creato il cluster. Questo tipo di utente è identificato dal nome utente `kubernetes-admin`.
**Per revocare l'accesso a un amministratore Kubernetes integrato:**
+ Identifica il `userType` nella sezione `Access Key details`.
+ Se il `userType` è un **Ruolo** e il ruolo appartiene a un ruolo dell'istanza EC2:
+ Identifica l'istanza e segui le istruzioni riportate in [Correzione di un'istanza Amazon EC2 potenzialmente compromessa](compromised-ec2.md).
+ Se il `userType` è un **Utente** o un **Ruolo** assunto da un utente:
1. [Ruota la chiave di accesso](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey) dell'utente.
1. Ruota tutti i segreti a cui l'utente ha avuto accesso.
1. Consulta le informazioni in [Il mio Account AWS potrebbe essere compromessa](https://repost.aws/knowledge-center/potential-account-compromise) per ulteriori dettagli.
**Utente autenticato OIDC**: un utente a cui è stato concesso l'accesso tramite un provider OIDC. In genere un utente OIDC ha un indirizzo e-mail come nome utente. Puoi verificare se il cluster utilizza OIDC con il comando seguente: `aws eks list-identity-provider-configs --cluster-name your-cluster-name `
**Per revocare l'accesso a un utente autenticato OIDC:**
1. Ruota le credenziali dell'utente nel provider OIDC.
1. Ruota tutti i segreti a cui l'utente ha avuto accesso.
**AWS-Auth ConfigMap defined user: un utente** IAM a cui è stato concesso l'accesso tramite un -auth. AWS ConfigMap Per ulteriori informazioni, consulta [la sezione Gestione degli utenti o dei ruoli IAM per il tuo cluster](https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html) nella **Amazon EKS User Guide**. Puoi esaminarne le autorizzazioni utilizzando il comando seguente: `kubectl edit configmaps aws-auth --namespace kube-system`
**Per revocare l'accesso di un AWS ConfigMap utente:**
1. Utilizzate il seguente comando per aprire. ConfigMap
```
kubectl edit configmaps aws-auth --namespace kube-system
```
1. Identifica il ruolo o la voce utente nella sezione **MapRoles** o **MapUsers** con lo stesso nome utente riportato nella sezione dei dettagli utente di Kubernetes del tuo risultato. GuardDuty Consulta l'esempio seguente, in cui l'utente amministratore è stato identificato in un esito.
```
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. Rimuovi quell'utente da. ConfigMap Consulta l'esempio seguente, in cui l'utente amministratore è stato rimosso.
```
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. Se il `userType` è un **Utente** o un **Ruolo** assunto da un utente:
1. [Ruota la chiave di accesso](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey) dell'utente.
1. Ruota tutti i segreti a cui l'utente ha avuto accesso.
1. Controlla le informazioni in [Il mio AWS account potrebbe essere compromesso](https://aws.amazon.com//premiumsupport/knowledge-center/potential-account-compromise/) per ulteriori dettagli.
Se l'esito non ha una sezione `resource.accessKeyDetails`, l'utente è un account di servizio Kubernetes.
**Account di servizio**: l'account di servizio fornisce un'identità per i pod e può essere identificato da un nome utente con il formato seguente: `system:serviceaccount:namespace:service_account_name`.
**Per revocare l'accesso a un account di servizio:**
1. Ruota le credenziali dell'account di servizio.
1. Consulta le linee guida sulla compromissione dei pod nella sezione seguente.
## Riparazione dei pod Kubernetes potenzialmente compromessi
Quando si GuardDuty specificano i dettagli di un pod o di una risorsa di carico di lavoro all'interno della `resource.kubernetesDetails.kubernetesWorkloadDetails` sezione, quel pod o risorsa del carico di lavoro è stato potenzialmente compromesso. Un GuardDuty risultato può indicare che un singolo pod è stato compromesso o che più pod sono stati compromessi a causa di una risorsa di livello superiore. Consulta i seguenti scenari di compromissione per indicazioni su come identificare il pod o i pod che sono stati compromessi.
**Compromissione di pod singoli**
Se il campo `type` all'interno della sezione `resource.kubernetesDetails.kubernetesWorkloadDetails` è **pod**, l'esito identifica un singolo pod. Il campo nome è il `name` del pod e il campo `namespace` è il relativo spazio del nome.
Per informazioni sull'identificazione del nodo di lavoro che esegue i pod, consulta [Identify the offending pod e worker node](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_identify_the_offending_pod_and_worker_node) nella *Amazon EKS Best* Practices Guide.
**Pod compromessi tramite una risorsa del carico di lavoro**
Se il campo `type` all'interno della sezione `resource.kubernetesDetails.kubernetesWorkloadDetails` identifica una **Risorsa del carico di lavoro**, ad esempio un'`Deployment`, è probabile che tutti i pod all'interno della risorsa del carico di lavoro siano stati compromessi.
Per informazioni sull'identificazione di tutti i pod della risorsa del carico di lavoro e dei nodi su cui sono in esecuzione, consulta [Identifica i pod e i nodi di lavoro offensivi utilizzando il nome del carico di lavoro nella](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_identify_the_offending_pods_and_worker_nodes_using_workload_name) *Amazon* EKS Best Practices Guide.
**I pod sono stati compromessi tramite un account di servizio**
Se un GuardDuty risultato identifica un account di servizio nella `resource.kubernetesDetails.kubernetesUserDetails` sezione, è probabile che i pod che utilizzano l'account di servizio identificato siano compromessi. Il nome utente riportato da un esito è un account di servizio se ha il formato seguente: `system:serviceaccount:namespace:service_account_name`.
Per informazioni sull'identificazione di tutti i pod che utilizzano l'account di servizio e i nodi su cui sono in esecuzione, consulta [Identifica i pod e i nodi di lavoro offensivi utilizzando il nome dell'account di servizio](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) nella *Amazon EKS Best* Practices Guide.
*Dopo aver identificato tutti i pod compromessi e i nodi su cui sono in esecuzione, consulta [Isolare il pod creando una politica di rete che neghi tutto il traffico in ingresso e in uscita verso il pod nella Amazon EKS Best Practices Guide](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).*
**Per rimediare a un pod potenzialmente compromesso:**
1. Identifica la vulnerabilità che ha compromesso i pod.
1. Implementa la correzione di tale vulnerabilità e avvia nuovi pod sostitutivi.
1. Eliminare i pod vulnerabili.
Per ulteriori informazioni, consulta [Redeploy pod o workload compromessi nella](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_redeploy_compromised_pod_or_workload_resource) *Amazon EKS* Best Practices Guide.
Se al nodo di lavoro è stato assegnato un ruolo IAM che consente ai Pods di accedere ad altre AWS risorse, rimuovi tali ruoli dall'istanza per evitare ulteriori danni causati dall'attacco. Allo stesso modo, se al pod è stato assegnato un ruolo IAM, valuta se puoi rimuovere in sicurezza le policy IAM dal ruolo senza influire sugli altri carichi di lavoro.
## Riparazione delle immagini dei container potenzialmente compromesse
Quando un GuardDuty risultato indica una compromissione del pod, l'immagine utilizzata per avviare il pod potrebbe essere potenzialmente dannosa o compromessa. GuardDuty i risultati identificano l'immagine del contenitore all'interno del `resource.kubernetesDetails.kubernetesWorkloadDetails.containers.image` campo. Puoi determinare se l'immagine è dannosa scansionandola alla ricerca di malware.
**Per correggere un'immagine del contenitore potenzialmente compromessa:**
1. Interrompi immediatamente l'utilizzo dell'immagine e rimuovila dal tuo repository di immagini.
1. Identifica tutti i pod utilizzando l'immagine potenzialmente compromessa.
Per ulteriori informazioni, consulta [Identifica i pod con immagini e nodi di lavoro vulnerabili o compromessi](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_identify_pods_with_vulnerable_or_compromised_images_and_worker_nodes) nella *Amazon EKS Best Practices* Guide.
1. Isola i pod potenzialmente compromessi, ruota le credenziali e raccogli dati per l'analisi. Per ulteriori informazioni, consulta [Isolare il pod creando una policy di rete che neghi tutto il traffico in ingresso e in uscita verso il pod nella](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) *Amazon EKS* Best Practices Guide.
1. Elimina tutti i pod utilizzando l'immagine potenzialmente compromessa.
## Riparazione dei nodi Kubernetes potenzialmente compromessi
Un GuardDuty risultato può indicare una compromissione del nodo se l'utente identificato nel risultato rappresenta l'identità di un nodo o se il risultato indica l'uso di un contenitore privilegiato.
L'identità utente è un nodo worker se il campo **nome utente** ha il seguente formato: `system:node:node name`. Ad esempio, `system:node:ip-192-168-3-201.ec2.internal`. Ciò indica che l'avversario ha ottenuto l'accesso al nodo e ne utilizza le credenziali per comunicare con l'endpoint dell'API Kubernetes.
Un esito indica l'uso di un container privilegiato se il campo `resource.kubernetesDetails.kubernetesWorkloadDetails.containers.securityContext.privileged` dell'esito di uno o più container elencati nell'esito è impostato su `True`.
**Per riparare un nodo potenzialmente compromesso:**
1. Isola il pod, ruota le sue credenziali e raccogli dati per l'analisi forense.
Per ulteriori informazioni, consulta [Isolare il pod creando una policy di rete che neghi tutto il traffico in ingresso e in uscita verso il pod nella](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) *Amazon EKS* Best Practices Guide.
1. Identifica gli account di servizio utilizzati da tutti i pod in esecuzione sul nodo potenzialmente compromesso. Controlla le relative autorizzazioni e, se necessario, ruota gli account di servizio.
1. Termina il nodo potenzialmente compromesso.