Datamasking op bestands- of op databaseniveau?

We hebben al veel geschreven over de privacywetgeving en wat die betekent voor bijvoorbeeld testen. Datamasking is een oplossing die ervoor zorgt dat je buiten de productieomgeving kunt werken met representatieve data. Bijvoorbeeld om software te testen of analyses te maken. Maar hoe wérkt het precies? En dan vooral: hoe werkt datamasking in de softwareketen?

Er zijn grofweg twee manieren om persoonsgegevens te anonimiseren.

• Gegevens direct in de database manipuleren, of
• Bestanden creëren met alleen de te anonimiseren gegevens.

Direct in de database

De eerste oplossingen voor datamasking werkten bijna uitsluitend direct op de database. Dit werkt als volgt: bij de implementatie wordt aan elk te anonimiseren veld in de database een maskeerregel gekoppeld. Nadat er vervolgens een connectie is gemaakt tussen de maskeeroplossing en de database, wordt de data geanonimiseerd. Dit werkt prima, zeker zolang een organisatie slechts één type database gebruikt.

Deze oplossing heeft ook nadelen. Zo moet je voor elk type database de datamasking-oplossing opnieuw implementeren. Immers, de structuur van de nieuwe database is anders en daarmee verandert ook de configuratie van de datamasking-oplossing.

Misschien nog wel een groter probleem is het bewaken van dataconsistentie. In een ketenomgeving is dat een grote uitdaging. Alleen als de datamasking-oplossing voorziet in de mogelijkheid een connectie te maken met elk type database in de keten, ontstaat een consistente dataset. En dat zelfs alleen als in elke database op dezelfde manier een relatie te leggen is tussen de gegevens uit de ene en uit de andere database.

Ook de tijd is hier een vijand. Elke database moet apart worden geanonimiseerd. Dat is tijdrovend, nog los van het feit dat ook de beheersinspanning groot is. Elke configuratie moet apart worden beheerd en elke wijziging in een database leidt tot een aanpassing van de bijbehorende maskeerconfiguratie.

Samenvattend: in een omgeving waar slechts sprake is van één database, werkt datamasking direct op de database prima. Maar zodra je data wilt gaan delen binnen een keten (al dan niet extern), kleven er grote nadelen aan dit soort oplossingen.

Maskeren op bestandsniveau

Sinds een aantal jaar bestaat er een andere mogelijkheid om data te anonimiseren. Hierbij wordt de data op bestandsniveau gemaskeerd. Hoe werkt dit? De eerste stap is: kijken wat het bronsysteem is. Met andere woorden: waar worden de te maskeren gegevens voor de eerste keer opgeslagen? Dat kan in één database zijn, maar ook in meerdere.

In de tweede stap wordt per brondatabase een bestand gegenereerd dat alleen de te maskeren gegevens bevat. Dus stel dat een database NAW gegevens en contractgegevens bevat, waarbij alleen de NAW gegevens persoonsgegevens zijn, dan wordt een bestand gegenereerd met alleen de NAW gegevens. Dit bestand bevat slechts een fractie van de totale data.

In de volgende stap wordt dit bestand geanonimiseerd. Om dit te kunnen doen is de datamasking-oplossing eenmalig geconfigureerd. Tijdens deze initiële implementatie is per soort veld in het bestand aangegeven welke maskeerregel moet worden gebruikt. Bovendien kan op deze manier de relatie tussen velden, bijvoorbeeld een gezinssamenstelling, behouden blijven.

Tijdens de laatste stap wordt het geanonimiseerde bestand teruggeplaatst in de doeldatabase(s). Dit kan het bronsysteem zijn, maar dit kan ook een andere database zijn. Sterker nog, omdat dit type oplossing werkt op bestandsniveau, kan in één keer een hele keten worden bijgewerkt. Ook als er sprake is van verschillende typen databases!

Eenmalig en snel

Maskeren op bestandsniveau in plaats van op databaseniveau, heeft daarom een aantal grote voordelen.

• Per bronsysteem hoef je de datamasking-oplossing maar één keer te configureren, ongeacht het aantal doeldatabases in de keten.
• Wijzigingen in het datamodel leiden praktisch nooit tot wijzigingen in de configuratie van de datamasking-oplossing. Zolang het bestand gelijk blijft maakt het voor de datamasking-oplossing niet uit of de gegevens initieel ergens anders uit de database kwamen.
• De organisatie kan een deel van het implementatiewerk zelf doen, bijvoorbeeld het genereren van bestanden. Dit versnelt de implementatie en maakt het goedkoper. Ook wordt het beheer daarna gemakkelijker.
• Maskeren op bestandsniveau is volledig database-onafhankelijk. Zolang er een bestand kan worden gemaakt dat na het maskeren weer kan worden teruggeplaatst, is het mogelijk de data te anonimiseren. Vooral in complexe ketenomgevingen biedt dit grote voordelen.
• Consistentie over systemen heen kan eenvoudig worden gewaarborgd.
• Maskeren op bestandsniveau is goed te integreren in een continuous delivery
• En de laatste: ook (externe) bestanden waarmee een database wordt gevoed/opgebouwd kunnen worden gemaskeerd. Denk hierbij aan berichten die worden uitgewisseld met bijvoorbeeld een (toe)leverancier.

Ketens worden steeds complexer, dataconsistentie is cruciaal en organisaties automatiseren steeds vaker delen van hun voortbrengingsproces (CD/CI). Daarom is het cruciaal dat een datamasking-oplossing hierbij aansluit. Na implementatie moet je er gewoon geen omkijken meer naar hebben. Het moet je primaire proces ondersteunen, en niet voor extra werk zorgen!