Wat moet ik doen als mijn klant me productiedata geeft om te testen?

| AE 10350 | Beveiliging, Privacy, Software | 19 reacties

Een lezer vroeg me:

Wij ontwikkelen enterprisesoftware voor klanten, en testen deze uiteraard ook. Meestal ontvangen we daarvoor de testdata van de klant en soms zit daar ineens productiedata tussen inclusief persoonsgegevens. Zijn wij daarvoor aansprakelijk onder de GDPR?

Het is uiteraard een goed idee om software te testen alvorens je deze gebruikt, zeker wanneer die software persoonsgegevens gaat verwerken. Dergelijke software moet immers veilig zijn en voldoen aan de beginselen van privacy by design en privacy by default.

Goede testdata is daarbij van belang, maar is vaak moeilijk te krijgen. Daarom zie je regelmatig dat er toch met productiedata wordt getest, dat is dan de enige bron van een grote hoeveelheid uiteenlopende data waarmee genoeg aspecten getest kunnen worden.

Handig, maar erg problematisch: je weet immers per definitie nog niet of de software veilig is en wel privacytechnisch dichtgetimmerd is. Daarmee neem je als bedrijf (de klant dus van de vraagsteller) een serieus risico op datalekken. Bovendien moet je met je wederpartij (zoals de vraagsteller dus) een verwerkersovereenkomst sluiten waarin je de omgang met deze data expliciet reguleert, en dat wordt vaak vergeten want “het is maar om te testen”.

Het ontwikkelbedrijf zou ik adviseren om expliciet in de overeenkomsten op te nemen dat er géén productiedata wordt geleverd en al helemaal niets waar persoonsgegevens in zit. Een anti-verwerkersovereenkomst, zeg maar. Stuurt de klant die dan toch, dan heb je in ieder geval een sterk argument dat dit niet de bedoeling was. Uiteraard moet je dat bij ontdekking wel melden en die data vervolgens meteen wissen.

Arnoud

