Hoe pseudoniemen persoonlijke gegevens extra beschermen

Smals ontwikkelde drie technieken waarmee gevoelige gegevens van burgers extra beschermd worden met behulp van pseudoniemen.

Binnen de publieke sector zijn er heel wat systemen die gevoelige informatie van personen verwerken, waaronder medische en sociale gegevens. Deze data zijn erg waardevol, ook voor interne en externe kwaadwilligen en dienen dus adequaat beschermd te worden.

Cybersecurity bestaat uit een ruime set van maatregelen en technieken, waaronder policies, firewalls, toegangscontrole en vercijfering. Identifier pseudonimisatie situeert zich op hetzelfde lage niveau als vercijfering: in de datalaag die direct de data zelf beschermt. Het is een techniek die toelaat gegevens niet langer onder identifiers zoals rijksregisternummers te verwerken, maar onder pseudoniemen. Dit zijn unieke codes die enkel met een sleutel terug om te zetten zijn naar het oorspronkelijke rijksregisternummer. Bovendien kunnen ze enkel gebruikt worden door een specifieke applicatie of binnen een specifieke context.

Smals Research ontwikkelde drie verschillende systemen voor identifier  pseudonimisatie: blinde pseudonimisering, structuurbehoudende pseudonimisering en “Oblivious Join”.  Deze systemen zijn bovendien nuttige bouwstenen om de GDPR na te leven. Kristof Verslype, bezieler van deze systemen, keek hiervoor tijdens een webinar naar de concrete behoefte binnen de sociale zekerheid en gezondheidssector.

Op 10 oktober 2024 geeft Smals een presentatie op Devoxx van 9u30 tot 10u20. Meer informatie daarover vind je hier.

Structuurbehoudende pseudonimisering

Bij de ontwikkeling van software worden verschillende fases in gescheiden omgevingen doorlopen: de testfase wordt doorgaans gevolgd door de acceptiefase en ten slotte is er de productiefase. Deze procedure moet garanderen dat alles foutloos verloopt eens de applicatie live gaat en wordt bij elke update opnieuw doorlopen.

In de praktijk worden er in de test- en acceptatiefasen regelmatig persoonlijke gegevens van burgers gebruikt. Dat is onwenselijk en gaat onvermijdelijk gepaard met veiligheidsrisico’s. Dankzij de structuurbehoudende pseudonimisering wordt de privacy van burgers in de test- en accceptatiefase van reeds bestaande applicaties beter beschermd.

Het is een courante praktijk om regelmatig een snapshot te maken van de gegevens in de productie-omgeving om ze vervolgens te importeren in de acceptatie- of testomgeving. Bovenstaande tabel toont fictieve snapshot met persoonsgegevens uit de productieomgeving. Om de privacy te verbeteren worden twee operaties uitgevoerd voorafgaand aan een import in de acceptatie- of testomgeving.

Een eerste operatie, de pseudonimisatie, vervangt rijksregisternummers door pseudoniemen. Deze pseudoniemen hebben dezelfde structuur als de originele rijksregisternummers. Dit structuurbehoudende karakter is noodzakelijk aangezien de applicatie en onderliggende database enkel overweg kunnen met iets met de structuur van een rijksregisternummer. Bij de ongestructureerde identifiers, zoals naam en voornaam, wordt een shuffle (column-wise permutation) uitgevoerd, waarbij de voor- en achternamen letterlijk door elkaar geschud worden. De ‘shuffle’ gebeurt lokaal door de organisatie, terwijl voor de pseudonimisatie beroep gedaan wordt op een dienst van Smals.

Communicatie tussen de toepassing in acceptatie en de buitenwereld moet mogelijk blijven. Dit verloopt via een proxy, die met behulp van de pseudonimiseringsdienst van Smals de pseudoniemen in uitgaande berichten vervangt door de oorspronkelijke rijksregisternummers, en de rijksregisternummers in binnenkomende berichten vervangt door pseudoniemen.

