La gestione dei database secondo il GDPR

Una corretta gestione dei database e dei dati in essi contenuti è fondamentale per essere certi di soddisfare i requisiti richiesti dal regolamento GDPR (General Data Protection Regulation) in vigore in Europa dal 25 maggio 2018.


Vediamo quali sono le azioni e le precauzioni che è possibile adottare per assicurarsi che il proprio database sia a prova di normativa sulla privacy. 

Le implicazioni del GDPR sui database

Un database deve soddisfare i requisiti stabiliti dal Regolamento Europeo sulla Protezione dei Dati, il famoso GDPR, quando in esso sono salvati dati personali, ovvero tutti quei dati che qualificano in qualsiasi modo una persona. Per questo per le aziende è necessario stabilire una corretta procedura di gestione dei dati e dell'infrastruttura che li supporta, soprattutto per quanto riguarda la sicurezza di tali dati.


Per assicurarsi di rispettare la normativa, il punto di partenza è un controllo completo di tutti i sistemi che possono essere vittime di attacco e quindi furto o perdita dei dati: non solo per quanto riguarda i database ma anche firewall, posta elettronica, accessi ad internet.


Database  e sicurezza

Il GDPR ha introdotto vari obblighi relativi alla sicurezza nella gestione dei dati personali, specificando che chi gestisce i database ha il dovere di implementare soluzioni tecniche ed organizzative appropriate per proteggere i dati.


Quali sono i dati personali previsti dal GDPR?

Ma quali sono di preciso i dati personali, ovvero quei dati che identificano o qualificano una persona? Ecco una panoramica:

  • Nome e cognome
  • Codici identificativi (es. tessera sanitaria, codice fiscale)
  • Nickname utilizzato in rete
  • Informazioni sulla sfera fisica, fisiologica o genetica
  • Informazioni mediche
  • Informazioni relative alla localizzazione geografica
  • Informazioni bancarie e reddito
  • Profilo culturale o religioso
  • Indirizzi IP e Cookies
  • Qualsiasi informazione che consenta di identificare una persona, direttamente o indirettamente.

Alcuni di questi dati vengono definiti dati sensibili: si tratta di tutti quei dati che rivelano l'origine razziale od etnica, le convinzioni religiose, filosofiche, le opinioni politiche, l'appartenenza sindacale, relativi alla salute. l'orientamento e la vita sessuale, i dati genetici e quelli biometrici. Come si intuisce facilmente, sono informazioni delicate, che richiedono particolare attenzione nella loro protezione e gestione. Vengono considerati una categoria a parte i dati giudiziari, ovvero tutti quei dati relativi al casellario giudiziale, alle sanzioni amministrative e la qualifica di indagato o imputato relativi alla persona. Anche i dati giudiziari, come i dati sensibili, vanno trattati con apposite precauzioni, come ad esempio la cifratura.

Quali database e software contengono dati personali in azienda?

In un'azienda. come del resto in qualsiasi altro tipo di attività, vanno considerati i dati relativi non solo ai clienti, ma anche ai dipendenti e ai fornitori. Alcuni degli applicativi che processano questi dati sono:

  • Gestionale
  • CRM
  • Gestione paghe
  • Sales force automation (ovvero tutti quegli applicativi utilizzati da marketing e forza vendita per automatizzare le comunicazioni e la gestione dei clienti e potenziali clienti)
  • Posta elettronica
  • Portale web e portale e-commerce
  • Fogli Excel e database costruiti con personal database systems, come ad esempio Access.


Come raggiungere la conformità al GDPR in quattro passi

1. Scoprire e classificare

In questa fase si identifica e classifica quali sono i dati personali attualmente in uso e dove si trovano.


2. Gestire

Controllo dei dati personali e le modalità di accesso e di utilizzo a questi da parte degli applicativi e degli utenti.


 3. Proteggere

Ovvero implementare meccanismi di sicurezza per prevenire ed identificare le vulnerabilità e rispondere alle eventuali fughe di informazioni.


4. Controllare e documentare

In questa fase si procede ad osservare i dati, certificarli, mantenere aggiornata la documentazione e registrare le richieste di accesso.


Primo passo: scoprire e classificare

Il primo passo è localizzare ed identificare tutti i sistemi aziendali che memorizzano dati personali e realizzare un inventario completo degli stessi. Successivamente, occorre identificare i requisiti di accesso da parte di utenti e applicazioni e identificare tutti i potenziali rischi.


