Errori di configurazione cloud: quali sono e come trovarli

La risposta breve: gli errori di configurazione cloud più frequenti sono quasi sempre gli stessi. Identità con più permessi del necessario, chiavi di accesso che non scadono, account amministrativi senza MFA, storage e database raggiungibili da internet, regole di rete aperte a tutti, log spenti o incompleti, accessi di fornitori mai revocati. Si trovano con un inventario completo degli account, gli strumenti di postura nativi del provider, una baseline riconosciuta e, se i cloud sono più di uno, un controllo continuo via API.

Perché nel cloud la configurazione pesa così tanto

Nel modello di responsabilità condivisa descritto da AWS, il lavoro di configurazione dei servizi spetta al cliente. È lì che si sbaglia. Nella scheda Mitigating Cloud Vulnerabilities del 22 gennaio 2020, la NSA indicava l'errore di configurazione come la vulnerabilità cloud più diffusa, sfruttabile anche da attaccanti poco sofisticati, che nasce spesso da errori nelle policy dei servizi cloud o da una lettura sbagliata della responsabilità condivisa. Google, nella sezione sicurezza del suo Well-Architected Framework, scrive che molte violazioni nel cloud sono la conseguenza diretta di un errore di configurazione.

I numeri recenti raccontano anche un miglioramento.

• Google Cloud, Cloud Threat Horizons Report H1 2026. Negli incidenti osservati sugli ambienti Google Cloud, l'errore di configurazione è stato il vettore di accesso iniziale nel 29,4% dei casi nel primo semestre 2025 e nel 21% nel secondo; le credenziali deboli o assenti sono scese dal 47,1% al 27,2%. Google precisa che i dati riguardano una parte dell'attività osservata e ritiene che il cambiamento possa dipendere dalla sua strategia secure-by-default e da controlli più robusti sulle credenziali.
• Stesso rapporto, indagini Mandiant. Negli incidenti del secondo semestre 2025 sui principali ambienti cloud e SaaS, non solo Google Cloud, l'accesso iniziale è passato da problemi di identità nell'83% dei casi.
• ENISA, Threat Landscape 2026. Sugli 8.257 incidenti del 2025 analizzati, tra gli accessi non autorizzati di cui è stato possibile identificare il vettore di intrusione, il 20,7% è passato da un errore di configurazione o da un'esposizione accidentale, contro il 60,4% delle vulnerabilità. Il dato non riguarda solo il cloud.

Il margine di tempo è stretto: Google riferisce di aver osservato nel 2025 attaccanti che sfruttavano applicazioni configurate male su Google Cloud, installando miner di criptovalute, soprattutto su macchine virtuali e cluster Kubernetes, in meno di un'ora dalla creazione delle istanze.

Gli errori di configurazione cloud più frequenti

1. Identità con più permessi del necessario

Ruoli amministrativi dati per comodità, service account con permessi ampi, persone che hanno cambiato mansione e conservano gli accessi di prima. Nella scheda congiunta Use Secure Cloud Identity and Access Management Practices (marzo 2024), NSA e CISA osservano che è facile configurare male i controlli di accesso fino a lasciare risorse aperte, e che questi errori sono comuni e hanno causato fughe di dati di grandi dimensioni. E ricordano che molti provider usano permessi gerarchici: un accesso dato su una cartella o su un'unità organizzativa vale per tutto ciò che contiene.

2. Chiavi e credenziali che non scadono

Chiavi di accesso statiche, chiavi dei service account scaricate su un portatile, token lasciati in un repository. NSA e CISA raccomandano di evitare chiavi con privilegi di root o amministrativi, di generarle solo per un uso di breve durata e di non scriverle mai in chiaro nel codice sorgente. AWS, nelle sue best practice IAM, chiede che persone e workload accedano con credenziali temporanee; Google Cloud, per le organizzazioni create dal 3 maggio 2024, blocca per default la creazione di chiavi persistenti per i service account.