Deel dit artikel

  1. Wat moet ik doen als mijn klant me productiedata geeft om te testen?

    BURN IT! En je klant een standje geven. Foei.

    Behalve dat is het natuurlijk een goed idee als je productiedata wel gebruikt om te testen, maar met de privacy-gevoelige gegevens afdoende gescrambled. Potentieel een dienst die je de klant los nog kan aanbieden (uitgevoerd door een andere ontwikkelaar of een derde partij).

  2. Ik ben momenteel bezig met een migratie van een archiefsysteem en daarbij is de enige manier om goed te testen met productiegegevens. De reden hiervoor is simpel. De software is gemaakt zonder productiegegevens, en het blijkt dat deze niet robuust genoeg is om productiegegevens te hanteren. Ineens blijkt hij zich te verslikken op te lange titels, op punten in mapnamen, op het adres waar naartoe geïmporteerd moet worden. Ik ga zelf niet over contracten, dus ik ga er maar even van uit dat er een verwerkersovereenkomst is, en de enige toegang die het ontwikkelbedrijf heeft tot de gegevens is via teamviewer, maar het kan best zijn dat test-gegevens niet afdoende de problemen hebben die in de echte wereld wel spelen. En gezien archief vaak een ondergeschoven kindje is waar niet te veel budget voor beschikbaar is, moeten testsets vaak on-the-fly verzonnen worden en samengesteld uit productiegegevens. Het staat namelijk niet gauw in een verkiezingsprogramma…

    • Dat is inderdaad wel een probleem. De software moet namelijk robuust genoeg zijn. Dus ook niet té robuust. Je kan wel veel moeite doen om ook Chinese karakters in de mapnamen aan te kunnen, maar als die op productie niet voorkomen, is dat weggegooide tijd en weggegooid geld. Om er achter te komen wat er nodig is, zal een programmeur toch op enig moment toegang moeten hebben tot de productiedata.

      • In mijn ervaring is dat onderscheid vaak verwaarloosbaar. Als je een beetje competent aan je software werkt, gebruik je doorgaans libraries die door derden zijn ontwikkeld om correct met je data om te gaan, en die hebben doorgaans sowieso gewoon al ondersteuning voor alle vreemde edge cases die voor jou niet belangrijk zijn. Maar voor jou maakt dat niet uit, het gebruiken van die library kost net zoveel werk, of hij nu wel of niet Chinese karakters ondersteunt.

        Dat is natuurlijk een ander verhaal als er geen robuuste libraries verkrijgbaar zijn die aan je eisen voldoen; dan zul je wel een overweging moeten maken in wat je ondersteunt, en wat niet. Maar:

        1. Het uitgangspunt moet nog altijd zijn dat je alles ondersteunt, en dat iedere individuele niet-ondersteunde usecase beargumenteerd moet worden.

        2. Standaard is het sowieso wenselijk om generieke implementaties te gebruiken waar het niet zo boeiend is met wat voor data je werkt; al is het maar om te voorkomen dat je de business requirements verkeerd ingeschat hebt, en toch een belangrijke usecase niet ondersteunt omdat je dacht dat het niet nodig zou zijn.

        3. Ook als je iets niet ondersteunt, moet je software gewoon robuust zijn; zij het dan door “nee, deze data accepteer ik niet” te zeggen i.p.v. de data proberen te verwerken. Het wordt pas niet-robuust als je software bijvoorbeeld crasht op bepaalde data die je niet ondersteunt, en dat is gewoon nooit acceptabel, ongeacht je usecases of aannames.

        Ik vind het persoonlijk erg gevaarlijk om “de software moet niet te robuust zijn” als uitgangspunt te nemen. Dit drijft mensen om niet na te denken over wat een correct implementatie zou zijn, maar om in plaats daarvan letterlijk en zonder nadenken de business requirements te implementeren, en zo de kantjes ervan af te lopen. En laat die houding nu net zijn waar de meeste bugs vandaan komen.

        (Overigens hoor ik vaak de rechtvaardiging dat “het teveel tijd kost om het correct te implementeren”, maar dit is kant-en-klare onzin. Als je ‘correct implementeren’ als gewoonte hebt, dan kost het niet meer tijd dan wanner je de kantjes ervan afloopt; sterker nog, het kost je minder tijd, omdat je niet naderhand allerlei over-het-hoofd-geziene dingen hoeft te fixen.)

        EDIT: De blog heeft m’n nummering opgegeten, maar die puntjes hierboven horen dus genummerd te zijn.

    • Als je alleen hoeft te weten hoe je system presteert als er miljoenen rows in staan, of alle velden tot de nok toe gevuld zijn, heeft niet direct productie data nodig. Op mijn werk gebruik ik een tooltje waar je (MS SQL) databases kunt vullen met test-data die gebaseerd is op bepaalde kenmerken (google bijvoorbeeld eens op red gate sql data generator).

      • Vaak kom je er pas achter wat lastig aan jouw data is, als het programma zich ergens in verslikt. Zo hadden wij niet bedacht dat een straatnaam een probleem kon zijn, totdat het bleek dat sommige straatnamen een afkorting bevatten (meestal een initiaal van een straat genoemd naar een persoon), waardoor er een punt kwam te staan in een mapnaam, waardoor het programma de rest van de mapnaam als bestandsextensie zag. Tegelijkertijd wil je ook niet, zoals SQB al aangaf, dat je programma tegen complexe dingen kan die in de werkelijkheid niet voorkomen, zoals Chinese tekens. Bovendien kun je de data niet scramblen of anonimiseren, zoals elders geopperd, omdat het om archiefmappen gaat en er dus scans in de vorm van pdf’s en tifs in zitten. Anonimiseren kost dan teveel geld voor een testset terwijl scramblen haast onmogelijk is. De conclusie is dan dat de ontwikkelaar een verwerkersovereenkomst moet ondertekenen, omdat hij data gaat zien die niet naar buiten mogen.

        • totdat het bleek dat sommige straatnamen een afkorting bevatten (meestal een initiaal van een straat genoemd naar een persoon), waardoor er een punt kwam te staan in een mapnaam, waardoor het programma de rest van de mapnaam als bestandsextensie zag.

          Wat mij betreft is het gebruik van datavelden als mapnaam/filenaam in elk geval een absolute no-go, tenzij je een converter schrijft om ongewenste characters te vertalen naar numerieke sequences die wel zijn toegelaten (a la html-encoding, maar dan customized). Dit is nauwelijks een kwestie van wel-of-niet robuust zijn, maar een regelrechte ontwerpblunder die iedereen met programmeerervaring al van mijlenver ruikt.

          Vaak kom je er pas achter wat lastig aan jouw data is, als het programma zich ergens in verslikt.

          Dat kan je in de meeste gevallen voorkomen door je ontwerpproces two-way te maken: in de eerste stap ga je voorwaarts, op basis van je criteria en data verzin je een ontwerp en een ruwe implementatie aanpak. In de tweede stap ga je de andere kant op en vraag je je af als ik voor deze implementatie kies, in welke gevallen/data crasht de boel dan? en stel je je ontwerp bij. Uitgangspunt is dus niet sec ‘beter maken’ maar ‘het ontwerp klopt waarschijnlijk niet’. Als je dat een paar keer itereert heb je 99% van de mogelijke problemen al getackeld voordat je ook maar 1 regel code hebt geschreven. Agressief schieten op je eigen ontwerp helpt echt…

  3. Een goede manier om productiedata veilig te gebruiken is delen van de personalia onderling te verwisselen. Je krijgt dan voornaam a, met achternaam f, en geslacht b, etc. De data is dan compleet random maar is nog steeds representatief voor real world data. Als je klant je echte data geeft, bel je ze op, zeg je “nooit meer doen” en bied je ze aan een tool te maken die dit randomizen voor ze doet 🙂

Laat een reactie achter

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

Volg de reacties per RSS