In ambito database questo significa:

  • Identificare quali server e/o database contengono dati personali.
  • Identificare quali campi o record delle tabelle contengono questi dati.
  • Stabilire dove vanno a finire i dati una volta che lasciano il database (quali applicazioni li utilizzano).
  • Sapere chi ha accesso e a quali elementi del dato nel sistema.
  • Capire se è necessario mantenere queste informazioni per tutto il tempo.
  • Identificare quali elementi e configurazioni del DBMS possono essere raggiunti e potenzialmente sfruttati per prendere possesso dei dati.


Per effettuare un'analisi completa ed efficace in collaborazione con gli addetti alla gestione della privacy aziendale, sarà opportuno preparare:

  • Una mappa riassuntiva degli oggetti identificati e le e relazioni logiche che li legano (data flow).
  • I dati organizzati in una matrice che ha come dimensioni:
    • Categoria del dato
    • Livello di sensibilità.
  • Una mappa che visualizzi i potenziali accessi alle diverse risorse identificate.


Raccogliere e classificare queste informazioni consente inoltre di limitare le successive attività di gestione solo al contesto individuato.

Come scoprire e classificare in SQL Server

Per identificare i dati personali:
  • Interrogare i metadati (sys.columns) e analizzare i nomi delle colonne per identificare informazioni personali:
    • Data_di_nascita
    • Nome
    • Codice_Fiscale, CF
    • ID
  •  Le colonne che contengono dati personali possono essere «taggate» utilizzando le proprietà estese (Extended properties) presenti a diversi livelli della struttura degli oggetti di SQL Server.
  • Utilizzo della ricerca Full-Text per ricercare parole chiave all’interno dei campi di testo.

Per identificare i pattern di accesso ai dati personali:
  • Review della sicurezza al fine di mappare la cosiddetta «superficie di attacco» del DBMS.
  • Analisi degli accessi che vengono effettuati ai database ( Mole importante di informazioni. Servono strumenti e tecniche per riassumere i contenuti).
  • Riduzione della superficie di attacco:
    • Quali features sono abilitate? Se non sono utilizzate, disabilitarle:
      • XP_CMDSHELL, CLR, Filestream, Cross
      • DB Ownership Chaining, OLE AUTOMATION, External Scripts, Ad-hoc
      • Distributed Queries, Trustworthy bit, Servizi SSAS, SSRS, SSIS.
    •  Protocolli di rete che non sono utilizzati.
    • Se non necessario alle applicazioni, disabilitare anche il servizio SQL.
    • Server Browser.
    • Disinstallare i database di esempio e mantenere pulito ed ordinato l'albero dei database.

Secondo passo: gestire

Dopo che i dati personali sono stati individuati e con la gap analysis si è ottenuta una misura del rispetto della compliance, occorre implementare dei meccanismi per minimizzare il rischio di accesso non autorizzato ai dati o di perdite degli stessi. Andremo quindi a verificare, sia in SQL Server on-premises che su Azure SQL:
  • Autenticazione degli utenti
  • Autorizzazioni
  • Dynamic Data masking
  • Row level security.


Come gestire i dati in SQL Server: l'autenticazione degli utenti

Gestire l’accesso degli utenti e controllare come sono utilizzati i dati è fondamentale. Dovrebbero essere implementati dei meccanismi di controllo per minimizzare i rischi di accesso ai dati da parte di utenti non autorizzati o in caso di perdita dei dati stessi.


A livello di autenticazione degli utenti (e gruppi di utenti) possiamo utilizzare:


1) Windows authentication (la sicurezza è integrata con quella di Windows

          • Best practice
          • Gestita centralmente da Active Directory
          • Supporta le password policy enforcement rules:
              • Validazione della complessità
              • Scadenza
              • Account lockout

2) Mixed authentication
    • SQL Server built-in authentication

L'autenticazione degli utenti in Azure Database

In questo ambiente, il Firewall è attivato alla creazione del database by default, nessuno può accedere al medesimo.  La procedura consigliata è di configurare l’accesso solo da IP conosciuti.


Vi sono due tipi di autenticazione supportata:

  • SQL Auth
  • Azure Active Directory Auth


Inoltre vi è la possibilità di integrare l’AD on premise.


Come gestire i dati in SQL Server: le autorizzazioni

E’ necessario definire una corretta politica di autorizzazione agli oggetti del database in modo da garantire una separazione dei ruoli.