Perché conta: secondo il rapporto Threat Horizons, nel secondo semestre 2025 il 21% dei casi analizzati da Mandiant è partito da credenziali rubate, di persone o di servizio, comprese chiavi di accesso AWS che si sospetta fossero state esposte in un incidente del 2022.

3. Account amministrativi senza MFA

Gli account cloud sono in genere raggiungibili da ovunque, e per questo, spiegano NSA e CISA, sono più esposti alle debolezze dell'autenticazione a un solo fattore. La loro indicazione è usare l'MFA e, dove possibile, metodi resistenti al phishing come FIDO/WebAuthn. Il caso più delicato è l'utente root, a cui AWS dedica una best practice IAM specifica.

4. Storage e database raggiungibili da internet

È l'errore che finisce sui giornali: gli esempi citati dalla NSA nel 2020 sono di questo tipo, compreso un database Elasticsearch esposto con i dettagli di viaggio di personale della Difesa statunitense. Qui i default sono cambiati. Da aprile 2023 AWS attiva S3 Block Public Access e disattiva le ACL su tutti i bucket nuovi; su Azure l'accesso anonimo ai dati dei blob è vietato per impostazione predefinita. L'annuncio di AWS però è esplicito: per i bucket esistenti non cambia nulla.

5. Regole di rete aperte a tutto internet

SSH e RDP aperti a qualunque indirizzo, porte di gestione esposte, servizi interni con un IP pubblico. A volte basta il default. Su Google Cloud ogni progetto nuovo nasce con una rete default, a meno che una policy di organizzazione non lo impedisca, e quella rete ha regole firewall già presenti che consentono connessioni in ingresso sulle porte 22 (SSH) e 3389 (RDP) da qualsiasi indirizzo, 0.0.0.0/0. Google precisa che si possono cancellare o modificare: se nessuno l'ha fatto, sono ancora lì.

6. Log spenti o incompleti

Un incidente si ricostruisce solo con i log che c'erano. Due default da conoscere:

• su Google Cloud gli audit log di tipo Data Access, quelli che registrano chi legge i dati, sono disattivati per default per tutti i servizi tranne BigQuery, e vanno attivati in modo esplicito;
• su AWS CloudTrail è attivo per default, ma lo storico consultabile copre 90 giorni di eventi di gestione per regione, e i trail, che vanno creati, per default non registrano gli eventi sui dati, come le letture degli oggetti S3.

I log sui dati generano grandi volumi, ma cosa registrare va deciso prima dell'incidente, da chi conosce i dati.

7. Errori copiati da template e infrastructure as code

Quando l'infrastruttura nasce da codice, un errore nel template si replica in ogni ambiente che lo usa. Vale anche al contrario: la NSA indica l'infrastructure as code come un modo per ridurre gli errori di configurazione, e NSA e CISA suggeriscono di scrivere anche i permessi come codice (policy as code), così da avere uno stato di riferimento da cui accorgersi delle derive. Cosa cerca uno scanner nei template prima del deploy, e cosa gli sfugge, è nella scheda sull'IaC scanning.

8. Accessi di terze parti e applicazioni SaaS dimenticati

Fornitori e managed service provider con accessi permanenti, applicazioni collegate al tenant e mai riviste. NSA e CISA notano che gli attaccanti provano a sfruttare gli account esterni a cui è stato concesso accesso al tenant, e hanno dedicato una scheda della serie del 7 marzo 2024 ai rischi dei managed service provider nel cloud. Anche Microsoft 365 e Google Workspace vanno controllati come un account AWS.

La trappola dei default migliorati

I provider hanno reso più sicure le impostazioni di partenza, ma il cambiamento vale soprattutto per ciò che si crea dopo. Restano fuori, per esempio, i bucket S3 nati prima di aprile 2023 e le organizzazioni Google Cloud create prima del 3 maggio 2024. Google lo scrive nella pagina sulle organizzazioni sicure per default: un'organizzazione nuova può avere una postura di sicurezza diversa da quelle già esistenti.

