Home > SQL Server e la legge sulla Privacy

SQL Server e la legge sulla Privacy

Introduzione e finalità dell’articolo

E’ bene sottolinearlo subito: la legge sulla privacy ([1]) deve essere interpretata, e come tale ogni interpretazione può essere fatta in modo più o meno stringente. La finalità del presente articolo non vuole essere quella di capire come interpretare e quindi implementare tale legge, ma semplicemente una descrizione di tutte le soluzioni native di SQL Server che vi permettono di adempiere alla stessa. Il "livello", sulla base dell’interpretazione che volete dare alla normativa, ed alla quale vorrete pertanto adeguarvi, sarà una decisione unicamente vostra, per la quale nè UGISS nè l’autore dell’articolo possono essere ritenuti responsabili.

Per limitare lo scopo dell’analisi, l’articolo si concentrerà sulle problematiche legate alle misure prescritte per gli amministratori di sistema, dato che la normativa si occupa nello specifico della protezione dei dati personali da parte di chi, per il ruolo che ricopre, potrebbe accedervi senza alcuna limitazione, e che quindi deve essere regolamentato in maniera specifica. Tale documento rappresenta, inoltre, la maggior incombenza per ogni società che tratta dati personali di clienti, fornitori e/o dipendenti, e che fa uso di server o di computer in azienda, dato che in questi casi, c’è sicuramente la figura di "amministratore di sistema" che, in possesso della password amministrativa, può potenzialmente accedere ai dati di chiunque. In altre parole, tale documento è di interesse per tutte le aziende, dato che credo sia difficile oggiogiorno trovare un’azienda che al suo interno non faccia uso di sistemi informatici.

Per quanto detto, come punto di partenza dell’analisi, utilizzeremo il documento 

Misure e accorgimenti prescritti ai titolari dei trattamenti effettuati con strumenti elettronici relativamente alle attribuzioni delle funzioni di amministratore di sistema – 27 novembre 2008

 
Dove, alla sezione FAQ
 
 
è possibile trovare risposte alle domande più comuni, ed anche qualche chiarimento utile per definire l’area di applicabilità della legge stessa.

Il presente articolo, ovviamente, si limiterà alla trattazione degli argomenti declinati nell’ambito dell’applicabilità su SQL Server (versione 2000 o superiore).

 
Definizione di "Dati Personali", "Dati Identificativi", "Dati Sensibili", "Dati Giudiziari"
 
Secondo il Decreto legislativo 30 giugno 2003, n. 196 [7]:

"dato personale", qualunque informazione relativa a persona fisica, persona giuridica, ente od

associazione, identificati o identificabili, anche indirettamente, mediante riferimento a qualsiasi altra
informazione, ivi compreso un numero di identificazione personale;
 
"dati identificativi", i dati personali che permettono l’identificazione diretta dell’interessato;

Garante Privacy Page 2 of 58
 
"dati sensibili", i dati personali idonei a rivelare l’origine razziale ed etnica, le convinzioni religiose,

filosofiche o di altro genere, le opinioni politiche, l’adesione a partiti, sindacati, associazioni od organizzazioni
a carattere religioso, filosofico, politico o sindacale, nonché i dati personali idonei a rivelare lo stato di salute
e la vita sessuale;
 
"dati giudiziari", i dati personali idonei a rivelare provvedimenti di cui all’articolo 3, comma 1, lettere da
a) a o) e da r) a u), del d.P.R. 14 novembre 2002, n. 313, in materia di casellario giudiziale, di anagrafe
delle sanzioni amministrative dipendenti da reato e dei relativi carichi pendenti, o la qualità di imputato o di
indagato ai sensi degli articoli 60 e 61 del codice di procedura penale;
 
Legge sulla Privacy e SQL Server 

Le FAQ del documento specifico ([5] punto 1) per gli amministratori di sistema, definiscono tale figura come

l’amministratore di sistema è assunto quale figura professionale dedicata alla gestione e alla manutenzione di impianti di elaborazione con cui vengano effettuati trattamenti di dati personali, compresi i sistemi di gestione delle basi di dati

Questa definizione identifica senza alcun dubbio tutte le persone il cui account è inserito nel server role "sysadmin", dato che hanno accesso illimitato a tutte le risorse di SQL Server. Dato che un’istanza di SQL Server può contere più database e che un account può non essere amministratore di SQL Server ma essere comunque definito come amministratore di determinati database, semplicemente inserendo tale account nel database role "db_owner" (con accesso illimitato alle risorse dello specifico dabatase in cui è "db_owner"), è bene sottolineare che, nel caso di un’interpretazione stringente della legge, tali account possono essere equiparati agli amministratori di sistema stessi.

