De laatste tijd is er door onder andere de AVG/GDPR steeds meer aandacht voor het maskeren van (privacy)gevoelige gegevens. Organisaties doen dit meestal om deze gegevens ook buiten hun live omgeving te kunnen gebruiken. Ze willen bijvoorbeeld betrouwbaar kunnen testen of analyses kunnen doen. Tegelijkertijd willen ze het risico op een datalek minimaliseren en de privacy van hun klanten, patiënten of huurders beschermen.
Door de gevoelige gegevens te maskeren, maak je ze onherleidbaar. Je zorgt er dus voor dat de gegevens niet meer aan een ‘echt’ persoon te koppelen zijn. Dit kun je bijvoorbeeld doen door alle namen te vervangen door ‘xxx-jes’. Keerzijde van deze manier van maskeren is dat de gegevens dan minder representatief worden voor de ‘echte’ situatie. Je mist dan bijvoorbeeld diakrieten en andere leestekens die in een live situatie vaak voor onverwachte problemen zorgen.
Maskeren
Dit kun je oplossen door gegevens te maskeren waarbij je de representativiteit behoudt. Een voorbeeld hiervan is het vervangen van de ‘echte’ namen door namen van een zelf samengestelde lijst. Of het dusdanig aanpassen van een geboortedatum, zodat de leeftijd in jaren gelijk blijft.
Maar los van de discussie hoe je de gegevens gaat maskeren, speelt altijd nog de vraag wie de gegevens gaat maskeren. Met andere woorden, gaat u als gebruiker van een applicatie zelf op zoek naar een oplossing om de gegevens te maskeren, of vindt u dat de leverancier van de applicatie een oplossing hiervoor moet aanbieden?
In eerste instantie lijkt de optie dat de leverancier een kant en klare oplossing aanbiedt, erg aantrekkelijk. Immers, als gebruiker kunt u er dan van uit gaan dat de oplossing goed samenwerkt met de applicatie. Bovendien zorgt het ervoor dat u als gebruiker zelf geen tijd en energie hoeft te investeren in het zoeken naar een passende oplossing.
Nadelen
Maar er kleven ook twee grote potentiële nadelen aan deze oplossing. De eerste is dat de representativiteit van de gemaskeerde data onder druk komt te staan. Veel softwareleveranciers die zelf een oplossing aanbieden, kiezen er namelijk voor om een relatief simpel script te (laten) ontwikkelen om de gegevens te maskeren. Dit zorgt dan voor de situatie die we eerder beschreven waarbij namen bijvoorbeeld vervangen worden door ‘xxx-jes’ en dat leeftijden allemaal gewijzigd worden in dezelfde datum.
Dit eerste nadeel is simpel te ondervangen door als softwareleverancier goed na te denken over de manier van maskeren. Zo ken ik voorbeelden van softwareleveranciers die hun klanten een volwassen oplossing aanbieden waarmee de data onherleidbaar gemaakt wordt en representatief blijft.
Het tweede potentiële nadeel heeft echter een wat meer fundamenteel karakter. Als een softwareleverancier een oplossing aanbiedt, dan werkt deze oplossing met de applicatie waar die voor aangeboden wordt. Dit klinkt misschien als een open deur, maar de impact is groot.
Stel dat de leverancier van uw erp of epd een oplossing aanbiedt, dan is deze oplossing ontwikkeld voor dat erp of epd. Resultaat van het maskeren is dan bijvoorbeeld dat cliënt Jan na het maskeren Piet heet. Maar stel dat de gegevens van deze cliënt ook in een andere applicatie gebruikt worden voor bijvoorbeeld de facturatie of iets dergelijks. Hoe zorgt u dan dat cliënt Jan ook daar voortaan als cliënt Piet weergegeven wordt? Met andere woorden, hoe borgt u dat de gegevens consistent over de hele keten gemaskeerd worden. Dit is met name relevant zodra de keten bestaat uit applicaties van verschillende leveranciers. En laat dat nu bijna altijd de situatie zijn…
Zie hier het probleem, de leverancier van uw erp of epd voelt zich verantwoordelijk voor zijn applicatie en biedt daar een oplossing voor. Net zoals de leverancier van uw facturatiepakket misschien een oplossing aanbiedt voor zijn pakket. Voor u als klant betekent dit dat u extra kosten maakt aangezien u voor elk pakket apart een oplossing moet aanschaffen en het zorgt ervoor dat de data niet meer consistent over de keten gebruikt kan worden. Een echte ketentest is hiermee dus niet langer mogelijk!
Oplossing van leverancier
Betekent dit dan dat het geen goed idee is als een softwareleverancier zelf een oplossing aanbiedt, nee zeker niet! Want er zijn ook voorbeelden van leveranciers die dit probleem onderkennen en een oplossing aanbieden waarmee het mogelijk is om gegevens wel consistent te maskeren. Zij doen dat dan door een oplossing te kiezen waarbij de gegevens op bestandsniveau gemaskeerd worden. Deze gemaskeerde gegevens kunnen vervolgens in hun eigen applicatie teruggeplaatst worden en ook in alle andere applicaties in de keten.
Dit lost beide problemen die eerder geschetst werden op: u hoeft maar één oplossing aan te schaffen en de gegevens blijven consistent. Zodra u namelijk een oplossing hebt voor uw bronsysteem, kunt u alle gekoppelde systemen bijwerken. Dit scheelt tijd en geld en een ketentest blijft mogelijk!
Op deze manier heeft u als klant feitelijk het beste van twee werelden: u hebt de beschikking over een door de leverancier ondersteunde oplossing om de gegevens te maskeren en u kunt de keten consistent houden. De combinatie van de ondersteuning door de leverancier, het behouden van de representativiteit en het kunnen bieden van een consistente ketenomgeving, blijkt dan vaak de ideale oplossing te zijn.
En dat brengt ons bij het antwoord op de vraag uit de titel van deze blog ‘zou data masking een integraal onderdeel moeten zijn van de applicatie’?
Ik ben van mening dat dit in principe de beste oplossing is. Randvoorwaarde hierbij is dat de data op een slimme manier gemaskeerd wordt zodat de gegevens onherleidbaar gemaakt worden en representatief blijven. Daarnaast moet het maskeren zo ingericht worden dat de gegevens consistent blijven over alle applicaties heen. Om dit te bereiken ziet u dat leveranciers van een applicatie vaak de samenwerking zoeken met gespecialiseerde aanbieders van data masking software. Als klant profiteert u dan van de ondersteuning door de leverancier en u hebt de beschikking over een volwassen data masking-oplossing. Wat mij betreft het meest optimale scenario!
