L’ultimo provvedimento di giugno del Garante della Privacy sugli Amministratori di Sistema (d’ora in poi AdS) e prima ancora le FAQ hanno chiarito meglio cosa si intende per “Registrazione degli accessi”. Ma questa nuova consapevolezza in realtà nasconde delle problematiche tecniche tutt’altro che risolte…

Il provvedimento originario del 27 Novembre 2008 del Garante della Privacy al punto f) indicava l’obbligo di adozione di sistemi idonei alla registrazione degli accessi logici da parte degli AdS, richiedendo che le registrazioni avessero caratteristiche di completezza, inalterabilità e possibilità di verifica della loro integrità e fossero conservate per almeno 6 mesi. Questa richiesta aveva sollevato molti dubbi, legati alla definizione di accessi logici: accessi a cosa? Ai sistemi, alle applicazioni, agli specifici files…? La FAQ 9 pubblicata successivamente ha poi chiarito che per access log era da intendersi la registrazione degli eventi di login, logout, errore, ecc nelle fasi di connessione a sistemi di elaborazione o a sistemi software. In più, la FAQ 15 ha specificato che non era richiesto il tracciamento delle attività degli AdS, proprio perché la finalità di tali registrazioni era quella di eventualmente verificare anomalie nella frequenza degli accessi e nelle loro modalità (FAQ 16). In pratica, l’obiettivo è quello di circoscrivere le attività degli AdS in ambiti operativi leciti.

La FAQ 12 viene incontro al 95% degli AdS, spiegando che il requisito dell’inalterabilità dei log può essere ragionevolmente soddisfatto con la strumentazione software in dotazione: significa che, per coloro che gestiscono la loro rete tramite un dominio Microsoft, il tracciamento degli accessi effettuato con gli Event Viewer dei server di dominio è sufficiente (sempre che non ci siano dati personali residenti in server fuori dominio…). A questo punto, per soddisfare gli adempimenti di legge basta trovare il modo di esportare questi log per evitare che vengano sovrascritti prima di 6 mesi: la modalità in cui sono criptati dal sistema operativo garantisce in maniera ragionevole il requisito dell’inalterabilità.

Per il mondo open source la cosa è leggermente più complessa: per garantire il rispetto degli obblighi di legge occorrerebbe fare in modo di rendere i log inalterabili. Questo si può fare masterizzandoli, come indicato nella FAQ 12. In realtà è un palliativo, poiché i log di Linux sono dei file di testo editabili senza troppa difficoltà: se un AdS vuole modificarli basta che ne tenga una copia, apporti le modifiche desiderate, porti indietro l’orologio di sistema e masterizzi il file modificato (facendo “sparire” quello originale). Una soluzione più robusta è quella di apporre ai files di log una marca temporale, ma questa soluzione ha dei costi in termini di tempo e di denaro.

Un problema da molti sottovalutato è l’accesso alle banche dati: la FAQ 19 specifica che “…Tra gli accessi logici a sistemi e archivi elettronici sono comprese le autenticazioni nei confronti dei data base management systems (DBMS), che vanno registrate”. Questo significa che, per quelle banche dati dove è consentito un accesso diretto al DB (per esempio tramite una console per Data Base Administrator), occorre tracciare gli access log. Qui l’approccio ha difficoltà differenti a seconda del DB utilizzato. Per la versione enterprise dei database proprietari (es. Oracle e MS SQL server) i log di accesso sono all’interno del DB, hanno un sistema di criptazione simile a quello dei log di Windows e non vengono mai sovrascritti (salvo interventi “mirati”). Quindi, ogni volta che si effettua il (necessario!) backup del DB tramite un dump vengono salvati anche i log.
Diverso è il discorso per le versioni “Express” di questi DB proprietari, per cui la gestione dei log è organizzata diversamente. Occorrerebbe valutare caso per caso.
Infine, nei database che hanno un certo successo negli ambienti open source (es. Mysql e Firebird) i log di sistema sono anch’essi dei files di testo, come nei corrispondenti sistemi operativi, per cui si presentano le medesime problematiche. Dulcis in fundo, affrontare il problema della gestione dei DB access è come scoperchiare il vaso di Pandora.

Comunque il problema più grosso, nel campo dei database, è di carattere culturale: spesso vengono creati degli utenti fittizi che fanno capo alle applicazioni che li utilizzano. I loro manutentori, quando intervengono, utilizzano questi profili utente impersonali ed anonimi che vanno contro le indicazioni del Garante (no, non il provvedimento del novembre 2008, bensì le misure minime di sicurezza contenute nel D.Lgs. 196/2003!). Questo perché in molti casi l’applicativo è stato realizzato da programmatori che hanno buone conoscenze applicative ma una scarsa conoscenza di database administration, per cui vengono tralasciati gli accorgimenti tipici dei DBA.

Ne è la riprova un altro malcostume molto diffuso: molte delle banche dati (NB non tutte!) su cui poggiano gli applicativi utilizzati quotidianamente hanno ancora le default password degli utenti amministratori. Basti pensare all’utente SYSDBA (password “masterkey”) di Interbase o all’utente system (password “sys”) per Oracle RDBMS; SQL server ha l’utente sa, mentre Mysql ha l’utente root entrambi inizialmente senza password (per una panoramica della password di default è possibile cliccare qui).

Concludendo, mentre per i sistemi operativi proprietari la gestione degli adempimenti legati agli AdS è piuttosto snella, nel mondo open source la situazione non è sempre così chiara; anche nell’ambito della gestione degli accessi ai database i punti oscuri sono ancora parecchi, sia per motivazioni di carattere oggettivamente tecnico che soggettivamente culturale.

Per gli altri aspetti, potrebbe essere interessante leggere anche l’articolo “Amministratori di Sistema in outsourcing – le modifiche del Garante”

Per altre questioni riguardanti la protezione dei dati personali è possibile consultare il nostro forum sull’argomento o scrivere a formazione@blog.sinetinformatica.it