Sicurezza dei dati: rischi, controlli e le fondamenta della governance

Il panorama dei dati è cambiato più rapidamente della maggior parte dei programmi di sicurezza. Oggi i dati transitano attraverso pipeline, condivisioni con partner, agenti AI e app a valle, e questi spostamenti creano spesso punti di controllo che i modelli di sicurezza tradizionali non erano progettati per gestire su larga scala. Crittografia, controllo degli accessi e monitoraggio restano essenziali, ma la sicurezza dei dati dipende ora dalla governance: sapere quali dati esistono, chi ne è titolare, quanto sono sensibili e quali regole si applicano.

Sicurezza e governance dei dati sono discipline distinte, ma quando operano separatamente diventa difficile applicare le policy man mano che le informazioni si spostano tra sistemi, team e ambienti. Questa guida illustra cosa significhi oggi sicurezza dei dati, perché la posta in gioco sia più alta, i principali rischi e le normative che orientano i programmi aziendali, e i controlli che le organizzazioni adottano per proteggere i dati lungo il loro ciclo di vita.

La sicurezza dei dati è l’insieme di pratiche, controlli e tecnologie che proteggono i dati digitali da accessi non autorizzati, corruzione, furto o perdita lungo il loro ciclo di vita. Deve tenere conto dei dati inattivi, dei dati in transito e dei dati in uso, oltre che delle identità, delle policy e dei sistemi che interagiscono con quei dati in ogni fase. I punti di controllo variano a seconda di dove risiedono i dati e di come si muovono, ed è questo a rendere la disciplina complessa nella pratica.

Il framework di riferimento è la triade riservatezza, integrità e disponibilità. La riservatezza garantisce che solo utenti, servizi e workload autorizzati possano accedere ai dati sensibili. L’integrità garantisce che i dati restino accurati, completi e affidabili mentre vengono creati, trasformati, interrogati, condivisi o utilizzati nelle app a valle. La disponibilità garantisce che i dati restino accessibili agli utenti autorizzati quando l’azienda ne ha bisogno, anche in caso di guasti, interruzioni o attacchi.

La sicurezza dei dati è correlata ma distinta dalla data privacy e dalla data governance. La data privacy definisce come i dati personali debbano essere raccolti, utilizzati, conservati e divulgati, in genere in risposta a normative come il GDPR o il CCPA. La data governance definisce chi è titolare dei dati, come vengono classificati, quali regole si applicano e chi o cosa può utilizzarli. La sicurezza dei dati applica queste regole tramite controlli degli accessi, crittografia, mascheramento, monitoraggio, policy di conservazione e gestione degli incidenti.

I dati sensibili non risiedono più in un numero ristretto di sistemi controllati. Si muovono tra app SaaS, data lake, warehouse, ambienti partner, workflow di collaboration e pipeline AI. Una singola colonna che contiene numeri di conto, informazioni sanitarie protette o dettagli finanziari può essere copiata, trasformata, incorporata, condivisa o recuperata in più punti, il che significa che la sicurezza deve seguire i dati anziché fare affidamento sulla tenuta del perimetro di rete.

La pressione normativa riflette l’evoluzione del panorama dei dati. GDPR, CCPA, HIPAA, PCI DSS e SOX continuano a orientare il modo in cui le organizzazioni proteggono i dati personali, di pagamento, sanitari e finanziari. DORA è entrato in vigore il 17.01.2025 per le entità finanziarie dell’UE, mentre gli Stati membri dell’UE erano tenuti a recepire NIS2 nel diritto nazionale entro il 17.10.2024. In India, il Digital Personal Data Protection Act, 2023, ha definito il framework per i dati personali digitali, mentre le Digital Personal Data Protection Rules, 2025, ne scandiscono le fasi di attuazione.

La conformità, però, è soltanto il punto di partenza. Un’azienda può soddisfare uno specifico requisito di audit e avere comunque ruoli con permessi eccessivi, copie obsolete di dati sensibili, condivisioni con partner non monitorate o workload AI che recuperano più contesto di quanto l’utente dovrebbe vedere.

