GDPR come rispondere ai requisiti di auditing

Daniele GrandiniLog Analytics, Operations Management Suite

images.png

La General Data Protection Regulation (GDPR) è un tema che interessa tutti. Tutti noi come persone che utilizzando servizi che a vario titolo hanno accesso a nostre informazioni personali. Praticamente tutte le aziende che forniscono servizi a vario titolo a persone fisiche. Tutti i professionisti che operano a vario titolo nel mondo ICT, nella quasi totalità dei casi infatti le informazioni personali protette da GDPR sono trattate con strumenti informatici.

Se la vostra professione vi chiama a prendere decisioni tecnologiche per la vostra azienda, operare sistemi IT o sviluppare software, non potete nascondervi, il 25 Maggio 2018 è la data entro la quale occorrerà essere compliant con la direttiva Europea, dopo tale scadenza siamo passibili di conseguenze penali e multe fino a 20M di Euro o il 4% del fatturato aziendale. Il percorso per la compliance non può prescindere dal consultare un legale specializzato in materia (un legale non specializzato vi darà solo indicazioni generali di poca utilità) . Occorrerà quindi predisporre un assessment di tutti i processi che in azienda trattano dati personali di qualsiasi natura e dei rischi ai quali sono esposti. Si tratta di un vero e proprio risk assessment, ma l’importante è avere un’anagrafica dei processi e delle basi dati, la valutazione del rischio può essere fatta a diversi livelli e soprattutto deve e può essere integrata e migliorata nel tempo: non è necessario uno studio che impegni risorse economiche importanti da subito. A partire da questa anagrafica sarà possibile iniziare il processo di analisi di compliance al GDPR.
Di tutte le misure necessarie, badate bene tra queste ricadono anche azioni che possono essere realizzate solo con modifiche al codice e non con semplici configurazioni, mi interessa oggi soffermarmi sul tema del controllo di accesso ai dati personali che si esplicita in modo più generale al tema dell’auditing.

## Di cosa dobbiamo fare auditing?

Ovviamente il tema è molto ampio, ma se riconduciamo l’ambito a quello che è lo scopo del GDPR, ciò che viene chiesto è un audit di tutti gli accessi ai dati protetti (ovvero ai dati personali). L’audit non viene chiesto in modo diretto, ma è necessario per assicurare la possibilità di un uso congruo dei dati personali. Con il GDPR “l’onere della prova” è in carico sia al controller sia al processor, è quindi indispensabile dotarsi di un sistema di audit trial / log che in prospettiva possa diventare il Security Information and Event Management (SIEM) aziendale o che si possa integrare in un sistema di Event Management per contribuire con i dati di Security.
Tornando quindi all’ambito, è evidente che ogni accesso ai sistemi e agli applicativi che processano quel dato deve essere oggetto di audit. Non solo, ogni modifica dei ruoli di sicurezza, informazioni rispetto all’identità e al punto di connessione devono essere tracciate. Per declinare questo su un ambito più tecnologico, è evidente come occorra collezionare gli accessi di tutte le identità ai sistemi e ai dati (security logs, auditd logs, …), alle modifiche effettuate alle identità (utenti) e il maggior numero di informazioni rispetto al canale di accesso utilizzato (esempio indirizzo IP, geo localizzazione, nome della stazione, …). In particolare risulta necessario un audit delle operazioni effettuate sugli utenti nella directory delle identità (Active Directory, OpenLDAP, repository locali o applicativi). Non è strettamente necessario invece raccogliere i dati di accesso ai firewall aziendali (supponendo che gli applicativi siano compliant alla legge), ma si suggerisce caldamente di includerli nella propria politica di auditing. Particolare attenzione deve essere posta a livello applicativo per garantire un audit dell’accesso al dato e alle funzioni di gestione che permetta effettivamente di identificare la persona che compia l’azione: questo potrebbe richiedere una modifica applicativa non banale (come per altro tante altre richieste incluse nel GDPR) . SI pensi ad esempio ad un applicativo web based con un database in backend, tipicamente l’accesso al database avviene utilizzando un account applicativo impersonale, mentre l’utilizzatore effettua il logon all’applicativo che ne decide profilo e ruolo dopo averne validato l’identità. In questo scenario non è possibile affidarsi alle funzionalità di audit fornite da tutti i sistemi database di livello enterprise, ma occorre che sia l’applicativo ad implementare il proprio audit trail.
In sintesi, occorre costruire un audit trail che:

  • registri l’accesso ai sistemi che contengono i dati e gli applicativi
  • registri ogni accesso al dato protetto effettuato in qualsiasi modo e secondo qualsiasi canale
  • registri ogni modifica effettuata alle identità autorizzate all’accesso al dato e ogni modifica alle identità con diritti amministrativi sulle stesse
  • registri gli accessi esterni alla nostra rete, anche se non strettamente necessario, si tratta comunque di una buona pratica che garantisce la completezza dell’informazione

