Blogs

Blog #1: Pragmatische privacy voor programmeurs

Als softwareontwikkelaars moeten we niet alleen zorgen dat de applicaties die we bouwen de juiste functionaliteiten hebben, we moeten ook zorgen dat ze aan diverse niet-functionele eisen voldoen. Apps moeten beveiligd zijn tegen hackers, snel genoeg zijn om de gebruikers tevreden te houden, snel schalen en niet crashen bij piekbelasting. Anno 2018 is het onvermijdelijk dat ook privacy op de lijst van eisen staat. Dankzij de invoering van de Algemene Verordening Gegevensbescherming (AVG) in mei 2018 staat privacy bij bijna alle programmeurs op de agenda.

Buiten de EU gaan sommige partijen heel simpel met deze wetgeving om. Zij blokkeren namelijk alle gebruikers uit de EU. Hier in Nederland hebben we die optie niet en moeten we wel de AVG-wetgeving (ook bekend onder de Engelstalige afkorting GDPR) opvolgen en hiermee werken.

Als je geluk hebt, werk je bij een grote organisatie die privacy experts in dienst heeft, die ons als developers kunnen instrueren. Als je erg veel geluk hebt, heb je misschien zelfs een privacy engineer als collega, die genoeg van software engineering af weet om het werk van je over te nemen. Maar vaak lopen zulke experts niet rond of zijn ze niet beschikbaar. Dat betekent dat we als programmeurs zelf aan de bak moeten. Maar hoe dan? We hebben geen tijd om allemaal privacy expert te worden!

In dit artikel (en de volgende delen) beschrijf ik een pragmatische aanpak om als programmeur met privacy om te gaan, specifiek met de AVG. Maar voordat we met praktische zaken aan de slag kunnen, moeten we een basisidee hebben van wat privacy eigenlijk inhoudt.

Vrijwaring: privacy is een juridisch onderwerp. Onderstaande is een generieke aanpak, maar geen maatwerk voor jouw applicaties. De aanpak bevat mogelijk onjuiste aannames, neemt jouw specifieke situatie niet in ogenschouw en is bedoeld ter illustratie.

Een beetje theorie

In het geval van software gaat privacy over bescherming van persoonsgegevens. Dat lijkt misschien helder genoeg, maar nadere beschouwing kan geen kwaad:

Allereerst: wat zijn persoonsgegevens? Volgens de AVG zijn persoonsgegevens informatie over identificeerbare personen. Dat is een vrij brede en vage definitie. Er bestaat geen opsomming van alle mogelijke persoonsgegevens en het is ook niet mogelijk die op te stellen, omdat het context-afhankelijk is. Laten we haarkleur als voorbeeld nemen. Dat is informatie die overduidelijk betrekking heeft op een persoon. Maar maakt haarkleur een persoon identificeerbaar? Op mondiaal niveau niet. Met aanvullende gegevens kunnen we wellicht iemand indirect identificeren. Als je bijvoorbeeld weet dat de persoon bij hetzelfde bedrijf als jou werkt of in jouw straat woont, dan zou de haarkleur voldoende kunnen zijn om de persoon te identificeren. In zulke gevallen is haarkleur een persoonsgegeven onder de AVG.

Het tweede element is bescherming. De apps die we bouwen moeten bescherming bieden tegen iedereen: mensen met technische toegang tot de app (wijzelf), collega’s, partners en buitenstaanders. Om persoonsgegevens voldoende te beschermen hebben we een aantal plichten. Om te beginnen moeten we een geldige reden (grondslag) hebben voor het verwerken van persoonsgegevens. Vervolgens mogen we die gegevens alleen voor die reden verwerken (doelbinding), gebruiken, etc. De personen waarop de gegevens betrekking hebben, hebben ook diverse rechten die we moeten garanderen. Zo heeft die persoon het recht te weten dat er persoonsgegevens verwerkt worden (recht op informatie) en om te zien welke gegevens verwerkt zijn (recht van inzage).

