IT 01.Home - matiux/broadway-sensitive-serializer Wiki

Introduzione

L'idea dietro a questo progetto è quella di rendere compliant un sistema CQRS + ES, nello specifico implementato attraverso la libreria Broadway, con il regolamento generale sulla protezione dei dati (GDPR), in particolare con il diritto all'oblio.

Concetti base

CQRS

CQRS (Command Query Responsibility Segregation) punta a separare le responsabilità per le query e per i comandi. Si tratta di un pattern che separa le operazioni di lettura e scrittura su un determinato modello. Questo, nella pratica, porta a oggetti concreti differenti, separati in modelli di scrittura e modelli di lettura. Questo pattern può quindi portare ad avere differenti tabelle o data store in cui i dati sono separati in base a che si tratti di un comando (scrittura) o di una query (lettura). Separazione a parte, verrà comunque persistito l'ultimo stato del modello come avviene nei sistemi CRUD tradizionali.

ES

ES (Event Sourcing), utilizzato insieme a CQRS, "trasforma" la parte di scrittura dei modelli del CQRS, in un susseguirsi di eventi che vengono persistiti in un Event Store, una specifica tabella o data store che funge da registro cronologico e immutabile degli eventi. L'idea è che i comandi eseguiti su un modello, generano eventi che vengono persistiti nell'Event Store. In questa tabella ci sono tutti gli eventi occorsi per un determinato modello. L'Event Store è quindi un sistema di registrazione di tutti gli eventi che, se riapplicati dal primo all'ultimo al modello, lo portano al suo ultimo stato. Oppure potrebbe essere possibile vedere lo stato di un modello indietro nel tempo. Questi eventi poi, se ascoltati da specifici Listeners, possono proiettare delle viste specifiche (Read Model) o generare nuovi comandi. Le viste saranno quindi i modelli (persistiti in tabelle diverse dall'Event Store o addirittura un diverso Data Store) utilizzati dalle query di lettura.

Immutabilità dell'Event Store

Quando utilizziamo il pattern CQRS+ES abbiamo quindi un Event Store nel quale verranno scritti tutti gli eventi in ordine cronologico e raggruppati per ogni modello. L'Event Store è per sua natura immutabile; dopo aver scritto un evento, questo non potrà mai più essere modificato. Se necessario verranno emessi eventi di compensazione per sopperire agli eventi precedenti. Immaginate un conto bancario e la relativa lista dei movimenti, e pensate a un evento di compensazione come a un movimento di storno.

Art. 17 GDPR - Oblio

La normativa dice: L'interessato ha il diritto di ottenere dal titolare del trattamento la cancellazione dei dati personali che lo riguardano senza ingiustificato ritardo e il titolare del trattamento ha l'obbligo di cancellare senza ingiustificato ritardo i dati personali. Versione completa

CQRS + ES + GDPR

Abbiamo detto che nel pattern CQRS + ES l'Event Store è immutabile e abbiamo anche detto che per essere compliant con la GDPR, un utente può richiedere la cancellazione dei suoi dati. Messa così sembra un paradosso no? Perchè cancellare i dati di un utente in un sistema CQRS + ES vorrebbe dire o cancellare gli eventi dall'Event Store o modificare gli eventi esistenti. Entrambe cose che non possiamo fare. Gli eventi di compensazione in questo caso non ci aiuterebbero in quanto tornando indietro nella storia, potremmo sempre recuperare i dati dell'utente.

La proposta

Questa libreria propone un soluzione al problema di cui sopra. Invece di ragionare in termini di cancellazione o modifica degli eventi, l'idea è quella di persistere fin dall'inizio della storia, eventi in cui il payload (le informazioni dell'utente, o in generale dell'evento contenente dati sensibili) è criptato tramite una chiave di criptazione specifica per ogni Aggregato. Finché la chiave sarà presente, si potranno criptare e decriptare i dati. Quando la chiave verrà cancellata (a seguito della richieste di un utente), gli eventi rimarranno si nell'Event Store, ma le chiavi del payload saranno criptate senza possibilità di decodifica. La storia rimarrà quindi invariata, ma i dati non comprensibili.