Va da se che se il dato e i punti di accesso applicativi allo stesso sono contenute unicamente su sistemi server non è necessario auditing a livello delle device utente.

## Quali sono le caratteristiche di un sistema di auditing?

È comunemente condiviso in letteratura che un sistema di audit trail debba avere le seguenti caratteristiche:

  • **Completezza** – ossia il dato non deve avere porzioni mancanti e deve contenere tutte le informazioni utili al suo scopo. La completezza deve essere prima di tutto garantita dal sistema che genera l’audit log, il sistema di collezione dovrà semplicemente non introdurre proprie criticità ad esempio permettendo gap nella raccolta degli eventi stessi.
  • **Inalterabilità** – il dato deve essere inalterabile in tutto il suo percorso dall’origine fino al vault, questo significa crittografia in transito e impossibilità di intervenire in modifica sul dato raccolto. Per garantire questo il dato deve essere copiato dal sistema che lo ha generato nel più breve tempo possibile.
  • **Integrità** – il dato raccolto e processato deve mantenere la propria integrità in termini di completezza (vedi primo punto). SU questo punto spesso ci sono interpretazioni che indicano che il dato deve essere mantenuto nel suo formato originale, questa è evidentemente una sciocchezza, in quanto ogni operazione, foss’anche solo di export, cambia il formato del dato e potenzialmente può introdurre modifiche allo stesso. D’altra parte affidarsi a copie del dato in formato nativo, anche fosse possibile senza introdurre comunque una potenziale alterazione, costituisce un grosso problema in tema di
    inalterabilità, in quanto non è possibile pensare a copie nell’ordine dei secondi o anche solo dei minuti, e rende il dato stesso di difficile utilizzo in fase di indagine. È la soluzione adottata che deve garantire tecnologicamente l’integrità del dato raccolto.
  • **Mantenimento** – il dato deve essere mantenuto per un periodo prefissato, tipicamente nell’ordine dei mesi. La disposizione del Grante Privacy italiano, comunemente conosciuta come “Direttiva Amministratori di Sistema” prescrive un mantenimento di 6 mesi.

## Quali sono le sfide di un sistema di auditing?

La raccolta di un audit trail con le caratteristiche sopra riportate impone diverse sfide tecnologiche, premesso che la completezza del dato deve essere garantita in origine prima di tutto e che il sistema di collezione deve semplicemente non introdurre proprie criticità, gli altri requirements portano ad avere:

  • un volume di dati raccolti e da gestire importante, in molti casi diventa la base dati più voluminosa a livello aziendale.
  • una difficoltà tecnologica nel garantire l’inalterabilità

Ho potuto vedere molte implementazioni effettuate on premises soffrire di:

  • Alti costi di gestione dovuti ai volumi dati da mantenere in termini di capacità elaborativa, sistema di protezione del dato (backup) e difficoltà nel garantire un Recovery Time Objective (RTO). Anche se esistono soluzioni che tentano di ridurre le dimensioni del dato raccolto queste vanno o a discapito delle performance, oppure causano un data loss mantenendo solo alcune proprietà dell’evento originale.
  • Pessime performance in interrogazione
  • Difficoltà nell’ingestion di fonti dati non previste dal prodotto
  • possibilità di garantire la non modificabilità del dato una volta raccolto solo tramite un processo organizzativo, ovvero tramite nomina di un auditor o Data Protection Officer che abbia esclusivo accesso al vault dei dati e che non detenga alcun diritto amministrativo sui servizi soggetti ad audit. Nelle piccole e medie aziende questo processo organizzativo ha sfide quasi insormontabili. L’unico modo tecnico per garantire la non modificabilità del dato sarebbe un meccanismo di signature con time stamping pubblico sia a livello di riga sia a livello di intero stream in modo progressivo. Non conosco una soluzione commerciale che sia in grado di fare questo e di avere la scalabilità necessaria a gestire un flusso come quello di audit log.

I sistemi operati dalla cloud permettono di superare questi vincoli, ma ovviamente hanno una forte dipendenza dalla connettività e possono presentare criticità in termini di certificazioni di sicurezza.
È infine evidente che un sistema di audit collection che possa essere usato per garantire una compliance al GDPR debba esso stesso essere progettato e operato secondo le stesse norme, pena venire a cadere la non ripudiabilità del dato a fronte di un contenzioso. Questo a prescindere della locazione fisica in cui è implementato.

## Come Microsoft Operations Management Suite risponde a queste richieste?