De structuurbehoudende pseudonimiseringsdienst van Smals is ontwikkeld als een generieke dienst. Dit betekent dat heel wat organisaties er gebruik van kunnen maken indien ze dit wensen, voor een brede waaier aan toepassingen. Welke operaties er lokaal nodig zijn, hangt af van de concrete toepassing. Een ‘shuffle’ volstond bij de klant waarmee Smals samenwerkt, maar dit zal wellicht niet altijd het geval zijn. Het meer generieke aspect, zijnde het omzetten van identifiers in pseudoniemen en vice versa, werd in de Smals dienst ondergebracht.

Wanneer die dienst gebruik zou maken van traditionele technologie, zou deze een tabel met rijksregister-pseudoniem-koppels moeten bijhouden per test- of acceptatieomgeving die van de dienst gebruik maakt. Het resultaat zou een groot aantal tabellen zijn, die potentieel honderdduizenden of meer rijen bevatten. Die tabellen moeten dan stuk voor stuk bewaard worden, wat veel opslag vereist. Bovendien wijzigen de tabellen continu omdat er regelmatig burgers bijkomen (of verdwijnen). Dit zorgt voor extra complexiteit en vormt een uitdaging op het vlak van opslag en synchronisatie.

De dienst van Smals werkt niet met tabellen, maar met compacte 32-bytes cryptografische sleutels, die over een langere tijd constant blijven. Pseudoniemen worden on the fly berekend op basis van binnenkomende rijksregisternummers (of omgekeerd). De sleutels kunnen beter beschermd worden dan grote tabellen door ze te bewaren en te beheren in Hardware Security Modules (HSM). Die zijn speciaal gebouwd om dergelijke cryptografische sleutels te beveiligen. Bovendien is de entiteit die de veilige data bewaart een andere entiteit dan de organisatie die de sleutel beheert (separation of duties). Dit resulteert in een extra niveau van veiligheid. Een bijkomend voordeel van een centrale dienst is dat organisaties die van de dienst gebruik maken zich niets hoeven aan te trekken van het sleutelbeheer.

Structuurbehoudende pseudonimisering is heel eenvoudig qua infrastructuur, opslag en synchronisatie.

Kristof Verslype, Smals Research

Deze structuurbehoudende pseudonimisering kan de privacy van burgers aanzienlijk verhogen in de acceptatie –en testomgeving van reeds bestaande applicaties, maar zit nog in een experimentele fase. Smals bekijkt momenteel hoe deze dienst live gebracht kan worden.

eHealth blinde pseudonimisering

Bij nieuwe applicaties gaat Smals nog een stap verder dankzij privacy-by-design, waarbij ze reeds bij het ontwerp van de toepassing rekening houden met de privacy van de burger. Zo worden persoonsgegevens niet enkel in test- en acceptatieomgevingen beter beschermd door pseudoniemen, maar ook in de productieomgeving. Dit was de aanpak bij de blinde pseudonimiseringsdienst van eHealth, die vandaag reeds in de praktijk ingezet wordt bij artsen voor het beschermen van medische persoonsgegevens, in het kader van onder meer verwijsvoorschriften. Met een verwijsvoorschrift schrijft een zorgverlener de patiënt verschillende types zorg voor, andere dan farmaceutische zorg (bijvoorbeeld zorg door een kinesitherapeut, een thuisverpleegkundige…).

lees ook

Introductie tot de nieuwe eHealth pseudonimiseringsdienst

Net zoals bij de structuurbehoudende pseudonimisering, is er een separation of duties: de pseudonimiseringsdienst kent de pseudonimiseringssleutels maar heeft geen toegang tot persoonsgegevens. De achterliggende dienst ziet de gepseudonimiseerde persoonsgegevens, maar heeft geen toegang tot de pseudonimiseringssleutels.

Een aanpak die in het verleden toegepast werd was een volledige encryptie van de persoonsgegevens, met uitzondering van het rijksregisternummer. Dit systeem is enerzijds heel veilig, anderzijds beperkt zo’n volledige encryptie de functionaliteit. Zo was het niet mogelijk om input te valideren, er statistieken uit te halen of er analyses op te doen.

Om toch deze functionaliteiten te behouden, zonder dit ten koste te laten gaan van de privacy, werd een nieuwe aanpak uitgetekend. Bovenstaande figuur illustreert het scenario waarbij een arts een voorschrift uitgeeft en de voorschriftendata onder een pseudoniem bewaard wordt door een centrale dienst.

