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à.

# Risposta agli incidenti e analisi forensi
<a name="incident-response-and-forensics"></a>

La tua capacità di reagire rapidamente a un incidente può aiutarti a ridurre al minimo i danni causati da una violazione. Disporre di un sistema di allerta affidabile in grado di avvisarti in caso di comportamenti sospetti è il primo passo per un buon piano di risposta agli incidenti. Quando si verifica un incidente, è necessario decidere rapidamente se distruggere e sostituire il contenitore danneggiato oppure isolare e ispezionare il contenitore. Se si sceglie di isolare il contenitore nell'ambito di un'indagine forense e di un'analisi delle cause principali, è necessario seguire la seguente serie di attività:

## Esempio di piano di risposta agli incidenti
<a name="_sample_incident_response_plan"></a>

### Identifica il Pod e il nodo di lavoro incriminati
<a name="_identify_the_offending_pod_and_worker_node"></a>

La prima cosa da fare dovrebbe essere quella di isolare il danno. Inizia identificando il punto in cui si è verificata la violazione e isola il Pod e il relativo nodo dal resto dell'infrastruttura.

### Identifica i pod e i nodi di lavoro incriminati utilizzando il nome del carico di lavoro
<a name="_identify_the_offending_pods_and_worker_nodes_using_workload_name"></a>

Se conosci il nome e lo spazio dei nomi del pod incriminato, puoi identificare il nodo di lavoro che esegue il pod come segue:

```
kubectl get pods <name> --namespace <namespace> -o=jsonpath='{.spec.nodeName}{"\n"}'
```

