Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

La gestione dei database secondo il GDPR – SQL Server

202 views

Published on

La nuova privacy europea e come adeguarsi entro la scadenza normativa per la gestione dei database Microsoft SQL Server e infrastruttura informative aziendali.

Published in: Internet
  • Be the first to comment

  • Be the first to like this

La gestione dei database secondo il GDPR – SQL Server

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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/)

×