Chiarimenti in merito al provvedimento su Amministratori di Sistema

Mancano pochi giorni alla scadenza degli adempimenti contenuti nel  provvedimento del 27 novembre 2008 del Garante per la Privacy (pubblicato sulla G.U. n. 300 del 24 dicembre 2008) che fa obbligo a tutte le aziende di mettere in atto una serie di misure per ottenere un maggiore controllo degli amministratori di sistema. La scadenza, inizialmente prevista per il 24 aprile 2009, è stata prorogata al 30 giugno 2009.

Il Garante ha pubblicato di recente alcuni chiarimenti al provvedimento sotto forma di risposte a FAQ (Frequently Asked Questions) che riproduciamo di seguito:

1) Cosa deve intendersi per “amministratore di sistema”?
In assenza di definizioni normative e tecniche condivise, nell’ambito del provvedimento del Garante 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, 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.
Il Garante non ha inteso equiparare gli “operatori di sistema” di cui agli articoli del Codice penale relativi ai delitti informatici, con gli “amministratori di sistema”: questi ultimi sono dei particolari operatori di sistema, dotati di specifici privilegi.
Anche il riferimento al d.P.R. 318/1999 nella premessa del provvedimento è puramente descrittivo poiché la figura definita in quell’atto normativo (ormai abrogato) è di minore portata rispetto a quella cui si fa riferimento nel provvedimento.
Non rientrano invece nella definizione quei soggetti che solo occasionalmente intervengono (p.es., per scopi di manutenzione a seguito di guasti o malfunzioni) sui sistemi di elaborazione e sui sistemi software.

2) Cosa vuol dire la locuzione “Qualora l’attività degli ADS riguardi anche indirettamente servizi o sistemi che…”
I titolari sono tenuti a instaurare un regime di conoscibilità dell’identità degli amministratori di sistema, quale forma di trasparenza interna all’organizzazione a tutela dei lavoratori, nel caso in cui un amministratore di sistema, oltre a intervenire sotto il profilo tecnico in generici trattamenti di dati personali in un’organizzazione, tratti anche dati personali riferiti ai lavoratori operanti nell’ambito dell’organizzazione medesima o sia nelle condizioni di acquisire conoscenza di dati a essi riferiti (in questo senso il riferimento nel testo del provvedimento all'”anche indirettamente…”).

3) Il caso di uso esclusivo di un personal computer da parte di un solo amministratore di sistema rientra nell’ambito applicativo del provvedimento?
Non è possibile rispondere in generale. In diversi casi, anche con un personal computer possono essere effettuati delicati trattamenti rispetto ai quali il titolare ha il dovere di prevedere e mettere in atto anche le misure e gli accorgimenti previsti nel provvedimento. Nel caso-limite di un titolare che svolga funzioni di unico amministratore di sistema, come può accadere in piccolissime realtà d’impresa, non si applicheranno le previsioni relative alla verifica delle attività dell’amministratore né la tenuta del log degli accessi informatici.

4) Relativamente all’obbligo di registrazione degli accessi logici degli AdS, sono compresi anche i sistemi client oltre che quelli server?
Si, anche i client, intesi come “postazioni di lavoro informatizzate”, sono compresi tra i sistemi per cui devono essere registrati gli accessi degli AdS.
Nei casi più semplici tale requisito può essere soddisfatto tramite funzionalità già disponibili nei più diffusi sistemi operativi, senza richiedere necessariamente l’uso di strumenti software o hardware aggiuntivi. Per esempio, la registrazione locale dei dati di accesso su una postazione, in determinati contesti, può essere ritenuta idonea al corretto adempimento qualora goda di sufficienti garanzie di integrità.
Sarà comunque con valutazione del titolare che dovrà essere considerata l’idoneità degli strumenti disponibili oppure l’adozione di strumenti più sofisticati, quali la raccolta dei log centralizzata e l’utilizzo di dispositivi non riscrivibili o di tecniche crittografiche per la verifica dell’integrità delle registrazioni.

