L'avvento del GDPR nel Maggio del 2018 ci consente di fare una serie di riflessioni riguardo ai nostri database e ai dati in essi contenuti. Come dobbiamo prepararci?

1. La gestione dei database
secondo il GDPR – SQL Server
La nuova privacy europea (GDPR): come adeguarsi entro la scadenza normativa
Vicenza, 2017-06-26

2. What we do
• DBA Services
• Database Consulting
• Business Intelligence
• Software development
Who we are
• Founded: 2014
• Total Employment: 5
• Head Office: Vicenza
18+ years in SQL Server
10+ years in BI & OLAP
www.datamaze.it

3. Cosa vedremo
3
• Le implicazione del GDPR sui nostri database
• Quali informazioni proteggere
• La compliance
• 1. Scopri e classifica
• 2. Gestisci
• 3. Proteggi
• 4. Controlla e documenta
• Alcuni aspetti da non sottovalutare
• Il datawarehouse e la business intelligence

4. Le implicazioni del GDPR sui nostri
database
Un’azienda che possiede un database che è soggetto all’applicazione del GDPR, sia
esso gestito nel cloud oppure on premises, è tenuta ad assicurare che i dati che
qualificano in qualsiasi modo un individuo siano correttamente gestiti e protetti in base ai
principi espressi nel GDPR.
Questo significa che molte aziende avranno bisogno di revisionare ed apportare
modifiche alle loro procedure di gestione dei dati e dell’infrastruttura a supporto, con
particolare attenzione agli aspetti di sicurezza.
Ci sono infatti diversi obblighi specificatamente introdotti dal GDPR, relativi a controlli e
sicurezza che girano attorno alla gestione dei dati personali. Il regolamento obbliga chi
gestisce i dati ad «implementare misure tecniche ed organizzative appropriate» per far
fronte a tali obblighi.
4

5. Quali informazioni proteggere?
A quali dati ci riferiamo? (elenco non esaustivo…)
• Nome e Cognome
• Numeri e codici identificativi (Codice fiscale, numero della tessera sanitaria,…)
• Indirizzo email
• Nickname utilizzati on-line
• Informazioni relative alla sfera fisica, fisiologica o genetica
• Informazioni mediche
• Informazioni relative alla localizzazione geografica
• Informazioni bancarie
• Reddito
• Profilo culturale e religioso
• Indirizzi IP
• Cookies
• … ogni altra informazioni ci possa aiutare ad identificare, direttamente o
indirettamente, un individuo.
5

6. Quali informazioni proteggere?
Quali sono i database ed applicativi che sono presenti in azienda e contengono dati
personali?
• CRM
• Gestione paghe
• Sales force automation
• Posta elettronica
• Portale e-commerce
• Gestionale (soprattutto negli scenari B2C)
Per non parlare di:
• Fogli di excel sparsi sul file system (spesso dimenticati…)
• Database costruiti con personal database systems (Microsoft Access, FileMaker,
etc…)
Anche in questo caso l’elenco non è esaustivo…
6

7. La compliance
Il processo di raggiungimento della compliance al GDPR si estende a tutto l’ambito
servito dall’IT
GDPR
Compliance
Scopri e
classifica
Gestisci
Proteggi
Controlla e
documenta
• Scopri. Identifica e classifica quali
sono i dati personali attualmente
gestiti e dove risiedono.
• Gestisci. Governa i dati personali e
le modalità di accesso ed utilizzo.
• Proteggi. Implementa dei
meccanismi di sicurezza per
prevenire, identificare e rispondere
alle vulnerabilità ed alle fughe di
informazioni.
• Controlla e documenta. Osserva i
dati, certificali, mantieni la
documentazione, le richieste di
accesso.
7
1
2
3
4

8. 1. Scopri e classifica
First things first
• Localizzare e classificare tutti i sistemi che memorizzano dati
• Fare un inventario dei dati personali e sensibili
• Identificare i requisiti di accesso ai dati da parte di utenti e applicazioni
• Identificare i potenziali rischi
Dobbiamo essere pronti a rispondere a domande del tipo:
• Quali server e/o database contengono dati personali?
• Quali campi o record delle mie tabelle contengono questi dati?
• Dove vanno a finire i dati una volta che lasciano il database? Applicazioni…
• Chi ha accesso e a quali elementi del dato nel mio sistema?
• Mi serve mantenere queste informazioni per tutto questo tempo?
• Quali elementi e configurazioni del mio DBMS possono essere raggiunti e
potenzialmente sfruttati per prendere possesso dei miei dati?
8

