Logging e monitoring delle risorse IT: le disposizioni per dossier e fascicolo sanitario elettronico

La protezione delle informazioni digitali, oggi risorsa cardine per i processi delle organizzazioni (anche manifatturiere), postula procedure di sicurezza articolate su diversi livelli: una delle componenti essenziali per presidiare l’integrità, la disponibilità e la riservatezza dei dati (personali e non) è rappresentata dal processo di logging e monitoring degli accessi e delle attività svolte sui sistemi informativi, aspetto su cui è opportuno richiamare la riflessione in quanto non sempre adeguatamente considerato al di fuori degli ambiti tecnici delle compagini delle organizzazioni.

In questo intervento si intende proporre un’illustrazione degli aspetti principali della materia per poi fare cenno alla situazione afferente a uno dei settori più delicati sotto il profilo dei dati personali, quello della gestione di informazioni particolari quali quelle relative alla salute (dossier e fascicolo sanitario elettronico nella recente versione 2.0).

L’importanza del processo di logging e monitoring

Il logging e monitoring è uno strumento volto al presidio delle risorse IT – tecniche e informative – multistrato: come vedremo ha funzione di sicurezza real time tramite strumenti del tipo IAM (Identity and Access Management), ove connotato da specifici sistemi di alert ed ex-post, per ricostruire eventi tecnici e/o anomali anche a fini di forensic analysis.

Di questa sua centralità occorre quindi avere contezza in quanto fattore abilitante per una gestione dei sistemi informativi efficace, sicura e compliant alle norme di legge (GDPR in primis per quanto attiene ai dati personali) e/o alle previsioni contrattuali e, comunque, alle policy che le organizzazioni si danno in tema di governance dei dati.

Non va tralasciata, comunque, la ulteriore valenza preventiva che la sua (dovuta) pubblicizzazione ai soggetti abilitati all’accesso, interni ed esterni all’organizzazione, può avere in quanto freno ad accessi – anche solo tentati – estemporanei se non illeciti, atteso che la relativa informativa sul logging e monitoring (anche ai sensi del GDPR) renderebbe possibile formulare contestazioni (in ogni caso possibili nel caso di fattispecie penali) ove emergessero nel monitoraggio comportamenti “eccentrici”.

Step applicativi del processo di logging e monitoring

In linea con quanto accennato, il processo in esame è articolabile in diversi step:

