Gegevensverwerkende software test je met behulp van data. In de meeste testomgevingen mogen testers niet met productiedata werken, daarom gebruiken ze meestal een dataset die speciaal voor testdoeleinden is gemaakt. Hierbij bestaat een spanningsveld tussen bruikbaarheid en beveiliging: hoe realistischer de testdata, hoe meer de software zich bij het testen zal gedragen als in een productieomgeving, maar ook hoe groter het risico dat de testset gegevens onthult die niet in een testomgeving thuishoren.

Hoe maak je een realistische en toch veilige testset? Hoe ga je om met commercieel gevoelige informatie? En met privacygevoelige informatie? Ben je betrokken bij het maken van testdata, of ben je benieuwd hoe Data eXcellence dit aanpakt, lees dan verder.

Inleiding

Organisaties die gegevens opslaan en verwerken, treffen maatregelen om de veiligheid van hun gevoelige gegevens te garanderen. Gevoelige gegevens zijn gegevens die strategisch of commercieel gevoelig zijn of gegevens die privacygevoelig zijn. In dit laatste geval formuleert de GDPR eisen met betrekking tot de vastlegging en verwerking van persoonsgegevens (zie https://www.eugdpr.org/ en https://hulpbijprivacy.nl/).

De veiligheid van gevoelige data vergt een toegangsbeperking en een nauwkeurige administratie voor alle systemen waarin gebruikers met deze gegevens werken. Hierdoor zijn deze gegevens bijvoorbeeld alleen toegankelijk voor een selecte groep medewerkers in een afgeschermde omgeving waarbij het systeem iedere actie (raadplegen, bewerken, verwijderen) logt.

In een ontwikkelomgeving zijn dit soort maatregelen duur en bemoeilijken ze het werk. Daarom gebruiken ontwikkelaars en testers van gegevensverwerkende software testdata: gegevens die – mochten ze onbedoeld “op straat” belanden – geen problemen veroorzaken op het gebied van privacy, geen bedrijfsgeheimen onthullen en geen imagoschade voor de organisatie opleveren.

Testgegevens kun je produceren door fictieve gegevens op te voeren in het systeem waarop getest moet worden. Deze werkwijze heeft echter nadelen:

  • Vervuiling. De aanpak werkt alleen als een aparte omgeving beschikbaar is (applicaties, database) waarin de testgegevens kunnen worden opgevoerd, anders wordt de testset “vervuild” met andere gegevens.
  • Tijdrovend. Het is tijdrovend om een testset van enig volume op te voeren.
  • Bewerkelijk. Het is bewerkelijk om een realistische hoeveelheid historie op te voeren. Bijvoorbeeld hypotheken of pensioenen die al jaren lopen (of juist zijn beëindigd), inclusief transactiehistorie. Of rentewijzigingen in het verleden.
  • Onvoldoende variatie. Het is lastig om voldoende variatie in de portefeuille aan te brengen. Van alle “smaken” moet een voorbeeld worden opgevoerd.
  • Veroudering. Een testset veroudert snel.
  • Soms niet mogelijk. In het geval van dataconversies is de beoogde doelomgeving vaak nog incompleet, waardoor het opvoeren van testdata niet of heel beperkt mogelijk is.

Dit artikel behandelt het anonimiseren van data: het zodanig bewerken van bestaande productiegegevens dat ontwikkelaars en testers er in een onbeveiligde omgeving mee mogen werken. We hebben het dan over gestructureerde data in databases. Ongestructureerde gegevens als pdf-bestanden, scans of documenten blijven in dit artikel buiten beschouwing.

Bij dataconversies voer je de anonimisatie uit op data uit de bronsystemen. Door zo’n dataset te anonimiseren en vervolgens de conversiesoftware te draaien met de anonieme data, ontstaat een anonieme testset in het formaat van het doelsysteem:

Hieronder ga ik allereerst in op het anonimiseren van strategisch of commercieel gevoelige data. Hierbij geef ik tips over hoe je een testset kan maken die voldoende variatie heeft zonder dat gevoelige informatie wordt prijsgegeven.

Vervolgens ga ik in op het anonimiseren van privacygevoelige data. Hier speelt vooral de afweging tussen realisme en de veiligheid.

Anonimiseren van strategisch of commercieel gevoelige data

Onder “strategische of commerciële gevoeligheid” verstaan we gegevens die losstaand onschuldig lijken, maar die als geheel belangrijke informatie over een organisatie prijsgeven: hoeveel klanten heeft de organisatie, wat is het totaal belegd vermogen, wat is de dekkingsgraad van de zekerheden, welke producten verkoopt de organisatie, wat is de verdeling van de portefeuille, hoeveel provisie krijgt een tussenpersoon, welke winstmarge heeft een product, enz.

Een effectieve manier om de strategische of commerciële gevoeligheid van gegevens weg te nemen is het maken van een selectie: uit de totale gegevensverzameling wordt een subset samengesteld. Deze subset bevat een grote spreiding aan voorkomende waarden, maar de samenstelling van de originele set valt er niet uit af te leiden.

Hoe wordt een selectie gemaakt?

Het maken van een testset met zo groot mogelijke variatie bij zo klein mogelijke hoeveelheid data, kan complex zijn. Vaak voldoet de volgende aanpak:

  1. Bepaal twee of drie eigenschappen die van belang zijn voor de variatie in de dataset (bijvoorbeeld soort dekking bij een verzekering, producttype bij een spaarproduct, aflosvorm bij een hypotheek). Analyseer welke verschijningsvormen van deze eigenschappen in de dataset aanwezig zijn (bijvoorbeeld bij de eigenschap aflosvorm: annuïtair, lineair, aflossingsvrij, spaar, belegging ).
  2. Stel vast welke entiteit de centrale entiteit in de dataset is. In een hypotheekadministratie zal dat bijvoorbeeld de lening zijn, in een klantenadministratie de klant. Dit heet de hoofdentiteit.
  3. Selecteer willekeurig een aantal voorkomens van deze hoofdentiteit voor iedere eigenschap die bij punt 1 is gedefinieerd. Zorg ervoor dat van ieder van deze eigenschappen alle varianten aanwezig zijn. In het genoemde voorbeeld van de aflosvorm: selecteer willekeurige leningen zodat de aflosvormen annuïtair, lineair, aflossingsvrij, spaar en belegging allemaal voorkomen. Het aantal voorkomens van de hoofdentiteit dat geselecteerd wordt, is afhankelijk van de variatie in de totale dataset. Een goed startpunt is 500 tot 1000 stuks.
  4. Maak de dataset consistent. Selecteer uit alle tabellen de gegevens die horen bij de geselecteerde hoofdentiteiten. Bijvoorbeeld: uit de totale set met boekingen worden alleen de boekingen geselecteerd die horen bij een geselecteerde hoofdentiteit. Op deze manier wordt een consistente dataset geselecteerd met een grote variatie aan eigenschappen, waarin de strategisch of commercieel gevoelige informatie niet meer terug te vinden is.

Later kun je eventueel nog specifieke gegevens toevoegen of juist verwijderen als dat voor testdoeleinden nodig is. De selectie wordt dus langzaamaan steeds verbeterd. Je kunt bijvoorbeeld foutieve waarden die in de productiedata aanwezig zijn, bewust in de selectie opnemen om te testen of de software met deze fouten om kan gaan.

Voer de selectie regelmatig opnieuw uit, zodat de testset steeds is gebaseerd op recente productiegegevens. Het is van belang dat de testdata geheel geautomatiseerd gemaakt wordt. Hierdoor kan de testset naar behoeven – handmatig of als onderdeel van een geautomatiseerde test – worden geconstrueerd.

Data eXcellence gebruikt eigen software om de selectie uit te voeren. Deze software selecteert een minimale hoeveelheid data met een maximale variatie voor de geconfigureerde eigenschappen.

Anonimiseren van privacygevoelige data

Gegevenselementen die tot specifieke personen of organisaties te herleiden zijn, mogen niet in handen van onbevoegden komen. Daarom vervang je zulke elementen door andere willekeurige gegevens.

Welke gegevenselementen moeten worden vervangen?

Een gegevenselement moet worden vervangen als dit gegevenselement op zichzelf of in combinatie met andere gegevens onthult welke personen of organisaties in de administratie aanwezig zijn.

Hoe minder elementen worden vervangen, hoe realistischer de dataset zich zal gedragen. Dat verhoogt de bruikbaarheid voor testdoeleinden. Daar staat tegenover dat te weinig substitueren weer leidt tot veiligheidsrisico’s. Deze afweging wordt samen met de gegevenseigenaar gemaakt. De vuistregel is: vervang alle elementen die een risico opleveren, maar ook niet meer dan dat.

Weinig substitueren

+ Verhoogde bruikbaarheid van dataset
- Onveilig

Veel subsititueren

+ Veilig
- Dataset minder bruikbaar of zelfs volledig onbruikbaar

Te veel substitueren kan leiden tot een onbruikbare dataset. Gegevens worden onderling inconsistent of voldoen niet meer aan de eisen van het systeem waarvoor ze bestemd zijn: iemand met een jeugdspaarrekening die volgens zijn geanonimiseerde geboortedatum 60 jaar oud is, of een lening die volgens de geanonimiseerde ingangsdatum 3 jaar loopt, maar wel 20 jaar transactiehistorie heeft. Daarom is het van belang om per gegevenselement zorgvuldig af te wegen of substitutie nodig is of niet.

Data eXcellence gebruikt eigen software die in databases patronen herkent als creditcardnummer, IBAN, BSN of rekeningnummer. Dat helpt bij het bepalen van de lijst met te vervangen gegevenselementen. Op deze lijst komen vrijwel altijd de volgende elementen voor:

  • Achternaam
  • Straatnaam
  • Postcode
  • Woonplaats
  • Opmerkingen (waarin vaak notities staan met privacygevoelige zaken: telefoonnummers, mailadressen, namen van partners, rekeningnummers enz.)
  • Omschrijvingen van een transactie of betaling
  • BSN
  • Bedrijfsnaam
  • KVK-nummer
  • IBAN of rekeningnummer
  • Creditcardnummer

(Kijk ook eens op https://en.wikipedia.org/wiki/Personally_identifiable_information)

Niet nodig om te vervangen zijn de volgende elementen:

  • Geboortedatum (in Nederland worden iedere dag honderden mensen geboren, dus alleen een datum leidt niet tot een specifieke persoon)
  • Overlijdensdatum (idem)
  • Huisnummertoevoeging
  • Tussenvoegsel
  • Aanhef
  • Geslacht
  • Titel (behalve als deze tot een unieke persoon leidt)
  • Financiële en operationele gegevens of transacties die niet tot een natuurlijke persoon of organisatie te herleiden zijn: bedragen, percentages, transactietypen
  • Ondersteunende gegevens die nodig zijn om het systeem te laten functioneren

Bespreekgevallen zijn gegevenselementen die in theorie een privacy-probleem op kunnen leveren:

  • Voornaam: een zeldzame voornaam zou herkenbaar kunnen zijn, maar in de praktijk is een voornaam alleen niet tot een specifieke natuurlijke persoon te herleiden
  • Voorletters: een zeldzame combinatie van voorletters zou herkenbaar kunnen zijn, maar het is dubieus of dat echt voorkomt
  • Huisnummer: er zijn exotische nummers die niet veel voorkomen, maar het is de vraag of zo’n huisnummer zonder overige adresgegevens echt tot een specifiek adres te herleiden is

De betekenis van een element bepaalt of substitutie nodig is of niet. Zo kan een leningnummer in het ene systeem een betekenisloze technische sleutel zijn (geen substitutie) en in het andere systeem een rekeningnummer of IBAN (wel substitutie).

Verder zijn er gegevens die je wel of niet moet vervangen afhankelijk van de rol waarin ze in het systeem voorkomen. Van een notariskantoor dat een zakelijke lening bij een bank heeft, moeten de gegevens worden geanonimiseerd (het notariskantoor is een klant). Maar wanneer een notaris aktes opstelt of hypotheken passeert, is het niet nodig de bijbehorende gegevens te anonimiseren. Het is immers geen geheim dat een notaris dat soort activiteiten uitvoert (het notariskantoor is een derde partij die een dienst uitvoert).

Anonimisatieafspraak

De anonimisatieafspraak legt vast welke gegevenselementen geanonimiseerd worden. Dit is een vastlegging van bovenstaand proces. Mochten de afspraken later wijzingen, dan wordt dit ook vastgelegd. Zo is steeds duidelijk wat de actuele afspraken zijn.

De anonimisatie-software produceert een rapport dat de geanonimiseerde elementen bevat. Dit rapport dient als bewijs dat de anonimisatie is uitgevoerd zoals afgesproken.

Op welke manier worden gegevens vervangen?

Hoe “netter” de gegevens worden vervangen, hoe realistischer het resultaat. In principe kun je ieder alfanumeriek gegeven door een willekeurige letterreeks vervangen, maar dat kan de bruikbaarheid van de testset verminderen: als alle namen, adressen etc. eruit zien als “Test” of “xxxx” zijn individuele gegevens nauwelijks te herkennen, wat het testen bemoeilijkt. Van de andere kant: als gegevens heel realistisch worden vervangen, is het moeilijk te zien of de gegevens wel of niet geanonimiseerd zijn. Misschien werken de testers dan per ongeluk toch met productiedata.

Een goede oplossing hiervoor is om gegevens te vervangen door soortgelijke gegevens, die wel meteen herkenbaar zijn als testdata. Bijvoorbeeld: in een dataset van een Nederlandse hypotheekverstrekker kun je alle namen vervangen door Engelstalige namen en alle plaatsnamen door namen van buitenlandse steden.

Een speciale behandeling krijgen sleutelwaarden. Om de referentiële integriteit van de anonieme set te waarborgen, vervang je gelijke waarden in de gehele dataset door dezelfde anonieme waarden. Bijvoorbeeld: als leningnummer 123456 in een bepaalde tabel wordt vervangen door 100001, moet leningnummer 123456 ook in alle andere tabellen waarin de waarde voorkomt, worden vervangen door 100001.

Tot slot moet je rekening houden met eventuele datakwaliteitseisen van het systeem waarvoor de testset bestemd is. Veel systemen voeren controles uit op het formaat van bepaalde velden. Voorbeelden daarvan zijn een Nederlandse postcode, BSN en IBAN. Als dergelijke controles aanwezig zijn, moeten de gesubstitueerde gegevens aan de gestelde regels voldoen.

Welke software is beschikbaar?

Voor het uitvoeren van de substitutie zijn meerdere softwarepakketten beschikbaar.
Data eXcellence gebruikt hiervoor SQL Data Generator van Red Gate (https://www.redgate.com/products/sql-development/sql-data-generator/index) en Privacy van Datprof (https://www.datprof.com). Een andere bekende oplossing is ARX (http://arx.deidentifier.org/). Wie even zoekt, zal ontdekken dat er volop keuze is.

Conclusie

Door middel van anonimisatie verandert een dataset met productiedata in goed bruikbare testdata. Met de voorbeelden en de verwijzingen in dit artikel kan iedereen meteen aan de slag. Het is de moeite waard eenmalig te investeren in een geautomatiseerd proces – en dat proces regelmatig uit te voeren. Hierdoor blijft de testset actueel en vormt deze dus een goede afspiegeling van de werkelijkheid. Leg de afspraken met de eigenaar van de data goed vast.

Wil je meer weten?

Contact DX