Andy's Weblog

Gli obblighi per gli Amministratori di Sistema: una proposta concreta dopo tanta teoria giovedì 4 giugno 2009

Riprendo il discorso sul tema del provvedimento del Garante 27/11/2008 sulle Misure e accorgimenti relativamente alle attribuzioni delle funzioni di amministratore di sistema.

Il Garante ha fatto della teoria; si è quindi reso conto di avere creato un mostro che non sa gestire, ed ha fatto ricorso alla consultazione pubblica (che avrebbe dovuto essere stata fatta prima, e non dopo), da cui speriamo si arrivi a qualcosa di concreto e di realistico.

I propositi sono buoni, ma la generalità della cosa ha reso di fatto inutile ai fini pratici la nuova norma.

L’auditing sull’accesso ai dati sensibili (di fatto, è di questo che si parla) si può fare in vari modi, e soprattutto con vari livelli di profondità.

Le esigenze di una Telecom, di un ISP e di un’azienda che fabbrica bulloni sono completamente differenti.

E cosa è che fa la differenza? Il rischio.
Riuscire ad accedere ai database di una Telecom o dellla Sanità, o del Ministero della Giustizia, comporta rischi incredibilmente più elevati che riuscire ad accedere al database dei dipendenti dell’impresa a conduzione familiare che produce bulloni nel garage sottocasa.

In aggiunta, la protezione dei dati ha un costo, in particolare in materia di competenze.

Ciò che avrebbe dovuto fare il Garante è di stabilire una griglia, in cui tenere conto della quantità e della qualità dei dati gestiti.

La qualità è ovviamente un fattore fondamentale: i dati giudiziari o sanitari, piuttosto che quelli finanziari, comportano intrinsecamente più rischi che i puri dati anagrafici.

Altro fattore fondamentale è la quantità: una cosa è gestire un database dei 5 o 10 nominativi dei dipendenti dell’azienda, un’altra è gestire database che contengono milioni di anagrafiche, e magari per ciascuna anche il tracciato telefonico e l’identificazione delle celle che hanno servito le telefonate.

In sintesi, il Garante avrebbe potuto stabilire dei requisiti minimi in termini di:
– certificazioni di sicurezza dell’azienda, e dei suoi eventuali subfornitori;
– professionalità degli amministratori (certificazioni personali, etc.)
– integerrimità del personale responsabile;
– quantità e dettaglio dei log di auditing, in relazione ai dati gestiti;
– elenco minimo delle informazioni da auditare;
– modalità e durata della conservazione dei log (personalmente, li farei criptare con la chiave pubblica di un certificato della Magistratura);

Forse c’è anche altro, ma l’elenco di cui sopra serve già a dare un’idea di cosa intendo significare.

Faccio invece una digressione sulla criptazione dei supporti su cui vengono conservati i log.
Nel caso la cosa non fosse chiara a tutti, la disposizione del Garante, così com’è, mi risulta essere sostanzialmente inutile.
Oltre al fatto che in generale i log possono essere ‘epurati’ prima di essere trasferiti su un supporto non riscrivibile (a meno di soluzioni non banali), essi possono essere modificati anche dopo: è sufficiente scaricare il contenuto del supporto, modificare il contenuto dei log, e ri-masterizzare il tutto su un nuovo supporto, da sostituire all’originale.

In sostanza, i log devono come minimo essere accompagnati da una marca temporale certa, che ne garantisca l’immutabilità.
Visto poi che tali log sono necessari, di fatto, soltanto in caso di indagini della Magistratura, se questi fossero criptati con la chiave pubblica di un certificato della stessa, tali log non potrebbero essere aperti se non in caso di indagine.

In questo modo si preserva la privacy di tutti (anche degli amministratori di sistema), non si fa telecontrollo, ed i log stessi non possono divenire interessanti per compiere un furto (per fare un esempio, ad un malintenzionato i log della Telecom di turno possono raccontare molte cose sull’architettura dei sistemi e dei servizi).