Provvedimento sugli amministratori di sistema: i chiarimenti del Garante

Il Garante per la protezione dei dati personali è recentemente ritornato sul tanto discusso provvedimento del 27 novembre scorso relativo agli amministratori di sistema, al fine di discuterne le criticità ed esplicare alcuni termini che, nel complesso generale del Provvedimento, potevano risultare abbastanza oscuri. Per quanto riguarda il primo aspetto, è stata infatti indetta una con un apposito Provvedimento del 21 aprile 2009 una consultazione pubblica sui temi oggetto del Provvedimento del 27 novembre 2008 relativo agli amministratori di sistema.

Relativamente ai chiarimenti su alcuni termini e adempimenti contenuti nel Provvedimento, invece, sono state recentemente diramate dallo stesso Garante alcune FAQ che vogliono meglio precisare il significato o l’ambito applicativo di alcuni punti cruciali. Esse consistono in 24 risposte, delle quali qui si esamineranno le principali, rinviando per ulteriori approfondimenti alla lettura delle FAQ sul sito del Garante.(http://www.garanteprivacy.it/garante/doc.jsp?ID=1577499#FAQ).

La prima domanda cui il Garante vuol fornire risposta, ovviamente, è cosa debba correttamente intendersi come “amministratore di sistema”. A questa interrogativo il Garante risponde che, mancando definizioni normative e tecniche condivise, per l’ambito del Provvedimento in esame tale figura dovrà essere intesa come “[la] 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, i sistemi software complessi quali i sistemi ERP (Enterprise resource planning) utilizzati in grandi aziende e organizzazioni, le reti locali e gli apparati di sicurezza, nella misura in cui consentano di intervenire sui dati personali”, mentre non rientrano in tale definizione tutti quei soggetti che hanno potere d’intervento solo occasionale sui sistemi di elaborazione e sui sistemi software.

Possiamo quindi desumere che il Garante abbia voluto dipanare i dubbi relativi a tutte quelle figure non espressamente votate all’amministrazione dei sistemi ma che, tuttavia, potrebbero saltuariamente svolgere delle funzioni ad essa assimilabili, escludendoli definitivamente dall’ambito di applicazione del Provvedimento. Analogamente, il Garante interviene per correggere un’espressione utilizzata  nella Premessa al Provvedimento e che poteva suonare scorretta, ovvero l’equiparazione dell’amministratore di sistema alle figure di “operatore del sistema” cui spesso il codice penale fa riferimento per la disciplina delle aggravanti negli articoli relativi ai computer crimes.

Nel caso del dettato penalistico, infatti, non ci si vuol riferire esclusivamente ai soggetti che hanno elevati poteri di gestione e di accesso al sistema informatico, bensì a tutti quei soggetti che, disponendo di un legittimo accesso ad un sistema, sfruttino tale qualità per compiere determinati illeciti. Si potrebbe quindi concludere con una frase riassuntiva per cui tutti gli amministratori di sistema saranno necessariamente operatori di sistema secondo le aggravanti del codice penale, ma non tutti gli operatori di sistema per come intesi dal codice penale saranno necessariamente amministratori di sistema.

Buona parte delle FAQ è dedicata, come prevedibile, ai file di log richiesti dal Provvedimento, ossia cosa debba essere inteso come access log, cosa significa che tali log siano “completi” e “inalterabili” e come effettuare la verifica annuale che, si ricorda, grava sul titolare del trattamento. È risaputo, infatti, che l’amministratore di sistema, proprio in virtù degli ampi poteri di cui dispone, potrebbe facilmente eludere qualsiasi controllo o modificare qualsiasi tipo di log, salvo quelli che sfuggono alla sua gestione.

I commentatori del Provvedimento del Garante, quindi, si erano trovati dinanzi ad alcune difficoltà tecniche non insormontabili ma, comunque, abbastanza complesse, in quanto l’unico modo per attuare le prescrizioni del Garante sembrava fosse la strutturazione di una porzione del sistema abilitata a raccogliere i log generati dall’attività dell’amministratore di sistema, sulla quale quest’ultimo non avesse poteri di accesso, e tali poteri fossero riservati solo al titolare del trattamento. Le difficoltà sono evidenti: in primis, la creazione di tali strutture non è cosa di poco conto e in secundis non è assolutamente detto che il titolare del trattamento disponga delle conoscenze tecniche necessarie per poter controllare i log file e verificare, tramite essi, la correttezza dell’operato dell’amministratore di sistema. Si era quindi in una situazione di stallo sintetizzabile nel brocardo latino quis custodiet ipsos custodes, fin quando le FAQ del Garante sono intervenute a portare un po’ di luce sulla questione e a ridimensionare i termini del problema che, forse, erano stati senza motivo esasperati.

Innanzitutto il Garante precisa che per access log bisogna intendere “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”.  Tale spiegazione ci fa capire, innanzitutto, che non sarà necessario  dotarsi di un sistema di logging apposito, potendosi ritenere sufficiente anche quello messo a disposizione da alcuni sistemi operativi già pensati per il networking, e secondariamente che gli elementi presenti in questi log dovranno contenere: 1) lo user ID mediante il quale individuare univocamente l’amministratore di sistema operante in quel momento su quella determinata macchina o software; 2) i riferimenti temporali alla generazione dell’evento (data e ora); 3) una sommaria descrizione dell’evento. Giova sottolineare che alcuni sistemi operativi dispongono già di default di sistemi di logging in grado di fornire questo livello di completezza, ma in ogni caso sono già disponibili soluzioni software in grado di costruire log siffatti o anche più complessi.

