Modello di responsabilità condivisa nel cloud: chi fa cosa

La risposta breve: il modello di responsabilità condivisa (shared responsibility model) è la divisione dei compiti di sicurezza tra il provider cloud e il cliente. Il provider risponde dell'infrastruttura su cui girano i servizi: datacenter, rete fisica, server, virtualizzazione. Il cliente risponde di ciò che ci mette dentro e di come lo configura: dati, identità, accessi, configurazioni. Il confine si sposta a seconda del servizio (IaaS, PaaS, SaaS), ma dati e identità restano sempre al cliente, e con loro gli obblighi normativi.

Cosa dice il modello, in pratica

AWS lo riassume con due formule diventate standard: security of the cloud, la sicurezza del cloud, che spetta al provider, e security in the cloud, la sicurezza nel cloud, che spetta al cliente. Nella pagina dedicata al modello, AWS scrive di essere responsabile dell'infrastruttura che fa girare tutti i servizi offerti nel suo cloud, e che la responsabilità del cliente dipende dai servizi che sceglie.

Microsoft e Google descrivono la stessa divisione con parole diverse. La documentazione di Azure dice che, in qualunque modello di servizio, dati e identità sono del cliente, e che è il cliente a doverne garantire la sicurezza insieme ai componenti cloud che controlla. Google, nel suo Well-Architected Framework, precisa che il provider resta sempre responsabile della rete e dell'infrastruttura sottostanti, e il cliente resta sempre responsabile delle proprie policy di accesso e dei propri dati.

Microsoft precisa che la sua pagina usa la parola responsabilità in senso di governance (chi configura, gestisce e monitora ciascun controllo) e non trae conclusioni legali. Il modello è una mappa operativa: chi risponde davanti a un'autorità lo dicono norme e contratti.

Come cambia la divisione tra IaaS, PaaS e SaaS

Più il servizio è gestito, più compiti passano al provider. Non passano mai tutti.

IaaS: macchine virtuali, storage, reti

Qui il cliente ha il carico maggiore. Per chi usa istanze EC2, AWS indica come responsabilità del cliente la gestione del sistema operativo guest, compresi aggiornamenti e patch di sicurezza, il software installato sulle istanze e la configurazione del firewall fornito da AWS. Google dice lo stesso in sintesi: in IaaS la maggior parte delle responsabilità di sicurezza è del cliente, mentre quelle del provider si concentrano sull'infrastruttura e sulla sicurezza fisica.

PaaS: database gestiti, container gestiti, funzioni

Il provider prende in carico sistema operativo e runtime. Nella matrice di Microsoft, in PaaS il sistema operativo è del provider, mentre applicazioni e controlli di rete diventano responsabilità condivise. Google scrive che in PaaS il cliente condivide con il provider i controlli a livello applicativo e la gestione dell'IAM, e resta responsabile della sicurezza dei propri dati.

Per servizi come S3 o DynamoDB, AWS lascia al cliente la gestione dei dati (comprese le scelte di cifratura), la classificazione degli asset e i permessi IAM.

SaaS: applicazioni pronte

Qui il provider ha il grosso delle responsabilità, ma non tutte. Google lo scrive per Google Workspace e per le altre applicazioni SaaS: il cliente resta responsabile dei controlli di accesso e dei dati che sceglie di conservare nell'applicazione. Nella matrice di Microsoft, anche per Microsoft 365 restano al cliente dati, configurazioni e impostazioni, identità e utenti, mentre applicazioni e dispositivi client diventano responsabilità condivise.

Cosa resta sempre al cliente

Mettendo insieme le tre documentazioni, c'è un nucleo che non si trasferisce mai, in nessun modello di servizio. Microsoft lo elenca in modo esplicito:

• Dati: classificazione, misure di tutela, decisioni sulla cifratura, rispetto dei requisiti di governance.
• Endpoint: i dispositivi da cui si accede ai servizi cloud, portatili e telefoni compresi.
• Account: creazione, gestione e rimozione degli accessi degli utenti.
• Gestione degli accessi: ruoli, autenticazione a più fattori, policy di accesso condizionale.

