Mag je testen met persoonsgegevens van klanten?

Een lezer vroeg me:

Na Lektober zijn we bij ons op het werk vol op de beveiliging gesprongen. Alle bestanden met persoonsgegevens zijn opgeschoond en alle systemen zijn maximaal beveiligd. Volgens mij net iets té ver: ik mag onze software niet meer testen met ‘echte’ persoonsgegevens, alleen met een bestand met een paar honderd nepadressen. Dit omdat testen met persoonsgegevens verboden zou zijn onder de Wet bescherming persoonsgegevens. Is dat echt zo?

De Wet bescherming persoonsgegevens (Wbp) verbiedt niet letterlijk het testen met productiegegevens. Die zegt alleen dat je de gegevens mag gebruiken voor het doel waarvoor je ze krijgt, en voor doelen die in duidelijk direct verband daarmee staan (art. 8 en 9 Wbp). Het testen van de omgeving waarbinnen je persoonsgegevens wilt gaan gebruiken, lijkt mij zonder meer voldoende verband te hebben met het daadwerkelijk (productie) gebruik van die omgeving.

De norm “Achtergrondstudies en Verkenningen Nr. 23” van het Cbp is streng:

Voor het testen van informatiesystemen met persoonsgegevens mogen uitsluitend gegevens van fictieve personen gebruikt worden.

Deze norm is niet wettelijk bindend. Je moet deze norm zien als “zo doe je het goed” maar daaruit volgt niet “als je wat anders doet, zit je fout”. Als je wat anders doet, begeef je je in onontgonnen terrein. Dat mag, zolang je zelf dan maar uiterst goed oppast wat je doet. Een eigen norm daarvoor maken is geen slecht idee dan. Ik vond de Richtlijn gebruik productiegegevens uit alweer 2005 van het Bureau Keteninformatie Werk en Inkomen waar nuttige tips in staan.

Testen met echte persoonsgegevens moet wel nodig zijn, oftewel het gebruik van die testgegevens zou niet voldoende moeten zijn. Om bijvoorbeeld te kijken of de interface voor het oproepen van klantgegevens of bestellingen prettig werkt (een usabilitytest), kun je prima volstaan met fictieve gegevens. Een stresstest op de performance kan echter niet met honderd nepadressen als je in productie met honderdduizend echte adressen gaat werken.

Natuurlijk moet je altijd adequate beveiliging (art. 13 Wbp) hanteren, dus ook in je testomgeving. De testomgeving moet dus op dezelfde wijze zijn afgeschermd voor ongeautoriseerde toegang en gebruik. De personen die het systeem testen, moeten aan dezelfde geheimhouding en audits onderworpen zijn als de personen die het productiesysteem beheren. Dat wordt nog wel eens vergeten – men huurt een IT-er in om een databasekoppeling te bouwen en denkt dan niet dat daarbij geheimhouding nodig is. Maar als hij dan een test met productiegegevens gaat doen, is dat wel degelijk wettelijk verplicht.

Het is jammer dat sommige bedrijven zo doorslaan meteen: van totale laksheid naar OMGWTFWBP alles-verbieden-volstrekte-geheimhouding-niets-mag-meer. Even rustig ademhalen graag voor je zulke beleidsregels opstelt.

Arnoud