Un cloud aperto qualche anno fa porta con sé le impostazioni di allora. Quando un provider annuncia un default più sicuro, la domanda è: lo abbiamo applicato anche a quello che c'era già?

Come si trovano gli errori di configurazione

Il cloud cambia a ogni rilascio: serve una sequenza ripetibile.

Parti dall'inventario degli account

Elenca tutti gli account AWS, le subscription Azure, i progetti Google Cloud e i tenant SaaS, compresi quelli di test e quelli aperti da un fornitore. Un errore non si cerca in un account che non sai di avere.

Usa gli strumenti nativi del provider

• AWS Security Hub CSPM confronta gli account con standard come le AWS Foundational Security Best Practices, i CIS Benchmark, PCI DSS e NIST.
• Microsoft Defender for Cloud, quando viene attivato su una subscription, applica per default il Microsoft cloud security benchmark e calcola un secure score; valuta anche account AWS e progetti Google Cloud collegati.
• Security Command Center, con i suoi servizi gestiti di analisi, cerca negli ambienti Google Cloud gli errori di configurazione più comuni.

Sugli accessi servono controlli specifici. AWS indica IAM Access Analyzer per verificare gli accessi pubblici e tra account diversi e per generare policy a privilegio minimo dall'attività reale, e chiede di rimuovere con regolarità utenti, ruoli, permessi e credenziali inutilizzati. Per Microsoft 365 e Google Workspace, CISA mette a disposizione gratuitamente ScubaGear e ScubaGoggles, che confrontano la configurazione del tenant con le baseline del progetto SCuBA.

Misura contro una baseline riconosciuta

I Foundations Benchmark del CIS esistono per AWS, Azure e Google Cloud e fissano una base a livello di account. Come sono fatti e quale profilo scegliere lo spieghiamo in CIS Benchmark: cos'è e come si usa.

Con più cloud, una vista sola e un ordine di priorità

Con più provider serve una vista unica, ed è il lavoro del CSPM, la componente di una CNAPP che legge le configurazioni via API. La differenza che conta è la priorità: un bucket pubblico vuoto e un bucket pubblico con i dati dei clienti, raggiungibile da un'identità con permessi eccessivi, non sono lo stesso problema.

Wiz, di cui AmagisTech è partner, si collega agli account cloud via API, senza agenti, e mette in relazione errori di configurazione, vulnerabilità, identità, segreti, esposizione su internet e dati sensibili per individuare le combinazioni che formano un percorso di attacco reale (Wiz, How to Evaluate Wiz: Common FAQs). Cosa si riceve da una prima analisi di questo tipo lo raccontiamo nella fotografia del cloud.

Blocca a monte le configurazioni vietate

• Guardrail a livello di organizzazione. Le service control policy di AWS Organizations, che AWS raccomanda per fissare limiti ai permessi su tutti gli account, le policy di organizzazione di Google Cloud, Azure Policy. Bloccano in partenza le configurazioni non ammesse, per esempio, su Google Cloud, la creazione di chiavi persistenti per i service account.
• Controlli sui template nella pipeline. Un errore fermato nel codice non arriva in produzione.

E la compliance?

Nella ISO/IEC 27001:2022 la configurazione sicura corrisponde al controllo 8.9 dell'Annex A (Configuration management) e l'uso dei servizi cloud al 5.23. Cosa prevedono NIS2 e le misure ACN sulle configurazioni sicure lo abbiamo ricostruito nella guida all'hardening dei sistemi.

In sintesi

Gli errori di configurazione cloud più frequenti riguardano permessi, chiavi, MFA, risorse esposte, reti aperte, log e accessi di terzi. I provider hanno migliorato i default, ma soprattutto per le risorse nuove. Si trovano con inventario, strumenti nativi, una baseline riconosciuta e, con più cloud, un controllo continuo via API che ordini i problemi per rischio reale.

Se vuoi capire se questi errori ci sono anche nel tuo cloud, puoi partire dalla fotografia del cloud con Wiz: collegamento via API, senza agenti, a partire da una call di 20 minuti con un advisor AmagisTech.