Microsoft Operations Management Suite – Log Analytics (LA) è una soluzione completamente cloud based che promette di rispondere a tutte le caratteristiche necessarie ad implementare un moderno sistema di auditing e molto più. LA infatti è un sistema di data ingestion e analysis general purpose che permette di applicare sui dati raccolti interrogazioni su cui basare alerting, reporting, dashboard, export in locale o verso account PowerBI, il tutto garantendo l’integrità del dato e l’inalterabilità dello stesso.
LA permette di raccogliere dati da qualsiasi fonte:

  • Tramite agenti per i sistemi operativi (Windows o Linux che siano)
  • Tramite interfaccia con le diagnostiche e l’audit di Microsoft Azure
  • Tramite interfaccia diretta ad altri sistemi (ad esempio Office 365 o Application Insights)
  • Tramite interfaccia pubblica REST based per consolidare anche log verticali generati da propri applicativi

Una volta che le varie sorgenti dati sono state connesse al workspace LA, gli eventi e in generale le informazioni raccolte iniziano ad alimentare il vault in modo sicuro (TLS) e mutuamente autenticato. Appena indicizzate le informazioni vengono messe a disposizione del linguaggio di ricerca della soluzione e possono essere consultate tramite interfaccia web o tramite web service REST. Il tempo di latenza da quando il dato è generato a quando viene scritto sul vault sulla cloud è di qualche secondo sui sistemi Windows (informazione non documentata) fino ad un massimo di 20” sui sistemi Linux. Il tempo dopo il quale il dato indicizzato viene reso disponibile alle interrogazioni è tra i 20” e i 120” dalle misurazioni empiriche solte sul campo. In generale possiamo definire questo tipo di ingestion “near real-time”.

log-analytics-security-diagram.png

Microsoft garantisce la durability

del dato e la sua congruenza, questo ci permette di delegare completamente tutti i temi che riguardano la protezione del dato raccolto.
In caso di assenza di connettività l’agente sui sistemi è autonomo per 2 ore (configurabile), accodando il dato ed effettuando tentativi di trasmissione ogni 8 minuti.
Per quanto riguarda le caratteristiche di un audit trail, OMS permette di:

  • Completezza – garantita dal fatto che la soluzione colleziona i dati direttamente dalla sorgente (Security log windows, audit trail linux, log di Office 365 e così via) e dal fatto che i log vengono immediatamente collezionati dall’agente. Se l’amministratore decidesse di cancellare il security log, questo evento sarebbe comunque collezionato evidenziando l’operazione.
  • Inalterabilità – L’inalterabilità si ottiene prima di tutto grazie alla raccolta “near real time” delle informazioni dai security log e dalla loro trasmissione in modo cifrato sulla rete fino a raggiungere il workspace sulla cloud. Non solo il dato in transito è protetto tramite il protocollo TLS, ma OMS implementa anche il certificate pinning che impedisce attacchi di man n the middle. Una volta raggiunto il vault sulla cloud il dato non sarà più modificabile.
  • Integrità – l’integrità del dato è garantita da Microsoft in base alla implementazione tecnologica della soluzione e alle certificazioni in termini di operations raggiunte
  • Mantenimento – ad oggi Log Analytics permette di mantenere il dato per 24 mesi

Perché OMS può essere utilizzato come audit vault per il GDPR

Alcune aziende classificano anche i dati di auditing come dati protetti, ma in generale tutte considerano questi dati come un patrimonio importante su cui esercitare le opportune misure di controllo. Come per tutti i servizi implementati su Microsoft Azure è possibile scegliere la region dove memorizzare i dati, il numero di datacenter dove è implementato LA è in costante aumento. Al momento della redazione di questo articolo è possibile memorizzare i propri dati presso il data center “West Europe” e avere quindi garanzia che i dati rimangano sul territorio della comunità europea.

Essendo un servizio basato sui datacenter Azure eredita da questi tutte le caratteristiche di sicurezza fisica e logica (si vedano i riferimenti), in particolare Log Analytics è al momento è certificato:

Quali altre funzioni Microsoft Operations Management Suite può coprire?

In questo articolo mi sono concentrato sulle funzionalità di security log ingestion di OMS, ma la suite permette di rispondere a diverse richieste incluse nel GDPR, da quelle più comuni e sicuramente già indirizzate all’interno di tutti i sistemi IT:

  • Protezione del dato (backup)
  • Patching
  • Controlli antimalware

A quelle meno comunemente implementate:

  • Disaster recovery tra datacenter di proprietà o tra datacenter di proprietà e Azure oppure ancora tra data center Azure
  • Data breach detection e security baselines basate sul know how maturato da Microsoft nella gestione dei propri sistemi

Tutto questo sempre in modalità multipiattaforma e multi cloud.

microsoft-operations-management-suite-12-638.jpg

Riferimenti