Sicurezza dei dati nel cloud: rendere concreta la responsabilità condivisa

Un cloud provider gestisce una parte dell'ambiente di sicurezza. Il vostro team deve comunque stabilire quali protezioni configura, se coprono i dati e i servizi in uso e come sa che restano efficaci.

La sicurezza dei dati nel cloud protegge riservatezza, integrità e disponibilità nelle fasi di archiviazione, elaborazione, condivisione e ripristino. Comprende database e object storage, ma anche autorizzazioni applicative, esportazioni da SaaS, identità di servizio, backup e i laptop o i sistemi di automazione in grado di recuperare dati.

Dal punto di vista di un CTO, la responsabilità condivisa diventa utile solo quando produce decisioni ingegneristiche specifiche: chi configura un controllo, chi lo monitora, quali evidenze ne dimostrano il funzionamento e chi interviene quando fallisce. La dichiarazione di sicurezza di un provider non può rispondere a queste domande per il vostro deployment.

Stabilire il perimetro prima di scegliere i controlli

Gli ambienti cloud combinano infrastrutture, piattaforme e applicazioni erogate da remoto. Il cloud pubblico utilizza in genere un'infrastruttura gestita dal provider al servizio di più clienti; il cloud privato è dedicato a un'unica organizzazione. Nessuna delle due etichette determina se i vostri dati siano adeguatamente protetti. Isolamento, percorsi di accesso, titolarità operativa e meccanismi di ripristino contano più dell'etichetta.

Partite da un servizio aziendale e ricostruitene le dipendenze. Identificate account o sottoscrizioni cloud, regioni, servizi, archivi di dati, amministratori e sistemi di deployment. Includete i prodotti SaaS usati da assistenza, amministrazione e sviluppo: un database di produzione può essere rigorosamente controllato mentre la relativa esportazione dei clienti si trova in uno spazio di lavoro ampiamente condiviso.

L'inventario dovrebbe rispondere a queste domande:

• Quali informazioni vengono archiviate o elaborate, e chi è titolare della finalità di business?
• Dove si trovano i record primari, le repliche, i log, le esportazioni, le cache e le copie di backup?
• Quali persone, workload, fornitori e destinatari esterni possono accedervi?
• Quali account, regioni e servizi sono approvati, e come vengono individuati quelli nuovi?
• Quali requisiti di conservazione, cancellazione, disponibilità e contrattuali si applicano?

La scalabilità e l'accessibilità remota del cloud possono migliorare l'operatività, mentre i servizi gestiti possono ridurre la manutenzione dell'infrastruttura. Rendono però anche facile creare risorse e copie più velocemente di quanto i revisori riescano a tenerne traccia. Il costo della sicurezza comprende quindi amministrazione delle identità, monitoraggio, raccolta delle evidenze, test di ripristino e supervisione dei fornitori, non solo la fattura dello storage.

Classificare le informazioni dove si trovano davvero

Utilizzate uno schema di classificazione gestibile e legato ad azioni concrete. Ad esempio, le categorie pubblico, interno, riservato e ad accesso limitato possono determinare regole di condivisione, revisioni degli accessi, logging e conservazione. Definite quale categoria copre identificativi dei clienti, segreti di autenticazione, dati finanziari, codice sorgente e informazioni personali sensibili.

La discovery automatizzata può aiutare a individuare dataset trascurati, ma i risultati vanno convalidati con i titolari dei dati. Uno scanner può non rilevare archivi compressi o campi specifici di un'applicazione, mentre una stringa di test innocua può generare un falso positivo. Registrate le posizioni non scansionate e i limiti del campionamento. Per un flusso di discovery più completo, consultate data discovery e privacy.

Mappare la responsabilità servizio per servizio

Il confine delle responsabilità cambia in base al modello di servizio e all'implementazione del provider. Considerate quanto segue un punto di partenza da confermare con la documentazione del servizio e i contratti, non una ripartizione universale.

Per ogni protezione importante, registrate il contributo del provider, la configurazione a carico del cliente, il responsabile operativo, il revisore e la fonte delle evidenze. Evitate voci come "cifratura: provider". Scrivete invece: "Il provider fornisce la cifratura gestita; il team di piattaforma sceglie la configurazione delle chiavi; la sicurezza verifica le autorizzazioni di decifratura; il responsabile del servizio testa il ripristino."

