Privacy by design

Hoewel klanten en werknemers zelf op het internet hun hele leven mogen tentoonstellen mogen bedrijven dit niet. De general data protection regulation (GDPR) wordt naar verwachting in 2016 gehandhaafd. Deze verordening eist dat bedrijven controle hebben over dataprocessen en systemen, wanneer deze persoonlijke data bevatten. Persoonlijke data is hierbij elke informatie over een individu. Dit kan betrekking hebben op zijn privé, beroep of publiekelijk bekend leven. Dit kan van alles zijn zoals, een naam, een foto, een email adres, bankgegevens, social network posts, medische informatie of een IP adres.

Dit plaatst de medewerker en klant in de driver seat. Hij heeft wat te vertellen over zijn gegevens, inzage in wat er mee gebeurt en het recht van verwijdering. Er worden eisen gesteld aan de beveiliging van zijn gegevens. Belangrijk in dit verhaal is dat de sancties erg hoog zijn. De Europese discussie loopt nog en hoe het proces van geleidelijk (of abrupt) opvoeren van de handhaving loopt is onduidelijk. Eén prominent gegeven steekt er voor mij boven uit: ‘Privacy by Design’.

Stel nu eens dat dit gemeengoed is en een belangrijke Europese instantie een paar grote jongens publiekelijk heeft gekapitteld. Zelf weten we niets meer van onze IT, want dit is allemaal verCloud met Consumer IT. De data waar bedrijven op worden aangesproken zit verspreid over het internet, in systemen die van nature met elkaar social data uitwisselen. De nu benodigde data hygiëne hadden we toen niet bedacht. De sourcing naar de cloud was primair ingegeven vanuit een verschuiving van Capex naar Opex met als richtlijn zo standaard als mogelijk. Cloudleveranciers op hun beurt willen continuïteit en een belangrijk strijdmiddel daarbij is de beschikking over de data. De data is zeer veilig in de cloud maar verantwoordelijkheid over bedrijfsdata blijft bij u liggen, zoals vermeld in de kleine lettertjes.

Tokens voor de thuiswerkers hebben we vervangen voor sterkere identiteitscontroles: facial recognition, keyboard behaviour en identificatie met je hartslagmeter. De nieuwe eisen zoals de retentietermijn van persoonlijke data en de mogelijkheid om deze op verzoek te verwijderen, leiden dan tot kostbare additionele diensten. Interessant is wellicht de mogelijkheid om dit van tevoren in het ontwerp in te bouwen.

Een centrale bron met persoonsgegeven zal altijd wel noodzakelijk blijven, maar de vanzelfsprekendheid van de medewerking met alle Master Data Management initiatieven is er ineens vanaf. Het privacy filter zit ertussen. Dit zorgt er voor dat persoonsgegevens omgezet worden naar anonieme stuurparameters, een duidelijke grens aan het hergebruik van persoonsgegevens.

Hoe werkt zo’n privacy filter?

Heeft u een kopietje geldig rijbewijs, paspoort, wat is uw huisadres? De vraag wordt honderden keren gesteld. Het geeft wel veel meer informatie dan datgene wat noodzakelijk is. De werking kan ook anders: U wordt gerouteerd naar de RijksDient voor het Wegverkeer (RDW) en de Gemeentelijke Basis Administratie (GBA). Hier logt u in met uw DigiD en geeft toestemming aan die instantie om de vraag naar uw paspoort en rijbewijs eenmalig te beantwoorden. Nadat de instantie is geauthenticeerd beantwoorden deze systemen met een versleuteld bericht. Het enige dat van een persoon wordt opgeslagen is de bevestiging dat de gevraagde documenten bestaan.

Online klanten die bestellen moeten vaak ook betalen. Wanneer de betaling heeft plaatsgevonden geeft de bank tevens een one-time authorisation code aan de opgegeven transporteur om het afleveradres op te vragen. Op het moment dat een applicatie van de transporteur adresgegevens nodig heeft, wordt dit aangevraagd met authenticatie en encryptie van het bericht. Na gebruik direct weer weg te gooien. De transporteur vraagt bij aflevering om een door de leverancier gemaakte code. Als deze correct is dan is het pakketje correct afgeleverd. De transporteur heef alleen het afleveradres opgeslagen.

Ook medewerkergegevens worden veelvuldig hergebruikt over het IT landschap. Maar al te vaak wordt onder de druk van de dagelijkse gang van zaken besloten om dan maar de gegevens van een medewerker over te zetten in een applicatie omdat deze dat nodig heeft (mogen we echt het BSN niet hebben?). Bijvoorbeeld voor autorisatiedoeleinden is het volledige medewerkerbestand wel handig. Dit is voor de hacker ook interessant. Nou ja hacker, een middelbare scholier met een backtrack Linux distro op een oud mobiel. In een need-to-know principe zijn de meeste schatkamers leeg. Hoe moet dat dan anders?

Veelal worden autorisatieregels afgeleid van organisatorische gegevens van een medewerker. I.p.v. deze gegevens te sturen kun je de autorisatie sturen. Je geeft bijvoorbeeld niet de afdeling prijs maar een entitlement: deze gebruiker mag handeling x op data y uitvoeren. De buitenstaander kan deze aanpak niet reverse engineeren naar persoonlijke gegevens en als de gegevens verwijderd worden uit de centrale bron is er ook gelijk voldaan aan het right to be forgotten.

De GDPR voorziet ook in een nieuwe rol: de Data Protection Officer (DPO). Als hoofdverantwoordelijke moet hij toezien op de naleving van het minimalistisch gebruik van persoonsdata. Bij compromittering van service provider is er geen risico van lekken van gegevens waarmee direct of via webmining een persoon is te koppelen.

Als er in de keten iets fout gaat dan is een reconstructie vaak wel nodig. Net als de officier van justitie toestemming moet geven om het persoonszegel op een DNA profiel te koppelen aan een identiteit zal de DPO toestemming moeten geven om een reconstructie van de aflevering op een adres bij een persoon te kunnen maken. In een ideale situatie gebeurt dit sporadisch.

Wilt u hier meer van weten? U kunt mij hier op dit blog vinden en via linkedin. Aangezien dit blog niet selfdestructs verzoek ik U mijn gegevens direct te vergeten op straffe van 2% van uw jaarinkomen. Bij detectie van meer dan 50 lezers van dit blog die dit niet naleven zal de GBA-webservice negatief beantwoorden.

Caveat auctor nomen nescio.