9. 1. Scopri e classifica
Elementi da produrre per una efficace gap analysis durante il confronto con il privacy
team:
• Creare una mappa riassuntiva degli oggetti identificati e le relazioni logiche che li
legano (data flow);
• Presentare i dati in base ad una matrice che ha come dimensioni:
• Categoria del dato
• Livello di sensibilità
• Creare una mappa che visualizzi i potenziali accessi alle diverse risorse identificate
Raccogliere e classificare queste informazioni ci porta il beneficio indiretto di limitare le
successive attività di gestione solo al contesto individuato.
9

10. 1. Scopri e classifica. Come?
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
10

11. 1. Scopri e classifica. Come?
Identificare i pattern di accesso ai dati personali. Review della sicurezza al fine di
mappare la cosiddetta «superficie di attacco» del DBMS
• Analizziamo gli accessi che vengono effettuati ai database
• Mole importante di informazioni. Servono strumenti e tecniche per
riassumere i contenuti
• Riduciamo la superficie di attacco
• Quali features sono abilitate? Se non sono utilizzate, disabilitiamole
• 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, disabilitiamo anche il servizio SQL
Server Browser
• Disinstalliamo i database di esempio e manteniamo pulito ed ordinato il
nostro albero dei database
11

12. 2. Gestisci
Dopo che i dati personali sono stati individuati e con la gap analysis abbiamo una misura
del rispetto della compliance, dobbiamo implementare dei meccanismi per minimizzare il
rischio di accesso non autorizzato ai dati o di perdite degli stessi.
• Autenticazione degli utenti
• Azure SQL
• Autorizzazioni
• Dynamic Data masking
• Row level security
12

13. 2. Gestisci. Autenticazione degli utenti.
• Gestire l’accesso degli utenti e controllare come sono utilizzati i dati
• 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
• Autenticazione degli utenti (e gruppi di utenti)
• 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
• Mixed authentication
• SQL Server built-in authentication
«I dati personali dovrebbero essere trattati in modo da
garantirne un'adeguata sicurezza e riservatezza, anche per impedire
l'accesso o l'utilizzo non autorizzato dei dati
personali e delle attrezzature impiegate per il trattamento»
Azure Database
• Firewall attivato alla creazione del
database
• By default, nessuno può accedere
• Consigliato configurare l’accesso solo da
IP conosciuti
• Due tipi di autenticazione supportata
• SQL Auth
• Azure Active Directory Auth
• Possibilità di integrare l’AD on premise
SQL Server 2000 (tutte le edizioni)
Azure SQL Database
13

14. 2. Gestisci. Autorizzazioni.
E’ necessario definire una corretta politica di autorizzazione agli oggetti del database in
modo da garantire una separazione dei ruoli.
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.
14

15. 2. Gestisci. Dynamic Data Masking.
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à
SQL Server 2016 (tutte le edizioni)
Azure SQL Database
Il GDPR si riferisce a questo aspetto richiedendo che l’organizzazione attui
«misure tecniche e organizzative adeguate, quali la pseudonimizzazione, volte
ad attuare in modo efficace i principi di protezione dei dati, quali la
minimizzazione…»
15

16. 2. Gestisci. 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.
SQL Server 2016 (tutte le edizioni)
Azure SQL Database
Il GDPR definisce che gli utenti devono avere accesso solo ai dati che sono di
loro pertinenza riducendo così il rischio di «divulgazione non autorizzata o
dall’accesso, in modo accidentale o illegale ai dati personali»
16

17. 3. Proteggi
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 e identificare tempestivamente le fughe di dati.
Proteggere i dati personali dalle minacce in termini di sicurezza è uno dei
principi fondamentali del GDPR che richiede che le organizzazioni
implementino la «Protezione dei dati fin dalla progettazione e protezione per
impostazione predefinita»
• Transport Layer Security
• Transparent Data Encryption
• Always Encrypted
• Auditing
• SQL Threat Detection
• Business Continuity
17

18. 3. Proteggi. 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
Proteggere il dato durante la sua trasmissione è esplicitamente citato con lo
scopo di evitare possibili «accessi non autorizzati» e minimizzare questo
rischio
SQL Server 2008 (tutte le edizioni)
Azure SQL Database
18

19. 3. Proteggi. 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.
• Attenzione: i dati contenuti nelle tabelle sono ancora in chiaro. Sono i file
del database che vengono cryptati. 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
• Trasparente per le applicazioni, non richiedono modifiche.
• Altre normative privacy e sicurezza, considerano questa funzionalità come
«core requirement»
In questo caso la protezione è a livello fisico e serve a prevenire il rischio di
compromissione dello storage, ad esempio consentendo la copia dei file del
database «…rischi presentati dal trattamento che derivano in particolare dalla
distruzione, dalla perdita, dalla modifica, dalla divulgazione non autorizzata, o
dall’accesso…)
SQL Server 2008 (Enterprise Edition)
Azure SQL Database
19