Om te vermijden dat de pseudonimiseringsdienst profielinformatie over burgers zou kunnen opstellen op basis van metadata, verbergen we voor die dienst inkomende en uitgaande rijksregisternummers en pseudoniemen. Dit wordt gerealiseerd aan de hand van de paarse operaties (blind en unblind). Blindering is een kortstondige encryptie met een eenmalige sleutel die enkel gekend is door de arts. De arts blindeert het rijksregisternummer en stuurt het naar de pseudonimiseringsdienst. Die dienst zet de geblindeerde identifier om naar een geblindeerd pseudoniem (pseudonymise) en stuurt het resultaat terug naar de arts die dat als enige kan unblinden.

Hoewel dit op zich al een sterk model is, willen we evenmin dat de pseudoniemen zichtbaar zijn voor de dokter. Dit is immers een extra identificatierisico: idealiter ziet elke partij enkel datgene wat het sensu stricto hoort te zien. Daarom worden nog twee stappen toegevoegd (oranje kaders): De pseudonimiseringsdienst encrypteert het geblindeerde pseudoniem en stuurt dit terug naar de arts. De arts kan enkel de blindering verwijderen. Zo blijft enkel een geëncrypteerd pseudoniem over. Dat wordt vervolgens naar de centrale voorschriftendienst gestuurd die het als enige kan decrypteren. Samengevat ziet de arts enkel het rijksregisternummer, ziet de dienst die persoonsgegevens bewaart enkel het pseudoniem, en ziet de pseudonimiseringsdienst geen van beide.

Om hier nog een extra veiligheidslaag op te leggen, voegt de pseudonimseringsdienst context toe aan het geblindeerde pseudoniem voordat het geëncrypteerd wordt. Dat wordt door de achterliggende dienst geverifieerd (blauwe kaders). Minimaal zal de pseudonimiseringsdienst een timestamp toevoegen. Hierdoor kunnen de geëncrypteerde pseudoniemen die de zorgverstrekker ontvangt slechts gedurende een beperkte tijd gebruikt worden, wat misbruik tegengaat.

Blinde pseudonimisering zorgt er zo voor dat elke partij enkel de strikt nodige informatie kan raadplegen en er geen informatie lekt naar de pseudonimiseringsdienst. Bovendien gebruikt dit systeem aan de kant van de zorgverstrekker geen sleutels die langere tijd bewaard moeten worden. Dat is een groot voordeel, aangezien adequaat sleutelbeheer lastig is en niemand dit eigenlijk echt graag doet. Het systeem biedt een hoge mate van veiligheid en kan een belangrijke rol spelen in het reduceren van datalekken.

Oblivious Join

Voor onderzoeksdoeleinden, bijvoorbeeld vanuit universiteiten, dienen geregeld persoonsgegevens afkomstig van verschillende bronnen gekruist en gepseudonimiseerd te worden. Dat laatste is een noodzakelijke maatregel die helpt te verhinderen dat een onderzoeker persoonsgegevens kan koppelen aan natuurlijke personen. Dergelijke kruisingsprojecten kunnen vrij complex worden, in het bijzonder wanneer de databronnen zelf niet autonoom kunnen bepalen over welke burgers ze data moeten aanleveren. Zo moest het Belgisch kankerregister in een eerder kruisingsproject data aanleveren over burgers met Multiple Sclerose (MS), zonder zelf te weten te komen wie die ziekte heeft.

Om dergelijke  kruisingsprojecten op een elegante, kostenefficiënte en veilige manier aan te pakken, ontwikkelde Smals ‘Oblivious Join’. Daarbij is er geen datalekkage; de databronnen leren geen nieuwe persoonsgegevens door aan dergelijke projecten deel te nemen, en de dataontvanger (de collector) komt enkel gepseudonimiseerde data te weten die noodzakelijk is in het kader van het onderzoek. De collector is nog niet de onderzoeker zelf, maar moet je zien als een intermediaire partij.

Oblivious Join is bovendien gedistribueerd; er is noch een centrale pseudonimiseringsdienst, noch een coördinerende centrale partij die betrokken is bij de uitvoering van kruisingsprojecten. Alles verloopt door middel van samenwerking tussen de databronnen en de collector.

