7 errori compliance cloud: come prevenirli subito

I sette errori di compliance cloud che ricorrono più spesso nelle aziende italiane sono: configurazioni errate delle risorse, chiavi e credenziali esposte, assenza di autenticazione a più fattori, gestione privilegi (IAM) inadeguata, backup e piani di ripristino incompleti, patching trascurato, e logging/crittografia insufficienti a cui si aggiunge l’ambiguità sulla titolarità dei controlli tra cliente e provider.

Per ognuno esiste un’azione correttiva verificabile da subito: eseguire una scansione CSPM sulle risorse pubbliche, ruotare le chiavi statiche più vecchie di 90 giorni, imporre MFA su tutti gli account con privilegi amministrativi, rivedere i ruoli IAM con permessi eccessivi, testare un restore completo, verificare la data dell’ultima patch critica, esportare i log su storage immutabile e infine formalizzare per iscritto chi controlla cosa nel modello di responsabilità condivisa.

Due segnali indicano che il lavoro sta funzionando: la totalità degli account admin ha MFA attivo e i log che restano disponibili ed esportati oltre la finestra di conservazione predefinita del provider, spesso limitata a 30 o 90 giorni.

Punti chiave

La compliance cloud richiede monitoraggio continuo e mappatura chiara delle responsabilità: senza questi due elementi, anche una certificazione ottenuta perde valore nel tempo.

Indice

• Perché la compliance cloud è diversa da quella on-premise
• I 7 errori di compliance cloud: impatto e correzioni pratiche
• Governance operativa con ISO 27017, ISO 27018 e NIS2
• Tempi e costi per correggere gli errori più comuni
• Checklist operativa: 10 azioni da eseguire subito
• Fonti

Perché la compliance cloud è diversa da quella on-premise

Nel cloud la responsabilità è condivisa per definizione: il provider gestisce l’infrastruttura fisica, ma identity management, configurazione delle risorse, logging e patching applicativo restano quasi sempre a carico del cliente. Le risorse cloud nascono e vengono distrutte in minuti, quindi una configurazione sicura oggi può diventare una falla domani senza che nessuno la modifichi consapevolmente: è la cosiddetta deriva di configurazione.

Le linee guida tecniche collegate alla direttiva NIS2 richiedono che le entità sottoposte agli obblighi eseguano monitoraggio e revisioni periodiche della compliance, con evidenze documentate e reporting al management almeno una volta all’anno o dopo cambiamenti rilevanti.

Una certificazione ottenuta non basta se non è accompagnata da un monitoraggio continuo: i controlli implementati una volta sola perdono efficacia man mano che l’infrastruttura cambia sotto di loro.

Questo è il motivo per cui un audit statico, fatto una volta e archiviato, non regge più il confronto con un’infrastruttura che cambia ogni giorno.

I 7 errori di compliance cloud: impatto e correzioni pratiche

1. Configurazioni errate delle risorse cloud. Bucket di storage pubblici, database esposti su internet senza restrizioni di rete, ambienti di test dimenticati online: sono la causa più comune di violazione della compliance. L’impatto è immediato sulla fiducia dell’auditor, perché dimostra assenza di controlli automatizzati. Come evidenziano diverse analisi tecniche, molte lacune nascono dall’assunzione errata che il provider “gestisca tutto”. Correzione: attivare uno strumento CSPM con scansione continua e definire baseline di configurazione per ogni tipo di risorsa. Quick check: nessuna risorsa di storage risulta pubblica senza autorizzazione esplicita; il report CSPM viene esportato mensilmente.

2. Chiavi di accesso e credenziali esposte. Chiavi API salvate in repository di codice, credenziali statiche che non ruotano mai, service account con permessi eccessivi. Correzione: adottare un secret manager centralizzato e imporre rotazione automatica. Quick check: nessuna chiave attiva ha più di 90 giorni; scansione dei repository per credenziali in chiaro completata senza esiti.