Includete le identità di servizio e l'automazione del deployment accanto agli utenti umani. Una pipeline che crea risorse, modifica le policy di accesso o recupera segreti fa parte del perimetro di sicurezza. Anche gli operatori dei servizi gestiti e i fornitori di supporto esterni necessitano di responsabilità esplicite, pur quando amministrano l'infrastruttura per vostro conto.

Individuate i punti in cui i passaggi di consegne possono fallire. Se il provider segnala una credenziale compromessa, chi riceve la comunicazione fuori dall'orario di lavoro? Se un database non è disponibile, chi decide se ripristinare, effettuare un failover o attendere? Assegnate un unico responsabile interno a ciascun risultato lato cliente, anche quando il lavoro è svolto da più team.

Valutare le garanzie del provider senza estenderle oltre il dovuto

Esaminate la documentazione di sicurezza del servizio, le comunicazioni sugli incidenti, le modalità di accesso del supporto, i sub-responsabili, il comportamento in caso di cancellazione, le opzioni di ripristino e i log di audit disponibili. Verificate se il livello di account in uso includa effettivamente le funzionalità di cui la vostra architettura ha bisogno.

I documenti di garanzia richiedono una verifica del perimetro. Un report SOC 2 è un report di attestazione, non una certificazione. La certificazione ISO 27001 riguarda un sistema di gestione della sicurezza delle informazioni con un perimetro definito, non la prova che il vostro tenant sia configurato in modo sicuro. Verificate i servizi coperti, il periodo di riferimento, le eccezioni e i controlli a carico del cliente indicati nel report.

Ove pertinente, il catalogo C5 del BSI fornisce criteri di garanzia per il cloud. Distinguete una valutazione di Tipo 1, relativa alla progettazione e all'implementazione in un dato momento, dalla copertura di Tipo 2, relativa al funzionamento in un periodo. Nessuna delle due sostituisce il test dei vostri accessi e flussi di dati.

Tradurre gli obblighi in requisiti tecnici

Determinate la normativa applicabile e gli impegni verso i clienti prima di scegliere una regione o accettare le condizioni del provider. L'applicabilità dipende dalle informazioni, dai ruoli nel trattamento, dal settore, dalle giurisdizioni e dai rapporti di servizio. Il report o il certificato di un provider non dimostra la conformità normativa della vostra organizzazione.

Per i dati personali soggetti al GDPR, l'articolo 32 richiede una sicurezza adeguata al rischio; non è un obbligo generalizzato di cifrare ogni dataset in ogni circostanza. Quando il provider agisce come responsabile del trattamento, valutate i requisiti contrattuali dell'articolo 28. I meccanismi di trasferimento internazionale richiedono una valutazione separata. La sola ubicazione dei dati non dimostra la sovranità né la conformità al GDPR, in particolare quando l'accesso del supporto o i sub-responsabili creano ulteriori percorsi di accesso.

Come raccomandazione pratica, traducete ogni requisito applicabile in un'affermazione verificabile: regioni di trattamento consentite, destinatari approvati, periodi di conservazione, restrizioni di accesso, obiettivi di ripristino o passaggi di consegne per la notifica degli incidenti. Fate confermare l'interpretazione a specialisti legali e privacy, mentre l'ingegneria stabilisce come il requisito verrà attuato e documentato.

Verificare l'accesso effettivo, non solo le autorizzazioni previste

Credenziali sottratte, privilegi eccessivi, condivisioni pubbliche e abusi interni sono vie comuni di esposizione dei dati nel cloud. Un archivio cifrato può comunque divulgare record tramite un account autorizzato o un'applicazione che restituisce i dati del cliente sbagliato.

Federate le identità umane ove possibile, in modo che i processi di ingresso, cambio di ruolo e uscita del personale raggiungano i servizi cloud. Richiedete un'autenticazione forte per gli accessi privilegiati, privilegiate un'MFA resistente al phishing ove supportata e separate il lavoro ordinario dall'amministrazione. Gli accessi di emergenza richiedono credenziali controllate, un uso monitorato e un processo di ripristino testato; non devono diventare un aggiramento permanente.

Per le identità dei workload, preferite credenziali con ambito ristretto e di breve durata, ove supportate. Rivedete le relazioni di fiducia: quale workload può assumere un ruolo, a quali condizioni e in quale ambiente? Eliminate i segreti incorporati da repository e artefatti di deployment e limitate l'accesso al servizio di gestione dei segreti stesso.

