"Kunnen jullie mijn gegevens verwijderen?"
Voor de meeste software is dat een simpele vraag. Je zoekt de rij in de database, je drukt op delete, klaar. Maar bij event sourcing ligt dat anders. Daar is de hele architectuur gebouwd op één principe: je verwijdert nooit iets. Elk event is een feit dat gebeurd is, en feiten schrijf je niet weg.
Dat botst frontaal met de GDPR wetgeving. Het recht op vergetelheid zegt dat iemand mag eisen dat je zijn of haar persoonsgegevens wist. Niet archiveert, niet verstopt, maar echt wist.
Twee regels die elkaar recht in de ogen kijken. Hoe los je dat op?
Waarom je events niet gewoon verwijdert
Je zou kunnen denken: verwijder dan toch gewoon die events. Maar dan breek je precies wat event sourcing waardevol maakt.
Een event store is een logboek van je bedrijf. Elke offerte die vertrok, elke goedkeuring, elke wijziging staat erin, in volgorde. Andere events verwijzen ernaar. Je afgeleide overzichten (projections) worden eruit opgebouwd. Haal je er middenin events uit, dan klopt je geschiedenis niet meer, en riskeer je dat de rest van je systeem op drijfzand staat.
Bovendien wil je vaak helemaal niet alles kwijt. Dat er op 12 maart een kandidaat solliciteerde, is een feit dat je statistieken en je audit trail nodig hebben. Wie die kandidaat was, dat is wat weg moet.
Crypto shredding: de sleutel weggooien in plaats van de kluis
De oplossing heet crypto shredding, en het idee is verrassend eenvoudig.
Stel je voor dat je alle persoonsgegevens van één persoon in een kluis stopt. De kluis blijft gewoon staan waar hij staat, maar zonder sleutel kan niemand erin. Wil je die persoon vergeten? Dan gooi je niet de kluis weg, maar de sleutel.
Vertaald naar software:
- Elke persoon krijgt een eigen encryptiesleutel.
- Persoonsgegevens in events worden met die sleutel versleuteld voor ze in de event store belanden.
- Bij het lezen worden ze automatisch ontsleuteld. Niemand merkt er iets van.
- Vraagt iemand om vergeten te worden? Dan verwijder je de sleutel. Eén delete, en alle events van die persoon zijn permanent onleesbaar.
De events zelf blijven staan. Het type, de volgorde, de timestamps: alles blijft intact. Alleen de inhoud is voorgoed weg. Je geschiedenis klopt nog, je statistieken kloppen nog, maar de persoon is echt vergeten.
Niet alles hoeft op slot
Een verfijning die veel verschil maakt: je hoeft niet het hele event te versleutelen. Vaak bevat een event maar een paar velden met persoonsgegevens.
Neem een event als "kandidaat aangemaakt". De naam en het e-mailadres zijn persoonsgegevens, maar de functietitel en de datum niet. Versleutel je alleen die gevoelige velden, dan blijft de rest van het event ook na het vergeten gewoon leesbaar. Je rapportage over hoeveel kandidaten er per maand binnenkwamen blijft werken, terwijl namen en e-mailadressen verdwenen zijn.
De valkuilen waar je op moet letten
Crypto shredding klinkt elegant, en dat is het ook. Maar een paar dingen moet je goed doen, anders is het schijnveiligheid.
Je sleutels moeten echt weg kunnen. Klinkt logisch, maar veel systemen doen aan soft delete: verwijderde rijen blijven stiekem bestaan met een vlagje erop. Voor encryptiesleutels is dat dodelijk. Weg moet weg zijn, ook in back-ups van je sleutelopslag.
Je afgeleide data moet mee. Events versleutelen is niet genoeg als je projections, zoekindexen en caches diezelfde persoonsgegevens onversleuteld bijhouden. Bij het vergeten moet ook die afgeleide data opgeruimd worden.
Metadata kan ook verraden. Als je events getagd zijn met een e-mailadres als identifier, dan staat er nog steeds een persoonsgegeven in je log, ook na het shredden. Gebruik anonieme id's als tags, nooit de gegevens zelf.
Gedeelde data vraagt een keuze. Een bericht tussen twee personen hoort bij allebei. Wat gebeurt er als één van hen vergeten wil worden? Daar moet je vooraf over nadenken, niet op het moment dat het verzoek binnenkomt.
Hoe wij het aanpakken
Bij Tandem Studio bouwen we op event sourcing, en crypto shredding zit standaard in ons framework. Niet als losse toevoeging achteraf, maar als laag die automatisch meedraait.
Bij het wegschrijven van een event geef je aan welke tag de persoon identificeert en welke velden persoonsgegevens bevatten. Het framework versleutelt die velden zelf, met een eigen sleutel per persoon. Bij het lezen wordt alles transparant ontsleuteld. De rest van de applicatie weet van niets.
Wil iemand vergeten worden? Dan gebeuren er twee dingen. Eerst schrijven we een gewoon domein-event weg, zodat overzichten en zoekindexen de persoon meteen opruimen. Daarna verwijderen we de sleutel, definitief. Vanaf dat moment zijn alle oude events van die persoon onleesbaar, ook als je de geschiedenis later opnieuw afspeelt. Het systeem herkent verwijderde data en slaat die netjes over.
Ook gedeelde data is afgedekt: wordt één van de betrokkenen vergeten, dan gaat de gedeelde sleutel mee de vuilbak in.
Zo krijg je het beste van twee werelden. Een volledig, betrouwbaar logboek van je bedrijf, én de zekerheid dat een verwijderverzoek echt iets verwijdert.
Waarom we sowieso voor event sourcing kiezen, lees je in Event sourcing voor KMO-software. Hoe we met datzelfde model ook consistente businessregels afdwingen (en waarom tags daarbij belangrijk zijn), leggen we uit in Wat is DCB (Dynamic Consistency Boundary)?. En dat het snel én betaalbaar blijft, toonden we met een benchmark op gewone Europese infrastructuur.
Werk je met persoonsgegevens en wil je weten of jouw software een verwijderverzoek echt aankan? Praat met ons, we bekijken het graag samen.