24 reacties

  1. Is dat doorslaan bij het reageren niet een direct gevolg van het feit dat men meestal pas reageert als het net mis gegaan is. Of als men door een nieuwswaardige (dus grote) blunder bij de concurrent met de neus op de feiten gedrukt wordt. Het blijft nu eenmaal zo dat mensen die schrikken heftiger reageren en dus vaak overreageren.

  2. In de financiele wereld wordt contractueel vastgelegd dat er nooit getest mag worden met productie data. Ook bij interene software/applicatie/database ontwikkeling wordt er geen gebruik gemaakt van productie data. Alle test data is geanonimiseerde data, juist om te voorkomen dat productie data in een onbeveiligde omgeving kan komen.

    Ik vind het beleid van het genoemde bedrijf dan ook zo gek nog niet. En een grote lijst of database met geanonimiseerde data maken is echt zo moeilijk niet. Is prima te doen met een klein Unix scriptje.

  3. Het is denk ik met name relevant als je wil testen of je code ook bestand is tegen alle onverwachte, kwaadaardige of stupide inputs die mensen geven. Het nadeel van een gegenereerde lijst met testdata is dat die per definitie voldoet aan alle criteria die je aan je productiedata stelt. De werkelijke productiedata kan daar nog wel eens van afwijken.

  4. @Arnoud: Je maakt een invoerbestand met 150.000 records (300 voornamen * 500 achternamen => 150000 unieke combinaties.)

    @Peter, 5: Je kunt (moet) de onzinnige gegevens testen, maar dat kan ook met speciaal geprepareerde testgegevens. Als je testers creatief genoeg zijn gebeurt dat ook. Wat ik me kan voorstellen is dat je aan het eind van je testfase ruimte inbouwt om een aantal tests te draaien met productiegegevens, waarbij je de nodige voorzorgen neemt om vertrouwelijkheid van de gegevens te bewaren. Let dan ook op dat je met je foutrapporten geen persoonsgegevens lekt.

  5. Arnoud, zou je ook de naam ????????????? ????????????????? in je testgevallen opnemen? Dat hangt helemaal van de specificaties van het systeem af. Bij het opzetten van je tests zul je keuzes moeten maken over hoe je het doet. Voor performance tests wil je hardware en een database die de productiehardware en database zo goed mogelijk benadert. Bij functionele tests wil je vaak een kleinere database met zoveel mogelijk bijzondere gevallen: Kan ik “Valéry Discard d’Estaing” invoeren? Hoe sorteert d’Estaing (tussen de Bruin en de Vries)?

    Ook als je met de productiedatabase test, kan het zijn dat er opeens de Noor ??vik langskomt die voor problemen in de backoffice applicatie zorgt… (?? komt na Z in het Noorse alfabet)

  6. Zoals RML al zegt: ‘een grote lijst of database met geanonimiseerde data maken is echt zo moeilijk niet’.

    Wat ik meestal doe is van de productiedatabase gewoon de gegevens in elke kolom een random aantal posities omlaag verschuiven (en wat er onder uit valt er boven weer in plakken). Alleen even zorgen dat data die bij elkaar hoort bij elkaar blijft (bijvoorbeeld adresgegevens als je ergens een postcode check doet).

  7. @7 Arnoud ongebruikelijke namen: beetje serieuze bouwers en testers hebben inmiddels ervaring en daarop gebaseerde lijstjes met dit soort valkuilen. Als externe bron wordt vaak de lijst eisen/voorschriften van de GBA toegepast.

    Namen (als in voor -en achternamen)zijn trouwens imho niet de ergste horde. Adressen en dan helemaal in combinatie met huisnummers kunnen menig databasemigreerder tot wanhoop drijven (Haarlem anyone?).

  8. @Rob, technisch gesproken werk je nog steeds met de persoonsgegevens van je klanten (Postcode + huisnummer identificeert een gezin). Met een omkeerbare “scrambling” (als je van één record weet hoe je de velden weer aan elkaar moet plakken, kun je de volledige database herstellen) loop je alsnog risico’s op een lektober vermelding.

    Aan de andere kant, als je testdatabase alleen toegankelijk is vanaf de afdeling software-ontwikkeling, dan weet je waar je die gegevens moet beveiligen: Software ontwikkelaars moeten geheimhouding beloven.

  9. MathFox | 16 november 2011 @ 10:18

    Ook als je met de productiedatabase test, kan het zijn dat er opeens de Noor ??vik langskomt die voor problemen in de backoffice applicatie zorgt??? (?? komt na Z in het Noorse alfabet)

    Met Unix locale schijnt dat te kunnen, alleen moet je dan wel voor de hele sortering kiezen voor één taal, vrees ik.

    Ik heb er beperkte ervaring mee opgedaan: http://rudhar.com/index/cron/nl.htm

  10. Een stresstest op de performance kan echter niet met honderd nepadressen als je in productie met honderdduizend echte adressen gaat werken.

    Voor een stresstest kun je altijd meer nepdata genereren. Computers zijn daar goed in.

  11. Ik denk dat het voorbeeld van stresstest met echte gegevens niet heel gelukkig gekozen is. Je kunt, zoals Bastiaan aangeeft, prima heel veel testdata genereren. Het gaat zoals Arnoud aangeeft met name om de variaties die in echte productiedata zitten, en die genereer je niet zo makkelijk. Je zult dus per test moeten kiezen of het met test- of met productiedata moet.

  12. Arnoud@7:

    [..]maar hoe weet je dat ie dan ook ongebruikelijke namen als Valéry Giscard d???Estaing of Georg Müller accepteert?[..]

    Dit is juist een argument om gegenereerde data te gebruiken. Je kunt immers nooit zeker zijn dat je reeds bestaande echte data alle potentiele valkuilen bevat.

  13. Misschien een combinatie van de twee eerst alles testen met een test database als alles goed verlopen is dan de echte database testen die niet op internet staat aangesloten. Als die twee testen doorstaan zijn dan het echte werk op het laatst moet toch de feitelijke database beschermd worden.

  14. Tja… Ik, software-developer, ken het probleem. Tegenwoordig werk ik aan een cloud-oplossing waar gebruikers informatie over hun clienten in bij kunnen houden. Sowieso is dat een lastig onderwerp omdat dan de vraag openstaat of de prive-gegevens wel goed zijn afgeschermd. Maar dat is wel goed geregeld. Alleen, in de productie-omgevingen kan wel eens iets fout gaan en dan komt er een fout-rapport in onze richting. We krijgen dan een indicatie van waar het ongeveer mis ging maar soms is de betreffende situatie niet te herhalen met test-data en moeten we in de data zoeken naar het exacte probleem. Het kan zijn dat de betreffende records van die client corrupt zijn geraakt of dat er ergens bij een upgrade iets mis ging. We hebben dan geen andere mogelijkheid om de client-data te onderzoeken. Maar dat onderzoek wordt gedaan door een apart team dat de geheimhouding waarborgt. Als ze eenmaal weten hoe de situatie nagebootst kan worden, word er een test-klant aangemaakt met test-data die de betreffende fout ook doet ontstaan. En dan kunnen we kijken waar het in de code fout gaat. En als het om een corrupt data-record gaat dan kan dit gerepareerd worden zodat de gebruiker door kan gaan met zijn werk, terwijl wij ook onderzoeken hoe dit heeft kunnen gebeuren. In principe gebruiken we dus geen klant-data.

    Alleen, hoe zit het dan als een tester/programmeur een testcase opzet met zijn eigen gegevens en een groot deel bij elkaat gefantaseerde data? Maar dus wel de eigen naam, geboortedatum, geslacht en zo… Mag je hierbij ook namen van collega’s gebruiken met verder nep-gegevens?

  15. De reaguurders bij o.a. 2 en 6 onderschatten een beetje de moeilijkheidsgraad van aanmaak van nep productiedata, zeker in omstandigheden waarin bv. moet worden geketentest. Hierbij moet dus over meerdere applicaties en ketens van applicaties de data consistent blijven, vaak verspreid over meerdere tabellen en databases, soms (vaak) ook met systemen waar jouw afdeling of bedrijf niet zelf de controle over hebt.

    Dan is het vaak vele malen makkelijker en goedkoper en betrouwbaarder om echte productiedata te gebruiken, ook al is dit niet optimaal ten opzichte van de privacy van de gebruikers/klanten.

  16. @Martin, daar staat dan weer tegenover dat je de productie-data kunt anonimiseren door deze door een speciaal filter te halen. Dat filter dient dan de data te anonimiseren door namen door willekeurige woorden te vervangen. Of beter, door iedere letter te vervangen door een willekeurig andere letter. Idem voor codes zoals een BSN/SOFI nummer en zo. Het is mogelijk om productie-data te gebruiken zonder deze ook inhoudelijk te kunnen bekijken.

  17. @18, ik ben het eens dat een ketentest met een kopie van de gebruikersdata makkelijker en goedkoper is op te zetten. Als je besluit om het te doen dan zeg jij daarmee als ontwikkelaar/tester/manager dat je de privacy van de klanten van je baas of opdrachtgever geen cent waard vindt. (Tot je geld besteed aan een redelijke beveiliging van de ketentestomgeving.) De houding “Het is goedkoper om niet te beveiligen” leidt tot Lektober, Lektember, Lektuari, etc. vermeldingen.

    1. De wet datalekken (art. 34a Wbp) verandert niets aan wat ik in de blog vermeld. Deze wet introduceert boetes op overtreding van de Wbp en eist dat je een inbreuk op de beveiliging meldt. HEt is niet zo dat de lat over legaal gebruik nu hoger ligt of zo. Natuurlijk is en blijft het een aandachtspunt of testen met productiegegevens echt nódig is; hier hebben andere reacties al diverse nuances bij geplaatst.

  18. Gezien de nieuwe wetgeving https://autoriteitpersoonsgegevens.nl/nl/over-privacy/wetten/europese-privacywetgeving is e.e.a. weer wat complexer. Mag ik testen met mijn eigen persoonsggegevens? Mag je nu een eigen ** NIEUWE ** testset opbouwen met 1. Bestaande postcodes + bestaande huisnummers uit nederland of overal een random huisnummer > 25.000 of overal koppelen aan een bedrijfspostcode 2. Bestaande BSN nummers aparte range maar hoe dan B2B te testen 3. Bestaande telefoonnummers (mobiele nummer wel een persoonsgegeven en vast nummer afhankelijk van de context) 4. Bestaande MAC / network adressen 5. Bestaande produktie IP nummers 6. Bestaande bank IBAN/BBAN rekeningnummers 7. ……

    Mag je een bestaande PRODUKTIE database pseudonimiseren en welke regels zijn dan handig 1. Requirements aan pseudonimisering vanuit software test perspectief a. Iedereen in het huishouden moet dezelfde achternaam houden te realiseren door een eenmalige verschuiving middels een achternamen tabel en deze tabel achter slot en grendel b. Iedereen in het huishouden een andere voornaam te geven te realiseren door een eenmalige verschuiving middels een voornamen tabel en deze tabel achter slot en grendel c. Alle geslachten M/V om te wisselen om partnerregistraties correct te houden d. Geboortedatum +/- een random nummer van max 30 dagen e. BSN nummer te verschuiven Van een gemiddelde ZZPér is deze info min of meer publiek uit het BTW nummer te halen (dat lijkt me een tegenstrijdige wetgeving) f. telefoonnummer is gemiddeld gezien te vervangen door een willekeurige random getal als het maar met 06 begint echter risico is dan weer dat het een 06 nummer word dat wel bestaat en in gebruik is bij iemand anders g. Diverse ingescande documenten gekoppeld via uniek nummer als telnr, bsn, klantnummer, userid etc. door 10-tallen bestanden heen h. Diverse transactiegegevens als factuur, telefoonrecords, netwerkverkeer, ….. deze leiden namelijk meestal niet direct naar een natuurlijk persoon maar vanwege imagoschade wil je deze waarschijnlijk ook pseudonimiseren

    Testen met overleden personen lijkt me vanuit ethisch en imagoschade perspectief ook niet echt handig De wetteksten zijn over bovenstaande voor meerder uitleg vatbaar

Geef een reactie

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren, <UL>/<OL> voor lijsten, en <em> en <strong> voor italics en vet.