Modello di Responsabilità Condivisa: Cloud Security e compliance NIS2/DORA
L’adozione del cloud ridefinisce i confini del rischio. Il Modello di Responsabilità Condivisa (Shared Responsibility Model – SRM) nasce per eliminare ogni ambiguità sulla sicurezza, tracciando una linea netta tra i doveri del fornitore e quelli del cliente.
Il Modello di Responsabilità Condivisa è un documento tecnico che delinea la strategia di gestione del rischio aziendale. I principali vantaggi sono:
- Riduzione del carico operativo: delegando al fornitore la manutenzione dell’infrastruttura fisica, i team interni possono concentrarsi su attività ad alto valore, come la protezione dei dati sensibili e del codice proprietario.
- Prevenzione delle violazioni: molte violazioni dei dati avvengono perché le organizzazioni presumono erroneamente che il fornitore si occupi di aspetti che spettano a loro, come la configurazione dei firewall o dei permessi. Il SRM assicura che non esistano “punti ciechi” nella difesa.
- La Responsabilità non è delegabile: sebbene le operazioni IT possano essere esternalizzate, l’azienda rimane l’unica responsabile legale e normativa per la sicurezza dei dati e la continuità del servizio (specialmente sotto NIS2 e DORA).
In questa “partnership di sicurezza”, se una delle due parti non adempie ai propri doveri, l’intero sistema diventa vulnerabile. La conformità non si eredita passivamente dal provider, ma deve essere costruita attivamente “nel” cloud.
> Scopri la formazione su Cloud Platform Administration
Sicurezza “del” Cloud vs Sicurezza “nel” Cloud
Per garantire una copertura totale, il modello separa la protezione dell’infrastruttura dalla protezione dei carichi di lavoro:
Sicurezza “del” Cloud – la responsabilità del Provider
Il fornitore (AWS, Azure o Google Cloud) protegge l’infrastruttura globale che esegue i servizi. Questo include la sicurezza fisica dei data center, l’hardware, le reti e il livello di virtualizzazione (hypervisor). L’obiettivo è garantire una struttura resiliente e protetta da guasti o intrusioni fisiche.
Sicurezza “nel” Cloud – la responsabilità del Cliente
Il cliente è l’unico responsabile di tutto ciò che inserisce e configura nell’ambiente cloud. Questo perimetro include la gestione delle identità (IAM), la crittografia dei dati, la configurazione dei sistemi operativi e la protezione del codice applicativo.
> Leggi anche: “Identity & Access Management: panoramica e strumenti open source”
Responsabilità Cloud: IaaS, PaaS e SaaS a Confronto
Il confine tra la sicurezza “del” cloud (provider) e “nel” cloud (cliente) si sposta significativamente a seconda del modello di servizio adottato e influenza direttamente il carico operativo e i costi di gestione della sicurezza.
Più il servizio è gestito dal provider, meno responsabilità operative ricadono sul cliente, ma la protezione di dati e identità rimane sempre un compito esclusivo del cliente.
| Componente | IaaS (es. EC2, Azure VM) | PaaS (es. AWS Lambda, App Engine) | SaaS (es. Microsoft 365, Salesforce) |
| Infrastruttura Fisica e Rete | Provider | Provider | Provider |
| Virtualizzazione (Hypervisor) | Provider | Provider | Provider |
| Sistema Operativo (Patching) | Cliente | Provider | Provider |
| Middleware e Runtime | Cliente | Provider | Provider |
| Codice e Applicazioni | Cliente | Cliente | Provider |
| Identità e Accessi (IAM) | Cliente | Cliente | Cliente |
| Dati e Endpoint | Cliente | Cliente | Cliente |
IaaS (Infrastructure as a Service)
In questo modello, il provider fornisce solo “l’hardware virtuale”. È lo scenario più simile alla gestione di un data center on-premise, ma senza l’onere dell’edificio fisico.
- Cosa fa il Provider: si limita alla sicurezza fisica, alla rete di base e all’hypervisor.
- Cosa deve fare il Cliente: è responsabile di quasi tutto lo stack software. Installa, configura e aggiorna il sistema operativo, inclusi i patch di sicurezza e gestisce il middleware e configurare i firewall di rete.
- Caso d’uso tipico: migrazione “lift-and-shift” di macchine virtuali legacy.
PaaS (Platform as a Service)
Qui il provider gestisce anche il sistema operativo e l’ambiente di esecuzione, permettendo al team IT di concentrarsi solo sul valore aggiunto.
- Cosa fa il Provider: si occupa di aggiornamenti e patch del sistema operativo, del middleware e del runtime necessario per far girare le app.
- Cosa deve fare il Cliente: si occupa esclusivamente dello sviluppo sicuro delle proprie applicazioni e dei dati che esse trattano. Non si deve preoccupare di aggiornare Windows o Linux, ma si deve assicurare che il codice sia privo di vulnerabilità.
SaaS (Software as a Service)
In questo modello, il provider gestisce l’intero stack tecnologico e il cliente utilizza il software “così com’è”.
- Cosa fa il Provider: gestisce tutto, dall’infrastruttura fisica all’applicazione finale.
- Cosa deve fare il Cliente: rimane responsabile della gestione degli accessi (chi può entrare), delle impostazioni di sicurezza dell’applicazione e della protezione degli endpoint (i dispositivi usati per accedere).
Analisi Comparativa: AWS vs Azure vs Google Cloud
Sebbene tutti i principali provider seguano il principio fondamentale per cui il fornitore protegge l’infrastruttura e il cliente protegge i carichi di lavoro, esistono sfumature e fondamentali che chi prende le decisioni deve conoscere per gestire un ambiente multi-cloud.
Amazon Web Services (AWS)
Il modello di AWS è il punto di riferimento per la sua natura esplicita e la distinzione netta tra “dentro” e “fuori”.
- Sicurezza “del” Cloud: AWS si occupa dell’infrastruttura fisica, dei data center, delle reti globali e dell’hardware, garantendo che “l’edificio” sia sicuro.
- Sicurezza “nel” Cloud: il cliente è responsabile di tutto ciò che inserisce nell’ambiente. Per servizi IaaS come EC2, questo include il sistema operativo guest, il firewall e il patching.
- Vantaggio: la documentazione estensiva di AWS delinea confini molto netti, facilitando l’identificazione delle responsabilità durante gli audit e gli esami di compliance.
Microsoft Azure: focus su identità e dati
Azure struttura il suo modello attorno alla gerarchia dei servizi, ma pone un’enfasi sulla protezione dell’asset più critico: l’identità.
- Responsabilità costanti: indipendentemente dal modello (IaaS, PaaS o anche SaaS), Azure sottolinea che il cliente è sempre responsabile dei propri dati, degli endpoint (dispositivi), degli account e della gestione degli accessi.
- Aree condivise: Azure definisce esplicitamente alcune zone come “condivise”, specialmente nei modelli PaaS, dove controlli di rete e sicurezza applicativa possono ricadere su entrambi a seconda della configurazione.
- Strumenti integrati: il punto di forza è l’integrazione di tool come Microsoft Defender for Cloud, che aiutano il cliente a capire attivamente quali configurazioni di sicurezza sono di sua competenza.
Google Cloud Platform (GCP): sicurezza di default e “Shared Fate”
Google adotta un approccio proattivo, puntando sull’automazione e su una nuova filosofia di partnership.
- Sicurezza Predefinita: GCP tende ad avere configurazioni predefinite più restrittive; ad esempio, gestisce la crittografia dei dati a riposo per impostazione predefinita su quasi tutti i servizi, riducendo il rischio di errore umano.
- Shared Fate (Destino Condiviso): Superando la divisione netta, Google introduce il concetto di “Shared Fate”. Invece di limitarsi a indicare i problemi del cliente, Google fornisce strumenti e garanzie attive per aiutarlo a configurare l’ambiente in modo sicuro, creando una vera partnership sulla sicurezza.
- Complessità Tecnica: Ogni servizio ha un profilo di configurazione diverso, il che richiede una conoscenza specifica approfondita per determinare la postura ottimale.
Nonostante l’automazione di Google o i tool di Azure, la responsabilità per dati e identità non può mai essere esternalizzata.
Le “Zone Grigie” del Cloud: dove si nascondono i rischi di sicurezza
Le “zone grigie” del Modello di Responsabilità Condivisa sono i punti in cui la divisione dei compiti tra fornitore e cliente non è netta. Spesso è proprio in questi spazi di ambiguità che si verificano le violazioni, poiché entrambe le parti potrebbero presumere che l’altra se ne stia occupando. Senza un modello chiaro, si creano “punti ciechi” nella difesa.
I “Controlli Condivisi”
Esistono aree in cui la responsabilità richiede una collaborazione attiva. Se non coordinata, questa zona diventa un punto di fallimento critico:
- Gestione delle Patch: il provider aggiorna l’infrastruttura fisica, ma in IaaS il cliente deve patchare il sistema operativo “guest” e le applicazioni. La confusione su quale livello di patching spetti a chi è una causa comune di vulnerabilità.
- Configurazione e Infrastructure as Code (IaC): il provider mantiene la configurazione dell’hardware, ma il cliente deve configurare correttamente database e workload. L’errore umano nella definizione delle regole IaC rimane frequente.
- Logging e Monitoraggio: il provider garantisce che gli strumenti (come CloudTrail o Azure Monitor) funzionino, ma non li configura per chi li usa. Molti incidenti rimangono invisibili perché il cliente presume erroneamente che il monitoraggio sia attivo di default.
> Leggi anche: “Infrastructure-as-code: automazione, coerenza e scalabilità”
L’illusione del “No Ops” nel Serverless e PaaS
Man mano che ci si sposta verso servizi gestiti (PaaS e Serverless), la linea di demarcazione diventa meno visibile.
- L’errore del Serverless: i clienti spesso pensano che “nessuna operazione” (No Ops) significhi “nessuna sicurezza”.
- Cosa resta al cliente: anche nel serverless, rimani responsabile della sicurezza del codice, della gestione dei segreti (password, chiavi API) e delle dipendenze delle librerie. Devi proteggere l’applicazione mentre è in esecuzione configurando i controlli di accesso a livello applicativo.
Responsabilità Condivisa per l’IA
L’adozione dell’Intelligenza Artificiale introduce zone grigie non coperte dai modelli tradizionali.
- Responsabilità del Provider: protegge l’infrastruttura e l’hosting del modello.
- Responsabilità del Cliente: sicurezza dei prompt, prevenzione di prompt injection e gestione etica e normativa dei dati inseriti nel modello.
Errori di configurazione del cloud
Gli errori di configurazione sono la causa principale della maggior parte delle violazioni nel cloud. Questi ricadono quasi interamente sotto la responsabilità del cliente (“sicurezza nel cloud”)
- Storage pubblico non protetto: lasciare bucket S3 o Azure Blobs accessibili a chiunque. Spesso accade per un’errata comprensione dei permessi “autenticati” vs “pubblici”.
- IAM permissivo e mancanza di MFA: assegnare privilegi eccessivi (violando il least privilege) e non attivare l’autenticazione a più fattori per gli account privilegiati.
- Configurazioni di rete insicure: permettere traffico in uscita illimitato o lasciare porte di gestione (SSH/RDP) aperte a tutto il mondo.
- Gestione delle chiavi API: lasciare chiavi hardcodate nel codice o caricarle accidentalmente su repository pubblici.
- Utilizzo di impostazioni di default: mantenere password predefinite o servizi non necessari attivi, aumentando la superficie di attacco.
La zona grigia più grande è psicologica: l’assunzione errata che “se è nel cloud, è sicuro” porta a trascurare configurazioni critiche come la crittografia (spesso disponibile ma non attiva di default).
Compliance: l’impatto di NIS2 e DORA sul Modello SRM
Il Modello di Responsabilità Condivisa (SRM) è anche il fondamento contrattuale e operativo su cui si basa la conformità alle direttive europee NIS2 e DORA. Poiché queste normative richiedono una gestione rigorosa dei rischi ICT e la garanzia della resilienza operativa, il modello SRM diventa lo strumento essenziale per mappare esattamente chi deve implementare ogni singolo controllo di sicurezza.
> Leggi anche: “NIS 2: per chi è obbligatoria e quali sono i requisiti per le aziende”
Il principio della “Non-Delegabilità” della responsabilità legale
Un concetto che ogni CISO deve prendere in considerazione è che, sebbene sia possibile esternalizzare le operazioni IT a un provider cloud, l’azienda, ovvero il cliente, rimane l’unico responsabile legale e normativo per la sicurezza dei dati e la continuità del servizio.
Molte aziende ritengono erroneamente che l’uso di un provider certificato (come AWS o Azure) le renda automaticamente conformi. In realtà, le certificazioni del provider (SOC 2, ISO 27001) coprono esclusivamente la “sicurezza del cloud” (infrastruttura), ma non dimostrano la protezione dei dati o la corretta configurazione degli accessi, che restano a carico del cliente.
Sotto DORA, gli organi di gestione sono chiamati a rispondere direttamente della gestione del rischio ICT. Il modello SRM serve a delimitare i controlli sotto il controllo diretto dell’azienda rispetto a quelli affidati a terzi, permettendo una visione chiara del rischio residuo.
Gestione del Rischio della Supply Chain (Terze Parti)
DORA pone un’enfasi massiccia sulla gestione del rischio derivante dai fornitori terzi di servizi ICT (Cloud Service Providers). Il modello SRM è lo strumento pratico per gestire questo requisito:
- Mappatura dei controlli: per la compliance, le aziende devono sapere quali controlli sono gestiti dal fornitore (es. patching dell’hypervisor) e monitorarli tramite le attestazioni del fornitore stesso.
- Gap Analysis: il modello aiuta a identificare falle di sicurezza. Se il provider gestisce l’infrastruttura ma non il patching del sistema operativo (come in IaaS) e il cliente trascura questo aspetto, si crea una violazione immediata della conformità.
Incident Response: chi interviene in caso di attacco?
NIS2 e DORA impongono tempi strettissimi per la segnalazione degli incidenti e piani di continuità robusti. In questo contesto, il modello SRM determina i protocolli di reazione:
- Delineazione dei ruoli: in caso di attacco DDoS all’infrastruttura, la risposta spetta al provider. Se l’incidente riguarda una compromissione di credenziali o un bucket S3 esposto, la responsabilità dell’intervento è esclusivamente del cliente.
- Disaster Recovery: mentre il provider garantisce la disponibilità fisica dei server, è responsabilità del cliente configurare backup, disaster recovery e replicazione dei dati tra regioni diverse. Ignorare questa parte del modello SRM comporta il fallimento dei requisiti di resilienza di DORA.
> Scopri il corso sull’Incident Response
Audit e monitoraggio continuo tramite CSPM
Le normative moderne segnano il passaggio da audit periodici a un monitoraggio continuo della postura di sicurezza.
In questo contesto, gli strumenti di Cloud Security Posture Management (CSPM) sono essenziali perché mappano automaticamente le configurazioni del cliente direttamente sui controlli richiesti da DORA, NIS2 o GDPR. Questi tool forniscono report in tempo reale che dimostrano agli auditor che la parte di responsabilità spettante al cliente è gestita attivamente.
Nel quadro di NIS2 e DORA, mentre il cloud provider garantisce la resilienza e la protezione dell’infrastruttura fisica e logica sottostante , la normativa sanziona il cliente per le vulnerabilità derivanti da una gestione impropria delle configurazioni di sicurezza o degli accessi ai dati.