5) Cosa si intende per operato dell’amministratore di sistema soggetto a controllo almeno annuale?
È da sottoporre a verifica l’attività svolta dall’amministratore di sistema nell’esercizio delle sue funzioni. Va verificato che le attività svolte dall’amministratore di sistema siano conformi alle mansioni attribuite, ivi compreso il profilo relativo alla sicurezza.

6) Chiarire i casi di esclusione dall’obbligo di adempiere al provvedimento.
Sono esclusi i trattamenti effettuati in ambito pubblico e privato a fini amministrativo-contabili che, ponendo minori rischi per gli interessati, sono stati oggetto delle misure di semplificazione introdotte nel corso del 2008 per legge (art. 29 d.l. 25 giugno 2008, n. 112, conv., con mod., con l. 6 agosto 2008, n. 133; art. 34 del Codice; Provv. Garante 27 novembre 2008).

7) Cosa si intende per descrizione analitica degli ambiti di operatività consentiti all’ADS? [Rif. comma 2, lettera d]
Il provvedimento prevede che all’atto della designazione di un amministratore di sistema, venga fatta “elencazione analitica” degli ambiti di operatività consentiti in base al profilo di autorizzazione assegnato, ovvero la descrizione puntuale degli stessi, evitando l’attribuzione di ambiti insufficientemente definiti, analogamente a quanto previsto al comma 4 dell’art. 29 del Codice riguardante i responsabili del trattamento.

8) Oltre alla job description si deve andare più in dettaglio? Si devono indicare i singoli sistemi e le singole operazioni affidate?
No, è sufficiente specificare l’ambito di operatività in termini più generali, per settori o per aree applicative, senza obbligo di specificarlo rispetto a singoli sistemi, a meno che non sia ritenuto necessario in casi specifici.

9) Cosa si intende per access log (log-in, log-out, tentativi falliti di accesso, altro?…) [Rif. comma 2, lettera f]
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.
Gli event records generati dai sistemi di autenticazione contengono usualmente i riferimenti allo “username” utilizzato, alla data e all’ora dell’evento (timestamp), una descrizione dell’evento (sistema di elaborazione o software utilizzato, se si tratti di un evento di log-in, di log-out, o di una condizione di errore, quale linea di comunicazione o dispositivo terminale sia stato utilizzato…).

10) Laddove il file di log contenga informazioni più ampie, va preso tutto il log o solo la riga relativa all’access log? [Rif. comma 2, lettera f]
Qualora il sistema di log adottato generi una raccolta dati più ampia, comunque non in contrasto con le disposizioni del Codice e con i principi della protezione dei dati personali, il requisito del provvedimento è certamente soddisfatto. Comunque è sempre possibile effettuare un’estrazione o un filtraggio dei logfiles al fine di selezionare i soli dati pertinenti agli AdS.

11) Come va interpretata la caratteristica di completezza del log? Si intende che ci devono essere tutte le righe? L’adeguatezza rispetto allo scopo della verifica deve prevedere un’analisi dei rischi?
La caratteristica di completezza è riferita all’insieme degli eventi censiti nel sistema di log, che deve comprendere 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. L’analisi dei rischi aiuta a valutare l’adeguatezza delle misure di sicurezza in genere, e anche delle misure tecniche per garantire attendibilità ai log qui richiesti.

12) Come va interpretata la caratteristica di inalterabilità dei log?
Caratteristiche di mantenimento dell’integrità dei dati raccolti dai sistemi di log sono in genere disponibili nei più diffusi sistemi operativi, o possono esservi agevolmente integrate con apposito software. 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. In casi più complessi i titolari potranno ritenere di adottare sistemi più sofisticati, quali i log server centralizzati e “certificati”.
È 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, prevedendo soltanto, come forma minima di documentazione dell’uso di un sistema informativo, la generazione del 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.

13) Si individuano livelli di robustezza specifici per la garanzia della integrità?
No. La valutazione è lasciata al titolare, in base al contesto operativo (cfr. faq n. 14).