Oblivious Join werkt in drie stappen. Stap één is een geautomatiseerd protocol dat cryptografische afspraken tussen de databronnen maakt. Na die eerste stap, kunnen de databronnen op zichzelf data gaan pseudonimiseren en vercijferen die vanuit hun standpunt mogelijk relevant kan zijn voor het onderzoeksproject, en het resultaat versturen naar de collector. Dankzij de afspraken gemaakt in de eerste stap kunnen we garanderen dat de collector in de derde en laatste stap enkel gepseudonimiseerde data kan decrypteren en koppelen die nodig zijn in het kader van het onderzoeksproject.

In het eerdere voorbeeld betekent dit dat het Belgisch Kankerregister eerst afspraken maakt met een databron die wel weet wie MS heeft. Vervolgens pseudonimiseert en vercijfert het gegevens over alle burgers die die kankerdiagnose kregen en stuurt het resultaat naar de collector. De collector kan enkel die records afkomstig van het Belgisch Kankerregister decrypteren die betrekking hebben tot mensen met MS.

In een Oblivious Join protocol zien databronnen enkel de identifiers(rijksregisternummers)en geen pseudoniemen, de collector ziet enkel de pseudoniemen maar niet de identifiers. Er is geen tussenkomst van een pseudonimiseringsdienst. Het valt al op dat de collector hier een belangrijke rol speelt, en wordt dan ook verwacht om irrelevante cijferteksten meteen te verwijderen. Verder zal de collector extra controles uitvoeren op de data om na te gaan of het identificatierisico van individuele records niet te groot is bij de uitvoering van het onderzoek. Vervolgens kan het op een gecontroleerde manier de onderzoeker toegang tot de data geven.

Hoe verloopt dit in de praktijk? Zowel de databronnen als de collector downloaden eerst een stukje software: de Oblivious Join client. Daarnaast ontvangen ze van de coördinerende partij een project-specifiek JSON-bestand, dat alle relevante informatie bevat om het protocol geautomatiseerd uit te voeren. Elke databron maakt bovendien een CSV-bestand aan met alle geïdentificeerde persoonsgegevens die mogelijk relevant zijn voor het onderzoek. De databronnen geven dan zowel het JSON-bestand als het CSV-bestand aan de client, terwijl de collector enkel het JSON-bestand als input geeft. Het protocol wordt vervolgens uitgevoerd, wat inhoudt dat de verschillende partijen met elkaar communiceren. Als resultaat van het protocol verkrijgt de collector de minimaal noodzakelijke, gepseudonimiseerde persoonsgegevens die vereist zijn in het kader van het onderzoek (het zwarte CSV-bestand in de figuur). Dit gebundelde CSV-bestand omvat de strike noodzakelijke, gepseudonimiseerde data afkomstig van de drie databronnen die relevant zijn voor het onderzoek.

Samengevat is Oblivious Join privacy-vriendelijk, veilig, gedistribueerd en eenvoudig in gebruik. Het vormt een veilig manier om data te ontsluiten, maar zit vandaag nog in de experimentele fase.

Van experimenteel tot vandaag bruikbaar

Bovenstaande projecten bevinden zich elk in een ander stadium, van een experimentele fase tot een reeds gebruikte tool in de praktijk. Er is geen one-size-fits-all-oplossing als het gaat over pseudonimiseringstechnieken. Welke van oplossing het meest geschikt is hangt uiteraard af van de concrete vereisten.

Eerder publiceerde Smals al twee artikelen rond pseudonimisatie op ITdaily. Wie graag dieper wil duiken in het eHealth-project, kan hier terecht. Verder is er ook format-preserving encryptie (FPE) dat werd gestandaardiseerd door het NIST. Alles daarover kan je hier lezen.

————————————————-
Dit is een redactionele bijdrage in samenwerking met Smals. Op 10 oktober 2024 geeft Smals een presentatie op Devoxx van 9u30 tot 10u20. Meer informatie daarover vind je hier.

nieuwsbrief

Abonneer je gratis op ITdaily !

  • This field is for validation purposes and should be left unchanged.
terug naar home