Audit log solution home made

Volevo raccontare la storia di un servizio che ho progettato.

Ormai è sempre più importante la gestione degli audit logs e di poterli recuperare anche dopo anni per verificare e capire chi ha fatto cosa.

Questo è essenziale come tutela legale soprattutto per una realtà che opera nel mondo sanitario.

Ci sono alcune soluzioni software che ti permettono di salvare questi dati, ma noi abbiamo voluto approcciarsi con un MVP creato internamente.

La scelta, ormai come per tutta la nostra Developer Platform Samaritan è ricaduta sulla creazione di un microservizio che si appoggia su alcune tecnologie/servizi AWS.

Abbiamo quindi definito i requisiti che il servizio doveva avere così da capire che tecnologie e che approccio utilizzare per l’implementazione.

I requisiti individuati erano:

• durabilità del dato
• comodità di ricerca
• costi ridotti
• facilità nel invocare il servizio
• struttura dati custom
• regolamentazione sugli accessi ai dati

Definiti i requisiti abbiamo iniziato a individuare le tecnologie /servizi che erano più aderenti al nostro desiderata.

Tecnologie usate sono state:

• API GATEWAY: per creare un endpoint per pubblicare il log da scrivere. Questo utile per dare anche ai fornitori esterni la possibilità di scriverci log senza necessariamente avere un’account AWS e una secrets.
• SQS + SQS DLQ: per gestire una coda di tutti i log Questa risulta molto utile per sequenziare le scritture e ridurre il carico per moltissimi log (ci aspettiamo mediamente un carico di 100K di log giornalieri gestendo solo i nostri sw proprietari principali ) e per gestire errori sul consumer e non perdere nessun evento di log
• S3: è il repository dei log vedremo poi nel dettaglio perché si è scelto S3 e non un DB per gestire i dati
• LAMBDA: per poter gestire il publisher e il consumer del nostro servizio
• CLOUDWATCH: per il monitoraggio dei log e alert verso slack per possibili don

Perché abbiamo usato S3 e non un DB ?

La scelta di S3 è stata legata a due fattori principali:

• costo
• facilità di gestire permessi

Il costo perché nei requisiti avevamo la “durabilità del dato” e questo per noi vul dire conservare un log per 10 anni. Avere quindi un DB ci comportava costi di gestione, di manutenibilità del servizio alti pensando soprattutto al fatto che questi dati, nello scenario più felice, non andranno mai visionati (sono usati solo per fare verifiche su degli illeciti).

S3 quindi risultava la scelta migliore per:

• costo contenuto
• possibilità di cambiare classe di storage dinamicamente ai file così da spendere ancora meno

L’altro aspetto, quello dei permessi, non ci ha fatto andare su un DB perchè la semplicità di gestione dei permessi per un bucket S3 (anche su singolo utente IAM) ci sono risultati utilissimi e molto sicuri.

Inoltre S3 ha un’ottima gestione delle versioni, per cui possiamo avere traccia di tutti i cambiamenti del file in ottica di atomicità del dato.

I file vengono salvati in CSV con una struttura ben precisa così da standardizzare la scrittura nel tempo per facilitarne poi il recupero e l’analisi. Il publisher infatti ha un validatore dei campi richiesti, così da validare l’input sul file.

Workflow di scrittura e log rotation

Di seguito trovate il diagramma di flusso di come funziona il microservizio.

Come prevediamo la ricerca?

Per la ricerca, visto che i file sono dei CSV abbiamo tenuto le possibilità molto aperte:

• AWS KENDRA: per la ricerca in realtime su tutti i file salvati nel S3
• EXCEL: se si deve recuperare un log specifico per essere più veloci e ridurre i costi
• RICERCA FULL-TEXT: essendo i dati in CSV la ricerca full-text o il caricamento in un DB temporaneo è di facile implementazione

Questo servizio è stato un buon banco di prova per utilizzare in modo diverso alcune tecnologie ma soprattutto capire che, con la Developer Platform creata, siamo molto liberi di creare servizi di qualsiasi natura e scopo in maniera semplice e veloce.