Ik deel graag hoe NovoServe data masking heeft toegepast bij het bouwen van ons eigen interne datawarehouse om gevoelige informatie, zoals de Personally Identifiable Information (PII) van onze klanten, beter te beschermen.
Als bare metal-provider heeft NovoServe een behoorlijk complexe technische architectuur: we beheren diverse systemen voor klantenportalen, netwerkbeheer, server provisioning, boekhouding en meer. Vaak moeten we analyses uitvoeren op gecombineerde data uit deze verschillende systemen. Om dit mogelijk te maken, hebben we ons eigen datawarehouse gebouwd om data uit verschillende bronnen te verzamelen in één omgeving voor analyse en archivering.
We gebruiken data uit ons warehouse voor traditionele business intelligence-rapportages (zoals financiële KPI's), maar ook voor meer technische doelen, zoals het monitoren van dataconsistentie tussen verschillende systemen.
Met grote kennis komt groot risico
Het samenbrengen van veel data is zakelijk gezien erg nuttig, maar introduceert ook nieuwe risico's: bij een datalek in ons datawarehouse zou de data uit vele verschillende systemen in één keer gevaar lopen.
Om de kans op een inbreuk te verkleinen, hebben we uiteraard diverse technische maatregelen genomen, zoals zeer beperkte toegang voor teamleden, een strikte firewall en een dedicated hardware server voor het hosten van de database.
Hoewel we de kans op een inbreuk hebben verkleind met technische maatregelen, ontwerpen we graag met calamiteiten in het achterhoofd: als er toch een inbreuk plaatsvindt, hoe kunnen we de impact van een datalek dan beperken?
Gegevensminimalisatie: redeneren vanuit noodzaak in plaats van overvloed
Waar we in de infrastructuur-wereld vaak pleiten voor "go big", nemen we het tegenovergestelde standpunt in als het gaat om gevoelige data: we hebben liever minder dan meer.
Daarom hebben we onze veilige datawarehouse-infrastructuur niet alleen ontworpen voor beveiliging, maar ook met dataminimalisatie in gedachten. Mocht er een inbreuk plaatsvinden, dan is de beste manier om de impact qua gestolen data te beperken, ervoor zorgen dat de data simpelweg niet in het systeem aanwezig is!
Dit begon met een discussie over hoe we ons datawarehouse wilden gebruiken. Vanaf het begin werd besloten dat het warehouse gebruikt zou worden voor rapportage en analyse, maar niet voor operationele processen zoals facturatie. Dit betekent dat, hoewel sommige data gekoppeld moet worden aan specifieke klanten (bijvoorbeeld om klantspecifieke issues te analyseren), we geen adres- of betaalgegevens van onze klanten in ons datawarehouse nodig hebben.
Ons doel was nooit om zoveel mogelijk data op te slaan in ons warehouse, maar alleen wat nodig was! Dit leidde ons logischerwijs naar data masking.
Data masking: maximaliseren wat er "niet is"
Data masking is een proces waarbij gevoelige informatie (zoals persoonsgegevens) uit een dataset wordt verwijderd, terwijl de bruikbaarheid van de dataset voor de beoogde gebruikers behouden blijft.
Bijvoorbeeld: bij het gebruik van een klantenlijst om de geografische spreiding per land te analyseren, zijn klantnaam, e-mailadres of exacte adressen niet relevant. Deze kunnen worden gemaskeerd voordat de lijst wordt verwerkt. (Voor wie graag een standaard als referentie heeft: ISO 27001 Annex A / ISO 27002:2022 Control 8.11 "Data Masking" beschrijft toepasselijke overwegingen in meer detail.)
In de context van databescherming gaan discussies over informatiebeveiliging vaak over het waarborgen van de vertrouwelijkheid van data. Er is veel aandacht voor maatregelen zoals encryptie, authenticatie/autorisatie en vulnerability management. Echter, Privacy by Design begint bij het begrijpen van de minimale set data die je écht nodig hebt en op basis daarvan de data die je hebt te minimaliseren. Alles wat er niet is, kan ook niet lekken.
Een stukje techniek (SQL & ETL)
Omdat veel van de (open-source) systemen die we gebruiken gebaseerd zijn op SQL-databases, is ons datawarehouse dat ook. Op het laagste niveau gebruiken we ETL (extract-transform-load) om data van de verschillende bronnen naar vergelijkbare schema's in ons warehouse te laden. Hierdoor kunnen we SQL-queries uit ons warehouse zonder veel moeite terugzetten naar de originele systemen.
De originele tabellen bevatten echter vaak gevoelige data. Bijvoorbeeld: klantdata in een billingsysteem bevat niet alleen de bedrijfsnaam, maar ook adresgegevens (nodig voor facturen) en mogelijk zelfs betaalinformatie zoals bankgegevens.
Om de originele tabelschema's te behouden maar de gevoelige informatie weg te laten, hebben we verschillende mechanismen voor data masking geïmplementeerd in de ETL-tool die we gebruiken: In sommige gevallen maskeren we data op basis van specifieke kolommen. In andere gevallen maskeren we data op basis van specifieke rij-criteria.
Door de data te maskeren als onderdeel van het extractieproces bij de bron, zorgen we ervoor dat deze het datawarehouse-systeem nooit binnenkomt. Gemaskeerde rijen worden simpelweg weggelaten, terwijl gemaskeerde kolommen een plaatshouderwaarde krijgen (bijv. 'REDACTED') in plaats van de originele waarde.
Maar het behoud van de originele datastructuur (bijvoorbeeld alle kolommen) stelt ons wel in staat om SQL-queries uit te wisselen tussen productiesystemen en het datawarehouse.
Een data-analist kan een SQL-query ontwikkelen op gemaskeerde tabellen binnen ons datawarehouse om een issue te analyseren. Als het issue wordt gevonden, maar toegang tot gevoelige data nodig is voor de oplossing, kan dezelfde query worden gegeven aan een engineer met de juiste rechten op een productiesysteem om de aanvullende gevoelige waarden te verkrijgen. Onze analisten hebben dus geen toegang tot gevoelige data, maar kunnen wel analyses uitvoeren op productiedata in het warehouse, met de mogelijkheid om hun queries indien nodig over te zetten naar (individuele) productiesystemen.
Veilige infrastructuur waarop je kunt vertrouwen
We draaien ons datawarehouse nu al enkele jaren met data masking en hebben nog nooit spijt gehad van onze beslissing om veel gevoelige data buiten ons warehouse te houden.
Ja, onze data-analisten kunnen sommige zeer klantspecifieke vragen niet beantwoorden op basis van wat we in ons warehouse hebben. En ja, dat is soms wat vervelend voor collega's die dat soort vragen toch proberen te stellen. Maar eerlijk gezegd: dit is data masking die precies werkt zoals bedoeld. We beperken niet alleen de impact van potentiële datalekken, maar we begrenzen ook strikt de toegang tot potentieel gevoelige data voor rollen zoals data-analisten, die daar toch al niet mee horen te werken.
Door onze interne systemen met deze striktheid te ontwerpen—met prioriteit voor Privacy by Design en dataminimalisatie—laten we dezelfde engineering-mindset zien die we toepassen op jouw dedicated servers. Of je nu in FinTech, AdTech of de zorg werkt, je hebt een partner nodig die niet alleen praat over beveiliging, maar het in de architectuur van het bedrijf bouwt. Je kunt erop vertrouwen dat hetzelfde beschermingsniveau wordt toegepast op het netwerk en de hardware waarop jouw bedrijfskritische workloads draaien.
Data masking is een krachtige, maar vaak ondergewaardeerde aanpak van databescherming. We hopen dat het delen van onze aanpak je inspireert om voor Data Protection Day 2026 eens kritisch naar je eigen datapipelines te kijken.