Per stabilire quali autorizzazioni concedere, è utile il principio del «privilegio minimo»: utenti e applicazioni accedono al sistema con il set minimo di privilegi necessario a svolgere il loro compito. Utenti e gruppi possono essere mappati su ruoli ben definiti e personalizzabili all’interno del database in modo da assegnare i permessi di accesso in base a bisogni specifici.

Come gestire i dati in SQL Server: Dynamic Data Masking

Il DDM limita l’esposizione di dati sensibili mascherando gli stessi agli utenti o alle applicazioni non autorizzate.


Il DBA può selezionare le colonne all’interno delle tabelle che contengono informazioni da proteggere e mascherarle oltre a definire quali utenti hanno i privilegi per poter accedere alle informazioni in chiaro.


La protezione del dato è eseguita dal motore del database e funziona «on the fly» con un impatto minimo a livello di prestazioni. I dati

all’interno delle tabelle rimangono in chiaro. L’applicazione non necessità di essere modificata in alcun modo per sfruttare questa funzionalità


Come gestire i dati in SQL Server: Row-Level Security

RLS limita l’accesso alle righe di una tabella del database in base ai privilegi assegnati all’utente che esegue la query.


Una query, potenzialmente, ritorna un set di dati diverso a seconda di chi la esegue. L’impatto a livello applicativo è minimo e non sono necessarie modifiche.

Terzo passo: proteggere

In questa terza fase, il focus si sposta sull’applicazione dei meccanismi di protezione e monitoraggio dei dati. Lo scopo è quindi quello di salvaguardare l’informazione ed identificare tempestivamente le fughe di dati.

Le soluzioni a disposizione sono:
  • Transport Layer Security
  • Transparent Data Encryption
  • Always Encrypted
  • Auditing
  • SQL Threat Detection
  • Business Continuity.


Come proteggere i dati in SQL Server: Transport Layer Security

E’ buona norma utilizzare sempre connessioni protette con TLS in modo da assicurare che il dato sia cryptato nel tragitto che compie da e per il database. In questo modo riusciamo a mitigare attacchi del tipo «man in the middle».


SQL Server e Azure SQL Database supportano TLS 1.2.


Come proteggere i dati in SQL Server: Transparent Data Encryption

Meccanismo di cifratura del dato che agisce a livello di storage fisico. Le informazioni sono salvate sul disco in modo protetto e SQL Server effettua il processo di encrypt e decrypt real-time.


Occorre precisare che i dati contenuti nelle tabelle sono ancora in chiaro. Sono solo i file del database che vengono criptati. Se questi vengono spostati o copiati su un altro server, non possono però essere utilizzati. Questo vale anche per i backup e per i dati contenuti nel transaction log.


TDE si applica all’intero database e risulta essere trasparente per le applicazioni, che non richiedono modifiche. Risulta interessante notare come alcune normative privacy e sicurezza considerano questa funzionalità come «core requirement».

Come proteggere i dati in SQL Server: Always Encrypted