Un log, quindi, potrà dirsi “completo” nella misura in cui contenga “tutti gli eventi di accesso interattivo che interessino gli amministratori di sistema su tutti i sistemi di elaborazione con cui vengono trattati, anche indirettamente, dati personali”, laddove gli “eventi di accesso interattivo” dovranno fornire quelle indicazioni sommariamente summenzionate e, peraltro, riferite esclusivamente all’accesso, non dovendosi registrare i dati relativi all’attività interattiva compiuta dall’amministratore di sistema. Un log, inoltre, potrà dirsi “inalterato” qualora vengano usati i normali strumenti di integrità dei dati già disponibili nei sistemi operativi  o eventualmente ottenibili mediante appositi software. Per i casi più semplici, lo stesso Garante dice che può essere sufficiente esportare periodicamente tali log file su supporti di memorizzazione non riscrivibili. Nel caso in cui, invece, per la delicatezza dei dati trattati o per le specifiche caratteristiche del trattamento si renda necessaria una soluzione più efficace, si potrà pensare a una sorta di log server che si preoccupi di collazionare tutti i log e di certificarli con strumenti analoghi a quelli adoperati, ad esempio, per la generazione di un documento firmato digitalmente.

È lo stesso Garante a precisare che “È ben noto che il problema dell’attendibilità dei dati di audit, in genere, riguarda in primo luogo la effettiva generazione degli auditable events e, successivamente, la loro corretta registrazione e manutenzione. Tuttavia il provvedimento del Garante non affronta questi aspetti, prevendendo soltanto, come forma minima di documentazione dell’uso di un sistema informativo, la generazione dei log degli “accessi” (login) e la loro archiviazione per almeno sei mesi in condizioni di ragionevole sicurezza e con strumenti adatti, in base al contesto in cui avviene il trattamento, senza alcuna pretesa di instaurare in modo generalizzato, e solo con le prescrizioni del provvedimento, un regime rigoroso di registrazione degli usage data dei sistemi informativi”.

Viene, infine, chiarita la questione relativa alle “qualità morali” che molti avevano letto come conditio sine qua non per poter correttamente nominare un soggetto amministratore di sistema. Il Garante, infatti, precisa che i richiami alle qualità dell’amministratore di sistema fatte nel Provvedimento riguardano solo le qualità tecniche, professionali e di condotta, e non particolari requisiti morali che debbono essere posseduti da quest’ultimo.

Un ultimo accenno merita l’ambito di applicazione del Provvedimento che, come ribadito dal Garante, riguarda tutte quelle strutture che non possono beneficiare delle semplificazioni in materia di misure di sicurezza previste per quei trattamenti effettuati in ambito pubblico e privato a fini amministrativo-contabili. In buona sostanza, e rinviando nuovamente alla lettura integrale delle FAQ sul sito, possiamo concludere affermando che il Garante ha offerto una rilettura di diversi punti oscuri del Provvedimento, rendendoli non solo più chiari ma, probabilmente, anche più applicabili nelle realtà concrete preposte al trattamento dei dati personali.

Avv. Pierluigi Perri

Foro di Milano

Dottore di ricerca in Informatica giuridica e Diritto dell'informatica Università di Milano