In base a quanto detto, si deve quindi applicare il punto 4.5 della legge [4], che prevede la

registrazione degli accessi logici (autenticazione informatica) ai sistemi di elaborazione e agli archivi elettronici da parte degli amministratori di sistema. Le registrazioni (access log) devono avere caratteristiche di completezza, inalterabilità e possibilità di verifica della loro integrità adeguate al raggiungimento dello scopo di verifica per cui sono richieste.Le registrazioni devono comprendere i riferimenti temporali e la descrizione dell’evento che le ha generate e devono essere conservate per un congruo periodo, non inferiore a sei mesi.

E’ chiaro che, sulla base dell’interpretazione più o meno restrittiva, si posso avere scenari molto diversi. Nel caso più semplice potrebbe essere sufficiente assicurarsi di avere un log degli accessi (login e logout) a SQL Server da parte degli amministratori di sistema, nel caso più restrittivo, la registrazione degli accessi ai singoli dati. 

 
Applicazione della normativa – Gli account
 
La normativa, al punto 5 del [6], definisce che, per ogni account:
La parola chiave, quando è prevista dal sistema di autenticazione, è composta da almeno otto caratteri oppure, nel caso in cui lo strumento elettronico non lo permetta, da un numero di caratteri pari al massimo consentito; essa non contiene riferimenti agevolmente riconducibili all’incaricato ed è modificata da quest’ultimo al primo utilizzo e, successivamente, almeno ogni sei mesi. In caso di trattamento di dati sensibili e di dati giudiziari la parola chiave è modificata almeno ogni tre mesi.
Per quanto riguarda gli account basati sulla Windows Authentication, il problema non si pone in quanto il tutto è gestito a livello di macchina (nel caso di server stand-alone) o di dominio. Non c’è quindi nessun problema nè per SQL Server 2000 nè per tutte le versioni successive.
 
Se invece si utilizzano anche account basati sulla SQL Authentication, allora il problema deve essere risolto usando SQL Server.
 
SQL Server 2000
Con SQL Server 2000 NON E’ POSSIBILE assicurare in modo automatico l’applicazione di tale regolamentazione, dato che non c’è modo di forzare l’utente a modificare la propria password al primo utilizzo ne, successivamente, di obbligarlo all’utilizzo di una password della complessità richiesta. Non è inoltre possibile impostare la scandenza della stessa.
 
Tutti coloro che stanno usando SQL Server 2000, quindi hanno solo un modo per poter ottemperare a questa norma: utilizzare esclusivamente l’autenticazione di Windows, disabilitare la SQL Authentication e configurare correttamente la gestione degli account a livello di server o – meglio – di dominio.
 
Considerando anche che ormai SQL Server 2000 è un prodotto al termine del suo ciclo di vita, è fortemente consigliabile l’aggiornamento a SQL Server 2005 o successivi.
 
SQL Server 2005 o successivi
Dalla versione 2005 di SQL Server è possibile richiedere che la password abbia una complessità adeguata, impostarne la scadenza ed obbligare l’utente a cambiarla al primo accesso, sia per gli account di Windows sia per gli account di SQL Server.
Tale funzionalità è disponibile solamente se il sistema operativo sulla quale è installato SQL Server è Windows Server 2003 o successivo:
 
Password Policy
 
Strong Passwords
 
Da questo punto di vista, una volta configurate correttamente tale impostazioni, SQL Server 2005 o successivo risulta completamente aderente a questa parte della normativa.
 
 
Applicazione della normativa – Registrazione degli accessi
 
Come già riportato nel paragrafo introduttivo, la normativa prevede la "registrazione degli accessi logici" (punto 4.5 della legge [4]) effettuati da parte degli amministratori di sistema. La normativa fa riferimento ad un access-log, la cui definizione è, secondo quanto, riportato nel documento [5]:

Per access log si intende la registrazione degli eventi generati dal sistema di autenticazione informatica all’atto dell’accesso o tentativo di accesso da parte di un amministratore di sistema o all’atto della sua disconnessione nell’ambito di collegamenti interattivi a sistemi di elaborazione o a sistemi software.

