BLOG

Databeveiliging, Privacy

Privacy by Design

13 december 2019

In mei vorig jaar ging de AVG (ook wel bekend onder de Engelstalige afkorting GDPR) van kracht. Deze wet heeft ervoor gezorgd dat bedrijven veel beter moeten nadenken over welke persoonsgegevens ze gebruiken en opslaan. Dit heeft uiteraard ook gevolgen voor software. Bij het ontwikkelen van nieuwe software is het daarom belangrijk om een ontwerp toe te passen dat rekening houdt met alle eisen die aan de opslag persoonsgegevens tegenwoordig gesteld worden: Privacy by Design.

GDPR

Na de roerige periode die in de maanden rondom de invoering van de AVG/GDRP is ontstaan, is inmiddels het stof neergedaald. De meeste bedrijven hebben een redelijk beeld van wat de wetgeving voor invloed heeft op de persoonsgegevens die binnen het bedrijf gebruikt worden. In het kort komt het er op neer dat je alleen persoonsgegevens mag gebruiken en opslaan die nodig zijn voor de werking van het product en alleen met toestemming van de persoon. Dit is vrij duidelijk. Een bedrijf is echter ook verplicht om gegevens veilig op te slaan; dit is al een stuk onduidelijker, want was is je definitie van ‘veilig’ en hoever moet je daarmee gaan? Als we kijken naar de Europese wetgeving en dan specifiek letten op de eisen die aan software gesteld worden, zijn die volgende regels van groot belang:

Personen hebben het recht om:
• Hun persoonlijke data te bekijken
• Hun persoonlijke data te verbeteren
• Hun persoonlijke data te verwijderen
• Hun persoonlijke date te exporteren

Organisaties moeten:
• Persoonlijke gegevens adequaat beschermen
• Toestemming vragen voor het verwerken van persoonlijke data
• Bijhouden welke bewerkingen er op de persoonsgegevens uitgevoerd zijn
• Duidelijk aangeven welke data verwerkt wordt en waarom
• Regelgeving hebben over na hoeveel tijd gegevens verwijderd worden
• De autoriteiten op de hoogte brengen van datalekken

Verschillende persoonsgegevens

Zoals je ziet zijn er een aantal heel duidelijke regels, maar ook een aantal die vrij zijn voor interpretatie. Dit komt ook omdat er verschillende soorten persoonsgegevens gedefinieerd zijn. Zo zijn er de ‘normale’ persoonsgegevens, zoals naam, adres, geboortedatum, maar ook bijvoorbeeld IP-adres. Daarnaast zijn er ook de gevoelige persoonsgegevens. Dit zijn bijvoorbeeld gegevens over geloof, geaardheid en medische gegevens. Deze gevoelige persoonsgegevens zijn door de wet extra beschermd. Vandaar de regel “Persoonlijke gegevens adequaat beschermen”. Wat adequaat is, heeft dus te maken met welke gegevens betrokken zijn.

Privacy By Design

Er is dus veel regelgeving, maar ook veel interpretatie. Om er zeker van te zijn dat de software aan alle eisen voldoet en de kans op data-lekken tot een minimum beperkt wordt, is het daarom goed om de software te ontwerpen volgens Privacy by Design.
Het onderstaande schema laat overzichtelijk zien hoe Privacy by Design in elkaar zit.

privacy by design
In het schema worden 8 principes benoemd. Deze zal ik hieronder verder uitwerken.

Minimaliseren

Het is belangrijk om niet meer data op te slaan dan nodig is. Dat lijkt een open deur in trappen, maar toch staat er vaak data opgeslagen in databases die niet of niet meer gebruikt wordt. Maar ook is data vaak op meerdere plekken opgeslagen en hoeft de applicatie de gegevens niet zelf bij te houden, maar kan deze ook opgevraagd worden wanneer deze nodig is.

Scheiden

Door gegevens te scheiden verklein je de problemen bij eventuele datalekken en kun je ze tot op zekere hoogte voorkomen. Denk hierbij aan N.A.W. gegevens scheiden van gegevens over het gebruik binnen een applicatie.

Samenvoegen

Volgens de AVG/GDPR mag niet meer data bewaard worden dan nodig is. Stel je wilt graag weten hoe vaak een bepaalde actie uitgevoerd wordt in de applicatie, dan kun je loggen welke gebruiker op welk moment de actie uitvoert, waardoor het mogelijk is om rapportages uit te voeren over deze actie. Echter is het ook mogelijk om in plaats van individueel gebruik te loggen, te loggen hoe vaak de actie aangeroepen is en dus de gebruiksgegevens te aggregeren of te wel samen te voegen.

Verbergen

Onder verbergen vallen het toepassen van encryptie en anonimisatie. Om de organisatie en de personen te beschermen tegen het verliezen van gegevens, moeten persoonsgegevens altijd versleuteld zijn. In de database tijdens de opslag, maar ook tijdens het transport over beveiligde verbindingen (bijvoorbeeld https). Bij anonimisatie worden persoonsgegevens zo aangepast (of verwijderd van andere gegevens) dat niet te achterhalen is op welke persoon de gegevens van toepassing zijn.

Informeren

De applicatie maakt duidelijk aan de gebruiker welke data verwerkt worden en waarom dit nodig is. Daarnaast moet de gebruiker deze gegevens kunnen zien.

Controleren

De gebruiker moet de controle hebben over de gegevens en is in staat om de gegevens te (laten) verwijderen.

Aantonen

Door middel van logging en audittrails is de software instaat om te laten zien wie, wanneer de persoonsgegevens heeft gebruikt. Wanneer gegevens aangepast zijn, moet duidelijk zijn wie dat gedaan heeft.

Afdwingen

Uiteraard is het van uiterst belang dat alleen de juiste personen bij de data kunnen komen, of te wel: toegangsbeheer. Autorisatie en authenticatie moeten op een solide en beproefde manier geïmplementeerd zijn. Daarnaast moet de organisatie beleid hebben dat vastlegt (en afdwingt) welke personen bij (bijvoorbeeld) productie data kunnen.

Door bovenstaande 8 principes na te leven bij het ontwerpen van software, dwingt de architectuur af dat de applicatie veilig is en aan wetgeving voldoet. Dit is natuurlijk in het voordeel van de organisatie én van de personen waarvan de gegevens verwerkt worden.

Neem voor meer informatie over veilige applicaties en de implementatie van GDPR in uw applicaties contact op met Christian. CPeeters@senet.nl

 

Bronnen:
https://gdpr-info.eu/
https://www.cs.ru.nl/~jhh/publications/pdp.pdf