L’adozione del cloud nei settori ad alta criticità (energia, trasporti, sanità, infrastrutture digitali, finanza) ha raggiunto una maturità operativa che non ammette più approcci improvvisati.

Infrastrutture ibride, ambienti multi-cloud, workload distribuiti tra on-premise e provider pubblici: lo scenario tecnologico è cambiato in profondità, ma con la complessità architetturale è cresciuta anche quella normativa.

Il cloud nei settori critici: opportunità e responsabilità

La direttiva NIS2 (recepita in Italia con il D.lgs. 138/2024), il regolamento DORA per il settore finanziario, il GDPR per il trattamento dei dati personali e le linee guida ENISA per la sicurezza cloud definiscono un quadro di obblighi articolato e non sempre facilmente leggibile.

A questi si affiancano framework tecnici internazionali – ISO 27001, ISO 27017, ISO 27018, CSA CCM, NIST CSF – che forniscono il vocabolario operativo per tradurre i requisiti normativi in controlli concreti.

La cloud compliance, in questo contesto, non è semplicemente una questione di audit e certificazioni. È il risultato di scelte architetturali, processi di governance e capacità tecniche che devono essere integrate fin dalla progettazione dei sistemi.

Chi opera nei settori critici lo sa bene: un incidente di sicurezza su un ambiente cloud non è solo un problema tecnico, è un evento con ricadute regolatorie, reputazionali e, in certi casi, penali.

Il quadro normativo: cosa chiedono NIS2, DORA e GDPR al cloud

Ecco, innanzitutto, un quadro d’insieme di quello che è l’attuale quadro normativo in cui si muovono aziende e professionisti del settore.

NIS2 e la sicurezza della supply chain cloud

La direttiva NIS2 impone ai soggetti essenziali e importanti di adottare misure tecniche e organizzative adeguate alla gestione dei rischi per la sicurezza delle reti e dei sistemi informativi. Per chi utilizza servizi cloud, questo si traduce in obblighi precisi: valutazione del rischio dei provider, contrattualizzazione dei requisiti di sicurezza, monitoraggio continuo e capacità di risposta agli incidenti.

L’articolo 21 della direttiva è esplicito nel citare la sicurezza della catena di approvvigionamento come area di intervento obbligatoria. Un’organizzazione che esternalizza workload critici su infrastrutture cloud senza presidiare la catena di fornitura non è conforme, indipendentemente dalle certificazioni del proprio CSP (Cloud Service Provider). La responsabilità rimane in capo al soggetto regolamentato.

Dunque, è importante:

• mappare tutti i CSP e sub-processor nella catena cloud;
• includere clausole di sicurezza nei contratti (SLA, diritto di audit, notifica incidenti);
• effettuare una valutazione del rischio specifica per ogni provider critico;
• verificare che i CSP rispettino standard riconosciuti (ISO 27001, CSA STAR, SOC 2).

DORA: resilienza operativa digitale nel cloud finanziario

Per le entità finanziarie (banche, assicurazioni, gestori di fondi, infrastrutture di mercato) il regolamento DORA (Digital Operational Resilience Act, applicabile dal 17 gennaio 2025) introduce requisiti specifici per la gestione del rischio ICT legato ai provider terzi, inclusi i CSP.

L’ICT Third-party risk management (TPRM) diventa un processo strutturato, con registro dei contratti, valutazione della concentrazione e test di resilienza operativa.

DORA distingue tra provider ICT critici e non critici e per i primi prevede un regime di sorveglianza diretta da parte delle autorità europee (EBA, ESMA, EIOPA). Chi utilizza hyperscaler come AWS, Azure o Google Cloud per funzioni critiche deve verificare se il proprio CSP è stato designato come provider critico e adeguare di conseguenza il proprio framework di governance.

Anche in questo caso, come per la NIS2, è importante:

• classificare i servizi cloud per criticità operativa;
• aggiornare il registro dei contratti ICT con tutti i provider cloud;
• eseguire TLPT (Threat-Led Penetration Testing) su ambienti cloud critici;
• definire exit strategy e piani di migrazione per ogni CSP critico.

GDPR e protezione dei dati nel cloud

Il GDPR non è una novità, ma la sua applicazione al cloud resta un terreno di frequenti non conformità.

Il trasferimento di dati personali verso CSP extra-UE (in particolare verso provider statunitensi) richiede la verifica delle basi giuridiche di trasferimento (Standard Contractual Clauses, adeguatezza del paese terzo) e la conduzione di Transfer Impact Assessment (TIA) in presenza di rischi elevati.