Una sicurezza dei dati efficace richiede una difesa in profondità: crittografia per proteggere i dati inattivi e in transito, controllo degli accessi per limitarne l’utilizzo, mascheramento e policy a livello di riga per contenere l’esposizione all’interno delle query, data loss prevention per ridurre gli spostamenti impropri, posture management per far emergere i rischi e monitoraggio continuo per rilevare comportamenti anomali.

L’AI ha reso la sicurezza dei dati più urgente. Dati di addestramento, vector embedding, sistemi di retrieval-augmented generation, contesto accessibile agli agenti AI e output dei modelli creano percorsi di fuga di dati che cinque anni fa non esistevano nella stessa forma. La domanda sul controllo degli accessi non è più solo “Questo dipendente può eseguire query sulla tabella?”, ma anche “Questo agente AI può recuperare la riga, usare l’embedding, richiamare lo strumento e produrre un output che espone dati sensibili?”

Molte organizzazioni sono in ritardo sulla sicurezza dell’AI. Secondo il 2025 Enterprise Data Security Confidence Index di Bedrock Data, il 79% dei team di sicurezza fatica a classificare i dati sensibili utilizzati nei sistemi di AI e machine learning, e meno della metà dichiara un alto livello di fiducia nel controllo dei dati sensibili impiegati per l’addestramento dei modelli.

Guarda il video per scoprire come implementare le best practice di sicurezza con Trust Center in Snowflake Horizon:

Il controllo degli accessi è il meccanismo fondamentale della sicurezza dei dati: le regole e la loro applicazione che stabiliscono chi può leggere, scrivere, modificare o condividere dati specifici. La gestione degli accessi definisce il ciclo di vita operativo, ossia come l’accesso viene richiesto, approvato, provisionato, revisionato e revocato, mentre il controllo degli accessi applica tali decisioni tramite ruoli, attributi, privilegi, policy e audit trail.

La maggior parte dei programmi enterprise combina controllo degli accessi basato sui ruoli (RBAC), controllo degli accessi basato sugli attributi (ABAC) e policy granulari. RBAC concede i privilegi tramite ruoli legati a funzioni o responsabilità aziendali. ABAC valuta attributi come dipartimento, area geografica, livello di autorizzazione, sensibilità dei dati o tipo di workload. Le regole a livello di riga e di colonna affinano quindi l’accesso all’interno di una tabella, così gli utenti possono lavorare sugli stessi dati senza ricevere la medesima visualizzazione di ogni record.

Il controllo degli accessi basato sui ruoli è il modello di controllo degli accessi più diffuso perché mappa le autorizzazioni sul modo in cui le organizzazioni già operano. Anziché concedere i privilegi direttamente a ciascun utente, gli amministratori li assegnano ai ruoli, associano gli utenti a tali ruoli e utilizzano una gerarchia di ruoli per ereditare le autorizzazioni dove opportuno.

Il principio del privilegio minimo dovrebbe orientare il modello dei ruoli fin dall’inizio. I ruoli dovrebbero concedere l’accesso minimo necessario affinché una persona, un service account o un workload svolga il proprio compito, con privilegi elevati separati, revisionati e, quando possibile, limitati nel tempo. Con la crescita degli ambienti, i team devono monitorare la proliferazione dei ruoli, le autorizzazioni ereditate e gli accessi basati su eccezioni.

La crittografia dei dati trasforma i dati leggibili in testo cifrato che solo le parti autorizzate possono decifrare. Protegge i dati inattivi nello storage, i dati in transito sulle reti e, a seconda dell’architettura, i dati in uso durante l’elaborazione. La crittografia riduce l’esposizione in caso di accesso improprio allo storage, intercettazione del traffico o backup che lascia l’ambiente previsto.

La crittografia dei dati inattivi protegge i dati archiviati come tabelle, file, snapshot e backup. La crittografia dei dati in transito protegge i dati mentre si spostano tra client, servizi, app e componenti della piattaforma, in genere tramite TLS. La crittografia dei dati in uso è la categoria più complessa, perché i dati spesso devono essere elaborati in forma leggibile, ma le piattaforme moderne riducono sempre più l’esposizione grazie a ambienti di esecuzione sicuri, applicazione delle policy e percorsi di elaborazione attentamente controllati.

