NIS2 e cloud: le misure su AWS, Azure e Google Cloud

Risposta breve: la NIS2 non ha regole a parte per il cloud. Le misure del D.Lgs. 138/2024 e le misure di sicurezza di base di ACN valgono per i sistemi che usi, anche se girano su AWS, Azure o Google Cloud. Il provider risponde della sua infrastruttura; account, identità, configurazioni, log, backup e il rapporto con il fornitore restano a te, e ACN chiede di mettere in inventario anche i servizi cloud.

Sotto, le misure ACN lette sul cloud pubblico, il rapporto con il provider e chi notifica un incidente. Per il quadro generale c'è la guida completa alla NIS2.

Due soggetti NIS2 nello stesso cloud

Nel rapporto fra un'azienda e il suo cloud provider la NIS2 entra due volte.

Il provider è un soggetto NIS2 per conto suo. I fornitori di servizi di cloud computing stanno nel settore delle infrastrutture digitali dell'allegato I del D.Lgs. 138/2024. L'articolo 5 li sottopone alla giurisdizione dello Stato membro in cui hanno lo stabilimento principale nell'Unione, cioè quello in cui si prendono prevalentemente le decisioni sulla gestione del rischio informatico. Per loro la Commissione europea ha fissato requisiti tecnici e metodologici dettagliati con il Regolamento di esecuzione (UE) 2024/2690.

Tu sei un soggetto NIS2 per i tuoi sistemi. L'articolo 24 del decreto chiede misure di gestione del rischio per i sistemi informativi e di rete che i soggetti utilizzano nelle loro attività o nella fornitura dei loro servizi. Non distingue fra un server in sala macchine e una macchina virtuale in una region europea.

Quindi la conformità del provider non si trasferisce al cliente. I tre grandi provider lo scrivono nei propri modelli di responsabilità condivisa:

• AWS risponde della sicurezza of the Cloud (hardware, software, rete e strutture che fanno girare i servizi); la sicurezza in the Cloud resta al cliente e dipende dal servizio. Su un'istanza EC2, che è IaaS, sistema operativo, patch e security group sono del cliente.
• Microsoft scrive che, per ogni tipo di servizio cloud, dati e identità restano del cliente (pagina Shared responsibility in the cloud, aggiornata il 24/08/2026).
• Google Cloud, nella sua pagina sulla NIS2, si impegna nei contratti sulle misure di sicurezza dei propri servizi e ricorda che la sicurezza dei dati e delle applicazioni nel cloud la definisce il cliente.

Le misure ACN lette sul cloud

In Italia le misure dell'articolo 24 sono state tradotte da ACN nelle misure di sicurezza di base della Determinazione 379907/2025: l'allegato 1 ne elenca 37 per i soggetti importanti, l'allegato 2 ne elenca 43 per gli essenziali. Ecco quelle che sul cloud cambiano forma.

1. Inventario: account, servizi e flussi

La misura ID.AM-04 è l'unica che nomina il cloud in modo esplicito: «È mantenuto un inventario aggiornato dei servizi informatici erogati dai fornitori, ivi inclusi i servizi cloud.» Accanto c'è ID.AM-02, l'inventario di servizi, sistemi e applicazioni, comprese quelle accessibili tramite API. Per i soggetti essenziali si aggiunge ID.AM-03, l'inventario dei flussi di rete fra i propri sistemi e l'esterno.

Sul cloud l'inventario parte da un elenco che spesso nessuno ha completo: tutti gli account AWS, le subscription Azure e i progetti Google Cloud, compresi quelli di test. Un account fuori inventario resta fuori anche dalla valutazione del rischio.

2. Identità e accessi

Sul cloud queste misure valgono prima di tutto per la console e le API da cui si amministra tutto:

• PR.AA-01: tutte le utenze, comprese quelle con privilegi amministrativi e quelle per l'accesso remoto, censite e individuali, con verifica periodica delle autorizzazioni almeno sui sistemi rilevanti. Nel cloud contano anche account di servizio, chiavi di accesso e ruoli usati dalle applicazioni, non solo le persone.
• PR.AA-03: autenticazione multifattore almeno per i sistemi rilevanti, in base alla valutazione del rischio.
• PR.AA-05: permessi assegnati secondo minimo privilegio e separazione delle funzioni, e utenze amministrative distinte da quelle ordinarie, con credenziali diverse. Nel cloud i permessi si accumulano in fretta: un ruolo largo dato per sbloccare un rilascio tende a restare.

