Informatiebeveiliging

Gegevensbescherming

De Vorderingenoverzicht Rijk applicatie is een hulpmiddel dat door de burger zelf gebruikt kan worden. Vanuit het oogpunt van informatiebeveiliging is het hoofddoel om te voorkomen dat een ander dan de betreffende burger zelf op enige wijze toegang verkrijgt tot de vertrouwelijke informatie over de financiële verplichtingen van de burger.

Het Vorderingenoverzicht Rijk is daarom ontworpen op basis van de principes van security en privacy by design: security en privacy zijn vanaf het begin uitgangspunt bij het ontwerp van de oplossing. Alle communicatie vindt rechtstreeks tussen de burger en de (overheids)organisatie(s) plaats. Gegevens worden dus echt alleen verwerkt door de betreffende bronorganisatie en de burger zelf. Het totaaloverzicht komt alleen binnen het domein van de burger zelf tot stand. Zo worden gegevens op zo min mogelijk plaatsen verwerkt en behoudt de burger maximale regie op gegevens. Niemand anders verwerkt de gegevens.

Uitdagingen

Om de informatiebeveiliging te garanderen en tegelijkertijd de gebruikersvriendelijkheid hoog te houden betekent dit dat er een aantal uitdagingen rondom authenticatie ("bewijzen wie je bent") en autorisatie ("toegangsbeveiliging") dient te worden opgelost:

1. Een burger wil zeker weten dat hij daadwerkelijk met de betreffende bronorganisatie communiceert.
2. Een bronorganisatie wil zeker weten dat hij de betreffende gegevens alleen aan de (juiste) burger verstrekt.
3. Transport van gegevens verloopt via veilige verbindingen.
4. Gegevens zijn binnen het domein van de bronorganisatie goed beschermd.
5. Gegevens zijn binnen het domein van de burger goed beschermd.

Aanvullende uitdagingen daarbij zijn onder meer:

• A. De burger communiceert met een groot aantal overheidsorganisatie(s) tegelijk (dat vereist dus een stuk 'boekhouding' over de veilige kanalen met elke bronorganisatie).

• B. Gebruikersvriendelijkheid is erg belangrijk (de burger vragen om bij elke organisatie afzonderlijk in te loggen is daarom onwenselijk).

Het stelsel

Een belangrijk eerste puzzelstuk voor het oplossen van deze combinatie van uitdagingen is het stelsel. Het stelsel is een manier om op een betrouwbare plek alle informatie over de deelnemers aan het Vorderingenoverzicht Rijk vindbaar te maken. Het stelselschema (de lijst met alle deelnemers in het stelsel) is ondertekend door de stelselbeheerder [Noot: dit is momenteel nog niet geïmplementeerd, TODO]. Omdat de stelselbeheerder alleen geverifieerde organisaties toelaat in het stelsel, weet de burger zeker dat de organisaties in het stelsel echt de betreffende organisaties zijn, en dat hij op de juiste manier met de betreffende organisaties communiceert. Daarmee is uitdaging #1 opgelost: de burger hoeft nu enkel de stelselbeheerder te vertrouwen, en dat verkleint het werk dat hiervoor aan de kant van de burger hoeft te worden uitgevoerd enorm.

Keuze stelselbeheerder Vorderingenoverzicht Rijk

De stelselbeheerder dient daarom een betrouwbare, herkenbare partij te zijn. We zijn nog in gesprek welke partij de meest logische stelselbeheerder zou zijn voor het stelsel van het Vorderingenoverzicht Rijk.

Digitale handtekening

Omdat het onwenselijk is dat de burger bij elke handeling die hij uitvoert opnieuw zijn identiteit moet laten controleren (dit is veel teveel werk), gebruikt het Vorderingenoverzicht Rijk een digitale handtekening om herhaaldelijk een identiteitsbewijs te leveren.

Wanneer de Vorderingenoverzicht Rijk applicatie voor de eerste keer wordt opgestart, maakt deze een keypair aan, bestaande uit een private en public key. De public key wordt gebruikt ter identificatie van de applicatie die namens de burger alle geautomatiseerde handelingen verricht, en de private key wordt gebruikt om op verschillende momenten digitale handtekeningen toe te voegen. Door middel van de handtekening kunnen de wederpartijen (de (overheids)organisaties) herhaaldelijk veilig met dezelfde burgerapplicatie communiceren.

Authenticatie en autorisatie

Zekerheid over de digitale handtekening alleen is echter niet voldoende voor de (overheids)organisaties om er zeker van te zijn dat gegevens alleen aan de juiste burger worden verstrekt. De digitale handtekening is op zichzelf namelijk niet te relateren aan de burger. Daarom dient er in relatie tot de digitale handtekening ook een identiteitscontrole plaats te vinden, en dient de handtekening gekoppeld te worden aan de persoon.

