Leestijd 7 min

Jan Eerdekens

In deze technische blogpost wil ik het hebben over hoe je eenvoudige en flexibele ETL-gebaseerde anonimisering kunt opzetten. Waarom? Wel, ik had onlangs de gelegenheid om een klein proof of concept uit te voeren voor een klant. De klant wilde weten welke opties beschikbaar waren om interne gegevens te nemen, alle persoonlijk identificeerbare informatie (PII) te verwijderen of anonimiseren en deze op een eenvoudige manier en vorm beschikbaar te maken voor externe partijen. Na het verzamelen van verdere vereisten werd de context voor dit proof of concept als volgt gedefinieerd: Welke oplossing dan ook, het moet in staat zijn om gegevens te extraheren uit een on premise Oracle database . Het eindresultaat moet een set CSV-bestanden zijn in een Amazon S3-bucket . Tussen het ophalen van de Oracle-gegevens en het dumpen ervan in CSV-vorm op S3, moet er iets zijn dat PII-gegevens verwijdert/anonimiseert. Indien mogelijk moet de gekozen oplossing cloud native zijn. In deze 3-delige blogreeks leg ik uit hoe je eenvoudige en flexibele ETL-gebaseerde anonimisering opzet: Het onderzoek naar producten die gebruikt zouden kunnen worden om het probleem op te lossen. Controleer ook hoe geschikt ze zijn voor wat de proof of concept moet bereiken. Hoe het gekozen product gebruikt kan worden om een ETL pipeline te maken die aan de eisen voldoet. Daarnaast, hoe je een lokale Oracle database opzet in Docker die gebruikt kan worden als databron voor het data ingestion deel van het proof of concept (gewoon omdat dit zo'n PITA was om te doen). En of dit op een cloud native manier kan worden gedaan. Onderzoek Het onderzoeksdeel van het proof of concept bestaat uit 2 delen: Hoe haal je data uit een Oracle database, anonimiseer je het op de een of andere manier en sla je het op als een stel CSV bestanden in een S3 bucket aka het ETL gedeelte. Uitzoeken wat de beste manier is om de anonimisering uit te voeren. De gegevens extraheren, transformeren en opslaan Het probleem van de klant klonk meteen al opmerkelijk als iets dat je zou kunnen oplossen met een ETL-product: Extract Transform Load . Het onderzoeksgedeelte voor dit deel van het proof of concept zou zich dus concentreren op dit type product. Ik kreeg ook wat input van iemand in mijn team om eens te kijken naar singer.io , omdat dat iets was dat ze in het verleden met succes hadden gebruikt voor dit soort problemen. Als je naar de homepage van Singer kijkt, vallen een aantal dingen meteen op: Singer maakt gegevensextractie en -consolidatie mogelijk voor alle tools van je organisatie. De open-source standaard voor het schrijven van scripts die gegevens verplaatsen. Unix-geïnspireerd: Singer taps en targets zijn eenvoudige applicaties samengesteld met pipes. JSON-gebaseerd: Singer-toepassingen communiceren met JSON, waardoor ze eenvoudig te gebruiken en te implementeren zijn in elke programmeertaal. Singer is dus gewoon een specificatie, zij het geen officiële. Het is een eenvoudig, op JSON gebaseerd dataformaat en je kunt iets in dit formaat produceren (een tap in Singer terminologie) of het formaat consumeren (een target ). Je kunt deze taps en targets aan elkaar koppelen om gegevens van de ene locatie te halen en op een andere locatie op te slaan. Singer wordt standaard geleverd met een heleboel taps (meer dan 100) en targets (10). Deze taps en targets zijn geschreven in Python. Omdat het centrale punt van het systeem slechts een gegevensformaat is, is het vrij eenvoudig om er zelf een te schrijven of een bestaand formaat aan te passen. Bij het controleren van de taps zou de standaard Oracle-tap het Extract-gedeelte van ons proof of concept moeten dekken. Hetzelfde lijkt echter niet het geval te zijn voor het Load gedeelte als we kijken naar de standaard targets. Er is een CSV target , maar deze slaat de resultaten lokaal op, niet in een S3 bucket. Er is een optie om gewoon dit doel te gebruiken en de S3 upload zelf te doen nadat de ETL pijplijn is voltooid. Een andere optie zou zijn om het bestaande CSV target aan te passen en de bestandsopslag te veranderen naar S3. Even Googelen levert een door de gemeenschap gemaakt S3 CSV Singer doel op. Volgens de documentatie zou dit target precies moeten doen wat we willen. Oeps, Singer transformeert niet Met de Extract en Load delen gedekt, blijft alleen het Transform deel van de ETL pijplijn over om uit te zoeken... en dit is waar het een beetje vreemd wordt. Ook al is Singer geclassificeerd als een ETL tool, het lijkt geen ondersteuning te hebben voor het transformatie gedeelte? Toen ik hier verder naar keek, kwam ik deze onheilspellend getitelde post tegen: Why our ETL tool does not do transformations . Als ik dit lees, lijkt het erop dat ze hun JSON specificatie/gegevensformaat beschouwen als het transformatiegedeelte. Dus ze ondersteunen transformatie naar ruwe gegevens en het opslaan ervan, maar ondersteunen geen andere soorten transformaties. Dat deel mag je zelf doen nadat het ergens is opgeslagen door een Singer-doel. Het blijkt dus dat Singer meer lijkt op het EL deel van een ELT product dan op een "old school" ETL product . Op dit punt zou Singer in ieder geval voldoende moeten zijn om de gegevens uit een Oracle database te halen en in CSV-formaat in een S3 bucket te zetten. En omdat Singer vrij eenvoudig, open en uitbreidbaar is, laat ik het hier voorlopig bij. Laten we verder kijken naar de anonimiseringsopties die in deze Singer-context zouden kunnen passen. Gegevens anonimiseren Net als bij het ETL-gedeelte, kreeg ik ook voor dit gedeelte wat input die me wees op Microsoft Presidio . Op de homepage kunnen we het volgende lezen: Het biedt snelle identificatie- en anonimiseringsmodules voor privé-entiteiten in tekst en afbeeldingen , zoals creditcardnummers, namen en meer. Het faciliteert zowel volledig geautomatiseerde als semi-geautomatiseerde PII de-identificatiestromen op meerdere platforms. Aanpasbaarheid in PII-identificatie en -anonimisering. Er staan dus veel veelbelovende dingen in die me zouden kunnen helpen bij het oplossen van mijn anonimiseringsbehoeften. Bij nader onderzoek lijkt het erop dat ik dit product evalueer tijdens een grote transformatie (snap je? 😉 ) van V1 naar V2. V1 bevatte wat ETL-achtige dingen zoals het ophalen van gegevens uit bronnen (hoewel Oracle-ondersteuning in de roadmap nooit lijkt te zijn gerealiseerd ) en het opslaan van geanonimiseerde resultaten in een aantal vormen/locaties. V2 heeft deze aanpak echter volledig losgelaten en concentreert zich puur op het detecteren en vervangen van PII-gegevens. In de kern is Presidio V2 een op Python gebaseerd systeem dat bovenop een AI-model is gebouwd. Dit stelt het in staat om automatisch PII-gegevens te ontdekken in tekst en afbeeldingen en deze te vervangen volgens de regels die je definieert. Ik heb wat tests gedaan met behulp van hun online testtool en het werkt min of meer, maar voor onze specifieke context moet het zeker worden aangepast. Als we kijken naar de meegeleverde testgegevens, lijkt het erop dat het vooral eenvoudige en korte gegevens zijn, maar geen grote tekstblokken of afbeeldingen. Dit roept de vraag op: zelfs als we Presidio kunnen configureren om te doen wat we willen, slaan we misschien kleine spijkers met een grote hamer? Is Presidio te veel? Laten we hier nog eens over nadenken. Als we gemakkelijk kunnen weten en definiëren welke eenvoudige kolommen in welke tabellen moeten worden geanonimiseerd en wanneer gewoon nulling of hashing van de kolomwaarden voldoende is, dan hebben we het autodetectie deel van Presidio niet nodig. We hebben ook geen Presidio-ondersteuning nodig voor volledige tekst of afbeeldingen en we hebben ook geen fancy substitutie-ondersteuning nodig. Presidio zou een krachtige bibliotheek kunnen zijn om een automatische anonimiseringsstap te maken voor onze Singer-gebaseerde pijplijn. Het helpt ook dat Presidio gebaseerd is op Python. Maar mijn gevoel zegt dat ik misschien eerst moet proberen om een iets eenvoudigere oplossing te vinden. Ik begon te zoeken naar iets dat een eenvoudige PII-vervanging kan doen en dat werkt in een Singer tap/target context. Ik vond deze Github repository: pipelinewise-transform-field . In de documentatie staat "Transformatiecomponent tussen Singer taps en targets". Klinkt verdacht veel als het " T " deel dat Singer als een ETL miste! Verderop in de configuratiesectie lezen we zelfs: "Je moet definiëren welke kolommen door welke methode moeten worden getransformeerd en in welke conditie de transformatie moet worden toegepast." en de mogelijke transformatietypes zijn: SET-NULL : transformeert elke invoer naar NULL HASH : transformeert stringinvoer naar hash HASH-SKIP-FIRST-n : Transformeert stringinvoer naar hash waarbij de eerste n tekens worden overgeslagen, bijv. HASH-SKIP-FIRST-2 MASK-DATE : Vervangt de maand- en dagdelen van datumkolommen door 1 jan. MASK-NUMBER : Zet elke numerieke waarde om in nul. MASK-HIDDEN : verandert een willekeurige tekenreeks in 'verborgen'. Dit lijkt volledig te voldoen aan onze eenvoudige anonimiseringseisen! We kunnen zelfs zien hoe we het moeten gebruiken in de context van Singer: some-singer-tap | transform-field --config [config.json] | some-singer-target Standaard Conclusie We hebben nu alle stukjes van de puzzel voor het opzetten van eenvoudige en flexibele ETL-gebaseerde anonimisering. In de volgende blogpost laten we zien hoe ze in elkaar passen en of ze de resultaten opleveren die de klant zoekt.

Leestijd 3 min

Simon Vercruysse

We zijn als ACA Group officieel ISO 27001 compliant! Onze Information Security Manager Simon Vercruysse legt uit wat die certificatie precies inhoudt en wat de voordelen zijn voor jouw (toekomstige) project.

Leestijd 5 min

Stijn Van den Enden

Of we nu onze telefoons ontgrendelen met gezichtsherkenning, stemcommando's roepen naar onze slimme apparaten vanaf de andere kant van de kamer of een lijst krijgen voorgeschoteld met films die we misschien leuk vinden... machine learning heeft in veel gevallen ons leven ten goede veranderd. Maar zoals met veel geweldige technologieën, heeft het ook een schaduwzijde. Een belangrijke is de massale, vaak ongereguleerde, verzameling en verwerking van persoonlijke gegevens. Soms lijkt het wel alsof er voor elk positief verhaal een negatief verhaal is over onze privacy die in gevaar is . Het is duidelijk dat we gedwongen zijn om privacy de aandacht te geven die het verdient. Vandaag wil ik het hebben over hoe we toepassingen voor machine learning kunnen gebruiken zonder dat we ons zorgen hoeven te maken over privacy en ons zorgen hoeven te maken dat privégegevens openbaar worden . Machine learning met randapparaten Door de intelligentie op randapparaten op locatie te plaatsen, kunnen we ervoor zorgen dat bepaalde informatie de sensor die deze vastlegt niet verlaat. Een randapparaat is een stuk hardware dat wordt gebruikt om gegevens dicht bij de bron te verwerken. In plaats van video's of geluid naar een gecentraliseerde processor te sturen, worden ze op de machine zelf verwerkt. Met andere woorden, je vermijdt dat al deze gegevens worden doorgestuurd naar een externe applicatie of een cloud-gebaseerde service. Edge-apparaten worden vaak gebruikt om latentie te verminderen. In plaats van te wachten tot de gegevens over een netwerk reizen, krijg je een onmiddellijk resultaat. Een andere reden om een edge device te gebruiken is om de kosten van bandbreedte te verlagen. Apparaten die gebruik maken van een mobiel netwerk werken mogelijk niet goed in landelijke gebieden. Zelfrijdende auto's maken bijvoorbeeld optimaal gebruik van beide redenen. Elke video-opname naar een centrale server sturen zou te tijdrovend zijn en de totale latentie zou de snelle reacties die we van een autonoom voertuig verwachten in de weg staan. Hoewel dit belangrijke aspecten zijn om te overwegen, ligt de focus van deze blogpost op privacy. Met de General Data Protection Regulation (GDPR) die in 2018 door het Europees Parlement van kracht werd, zijn mensen zich meer bewust geworden van hoe hun persoonlijke informatie wordt gebruikt . Bedrijven moeten toestemming vragen om deze informatie op te slaan en te verwerken. Sterker nog, overtredingen van deze verordening, bijvoorbeeld door geen adequate beveiligingsmaatregelen te nemen om persoonlijke gegevens te beschermen, kunnen leiden tot hoge boetes. Dit is waar edge devices in uitblinken. Ze kunnen een afbeelding of geluidsfragment onmiddellijk verwerken zonder dat er externe opslag of verwerking nodig is. Omdat ze de ruwe gegevens niet opslaan, wordt deze informatie vluchtig. Een randapparaat kan bijvoorbeeld camerabeelden gebruiken om het aantal mensen in een kamer te tellen. Als het camerabeeld op het apparaat zelf wordt verwerkt en alleen de grootte van de menigte wordt doorgestuurd, blijft ieders privacy gewaarborgd. Prototyping met Edge TPU Coral, een submerk van Google, is een platform dat software en hardware tools biedt om machine learning te gebruiken. Een van de hardwarecomponenten die ze aanbieden is het Coral Dev Board . Het is aangekondigd als " Google's antwoord op de Raspberry Pi ". Het Coral Dev Board draait een Linux-distributie gebaseerd op Debian en heeft alles aan boord om prototypes van machine learning-producten te maken. Centraal op het bord staat een Tensor Processing Unit (TPU) die is gemaakt om Tensorflow (Lite) bewerkingen uit te voeren op een energiezuinige manier. Je kunt meer lezen over Tensorflow en hoe het helpt om snel machinaal leren mogelijk te maken in een van onze eerdere blogposts . Als je goed naar een proces van machinaal leren kijkt, kun je twee fasen onderscheiden. De eerste fase is het trainen van een model op basis van voorbeelden, zodat het bepaalde patronen kan leren. De tweede fase is het toepassen van de mogelijkheden van het model op nieuwe gegevens. Bij het dev board hierboven is het de bedoeling dat je je model traint op cloudinfrastructuur. Dat is logisch, want voor deze stap is meestal veel rekenkracht nodig. Zodra alle elementen van je model zijn geleerd, kunnen ze naar het apparaat worden gedownload met behulp van een speciale compiler. Het resultaat is een kleine machine die een krachtig algoritme voor kunstmatige intelligentie kan uitvoeren terwijl hij niet is aangesloten op de cloud . Gegevens lokaal houden met Federated Learning Het bovenstaande proces doet je misschien afvragen welke gegevens worden gebruikt om het model voor machinaal leren te trainen. Er zijn veel openbaar beschikbare datasets die je kunt gebruiken voor deze stap. Over het algemeen worden deze datasets opgeslagen op een centrale server. Om dit te vermijden, kun je een techniek gebruiken die Federated Learning heet. In plaats van de centrale server het volledige model te laten trainen, doen verschillende nodes of edge devices dit individueel. Elk knooppunt stuurt updates over de parameters die ze hebben geleerd, ofwel naar een centrale server (Single Party) of naar elkaar in een peer-to-peer opstelling (Multi Party). Al deze wijzigingen worden vervolgens gecombineerd tot één globaal model. Het grootste voordeel van deze opzet is dat de opgenomen (gevoelige) gegevens nooit de lokale node verlaten . Dit is bijvoorbeeld gebruikt in Apple's QuickType toetsenbord voor het voorspellen van emoji's , op basis van het gebruik van een groot aantal gebruikers. Eerder dit jaar bracht Google TensorFlow Federated uit om applicaties te maken die leren van gedecentraliseerde data. Takeaway Bij ACA hechten we veel waarde aan privacy, net als onze klanten. Het privé houden van uw persoonlijke gegevens en gevoelige informatie is (y)onze prioriteit. Met technieken zoals federated learning kunnen we u helpen uw AI-potentieel te ontketenen zonder dat dit ten koste gaat van de gegevensbeveiliging. Benieuwd hoe dat precies in jouw organisatie zou werken? Stuur ons een e-mail via ons contactformulier en we nemen snel contact met je op.