Samengevat gaat privacy over:

  1. Persoonsgegevens:
    • Informatie over een persoon
    • Een persoon die identificeerbaar is
  2. Bescherming
    • Plichten
    • Rechten eigenaar

Pragmatisch naleven

De AVG maakt de verwerker van persoonsgegevens – wij dus – verantwoordelijk voor het aantonen dat de regels worden nageleefd. Dat lijkt ver van ons bed, maar lijkt veel op wat wij als developers doen. Zo gebruiken we geautomatiseerde tests om aan te tonen dat onze codes  de functionele eisen “naleven”, en gebruiken we monitoring om aan te tonen dat onze apps de performance-eisen “naleven”. We gaan proberen iets dergelijks te doen voor onze privacy-eisen.

Met behulp van de theorie uit de vorige paragraaf zouden we hiermee kunnen beginnen:

Informatie over een persoon Persoon identificeerbaar? Plichten vervuld? Rechten eigenaar voldaan?
Tabel 1
Aap Nee N.v.t. N.v.t.
Noot Ja

Dit is een lijst met kandidaat-persoonsgegevens. Als het inderdaad persoonsgegevens zijn (d.w.z. de persoon is identificeerbaar), dan moeten we ook aangegeven dat we aan onze plichten hebben voldaan en de rechten van de gebruikers voldoende hebben gewaarborgd. Als het geen persoonsgegevens zijn, laten we het op de lijst staan, zodat ook dit feit gedocumenteerd is.

Dit document zouden we overal kunnen bewaren, maar een centrale, toegankelijke plek is handig. Als je iets als GitHub gebruikt, is de README.md of de wiki een logische plek. Bijkomende voordeel hiervan is dat je links/plaatjes naar automatische tests zou kunnen toevoegen als we erin slagen die toe te voegen.

Laten we deze aanpak eens uitproberen door een eenvoudige applicatie te bouwen. Om aan te tonen dat dit prima past in een agile werkwijze, gaan we de app in een aantal increments bouwen. Omdat het een demonstratie-app is, gooien we er van alles en nog wat in: Kitchen Sink.

Increment 1: persoonsgegevens vermijden

In de eerste increment gaan we een eenvoudige statische site bouwen met een plaatje van een afvoerputje. Die site plaatsen we op een server die we toevallig nog hebben draaien. Daar staat al Apache (of NGINX) op, dus we hoeven alleen nog wat HTML neer te zetten.

We zijn snel klaar met privacy voor een statische website, toch? Nou, zelfs met deze opzet verwerken we al persoonsgegevens. Mensen zullen je site gaan bezoeken en Apache registreert elk van die bezoeken in z’n logfiles. Zijn websitebezoeken persoonsgegevens? Ze hebben absoluut betrekking op een persoon (veel bedrijven hebben er geld voor over om te weten welke sites je bezoekt). Is die persoon ook identificeerbaar? De logfile bevat normaliter het IP-adres van de bezoeker. Hoewel je daarmee niet de naam van een persoon kunt achterhalen, kun je met een IP-adres wel een persoon identificeren tussen verschillende websites en daarmee is het een persoonsgegeven. En als je IP-adressen combineert met andere voorhanden zijnde gegevens (zie browser fingerprinting) dan is het overduidelijk dat het om persoonsgegevens gaat.

Nu we deze statische pagina hebben toegevoegd, kunnen we onze checklist invullen:

Informatie over een persoon Persoon identificeerbaar? Plichten vervuld? Rechten eigenaar voldaan?
Tabel 2
Website-bezoek Ja N.t.b. N.t.b.

Maar hebben we deze persoonsgegevens nodig? We willen graag statistieken kunnen analyseren, zoals aantallen en herkomst van bezoekers, maar daarvoor hoeven we niet de persoon te kunnen identificeren. Als we de persoon niet langer identificeerbaar maken, gaat het niet meer over persoonsgegevens en valt het niet langer onder AVG.