I sistemi informativi e di rete rilevanti sono, per la determinazione, quelli la cui compromissione avrebbe un impatto significativo sui servizi per cui il soggetto rientra nella NIS2 (articolo 1, lettera l).

3. Configurazione ed esposizione verso l'esterno

Per i soggetti essenziali la misura PR.PS-01 chiede configurazioni di riferimento sicure (hardened), definite e documentate in un elenco aggiornato, almeno per i sistemi rilevanti. Per tutti, PR.IR-01 chiede l'elenco dei sistemi raggiungibili da remoto con le modalità di accesso, e sistemi perimetrali come i firewall configurati in modo adeguato.

Sul cloud il perimetro sono security group, regole firewall delle reti virtuali, endpoint pubblici e permessi sui bucket: basta un errore di configurazione per aprire un sistema a internet. Gli errori più frequenti sono raccolti in errori di configurazione cloud.

4. Log e monitoraggio

PR.PS-04 chiede di registrare tutti gli accessi da remoto e quelli con utenze privilegiate, di conservare in modo sicuro e possibilmente centralizzato i log necessari al monitoraggio, almeno per i sistemi rilevanti, e di definire per iscritto per quanto tempo. DE.CM-01 chiede strumenti tecnici per rilevare tempestivamente gli incidenti significativi.

Qui le impostazioni predefinite dei provider contano, perché non coincidono con quello che serve:

• su AWS, la Event history di CloudTrail mostra gli ultimi 90 giorni di eventi di gestione per region; per conservarli più a lungo si configura un trail o un archivio di CloudTrail Lake;
• su Azure, l'Activity Log conserva gli eventi per 90 giorni e poi li cancella; per tenerli oltre serve una diagnostic setting che li invii altrove;
• su Google Cloud, i Data Access audit logs sono disattivati per impostazione predefinita, BigQuery escluso, e vanno attivati esplicitamente.

La durata la stabilisce la tua valutazione del rischio, non il default del provider. E per DE.CM-01 servono regole di rilevamento e qualcuno che risponda, non solo log conservati.

5. Vulnerabilità e aggiornamenti

ID.RA-08 chiede un piano di gestione delle vulnerabilità approvato dagli organi di amministrazione e direttivi; PR.PS-02 chiede di installare senza ingiustificato ritardo gli aggiornamenti di sicurezza. Per i soggetti essenziali ID.RA-01 aggiunge vulnerability assessment e/o penetration test periodici sui sistemi rilevanti, anche prima della messa in esercizio, documentati in relazioni.

Sul cloud chi aggiorna dipende dal servizio: nell'esempio di AWS, su EC2 le patch del sistema operativo sono del cliente, su servizi astratti come S3 o DynamoDB sistema operativo e piattaforma li gestisce AWS.

6. Backup e ripristino

PR.DS-11 chiede backup periodici dei dati e delle configurazioni e, almeno per i sistemi rilevanti, copie offline. Per gli essenziali i backup vanno anche cifrati o protetti fisicamente, e va verificato periodicamente che si possano usare, con test di ripristino.

Sul cloud si trascurano due punti: le configurazioni (account, reti, ruoli) fanno parte del backup richiesto, e una snapshot che vive nello stesso account, cancellabile con le stesse credenziali dell'ambiente che dovrebbe ripristinare, nella nostra lettura difficilmente può valere come copia offline.

Il provider come fornitore: la catena di approvvigionamento

L'articolo 24 mette la sicurezza della catena di approvvigionamento fra le misure obbligatorie, tenendo conto delle vulnerabilità di ogni fornitore diretto e delle sue pratiche di sicurezza. Le misure ACN trattano il cloud provider come gli altri fornitori:

