Incident response nel cloud

Tue, 27 Oct 2026 09:00:00 +0200

Perché conta

Tutta la serie è stata prevenzione: ridurre la probabilità e il raggio d’esplosione. Ma la sicurezza non è mai assoluta — una chiave trapelerà, un ruolo verrà abusato, una dipendenza nasconderà una falla. La incident response è ciò che decide se quell’evento diventa un intoppo contenuto o una catastrofe. E nel cloud ha regole proprie: strumenti nuovi a tuo favore (ogni azione è un’API, ogni risorsa è clonabile) e insidie nuove da conoscere (le prove sono effimere, l’infrastruttura cambia sotto i piedi).

Le fasi, in chiave cloud

  flowchart LR
    P[Preparazione] --> D[Detection]
    D --> C[Contenimento]
    C --> E[Eradicazione]
    E --> R[Recupero]
    R --> L[Lezioni apprese]
    L -.migliora.-> P
    style C fill:#fde2e4,stroke:#e63946

Preparazione: prima dell’incidente. Ruoli e responsabilità definiti, accessi break-glass pronti, runbook scritti, log centralizzati e immutabili già attivi. Quasi tutto il successo si gioca qui.
Detection: l’allarme dalla threat detection o da una segnalazione. Si qualifica: è reale? quale perimetro tocca?
Contenimento: fermare l’emorragia senza distruggere le prove (sotto).
Eradicazione e recupero: rimuovere l’accesso dell’attaccante, ricostruire da uno stato pulito.
Lezioni apprese: cosa ha permesso l’incidente, come evitarlo — che rialimenta la preparazione.

Il contenimento cloud: veloce e chirurgico

Nel cloud il contenimento sfrutta IAM e API, ed è molto più rapido dell’on-premise:

Contenere una credenziale / risorsa compromessa:
  - revoca/disabilita l'identità o la chiave (taglia l'accesso all'istante)
  - isola la risorsa con un security group "quarantena" (nega ogni traffico)
  - NON spegnere subito la VM: perderesti la memoria volatile (prove)
  - revoca la chiave KMS se i dati cifrati sono a rischio

Il contenimento via identità è la mossa più potente: revocare un ruolo o una chiave taglia l’accesso dappertutto, istantaneamente — il rovescio positivo del fatto che nel cloud l’identità è il perimetro.

Le prove sono effimere: catturare prima

Qui sta la trappola del cloud. Una VM compromessa, se la spegni o la termina, svanisce con la sua memoria e spesso il suo disco. La forensics cloud sfrutta le API per catturare prima di agire:

Snapshot del disco della risorsa compromessa, copiato in un account forense isolato.
Dump della memoria volatile finché la macchina è viva.
Isolare, non distruggere: metti la risorsa in quarantena di rete per fermarla, ma tienila viva per analizzarla.

Molto di questo si automatizza: un playbook che, allo scattare di un allarme, isola la risorsa, ne cattura snapshot e memoria, revoca le credenziali coinvolte e apre un ticket — in secondi, senza attendere un umano. È il vantaggio cloud portato alla risposta.

Domanda: se ho fatto bene tutta la prevenzione dei capitoli precedenti — identità strette, rete segmentata, detection, postura curata — l'incident response non diventa un piano che non userò mai? Non è tempo investito in uno scenario che ho reso improbabile?

È tempo investito in uno scenario che hai reso improbabile ma non impossibile — e questa è esattamente la condizione in cui prepararsi conta di più, non di meno. La prevenzione riduce la frequenza e la gravità degli incidenti, non li azzera: resta sempre la vulnerabilità non ancora nota, la dipendenza compromessa a monte, l'errore umano, la credenziale di un fornitore, l'attacco che nessun controllo prevede. Proprio perché hai reso l'incidente raro, quando arriverà il tuo team non avrà pratica: nessuno ricorderà a freddo come si cattura uno snapshot forense, chi ha l'autorità di revocare un ruolo di produzione, dove sono i log, chi chiamare. Il valore della preparazione non è "sapere che un giorno servirà", è trasformare il panico in procedura: nel mezzo di un incidente reale, sotto pressione, con dati che forse escono in tempo reale, la differenza tra un'ora e un giorno di contenimento è un runbook già scritto e provato. E c'è un punto più sottile: la preparazione alla risposta migliora la prevenzione. Scrivere i runbook ti costringe a chiederti "se X venisse compromesso, come lo conterrei, avrei i log, potrei isolarlo?" — e quelle domande scoprono buchi nella prevenzione che altrimenti non vedresti (un log mancante, un accesso break-glass inesistente, una risorsa che non puoi isolare). Le esercitazioni (tabletop, simulazioni) valgono anche quando l'incidente non arriva, perché allenano il team e validano l'architettura. Infine, l'incident response non è solo tecnica: è decidere prima chi comunica, a chi, con quali obblighi di legge — cose che non si improvvisano mentre l'incidente è in corso. La prevenzione ti compra tempo e tranquillità; la preparazione alla risposta è l'assicurazione che paghi poco e che l'unico giorno in cui serve, vale tutto ciò che è costata.

Conclusione

L’incident response cloud contiene via IAM e rete (veloce, chirurgico), cattura le prove effimere prima di agire, e automatizza i playbook sfruttando le API — ma quasi tutto si decide nella preparazione fatta prima. Qui si chiude Sicurezza Cloud in pratica: dal modello di responsabilità condivisa fino alla risposta agli incidenti, con un filo conduttore unico — nel cloud l’identità è il perimetro e la configurazione è il campo di battaglia, e la sicurezza non è un prodotto che si compra, ma una disciplina che si pratica a ogni livello. Per riprendere il percorso dall’inizio, torna alla roadmap della serie.

Forensics on My personal blog

Incident response nel cloud

Perché conta

Le fasi, in chiave cloud

Il contenimento cloud: veloce e chirurgico

Le prove sono effimere: catturare prima

Conclusione