Er zijn diverse manieren om gegevens te “de-personaliseren”:

  1. Sla de gegevens niet op of verwijder de identificator (hier het IP-adres). Dit is veruit de simpelste manier, maar het nadeel is natuurlijk dat de gegevens dan ook niet gebruikt kunnen worden.
  2. Aggregatie van gegevens en/of identificatoren. Hierbij worden gegevens samengevat en individuele registraties verwijderd. In ons geval zou dat bijvoorbeeld kunnen door de gegevens rechtstreeks in onze analyse-software in te voeren.
  3. Anonimiseren van identificatoren. Hierbij zijn de identificatoren niet meer identificerend.

Laten we anonimiseren proberen, of beter, een zwakke vorm daarvan: maskeren van gegevens. In plaats van het volledig anonimiseren van het IP-adres, maskeren we het laatste octet van het IP(v4)-adres. Dus 192.168.11.12 wordt dan 192.168.11.x of – als we een geldig adres willen hebben – 192.168.11.0. Het is te beargumenteren dat dit onvoldoende anoniem is, maar Google Analytics volgt deze aanpak ook en wij nemen die hier over. Je kunt dit in Apache doen met een paar configuratieregels, of door  een module te installeren. Voor NGINX (en andere webservers) geldt hetzelfde.

Het is nuttig om deze keuze voor de-personaliseren in onze tabel op te nemen, zodat we ook kunnen zien waarom we website-bezoeken niet als persoonsgegevens beschouwen. We voegen een kolom toe:

Informatie over een persoon Persoon identificeerbaar? Gedepersonaliseerd? Plichten vervuld? Rechten eigenaar voldaan?
Tabel 3
Website-bezoek Ja Ja (Maskeren) N.t.b. N.t.b.

Hiermee zijn we nog niet klaar. We zeggen wel dat we identificatoren maskeren, maar daarmee is het nog niet waar. Als we bijvoorbeeld de instellingen per abuis wijzigen komen we daar nooit achter. Eigenlijk zouden we een test moeten maken om te zien of onze opzet nog altijd correct is.

Hoe je dit kunt doen hangt van de opzet af. Een elegante aanpak is om een log-analysetool te gebruiken zoals bijvoorbeeld SplunkElastic stack of Papertrail. In deze tools kun je een zoekopdracht maken die kijkt of er niet-gemaskeerde IP-adressen voorkomen in je logfiles. Mocht dat onverhoopt gebeuren, dan kun je een notificatie ontvangen of middels een webhook een andere applicatie inschakelen. Daarmee kunnen we een vinkje toevoegen aan onze tabel, de definitieve versie voor deze increment:

Informatie over een persoon Persoon identificeerbaar? Gedepersonaliseerd? Plichten vervuld? Rechten eigenaar voldaan?
Tabel 4
Website-bezoek Ja Ja (Maskeren) N.t.b. N.t.b.

In het volgende deel van Pragmatische Privacy voor Programmeurs ga ik de Kitchen Sink app uitbreiden en kijken of we ook onze plichten als gegevensverwerker kunnen vervullen.

Ondertussen kun je hier meer lezen over verwante onderwerpen:

Photo door Dayne Topkin op Unsplash.

Jeroen Heijmans is Java-developer bij het Rijks ICT Gilde (RIG). Bij het RIG krijgen onze collega's de tijd om hun vakkennis te delen binnen en buiten de Rijksoverheid. Jeroen deelt zijn kennis met andere Java-developers, engineers en programmeurs middels deze blog.

Reactie toevoegen

U kunt hier een reactie plaatsen. Ongepaste reacties worden niet geplaatst. Uw reactie mag maximaal 2000 karakters tellen.

Uw reactie mag maximaal 2000 karakters lang zijn.

Reacties

Er zijn nu geen reacties gepubliceerd.