Valutate le autorizzazioni effettive considerando policy di identità, policy delle risorse, assunzione di ruoli, appartenenza ai gruppi, link di condivisione e restrizioni a livello di organizzazione. "Sola lettura" può comunque consentire l'estrazione su larga scala di informazioni sensibili. Un ruolo che non può leggere i record ma può modificare l'applicazione o la policy delle chiavi può ottenere l'accesso indirettamente.

Le evidenze delle revisioni degli accessi dovrebbero identificare l'identità, la risorsa, le azioni consentite, la giustificazione di business, chi ha approvato e, ove applicabile, la data di revoca. Testate l'offboarding e la scadenza degli accessi temporanei invece di affidarvi esclusivamente a una procedura scritta.

Esaminare insieme esposizione e comportamento delle applicazioni

Una configurazione errata nasce spesso dalla combinazione di più impostazioni singolarmente plausibili. Per un object storage, la cifratura predefinita non dice chi può leggere gli oggetti né se una policy di condivisione li rende pubblici. Esaminate insieme identità, policy delle risorse, comportamento dell'applicazione e monitoraggio.

Verificate le restrizioni sull'accesso pubblico, il traffico di rete in ingresso, i listener dei database, la fiducia tra account, il comportamento dei link firmati e la condivisione esterna. Gli endpoint privati possono ridurre l'esposizione, ma non correggono privilegi eccessivi né un'applicazione vulnerabile. Separate gli ambienti e limitate l'accesso alla produzione dai sistemi di sviluppo.

Le API cloud richiedono autenticazione e autorizzazione a livello di oggetto e di azione. Un token utente valido non deve consentire a nessuno di recuperare i record di un altro tenant modificando un identificativo. Testate gli endpoint di esportazione, le operazioni amministrative, le query massive e i gestori di upload. I limiti di frequenza possono ridurre gli abusi, ma non sostituiscono l'autorizzazione.

Utilizzate la revisione dell'infrastructure as code e i controlli basati su policy per impedire impostazioni notoriamente non sicure, poi confrontate le regole approvate con la configurazione effettivamente distribuita. Modifiche da console, migrazioni e correzioni d'emergenza possono generare scostamenti. Registrate il motivo delle eccezioni, i controlli compensativi e la loro scadenza. La modellazione delle minacce può aiutare a individuare, prima dell'implementazione, i percorsi che portano da un'interfaccia esposta ai dati sensibili.

Trattare cifratura e accesso alle chiavi come controlli distinti

Proteggete i dati in transito con protocolli moderni autenticati e un'adeguata validazione dei certificati. Esaminate le connessioni interne tra applicazioni oltre agli endpoint pubblici. Per i dati archiviati, stabilite quali servizi, repliche, esportazioni, snapshot e backup siano cifrati e con quali modalità di gestione delle chiavi.

Le chiavi gestite dal provider e quelle gestite dal cliente supportano scelte operative diverse. Scegliete in base al modello di minaccia, ai requisiti contrattuali, alla separazione amministrativa e alle esigenze di ripristino. Una chiave gestita dal cliente non è automaticamente più sicura se lo stesso amministratore senza restrizioni controlla sia l'accesso ai dati sia le autorizzazioni sulle chiavi.

Documentate chi può cifrare, decifrare, amministrare, disabilitare ed eliminare le chiavi. Esaminate le modifiche alle policy delle chiavi e le attività di decifratura insolite. Definite processi di rotazione, revoca, conservazione e ripristino; a seconda del servizio, la rotazione di una chiave non comporta necessariamente la ricifratura di ogni copia esistente.

I servizi KMS e HSM possono supportare la protezione delle chiavi e le operazioni crittografiche, ma non eliminano le responsabilità legate al ciclo di vita. Testate le conseguenze dell'indisponibilità di una chiave prima di applicare un processo di eliminazione o revoca. Un backup protetto è inutilizzabile se la chiave necessaria non può essere recuperata. Consultate cifratura e gestione delle chiavi per le decisioni crittografiche di supporto.

Monitorare l'attività sui dati e preservare la capacità di risposta

