La responsabilità condivisa nel cloud deve essere tradotta in attività assegnate, non soltanto in una figura con due colonne. Un provider può proteggere l’infrastruttura sottostante mentre il cliente resta responsabile di autorizzazioni, configurazioni e uso del servizio. Il confine dipende dalla prestazione concreta e cambia tra servizi diversi.
Il risultato di questa guida è una matrice dei controlli: chi esegue l’attività, chi ne verifica l’esito, quale prova è disponibile e quali passaggi restano senza titolare. Il modello di responsabilità condivisa AWS costituisce un esempio documentato. Non va esteso automaticamente a tutti i provider o a ogni servizio AWS. Fonti consultate il 27 settembre 2026.
Scegliere un servizio e un obiettivo operativo
Partire da una prestazione definita, per esempio una base dati gestita usata dall’applicazione ordini. Identificare ambiente, regione, account, dati, utenti e dipendenze. La matrice diventa poco utile se mescola servizi con modelli di amministrazione differenti sotto la sola etichetta «cloud».
Descrivere poi l’obiettivo: impedire accessi non autorizzati, ripristinare dati, mantenere aggiornato un componente oppure rilevare un’attività anomala. Lo stesso obiettivo può richiedere più attività distribuite tra cliente e provider. La presenza di una funzione nel servizio non dimostra che il cliente l’abbia attivata o configurata correttamente.
La mappatura dei sistemi e dei flussi aiuta a identificare il perimetro. Registrare la versione della descrizione del servizio consultata e la data, così da poter rivedere il confine quando il prodotto o l’architettura cambiano.
Compilare la matrice per attività
| Obiettivo | Attività del provider da verificare | Attività del cliente | Prova del cliente |
|---|---|---|---|
| Limitare gli accessi | Meccanismi disponibili nel servizio | Definire ruoli e autorizzazioni | Configurazione e revisione dei diritti |
| Proteggere i dati | Funzioni di cifratura offerte | Scegliere impostazioni e gestione delle chiavi | Impostazioni e decisione sulle chiavi |
| Ripristinare | Capacità documentate di backup | Configurare, controllare e provare il recupero | Risultato della prova sul servizio |
| Rilevare anomalie | Eventi e interfacce disponibili | Abilitare raccolta, allarmi e risposta | Tracce ricevute e caso gestito |
| Gestire modifiche | Aggiornamenti di propria competenza | Valutare impatti e configurazioni | Analisi del cambiamento e verifica |
Questa tabella contiene domande di lavoro, non un’assegnazione universale. Sostituire ogni formulazione generale con il servizio effettivo. Se la documentazione non chiarisce un punto, registrare un’informazione mancante e assegnare la richiesta di chiarimento.
Scomporre il risultato in attività: capacità offerta dal provider, impostazione scelta dal cliente, identità autorizzate, monitoraggio dell’errore e prova del recupero. Alcune attività possono dipendere da un integratore. Per ciascuna riga annotare il riferimento alla documentazione del servizio consultata, la configurazione dell’ambiente e l’ultima verifica. Il modello AWS di responsabilità condivisa mostra che la ripartizione cambia con il servizio scelto; la matrice aziendale deve quindi essere aggiornata per il prodotto e per l’uso concreto.
Quando una funzione è disponibile ma non abilitata, evitare di registrarla come controllo già operante. Quando è abilitata, verificare chi riceve un eventuale errore e con quali permessi può correggerlo. Se la documentazione del provider non chiarisce un limite, attribuire a un referente interno la richiesta di spiegazione e una misura temporanea proporzionata. La riga diventa chiusa soltanto quando attività, responsabilità e prova descrivono lo stesso risultato.
Separare chi esegue da chi risponde del risultato
Il provider può eseguire un backup, mentre il cliente deve verificare che la configurazione risponda al proprio bisogno di continuità. Una società di servizi può amministrare il cloud per conto del cliente, introducendo un terzo soggetto nella matrice. Non eliminare la responsabilità interna soltanto perché l’attività è delegata.
Per ogni riga indicare operatore, responsabile interno, revisore e sostituto. Nelle organizzazioni piccole alcune persone possono cumulare ruoli, ma il significato della decisione deve restare distinto. Chi può modificare una configurazione non è necessariamente autorizzato ad accettare il rischio derivante da una configurazione incompleta.
La politica di sicurezza aziendale stabilisce le deleghe generali. La matrice dimostra come esse funzionano per questo servizio e individua i punti in cui il contratto, la procedura e l’accesso tecnico non coincidono.
Valutare le prove del provider nel loro ambito
La documentazione di AWS Audit Manager distingue raccolta di evidenze, controlli e valutazioni. Anche quando una raccolta è automatizzata, resta necessario capire che cosa dimostra il dato. Una fotografia della configurazione non documenta automaticamente il funzionamento di un processo durante tutto l’anno.
Il perimetro di un audit di sicurezza aiuta a stabilire quali ulteriori verifiche servono. Conservare il riferimento alla prova del provider e la valutazione interna dei suoi limiti, evitando di copiare documenti riservati in archivi accessibili a persone non autorizzate.
Ogni prova sostiene un’affermazione limitata. Un certificato riferito all’organizzazione del provider non prova che una determinata opzione sia stata attivata nell’account del cliente. Uno screenshot può mostrare un’impostazione in un momento preciso, ma non dimostra che sia rimasta attiva per l’intero periodo esaminato. Una prova di ripristino mostra il risultato nell’ambiente e nello scenario testati; non copre automaticamente tutti gli ambienti.
Nella matrice indicare quindi soggetto della prova, servizio, account o ambiente, periodo, metodo e limitazioni. Conservare un riferimento stabile al documento e la valutazione interna, evitando di diffondere copie di rapporti riservati. La documentazione di AWS Audit Manager descrive i concetti di controllo, valutazione ed evidenza; una raccolta automatica rimane da interpretare rispetto alla domanda di verifica.
Usare almeno un riscontro operativo per le attività più importanti: un accesso effettivamente negato secondo la regola, un recupero riuscito, un avviso ricevuto dalla persona designata. Se un test non è possibile senza rischio per la produzione, definire un ambiente rappresentativo e indicare le differenze. La conclusione deve riportare l’ambito provato e quello ancora aperto. Questa precisione rende il fascicolo utile a chi deve decidere, invece di accumulare documenti difficili da collegare ai controlli.
Esempio: database gestito con ripristino incompleto
Un’impresa ipotetica usa un database gestito per gli ordini. Il team ritiene che il provider gestisca «tutta la sicurezza» perché il servizio include backup automatici. La matrice separa la disponibilità della funzione, la configurazione della conservazione, la verifica degli errori e la prova di ripristino dell’applicazione.
Il provider documenta il meccanismo di backup. Il cliente deve ancora definire il periodo utile, controllare che il backup riguardi l’ambiente corretto e verificare il recupero. Un esercizio ripristina i dati, ma l’applicazione non riparte perché manca una configurazione esterna e nessuno dispone delle autorizzazioni necessarie nel nuovo ambiente.
L’esito modifica la matrice: il responsabile applicativo assume la verifica della configurazione, l’amministratore cloud gestisce i diritti e il referente continuità approva il risultato complessivo. Il backup non viene classificato come fallito in ogni suo aspetto; viene registrata la distanza tra recupero dei dati e ripresa del servizio.
La gestione del disaster recovery permette di collegare questa prova al bisogno operativo. La lezione concreta è che un’attività ben eseguita dal provider può non essere sufficiente a ottenere il risultato del cliente.
Individuare i controlli senza titolare
Cercare righe con formule come «gestito dal cloud», «a carico del partner» o «automatico». Chiedere chi riceve un errore, chi può intervenire e chi verifica il risultato. Se le risposte non sono disponibili, la riga contiene una dipendenza non governata.
Assegnare temporaneamente il problema a un responsabile interno, con una decisione sulle misure transitorie. Non lasciare il campo vuoto in attesa di un chiarimento commerciale. La mancanza di chiarezza richiede una gestione esplicita del rischio, non una presunzione favorevole.
Immaginare, come esercizio ipotetico, che una regola di monitoraggio smetta di ricevere eventi. Il provider continua a produrre i log del servizio, l’integratore gestisce il collegamento e il cliente consulta il cruscotto. Ciascuno può dichiarare di aver svolto la propria parte mentre l’allarme finale non funziona. La matrice deve rappresentare anche l’interfaccia tra le parti, con una persona che controlla l’arrivo degli eventi e apre il caso di errore.
Definire il primo segnale osservabile e l’ordine delle verifiche. Il team controlla se il servizio ha emesso l’evento, se l’integrazione lo ha trasferito e se il sistema di destinazione lo ha interpretato. Annota tempi, fonti e limiti dei log. Se non si può stabilire da quando il flusso è assente, non si deve dichiarare che il controllo ha operato senza interruzioni. Occorre valutare il periodo di visibilità mancante e scegliere una misura temporanea.
La ripartenza tecnica non coincide con la chiusura del caso. Dopo aver ripristinato il collegamento, inviare un evento controllato o usare una procedura sicura equivalente per verificare il percorso completo. Il responsabile interno conferma il risultato e aggiorna le istruzioni di gestione. Questa verifica aiuta a distinguere il difetto della configurazione del cliente da un problema del servizio del provider, senza assegnare colpe sulla base del solo contratto.
Coordinare una perturbazione del servizio
Un incidente del provider può essere annunciato per una regione o per un prodotto, mentre il cliente osserva soltanto che una parte della propria applicazione non risponde. Nella matrice indicare chi legge gli avvisi del provider, chi correla l’avviso con i servizi aziendali e chi decide se attivare la continuità. Un referente commerciale non possiede necessariamente i diritti tecnici per raccogliere i dati utili; l’escalation deve raggiungere anche l’operatore del servizio e il responsabile della funzione interessata.
Preparare prima dell’incidente i riferimenti che servono alla richiesta di supporto: identificativo dell’ambiente, servizio, regione, orario osservato e sintomi. Conservare queste informazioni nel canale autorizzato, senza inserire segreti in un ticket generico. Durante l’evento distinguere ciò che il provider conferma da ciò che il cliente osserva. Un avviso di ripristino del provider non dimostra da solo che code, integrazioni e utenti del cliente siano tornati operativi. La prova di chiusura comprende una verifica rappresentativa della funzione e la registrazione dei problemi ancora aperti.
Quando la comunicazione del provider è parziale, la persona interna incaricata può decidere una misura temporanea, per esempio limitare una funzione che genera errori ripetuti o deviare richieste verso il percorso previsto dal piano di continuità. La scelta dipende dall’impatto osservato e dalla propria architettura; non è una misura universale del modello cloud. Dopo l’evento confrontare cronologia del provider, log del cliente e decisioni prese. Se il passaggio di informazioni ha ritardato la risposta, aggiornare la riga di responsabilità che attribuisce l’ascolto degli avvisi e la verifica del risultato.
Gestire i cambiamenti del confine
Rivedere la matrice quando si cambia servizio, modello di gestione, fornitore operativo o architettura. Una migrazione da una macchina virtuale a un servizio gestito può spostare alcune attività, ma crearne altre relative alla configurazione e alle integrazioni. Conservare la versione precedente e la motivazione delle modifiche.
Verificare le dipendenze con identità, rete, chiavi e servizi esterni. Una configurazione sicura all’interno del servizio può essere indebolita da un accesso troppo ampio o da una dipendenza condivisa. Il dossier di approvazione della sicurezza può raccogliere la decisione sul rischio residuo complessivo.
Il passaggio da un servizio gestito a un altro cambia il perimetro delle attività anche quando entrambi sono venduti dallo stesso provider. Prima della migrazione confrontare riga per riga le capacità offerte, le impostazioni da rifare, i log disponibili e il metodo di ripristino. Identificare le dipendenze che restano presso il cliente, come identità, chiavi o rete. Un controllo non deve scomparire dalla matrice solo perché il vecchio prodotto è stato dismesso.
Se cambia l’integratore, verificare gli accessi di amministrazione e il possesso delle istruzioni operative. Il nuovo gestore deve poter eseguire una procedura rappresentativa; il precedente deve perdere gli accessi non più necessari. Annotare il momento del passaggio e il responsabile degli errori durante la transizione. Quando i due gestori lavorano insieme per un periodo limitato, definire il perimetro di entrambi e la data di revisione della sovrapposizione.
Dopo la migrazione, selezionare alcune righe critiche e farle dimostrare dal nuovo operatore. Una dichiarazione di completamento progetto non basta se nessuno sa localizzare le nuove prove o gestire un fallimento. Conservare le differenze rispetto alla vecchia matrice e il motivo della scelta, così il controllo può essere rivalutato quando cambiano prodotto, contratto o bisogno operativo.
Verificare la matrice con un esercizio breve
Selezionare un controllo di accesso, uno di ripristino e uno di monitoraggio. Chiedere agli operatori di mostrare l’ultima esecuzione e di spiegare il comportamento in caso di errore. Confrontare le risposte con contratto, documentazione del servizio e prove disponibili.
Registrare le differenze come azioni, distinguendo chiarimenti documentali da modifiche tecniche. Una matrice aggiornata deve consentire a un collega di capire il confine senza dover interpretare slogan sulla responsabilità condivisa. Il risultato è raggiunto quando ogni attività necessaria ha un titolare, una prova e un percorso di gestione dell’insuccesso.