Le organizzazioni devono adottare un modello operativo per il key management che stabilisca chi controlla le chiavi, come vengono ruotate, come viene registrato l’accesso ad esse e se requisiti normativi o interni richiedano chiavi gestite dal cliente. Per le organizzazioni con requisiti di controllo stringenti, le chiavi gestite dal cliente offrono un’ulteriore separazione tra l’operatore della piattaforma e il modello di controllo crittografico dell’organizzazione.

I principali meccanismi di crittografia proteggono il data layer, mentre la governance determina quali utenti, workload e policy possono consentire l’utilizzo dei dati decifrati.

Il mascheramento dei dati nasconde i valori sensibili agli utenti che non dovrebbero visualizzarli, preservando al contempo una struttura sufficiente per analisi, test o operazioni. Ad esempio, un support analyst può aver bisogno di sapere che un record cliente esiste senza vedere per intero il numero di previdenza sociale, il numero di carta di credito o il codice diagnostico. Un data scientist può aver bisogno di pattern geografici o demografici senza identificatori diretti.

Il mascheramento statico crea una copia sanitizzata dei dati, spesso destinata ad ambienti secondari come sviluppo, test o addestramento. Il mascheramento dinamico dei dati applica la policy in fase di query, così la stessa colonna può restituire valori diversi a seconda del ruolo, degli attributi o del contesto dell’utente. La tokenizzazione è affine: i valori sensibili vengono sostituiti con token non sensibili, reversibili solo in condizioni controllate. Anche la crittografia che preserva il formato può proteggere i valori sensibili mantenendo la struttura attesa dalle app.

Un mascheramento efficace dipende da un’accurata classificazione dei dati. Una policy non può proteggere la colonna email_address o un file non strutturato contenente dati sulle retribuzioni se l’organizzazione non è in grado di identificare i dati sensibili in primo luogo. Classificazione, tagging e mascheramento funzionano al meglio come un unico ciclo: individuare i dati sensibili, applicare un tag, associare la policy appropriata e monitorare se i nuovi asset richiedono lo stesso trattamento.

La sicurezza a livello di riga limita le righe che un utente può visualizzare in una tabella in base a identità, ruolo, attributi o relazione con i dati. È particolarmente utile quando team, aree geografiche, business unit o tenant diversi devono lavorare sulla stessa tabella senza ricevere gli stessi record.

L’esempio classico è un’applicazione di analisi dei dati multi-tenant: può servire centinaia di clienti da una tabella condivisa, ma ciascun cliente deve vedere solo le proprie righe. Senza la sicurezza a livello di riga, i team creano spesso viste duplicate, estrazioni o filtri specifici per applicazione difficili da controllare e facili da configurare in modo errato.

La sicurezza a livello di riga è più solida quando è dichiarativa e associata all’oggetto dati anziché nascosta nella logica applicativa. Se la policy risiede a livello di tabella, si applica in modo coerente a tutte le query e ai casi d’uso a valle, riducendo il rischio che una nuova dashboard, un notebook, un agente o un’applicazione aggiri il filtro previsto.

La data loss prevention (DLP) è la disciplina che consiste nel rilevare e impedire l’esfiltrazione, la fuga o la condivisione inappropriata dei dati sensibili. La causa può essere dolosa, come il furto di credenziali e l’esfiltrazione di dati, oppure colposa, come un analista che esporta più dati del necessario, una pipeline che scrive dati sensibili in una posizione non gestita o una condivisione con un partner che resta attiva dopo un cambiamento nella relazione commerciale.

La DLP moderna combina classificazione, applicazione delle policy, monitoraggio e risposta. La classificazione identifica i dati sensibili. Le etichette o i tag di sensibilità attribuiscono un significato a tali dati. Le policy determinano se i dati possono essere interrogati, copiati, esportati, condivisi o utilizzati da un workload. Il monitoraggio individua quindi pattern di accesso, attività di egress o eccezioni alle policy che richiedono un’indagine.

La DLP tradizionale operava spesso come controllo di rete o endpoint, il che aveva senso quando i file sensibili si spostavano tramite email, endpoint e canali di rete gestiti. In un ambiente dati moderno, i dati sensibili si muovono attraverso pipeline, condivisioni, API, notebook, app e sistemi AI. La DLP deve diventare più incentrata sui dati: le policy devono seguire l’oggetto dati, non solo il percorso di rete.