3. Assenza di autenticazione a più fattori. Un singolo account amministrativo senza MFA è spesso il punto di ingresso più semplice per un attacco. Correzione: rendere MFA obbligatorio a livello di policy per tutti gli account con privilegi, non solo per quelli “critici”. Quick check: elenco utenti con MFA attivo su tutti gli account admin; log della policy di enforcement disponibile.

4. IAM e gestione privilegi inadeguati. Ruoli troppo permissivi, principio del minimo privilegio ignorato, account condivisi tra più persone. Correzione: rivedere periodicamente i ruoli e applicare accessi temporanei per operazioni sensibili. Quick check: report di access review periodico firmato; nessun ruolo con permessi “owner” assegnato a più di due persone.

5. Backup e piani di ripristino incompleti. Avere un backup non basta se non è mai stato testato: il vero rischio compliance è non poter dimostrare che il ripristino funziona nei tempi previsti. Correzione: eseguire test di restore programmati e documentare i tempi di recupero. Quick check: ultimo test di restore completato con esito positivo negli ultimi 90 giorni.

6. Patching trascurato. Vulnerabilità note su sistemi operativi o componenti applicativi restano aperte per mesi. Correzione: automatizzare il patch management e tracciare le finestre di intervento. Quick check: nessuna vulnerabilità critica aperta da più di 30 giorni.

7. Logging insufficiente, crittografia carente e ambiguità sul modello di responsabilità. La retention predefinita dei log su molti servizi cloud copre solo 30 o 90 giorni, un intervallo spesso insufficiente per le richieste di un auditor. A questo si aggiunge la crittografia dei dati non attivata di default e la mancanza di un documento che chiarisca chi controlla cosa tra cliente e provider. Correzione: esportare i log su storage immutabile con retention di almeno 12 mesi, cifrare i dati a riposo e in transito, e formalizzare una matrice di responsabilità.

Un consiglio: imposta la retention dei log direttamente nella policy dello storage, non solo nel servizio di logging: uno storage immutabile con lock temporale impedisce anche una cancellazione accidentale o dolosa.

Un consiglio: integra il CSPM nel flusso di deployment, non come controllo separato: una scansione che blocca il rilascio in caso di configurazione non conforme costa meno di una violazione scoperta dopo mesi.

Governance operativa con ISO 27017, ISO 27018 e NIS2

ISO 27017 e ISO 27018 non sono certificazioni a sé stanti: funzionano come estensioni operative dell’ISMS costruito su ISO 27001, e servono proprio a mappare la responsabilità condivisa, definire le regole sui subprocessor e formalizzare la cancellazione sicura dei dati.

Gli auditor chiedono evidenze concrete: report di monitoraggio standardizzati, log con retention documentata, prove di test di ripristino. La guida che collega gli obblighi NIS2 dell’articolo 21(2) alla normativa tecnica CIR 2024/2690 mostra che log, patching e backup restano responsabilità del soggetto, anche quando l’infrastruttura è affidata a un provider terzo.

Le estensioni ISO per il cloud vanno integrate nel sistema di gestione esistente, aggiornando SoA, risk assessment e audit interni, non trattate come adempimenti isolati.

La frequenza minima raccomandata per il monitoraggio della compliance è annuale, con revisione immediata dopo ogni incidente o cambiamento significativo dell’infrastruttura, secondo le linee guida tecniche ENISA.

Tempi e costi per correggere gli errori più comuni

Non tutti gli errori richiedono lo stesso sforzo. Una pianificazione a cinque tappe permette di intervenire secondo priorità di rischio, partendo da ciò che espone dati sensibili o servizi pubblici:

