Data masking als integraal onderdeel van een applicatie

Data masking als integraal onderdeel van een applicatie

Data masking als integraal onderdeel van een applicatie. Goed idee of toch maar niet?

De laatste tijd is er door o.a. 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 de in een live situatie vaak voor onverwachte problemen zorgen.

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, ga je als gebruiker van een applicatie zelf op zoek naar een oplossing om de gegevens te maskeren, of vind je dat de leverancier van de applicatie een oplossing hiervoor moet aanbieden?

In 1e instantie lijkt de optie dat de leverancier een kant en klare oplossing aanbiedt, erg aantrekkelijk. Immers, als gebruiker kun je er dan van uit gaan dat de oplossing goed samenwerkt met de applicatie. Bovendien zorgt het ervoor dat je als gebruiker zelf geen tijd en energie hoeft te investeren in het zoeken naar een passende oplossing.

Maar er kleven ook twee grote potentiele 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 kennen wij voorbeelden van softwareleveranciers die hun klanten een volwassen oplossing aanbieden waarmee de data onherleidbaar gemaakt wordt en representatief blijft.

Het tweede potentiele 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 kinkt misschien als een open deur, maar de impact is groot.

Stel dat de leverancier van jouw 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 o.i.d. Hoe zorg je dan dat cliënt Jan ook daar voortaan als cliënt Piet weergegeven wordt? Met andere woorden, hoe borg je 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 jouw ERP of EPD voelt zich verantwoordelijk voor zijn applicatie en biedt daar een oplossing voor. Net zoals de leverancier van jouw facturatiepakket misschien een oplossing aanbiedt voor zijn pakket. Voor jou als klant betekent dit dat je extra kosten maakt aangezien je 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!

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: je hoeft maar 1 oplossing aan te schaffen en de gegevens blijven consistent. Zodra je namelijk een oplossing hebt voor jouw bronsysteem, kun je alle gekoppelde systemen bijwerken. Dit scheelt tijd en geld en een ketentest blijft mogelijk!

Op deze manier heb je als klant feitelijk het beste van twee werelden: je hebt de beschikking over een door de leverancier ondersteunde oplossing om de gegevens te maskeren en je kunt je keten consistent houden. Als EntrD ondersteunen wij steeds meer leveranciers die hun klanten op deze manier een oplossing willen bieden. 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’? Wij zijn 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 zie je dat leveranciers van een applicatie vaak de samenwerking zoeken met gespecialiseerde aanbieders van data masking software. Als klant profiteer je dan van de ondersteuning door de leverancier en je hebt de beschikking over een volwassen data masking oplossing. Wat ons betreft het meest optimale scenario!