La data security posture management (DSPM) è l’attività continua di individuazione, classificazione e valutazione del rischio dei dati sensibili negli ambienti di un’organizzazione. Risponde a tre domande pratiche: Dove si trovano i dati sensibili? Chi o cosa può accedervi? Quale rischio deriva da tale accesso, posizione o stato delle policy?

La DSPM è nata perché molti strumenti di sicurezza erano stati progettati attorno all’infrastruttura, non ai dati. Uno strumento di cloud security posture management (CSPM) può individuare un bucket esposto, una porta aperta o una policy debole di gestione delle identità e degli accessi, ma non indica necessariamente al team di sicurezza se la risorsa esposta contiene record dei clienti, codice sorgente, dati sanitari, dati di pagamento o log operativi ad alto rischio. La DSPM si concentra sui dati stessi: sensibilità, posizione, percorsi di accesso, copertura delle policy, pattern di utilizzo e rischio.

La DSPM nativa della piattaforma riduce alcune delle lacune che emergono quando uno strumento di terze parti deve analizzare in autonomia ogni archivio dati. Poiché la piattaforma conosce già quali oggetti esistono, quali utenti e ruoli possono accedervi, quali tag e policy si applicano e come i dati vengono interrogati o condivisi, l’individuazione e la valutazione del rischio poggiano su una base più continua rispetto alle sole scansioni periodiche.

I rischi per la sicurezza dei dati rientrano in tre grandi categorie: minacce esterne, minacce interne e rischi specifici dell’AI.

• Le minacce esterne comprendono ransomware, phishing, furto di credenziali, compromissione della supply chain e attacchi che utilizzano identità rubate o abusate per raggiungere i sistemi di dati. Restano attive perché gli aggressori non hanno bisogno di exploit diretti sul database se possono ottenere credenziali, compromettere un account di servizio o muoversi lateralmente da un sistema connesso.
• Le minacce interne comprendono insider malintenzionati, utenti negligenti, shadow IT, configurazioni errate e account con privilegi eccessivi. Un utente con ampi accessi può interrogare dati sensibili, esportarli, condividerli o instradarli in un workflow non gestito senza attivare gli stessi allarmi di un aggressore esterno: ecco perché privilegio minimo, separazione dei compiti, revisioni degli accessi e monitoraggio sono controlli di sicurezza dei dati, non semplici task di amministrazione delle identità.
• I rischi specifici dell’AI aggiungono un ulteriore livello. Il prompt injection può indurre un sistema con retrieval-augmented generation ad accedere o riepilogare contesto sensibile in modi non previsti dall’utente. La fuga di dati di training può esporre record sensibili attraverso il comportamento o gli output del modello. L’eccesso di autonomia degli agenti può verificarsi quando gli agenti autonomi ricevono un accesso a strumenti o dati più ampio di quello che l’utente dovrebbe avere. L’esfiltrazione degli output del modello può avvenire quando risultati sensibili escono dall’ambiente governato tramite chiamate a strumenti, plugin o app connesse.

Le normative che riguardano la sicurezza dei dati definiscono gli obblighi che i controlli di sicurezza devono soddisfare. Una normativa può specificare misure di salvaguardia, regole di notifica delle violazioni, aspettative di audit, limiti di conservazione o diritti relativi ai dati personali, e le organizzazioni soggette a tale legge devono tradurre i requisiti in controlli concreti su tutto il proprio patrimonio di dati.