A questo elenco la matrice di Microsoft aggiunge una riga che conta più delle altre: configurazioni e impostazioni sono del cliente in tutti i modelli, dall'on-premises al SaaS. Il provider mette a disposizione le opzioni, la scelta di come impostarle resta a chi usa il servizio.

Controlli condivisi e controlli ereditati

Tra i due estremi ci sono controlli che esistono su entrambi i lati, ciascuno per la sua parte. AWS ne indica tre:

• Patch management: AWS aggiorna l'infrastruttura, il cliente aggiorna sistemi operativi guest e applicazioni.
• Configuration management: AWS configura i propri dispositivi, il cliente configura sistemi operativi, database e applicazioni.
• Formazione: AWS forma i suoi dipendenti, il cliente forma i propri.

Poi ci sono i controlli ereditati, come quelli fisici e ambientali dei datacenter, che il cliente riceve per intero dal provider. Google spiega che controlli ereditati come la cifratura predefinita e i controlli sull'infrastruttura si possono presentare ad auditor e regolatori come parte delle evidenze della propria postura di sicurezza. È il punto in cui entrano le certificazioni del provider (ISO/IEC 27001, report SOC 2, CSA STAR): coprono la parte del provider, non quella del cliente.

Dove il modello viene letto male

Nella scheda Mitigating Cloud Vulnerabilities del gennaio 2020, la NSA indica l'errore di configurazione come la vulnerabilità cloud più diffusa e lo fa risalire spesso a errori nelle policy dei servizi cloud o a un malinteso sulla responsabilità condivisa. Nella stessa scheda ricorda che molti provider offrono strumenti di configurazione e di monitoraggio, ma che configurare il servizio secondo i requisiti dell'organizzazione resta compito del cliente. Google, nello stesso documento in cui descrive il modello, scrive che molte violazioni nel cloud sono la conseguenza diretta di un errore di configurazione.

Google segnala anche un'area spesso trascurata, la gestione degli incidenti: molti richiedono la collaborazione del provider per essere indagati, e il confine tra le due parti lì non è facile da tracciare. Va deciso prima, non durante.

I malintesi più frequenti sono quattro.

1. Con il SaaS se ne occupa il fornitore

Il provider gestisce l'applicazione, ma utenti, permessi, condivisioni e impostazioni del tenant restano del cliente. Un account amministrativo senza MFA su Microsoft 365 o su Google Workspace è un problema del cliente, non del provider.

2. Il provider è certificato, quindi lo sono anch'io

La certificazione del provider copre i controlli del provider. Le configurazioni, gli accessi e i dati del cliente non sono nel perimetro di quell'audit. Si ereditano evidenze, non la conformità.

3. Il provider ha gli strumenti, quindi la configurazione è a posto

Gli strumenti ci sono, ma vanno attivati, impostati e letti. È la distinzione della NSA tra strumenti offerti dal provider e configurazione che resta al cliente. Quali sono gli errori che si ripetono lo abbiamo raccolto in errori di configurazione cloud: quali sono e come trovarli.

4. Una matrice vale per tutto il cloud

La divisione cambia servizio per servizio. Google porta l'esempio di un'azienda che migra un'applicazione on-premises su Compute Engine, usa Google Workspace per la posta e BigQuery per l'analisi dei dati: tre modelli diversi nello stesso ambiente, con controlli che si sovrappongono. Con più provider le matrici si moltiplicano.

La responsabilità normativa non si delega

Il modello divide i compiti operativi. Gli obblighi di legge restano a chi usa il cloud, e le norme lo scrivono in chiaro.

