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
“OMGWTFWBP”, die houden we erin.
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.
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.
@RML: maar hoe doe je dan de test om te zien dat het ook werkt met 150.000 records?
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.
@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.
@MathFox: maar hoe weet je dat ie dan ook ongebruikelijke namen als Valéry Giscard d’Estaing of Georg Müller accepteert? Je moet dan alle real-world cases uitwerken op papier. Een stresstest met echte data is veel effectiever.
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)
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 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?).
@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.
MathFox | 16 november 2011 @ 10:18
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
Voor een stresstest kun je altijd meer nepdata genereren. Computers zijn daar goed in.
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.
Arnoud@7:
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.
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.
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?
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.
@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.
@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.