• Il GDPR è il framework dell’UE per i dati personali basato sui diritti. Richiede una base giuridica per il trattamento, riconosce alle persone diritti sui propri dati personali e crea obblighi in materia di protezione, responsabilità e notifica delle violazioni.
• Il CCPA si applica alle informazioni personali dei consumatori della California. Definisce i diritti alla privacy dei consumatori e, in determinati scenari di violazione, prevede un diritto di azione privata.
• L'HIPAA disciplina le informazioni sanitarie protette nel sistema sanitario statunitense. Richiede misure di salvaguardia amministrative, fisiche e tecniche per gli enti coperti e i loro partner commerciali.
• Il PCI DSS definisce i requisiti tecnici e operativi per la protezione degli ambienti che trattano i dati dei titolari di carta. Il PCI Security Standards Council descrive i propri standard come un framework di specifiche, strumenti, misurazioni e risorse di supporto per la gestione sicura delle informazioni dei titolari di carta.
• Il SOX si concentra sui controlli relativi al reporting finanziario. Per i team di sicurezza dei dati, l’aspetto pratico riguarda l’integrità, il controllo degli accessi e la verificabilità dei dati finanziari utilizzati nei processi di reporting.
• Il DORA si applica agli enti finanziari nell’UE e si concentra sulla resilienza operativa digitale, inclusa la capacità di resistere, rispondere e riprendersi dalle interruzioni delle tecnologie dell’informazione e della comunicazione. È entrato in vigore il 17.01.2025.
• La NIS2 amplia gli obblighi di cybersecurity e di notifica degli incidenti per i settori critici in tutta l’UE.
• Il DPDP Act indiano disciplina i dati personali digitali in India. La legge indica come proprio scopo quello di regolamentare il trattamento dei dati personali digitali in modo da riconoscere sia il diritto delle persone a proteggere i propri dati personali sia la necessità di trattarli per finalità lecite.

Il problema operativo ricorrente non è semplicemente sapere quali regole si applicano, ma dimostrare che i controlli di accesso, mascheramento, conservazione, monitoraggio e risposta agli incidenti sono applicati in modo coerente su tutti i sistemi in cui risiedono i dati regolamentati. La data governance contribuisce a sostenere la conformità alle normative collegando gli obblighi normativi ai data asset che li riguardano, così i team sanno cosa è protetto, quale policy si applica e dove sono le lacune.

I programmi di sicurezza dei dati variano in base a settore, architettura e profilo di rischio. Le pratiche seguenti coprono le aree fondamentali che la maggior parte dei programmi enterprise deve gestire correttamente. Non sono esaustive, ma rappresentano le più importanti per patrimoni di dati sempre più distribuiti che implementano workload AI.

Classificare e inventariare i dati sensibili

Parti dagli oggetti che necessitano di protezione: tabelle, viste, file, stage, set di dati, embedding, condivisioni, app e contesto accessibile all’AI. La classificazione identifica se tali oggetti contengono PII, informazioni sanitarie protette, dati dei titolari di carta, credenziali, proprietà intellettuale o altri dati sensibili. L’attività di inventario collega quindi tale classificazione a proprietari, lineage, regole di conservazione, percorsi di accesso e utilizzo a valle.

Applicare l’accesso con privilegio minimo a utenti, servizi e workload

Ogni utente, account di servizio, app e workload AI deve ricevere solo l’accesso necessario per svolgere un task definito. L’accesso deve avere un ciclo di vita: un nuovo utente riceve l’accesso attraverso un workflow approvato, gli accessi con privilegi elevati scadono al termine del task, gli utenti inattivi vengono rimossi e gli account di servizio vengono rivisti quando cambiano pipeline o app. I principi zero trust rafforzano questo modello trattando ogni richiesta come qualcosa da verificare in base a identità, contesto, dispositivo, workload e sensibilità.

Proteggere i dati sensibili con controlli basati su policy

Il mascheramento dinamico dei dati può nascondere i valori sensibili delle colonne al momento della query. Le policy di accesso righe possono limitare i record per area geografica, tenant, account o ruolo. La tokenizzazione può preservare una struttura utile riducendo al contempo l’esposizione del valore originale. Questi controlli sono particolarmente importanti quando più team utilizzano gli stessi dati governati. Anziché creare molte copie di una tabella clienti per ogni area geografica o funzione, i team applicano le policy all’oggetto condiviso e lasciano che la piattaforma imponga la vista appropriata.

Proteggere il movimento dei dati, la condivisione e la collaboration

Ogni volta che i dati si spostano, attraverso una pipeline, una condivisione con un partner, un’esportazione o un modello, si crea un punto di controllo. La destinazione è approvata? I dati sono ancora classificati? Si applica lo stesso mascheramento o la stessa policy a livello di riga? La condivisione serve ancora? La collaboration sicura funziona al meglio quando i team possono condividere dati governati senza creare estrazioni non gestite.

Monitorare gli accessi e indagare sulle attività insolite