14) Quali potrebbero essere gli scopi di verifica rispetto ai quali valutare l’adeguatezza?
Quelli descritti al paragrafo 4.4 del provvedimento e ribaditi al punto 2, lettera e), del dispositivo. L’adeguatezza è da valutare in rapporto alle condizioni organizzative e operative dell’organizzazione.

15) Cosa dobbiamo intendere per evento che deve essere registrato nel log? Solo l’accesso o anche le attività eseguite?
Il provvedimento non chiede in alcun modo che vengano registrati dati sull’attività interattiva (comandi impartiti, transazioni effettuate) degli amministratori di sistema. Si veda la risposta alla faq n. 11.

16) Quali sono le finalità di audit che ci dobbiamo porre con la registrazione e raccolta di questi log?
La raccolta dei log serve per verificare anomalie nella frequenza degli accessi e nelle loro modalità (orari, durata, sistemi cui si è fatto accesso…). L’analisi dei log può essere compresa tra i criteri di valutazione dell’operato degli amministratori di sistema.

17) Cosa si intende per “consultazione in chiaro”?
Il riferimento in premessa (par. 1 “Considerazioni preliminari”) è alla criticità di mansioni che comportino la potenzialità di violazione del dato personale anche in condizioni in cui ne sia esclusa la conoscibilità, come può avvenire, per esempio, nel caso della cifratura dei dati.

18) Il regime di conoscibilità degli amministratori di sistema è da intendersi per i soli trattamenti inerenti i dati del personale e dei lavoratori?
Si.

19) La registrazione degli accessi è relativa al sistema operativo o anche ai DBMS?
Tra gli accessi logici a sistemi e archivi elettronici sono comprese le autenticazioni nei confronti dei data base management systems (DBMS), che vanno registrate.

20) Nella designazione degli amministratori di sistema occorre valutare i requisiti morali? [Rif. comma 2, lettera a]
No. Il riferimento alle caratteristiche da prendere in considerazione, al comma 2, lettera a), del dispositivo, è all’esperienza, alla capacità e all’affidabilità del soggetto designato. Si tratta quindi di qualità tecniche, professionali e di condotta, non di requisiti morali.

21) Cosa si intende per “estremi identificativi” degli amministratori di sistema?
Si tratta del minimo insieme di dati identificativi utili a individuare il soggetto nell’ambito dell’organizzazione di appartenenza. In molti casi possono coincidere con nome, cognome, funzione o area organizzativa di appartenenza.

22) È corretto affermare che l’accesso a livello applicativo non rientri nel perimetro degli adeguamenti, in quanto l’accesso a una applicazione informatica è regolato tramite profili autorizzativi che disciplinano per tutti gli utenti i trattamenti consentiti sui dati?
Si. L’accesso applicativo non è compreso tra le caratteristiche tipiche dell’amministratore di sistema e quindi non è necessario, in forza del provvedimento del Garante, sottoporlo a registrazione.

23) Si chiede se sia necessario conformarsi al provvedimento nel caso della fornitura di servizi di gestione sistemistica a clienti esteri (housing, hosting, gestione applicativa, archiviazione remota…) da parte di una società italiana non titolare dei dati gestiti.
Il provvedimento si rivolge solo ai titolari di trattamento. I casi esemplificati prefigurano al più una responsabilità di trattamento (secondo il Codice italiano), e sono quindi esclusi dall’ambito applicativo del provvedimento.

24) Si possono ritenere esclusi i trattamenti relativi all’ordinaria attività di supporto delle aziende, che non riguardino dati sensibili, giudiziari o di traffico telefonico/telematico? Ci si riferisce ai trattamenti con strumenti elettronici finalizzati, ad esempio, alla gestione dell’autoparco, alle procedure di acquisto dei materiali di consumo, alla manutenzione degli immobili sociali ecc…).
Tali trattamenti possono considerarsi compresi tra quelli svolti per ordinarie finalità amministrativo-contabili e, come tali, esclusi dall’ambito applicativo del provvedimento.

* Così richiamate dal provvedimento “Amministratori di sistema: avvio di una consultazione pubblica” – 21 aprile 2009

Visita la pagina della consulenza privacy per maggiori informazioni.