jump to navigation

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

Posted by andy in Internet e società, privacy, tecnologia.
Tags: , , , ,
add a comment

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

i principali problemi nel provvedimento del Garante per gli AdS lunedì 18 maggio 2009

Posted by andy in privacy, tecnologia.
Tags: , , , , , ,
add a comment

Con riferimento al provvedimento del Garante 27/11/2008 – Misure e accorgimenti relativamente alle attribuzioni delle funzioni di amministratore di sistema, mi sono trovato ad affrontare, come tanti, il problema.

Ho letto molti pareri, ma ritengo le che problematiche principali siano relativamente poche.

In sintesi, i problemi di fondo che devono, a parer mio, essere affrontati e sviscerati, sono tre:

  1. chiarire quali siano lo scopo e le modalità minime per gestire appropriatamente i log di sistema;
  2. chiarire quali siano le responsabilità ed i requisiti minimi per gli amministratori di sistema;
  3. proporzionare i requisiti alle caratteristiche de trattamenti effettuati.

Scopo e Modalità
In merito al punto 1. direi che lo scopo è evidentemente quello di impedire a chicchessia di eseguire sui dati qualsiasi tipo di operazione senza che questa possa essergli ricondotta.
In questo senso, non deve essere possibile ad alcuno accedere ai dati con credenziali non proprie, o effettuare operazioni sui profili di altri utenti per poter acquisire, anche temporaneamente, il loro profilo, per poter effettuare operazioni sui dati, senza che queste vengano registrate.
Ovviamente, l’amministratore di sistema non deve in nessun modo poter accedere e modificare i log al fine di far scomparire tracce e prove delle proprie azioni.
I meccanismi esistono, ma la loro descrizione esula dallo scopo di questa mia mail.

Altro aspetto fondamentale che dovrebbe essere sviscerato riguarda come garantire l’autenticità dei log registrati su supporto non riscrivibile.
In effetti, il fatto che un dato sia memorizzato su un supporto non riscrivibile, non ne garantisce l’originalità né l’autenticità.
A titolo di esempio, è possibile prendere un supporto su cui siano registrati i log, trasferirli su un sistema, modificarli, e memorizzarli su un nuovo supporto non riscrivibile, da sostituire al primo.

Occorre evidentemente che il contenuto del supporto sia firmato digitalmente, con data certa.

Responsabilità
L’amministratore di sistema viene caricato di pesanti responsabilità.
Mentre un ADS di grandi società è sicuramente selezionato sulla base della propria professionalità, ed è certamente conscio dell’entità dei problemi che si trova ad affrontare e gestire, la stragrande maggioranza di società non può permettersi simili professionisti: l’amministrazione di sistema è spesso un’attività fai-da-te, o viene girata a giovani inesperti, spesso con contratti temporanei.
Non è assolutamente accettabile che vengano scaricate su figure di questo tipo responsabilità che sono, di fatto, dell’azienda.

Di fatto, occorre che il Garante definisca quali sono i requisiti minimi di professionalità da richiedere all’ADS, e di come il costo di questa professionalità possa essere relazionata alle disponibilità finanziare dell’azienda.

Proporzionalità dei Requisiti
Come si diceva poc’anzi, nella stragrande maggioranza dei casi molto probabilmente l’azienda non è in grado di gestire, pur con tutta la buona volontà, il problema posto dal Garante.
In sostanza, alle aziende medio-piccole non occorrono prescrizioni teoriche, ma indicazioni pratiche.
Quello che potrebbe fare il Garante, con il CNIPA, è di predisporre le necessarie indicazioni (o meglio ancora, gli strumenti software) tali che, se appropriatamente adottati, possano mettere in condizioni le aziende di rispettare la legge senza dover dedicare una non indifferente fetta del proprio bilancio ad avvocati e consulenti esterni.

In questo senso risulta tuttavia fondamentale definire bene quali siano le discriminanti.
Un azienda, anche molto piccola in termini di persone, che tuttavia non utilizzi l’informatica come puro mezzo accessorio alle attività del proprio core business, non potrà limitarsi ad implementare criteri minimi di sicurezza.

Esistono sicuramente altri aspetti rilevanti, ma ritengo che in generale ciò che dovrebbe essere fatto da parte del Garante non sia semplicemente il fornire norme, ma indicazioni pratiche e strumenti facilmente calabili nella realtà delle aziende.
Il CNIPA potrebbe essere e fornire un valido aiuto in questo senso.