Voor de gebruiker betekent dit dat wanneer de app voor het eerst gestart wordt, de app eerst 'geactiveerd' moet worden. Tijdens het activeren wordt de identiteit van de burger gecontroleerd en wordt de digitale sleutel die gebruikt wordt door de app om digitale handtekeningen te zetten, gekoppeld aan de persoon. Dit is een reeds lang bestaande juridische praktijk genaamd Legaliseren (van handtekeningen), waarvoor men in de papieren wereld onder meer terecht kan bij gemeenten, notarissen en/of (in het buitenland) bij een Nederlandse ambassade.

Er zijn in de digitale wereld verschillende manieren om een soortgelijke procedure te voltrekken, en de wijze waarop dit gebeurt maakt een apart onderdeel uit van de standaarden en afspraken die nodig zijn om het Vorderingenoverzicht Rijk te laten werken. Zie voor meer details de sectie App Activeren verderop op deze pagina.

Gebruik van de digitale handtekening in het Blauwe Knop protocol

De digitale handtekening wordt binnen het Vorderingenoverzicht Rijk niet alleen gebruikt om verzoeken om informatie over financiële verplichtingen te ondertekenen (net zoals men ook een papieren brief zou ondertekenen), maar op het niveau van het Blauwe Knop protocol voor communicatie tussen burgers en (overheids)organisaties ook om:

• Een veilig kanaal op te zetten tussen de burger(app) en de (overheids)organisatie. Voordat een veilig kanaal wordt geopend, bewijst de burger(app) het bezit van de private key.
• Encryptie van gegevens voordat deze aan de burger(app) worden verstrekt met de public key van de burger(app). Op die manier kan de verstrekkende organisatie zeker zijn dat de gegevens alleen kunnen worden ontsleuteld door de burger(app) die in het bezit is van de bijbehorende private key.

Verdere verbetering gebruik digitale handtekening

Op dit moment wordt voor alle bevraagde organisaties dezelfde digitale handtekening gebruikt. Omdat dit leidt tot herkenbaarheid over verschillende organisaties heen, en het onwenselijk is dat deze herkenbaarheid standaard bestaat, is een mogelijke verbeterslag hier om per organisatie andere sleutels of afgeleide sleutels te gaan gebruiken. Dit is op dit moment echter nog niet geïmplementeerd. De impact van dit aspect wordt binnen de context van het Vorderingenoverzicht Rijk flink verkleind omdat burgers sowieso ook toch al geïdentificeerd kunnen worden op basis van hun BSN. In andere use cases is dit belangrijk om op te lossen.

Sessies of Channels

Op dit moment hebben componenten die te maken hebben met het opzetten van veilige verbindingen tussen burgers en (overheids)organisaties namen die de term session bevatten. Mogelijk wordt dit in de uiteindelijke versie van het protocol nog hernoemd naar channel.

Veilige verbindingen (transport)

Op transportniveau past het Vorderingenoverzicht Rijk alle wereldwijd gangbare standaarden toe voor veilig internetverkeer (HTTP/TLS). Voor meer informatie over gebruikte standaarden zie standaarden.

Bescherming van gegevens binnen het domein van de bronorganisatie

Het spreekt voor zich dat gegevens binnen het domein van de bronorganisaties goed beschermd moeten zijn. Het Vorderingenoverzicht Rijk stelt zelf geen specifieke eisen aan deze bescherming, aangezien er grote verschillen zijn in de inrichting van informatievoorziening bij verschillende (overheids)organisaties, deze bescherming op dit moment ook al een eigen verantwoordelijkheid van de betreffende organisaties is, en hiervoor al vele internationale best practices (zoals het zero trust securitymodel) en Nederlandse normen (zoals bijvoorbeeld de Baseline Informatiebeveiliging Overheid) bestaan.

Bescherming van gegevens binnen het domein van de burger

Voor de bescherming van gegevens binnen het domein van de burger stelt het Vorderingenoverzicht Rijk de volgende eisen aan de Vorderingenoverzicht Rijk applicatie:

• Voordat toegang verkregen wordt tot de Vorderingenoverzicht Rijk applicatie dient een extra toegangscode te worden ingevoerd, die (al dan niet indirect) ook gebruikt wordt om gegevens te ontsleutelen. Dit kan in het kader van gebruiksgemak eventueel ook geïmplementeerd worden door middel van biometrische diensten zoals FaceID of fingerprint readers, mits deze veilig zijn.
• Gegevens worden enkel op het apparaat van de burger zelf verwerkt en niet getransporteerd via of naar andere systemen.
• Gegevens worden pas ontsleuteld binnen de Vorderingenoverzicht Rijk applicatie, en de private key waarmee dat gebeurt verlaat deze applicatie niet.
• De aanbieder van de applicatie voor het Vorderingenoverzicht Rijk verkrijgt op geen enkele wijze toegang tot de gegevens die ín de applicatie verwerkt worden.
• Gegevens zijn versleuteld wanneer de applicatie niet draait, zodat bij verlies of diefstal van het apparaat gegevens niet onversleuteld beschikbaar zijn voor aanvallers.
• De Vorderingenoverzicht Rijk applicatie maakt het mogelijk om alle gegevens inclusief metadata te verwijderen uit de applicatie (en het apparaat waar de applicatie op draait).

App Activeren

App Activeren met behulp van een App manager

Tijdens het App Activeren is er (net als in de papieren wereld) een dienstverlener die dit als dienst aanbiedt aan de burger. Deze dienstverlener noemen we 'App manager', omdat de dienst niet alleen het activeren omvat, maar ook het beheer van geactiveerde apps, en het kunnen intrekken van geactiveerde apps (revocation). De App Manager kan bijvoorbeeld een gemeente, ministerie of private partij zijn, en eventueel zou er keuze geboden kunnen worden uit meerdere.

Het App Activeren werkt dan als volgt:

• De burger(app) heeft een keypair gegenereerd.
• De burger(app) dient een verzoek in bij de App manager om (de public key) te legaliseren.
• De burger bewijst zijn identiteit aan de App manager op een door de App manager vereiste wijze (bijvoorbeeld met behulp van DigiD).
• Na vaststelling van de identiteit van de burger, genereert de App manager een certificaat waarin de public key van de burger(app), het tijdstip van de identiteitscontrole en het BSN van de burger worden ondertekend door de App manager.
• De App manager overhandigt het certificaat aan de burger(app)
• De burger(app) kan het bewijs vervolgens gebruiken in communicatie met alle (overheids)organisaties
• De betreffende overheidsorganisatie controleert behalve de digitale handtekening van de burger ook de geldigheid van het certificaat (de handtekening van de app manager).

Belangrijk is dat (net als in de papieren wereld), de App manager verder geen enkele betrokkenheid heeft bij de processen waarin de burger het certificaat vervolgens gebruikt. De App manager levert een op zichzelf staande dienst die enkel en alleen gericht is op het controleren van de identiteit van de burger en het afgeven van het certificaat (legalisatiebewijs).

Het activatieproces behelst in feite het registreren van de app bij de App manager, waarbij een certificaat (gelegaliseerde handtekening) verkregen wordt in de app. Een enigszins vereenvoudigde BPMN-modelering van het Legalisatieproces zoals dat in de referentie-implementatie van het Vorderingenoverzicht Rijk is geïmplementeerd als onderdeel van het gehele proces van het opvragen van informatie over financiële verplichtingen, ziet er als volgt uit:

(Klik hier voor een grotere versie)

App zelfstandig activeren met een Digitale Identiteit

Er zijn ontwikkelingen op het gebied van Digitale Identiteit die het mogelijk zouden kunnen maken dat een burger die op een eerder moment zijn digitale identiteit heeft geladen met diens BSN, die attributen vervolgens kan gebruiken om documenten te ondertekenen. In dat geval is geen externe partij als App manager nodig, maar kan de burger met zijn digitale identiteit zelf bewijzen wie hij is. Door middel van attribute based signatures (zie bijvoorbeeld Hampiholi et al.) kan de burger zijn BSN toevoegen aan de digitale handtekening.

Digitale identiteit gebruiken voor digitale handtekeningen

Een nog mooiere oplossing zou mogelijk zijn om een digitaal identiteitsmiddel dat attribute based signatures ondersteunt, direct te gebruiken voor het zetten van digitale handtekeningen op verzoeken om informatie over financiële verplichtingen. Dit is echter complexer omdat de Digitale Identiteit dan enige automatisering van het zetten van digitale handtekening moet ondersteunen, wat ook weer de nodige veiligheidsrisico's met zich mee brengt. Dit vereist nader onderzoek.

Andere oplossingsrichtingen voor het activeren van de app

Behalve activeren van de app met behulp van een App manager of zelfstandig activeren met behulp van een digitale identiteit, zijn er nog andere oplossingsrichtingen denkbaar die wellicht de gebruikersvriendelijkheid van het Vorderingenoverzicht Rijk verder kunnen verhogen. Aanvullende R&D is nodig om deze oplossingsrichtingen te onderzoeken.