• GV.SC-04: inventario aggiornato dei fornitori con potenziali impatti sulla sicurezza, con il referente e il tipo di fornitura;
• GV.SC-07: valutazione documentata del rischio della fornitura, che considera almeno l'accesso del fornitore ai sistemi, l'accesso a dati e proprietà intellettuale, l'impatto di una grave interruzione, tempi e costi di ripristino, il ruolo del fornitore nel governo dei sistemi;
• GV.SC-05: requisiti di sicurezza inseriti in contratti e accordi, fatte salve motivate e documentate ragioni normative o tecniche.

Con un hyperscaler il contratto è standard: Google scrive nella sua pagina NIS2 che, per la natura uno-a-molti dei servizi, offre la stessa sicurezza a tutti i clienti e pubblica la documentazione perché ciascuno la valuti nei propri requisiti di acquisto. La FAQ ACN MSB.16 aiuta a leggere il margine: nei contratti non vanno inseriti per forza tutti i requisiti delle misure di base, basta recepirne il contenuto sostanziale in base alla valutazione del rischio della fornitura. In pratica si confrontano impegni contrattuali e report di audit del provider (Google indica ISO/IEC 27001, SOC 2 e SOC 3) con i requisiti che ti servono, e si documenta il risultato. Il metodo generale è quello della gestione del rischio dei fornitori (TPRM).

Incidente nel cloud: chi notifica al CSIRT Italia

ACN ha risposto nelle FAQ su misure di sicurezza e notifica degli incidenti. Se un incidente significativo colpisce i sistemi di un soggetto NIS cliente a cui un soggetto NIS fornitore eroga servizi cloud, l'obbligo di notifica è di entrambi. L'eccezione: se il servizio è IaaS o hosting dell'infrastruttura del cliente, notifica solo il cliente (FAQ ISB.F.3).

La stessa FAQ chiede al cliente di assicurarsi, fra i requisiti della fornitura (GV.SC-01), che il fornitore segnali tempestivamente gli eventi di sicurezza che hanno impatto sui suoi servizi. Su IaaS, quindi, un incidente significativo sui tuoi sistemi lo notifichi tu, e solo tu. Tempi e contenuti delle notifiche sono in NIS2: notifica degli incidenti.

Le scadenze, oggi

Il termine per adottare le misure di base è di diciotto mesi dalla comunicazione di inserimento nell'elenco dei soggetti NIS (Determinazione 379907/2025, articolo 3). Per chi è in elenco dal 2025 ACN indica ottobre 2026. Per chi è entrato nel 2026 la Determinazione 127434/2026 fissa il termine al 31 luglio 2027.

E non sono la versione definitiva: il 18 settembre 2026 ACN ha avviato la consultazione delle misure di sicurezza rafforzate, con l'obiettivo di integrare e sostituire quelle di base. Conviene costruire evidenze che si aggiornano, non un dossier chiuso.

Come tenere le misure vive su più cloud

Sul cloud la parte difficile è dimostrare nel tempo che la configurazione rispetta la politica, perché l'ambiente cambia a ogni rilascio. Servono un solo inventario per tutti i cloud, letto dalle API dei provider; un controllo continuo delle configurazioni contro una baseline scritta, con i problemi in ordine di rischio; log centralizzati con qualcuno che li guarda. Gli strumenti nativi di ciascun provider coprono il proprio cloud; con più provider serve una vista unica.

Per la vista unica AmagisTech lavora con Wiz, di cui è partner. Wiz si collega via API, senza agenti, agli account AWS, Azure, Google Cloud e Oracle, e mette in relazione configurazioni, identità, vulnerabilità ed esposizione per ordinare i rischi. Dall'11 marzo 2026 fa parte di Google Cloud, con marchio e supporto multicloud confermati da Google. Uno strumento non rende conformi: politiche, approvazioni del vertice e priorità restano decisioni dell'azienda. Rende però verificabile, ogni giorno, lo stato delle misure tecniche.

In sintesi

Il provider risponde della sua infrastruttura ed è a sua volta un soggetto NIS2. Tu rispondi di inventario, identità, configurazioni, log, vulnerabilità e backup dei tuoi ambienti, e tratti il provider come un fornitore critico. Su IaaS la notifica degli incidenti è solo tua.

Se vuoi sapere com'è messo oggi il tuo cloud su queste misure, partiamo da una fotografia del cloud con Wiz: una call di 20 minuti, poi il collegamento via API ai tuoi account e la lista di cosa è esposto, in ordine di priorità.