Architectuur

Sleutels in plaats van persoonsgegevens

We werken aan een reserverings- en uitwisselingssysteem dat alleen sleutels bewaart. Alleen wie daar recht op heeft, zet een sleutel om in echte gegevens.

Door Bas Leijder HavenstroomAlgemeen directeur21 oktober 2026 · 4 min lezenRead in English

Veel oude, roestige sleutels aan haakjes tegen een muur — Foto: Iolandino Baiano via Unsplash

We werken aan een concept voor een reserveringssysteem, en breder voor gegevensuitwisseling tussen bedrijven, dat geen echte persoonsgegevens meer rondstuurt. In de systemen staan alleen sleutels. Alleen bepaalde mensen, systemen of bedrijven kunnen een sleutel omzetten in de echte naam, het adres of het telefoonnummer. Lekt er ergens iets, dan ligt er een lijst met sleutels op straat in plaats van een lijst met mensen.

Waarom we hieraan werken

Vandaag moesten beheerders overal PHP patchen, omdat twee lekken een aanvaller code lieten uitvoeren met de rechten van de webserver. Erik schreef daarover in PHP2Shell: snel patchen vraagt voorbereiding. Komt iemand zo binnen, dan kan die bij alles waar de webserver bij kan, en dat is meestal ook de database.

Het lek zit ook vaak bij een ander bedrijf dan waar de klant iets kocht. Logistiek bedrijf CEVA Logistics werd eind juli gehackt en daarbij zijn verzendgegevens gestolen. Klanten van onder meer bol, De Bijenkorf, ING, Ajax en Ace & Tate kregen bericht. Bij bol ging het om naam, adres, contactgegevens, de bestelde producten en trackinglinks. Twaalf bedrijven meldden het lek bij de Autoriteit Persoonsgegevens.

Die klanten hadden zelf niets met CEVA afgesproken. Hun gegevens stonden daar omdat een pakket bezorgd moest worden.

Hoe het werkt

Het idee is eenvoudig. Komt er een reservering binnen, dan gaan de naam, het telefoonnummer en het e-mailadres van de gast naar een aparte kluis. Het reserveringssysteem en alle partijen die meedoen, krijgen een sleutel: een willekeurige code die niets over de gast zegt.

Moet iemand de gast echt spreken of iets bezorgen, dan vraagt die de kluis om de sleutel om te zetten. De kluis kijkt wie het vraagt, welk gegeven die nodig heeft en of dat nu nodig is. Een hotel krijgt het telefoonnummer rond het verblijf, een bezorger het adres op de dag van bezorging. Elke omzetting wordt gelogd.

Voor één gegeven hebben we dit al gebouwd. Voor een online reisbureau krijgen hotels een 020-nummer in plaats van het 06-nummer van de gast. Het echte nummer krijgt een hotel pas na verificatie met het boekingsnummer en de postcode. Hoe dat werkt, schreef ik in telefoonnummers van gasten buiten hotelsystemen houden. Het nieuwe concept trekt dat door naar alle persoonsgegevens en naar elke partij in de keten.

Wat het oplost en wat niet

Wordt een partner gehackt, dan vindt de aanvaller sleutels. Daar kan die zonder de kluis niets mee. Hetzelfde geldt voor een applicatieserver met een lek als PHP2Shell: in de database staan geen namen en telefoonnummers.

De kluis zelf wordt dan wel het doelwit. Die moet je beter beveiligen dan de rest, met weinig toegang, weinig code en strakke logging. Toch is dat één systeem om goed te doen, in plaats van de systemen van elke partner waar je gegevens naartoe stuurt.

De AVG blijft gewoon gelden. De Europese privacytoezichthouders schreven in hun richtlijnen over pseudonimisering dat zulke gegevens persoonsgegevens blijven, zolang iemand ze met aanvullende informatie aan een persoon kan koppelen. Ze schrijven ook dat pseudonimisering risico's kan verminderen. Laat je eigen situatie dus wel toetsen.

En niet elk proces kan zonder echte gegevens. Een bezorger moet uiteindelijk een adres zien en een hotel moet een gast kunnen bellen. Het concept bepaalt wie dat ziet en wanneer, het haalt de gegevens niet weg.

Waar we nog over nadenken

We zoeken nog uit hoe je rechten tussen bedrijven regelt. Een partner moet tijdelijk iets mogen zien, en dat recht moet ook weer verlopen. Hoe leg je dat vast zonder dat elke partner een eigen koppeling moet bouwen?

Ook beschikbaarheid speelt mee. Ligt de kluis eruit, dan ziet niemand de gegevens. Dat is veilig, maar een hotel dat een gast niet kan bereiken, heeft daar niets aan.

Of dit voor elke sector werkt, weet ik nog niet. Voor reserveringen en voor bedrijven die klantgegevens met leveranciers delen, zoals een webshop met een bezorgdienst, past het goed. Mijn advies is om nu al voor elk gegeven dat je met een partner deelt na te gaan of die het altijd nodig heeft, of alleen op een bepaald moment. Wat we verder van bekende lekken leren, staat in wat we leren van bekende hacks.

Meer weten

Wil je meer weten over het concept, of heb je een proces waar het bij zou passen? Stel je vraag in de chat op deze pagina, of laat je gegevens achter via het contactformulier. Dan nemen we contact met je op.

Bronnen

Veelgestelde vragen

Wat is het verschil tussen een sleutel en een persoonsgegeven?

Een sleutel is een willekeurige code die in de plaats van een naam, adres of telefoonnummer staat. Zonder toegang tot de kluis waar de echte gegevens liggen, zegt die code niets over de persoon.

Valt een systeem met alleen sleutels nog onder de AVG?

Ja. Volgens de Europese privacytoezichthouders blijven gepseudonimiseerde gegevens persoonsgegevens zolang iemand ze met aanvullende informatie aan een persoon kan koppelen. Pseudonimisering kan de risico's wel verminderen.

Wie kan een sleutel omzetten in echte gegevens?

Alleen de mensen, systemen of bedrijven die daar recht op hebben, voor het gegeven dat ze nodig hebben en op het moment dat ze het nodig hebben. Elke omzetting wordt gelogd.

Over de auteur

Bas Leijder Havenstroom

Algemeen directeur

Bas richtte samen met Erik Schoorl ESBL op, een van de twee bedrijven achter Brainpower Group. Hij is algemeen directeur van ESBL B.V. en het eerste aanspreekpunt voor klanten.

Meer van Bas