Nel caso di una interpretazione poco stringente, è sufficiente loggare tutte le operazioni di login e di logoff fatte a SQL Server. Ciò è possibile sin dalla versione 2000 di SQL Server, abilitando l’opzione di loggare tutti gli eventi di logon e logoff tramite l’opzione "C2 Level Audit".
 
SQL Server 2000 Auditing
 
Nel caso in cui l’interpretazione, invece, venga fatta in modo più resistrittivo, cosa ci si deve aspettare? Dal punto di vista legislativo è importante tenere traccia solo degli accessi, non delle operazioni effettuate (vedi FAQ 15 del documento [5]):

Il provvedimento non chiede in alcun modo che vengano registrati dati sull’attività interattiva (comandi impartiti, transazioni effettuate) degli amministratori di sistema. 

Una interpretazione più restrittiva, quindi, è quella che prevede di dover loggare gli accessi di amministratori di sistema ad ogni singolo o specifico database e non solamente all’intero server, poichè non tutti i database possono contenere dati sensibili, e non è detto che per il semplice fatto che qualcuno abbia acceduto al server, si possa supporre che lo stesso abbia acceduto o meno anche a tali dati sensibili. E’ inoltre da considerare che un database può contenere più tabelle, di cui solo alcune contenenti dati personali e quindi sensibili alla legge sulla privacy. Registrando il semplice accesso ad un database, non è pertanto possibile sapere se la tabella contenente dati personali è stata acceduta o meno. Il decreto [7],

garantisce che il trattamento dei dati personali si svolga nel rispetto dei diritti e delle libertà fondamentali, nonché della dignità dell’interessato, con particolare riferimento alla riservatezza, all’identità personale e al diritto alla protezione dei dati personali.

Per poter quindi garantire una reale riservatezza e protezione del dato all’interno di un RDBMS, il logging dovrebbe essere fatto a livello di tabella (e/o addirittura a livello di colonna). Oltre a questo, un log dettagliato fino a questo livello sarebbe nell’interesse dell’amministratore di sistema, per poter dimostrare che, pur avendo acceduto al database, non ha acceduto alle tabelle contenenti dati personali. Dato che [5]

La raccolta dei log serve per verificare anomalie nella frequenza degli accessi e nelle loro modalità (orari, durata, sistemi cui si è fatto accesso…). 

E’ sicuramente importante poter fornire evidenza di ciò a cui si è acceduto durante, ad esempio, operazioni di manutenzione straordinaria notturne, che potrebbero altrimenti apparire "sospette" rispetto ad un uso normale del sistema.
 
Riassumento quanto detto nei diversi punti della normativa, non sarebbe quindi necessario tracciare le operazioni fatte sui dati, ma sarebbe sufficiente tracciare l’accesso agli stessi. Chiaramente quest’ultima opzione è la più restrittiva possibile, la cui applicazione ha delle implicazioni non banali in termini infrastrutturali e prestazionali, ma è anche quella che in caso di realtà particolarmente sensibili alla security (banche, assicurazioni, ospedali, ecc. ecc.) appare come la più sensata (rispetto a ciò che la legge si prefigge di ottenere).
 
Definito ciò, procediamo nell’analisi di come, utilizzando SQL Server 2000 o superiori, è possibile adempiere alla normativa.
 
SQL Server 2000
 
Con SQL Server 2000 l’unica possibilità per poter tracciare tutti gli accessi ad un determinato database, tabella od oggetto, è quella di utilizzare il tracing. Volendo è possibile anche pensare di implementare dei trigger su ogni tabella ma questa seconda ipotesi è poco percorribile per tre motivi:
  1. Manutenzione. La creazione di un trigger per tabella è un’operazione non banale dal punto di vista della quantità di lavoro necessario. Eventualmente la si può automatizzare usando un tool di code-generation, ma è comunque un processo lungo e costoso.
  2. Performance. I trigger sono parte della transazione che li manda in esecuzione, e quindi vanno ad impattarne le performance in modo sensibile, soprattutto se pensiamo di avere un’unica tabella di logging dove vengono registrati tutti gli accessi agli altri oggetti; ben presto questa diventerebbe il collo di bottiglia più grosso del nostro sistema, impattando in modo negativo sulle performance di ogni transazione.
  3. Completezza del logging. I trigger non possono in alcun modo intercettare il comando TRUNCATE TABLE.