1. registrazionedi eventi e attività che possono riguardare sia le attività svolte sulle risorse IT che l’accesso a dati e documenti;
2. monitoraggio continuo dei sistemi informatici per identificare comportamenti anomali o problematici (tramite strumenti appositi, possono essere rilevati pattern sospetti di file di log, attività non autorizzate o altre anomalie;
3. base per l’avvio di analisi di eventi o comportamenti anomali identificati tramite il monitoring.

Una volta definite le policy organizzative in materia di governance delle informazioni e di sicurezza IT (con la consulenza del RPD ove prevista tale figura), il ruolo di primo agente spetta alla Funzione IT che dovrà provvedere al recepimento delle indicazioni formulate dagli owner dei processi organizzativi e applicare le politiche definite in merito alla rilevazione, disamina e conservazione dei log.

Posto che la tassonomia dei log è molto ampia e quelli generati dall’interazione con i sistemi informativi sono soggetti a crescita esponenziale (approssimando big data sull’uso delle risorse e informazioni digitali) al crescere dei volumi di dati e documenti trattati, la definizione di una policy dovrebbe basarsi almeno sulla determinazione di:

1. eventi per i quali prevedere log, in funzione della criticità del sistema e di eventuali requisiti di business o legali;
2. tempi di retention dei file di log;
3. minimizzazione dei dati personali da censire con i log (ai sensi delle norme sulla privacy e dell’art. 4 della legge 300/1970;
4. articolazione del monitoraggio (a campione, con impostazione di alert anche real time, al crescere degli accessi per operatore, in orari eccentrici, per routine automatizzate, ad hoc etc.), cadenza temporale e reporting;
5. modalità di protezione, custodia e accesso ai files di log per evitarne la manipolazione e/o la perdita accidentale e per supportarne la validità giuridica; in argomento il Codice dell’amministrazione digitale D.lgs. 82/2005, oltre a modificare l’art. 2712 del Codice civile prevedendo che anche le riproduzioni informatiche possano formare “piena prova dei fatti e delle cose rappresentate, se colui contro il quale sono prodotte non ne disconosce la conformità ai fatti o alle cose medesime, prevede all’art. 20 che il documento informatico possa essere liberamente valutato a fini probatori in giudizio ”in relazione alle caratteristiche di sicurezza, integrità e immodificabilità”.

Norme e disposizioni in materia

In alcuni casi vi sono specifiche norme che forniscono indicazioni in merito, come nel caso delle disposizioni del Garante privacy sugli amministratori di sistema – esaminate in altro intervento e centrali in quanto tali operatori sono assegnatari di utenze con particolari privilegi – o, come vedremo avanti, del Dossier e del Fascicolo sanitario elettronico, con implicazioni ovviamente dirette in termini di responsabilità per l’organizzazione che non li osservi.

In altri casi, tale determinazione rimane in capo alle organizzazioni e costituisce anche fattore costitutivo della propria accountability.

Un primo riferimento in materia è costituito dalle specifiche indicazioni previste dallo standard internazionale ISO 27001 che definisce i requisiti di un sistema di gestione della sicurezza delle informazioni e fornisce indicazioni in tema di logging e monitoring e dal connesso ISO 27002 incentrato sulla definizione dei controlli).

Logging delle risorse IT: la tassonomia

La complessità del logging si palesa anche solo facendo cenno a una possibile tassonomia dei log:

1. Log di sistema: eventi e attività del sistema operativo, come avvio, arresto, e altre operazioni di sistema. Tali log supportano il monitoraggio e la risoluzione dei problemi tecnici;
2. Log di sicurezza: eventi relativi alla sicurezza, come tentativi di accesso non autorizzati, violazioni della sicurezza e attività sospette. Aiutano a identificare e mitigare le minacce alla sicurezza.
3. Log di applicazione: eventi specifici delle applicazioni, come errori, avvisi e attività dell’applicazione stessa. Possono essere utili anche per attività di debugging e per il monitoraggio delle prestazioni delle applicazioni.
4. Log di accesso: registrazione degli accessi degli utenti al sistema o alle risorse, con diversi livelli di profondità (quali: orario, client utilizzato, mero accesso/uscita, attività svolte dall’utente). Sono utili, se non necessari, per il presidio della regolarità degli accessi e per la conformità alle policy di sicurezza.
5. Log di rete: eventi e attività di rete, come traffico anomalo e tentativi di intrusione. Aiutano a monitorare e proteggere le reti da attacchi informatici.
6. Log di servizi cloud: eventi relativi all’utilizzo di servizi cloud, come accessi alle risorse cloud, attività degli utenti, modifiche di configurazione e avvisi di sicurezza.
7. Log di applicazioni web: informazioni riguardanti le attività e le operazioni di applicazioni web, come richieste HTTP, errori di applicazione, tentativi di accesso non autorizzato e attività degli utenti.
8. Log personalizzati: definiti per registrare eventi specifici in base alle esigenze dell’utente o dell’organizzazione. Ad esempio, log per monitorare attività di business specifiche o metriche di performance personalizzate.

Atteso che la quantità dei log generata dai sistemi, come accennato, è imponente, per gestirli è utile avvalersi di strumenti quali:

1. l’accennato IAM per verificare in modo rapido e preciso l’identità di una persona e permettere che tale utente acceda in linea con le autorizzazioni necessarie per avvalersi della risorsa richiesta, rilevare attività di accesso sospette e segnalare incidenti da verificare;
2. il SIEM (Security Information and Event Management) a fini di monitoraggio e gestione automatizzata degli eventi che accadono all’interno della rete e sui vari sistemi di sicurezza, fornendo una correlazione e aggregazione tra essi. I log sono una fonte centrale di informazioni per un SIEM.

Una questione non secondaria da considerare in tema di logging e monitoring, è quella afferente al rispetto dei principi in materia di trattamento dei dati personali. Al riguardo diverse sono le questioni da considerare:

1. i log tracciano tutte le attività svolte nell’interazione con i sistemi informativi, per quelli attinenti ai dipendenti, pertanto, occorre che siano gestiti nel rispetto sia delle norme sulla privacy sia delle previsioni dell’art. 4 della Lg. 300/1970 (nonché degli artt. 113 e 114 del Codice privacy che a tale legge fanno rimando) onde evitare che possano essere inquadrati come “mezzo di controllo” dell’operato del lavoratore;
2. il logging e monitoring dovrebbe essere reso noto agli interessati mediante una adeguata informativa (in forma specifica o nelle indicazioni per l’accesso ai sistemi) e trovare inoltre – in forma autonoma o nell’ambito di trattamenti afferenti a processi più ampi, ad es. uno generale di sicurezza IT – evidenza nel Registro dei trattamenti;
3. l’organizzazione in quanto titolare del trattamento deve dotarsi di sistemi e procedure di sicurezza a tutela dei dati di log, per garantirne, oltre che la disponibilità, anche integrità e riservatezza sia per compliance al GDPR sia per potersene fondatamente avvalere per la tutela del proprio patrimonio informativo. È infatti necessario che i file di log siano resi inalterabili e adeguatamente protetti, nell’interesse anche dei soggetti loggati (anche eventi patologici inerenti ai file di log possono quindi originare data breach). In assenza di ciò sarebbe indebolito il possibile utilizzo in sede di forensic analysis.
4. definire un congruo periodo di conservazione che sia tarato alle finalità definite e non eccedentari avendo cura, al termine del periodo di conservazione previsto, di procedere alla cancellazione di tali log, quali che siano le modalità di gestione (supporti logici e/o fisici).

Regole applicative a dossier e fascicolo sanitario elettronico

Uno degli ambiti in cui specifiche disposizioni prevedono una articolata attività di logging e monitoring è quello delle informazioni sullo stato di salute che alimentano i cd. Dossier e Fascicolo sanitario.

Il primo, il Dossier è afferente all’insieme dei dati personali generati da eventi clinici presenti e trascorsi riguardanti l’interessato, presso un organismo sanitario in qualità di unico titolare del trattamento, messi in condivisione dai professionisti sanitari che lo assistono, al fine di documentarne la storia clinica e di offrirgli un migliore processo di cura.

Con riguardo ai più recenti interventi, nel 2015 il Garante privacy nell’allegato A alle Linee guida in materia di Dossier sanitario ha fra l’altro previsto:

1. l’accesso selettivo ai dati del Dossier in linea con i principi di necessità, pertinenza, non eccedenza e indispensabilità;
2. la previsione di log, con riguardo ad ogni accesso al dossier, con riguardo almeno a:“codice identificativo del soggetto incaricato che ha posto in essere l’operazione di accesso; la data e l’ora di esecuzione; il codice della postazione di lavoro utilizzata; l’identificativo del paziente il cui dossier è interessato dall’operazione di accesso da parte dell’incaricato e la tipologia dell’operazione compiuta sui dati”, incluse le mere operazioni di consultazione (inquiry);
3. la registrazione delle operazioni di accesso in appositi file di log ai fini della verifica della liceità del trattamento dei dati;
4. che “pur in assenza di disposizioni normative recanti obblighi in materia di tracciabilità delle operazioni con riguardo sia all’an sia al quantum, e comunque ferma restando la disciplina in materia di controllo a distanza dell’attività dei lavoratori” debbano essere realizzati sistemi di controllo delle operazioni effettuate sul dossier sanitario, mediante procedure che prevedano la registrazione automatica in appositi file di log degli accessi e delle operazioni compiute;
5. un periodo non inferiore a 24 mesi dalla data di registrazione dell’operazione.

Sul Fascicolo, il Decreto del Ministero della Salute del 7 settembre 2023 sul “Fascicolo sanitario elettronico 2.0” (su cui il Garante ha formulato il proprio Parere – doc web 9900433 / 2023) con riguardo al logging e monitoring prevede, in particolare:

1. Il tracciamento degli accessi ai sistemi informatici. In particolare, per ogni accesso ai sistemi operativi, ai sistemi di rete, al software di base e ai sistemi complessi è previsto che il sistema di tracciamento debba registrare: i) identificativo univoco dell’utenza che accede; ii) data e ora di login; iii) logout e login falliti; iv) postazione di lavoro utilizzata per l’accesso (IP client). Inoltre, tali log devono essere: a) soggetti a monitoraggio costante allo scopo di individuare eventuali anomalie inerenti alla sicurezza (accessi anomali, operazioni anomale ecc.); b) per quelli afferenti agli amministratori di sistema e degli incaricati, la protezione da eventuali tentativi di alterazione e un sistema di verifica della loro integrità. La loro conservazione è inoltre prevista per 12 mesi (inferiore quindi al termine sopra indicato per il Dossier ma superando il minimo di sei mesi previsto dal Provvedimento del Garante sugli amministratori di sistema).
2. Il tracciamento degli accessi alla base dati. In particolare, è previsto che per le utenze nominali o riconducibili ad una persona fisica sia oggetto di log – oltre agli eventi previsti all’alinea precedente – il tipo di operazione eseguita sui dati (ad esclusione delle risposte alle query). Come per gli accesi ai sistemi IT, la conservazione è prevista per 12 mesi. È inoltre previsto che gli accessi al DB sia sotto “monitoraggio della componente di DataBase Monitoring che esegue un controllo di tutte le connessioni al DB per verificarne la liceità e la correttezza.
3. L’individuazione diversificata della titolarità del trattamento di tracciamento degli accessi (in generale in capo alle Regioni ma, ad esempio, anche al Ministero della Salute per l’assistenza sanitaria al personale navigante) e sistemi di log analysis “ per l’analisi periodica delle informazioni registrate nei log, in grado di individuare, sulla base di regole predefinite e formalizzate e attraverso l’utilizzo di indicatori di anomalie (alert), eventi potenzialmente anomali che possano configurare trattamenti illeciti”.
4. La periodica produzione di “report sintetici sullo stato di sicurezza del sistema (ad es. accessi ai dati, rilevamento delle anomalie ecc.)”.