Per alcune tipologie di dato particolarmente sensibili, la encryption a livello di file e di trasporto può non essere sufficiente (vedi l'art. 9 della normativa). In questi casi è possibile implementare delle politiche di data governance che consentono di differenziare il livello di protezione in base alla tipologia di dato.


Always encrypted consente di cifrare i dati sensibili all’interno dell’applicazione e non rivelare in nessun momento le chiavi di cifratura al motore del database.


Questa soluzione consente la separazione tra chi possiede i dati (e li può vedere) e chi li gestisce (e non dovrebbe avere accesso, ad esempio il DBA). Si tratta di un meccanismo trasparente per le applicazioni, che richiede però un driver di accesso ai dati particolari utilizzati dalle applicazioni.

Come proteggere i dati in SQL Server: SQL Threat Detection

SQL Threat Detection individua attività anomale effettuate sui database che possono essere interpretate come potenziali minacce alla sicurezza. Per il momento questa funzionalità è disponibile solo per i prodotti della famiglia Azure SQL.


Il database administrator viene notificato in modo proattivo di ogni attività sospetta che potrebbe indicare un accesso ai dati non autorizzato. 

Il sistema si aggiorna in automatico: viene infatti analizzato continuamente il pattern di utilizzo «normale» utilizzando algoritmi di machine learning e metodologie di analisi comportamentale.

Come proteggere i dati in SQL Server: Auditing

Per auditing si intende il mettere in atto delle valutazioni nei confronti di un sistema, al fine di individuare se siano soddisfatti i criteri prefissati ai quali quel particolare sistema deve uniformarsi.


SQL Server contiene raffinati meccanismi che consentono di abilitare la tracciatura delle attività effettuate dagli utenti. Il sistema infatti consente di raccogliere e analizzare informazioni che possono condurre all’identificazione di pattern anomali di utilizzo, abusi o violazioni del dato.


Questi meccanismi risultano particolarmente utili quando si ha a che fare con una grande mole di dati, le cui dimensioni implicano difficoltà nella lettura e nell'interpretazione.


Possono risultare molto utili anche gli strumenti di terze parti per l’analisi dei log. come ad esempio Netwrix.


Come proteggere i dati in SQL Server: Business Continuity

Dobbiamo preoccuparci di assicurare la resilienza e la disponibilità del dato nel caso di eventi avversi.


Strumenti a disposizione:
  • Piani di backup adeguati (e relativi test periodici di restore)
  • SQL Server Always On
  • Failover Cluster Instance
  • Availability Groups
  • Altre tecniche: Log shipping (da SQL 2000).

In aggiunta, su cloud:
  • Azure SQL Database point in time restore, long term retention (fino a dieci anni)
  • Active Geo replication (con rispetto della «residenza» del dato).

Quarto passo: controllare e documentare

La fase finale del processo per raggiungere e mantenere la compliance con il GDPR prevede di:
  • Documentare in modo o significativo e/o sistematico l’elenco dei trattamenti previsti, una valutazione dei rischi e le misure attuate per affrontarli.
  • Mantenere una traccia di tutte le attività che vengono eseguite sui database e che riguardano dati personali (inserimenti, modifiche, cancellazioni e consultazioni).
  • Rendere disponibili queste informazioni nel caso di richiesta da parte delle autorità.
  • Effettuare una verifica continua dei controlli e della gestione implementata nei passaggi precedenti in modo da innescare nuovamente il processo nel caso di cambiamenti significativi.
  • Anche in questo caso, gli strumenti di auditing, visti precedentemente, rappresentano la base per definire le informazioni che dovranno poi essere raccolte e documentate.

Come controllare e documentare: soluzioni custom o di mercato?

Come spesso accade, le soluzioni custom sembrano meno costose ma il TCO sul medio periodo supera quello di una soluzione di mercato (continui adattamenti, situazioni non previste da rimediare, velocità di implementazione).


Una soluzione di mercato è «certificata» indirettamente dal numero dei suoi utilizzatori, continuamente aggiornata, spesso rispondente anche ad altre normative (ISO27001,PCI DSS 3.0, HIPAA, SOX, FISMA / NIST800-53 e DLGs 196/03).

Come controllare e documentare: alcuni aspetti importanti

Diritto all’oblio

Sembra semplice: eliminiamo i dati della persona dal database. Ma in realtà non è sufficiente. Questo diritto infatti include tutti i backup effettuati, esportazioni di dati su altri strumenti (excel, file di testo, archivi di altro genere), business intelligence. Come può un DBA rimuovere i dati di una persona da un tape?


Portabilità del dato

Secondo la normativa «l’interessato ha il diritto di ricevere in un formato strutturato, di uso comune, leggibile ed interoperabile i dati personali che lo riguardano e trasmetterli ad un altro titolare del trattamento…ove tecnicamente fattibile». Esiste (o esisterà) un formato comune per lo scambio di queste informazioni?


Data retention

In base al principio introdotto della limitazione del periodo di conservazione, il dato dovrebbe essere conservato solo per il tempo strettamente necessario al suo trattamento. Non possiamo più «dimenticarci» i dati di una persona nel database se non  vengono utilizzati.


Data warehouse e Business Intelligence in merito al GDPR

Difficilmente, nei sistemi di analisi del dato abbiamo bisogno di informazioni puntuali relative alla persona (nome, cognome, Codice Fiscale). I dati sono valutati in modo aggregato.


Ci interessano però informazioni relative all’età, genere, localizzazione geografica. Ma posso includere i dati di quella persona nelle mie analisi anche se non riconducibili a nessuno in particolare?

Possiamo utilizzare alcune tecniche per filtrare (quando possibile) le informazioni:
  • Black list
  • Flagging

In un data warehouse sulle vendite non posso applicare filtri a priori oppure tecniche per il mascheramento. Spesso infatti dobbiamo ritornare queste informazioni ad altri sistemi (ad esempio le segmentazioni del mercato per il CRM).