Abbandonata quindi la strada dei trigger, rimane solamente quella del tracing. Più correttamente definito come Server-Side Tracing, questa funzionalità permette di intercettare tutti i comandi inviati a SQL Server da parte di qualsiasi applicazione. Tale funzionalità, per fare un esempio, è quella utilizzata dal SQL Server Profiler, per intercettare e mostrare i comandi inviati al database server.
 
Il Server-Side Tracing è comandato totalmente da una serie di stored procedure di sistema.
 
sp_trace_setstatus
 
Server-side Tracing
 
Per comodità è possibile configurare cosa loggare tramite l’interfaccia del SQL Server Profiler e quindi farsi generare uno script da mandare in esecuzione su SQL Server senza dover tener aperto il Profiler stesso. Questa possibilità è particolamente importante poichè l’utilizzo del SQL Server Profiler come strumento per intercettare i comandi inviati ha un’impatto non indifferente sulle performance di sistema, mentre invece l’utilizzo diretto del tracing non ha praticamente nessun impatto e può quindi essere utilizzato senza doversi preoccupare eccessivamente di impattare sulle performance (ipotizzando di avere un sistema di I/O adatto a sostenere il traffico su disco cosi generato)
 
Performance Impact: Profiler Tracing vs. Server Side SQL Tracing
 
Per poter loggare tutti i dati necessari per ottemperare alla legge sulla privacy nell’interpretazione più rilassata è necessario loggare gli eventi di "Audit Login", "Audit Logout" disponibili nella sezione "Security Audit" della finestra di configurazione del Profiler. Tali eventi tengono traccia di tutti i login ed i logout fatti su SQL Server. Se si vuole invece ottemperare all’interpretazione più restrittiva è necessario aggiungere anche l’evento "Audit Object Permission Event" (Event Class = 114). Tale evento, tramite il valore della "Permission" permette di sapere che tipo di accesso è stato fatto. I valori possono essere: 
 
1=SELECT ALL
2=UPDATE ALL
4=REFERENCES ALL
8=INSERT
16=DELETE
32=EXECUTE (procedures only)
 
Security Audit Data Columns
 
 
SQL Server 2005

 

Per SQL Server 2005 vale quanto detto per SQL Server 2000. L’unica differenza sta nel nome dell’evento da monitorare. L’Event Class è sempre il valore 114, ma il nome è stato cambiato in "Audit Schema Object Access Event", e si trova sempre nella sezione "Security Audit".
 
Audit Schema Object Access Event Class
 
Con SQL Server 2005 è possibile utilizzare la tecnologia degli Event Notification per intercettare gli eventi suddetti e memorizzarli all’interno del database stesso, sfruttando il Service Broker per
  • rendere asincrona l’operazione, cosi da non inficiare le performance del sistema  
  • eventualmente inviare le informazioni dell’evento ad un SQL Server centrale, preposto proprio alla raccolta di tali dati
 
Event Notifications 
 
Trace Events for Use with Event Notifications
 
Questa seconda opzione è più complessa – da un punto di vista implementativo – della prima, basata sul Server-Side Tracing, ma permette una flessibilità molto più elevata nel controllo dei dati di auditing e nella loro fruizione. Permette inoltre di automatizzare completamente il raccoglimento, l’elaborazione ed il consolidamente dei dati, in modo centralizzato e quindi più facilmente gestibile.
 
 
SQL Server 2008
 
SQL Server 2008, oltre a supportare tutte le soluzioni presentate per SQL Server 2000 e 2005, permette anche di utilizzare una nuova feature pensata appositamente per risolvere le problematiche. Tale feature si chiama, propriamente, SQL Server Audit:
 
Understanding SQL Server Audit
 
Questa tecnologia permette di specificare cosa si vuole monitorare sia a livello di server (Server Audit Specification) sia a livello di database (Database Audit Specification), permettendo quindi di implementare una soluzione in grado di soddisfare tutti i livelli di interpretazione che si possono dare alla legge.
 
 
Esempi di Implementazione dell’auditing con SQL Server
 
Esempi pratici di come poter implementare meccanismi di auditing si trovano qui:
 
Meccanismi di Auditing (SQL Server 2000 e 2005)

 

Meccanismi di Auditing con SQL Server 2005 e 2008 – Slides
 
Meccanismi di Auditing con SQL Server 2005 e 2008 – Demo
  