Osservazioni sulle regole di logging e monitoring

Si può, dunque, osservare che:

1. nel definire la sicurezza delle risorse IT andrebbe fortemente considerata l’attivazione di un processo di logging, anche ove non previsto da norme cogenti, non solo a fini di accountability ma perché la tutela della riservatezza – a maggior ragione se implica dati personali – non può essere garantita / dimostrata se, per usare una semplice metafora, la porta di ingresso di una struttura alberghiera è lasciata incustodita;
2. in assenza di un monitoring (possibilmente con avvisatori tempestivi e comunque periodico), viene depotenziato il logging, atteso che potrebbero emergere (essere confermati) solo gli abusi che per altri motivi fossero rilevati e restare silenti tutti gli altri. Poco vale l’obiezione, a volte formulata, che di fronte a grandi e articolati DB e grandi platee di potenziali accedenti una disamina a campione sarebbe poco significativa: piuttosto il campione dovrebbe essere adeguatamente articolato ed attentamente esaminato anche ai fini di un approfondimenti mediante altri campionamenti ove necessario;
3. in presenza di dati e informazioni per i quali le norme esterne e/o le policy interne prevedono il tracciamento (anche della sola visione), andrebbe evitata la loro esportazione in altri database o strumenti di collaboration ai fini del loro esame / utilizzo. Ciò in particolare ove questi fossero privi di analoghi sistemi di log (ad es. procedure in informatica d’utente più o meno strutturata) pur se fosse possibile adottare misure di limitazione degli accessi (ACL) o se il logging pur possibile non fosse idoneamente impostato / strutturato (ad es. tool di collaboration). Saremmo in presenza di un decadimento di fatto del livello di protezione delle informazioni pur se gli operatori che se ne avvalgono siamo della più totale affidabilità (la minaccia cybercrime prescinde dalla affidabilità e fiducia nelle persone);
4. laddove le informazioni trattate fossero rese disponibili anche ad utenti esterni, andrebbe anche per questi esperita una attività di logging e monitoring in linea con le norme sulla privacy (e di quelle, in alcuni casi, previste dalla legge). Se poi l’abilitazione di operatori terzi fosse devoluta ad amministratori della sicurezza esterni, andrebbe definito il loro ruolo nel logging e monitoring senza tralasciare che, con maggior evidenza nel caso di dati personali, la responsabilità ultima non potrebbe che restare in capo al titolare del trattamento;
5. nel caso di utenze, in primo luogo sistemistiche ma anche operative, che debbano essere assegnate in maniera non nominativa, occorrerebbe provvedere con sistemi di rilascio di password temporanee e di cui è tracciata l’assegnazione, al fine di poter ricondurre alle persone che di volta in volta se ne avvalgono le attività sui sistemi e sulle informazioni oggetto di log;
6. last but not least: se il trattamento delle informazioni fosse, talora e residualmente, effettuato in modalità tradizionale, su base analogica e non digitale, analogamente andrebbe impostato un processo di logging e monitoring che, se non potrà ovviamente contare su evidenze automatizzate, dovrebbe far perno comunque su procedure documentate, su sistemi di registrazione degli eventi e, di necessità, sul four eyes nel consentire l’accesso alle informazioni.

Considerazioni finali

In conclusione, se si conviene sull’importanza del logging e monitoring in primis per la tutela delle risorse IT, ma anche come un fattore che valorizza la reputazione e la resilienza di una organizzazione piuttosto che un adempimento meramente tecnico, è necessario che anche presso le funzioni di business vi sia consapevolezza che siamo in presenza di un adempimento collaterale ai processi ma che è un necessaria componente dei processi di cui si abbia l’ownership.

Ciò in quanto consente di identificare, rispondere e prevenire potenziali minacce alla sicurezza, alla riservatezza delle informazioni, fornendo altresì un contributo alla continuità operativa.

Le opinioni espresse dagli autori sono a titolo esclusivamente personale e non coinvolgono ad alcun titolo le organizzazioni presso cui operano.