Se una risorsa [ del carico di lavoro ](https://kubernetes.io/docs/concepts/workloads/controllers/) come una distribuzione è stata compromessa, è probabile che tutti i pod che fanno parte della risorsa del carico di lavoro siano compromessi. Usa il comando seguente per elencare tutti i pod della risorsa Workload e i nodi su cui sono in esecuzione:

```
selector=$(kubectl get deployments <name> \
 --namespace <namespace> -o json | jq -j \
'.spec.selector.matchLabels | to_entries | .[] | "\(.key)=\(.value)"')

kubectl get pods --namespace <namespace> --selector=$selector \
-o json | jq -r '.items[] | "\(.metadata.name) \(.spec.nodeName)"'
```

Il comando precedente è per le distribuzioni. È possibile eseguire lo stesso comando per altre risorse del carico di lavoro come replicasets, statefulsets, ecc.

### Identifica i pod e i nodi di lavoro incriminati utilizzando il nome dell'account di servizio
<a name="_identify_the_offending_pods_and_worker_nodes_using_service_account_name"></a>

In alcuni casi, potresti scoprire che un account di servizio è compromesso. È probabile che i pod che utilizzano l'account di servizio identificato siano compromessi. Puoi identificare tutti i pod utilizzando l'account di servizio e i nodi su cui sono in esecuzione con il seguente comando:

```
kubectl get pods -o json --namespace <namespace> | \
    jq -r '.items[] |
    select(.spec.serviceAccount == "<service account name>") |
    "\(.metadata.name) \(.spec.nodeName)"'
```

### Identifica i pod con immagini e nodi di lavoro vulnerabili o compromessi
<a name="_identify_pods_with_vulnerable_or_compromised_images_and_worker_nodes"></a>

In alcuni casi, potresti scoprire che l'immagine di un contenitore utilizzata nei pod del tuo cluster è dannosa o compromessa. Un'immagine del contenitore è dannosa o compromessa se è stato rilevato che contiene malware, è un'immagine notoriamente errata o presenta un CVE che è stato sfruttato. Dovresti considerare compromessi tutti i pod che utilizzano l'immagine del contenitore. Puoi identificare i pod usando l'immagine e i nodi su cui sono in esecuzione con il seguente comando:

```
IMAGE=<Name of the malicious/compromised image>

kubectl get pods -o json --all-namespaces | \
    jq -r --arg image "$IMAGE" '.items[] |
    select(.spec.containers[] | .image == $image) |
    "\(.metadata.name) \(.metadata.namespace) \(.spec.nodeName)"'
```

### Isola il pod creando una policy di rete che neghi tutto il traffico in ingresso e in uscita verso il pod
<a name="_isolate_the_pod_by_creating_a_network_policy_that_denies_all_ingress_and_egress_traffic_to_the_pod"></a>

Una regola di negazione di tutto il traffico può aiutare a fermare un attacco già in corso interrompendo tutte le connessioni al pod. La seguente politica di rete si applicherà a un pod con l'etichetta. `app=web`

```
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
spec:
  podSelector:
    matchLabels:
      app: web
  policyTypes:
  - Ingress
  - Egress
```

**Importante**  
Una policy di rete può rivelarsi inefficace se un utente malintenzionato ha ottenuto l'accesso all'host sottostante. Se sospetti che ciò sia accaduto, puoi utilizzare [ AWS Security Groups ](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) per isolare un host compromesso dagli altri host. Quando modifichi il gruppo di sicurezza di un host, tieni presente che avrà un impatto su tutti i contenitori in esecuzione su quell'host.

### Revoca le credenziali di sicurezza temporanee assegnate al pod o al nodo di lavoro, se necessario
<a name="_revoke_temporary_security_credentials_assigned_to_the_pod_or_worker_node_if_necessary"></a>

Se al nodo di lavoro è stato assegnato un ruolo IAM che consente ai Pods di accedere ad altre risorse AWS, rimuovi tali ruoli dall'istanza per prevenire 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.

### Circonda il nodo di lavoro
<a name="_cordon_the_worker_node"></a>

Isolando il nodo di lavoro interessato, stai informando lo scheduler di evitare di programmare i pod sul nodo interessato. Ciò ti consentirà di rimuovere il nodo per lo studio forense senza interrompere gli altri carichi di lavoro.

**Nota**  
Questa guida non è applicabile a Fargate in cui ogni pod Fargate viene eseguito nel proprio ambiente sandbox. Invece di isolarli, sequestra i pod Fargate interessati applicando una politica di rete che impedisca tutto il traffico in ingresso e in uscita.

### Attiva la protezione dalle interruzioni sul nodo di lavoro interessato
<a name="_enable_termination_protection_on_impacted_worker_node"></a>

Un utente malintenzionato può tentare di cancellare i propri misfatti chiudendo un nodo interessato. L'attivazione della protezione [ dalla ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html#Using_ChangingDisableAPITermination) terminazione può impedire che ciò accada. [La protezione scale-in dell'istanza ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-termination.html#instance-protection) proteggerà il nodo da un evento di scale-in.

**avvertimento**  
Non è possibile abilitare la protezione dalla terminazione su un'istanza Spot.

### Etichetta l'autore del reato Pod/Node con un'etichetta che indichi che fa parte di un'indagine attiva
<a name="_label_the_offending_podnode_with_a_label_indicating_that_it_is_part_of_an_active_investigation"></a>

Ciò servirà da avvertimento agli amministratori del cluster affinché non alterino i dati interessati Pods/Nodes fino al termine dell'indagine.

### Cattura gli artefatti volatili sul nodo di lavoro
<a name="_capture_volatile_artifacts_on_the_worker_node"></a>
+  **Acquisisci la memoria del sistema operativo. ** Questo catturerà il demone Docker (o un altro runtime del contenitore) e i relativi sottoprocessi per contenitore. Ciò può essere ottenuto utilizzando strumenti come [ LiME ](https://github.com/504ensicsLabs/LiME) e [ Volatility ](https://www.volatilityfoundation.org/) o strumenti di livello superiore come [ Automated Forensics Orchestrator per Amazon EC2 che si basano su di essi. ](https://aws.amazon.com/solutions/implementations/automated-forensics-orchestrator-for-amazon-ec2/)
+  **Esegui un dump ad albero netstat dei processi in esecuzione e delle porte aperte. ** Questo catturerà il demone docker e il relativo sottoprocesso per contenitore.
+  **Esegui i comandi per salvare lo stato a livello di contenitore prima che le prove vengano alterate. ** È possibile utilizzare le funzionalità del runtime del contenitore per acquisire informazioni sui contenitori attualmente in esecuzione. Ad esempio, con Containerd, puoi fare quanto segue:
  +  `crictl ps`per i processi in esecuzione.
  +  `crictl logs CONTAINER`per i log conservati a livello di demone.

    Lo stesso potrebbe essere ottenuto con containerd utilizzando la [ CLI ](https://github.com/containerd/nerdctl) nerdctl, al posto di (ad es.). `docker` `nerdctl inspect` Sono disponibili alcuni comandi aggiuntivi a seconda del runtime del contenitore. Ad esempio, Docker deve visualizzare `docker diff` le modifiche al filesystem del contenitore o `docker checkpoint` salvare tutto lo stato del contenitore, inclusa la memoria volatile (RAM). Consulta [ questo post sul blog di Kubernetes ](https://kubernetes.io/blog/2022/12/05/forensic-container-checkpointing-alpha/) per discutere di funzionalità simili con containerd o runtime. CRI-O 
+  **Metti in pausa il contenitore per l'acquisizione forense. **
+  **Effettua un'istantanea dei volumi EBS dell'istanza. **

### Ridistribuisci il pod o la risorsa di carico di lavoro compromessi
<a name="_redeploy_compromised_pod_or_workload_resource"></a>

Una volta raccolti i dati per l'analisi forense, puoi ridistribuire il pod o la risorsa del carico di lavoro compromessi.

Per prima cosa implementa la correzione della vulnerabilità compromessa e avvia nuovi pod sostitutivi. Quindi elimina i pod vulnerabili.

Se i pod vulnerabili sono gestiti da una risorsa di carico di lavoro Kubernetes di livello superiore (ad esempio, una distribuzione o DaemonSet), la loro eliminazione ne pianificherà di nuovi. Quindi i pod vulnerabili verranno lanciati nuovamente. In tal caso, dovresti distribuire una nuova risorsa sostitutiva per il carico di lavoro dopo aver risolto la vulnerabilità. Quindi dovresti eliminare il carico di lavoro vulnerabile.

## Raccomandazioni
<a name="_recommendations"></a>

### Consulta il white paper di AWS Security Incident Response
<a name="_review_the_aws_security_incident_response_whitepaper"></a>

Sebbene questa sezione fornisca una breve panoramica insieme ad alcuni consigli per la gestione di sospette violazioni della sicurezza, l'argomento è trattato in modo esauriente nel white paper AWS Security Incident Response. [https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)

### Esercitati, giornate di gioco sulla sicurezza
<a name="_practice_security_game_days"></a>

Dividi i professionisti della sicurezza in 2 squadre: rossa e blu. La squadra rossa si concentrerà sull'analisi delle vulnerabilità nei diversi sistemi, mentre la squadra blu sarà responsabile della difesa contro di esse. Se non hai abbastanza professionisti della sicurezza per creare team separati, valuta la possibilità di assumere un'entità esterna a conoscenza degli exploit di Kubernetes.

 [Kubesploit ](https://github.com/cyberark/kubesploit) è un framework di test di penetrazione che puoi utilizzare per condurre giornate di gioco. CyberArk A differenza di altri strumenti che analizzano il cluster alla ricerca di vulnerabilità, kubesploit simula un attacco reale. Ciò offre alla tua squadra blu l'opportunità di mettere in pratica la sua risposta a un attacco e di valutarne l'efficacia.

### Esegui test di penetrazione sul tuo cluster
<a name="_run_penetration_tests_against_your_cluster"></a>

Attaccare periodicamente il tuo cluster può aiutarti a scoprire vulnerabilità e configurazioni errate. Prima di iniziare, segui le linee guida per i [ penetration test ](https://aws.amazon.com/security/penetration-testing/) prima di eseguire un test sul tuo cluster.

## Strumenti e risorse
<a name="_tools_and_resources"></a>
+  [kube-hunter](https://github.com/aquasecurity/kube-hunter), uno strumento di test di penetrazione per Kubernetes.
+  [Gremlin](https://www.gremlin.com/product/#kubernetes), un toolkit di ingegneria del caos che puoi utilizzare per simulare attacchi contro le tue applicazioni e la tua infrastruttura.
+  [Attacco e difesa delle installazioni Kubernetes ](https://github.com/kubernetes/sig-security/blob/main/sig-security-external-audit/security-audit-2019/findings/AtredisPartners_Attacking_Kubernetes-v1.0.pdf) 
+  [kubesploit ](https://www.cyberark.com/resources/threat-research-blog/kubesploit-a-new-offensive-tool-for-testing-containerized-environments) 
+  [NeuVector di SUSE ](https://www.suse.com/neuvector/) open source, piattaforma di sicurezza per container zero-trust, fornisce la segnalazione di vulnerabilità e rischi e la notifica degli eventi di sicurezza
+  [Minacce persistenti avanzate ](https://www.youtube.com/watch?v=CH7S5rE3j8w) 
+  [Attacco e difesa pratici di Kubernetes ](https://www.youtube.com/watch?v=LtCx3zZpOfs) 
+  [Compromissione del cluster Kubernetes sfruttando le autorizzazioni RBAC ](https://www.youtube.com/watch?v=1LMo0CftVC4)