Il logging deve coprire le domande a cui chi risponde agli incidenti deve poter rispondere. Gli eventi di audit amministrativi possono mostrare chi ha modificato una policy senza mostrare chi ha scaricato un dataset. Stabilite dove è disponibile il logging degli accessi ai dati, se è attivo e quali eventi o servizi restano esclusi dalla copertura.

Raccogliete gli eventi pertinenti relativi a identità, piano di controllo, accesso ai dati, applicazioni, gestione delle chiavi e condivisione. Conservate identificativi di account e risorse, identità dell'attore, marcature temporali, azioni ed esiti. Proteggete i log da alterazioni e cancellazioni non autorizzate. Evitate di inserire nei log payload sensibili o credenziali riutilizzabili; i dati diagnostici possono diventare un'ulteriore fonte di esposizione.

Date priorità a scenari di rilevamento come:

• Un archivio ad accesso limitato che diventa pubblicamente accessibile.
• Una nuova relazione di fiducia esterna o l'assegnazione di un ruolo privilegiato.
• Esportazioni massive insolite o accessi da parte di un'identità inattiva.
• La disattivazione del logging o la modifica della sua destinazione.
• L'eliminazione di backup o modifiche all'amministrazione delle chiavi.

Definite chi deve rispondere e testate gli alert con un'esercitazione controllata. Una regola che invia notifiche a una casella di posta non presidiata non è un processo di rilevamento efficace. Registrate i fallimenti nella raccolta, i ritardi di acquisizione, le risorse appena create e i limiti del provider, invece di presentare una dashboard come copertura completa.

Durante un incidente, conservate le evidenze pertinenti e coordinate il contenimento tra identità, applicazioni e storage. Revocare un token può non chiudere altre sessioni né interrompere un'esportazione già in corso. Per le violazioni dei dati personali ai sensi del GDPR, i responsabili del trattamento informano i titolari senza ingiustificato ritardo. I titolari notificano la violazione all'autorità di controllo senza ingiustificato ritardo e, ove possibile, entro 72 ore dal momento in cui ne sono venuti a conoscenza, a meno che sia improbabile che la violazione presenti un rischio per i diritti e le libertà delle persone. Le violazioni ad alto rischio richiedono inoltre la comunicazione agli interessati senza ingiustificato ritardo, fatte salve le eccezioni dell'articolo 34. Conservate la motivazione della notifica o della mancata notifica.

Usare gli strumenti di sicurezza per domande definite

Gli strumenti di sicurezza per il cloud sono più utili quando il loro perimetro e lo scopo decisionale sono chiari:

Avviate l'applicazione delle regole DLP con test rappresentativi e la revisione dei titolari dei dati. Una regola che blocca il legittimo lavoro di assistenza può spingere gli utenti verso soluzioni alternative non controllate. Limitate scanner e agenti di monitoraggio agli accessi di cui hanno bisogno; uno strumento di discovery con ampio accesso in lettura diventa esso stesso un componente sensibile.

L'automazione può ridurre i controlli ripetitivi e la raccolta delle evidenze. Non può stabilire che un servizio non supportato sia sicuro né che un'interpretazione giuridica sia corretta. Mantenete esplicita la revisione umana per i risultati rilevanti e le eccezioni.

Dimostrare il ripristino indipendentemente dallo stato dei backup

I backup coprono perdite e danneggiamenti solo se possono essere ripristinati entro i tempi richiesti dal servizio. Stabilite con il responsabile di business gli obiettivi di punto di ripristino per la perdita di dati tollerabile e gli obiettivi di tempo di ripristino per l'interruzione tollerabile.

Distinguete replica, versioning, snapshot e backup. La replica può copiare un danneggiamento o una cancellazione. Gli snapshot possono restare vulnerabili allo stesso amministratore che controlla la produzione. Scegliete copie protette e una separazione amministrativa adeguate al modello di minaccia, compresa la resistenza alla cancellazione ove supportata.

Ripristinate un workload rappresentativo in un ambiente isolato. Verificate la coerenza dei dati, le dipendenze applicative, la configurazione delle identità, la disponibilità delle chiavi e il tempo di ripristino effettivo. Il solo ripristino del database non dimostra che il servizio aziendale funzioni. Registrate i fallimenti e ripetete il test dopo la correzione.

Valutate separatamente il ripristino dei servizi SaaS. Il disaster recovery del provider può ripristinare la piattaforma senza annullare una cancellazione accidentale nel vostro tenant. Determinate la granularità di ripristino disponibile, le finestre di conservazione, le opzioni di esportazione e chi è responsabile di avviare il ripristino. Applicate le regole di classificazione e conservazione anche ai backup.

