Privacy by Design: ontwerpprincipes voor veilige software

Bij web en app ontwikkeling is het van belang om tijdig na te denken over hoe er zorgvuldig met persoonsgegevens kan worden omgegaan, zowel vanuit een organisatorisch als een technisch oogpunt. De nieuwe privacywetgeving is een goede aanleiding om met Privacy by Design aan de slag te gaan. Vanaf 25 mei 2018 zijn bedrijven verplicht in het technisch ontwerp al te hebben nagedacht over hoe Privacy by Design geïmplementeerd gaat worden en er dus zorgvuldig met gegevens van de eindgebruikers kan worden omgegaan.

We bespreken zeven technische maatregelen, privacy by default en de rechten van betrokken om je een idee te geven van waar je nu en straks tijdens het (laten) ontwikkelen van je webapplicatie of app rekening mee dient te houden.

Als organisatie dien je goed na te denken over welke data je verwerkt en opslaat. Vanaf 25 mei 2018 mag alleen de data opgeslagen worden die voor het doel noodzakelijk is. Als je bijvoorbeeld spullen verstuurt naar een klant, is een adres noodzakelijk en nodig om het doel te bereiken. Maar in dit geval is een geboortedatum, of het opleidingsniveau van een klant niet van belang en mag dus ook niet opgeslagen worden. Als organisatie dien je dan ook eerst intern te bepalen welke data er écht nodig is, zodat daar bij de ontwikkeling rekening mee gehouden kan worden.

Daarnaast mag de data die wordt opgeslagen niet langer dan nodig bewaard worden. De bewaartermijn is afhankelijk van het doel waarvoor je de data opslaat. Je kunt vervolgens functionaliteit aan je software (laten) toevoegen waarmee de data van gebruikers na bijvoorbeeld zes maanden van inactiviteit automatisch verwijderd wordt.

Om te zorgen dat alleen de eindgebruiker bij zijn eigen data kan is het belangrijk om de juiste oplossingen voor authenticatie en autorisatie te kiezen. Bij Inspire kiezen we altijd voor bewezen oplossingen, omdat ze al duizenden malen in de praktijk gebruikt en daarmee getest zijn.

Bij webapplicaties en mobiele apps waarbij met gevoelige data wordt gewerkt raden we two-factor authenticationaan. De naam zegt het eigenlijk al: om in te loggen zijn twee ‘factoren’ nodig. Dit gaat in de meeste gevallen om iets wat de eindgebruiker weet en iets wat zij heeft. Denk bijvoorbeeld aan een wachtwoord en een vingerafdruk.

Een valkuil bij het kiezen van passende oplossingen voor authenticatie en autorisatie is dat je het de eindgebruiker ook té lastig kan maken om in te loggen. Bijvoorbeeld: hoe meer ingewikkelde eisen je aan een wachtwoord stelt, des te groter de kans dat de gebruiker zijn wachtwoord op een post-it opschrijft en op haar computermonitor plakt. Er moet dus altijd een zorgvuldige balans tussen veiligheid en gebruiksvriendelijkheid zijn.

Je wilt vanaf het eerste contactmoment met je webapplicatie of app een veilige verbinding tussen de gebruiker en de server kunnen garanderen. De communicatie dient daarom versleuteld te worden, zodat ongewenste derde partijen niet kunnen meekijken. Door gebruik te maken van het HTTPS protocol zorg je voor een versleutelde verbinding. Het is steeds gebruikelijker dat beveiligde verbindingen verplicht worden gesteld. Zo kunnen apps op Apple’s mobiele besturingssysteem iOS niet met servers communiceren die nog van het onbeveiligde HTTP protocol gebruikmaken.

Hashing is een handige hulpmiddel bij het pseudonimiseren van gegevens. Als een gebruiker zijn wachtwoord opslaat, zou het niet alleen onveilig zijn om deze in leesbare tekst op te slaan, het zou de gebruiker in theorie ook kunnen identificeren. Bij hashing wordt een tekst, zoals het wachtwoord, door een ‘hash functie’ gehaald. Hash functies hebben bij dezelfde invoer altijd dezelfde uitkomst, maar kunnen niet zomaar teruggerekend worden. De uitkomst wordt opgeslagen, dus niet het wachtwoord zelf. Het is daardoor niet te achterhalen wat het oorspronkelijke wachtwoord is, maar bij inloggen kan de hash functie wel gebruikt worden om te controleren of het ingegeven wachtwoord klopt.

Wordt data van gebruikers gedeeld met derde partijen? Dan is het van belang dat je daar transparant over bent. Het moet voor gebruikers duidelijk zijn welke data met wie gedeeld wordt. Ook moet het voor gebruikers mogelijk zijn om het delen van de data uit te schakelen en het aanpassen van deze instellingen moet eenvoudig toegankelijk zijn. Daarnaast is het van belang dat de instellingen standaard zo privacy-vriendelijk mogelijk voor gebruikers staan ingesteld. Onze developers hebben voor de eindgebruikers van diabetestype1.nl bijvoorbeeld alle profiel-instellingen standaard op ‘delen met niemand’ gezet. Een gebruiker mag zelf aangeven welke onderdelen van zijn profiel voor de buitenwereld zichtbaar zijn.

Als opdrachtgever dien je de “rechten van de betrokkenen” te faciliteren. Dit kun je op verschillende manieren vormgeven. Een gebruiker heeft bijvoorbeeld het recht op vergetelheid, wat in de praktijk betekent dat zij het recht heeft om aan te geven dat ze uit het systeem verwijderd wenst te worden. Dit kun je handmatig doen, maar je bent ook verplicht om gebruikers na een periode van inactiviteit automatisch te verwijderen. Samen met je digitale bureau kun je bepalen welke technische oplossing het beste op je bedrijfsvoering aansluit.

Kortom, denk al tijdens het ontwikkelproces na over hoe je veilig met de persoonsgegevens van je eindgebruikers kunt omgaan. Er zijn verschillende technische oplossingen die je kunt (laten) implementeren om de persoonsgegevens die je opslaat te beschermen én de veiligheid van je webapplicatie of mobiele app te vergroten.

Bron: https://www.inspire.nl/blog/privacy-by-design-ontwerpprincipes-voor-veilige-software/