La ISO 27018 è lo standard di riferimento specifico per la protezione dei dati personali nel cloud pubblico: definisce i controlli che i CSP devono implementare come processor. La sua adozione da parte del provider non esonera il titolare del trattamento dalle proprie responsabilità, ma costituisce un elemento significativo nella valutazione del rischio e nella documentazione della conformità.

Come per la NIS2 e il DORA, è importante:

• verificare la base giuridica per ogni trasferimento extra-UE;
• condurre TIA per i trasferimenti verso provider US con leggi di sorveglianza applicabili (CLOUD Act, FISA 702);
• selezionare CSP certificati ISO 27018;
• configurare la data residency per i dati sensibili;
• aggiornare il registro dei trattamenti con i riferimenti ai CSP come responsabili.

I framework di riferimento: da ISO 27017 a CSA CCM

Alla luce di quanto visto finora, è utile anche analizzare quelli che sono i framework di riferimento in materia di cloud security.

ISO 27001 e ISO 27017: la base della sicurezza cloud

ISO 27001 rimane lo standard fondamentale per i sistemi di gestione della sicurezza delle informazioni. Nel contesto cloud, la sua applicazione richiede un’estensione specifica: la ISO 27017 fornisce i controlli aggiuntivi per i servizi cloud, distinguendo le responsabilità tra CSP e cliente (cloud customer).

Questo allineamento è essenziale per evitare il rischio più comune nella governance cloud: le zone grigie, ovvero i controlli che nessuno presidia perché ciascuna parte assume che sia responsabilità dell’altra.

Lo standard introduce 7 controlli specifici per il cloud non presenti in ISO 27001, tra cui la gestione degli asset nel cloud, la protezione dell’ambiente virtuale del cliente, la configurazione delle reti virtuali e le procedure di cessazione del servizio.

La certificazione ISO 27017 di un CSP è un indicatore utile, ma non sufficiente: il cliente deve verificare che i controlli applicabili siano effettivamente implementati e non solo dichiarati.

CSA Cloud Controls Matrix: il riferimento operativo

La Cloud Controls Matrix (CCM) del Cloud Security Alliance è lo strumento più granulare per la valutazione della sicurezza cloud. Nella versione 4.0, la CCM organizza 197 obiettivi di controllo in 17 domini, dalla gestione delle identità alla sicurezza delle applicazioni, dalla crittografia alla gestione degli incidenti. Per ogni controllo, la matrice specifica se la responsabilità è del CSP, del cliente o condivisa.

La CCM si integra con CAIQ (Consensus Assessments Initiative Questionnaire), il questionario standardizzato che i provider compilano per comunicare il proprio posture di sicurezza.

Questo strumento è particolarmente utile nelle fasi di vendor assessment: consente di confrontare diversi CSP su una base comune e di identificare rapidamente i gap rispetto ai propri requisiti di sicurezza.

NIST CSF e CIS Controls: il complemento operativo

Il NIST Cybersecurity Framework (CSF) 2.0 ha introdotto la funzione Govern come sesto pilastro, affiancando le cinque funzioni originali (Identify, Protect, Detect, Respond, Recover). Questa evoluzione è particolarmente rilevante per il cloud: la governance della sicurezza non può essere delegata al CSP, deve essere esercitata attivamente dall’organizzazione cliente attraverso policy, ruoli e processi di supervisione.

I CIS Controls v8 offrono un percorso implementativo strutturato in tre livelli di priorità (Implementation Groups), adatto anche alle organizzazioni con risorse limitate.

I controlli relativi al cloud, in particolare CIS Control 4 (Secure Configuration), 6 (Access Control Management) e 12 (Network Infrastructure Management), sono stati aggiornati per coprire ambienti IaaS, PaaS e SaaS, con indicazioni specifiche per la configurazione sicura degli hyperscaler.

Strategie operative: costruire un programma di cloud compliance

Il concetto di Shared Responsibility Model è noto, ma spesso mal applicato. AWS, Azure e Google Cloud pubblicano matrici dettagliate che definiscono cosa è responsabilità del provider e cosa è responsabilità del cliente.

La regola generale è chiara: più si sale nello stack (da IaaS a PaaS a SaaS), più responsabilità si trasferiscono al provider. Ma questo non significa che il cliente possa dismettere la propria governance.

Anche in un ambiente SaaS, il cliente è responsabile della gestione delle identità e degli accessi, della classificazione dei dati che carica sulla piattaforma, della configurazione delle policy di sicurezza disponibili e della supervisione degli accessi privilegiati.

I data breach più frequenti in ambiente cloud non derivano da vulnerabilità del CSP, ma da misconfigurazioni del cliente: bucket S3 pubblici, credenziali IAM con privilegi eccessivi, log di audit disabilitati.

