Hmmm, dat zie iki eigenlijk vrijwel overall waar ik werk met grote databases, of die nu persoonsgegevens of andere gegevens bevatten: de testdatabase is een backup van de productiedatabase van een week oud of zo. Is makkelijk en je weet meteen of je programma niet overmatig traag wordt als er met een realistische hoeveelheid data gewerkt wordt (in plaats van te denken "hij kan deze 3 testrecords makkelijk verwerken, dan moet het met 3 miljoen records ook wel rap gaan).

@Arnoud: Ik zie het probleem niet zo. Het gaat om medewerkers binnen een bedrijf, die allen zich te houden hebben aan hun geheimshoudingsplicht. Je mag een training toch ook bijvoorbeeld geven op een productie omgeving ?

hoe zou jij het vinden als EPD software wordt getest met ECHTE gegevens van klanten, waarin je op een moment ontdekt dat er familie gegevens instaan die JIJ niet wist, en dat die gegevens het vertrouwensrecht tussen patiënt en arts geschonden heeft omdat je baas met echte gegevens de software wil test.
ik zou persoonlijk vol over mijn nek gaan.

Sorry, maar dit kan echt niet. Het is ook helemaal niet nodig. Een beetje bedrijf heeft testdata voor dit soort zaken. Kan best zijn dat je die baseert op echte data, maar dan wel zonder gegevens waarmee je bestaande personen kunt identificeren.

Het is relatief eenvoudig om bijvoorbeeld namen, adressen en andere gegevens te randomizen door ze te verwisselen. Zo wordt Henk Jansen, Gladioolweg 14 in Dronten ineens Pietje Puk Gladioolweg 27 in Klazinaveen. Je hebt dan nog steeds "like real" databases, maar de personen, adressen en andere gegevens zijn niet meer de werkelijkheid.

Met zo'n database kan je prima testen en zijn eventuele privacygevoelige gevens niet meer aan een bestaand persoon te koppelen. Dit is een oplossing die helaas nog veel te weinig wordt gebruikt, maar gelukkig op sommige plaatsen (al) wel.

@Spatieman:

En hoe zou je er tegenaan kijken indien medewerkers in een bedrijf die dag in, dag uit toegang hebben tot klantgegevens voor hun werk, zouden training op een omgeving met diezelfde data ? Ga je dan over je nek omdat het een training is, ook al zitten ze een uur later weer op hun plek, met toegang tot diezelfde klantgegevens ?

Overigens is het EPD wel een goed voorbeeld van een omgeving waar dit soort zaken terecht erg gevoelig liggen.

Het feit dat iemand bij een orgranisatie werkt waar bepaalde gegevens verwerkt worden, betekent niet meteen dat iedereen in die organisatie het recht heeft die gegevens te zien/gebruiken. Ook kunnen voor bepaalde gegevens best toereikende eisen gesteld zijn, voldoen de personen in de trainingen daaraan?

In mijn optiek is het beter om de prodcutie db goed te husselen voor je hem voor trainingen gebruikt.

Ja dat deden wij ook toen we nog tijd hadden voor dat soort dingen!
Er was een speciale testdatabasehusselaar die op die manier alle gevoelige gegevens door elkaar husselde.
Zoals al eerder gemeld wil je wel "representatieve" testdata (dus niet 3 records die iemand even heeft ingetypt).

Maar ja op een gegeven moment werkt dat ding dan niet meer of komt er een andere applicatie en is er geen tijd om hem
weer te updaten, of je krijgt te maken met gekoppelde applicaties die het lastiger maken. Dus tegenwoordig doen we
daar niet meer aan. Budgetten en mankracht staan onder druk door bezuinigingen, en dan moet je IETS droppen.
(dat is het idee achter bezuinigen)

En dan kom je er op een dag achter dat hoewel je productiesystemen zo mooi gepatched en beveiligd waren, je test-systemen dat allemaal niet hadden, want "het zijn maar ontwikkel-machines". Hoe vaak ik niet wachtwoorden tegenkom in ontwikkel systemen die ook in de productie omgeving werken, of kwetsbare development machines die toch stiekem toegang hebben tot productie - het is gewoon een slechte keuze die je maakt...

Laten we wat mogelijke voorbeelden nemen:
- je testsysteem voor het gemak aan internet hangen en die wordt gehackt.
- je acceptatie testen staan in verbinding met de buitenwereld met echte koppelingen
Dat kan als lijnverbinding of printwerk.
- je testsysteem wordt beheerd door externen met open toegang tot de data.
De genoemde scenario’s zijn niet ondenkbaar, er zijn praktijkvoorbeelden van te vinden.
Die hebben plaatsgevonden met de beste bedoelingen waarbij men het nooit heeft zien aankomen.

Je kan het beste de boel maar geanonimiseerd hebben.
Voor zover ik weet is zoiets sterk aanbevolen om te doen via al die lastige gevonden “guidelines” als ISo27k Nen7510

Ik snap het niet helemaal,maar mij lijkt mij gewoon wel duidelijk dat je geen prive gegevens van eventueel klanten mag gebruiken voor trainingsdoeleinden.
Ik ga er van uit dat dat dan nep klanten moeten zijn,op en eigen interne server,die dan net doet alsof het een echte communicatie met klanten betreft.
Zo kan je ook trainingen geven toch?.

Ik ben een Belg en ik dacht dat in Nederland een postcode uniek was per adres. Als je dan random adresgegevens gaat maken en je applicatie gaat ergens de postcode matchen met het adres dat in de database staat dan loopt het daar al fout.

Het is heel makkelijk om te roepen anonimiseer de boel, maar denk dan dat je vaak vele dingen niet meer zal kunnen testen.

Het maken van random data is veel werk, vooral als het realistisch moet zijn. Ook kan een database groeien, door je echte data te gebruiken neem je die groei ook mee in je test applicatie. Tot zo ver kan ik het mij nog wel voorstellen.

Dat neemt niet weg dat toegang tot privé gegevens gewoon beperkt moet blijven. Ik zou daarbij wel onderscheid maken tussen wat voor data het is. Als medewerkers toch al toegang hebben tot alle data, bijvoorbeeld omdat ze in een call center klanten moeten bellen, heeft het weinig waarde om telefoonnummers te verbergen tijdens de training, aangezien ze daarna daar toch toegang tot hebben. Dingen als naam, adres en telefoonnummer vind je ook in de telefoongids (.nl) terug, dus als je al iets wilt doen zou je hooguit mensen met geheime nummers kunnen verbergen. Random gegevens van verschillende mensen verwisselen is ook een simpele en goedkope oplossing, natuurlijk is het niet nodig om postcode en straat te randomize, die twee kun je gekoppeld houden, maar ondertussen wel de ziektegeschiedenis van mensen randomizen (stel dat je aan het EPD werkt). Eenmaal geanonimiseerd maakt het immers niet meer uit of medewerkers er in rondneuzen.

Het gebruik van produktie gegevens in een test of cursus omgeving kan leiden tot de volgende problemen:

De test data gaat via een "vergeten" koppeling door naar een (andere) produktie omgeving.

Een gebruiker denkt ingelogd te zijn op de test omgeving, maar zit in werkelijkheid in de produktie omgeving. Hierdoor wordt je produktie omgeving voorzien van ongewenste gegevens.

En zoals eerder genoemd:

Ongewenste inzage in vertrouwelijke gegevens (persoonsgegevens, wachtwoorden van systemen etc.).

Indien produktie data gebruikt dient te worden, dan dient deze altijd geanonimiseerd te worden. Indien je dit niet kunt, dan dien je zelf je eigen test set op te bouwen.

Test data is goed, omdat je dan vrij bent in alle handelingen. Het probleem van productiedata is dat je dan ook alle toegangsmaatregelen moet afdwingen op een testsysteem, en je dus beperkingen invoert. Dus een tester mag dan alleen die handelingen doen die hij vanuit zijn functie (bv. baliemedewerker bij filiaal X) zou mogen doen. Voor een ontwikkelaar/tester is dat niet werkbaar, waardoor je gefingeerde data nodig hebt. Voor een acceptatie omgeving kan dat wel, maar je hebt dat echte gebruikers nodig in hun eigen functie (dus echt baliemedewerker bij filiaal X). In zo'n geval is het niet belangrijk dat er productiedata in staat omdat deze medewerker vanuit zijn/haar functie ook toegang heeft tot de echte data. Voor trainingen kan het dan ook, maar de mensen die de training doorlopen mogen dan alleen toegang krijgen tot de data die ze straks in praktijk toch kunnen benaderen.
De meeste bedrijven zien echte data als mooie en goedkope testdata, maar vergeten dat je bij productiedata in een acceptatie systeem (of testsysteem of trainingssysteem) ook alle beveiliginsmaatregelen moet toepassen, dus audit logs, reviews, etc., en dat daarmee het ineens goedkoper kan zijn om toch maar met gefingeerde data te werken...

"De eis is dat je de gegevens mag gebruiken voor het doel waarvoor je ze krijgt, en voor doelen die in duidelijk direct verband daarmee staan"


Euh, serieus ? Ik ben benieuwd hoe de definitie testen wordt omgeschreven ? Testen heeft als doel de werking van de software/informatiesysteem te beoordelen (tenzij hier een andere omschrijving van de geven is), dit lijkt me niet verenigbaar met het doel waarvoor in deze de gegevens zijn verkregen en een verband tussen tussen het testen van software en bijvoorbeeld het ontvangen van een nieuwsbrief zie ik al helemaal niet (dit toch het doel waarvoor je bijv. in het database komt te staan)

Als je de productieomgeving wilt gaan testen met echte persoonsgegevens, dien je hiervoor toestemming te hebben van de betrokkenen. Gewoon even die persoon/personen aanschrijven en vragen of je zijn of haar persoonsgegeven mag gebruiken voor een test van het systeem (die hoeft je namelijk niet te doen met 100 000 records).

Volgens verschillende richtlijnen (denk bijv. aan ISO27001) dien je echter niet te testen in een productieomgeving maar een hier en aparte omgeving voor op te zetten die los staan van de productieomgeving. Dit heeft meerdere redenen; je wilt neit dat testen je productieomgeving raken, je wilt dat medewerkers zich niet kunnen verwarren tussen test en productieomgeving en daarnaast is WBP van toepassing op persoonsgegevens, als je deze persoonsgegevens gaat verwerken in een testomgeving moet je zorgen dat deze testomgeving voldoet aan de WBP en daarmee ook aan alle beveiligingsmaatregelen naar stand van de techniek. Der halve kan men de noodzaak ook niet aantonen voor het gebruik van persoonsgegeven in testen, er is nog nooit iemand geweest die de noodzaak daarvan heeft kunnen onderbouwen. In alle gevallen kunnen dezelfde doelen worden bereikt met dummie data en vervalt de noodzaak voor het gebruik van persoonsgegevens in testsituaties.

Ik wil Arnoud hartelijk danken voor zijn antwoord, maar ben het dit keer niet helemaal met hem eens dat er voldoende verband bestaat tussen het doel waarvoor de gegevens in de productieomgeving worden verzamelen (bijv. het ontvangen van een nieuwsbrief) en test van de technische werking van een informatiesysteem

Waarom is het maken random data veel werk ? leg eens uit?

Als het goed is heb je in je applicatie input, verwerking en output validatie gedaan. Hierin staan eigen waar bijv. de data aan moet voldoen, aan de hand van die regels code genereer je in een hand omdraait test data. Daarnaast zijn er veel voorbeeld bestanden / dummie bestanden met bijv. namen, adressen ect. etc. de dummie data is dus gewoon te downloaden ? Waar zit nu precies dat vele werk dan?

We hebben allemaal de bril op die enkel maar de techniek ziet.

In het informatie process gaat het om de gegevens zelf. Die kun je verwerken met machines maar de mens is daar ook een gewoon "resource" onderdeel. HRM Human Resource Management soms HCM Human Capital management in het nederlands personeelszaken. Niet te verwarren met het gebruik van dat woord bij defensie waar bij de aanduiding personeel het anti voorvoegsel voor het gemak is weggelaten.

Als je een nieuw resource item in de categorie human hebt zal je voordat je naar productie gaat daar een acceptatietest op willen loslaten. Het gaat hierbij niet om een resource van het type CPU IO of code. Het volstaat om daarvoor een beperkte logische gegevensset the hebben (testset) die de werkelijkheid voldoende benaderd.
Met die beperkte gegevensset en code die productiestatus heeft moet je de opleiding van mensen kunnen doen. Het hoeft geen fysiek zware omgeving te zijn. Regeressietesten wilde je al kunnen met je technische testen. Je kan daarvan een kopie gebruiken.

Een andere voor zoiets: "opleidingsomgeving".
Hebben we soms last van tunnelvisie dat alles (behalve code ook data) conform productie moet zijn?

Nou ja, in het genereren van die dummy data dus, je zult per tabel in je database moeten nadenken wat voor data er in moet, per kolom moet je iets kiezen, en je kunt niet zomaar random strings nemen 90% van de tijd. Oke, een boolean veld is nog makkelijk, maar nummertjes... moeten die tussen de 0-10 liggen of 10000-2000000? Een op veel relaties zorgen ervoor dat 3 regels in tabel 1 al snel 6 in tabel 2 zijn en 18 in tabel 3. Daar komen nog een hele rits aan business rules bij waar je rekening mee moet houden, iets wat met random data zeker niet gaat lukken op goed geluk. Dat je die business rules een kant op afdwingt wil niet zeggen dat je ook meteen data kunt genereren die daar wel aan voldoet (iets met NP problemen waar ik maar niet over zal beginnen). Natuurlijk kun je dummy namen importeren, maar dat je meer dan 5 minuten werk. Zal binnen een uurtje wel lukken, maar dat is dus al een uurtje per kolom. Komt bij dat je data dan ook nog eens niet meteen statistisch overeenkomt met de werkelijke data, je verhoudingen verschillen, je aantallen verschillen, en zelfs al is het vandaag goed, de productie database groeit en kan over een maand helemaal anders zijn.

Natuurlijk zijn er tools om dergelijke operaties makkelijker te maken, zweren dat je echt niet onverstandig om zult gaan met de echte data, en die erin knallen blijft gewoon zo veel simpeler.

De weg naar de hel is geplaveid met goede voornemens

Die NP problemen vallen hier best mee anders had je het niet kunnen beschreven wat je wil en het niet kunnen testen.
Gaat om de white-box aanpak in een beperkte setting en niet om de balck-box dan wel een onbperkte combinatie setting.

Een aparte opleidingsomgeving zoals beschreven is goed te doen.
Waar heb je dan de problemen?

De oorspronkelijke vraag is een typisch voorbeeld dat men er niet over nagedacht heeft. En maar voor de makkelijkste weg uit al technische beschibkare opties kiest. Bijvoorbeeld de POC met productie-data (en mogelijk productie externe koppelingen). Het argument die hebben we toch al en gebruiken we niet meer.

Er wordt hier inderdaad praktisch alleen naar de techniek gekeken.
Het door elkaar husselen van data kan ook grote gevolgen hebben voor het proces dat je wilt testen.
Bij financiële processen hangt het een en ander samen bij het herkennen/koppelen van adresgegevens en bankrekeningen.
Je hebt niets aan allerlei foutmeldingen die je straks in productie niet hoeft te verwachten omdat daar de data wel gewoon klopt.

Als je trainingen geeft, moet je er gewoon voor zorgen dat de cursisten in de testomgeving niet meer rechten hebben dan in de productieomgeving.

Wat is nu het probleem om te testen met echte data als je daar in je werk ook gewoon dagelijks mee te maken krijgt?

Ik snap de hele discussie daarom niet.

Het gebruik van (bestaande) testdata in een interne training voor medewerkers is niet zo'n groot probleem (zolang het een backup is en geen directe invloed heeft op de hoofddatabase). Het gebruik van bestaande klantgegevens voor het testen van een nieuwe applicatie (iets wat ik herhaaldelijk gelezen heb hierboven) wordt ten strengste afgeraden in de Security branche.

Het gebruik van bestaande klantgegevens in een testomgeving verhoogt het risico van het uitlekken van deze gegevens, want het is en blijft nog maar een test. Alle bugs/foutjes zullen nog niet zijn opgelost of zelfs geïdentificeerd en deze kunnen ervoor zorgen dat je klantgegevens op straat komen te liggen. Iets wat jij als programmeur/netwerkbeheerder/klant/manager absoluut niet wilt. Het is niet goed voor jouw indivuduele carriere alswel als het bedrijf. Denk hier altijd extra goed over na de volgende keer je bestaande klantgegevens gebruikt voor een testomgeving (vrijwillig of als opdracht).

Dan ben ik met je eens, er is hier nog niemand geweest die daadwerkelijk de noodzaak kan aantonen.


Wat is daar moeilijk aan, je valideert toch de data input, de data verwerking en de data output. Je weet dus waar de data aan moet voldoen en wat hier de patronen in zijn, simpel gezegd kun je op basis van validatie al gemakkelijk dummy data creëren. Input, verwerking en output validatie is een must, die code moet je toch schrijven en kun je dus net zo goed ook gebruiken dummy data mee te maken. Heb je die code niet, dan heb je waarschijnlijk een aantal basale beveiligingsmaatregelen vergeten tijdens de ontwikkeling......

De relatie tussen data zit in je database en niet in de data zelf. Wanneer kolom A een karateristiek bevat met Kolom B waardoor er een relatie te herkennen is in de data, deze herkenning vindt plaats in de code, deze code gebruik je om basis van die karakteristiek om je dummy data te creeeren.

Voorbeeld:

-een rekeningnummer (KOLOM A)bestaat uit 10 karakters de alleen uit cijfers mogen bestaan en moet voldoen aan de elfproef
-KOLOM B (wat dit ook moge zijn) bestaat uit de laatste 5 cijfers van rekeningnummer plus een toevoeging van 5 cijfers.

Op basis van deze voorwaarde creeer je voor record 1 een string van 10 karakters die voldoet aan de elfproef. Voor kolom B lezen we kolom A uit knippen dat 5 karakters(cijfers) en plakken daar 5 karakters(hoofdletters) aan vast. Ik zie geen problemen ....

Wat ik dan ook een interessante vraag vind, is of het is toegestaan dat een klant de privégegevens van een medewerker vordert, wanneer hij opbelt naar een klantenservice en vindt dat zijn probleem niet afdoende afgehandeld is. Daarnaast vraag ik me ook af of een klant het gesprek mag opnemen en openbaar maken zonder mijn toestemming en zonder dat mijn naam is weggehaald (is me een keer overkomen).