• DORA. Il Regolamento (UE) 2022/2554, all'art. 28 par. 1 lett. a, stabilisce che le entità finanziarie che usano servizi TIC di terzi "rimangono sempre pienamente responsabili del rispetto e dell’adempimento di tutti gli obblighi previsti dal presente regolamento e dalla normativa applicabile in materia di servizi finanziari". Cosa comporta per contratti e registro dei fornitori lo spieghiamo nella guida completa a DORA.
• NIS2. Il D.Lgs. 138/2024, all'art. 24 comma 2 lett. d, mette tra le misure obbligatorie la "sicurezza della catena di approvvigionamento, ivi compresi gli aspetti relativi alla sicurezza riguardanti i rapporti tra ciascun soggetto e i suoi diretti fornitori o fornitori di servizi". Il comma 3 chiede di tenere conto delle vulnerabilità specifiche di ogni fornitore e delle sue pratiche di sicurezza.
• GDPR. L'art. 28 par. 1 del Regolamento (UE) 2016/679 chiede al titolare di ricorrere solo a responsabili del trattamento che presentino "garanzie sufficienti per mettere in atto misure tecniche e organizzative adeguate". La scelta del provider è una decisione del titolare.
• ISO/IEC 27001:2022. L'Annex A dedica un controllo specifico all'uso dei servizi cloud, il 5.23 (Information security for use of cloud services).

Google aggiunge un caso concreto: se un'azienda ha clienti nell'Unione europea e deve tenere i loro dati nell'UE, spetta all'azienda assicurarsi che i dati restino nelle regioni europee di Google Cloud. Il provider offre le regioni, la scelta e il controllo sono del cliente. Su come valutare un provider prima di firmare, con i criteri di DORA, NIS2 e ACN, c'è la nostra guida su come scegliere un cloud provider.

Responsabilità condivisa e destino condiviso

Google ritiene che il modello di responsabilità condivisa, da solo, non basti ad aiutare i clienti a ottenere risultati di sicurezza migliori, e propone il concetto di shared fate, destino condiviso. In pratica: configurazioni sicure per default, blueprint e codice infrastrutturale già verificato con cui partire, strumenti di governance come Assured Workloads e Security Command Center, e il Risk Protection Program, costruito con due compagnie di assicurazione cyber. Non cambia chi risponde di cosa: riduce la distanza tra quello che il provider offre e quello che il cliente riesce davvero a configurare.

Come metterlo in pratica

1. Fai l'inventario dei servizi, non solo degli account. Per ogni servizio usato annota il modello (IaaS, PaaS, SaaS) e il provider. Il confine si legge a quel livello.
2. Leggi la matrice del provider per quei servizi. AWS, Microsoft e Google pubblicano le loro, e per standard come PCI DSS Google mette a disposizione una matrice di responsabilità dedicata.
3. Scrivi chi fa cosa anche dentro casa. Il lato cliente del modello va assegnato a persone e fornitori con un nome: IT interno, sviluppatori, managed service provider. Un compito del cliente senza titolare non lo fa nessuno.
4. Porta il modello nei contratti e nella gestione dei fornitori. È qui che DORA, NIS2 e GDPR chiedono evidenze. Il metodo per farlo è nella guida al third party risk management.
5. Verifica il tuo lato di continuo. Configurazioni, identità e accessi cambiano a ogni rilascio. Un controllo annuale fotografa un giorno solo.

L'ultimo punto è il lavoro di una CNAPP: leggere via API configurazioni, identità ed esposizione di tutti gli account, su più provider, e dire cosa va sistemato prima. Wiz, di cui AmagisTech è partner, si collega agli account cloud tramite integrazioni API, senza agenti, e mette in relazione errori di configurazione, identità, accessi di rete ed esposizione pubblica per individuare le combinazioni che formano un percorso di attacco reale (Wiz, How to Evaluate Wiz: Common FAQs). È, in sostanza, una verifica continua della parte del modello che spetta al cliente.

In sintesi

Il provider risponde dell'infrastruttura, il cliente di dati, identità, accessi e configurazioni. Il confine si sposta tra IaaS, PaaS e SaaS, ma quel nucleo resta sempre al cliente, insieme agli obblighi di DORA, NIS2 e GDPR. Servono una matrice per servizio, un titolare per ogni compito e un controllo continuo della propria parte.

Se vuoi vedere com'è messo oggi il tuo lato del modello, 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.