Applicazione della normativa – Consultazione degli accessi
Le informazioni recuperate loggando gli accessi al sistema, devono poter essere consultabili, come previsto della normativa (FAQ 5 e 16 del documento [5]). Nel caso dell’utilizzo di Server-Side Traces, è possibile accedere al contenuto dei file utilizzando il SQL Server Profiler. Per rendere più semplice la consultazione degli stessi è però consigliabile spostare i dati presenti in tali file in un database preposto per lo scopo.   

HOW TO: Programmatically Load Trace Files into Tables 
http://support.microsoft.com/kb/270599 

Posso importare un file di traccia del Profiler in una tabella SQL?
 
Se si è fatto uso di Event Notification, i dati sono già memorizzati in un database, e quindi la loro consultazione è immediata.
 
Nel caso di utillizo di SQL Server Audit, è possibile anche in questo caso accedere direttamente ai log,
 
How to: View an Audit Log
 
oppure caricare gli stessi in un database:
 
fn_get_audit_file
 
 
Applicazione della normativa – Conservazione ed Inalterabilità dei log
Per quanto riguarda l’adempimento della richiesta relativa all’inalterabilità del log, Il documento [5], alla FAQ 12, è sufficientemente chiaro:

Il requisito può essere ragionevolmente soddisfatto con la strumentazione software in dotazione, nei casi più semplici, e con l’eventuale esportazione periodica dei dati di log su supporti di memorizzazione non riscrivibili. 

La conservazione dei log, secondo quanto riportato dal documento [4] deve essere non inferiore a sei mesi.
 
 
Scadenze
Ricordo che l’applicazione della normativa, alla data attuale di pubblicazione dell’articolo, ha come scadenza il 15 Dicembre 2009 [8]:

RITENUTA, altresì, la necessità di prorogare i termini previsti per l’adempimento delle prescrizioni, disponendo che tutti i titolari del trattamento (qualunque sia la data di inizio dei trattamenti che li riguardano) adottino le misure e gli accorgimenti di cui al punto 2 del dispositivo del Provvedimento, come modificato e integrato dal presente provvedimento, entro il 15 dicembre 2009;

 
Conclusioni
L’applicazione della normativa sulla Privacy, come visibile, può essere molto semplice o molto complessa, in base all’interpretazione che si vuole dare alla legge. L’articolo ha mostrato come poter utilizzare SQL Server per essere aderenti alla normativa, lasciando al lettore la decisione sul grado di interpretazione da dare alla stessa. 
Nel caso si trattasero dati sensibili o giudiziari, è fortemente consigliabile leggere con attenzione quanto definito dalla normativa, in quanto la trattazione di tali dati richiede misure di sicurezza particolari.
 

Referenze

[1] Wikipedia – Legge sulla Privacy – http://it.wikipedia.org/wiki/Legge_sulla_privacy

[2] Sito Web Garante Privacyhttp://www.garanteprivacy.it
[4] Misure e accorgimenti prescritti ai titolari dei trattamenti effettuati con strumenti elettronici relativamente alle attribuzioni delle funzioni di amministratore di sistema – 27 novembre 2008 – http://www.garanteprivacy.it/garante/doc.jsp?ID=1577499
[5] FAQ – Misure e accorgimenti prescritti ai titolari dei trattamenti effettuati con strumenti elettronici relativamente alle attribuzioni delle funzioni di amministratore di sistema – 27 novembre 2008 – http://www.garanteprivacy.it/garante/doc.jsp?ID=1577499#FAQ
[6] Disciplinare tecnico in materia di misure minime di sicurezza –http://www.garanteprivacy.it/garante/doc.jsp?ID=1557184
[7] Decreto legislativo 30 giugno 2003, n. 196http://www.garanteprivacy.it/garante/doc.jsp?ID=1311248
[8] Modifiche del provvedimento del 27 novembre 2008 (25 giugno 2009) – http://www.garanteprivacy.it/garante/doc.jsp?ID=1626595

 

 

Chi è Davide Mauri

Microsoft Data Platform MVP dal 2007, Davide Mauri si occupa di Data Architecture e Big Data nel mondo dell'IoT. Attualmente ricopre il ruolo di "Director Software Development & Cloud Infrastructure" in Sensoria, societa specializzata nella creazione di Wearables e sensori per l'IoT applicati a tessuti ed oggetti sportivi.

Leggi Anche

Azure Key Vault e certificati code-signing: Strategie per la conformità post 1° Giugno 2023!

In questi giorni, ho avuto l’opportunità di esplorare il rinnovo di un certificato di code-signing …