Omnichannel MijnZaken Informatiebeveiliging en privacy

Category:Omnichannel
Informatiebeveiliging en privacy zijn binnen de referentiearchitectuur MijnZaken belangrijke aandachtspunten. Daarbinnen worden immers (ook) gevoelige, persoonlijke gegevens verwerkt.
De inhoud van dit hoofdstuk omvat enkele beveiligings- en privacyprincipes, maar is een eerste, theoretische uitwerking. Uiteindelijk moet op basis van pilots een meer gedetailleerde risicoanalyse worden gemaakt. Bij het maken van die nadere risicoanalyse zal gebruikgemaakt worden van de IRPA tool van de IBD zodat de analyses vastgelegd en te hergebruiken zijn door gemeenten die met MijnZaken aan de slag gaan.
== Uitgangspunten ==
De volgende uitgangspunten gelden in generieke zin bij de implementatie van MijnZaken:
* Burgers, bedrijven of instellingen zien alleen ‘eigen’ gegevens of gegevens waarvoor zij gemachtigd zijn;
* De privacy van de medewerkers van organisaties moet gewaarborgd zijn;
* Medewerkers van organisaties verwerken alleen die gegevens waarmee een doelbinding is;
* Alleen de juiste gegevens worden verwerkt en getoond.
== Grootste risico’s van MijnZaken ==
Op basis van hetgeen in deze referentiearchitectuur is beschreven, is een ruwe schatting te maken van dreigingen en risico’s om rekening mee te houden. In willekeurige volgorde zijn dit:
* Er worden onjuiste gegevens verstrekt. Dit kunnen niet-integere gegevens (bronsysteem) zijn of door het gebruik van een verkeerde koppeling;
* Gegevens of informatie wordt aan verkeerde mensen verstrekt (burgers, ambtenaren en ketenpartijen). Bijvoorbeeld door onjuiste authenticatie of autorisatie;
* De informatiesystemen die de gegevens moeten verwerken/verstrekken zijn niet beschikbaar. Mogelijk raken dan andere kanalen overbelast;
* Er wordt te weinig informatie verstrekt waardoor alsnog aanvullende vragen worden gesteld;
* Er wordt teveel informatie verstrekt. Dit kan bijvoorbeeld gebeuren doordat:
** In het kader van doelbinding teveel gegevens aan medewerkers worden getoond;
** Informatie wordt niet goed gefilterd;
* In het geval van eHerkenning het niet kunnen loggen op persoon maar op organisatie, waardoor niet duidelijk is wie wat heeft ingezien;
* MijnZaken is door middel van een API gateway vanaf het internet direct beschikbaar. Er bestaat een risico is dat derden toegang krijgen tot gegevens waar ze niet bij mogen.
== Maatregelen en componenten ==
De volgende maatregelen kunnen of moeten genomen worden om de risico’s weg te nemen of te minimaliseren:
* Autoriseren op zaakniveau / gegevens- en attribuutniveau / afnemer, onafhankelijk van kanaal;
* Zorgdragen dat op basis van autorisatie onderscheid kan worden gemaakt tussen inzage in “dat”- (inhoud) en “wat”- (procesverloop)-informatie;
* Er moeten beschikbaarheidsmaatregelen genomen worden zodat uitval van een informatiesysteem wordt beperkt;
* Er moet vastgelegd worden welke persoon welke gegevens op welk moment heeft ingezien;
* Het moet duidelijk gepubliceerd of gecommuniceerd zijn waar een burger, bedrijf of instelling terecht kan als er verstoringen bij het ophalen van gegevens worden geconstateerd;
* Veilig ontwikkelen/hanteren ontwikkelstandaarden;
* Tijdens en na het implementeren van (aanpassingen aan) de componenten worden testen uitgevoerd om de veiligheid en privacy te waarborgen (dit betreft ook pentesten);
* MijnZaken is internet facing middels een API gateway, dit betekent dat maatregelen goed ingeregeld moet worden om geen afbreuk te doen aan beveiliging;
* Er is gedegen documentatie beschikbaar waarin is beschreven hoe de informatievoorziening is geïmplementeerd en welke beveiligings- en privacymaatregelen getroffen zijn;
* Voor iedere MijnZaken-implementatie wordt een IRPA analyse uitgevoerd.
VNG Realisatie start eind 2021 met het uitwerken van een architectuur die beschrijft hoe IAM-functionaliteit er in een gegevenslandschap uit moet zien. De hieruit voortkomende principes en architectuur gaan in op het veilig ontsluiten van gegevens via API’s. Zodra deze uitwerking beschikbaar is, wordt een verwijzing hiernaar in deze referentiearchitectuur opgenomen.
== Verwerkingsregister en verwerkingenlogging ==
Eén van de genoemde risico’s is het verstrekken van teveel gegevens aan een medewerker. Dit kan gebeuren als niet duidelijk is met welke doelbinding de gegevens opgevraagd mogen worden. Organisaties zijn volgens Artikel 30 lid 1 AVG verplicht om een verwerkingsregister bij te houden. In een verwerkingsregister is o.a. vastgelegd:
* contactgegevens, bestaande uit:
*# uw naam en contactgegevens;
*# de naam en contactgegevens van partijen waarmee u gezamenlijke verwerkingsverantwoordelijke bent;
*# de contactgegevens van de functionaris voor gegevensbescherming (FG);
* de verwerkingsdoeleinden;
* de categorieën van betrokkenen en categorieën van persoonsgegevens;
* de categorieën van ontvangers;
* eventuele doorgiften van persoonsgegevens aan derde land of internationale organisatie;
* indien mogelijk, de bewaartermijnen;
* indien mogelijk, de beveiligingsmaatregelen.
De Informatiebeveiligingsdienst (IBD) heeft een handreiking geschreven hoe om te gaan met deze verplichting. Ook is er een vooringevuld verwerkingsregister beschikbaar gesteld.
Een aanvullende maatregel hierop is het vastleggen van de verwerkingsacties die op persoonsgegevens zijn uitgevoerd. Elke component die persoonsgegevens afneemt of aanbiedt, moet deze verwerkingsactie vastleggen. Het vastleggen gebeurt in een verwerkingenloggingregister. Door VNG Realisatie is de Verwerkingenlogging API-standaard ontwikkeld als onderdeel van de GEMMA referentiearchitectuur. Deze API-standaard biedt leveranciers van informatiesystemen gestandaardiseerde API-specificaties voor het vastleggen en ontsluiten van de logging van verwerkingen.
In deze referentiearchitectuur is daarom de referentiecomponent Verwerkingenloggingregister en bijhorende Verwerkingenlogging API opgenomen.
Onderstaande afbeeldingen zijn afkomstig uit de referentiearchitectuur Verwerkingenloggingregister en illustreren de relatie en afhankelijkheden tussen de relevante referentiecomponenten.