B7259 - Verwerkingen loggen aan beide kanten van een API

Situatie

Bij een API die persoonsgegevens verwerkt moeten zowel de aanroepende als de afhandelende partij loggen. Ofwel:

Als een gemeentelijke applicatie gegevens opvraagt uit het gegevensmagazijn moeten zowel de gemeentelijke applicatie als het magazijn loggen.
Als een derde gegevens (via een applicatie) opvraagt bij een service van de gemeente moeten applicatie en service beiden loggen.
Als de gemeente bij een derde gegevens opvraagt moeten zowel de gemeente als de derde partij loggen.

Besluit

Betrokken partijen (consumer/provider) zijn zelf verantwoordelijk voor het loggen van de verwerking.
Als er sprake is van twee verschillende organisaties dan:
- Loggen deze organisaties in hun eigen verwerkingenlog.
- Baseren deze organisaties zich ieder op een eigen verwerkingsactiviteit afkomstig uit hun eigen verwerkingsactiviteitenregister.
Als er sprake is van logging binnen dezelfde organisatie dan:
- Kunnen de systemen loggen in hetzelfde verwerkingenlog; dit is niet verplicht.
- Baseren de systemen zich nog steeds op hun eigen verwerkingsactiviteit, afkomstig uit het gemeentelijk verwerkingsactiviteitenregister.

Toelichting

Voorbeeld van communicatie tussen de gemeente en een derde.

N.B. Om een begrijpelijk voorbeeld te krijgen is voor rijbewijzen en dus voor het RDW gekozen. Het getoonde proces is echter niet besproken of afgestemd met het RDW.

Toelichting bij de stappen in de afbeelding:

Haal doelbinding op: Concreet betekent dit dat de UUID van de verwerkingsactiviteit wordt opgehaald. Waarschijnlijk is deze in de praktijk al bij het burgerzakensysteem bekend omdat deze onderdeel is van de configuratie van het systeem.
Log verwerking: Het burgerzakensysteem logt de verwerking. Uit verwerkingsactiviteit en handeling samen kan opgemaakt worden dat het bijvoorbeeld om een ‘Spoedprocedure rijbewijs’ gaat.
Opvragen gegevens Het burgerzakensysteem benadert een service van de RDW en vraagt informatie op over het rijbewijs.
Controleer autorisatie Het gaat hier om functionele autorisatie. Aan de ‘poort’ is al vastgesteld of we de partij kennen of het certificaat klopt etc. Diensten die niet openbare/privacygevoelige informatie verstrekken zullen echter ook altijd moeten controleren of de aanroepende partij ook daadwerkelijk geautoriseerd is om de dienst te gebruiken. Daarbij moet de identiteit van de partij vastgesteld worden. Autorisaties zouden alleen verstrekt mogen worden als er sprake is van een geldige doelbinding. Het is dus niet vreemd als er een (logische) koppeling zou bestaan tussen het autorisatieregister en het VAR. Indien een dergelijke koppeling bestaat zou de doelbinding uit het autorisatie register gebruikt kunnen worden om te loggen.
Log verwerking De RDW kan de verwerking nu loggen.
Leveren gegevens

Gevolgen van deze keuze

De partijen zijn zo min mogelijk afhankelijk van elkaar bij het implementeren van de logging. Verwerkingenlog en VAR van het RDW staan immers los van het verwerkingenlog en VAR van de gemeente, zowel tijdens de registratie als bij latere raadpleging.
Verschillende granulariteit in de verwerkingenlogs: De RDW heeft in haar verwerkingsactiviteitenregister geen details over de exacte verwerking die de gemeente uitvoert. Hierdoor zal het log van het RDW minder specifieke informatie bevatten dan het gemeentelijk verwerkingenlog. In het verwerkingenlog van de RDW staat dan bijvoorbeeld Verstrekken van rijbewijsgegevens aan gemeenten terwijl het gemeentelijk verwerkingenlog vermeldt Spoedprocedure rijbewijs.

Voorbeeld van communicatie binnen een gemeente

Het patroon lijkt sterk op dat van de communicatie met een derde partij. Grootste verschil is dat er binnen de gemeente gebruik gemaakt kan worden van hetzelfde VAR en verwerkingenlog. Dit is overigens niet noodzakelijk maar een keuze van de gemeente.

Ook de gevolgen zijn identiek. De systemen zijn zo onafhankelijk mogelijk in hun implementatie van verwerkingenlogging. En ook de granulariteit zal verschillen. Het gegevensmagazijn zal bijvoorbeeld Gegevensverstrekking t.b.v. burgerzaken loggen terwijl het burgerzakensysteem Spoedprocedure rijbewijs logt.

Afgewezen alternatief: consumer en provider loggen beiden op basis van dezelfde verwerkingsactiviteit

Bij dit alternatief geeft de consumer aan de provider door welke verwerkingsactiviteit de verwerking van de consumer rechtvaardigd. De provider zou dan loggen onder verwijzing naar dezelfde verwerkingsactiviteit.

Bij het afwijzen van dit alternatief speelde de volgende overwegingen:

Het verstrekken van gegevens door de RDW kan een andere grondslag hebben dan het gebruik van diezelfde gegevens door de gemeente in het kader van de aanvraag van een rijbewijs. De RDW moet dus zelf, los van de gemeente, de doelbinding kunnen verantwoorden. De RDW baseert zich daarom op een eigen verwerkingsactiviteit uit het eigen verwerkingsregister.
Het kan voor de RDW wel informatief zijn om te weten waarom de gemeente de gegevens gebruikt. Om deze reden is het mogelijk om de verwerkingsactiviteit van de gemeente mee te geven in de http header van de aanroep. De RDW kan die verwerkingsactiviteit opslaan in het veld Verwerkingsactiviteit ID Afnemer en een eventuele link naar een resources in Verwerkingsactiviteit URL Afnemer. Deze informatie kan bijvoorbeeld gebruikt worden bij een audit.

In de situatie dat consumer en provider onderdeel zijn van dezelfde gemeente zou er wel gebruik gemaakt kunnen worden van dezelfde verwerkingsactiviteit. Dit is bijvoorbeeld het geval als een vergunningenapplicatie informatie opvraagt bij een gegevensmagazijn. Het gegevensmagazijn zou zich dan de verwerkingsactiviteit van de vergunningenapplicatie kunnen gebruiken om te loggen. We hebben er echter voor gekozen om de werking binnengemeentelijk gelijk te laten zijn aan de werking binnen een keten. Het gegevensmagazijn moet dus loggen op basis van een eigen verwerkingsactiviteit.