Cloud Security Posture Management: visibilità continua

Un programma di cloud compliance efficace non può basarsi su audit puntuali. Gli ambienti cloud sono dinamici: nuove risorse vengono provisionate in minuti, le configurazioni cambiano, i permessi si accumulano.

Il CSPM (Cloud Security Posture Management) è la categoria di strumenti che risponde a questa esigenza, fornendo visibilità continua sullo stato di conformità dell’ambiente cloud rispetto a policy predefinite e framework normativi.

I principali strumenti CSPM, tra cui Microsoft Defender for Cloud, Prisma Cloud, Wiz e Lacework, permettono di mappare automaticamente le risorse cloud, rilevare misconfigurazioni, valutare la conformità rispetto a benchmark come CIS, NIST e ISO 27001, e prioritizzare la remediation in base al rischio effettivo.

Per le organizzazioni che operano in ambienti multi-cloud, è essenziale scegliere strumenti che supportino nativamente tutti i provider utilizzati.

Fatto questo, è utile:

• implementare uno strumento CSPM per ogni ambiente cloud produttivo;
• configurare policy di conformità basate su CIS Benchmarks e framework NIS2;
• abilitare il monitoraggio continuo con alert su misconfigurazioni critiche;
• integrare i risultati CSPM nel processo di gestione delle vulnerabilità;
• eseguire revisioni periodiche dei permessi IAM con strumenti di analisi dei diritti (CIEM).

Gestione delle identità e degli accessi: il perimetro è l’identità

Nel cloud, il perimetro di sicurezza tradizionale non esiste: l’identità è il nuovo perimetro. Una gestione rigorosa di IAM (Identity and Access Management) è il controllo più critico per la sicurezza cloud e, non a caso, uno dei requisiti espliciti tanto di NIS2 quanto di DORA.

Il principio del minimo privilegio deve essere applicato con strumenti automatizzati: in ambienti cloud complessi, la gestione manuale dei permessi è intrinsecamente insicura.

La federazione delle identità (SSO, SAML, OIDC), l’autenticazione a più fattori obbligatoria per tutti gli account privilegiati, la gestione dei segreti con vault dedicati (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) e l’analisi dei diritti effettivi rispetto a quelli concessi (Permission Gap Analysis) sono i pilastri di un programma IAM cloud maturo.

Per i settori critici, l’accesso privilegiato agli ambienti cloud deve essere mediato da soluzioni PAM (Privileged Access Management) con sessione registrata.

Data protection by design: crittografia e data residency

La protezione dei dati nel cloud richiede un approccio by design: le scelte di crittografia, classificazione e residenza dei dati devono essere fatte prima del provisioning, non corrette a posteriori. La crittografia end-to-end con chiavi gestite dal cliente (BYOK, Bring Your Own Key, o ancora HYOK, Hold Your Own Key per i contesti più sensibili) è il requisito minimo per i dati classificati come riservati o critici.

La data residency (ossia, la garanzia che i dati risiedano fisicamente in specifiche regioni geografiche) è un requisito normativo esplicito per alcune categorie di dati in settori regolamentati.

Tutti i principali CSP offrono oggi sovereign cloud o zone dedicate per i dati europei. Per le organizzazioni nei settori critici, è necessario verificare non solo la residenza dei dati primari, ma anche quella dei backup, dei log e dei metadati.

Dalla compliance alla resilienza: il ciclo di miglioramento continuo

Un programma di cloud compliance maturo non si esaurisce nel raggiungimento di una certificazione o nel superamento di un audit. È un ciclo continuo di valutazione, miglioramento e adattamento.

Il panorama normativo evolve (basti pensare all’implementazione progressiva di NIS2 nei diversi Stati membri) e con esso evolvono le minacce e le tecnologie disponibili per contrastarle.

La metrica più utile per misurare la maturità di un programma di cloud compliance non è il numero di controlli implementati, ma la velocità con cui l’organizzazione è in grado di rilevare e rispondere a una deviazione dal baseline di conformità.

Un ambiente cloud ben governato dovrebbe essere in grado di rilevare una misconfigurazione critica in minuti, non in settimane.

Per i CISO e i responsabili della sicurezza che operano nei settori critici, il messaggio finale è questo: la cloud compliance non è un progetto, è una competenza organizzativa. Richiede investimento in persone, processi e tecnologie, ma soprattutto richiede che la sicurezza cloud sia considerata una funzione strategica, non un adempimento burocratico.

Le organizzazioni che lo hanno compreso sono quelle che trasformano gli obblighi normativi in vantaggio competitivo. Perché la fiducia, nel mercato digitale, è essa stessa un asset.