Simpele en flexibele op ETL gebaseerde anonimisatie instellen – deel 1

• De oplossing moet in ieder geval ter plaatse gegevens kunnen extraheren uit een interne Oracle database.
• Het eindresultaat moet bestaan uit een set CSV-bestanden in een Amazon S3-bucket.
• Ergens in het traject tussen het opnemen van Oracle-data en het in CSV-vorm dumpen op S3, moet iets worden gerealiseerd dat persoonlijke gegevens verwijdert of anonimiseert.
• De gekozen oplossing moet bij voorkeur cloud native zijn.

Ik zal in deze reeks van drie blogs aan de hand van de volgende onderwerpen uitleggen hoe je een simpele en flexibele op ETL gebaseerde anonimisatie kunt instellen:

• Research naar producten die wellicht kunnen worden gebruikt om het probleem op te lossen. Controleer ook in welke mate ze geschikt zijn voor wat je met het proof of concept wilt bereiken.
• Hoe het gekozen product kan worden gebruikt om een ETL-pijplijn te creëren die aan de vereisten voldoet. En hoe je in Docker een lokale Oracle-database kunt instellen die als gegevensbron kan worden gebruikt voor de gegevensopname uit het proof of concept (gewoon omdat dit zo'n ‘PITA’ was om te doen).
• En of dit op cloud-native wijze kan worden bereikt.

Research

De research voor het proof of concept bestond uit twee delen:

• Gegevens uit een Oracle-database extraheren, op de een of andere manier anonimiseren en als een bundel CSV-bestanden opslaan in een S3-bucket oftewel het ETL-deel.
• Het bepalen van een optimale manier om de anonimisatie te realiseren.

Gegevens extraheren, transformeren en opslaan

Het was direct al duidelijk dat het probleem van de klant zou moeten kunnen worden opgelost met een ETL-product. Extract Transform Load. De research voor dit deel van het proof of concept draaide dan ook om dit product. Ik kreeg daarnaast een tip van een teamlid om een kijkje te nemen bij singer.io omdat ze dat in het verleden succesvol hadden gebruikt voor dergelijke problemen.

Bij het bekijken van de startpagina van Singer vallen direct een aantal zaken op:

• Singer gebruikt gegevensextractie en consolidatie voor alle tools in je organisatie.
• De open-source standaard om scripts te schrijven waarmee gegevens worden verplaatst.
• Op Unix geïnspireerd: de taps en targets van Singer zijn eenvoudige applicaties die zijn samengesteld uit pipes.
• Op JSON gebaseerd: de applicaties van Singer communiceren met JSON waardoor ze gebruiksvriendelijk zijn en eenvoudig te implementeren in alle soorten programmeertaal.

Singer is feitelijk gewoon een specificatie, maar geen officiële. Het is een simpele op JSON gebaseerde gegevensindeling en je kunt in deze indeling iets produceren (Singer noemt dit een tap) of de indeling gebruiken (een target). Je kunt deze taps en targets aan elkaar linken om gegevens uit de ene locatie te extraheren en op te slaan op een andere locatie. Singer wordt standaard geleverd met een aantal taps (100+) en targets (10). Deze taps en targets zijn geschreven in Python. Omdat het middelpunt van het systeem wordt gevormd door een gegevensindeling kun je er zelf eenvoudig één schrijven of een bestaand exemplaar aanpassen.

Als we de taps bekijken dan zou de standaard Oracle-tap moeten voldoen om het extraheren (Extract) te verzorgen voor ons proof of concept. Dit lijkt echter niet op te gaan voor het laden (Load) als we de standaard targets bekijken. Er is een CSV-target maar de resultaten worden lokaal opgeslagen en niet in een S3-bucket. Je kunt dit target uiteraard gewoon gebruiken en het uploaden naar S3 zelf regelen zodra de ETL-pijplijn is voltooid. Of je past het bestaande CSV-target aan en je wijzigt de bestandsopslag naar S3. Een korte zoektocht op Google levert een door de community gemaakt S3 CSV Singer-target op. Dit target zou volgens de documentatie perfect voldoen aan onze vereisten.

Whoops, Singer kan niet transformeren

Extract en Load zijn geregeld, maar we moeten ook nog iets verzinnen voor het Transform-deel van de ETL-pijplijn ... en dan ontdekken we iets raars. Singer wordt weliswaar geclassificeerd als een ETL-tool, maar biedt geen ondersteuning aan het transformatiedeel?

Ik stuitte vervolgens op een bericht met deze onheilspellende titel: Why our ETL tool doesn’t do transformations. Als je dit leest, lijkt het alsof ze hun JSON-specificatie/gegevensindeling beschouwen als het transformatiedeel. Ze ondersteunen dus de transformatie naar onbewerkte gegevens en de opslag ervan, maar andere soorten transformaties worden niet ondersteund. Dit moet je zelf regelen nadat het ergens is opgeslagen door een Singer-target. Het lijkt er dus op dat Singer eigenlijk het EL-deel is van een ETL-product en niet zozeer een ‘old school’ ETL-product.

Singer zou in ieder geval moeten volstaan om gegevens uit een Oracle-database te extraheren en in CSV-indeling op te slaan in een S3-bucket. En omdat Singer wel heel simpel, open en uitbreidbaar is, wil ik het daar voorlopig bij laten. Laten we ons verdiepen in de anonimisatieopties die in dit Singer-scenario zouden kunnen passen.

Anonimiseren

Net zoals bij het ETL-deel kreeg ik ook nu een tip, in dit geval over Microsoft Presidio.

Als we een kijkje nemen op de startpagina dan lezen we het volgende:

• Het biedt snelle identificatie- en anonimisatiemodules voor persoonlijke entiteiten in tekst en afbeeldingen zoals creditcardnummers, namen en meer.
• Kan worden gebruikt om PII-gegevensstromen geautomatiseerd én semi-geautomatiseerd te anonimiseren op meerdere platformen.
• Aanpasbaarheid bij PII-identificatie en anonimisatie.

Er zijn dus diverse interessante zaken die mij kunnen helpen om mijn anonimisatiebehoeften te vervullen. Het lijkt er vervolgens op dat ik dit product aan het evalueren ben tijdens een grote transformatie (wat een toeval) van V1 naar V2. V1 bevat enkele ETL-achtige zaken, zoals het ophalen van gegevens uit bronnen (alhoewel de ondersteuning van Oracle in de roadmap nooit van de grond lijkt te zijn gekomen) en het opslaan van geanonimiseerde resultaten in/op diverse formulieren/locaties. Deze aanpak is in V2 volledig verdwenen en richt zich nu uitsluitend op het vinden en vervangen van PII-gegevens.

Presidio V2 is feitelijk een op Python gebaseerd systeem gebouwd op een AI-model. Het kan zodoende automatisch PII-gegevens in tekst en afbeeldingen detecteren en vervangen volgens door jou gedefinieerde regels. Ik heb enkele testjes uitgevoerd met hun online testtool en het werkt wel min of meer, maar het moet voor ons specifieke doel zeker worden aangepast. Als we naar hun testgegevens kijken dan gaat het hoofdzakelijk om simpele en korte gegevens, maar geen grote stukken tekst of afbeeldingen. De vraag is of we, ook als we Presidio naar wens kunnen configureren, geen erg grote hamer gebruiken om kleine spijkers in te slaan?

Is Presidio teveel van het goede?

Laten we er nog eens naar kijken. We hebben het autodetectiegedeelte van Presidio niet nodig als eenvoudig kan worden bepaald en gedefinieerd welke simpele kolommen in welke tabellen geanonimiseerd moeten worden en het wissen of hashen van de kolomwaarden volstaat. Ook de volledige tekst- of afbeeldingsondersteuning van Presidio en hun ‘fancy’ vervangingsondersteuning is in dat geval overbodig. Presidio zou dienst kunnen doen als een krachtige bibliotheek om een automatische transformatiestap voor het anonimiseren van gegevens te creëren in onze op Singer gebaseerde pijplijn. Het is ook fijn dat Presidio gebaseerd is op Python. Toch zegt mijn gevoel me dat het misschien beter is om eerst een simpelere oplossing te zoeken.

Ik ging op zoek naar iets dat een simpele PII-vervanging kan verzorgen binnen een Singer tap/target-scenario. Ik ontdekte deze Github-opslagplaats: pipelinewise-transform-field. De documentatie wordt omschreven als “Transformatiecomponent tussen Singer-taps en -targets”. Dit lijkt verdacht veel op het 'T'-deel dat bij Singer als ETL ontbrak! Verderop in de configuratiesectie kunnen we zelfs het volgende lezen:

“Je moet definiëren welke kolommen door welke methode getransformeerd moeten worden en onder welke voorwaarde de transformatie uitgevoerd moet worden.”

en dit zijn de mogelijk soorten transformaties:

• SET-NULL: alle input wordt getransformeerd naar NULL
• HASH: string-input wordt getransformeerd naar hash
• HASH-SKIP-FIRST-n: string-input wordt naar hash getransformeerd waarbij de eerste n tekens worden overgeslagen, bijv. HASH-SKIP- FIRST-2
• MASK-DATE: vervangt de maanden en dagen in datumkolommen zodat deze altijd 1 januari zijn
• MASK-NUMBER: transformeert alle numerieke waarden naar nul
• MASK-HIDDEN: transformeert alle strings naar 'hidden'

Het lijkt erop dat aan al onze simpele anonimisatievereisten wordt voldaan! We kunnen zelfs zien hoe we het binnen de context van Singer kunnen gebruiken:

We beschikken nu over alle benodigde puzzelstukjes om een simpele en flexibele op ETL gebaseerde anonimisatie in te stellen. We zullen in de volgende blog bespreken hoe alle puzzelstukjes in elkaar vallen en of ze het gewenste resultaat opleveren voor de klant.