1. Quick win (1-2 settimane): attivazione MFA, chiusura risorse pubbliche non autorizzate. Costo: minimo, gestibile con il team interno.
2. Patching e IAM (2-4 settimane): revisione ruoli, automazione patch. Costo: moderato, spesso richiede tool aggiuntivi.
3. Logging e retention (3-6 settimane): configurazione storage immutabile, policy di conservazione. Costo: variabile in base al volume di log.
4. Test di backup e disaster recovery (4-8 settimane): simulazioni di restore documentate. Costo: da moderato a elevato se richiede consulenza esterna.
5. Governance e documentazione (continuo): mappatura ISO 27017/27018, revisione annuale. Costo: dipende dal ricorso a consulenza specializzata.

La priorità va sempre a ciò che combina esposizione di dati sensibili, privilegi elevati e accesso pubblico non controllato.

Checklist operativa: 10 azioni da eseguire subito

1. Esegui uno scan CSPM completo. Risultato: report con zero risorse pubbliche non autorizzate. Responsabile: team infrastruttura.
2. Attiva MFA su tutti gli account admin. Risultato: elenco utenti con MFA=on al 100%. Responsabile: IAM owner.
3. Ruota le credenziali statiche. Risultato: nessuna chiave attiva oltre 90 giorni. Responsabile: security team.
4. Rivedi i ruoli IAM con privilegi eccessivi. Risultato: report di access review firmato. Responsabile: manager IT.
5. Esporta i log su storage immutabile per almeno 12 mesi. Risultato: policy di retention documentata. Responsabile: SOC/logging owner.
6. Cifra dati a riposo e in transito. Risultato: configurazione crittografia verificata su ogni servizio. Responsabile: architetto cloud.
7. Automatizza il patch management. Risultato: nessuna vulnerabilità critica oltre 30 giorni. Responsabile: team operations.
8. Esegui un test di restore completo. Risultato: report con tempo di recupero misurato. Responsabile: team backup/DR.
9. Formalizza la matrice di responsabilità cliente-provider. Risultato: documento firmato e allegato all’ISMS. Responsabile: responsabile compliance.
10. Pianifica una revisione della compliance almeno annuale. Risultato: calendario di audit interno approvato. Responsabile: management/CISO.

Punto di vista di Securityhub sugli errori più ricorrenti

Nei progetti di certificazione osserviamo lo stesso schema: molte aziende trattano la compliance cloud come un progetto da chiudere una volta, non come un ciclo. Le evidenze operative, non il certificato appeso alla parete, sono ciò che regge davanti a un auditor. Integrare la revisione periodica nel calendario operativo, non solo nel piano di audit, fa la differenza tra dimostrare conformità e sperare di superarla.

Come Securityhub trasforma questi errori in evidenze pronte per l’audit

Correggere i sette errori descritti richiede spesso più di un intervento tecnico: serve un impianto documentale coerente che regga davanti a un auditor esterno. Securityhub affianca responsabili IT e titolari di PMI italiane nella costruzione di questo impianto attraverso consulenza per la certificazione ISO 27001, ISO 27017 e ISO 27018, audit interni e supporto nella preparazione della documentazione richiesta.

A differenza di un intervento spot su singole configurazioni, il lavoro con Securityhub integra i controlli cloud-specifici direttamente nel sistema di gestione della sicurezza esistente, evitando di dover rifare da zero l’analisi dei rischi ogni volta che cambia un requisito normativo. Chi vuole capire da dove partire può consultare la spiegazione dei sistemi di gestione della sicurezza e richiedere un primo assessment mirato sulla propria infrastruttura cloud.

Fonti

• ENISA — Technical implementation guidance on cybersecurity risk management measures (CIR 2024/2690)
• ISO 27001, 27017, and 27018: Understanding the Differences | Agency
• NIS2 Cloud Security: 5 Article 21 Controls Mapped to CIR 2024/2690 for AWS, Azure, and GCP – NIS2-Templates.com

Raccomandati

• 7 errori comuni nella sicurezza e come evitarli in azienda – Security Hub
• 7 esempi di misure preventive ISO 27017 per la sicurezza cloud – Security Hub
• 7 errori comuni ISO 27001 da evitare per la tua azienda – Security Hub
• 6 errori comuni certificazione ISO e come evitarli – Security Hub