Esempio pratico: un servizio di esportazione per i clienti

Consideriamo, a titolo illustrativo, un team SaaS che utilizza un database gestito, un object storage per le esportazioni e un worker in background. Supponiamo che le esportazioni contengano dati di contatto riservati dei clienti, che ogni cliente acceda solo alle proprie esportazioni e che gli obiettivi di ripristino concordati siano quattro ore di perdita di dati e otto ore di interruzione. Si tratta di ipotesi di esempio, non di obiettivi universali raccomandati.

Il provider gestisce l'infrastruttura gestita. Il team di piattaforma configura restrizioni di rete, identità, cifratura e logging. Gli sviluppatori dell'applicazione sono responsabili dell'autorizzazione per tenant e del comportamento dei link di esportazione. Il responsabile del servizio approva gli obiettivi di conservazione e di ripristino; la sicurezza rivede accessi ed evidenze.

Il worker riceve l'autorizzazione a leggere i record necessari del database e a scrivere le esportazioni nell'archivio designato. Non ha bisogno dell'autorizzazione a modificare la policy dello storage né a eliminare i backup. I download passano attraverso l'autorizzazione per tenant; gli eventuali link temporanei hanno una validità limitata e sono trattati come credenziali al portatore. I file di esportazione scadono secondo la regola di conservazione approvata.

I test comprendono una richiesta di oggetto non autenticata, un cliente che tenta di recuperare l'esportazione di un altro cliente e un worker che tenta un'azione amministrativa non consentita. I revisori verificano inoltre che l'accesso pubblico sia bloccato e che i download di prova generino gli eventi di audit attesi.

Un'esercitazione di ripristino verifica il database e le dipendenze applicative rispetto agli obiettivi di ripristino ipotizzati. Le evidenze comprendono esportazioni della configurazione, risultati dei test di autorizzazione, eventi di accesso campionati e il registro del ripristino. Se in una regione manca il logging degli accessi ai dati, il riesame registra la lacuna e assegna la correzione; i test superati altrove non la chiudono.

Conservare perimetro, eccezioni e decisioni di riesame

Le evidenze dovrebbero indicare account, risorsa, momento, metodo di raccolta e revisore. Un'esportazione della configurazione di un account non può dimostrare la postura di tutti gli account. Confrontate le risorse raccolte con l'inventario e registrate le raccolte fallite o le posizioni inaccessibili.

Mantenete per ogni servizio un insieme compatto di evidenze: la mappa delle responsabilità, la baseline approvata, i controlli attuali sulla configurazione, la revisione degli accessi effettivi, la copertura del logging, i risultati del ripristino e le eccezioni aperte. Ogni eccezione richiede un responsabile, una motivazione di rischio, controlli compensativi, un'approvazione, una scadenza e una condizione per il nuovo test.

Affiancate ai riesami programmati eventi che li facciano scattare. Modifiche sostanziali al deployment, nuove regioni, cambi di fornitore, incidenti, classificazioni dei dati modificate e nuovi percorsi di condivisione dovrebbero indurre una nuova valutazione. Il NIST Cybersecurity Framework offre un utile riferimento organizzativo attraverso le funzioni Govern, Identify, Protect, Detect, Respond e Recover; è una linea guida, non la prova che un deployment soddisfi i propri obblighi.

Secani può collegare questo lavoro a requisiti, oggetti di riferimento, evidenze, responsabili, attività e decisioni di riesame. Modellate il servizio cloud e le sue dipendenze, associate esportazioni della configurazione e registri dei test ai controlli che supportano e trasformate le lacune di copertura in lavoro assegnato. Mantenete esplicite l'approvazione umana e la tracciabilità delle fonti. Gli strumenti di sicurezza per il cloud restano la fonte della configurazione tecnica e degli alert; lo spazio di lavoro di compliance ne conserva il perimetro e le azioni che supportano.

Per il prossimo riesame tecnico, scegliete un flusso di dati sensibili. Ricostruite ogni copia e ogni percorso di accesso, assegnate le responsabilità lato cliente, testate le autorizzazioni effettive e ripristinate un workload rappresentativo. Estendete il perimetro quando quel riesame produce evidenze affidabili e un processo ripetibile.