20. 3. Proteggi. Always Encrypted
• Per alcune tipologie di dato particolarmente sensibili, la encryption a livello di file e di trasporto può
non essere sufficiente. (vedi art. 9)
• E’ 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.
• Separazione tra chi possiede i dati (e li può vedere) e chi li gestisce (e non dovrebbe avere accesso,
es DBA)
• Meccanismo trasparente per le applicazioni, richiede però un driver di accesso ai dati particolare
utilizzato dalle applicazioni.
SQL Server 2016 (tutte le edizioni)
Azure SQL Database
20

21. 3. Proteggi. SQL Threat Detection
• SQL Threat Detection individua attività anomale effettuate sui database che
possono essere interpretate come potenziali minacce alla sicurezza
• Per il momento disponibile solo su Azure SQL Database (SQL Server 2017?)
• Il database administrator viene notificato in modo proattivo di ogni attività
sospetta che potrebbe indicare un accesso ai dati non autorizzato
• Viene analizzato continuamente il pattern di utilizzo «normale» utilizzando
algoritmi di machine learning e metodologie di analisi comportamentale.
Il GDPR ha dei requisiti chiari riguardanti le violazioni dei dati: «In caso di
violazione dei dati personali, il titolare del trattamento notifica la violazione
all'autorità di controllo competente a norma dell'articolo 55 senza ingiustificato
ritardo e, ove possibile, entro 72 ore dal momento in cui ne è
venuto a conoscenza»
Azure SQL Database
Azure SQL Datawarehouse
21

22. 3. Proteggi. Auditing
• Auditing: 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.
• Consente di raccogliere e analizzare informazioni che possono condurre
all’identificazione di pattern anomali di utilizzo, abusi o violazioni del dato
• Grande mole di dati = difficoltà nella lettura ed interpretazione
• Strumenti di terze parti per l’analisi dei log (Netwrix ad esempio)
• Soluzioni custom (Microsoft Consulting Services Audit Project)
Il GDPR richiede espressamente che «Ogni titolare del trattamento e, ove
applicabile, il suo rappresentante tengono un registro delle attività di
trattamento svolte sotto la propria responsabilità»
SQL Server 2008
Azure SQL Database
22

23. 3. Proteggi. Business Continuity
Dobbiamo preoccuparci di assicurare la resilienza e la disponibilità del dato nel
caso di eventi avversi.
Il GDPR si riferisce esplicitamente a questo aspetto richiedendo che
l’organizzazione «implementi misure tecniche ed organizzative appropriate» e
nello specifico «la capacità di ripristinare tempestivamente la disponibilità e
l'accesso dei dati personali in caso di incidente fisico o tecnico»
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)
SQL Server 2012
Azure SQL Database
23

24. 4. Controlla e documenta
La fase finale del processo per raggiungere e mantenere la compliance con il GDPR
prevede di:
• Documentare in modo significativo e 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.
Valutazione d’impatto sulla protezione dei dati. E’ richiesto dal GDPR un assessment
dell’impatto dell’operatività riguardo la protezione dei dati personali. Questo include
«le misure previste per affrontare i rischi, includendo le garanzie, le misure di
sicurezza e i meccanismi per garantire la protezione dei dati personali e dimostrare
la conformità al presente regolamento»
24

25. 4. Controlla e documenta. 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).
25

26. Alcuni aspetti da non sottovalutare
Diritto all’oblio
Sembra semplice… eliminiamo i dati della persona dal database. Ma…non è sufficiente.
Questo 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
cit «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(rà) 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
li utilizziamo…
26

27. Il datawarehouse e la business intelligence
• Difficilmente, nei sistemi di analisi del dato abbiamo bisogno di informazioni puntuali
relative alla persona (nome, cognome, CF,…). 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? Prestare attenzione…
Clienti Ordini Vendite
Sistemi gestionali
Clienti
CRM
Sistemi analitici
Datawarehouse
Masking
dell’informazione
Masking e Unmasking
dell’informazione
27
• Possiamo utilizzare tecniche per filtrare
(quando possibile) le informazioni
• Black list
• Flagging
• In un datawarehouse sulle vendite non
posso applicare filtri a priori
• Oppure tecniche per il mascheramento
• Spesso dobbiamo ritornare queste
informazioni ad altri sistemi (es.
segmentazioni di mercato -> CRM)

28. Grazie!
cristiano.gasparotto@datamaze.it
www.datamaze.it
28
Riferimenti
• Beginning your General Data Protection Regulation (GDPR) Journey (https://aka.ms/GDPRJourneyWhitepaper)
• SQL and GDPR whitepaper (https://aka.ms/gdprsqlwhitepaper)
• GDPR Portal (http://www.eugdpr.org/)