Cronologia delle query, cronologia degli accessi, cronologia dei login, modifiche agli oggetti, tentativi di accesso non riusciti e modifiche alle policy aiutano tutti i team di sicurezza a rilevare abusi, indagare sugli incidenti e dimostrare l’efficacia dei controlli. Il monitoraggio deve combinare contesto delle policy, contesto delle identità e sensibilità dei dati: una singola query su una tabella protetta può essere normale per un ruolo e sospetta per un altro.

Governare i dati lungo l’intero ciclo di vita

Tabelle temporanee, copie di sviluppo, dati di test, feature derivate, dati di training dei modelli, indici vettoriali, report e dati archiviati possono tutti contenere informazioni sensibili. I controlli sul ciclo di vita devono definire conservazione, cancellazione, archiviazione, backup, ripristino, uso in dev/test e uso approvato dell’AI. I dati di produzione sensibili non dovrebbero essere copiati in ambienti secondari senza mascheramento o controlli sui dati sintetici.

Prepararsi alla risposta agli incidenti e al ripristino

I piani di risposta agli incidenti devono definire chi indaga sugli accessi sospetti, chi può revocare i privilegi, chi comunica con i team legali o di conformità e come vengono conservate le prove. Backup, replica, failover, punti di ripristino protetti e test di ripristino rientrano nel discorso sulla sicurezza dei dati, perché la disponibilità è parte della triade riservatezza, integrità e disponibilità.

Verificare i controlli e gestire le eccezioni

Revisioni degli accessi, eccezioni alle policy, copertura del mascheramento, stato della classificazione, registrazioni degli incidenti, rotazione delle chiavi, applicazione delle regole di conservazione e risultati del monitoraggio dovrebbero produrre artefatti che gli auditor e i team interni di gestione del rischio possano esaminare. Le eccezioni devono essere esplicite, approvate e a tempo determinato: un’eccezione permanente è spesso una lacuna nelle policy mascherata.

Snowflake unifica sicurezza dei dati e data governance nello stesso control plane della piattaforma: le organizzazioni possono così definire policy, classificare i dati, gestire gli accessi, monitorare l’attività e governare i workload di AI senza mantenere modelli di enforcement separati per ogni caso d’uso.

Snowflake Horizon Catalog è al centro di questo modello. Offre funzionalità di governance, discovery e catalogazione per la piattaforma dati, aiutando i team a gestire dati, app e asset di AI con un contesto condiviso, che include classificazione, policy di mascheramento, policy di accesso righe, lineage e monitoraggio della qualità dei dati.

RBAC, mascheramento, policy di accesso righe, tagging e policy di protezione dei dati operano sullo stesso modello di dati governati, riducendo le duplicazioni tra i team di governance e sicurezza. Con le policy di protezione dei dati Snowflake i team definiscono una sola volta autorizzazioni granulari e le applicano in modo coerente al momento della query, senza dover creare ruoli o viste aggiuntivi man mano che dati e team crescono.

Il Snowflake Compliance Center offre ai team un modo per monitorare la security posture dell’account Snowflake, mettere in evidenza i risultati degli scanner e valutare la maturità in materia di sicurezza dei dati e autenticazione direttamente da Snowflake, inclusi i risultati di rilevamento incentrati su attività potenzialmente sospette.

Infine, i workload di AI si basano su dati governati ma introducono nuovi pattern di accesso attraverso agenti, strumenti, sistemi di retrieval e output dei modelli. Horizon funge da catalogo AI universale che unifica contesto e governance su dati e asset di AI, mentre la partnership Snowflake con Bedrock Data garantisce visibilità sugli agenti AI e sui dati a cui possono accedere.

I controlli di sicurezza dei dati sono efficaci solo quanto il fondamento su cui poggiano. Policy di accesso, regole di mascheramento, restrizioni a livello di riga e monitoraggio richiedono tutti gli stessi input per funzionare in modo affidabile: un quadro accurato di dove risiedono i dati sensibili, come sono classificati e chi ne è responsabile. Senza questo fondamento, i team prendono decisioni ragionevoli sulla base di informazioni incomplete, e le lacune tendono a emergere nei momenti peggiori, durante l’indagine su un incidente o un audit di conformità.

La governance offre questo fondamento e aiuta i team a stabilire dove e come applicare i controlli di sicurezza dei dati. Ecco perché i programmi di sicurezza dei dati più solidi trattano classificazione, ownership e policy non come deliverable di governance, ma come prerequisiti di sicurezza.