Cloud security: gli errori di configurazione che contano

La maggior parte degli incidenti nel cloud non nasce da una vulnerabilità sofisticata del provider, ma da una configurazione sbagliata lato cliente. Un permesso troppo ampio, un archivio esposto, una chiave dimenticata in un repository. Il cloud non è meno sicuro del data center: è sicuro in modo diverso, e presuppone che Lei sappia esattamente quale metà del lavoro è Sua.

Il valore del cloud — velocità, elasticità, servizi gestiti — arriva insieme a una superficie che cambia in continuazione. Ogni nuova risorsa è una configurazione, e ogni configurazione può essere corretta o sbagliata. Gli errori che contano di più sono pochi e ricorrenti.

Il modello di responsabilità condivisa, capito sul serio

Ogni provider pubblica una versione dello stesso patto: loro proteggono l’infrastruttura, Lei protegge ciò che ci mette sopra — dati, identità, configurazioni, codice. Il confine si sposta a seconda del servizio: con una macchina virtuale gestisce quasi tutto lo stack; con un servizio serverless o gestito la responsabilità del provider sale, ma la configurazione degli accessi e la protezione dei dati restano sempre Sue.

Gli incidenti nascono spesso nella zona grigia, dove entrambe le parti danno per scontato che se ne occupi l’altra. Il primo controllo è capire, servizio per servizio, dove finisce il confine.

IAM: dove si decide quasi tutto

Nel cloud l’identità è il piano di controllo. Chi può creare, leggere, modificare e distruggere risorse è definito da policy IAM, e qui si concentra la maggior parte del rischio. I ruoli con permessi eccessivi, le utenze con privilegi amministrativi “per comodità”, i permessi ereditati che nessuno ha più rivisto: sono questi a trasformare un singolo accesso compromesso in un problema di ambiente.

Il principio è sempre il minimo privilegio, con permessi legati al compito e non alla persona, e una revisione periodica di ciò che è davvero in uso. Vanno trattati con particolare cura i ruoli capaci di modificare le policy stesse o di disattivare i log: sono le chiavi del regno.

La gestione dei segreti

Chiavi di accesso, token e password non vanno nel codice, nelle immagini dei container o nelle variabili d’ambiente lasciate in chiaro. Eppure è uno degli errori più comuni: un segreto committato in un repository, magari privato oggi e pubblico domani, resta nella storia del versionamento anche dopo essere stato rimosso.

La risposta è un servizio dedicato alla gestione dei segreti, con recupero a runtime, rotazione regolare e — dove possibile — credenziali di breve durata legate all’identità del carico di lavoro anziché a chiavi statiche. Meno segreti a lunga vita esistono, meno cose possono essere rubate.

Log e visibilità: vedere cosa succede

Non può indagare un incidente che non ha registrato. Il logging del piano di gestione — chi ha fatto quale chiamata API, quando e da dove — è la traccia che distingue una domanda a cui può rispondere in un’ora da una ricostruzione impossibile a mesi di distanza. Va abilitato in tutti gli account e in tutte le regioni, non solo in quelli che ricorda.

Ma i log servono solo se qualcuno li guarda. Servono conservazione adeguata, protezione da manomissioni e un minimo di rilevamento sui segnali che contano: creazione di credenziali, cambi di policy, accessi da luoghi inattesi. La visibilità è ciò che rende la sicurezza cloud verificabile invece che presunta.

Esposizione dei dati: pubblico per errore

Uno degli errori più costosi è anche uno dei più banali: un archivio di oggetti, un database o un backup reso raggiungibile dall’esterno senza che nessuno l’avesse deciso davvero. Basta un permesso di rete allentato, una policy di accesso troppo aperta, un ambiente di test copiato dalla produzione con i dati veri dentro. Il dato non è stato “rubato”: era pubblico e qualcuno l’ha semplicemente trovato.

La difesa è stratificata: la cifratura a riposo e in transito come base, ma soprattutto controlli che impediscano l’esposizione pubblica per impostazione predefinita, così che renderla accessibile richieda un atto esplicito e tracciato invece di essere un incidente silenzioso. E vale la pena sapere, in ogni momento, dove vivono i dati che contano davvero.

Rendere sicuro il default, non l’eccezione

Correggere le configurazioni una per una è una battaglia che non finisce. La leva vera è il modo in cui le risorse nascono: infrastruttura come codice con configurazioni sicure per impostazione predefinita, controlli automatici che bloccano gli errori noti prima del rilascio, e guardrail a livello di azienda che impediscono le configurazioni più pericolose ovunque, non account per account.

Così la sicurezza smette di essere una pulizia perenne e diventa una proprietà del modo in cui costruisce.

In sintesi

Nel cloud gli errori che contano sono pochi: confini di responsabilità dati per scontati, IAM troppo generoso, segreti mal gestiti e log assenti. Li affronti all’origine — con default sicuri, minimo privilegio e visibilità reale — e avrà eliminato la maggior parte degli incidenti prima che diventino tali.