Ketenarchitectuur Werk & Inkomen KARWEI 2.5 Hoofdstuk 7 tm 9

KARWEI beschrijft de uitgangspunten voor samenwerking en informatie-uitwisseling tussen overheidsorganisaties met behulp van ICT (architectuur) en het inzetten van techniek.

Hoofdstuk 7. Koppelvlakken

Hoofdstuk 8. Privacy en informatiebeveiliging

Hoofdstuk 9. Aansluiten nieuwe partijen

H7 Koppelvlakken

De inrichting van de keten werk en inkomen is gebaseerd op een servicegerichte architectuur (service oriented architecture, SOA). In deze architectuur ligt de nadruk op goed gedefinieerde services die zinvol zijn voor de business. Servicegerichte architectuur gaat over dienstverlening van ketenpartijen aan klanten en andere partijen, maar ook over services op functioneel niveau: van het ene systeem aan een ander systeem.

Dit hoofdstuk gaat over die functionele invulling van de servicegerichte architectuur en over de standaardisatie en koppelvlakken die we op dat gebied nastreven.

  • Welke services?

Welke services een ketenpartij aan andere partijen en/of aan klanten biedt, hangt nauw samen met de ketenregistraties waar die partij verantwoordelijk voor is. Zoals beschreven in hoofdstuk 6 heeft een registratiehouder van een ketenregistratie verantwoordelijkheden op het gebied van ontsluiting van de data uit de ketenregistratie, ten behoeve van de afnemers. De ontsluiting moet zo veel mogelijk op een gestandaardiseerde manier gebeuren, met nauwkeurig gespecificeerde koppelvlakken.

We maken onderscheid tussen gegevensdiensten en informatiediensten. Gegevensdiensten leveren ‘kale’ gegevens vanuit de registratie. Informatiediensten implementeren een bewerking op die gegevens.

Die bewerking kan bestaan uit het bij elkaar brengen van gegevens rond eenzelfde zoeksleutel uit verschillende achterliggende bronsystemen (zoals Suwinet-­‐Inkijk dat doet), maar ook uit het daadwerkelijk toepassen van bedrijfsregels om dienstverleningsrelevante informatie te creëren uit de kale gegevens.

De wijze waarop de betrokken gegevensdienst een webservice implementeert, is aan de registratiehouder zelf. Ook de wijze waarop de applicatie die de webservice gaat aanroepen gebouwd wordt, is aan de afnemende partij zelf. De servicegerichte architectuur bemoeit zich hier voornamelijk met de informatie-­‐ uitwisseling en de koppelvlakken, op basis van berichtenverkeer.

  • Wat is een koppelvlak?

Bij geautomatiseerde koppelingen tussen gedistribueerde systemen (machine-­‐machine) is er sprake van een interface waarmee communicatie mogelijk wordt gemaakt. Zo’n interface wordt een koppelvlak genoemd. De beschrijving van een koppelvlak noemen we koppelvlakspecificaties.

Dit is analoog aan niet-­‐ geautomatiseerde interacties tussen een professional en een front end-­‐applicatie (mens-­‐machine), waar de grafische gebruikersinterface communicatie mogelijk maakt. De beschrijving hiervan wordt vastgelegd in een functioneel ontwerp van de schermen.

Afbeelding 12. Beschrijving koppelvlak

Beschrijving koppelvlak

Bij de realisatie van bedrijfsapplicaties zijn beide varianten van belang. Behalve dat het te bouwen systeem aan de gebruikers de juiste functionaliteit moet bieden, moet het systeem aan de achterkant de voorgeschreven koppelvlakken implementeren. Zo moet bijvoorbeeld ieder GSD-­‐systeem onder andere de webservices 'GSDDossierPersoon' en 'AanvraagWWB' implementeren conform de betreffende koppelvlakspecificaties.

  • Standaard voor koppelvlakspecificaties

Voor webservices is de Web Services Description Language (WSDL) een internationaal breed geaccepteerde standaard voor het maken van koppelvlakspecificaties. Deze standaard wordt volop ondersteund in veel software. De beschrijving van de technologie van WSDL en het bijbehorende XML-­‐schema valt buiten de scope van deze ketenarchitectuur. De SuwiML Transactiestandaard geeft hiervan een uitgebreide beschrijving, inclusief de manier waarop we WSDL in de keten werk en inkomen toepassen. 

Afspraak 28       Ketenpartijen gebruiken gestandaardiseerde koppelvlakken; bijvoorbeeld op basis van open standaarden en/of SUWI-­standaarden.

 In de Suwiketen wordt ook gekeken naar andere standaarden waaronder de landelijke e-­‐overheid standaard Digikoppeling. Digikoppeling is een standaard voor logistieke berichtuitwisseling. Digikoppeling regelt een aantal logistieke aspecten van de gegevensuitwisseling zoals beveiliging, vertrouwelijkheid, integriteit, betrouwbaarheid en onweerlegbaarheid. Digikoppeling standaardiseert de logistieke laag (header); de inhoud (body) is domeinspecifiek (bijvoorbeeld SuwiML voor uitwisselingen tussen Suwipartijen). De SuwiML Transactiestandaard wordt op Digikoppeling aangepast.

  • Digikoppeling

De landelijke e-­‐Overheid heeft behoefte aan een goede standaardisatie op het gebied van berichtenverkeer. De standaarden voor Digikoppeling (voorheen Overheidsservicebus) zijn opgesteld op basis van enkele relevante internationale standaarden, zoals de WS-­‐* standaarden en de ebXML-­‐ familie.

Services op basis van Digikoppeling moeten zich houden aan profielen gebaseerd op de Nederlandse keuzen voor de doorvertaling van die internationale standaarden. De services zelf zijn niet door het Digikoppeling-­‐project ontwikkeld maar moeten gespecificeerd, geïmplementeerd en beschikbaar gesteld worden door de landelijke basisregistraties, de grote landelijke uitvoeringsorganisaties en verschillende andere overheden.

Allerlei overheidsinstellingen kunnen die services (mits geautoriseerd) vervolgens aanroepen en gebruiken. Ter ondersteuning heeft het Digikoppeling-­‐project een serviceregister en een compliancevoorziening opgeleverd.

Bij Digikoppeling zijn wat andere keuzes gemaakt dan oorspronkelijk in de keten werk en inkomen. De SuwiML Transactiestandaard licht deze verschillen toe. In de doorontwikkeling van de SuwiML standaard naar versie 4.0 wordt de beweging in de richting van Digikoppeling 3.0 vormgegeven.

Digikoppeling vereist dat gegevenstransport beveiligd moet zijn met TLS. Hiernaast biedt het mogelijkheden om de onweerlegbaarheid en identiteit van de afnemers vast te stellen op basis van het met PKI-­‐certificaten ondertekende berichten. Zeer vertrouwelijke of geheime gegevens kunnen end-­‐to-­‐end ge-­‐encrypt getransporteerd worden. Het autorisatiemodel is gebaseerd op organisatieniveau.

 Afspraak 29       Voor ieder koppelvlak met webservices worden specificaties gemaakt in SuwiML conform de SuwiML Transactiestandaard.

  • Fysieke implementatie

Na vaststelling van de koppelvlakspecificaties voor een service kan men de service fysiek implementeren. De webservice komt dan beschikbaar op een applicatieserver. De webservice houdt zich precies aan de koppelvlakspecificaties: hij ontvangt, herkent en valideert de gespecificeerde requests en hij stuurt responses terug die ook aan de koppelvlakspecificaties voldoen.

  • Soorten services

Er zijn verschillende soorten services, ieder met eigen kenmerken voor de bijbehorende koppelvlakken:

  • Raadplegingen (bevragingen).
  • Meldingen (waaronder: Suwinet Meldingen, Signalen en Abonnementenregistratie).

Deze tweedeling is in lijn met Digikoppeling waarbij het onderscheid tussen profielen gebaseerd is op wie de uitwisseling initieert, de afnemer of de leverancier (pull of push).

  • Randvoorwaarden

Bepaalde randvoorwaarden zijn bij de verschillende soorten services soms wel en soms niet aan de orde. Dat hangt af van het type uitwisseling (Architectuur Digikoppeling). Deze randvoorwaarden zijn met name:

  • Reliable messaging

Bij sommige uitwisselingen van meldingen vereisen het bedrijfsproces en de ondersteunende applicatie absolute zekerheid dat een bericht aankomt. Dit is vooral vereist bij meldingen. Een melding is namelijk vaak een trigger voor het proces bij de andere partij.

  • Tussenstations

Bij sommige uitwisselingen is de toepassing van tussenstations gewenst of zelfs noodzakelijk. Hierbij loopt de communicatie van de bron naar de bestemming via het tussenstation. Een tussenstation is een oplossing als de bestemming via de bestaande netwerken niet rechtstreeks bereikbaar is vanaf de bron.

Er bestaan transparante en niet-­‐transparante tussenstations. Niet-­‐transparante tussenstations hebben vaak ook de functie om te ontkoppelen. Dit kan bijvoorbeeld nodig zijn om downtijden bij de bestemming te ondervangen, het bericht door te kunnen verwijzen of berichten op maat te kunnen afleveren.

Het tussenstation kan dan zorgen voor caching, adressering, gegevenslogistiek, performance management en transformatie. Wanneer tussenstations worden gebruikt, is meer aandacht voor reliable messaging noodzakelijk. Bij tussenstations is het ook wenselijk om berichten te ondertekenen en eventueel te versleutelen.

Bovendien kan de service van het tussenstation (iets) afwijken van de service die de bestemming levert. Dit moet dan ook in de koppelvlakspecificaties tot uiting komen.

Alle bovenstaande varianten worden ondersteund door en besproken in de SuwiML Transactiestandaard.

  • Opname in het serviceregister

In de keten werk en inkomen wordt geen gebruik meer gemaakt van een centraal serviceregister. Wel wordt zo nu en dan het Digikoppeling Serviceregister geraadpleegd.

  • Services voor registraties buiten de keten

Ketenpartijen kunnen gegevens nodig hebben uit een (basis)registratie buiten de keten. Hiervoor kan een vertaling gemaakt worden in SGR / SuwiML. Vervolgens kunnen ook deze gegevens ontsloten worden met SuwiML webservices.

Momenteel zijn er bijvoorbeeld al SuwiML webservices beschikbaar voor het ontsluiten van gegevens uit de Basisregistratie personen (BRP, voorheen GBA), de Rijksdienst voor het Wegverkeer (RDW) en de Kamers van Koophandel. Deze SuwiML-­‐varianten van externe services worden centraal in de keten beschikbaar gesteld aan afnemers, dan wel gebruikt door Suwinet Inkijk.

Dit vraagt om een transformatie van een extern gegevensformaat van en naar SuwiML, en eventueel een transformatie op het gebied van autorisatie. De externe registratie kan verlangen precies te weten wie de afnemer is.

Bij verzoeken die via een SuwiML webservice naar de registratie gaan, kan het BKWI als centrale beheerder voor de SuwiML webservice zich niet voordoen alsof zij de afnemer zelf is. BKWI voert het beheer in opdracht van ketenpartijen of de registratiehouder. De bron is altijd leidend voor de eisen aan authenticatie en autorisatie. Op welke plek dit geïmplementeerd wordt, is ook aan de bron. Afnemers kunnen dit uitbesteden aan BKWI.

  • Verbeteren transparantie

De NORA stelt met betrekking tot transparantie onder andere:

P15. ‘Organisaties in het publieke domein maken zichtbaar wat zij doen, welke besluiten zij nemen, welke gegevens zij hebben en gebruiken en wat hun werkwijze is.’

P12. ‘Overheidsorganisaties betrachten maximale transparantie voor de betrokkenen wat betreft de op hen betrekking hebbende verwerking van persoonsgegevens en verstrekkingen aan derden van die persoonsgegevens. Zij streven daarom naar inzage langs elektronische weg voor die betrokkenen.’

Dit is binnen het SUWI-‐domein grotendeels te realiseren door voor iedere raadpleging en ieder signaal een afslag naar de Berichtenbox op Mijnoverheid.nl te sturen. Dit leidt tot veel extra berichtenverkeer, maar het geeft de geïnteresseerde burger een beter beeld van wat er met zijn gegevens gebeurt.

Wat weer bijdraagt aan de bewustwording bij overheidspartijen over het gebruik van gegevens. De Berichtenbox op MijnOverheid.nl zou de burger de mogelijkheid kunnen bieden om aan te vinken of hij dit soort mededelingen wil ontvangen of niet.

Een minder vergaande mogelijkheid om de burger transparantie te bieden is de website www.burgerservicenummer.nl. Per organisatie zou daar kunnen staan welke soorten gegevens gebruikt worden. Dit is op het moment van schrijven nog niet gerealiseerd. Organisaties met een FG (Functionaris Gegevensbescherming) hebben bovendien geen meldingsplicht naar het College Bescherming Persoonsgegevens (CBP), waardoor hun gebruik ook niet te vinden is op de site van het CBP.

7.1 Raadplegingen (pull­‐berichten)

Raadplegingen zijn de meest gebruikte webservices in de keten. Webservices van het type raadplegingen ontsluiten de informatie uit de verschillende ketenregistraties. Meestal is een burgerservicenummer vereist in de request, de response geeft vervolgens informatie over de persoon met dat burgerservicenummer.

Hieronder gaan we dieper in op de eisen die worden gesteld aan raadplegingen. Het burgerservicenummer is niet altijd de identificerende sleutel. Andere identificerende sleutels of nummers zijn ook mogelijk, bijvoorbeeld de identificatie van een werkgever met het zogenaamde KVK-­‐nummer of (in de toekomst) RSIN (Rechtspersonen Samenwerkingsverbanden Informatie Nummer).

Andere raadplegingen zijn zoekopdrachten en niet-­‐vertrouwelijke raadplegingen; zij krijgen aan het eind van deze paragraaf nog kort de aandacht.

  • Hoge beveiligingseisen

Bij de meeste raadplegingen wordt vertrouwelijke informatie over een klant verstuurd. Daarom worden hoge eisen aan de beveiliging gesteld. De webservice is alleen toegankelijk voor bevragingen door afnemers die geautoriseerd zijn. In de service level agreements staan afspraken over het gecontroleerd beschikbaar stellen van de gegevens aan de gebruikers bij de afnemer, dat wil zeggen: alleen aan geautoriseerde professionals.

  • Doelbinding

Bij het maken van koppelvlakspecificaties moet het principe van doelbinding een van de uitgangspunten zijn. Het principe van doelbinding heeft gevolgen voor de koppelvlakken van het type raadplegingen: de informatieset in de response moet aansluiten bij het werkproces waarvoor de informatie op dat moment van belang is.

Wanneer een ketenregistratie verschillende logische subsets bevat, dan moeten die subsets in de koppelvlakken afzonderlijk opvraagbaar zijn. Zo kan de gevraagde informatie goed afgestemd zijn op de informatiebehoefte van de gebruiker op dat moment (proportioneel), en bij de stap in het werkproces die door de gebruiker uitgevoerd wordt.

Afspraak 30    De partij die een raadpleging-­‐webservice van een ketenregistratie aanroept zal de verkregen informatie niet zelf opslaan, behalve als bewijslast bij de genomen besluiten. 

  • Granulariteit in de koppelvlakken

Doordat de logische subsets afzonderlijk beschikbaar gesteld worden in de koppelvlakken van raadplegingen, ontstaat er een zekere granulariteit in de koppelvlakken. Deze granulariteit moet goed zijn, maar ook werkbaar. Te fijnkorrelig is niet werkbaar, bijvoorbeeld als in de koppelvlakken per gegeven een aparte raadpleging gespecificeerd wordt.

Aan de andere kant doet te grofkorrelig geen recht aan het principe van doelbinding, bijvoorbeeld als er hele dossiers meegestuurd worden in de response op een raadpleging. Er ligt momenteel een voorstel om te gaan werken met ‘logische gegevensclusters’ die aansluiten op de functionele behoeften van de afnemers in de keten, en recht doen aan de samenhang van de gegevens in de registraties.

Afspraak 31      De partij die een raadpleging-­‐webservice aanroept is verantwoordelijk voor zorgvuldig gebruik van de geraadpleegde informatie door zijn medewerkers en ziet toe op autorisaties, doelbinding, beveiliging en de proportionele gegevenslevering binnen zijn organisatie.

  •  SuwiML koppelvlakspecificaties per raadpleging

Voor iedere raadpleging worden SuwiML koppelvlakspecificaties gemaakt. Het heengaande bericht bevat ten minste het burgerservicenummer, het teruggaande bericht bevat de gevraagde informatie over de persoon met dat burgerservicenummer. In het heengaande bericht kunnen daarnaast aanvullende parameters gespecificeerd zijn wanneer die voor de betrokken ketenregistratie nodig zijn om tot een juiste response te komen.

Afspraak 32       De bevraging van ketenregistraties geschiedt op basis van webservices. 

  • Zoekopdrachten

Naast raadplegingen aan de hand van een burgerservicenummer zijn allerlei andere zoekopdrachten mogelijk. Op basis van een zoeksleutel in het request zal de response een aantal treffers bevatten. De kadaster-­‐webservice kent bijvoorbeeld de mogelijkheid om de gerechtigden (eigenaren) van een kadastraal object op te vragen. Belangrijk is dat de koppelvlakspecificaties de oplevering van treffers scheiden van allerlei nadere informatie over die treffers. Dat zijn namelijk verschillende soorten raadplegingen waarvoor verschillende autorisaties kunnen gelden.

  • Niet‐vertrouwelijke raadplegingen

De PostcodeTabelwebservice is een voorbeeld van een raadpleging zonder vertrouwelijke informatie. In het request zit een postcode of een gemeentecode, en in de response de bijbehorende plaatsnaam of gemeentenaam. Dit betreft openbare informatie en daarom gelden hierbij minder strenge eisen aan de beveiliging en aan de mogelijkheden voor tracking en tracing. Daardoor zijn bijvoorbeeld minder veiligheidsmaatregelen vereist in de koppelvlakspecificaties.

7.2 Meldingen (push‐berichten)

Naast webservices voor raadplegingen kennen we webservices voor meldingen. Waar raadplegingen zijn bedoeld om informatie op te halen, gebruiken we meldingen om informatie te sturen. De keten werk en inkomen kent verschillende soorten meldingen. Een belangrijk onderscheid daarbij is of er wel of geen inhoudelijke gegevens meegestuurd worden.

Een Signaal bevat alleen de mededeling DAT er gegevens beschikbaar zijn gekomen, een Melding bevat ook de te leveren gegevens. We noemen dat respectievelijk een dun of een dik bericht.

We bespreken hieronder de voorziening Suwinet Meldingen en de Signalen. Daarnaast bespreken we de Centrale Abonnementenregistratie inclusief het landelijke Digilevering.

7.2.1.        Signalen

Signalen zijn hier elektronische berichten die een gebeurtenis melden, zoals de start of beëindiging van een uitkering, een dienstverband of een opleiding. Het gaat om veranderingen in de ketenregistraties. Omdat die veranderingen invloed kunnen hebben op de dienstverlening van ketenpartijen, worden koppelvlakspecificaties gemaakt van signalen. Een signaal bevat het burgerservicenummer van de betrokkene en de precieze gebeurtenis die heeft plaatsgevonden.

Afhankelijk van de noodzaak om naast het gemelde feit middels een signaal (dun bericht) een eerste beoordeling van het gemelde feit te kunnen doen worden enige inhoudelijke gegevens toegevoegd. Er wordt dan gesproken over een melding (dik bericht).

Echter niet alle daadwerkelijke gegevens die de gebeurtenis beschrijven worden toegevoegd. De afnemer moet de gegevens die nodig zijn voor een verdere beoordeling met een aparte bevraging ophalen. Het signaal wordt direct of via een centrale of decentrale abonnementenregistratie verspreid naar de partijen die de betrokkene als klant hebben of krijgen, en waarbij de gebeurtenis mogelijk van invloed is op de dienstverlening.

Centrale Abonnementenregistratie

De signalen worden bij voorkeur gegenereerd door de eigenaar van de (keten)registratie. Om de verspreiding van signalen naar afnemers te ondersteunen, wordt een Centrale Abonnementenregistratie ingericht in de GeVS. In de Abonnementenregistratie wordt bijgehouden welke signalen (en onder welke condities) op welke manier naar welke partijen of systemen gestuurd moeten worden. De ketenregistratie hoeft alleen zijn signalen naar de Abonnementenregistratie te sturen; de registratie verzorgt de verdere verspreiding.

Registratiehouders kunnen ook een eigen abonnementenregistratie inrichten en zelf signalen naar abonnees versturen. Een mogelijke variant is dat de ketenregistratie wel via de Abonnementenregistratie achterhaalt waar men op een bepaald moment een bepaald signaal heen moet sturen, maar dat de ketenregistratie het daadwerkelijk versturen van het signaal aan abonnees zelf voor zijn rekening neemt.

Voor de landelijke basisregistraties is een dergelijke voorziening in het leven geroepen die op dit moment geleidelijk wordt uitgerold. Deze heet Digilevering. Het is nadrukkelijk de bedoeling dat de Suwiketen op Digilevering gaat aansluiten voor het gebruik van de basisregistraties.

Om de verspreiding van signalen ook voor ketenregistraties mogelijk te maken is het nodig een ketenvoorziening in te richten voor de abonnementenregistratie en de afhandeling ervan. Deze dient dan als tussenliggende voorziening tussen Digilevering en de ketenpartijen, en handelt abonnementen ten aanzien van de ketenregistraties af.

Afspraak 33       De Abonnementenregistratie voorziet in beheerschermen waarin afnemers zelf hun abonnementen kunnen starten, beëindigen en onderhouden.

Afspraak 34       De Centrale Abonnementenregistratie wordt beheerd door BKWI.

Afspraak 35       Voor al het berichtenverkeer met de SUWI-­‐abonnementenservice wordt gebruik gemaakt van Digikoppeling WSRM-­‐profielen en de uitwisselingsstandaarden van Digilevering.

Afspraak 36       Signalen worden gegenereerd door de (keten-­‐ of basis)registraties.

Afspraak 37       Alle gestructureerde informatie die ketenpartijen uitwisselen, is gedefinieerd en vastgelegd in het SUWI Gegevens Register.

Afspraak 38       Voor ieder signaal worden conform SGR de SuwiML koppelvlakspecificaties gemaakt.

Het heengaande bericht bevat de gebeurtenis (zo nodig aangevuld met relevante parameters bij deze gebeurtenis) en het burgerservicenummer; het teruggaande bericht bevat een ontvangstbevestiging.

Afspraak 39       Afnemers richten webservices in (conform de koppelvlakspecificaties) om signalen te ontvangen die voor hen relevant zijn en waarvoor zij geautoriseerd zijn.

Afspraak 40       De Centrale Abonnementenregistratie heeft voor ieder signaal een webservice die voldoet aan de vastgestelde koppelvlakspecificaties en aan de SuwiML Transactiestandaard.

De dienstverlening van de afnemer reageert op de ontvangst van signalen. Daarom is gegarandeerde aflevering noodzakelijk bij signalen. Dit is een belangrijk verschil met raadplegingen, en het stelt extra eisen aan het systeem dat de signalen verstuurt én aan het systeem dat de signalen ontvangt.

De SuwiML Transactiestandaard wordt op dit punt doorontwikkeld om een profiel te realiseren waarin conform Digikoppeling 3.0 een WSRM (WebservicesReliable Messaging) beschikbaar komt. Na ontvangst van een signaal kan de afnemer besluiten om via een raadpleging gedetailleerde informatie (over de gebeurtenis, of over de klant) op te halen.

7.2.2.        Suwinet-Meldingen

Suwinet Meldingen is de voorziening waarmee berichten betrouwbaar op de juiste bestemming kunnen worden afgeleverd. Het gaat op dit moment om het doorsturen van aanvragen voor Bijstand bij gemeenten. Suwinet Meldingen is nog in ontwikkeling. Zo is het nog nodig het berichtenverkeer conform Digikoppeling in te vullen met een vorm van reliable messaging, in plaats van de tijdelijke store-­‐and-­‐forward.

Van belang is dat het in het geval van Suwinet Meldingen gaat om ‘dikke’ berichten. Het zijn berichten die de daadwerkelijk relevante gegevens bevatten. Er is dus geen bevraging nodig na het ontvangen van de melding.

  • Verschil met signalen

Een belangrijk verschil tussen signalen en de Suwinet Meldingen is dat er met de Suwinet Meldingen meer informatie uitgewisseld wordt tussen de ketenpartijen. De signalen beperken zich veel meer tot hun signaalfunctie, namelijk een melding dat een gegeven of een situatie veranderd is. De gegevens zelf blijven opgeslagen in de ketenregistratie waar ze thuis horen, maar kunnen uiteraard wel geraadpleegd worden via Suwinet-­‐Inkijk of via andere bevragende applicaties.

Het versturen van onnodig grote hoeveelheden gegevens en/of informatie door de keten moet worden voorkomen. Een signaal dat de gegevens zijn opgenomen in een ketenregistratie heeft daarom de voorkeur. Op deze manier worden de meest actuele gegevens gebruikt en overal beschikbaar gesteld.

7.2.3.        Correctieverzoeken

Het doorvoeren van mutaties in een ketenregistratie moet gecontroleerd gebeuren en wordt voornamelijk uitgevoerd door bevoegde professionals in een front end-­‐applicatie van de ketenregistratie zelf. Aanlevering van correctieverzoeken kan echter ook vanuit andere applicaties plaatsvinden, door andere professionals of door burgers zelf. De centrale SUWI Correctieservice faciliteert dit.

De correctieverzoeken moeten voldoende informatie bevatten om een onderzoek te starten en om uiteindelijk te beslissen of het correctieverzoek wordt geaccepteerd of verworpen. Daarom zijn er ook koppelvlakspecificaties beschikbaar voor correctieverzoeken. Deze specificaties worden geïmplementeerd in de Correctieservice.

Iedere applicatie die zijn gebruikers correctiemogelijkheden biedt, kan de correctieverzoeken van zijn gebruikers conform deze specificaties aanleveren bij de centrale Correctieservice. De Correctieservice stuurt het correctieverzoek door naar de verantwoordelijke ketenregistratie.

Bezien vanuit het bovenstaande gaat het bij correctieverzoeken over meldingen (Digikoppeling, push). 

Afspraak 41       Ketenregistraties sluiten aan op de Correctieservice. Afspraak 42       Bevragende applicaties sluiten aan op de Correctieservice.


Samenvattend onderkennen we voor het koppelingen domein de volgende componenten: 

 

 

Componentnaam

Doel

1

SuwiML

Gemeenschappelijke taal

2

Suwinet-Inlezen

Leveren van gegevens in de vorm van vraag-­‐ / antwoord-­‐berichten

3

Suwinet-Meldingen

Aanleveren van gegevens in de vorm van push berichten

4

Filtermechanisme

Voorziening t.b.v. implementeren proportionaliteit

5

IB broker

Centraal gemeentelijk verdeelstation

6

SUWI bulk Servcies

Service voor ondersteunen van beperkte bulkverwerking

7

Stekker 4

Ontsluitingsmethodiek van gemeenschappelijke voorzieningen tussen gemeenten en         UW

8

Digilevering

Signalen doorgeven

9

RINIS

Connectiviteit en transformatieberichten

10

Digikoppeling

Informatielogistiek protocol

 

11

Digimelding

Terugmelding op basisregistraties

12

Berichten op Maat (BOM)

Berichten die op maat worden samengesteld uit berichten van de bron

 

Steeds meer persoonsgebonden gegevens worden uitgewisseld tussen burgers en organisaties en tussen organisaties onderling. Ook de toegang tot elkaars voorzieningen neemt toe en daarmee ook de toegang tot nog meer informatie. Deze brede toegankelijkheid heeft echter een keerzijde.

Zonder adequate beveiliging kunnen gegevens op straat belanden, oneigenlijk worden gebruikt of zelfs worden misbruikt. Daarmee neemt het belang van informatieveiligheid alsmaar toe. Incidenten zoals DigiNotar en Lektober doen ons realiseren dat veiligheidsmaatregelen geen luxe meer zijn.

In het kader van de ‘Meldplicht organisaties bij diefstal, verlies of misbruik persoonsgegevens’ zijn partijen verplicht om diefstal, verlies of misbruik van persoonsgegevens te melden aan de betrokken personen en aan het College Bescherming Persoonsgegevens (CBP). Voor deze meldplicht bij datalekken wordt de Wet bescherming persoonsgegevens aangepast.

Partijen moeten de informatiebeveiliging op orde hebben om incidenten in de toekomst te voorkomen, maar ook om schade door onzorgvuldig handelen, onrechtmatig handelen of zelfs misbruik door bijvoorbeeld professionals te beperken én aan te tonen. Uit recente onderzoeken (rapport Inspectie Werk en Inkomen) blijkt dit echter niet altijd het geval. Informatie van onze burgers mag niet in onbevoegde handen komen.

Gebruik van persoonsgegevens betekent dus het hanteren van strikte privacyregels. Via de GeVS worden veel persoonsgegevens uitgewisseld. De SUWI-­‐ketenpartners (UWV, SVB en gemeenten) wisselen onderling informatie uit over inkomen, uitkeringen, maatregelen, arbeidsverleden, kinderbijslag en re-­‐ integratiegegevens.

Daarnaast kunnen de SUWI-­‐ketenpartners ook informatie opvragen bij registraties zoals de basisregistratie personen (BRP), de basisregistratie voertuigen (BRV), opleidings-­‐ en studiefinancieringsgegevens bij de Dienst Uitvoering Onderwijs (DUO), eigendomsgegevens onroerende zaken bij het Kadaster en bedrijfsgegevens bij het Nieuw HandelsRegister (NHR).

De veelheid en gevoeligheid van de gegevens die via de GeVS (kunnen) worden uitgewisseld bepalen dat de bescherming van de privacy en de beveiliging van de GeVS als geheel, maar ook elke component afzonderlijk, moeten voldoen aan de eisen die passend zijn voor het niveau van de risicoklasse van de gegevens. Informatiebeveiliging gaat verder dan alleen het beveiligen van informatiesystemen en de infrastructuur waar die gebruik van maken.

Het gaat bijvoorbeeld ook om de toegang tot gebouwen en de wijze waarop medewerkers met informatie omgaan of het nauwgezet uitvoeren van procedures waarbij informatie een belangrijke rol speelt. Dat vereist constante aandacht voor het verhogen van het beveiligingsbewustzijn van medewerkers.

  • Normenkaders

De wetgever en de ketenorganisaties hebben respectievelijk in de Regeling SUWI en in de Keten Service Level Agreement eisen en afspraken opgenomen voor de organisaties die zijn (of nog worden) aangesloten op de GeVS. Zo moeten de aangesloten organisaties relevante normen uit het normenkader GeVS opnemen in hun beveiligingsplan en hierover jaarlijks verantwoording afleggen. De normen uit het normenkader GeVS zijn ontleend aan:

  • Code voor Informatiebeveiliging ISO
  • Beveiliging van Persoonsgegevens (CBP).
  • Voorschrift informatiebeveiliging

Voor publieke organisaties die zijn (of in de toekomst worden) aangesloten op de GeVS staat het normenkader GeVS niet op zichzelf. Deze organisaties hebben in ieder geval ook te maken met het normenkader dat voor die overheidslaag van toepassing is. We hebben het hier over de Baseline Informatieveiligheid Rijksoverheid (BIR) en de Baseline Informatieveiligheid Gemeenten (BIG).

Mogelijk hebben organisaties ook andere normenkaders in hun beveiligingsplan opgenomen.

  • BIR :     De BIR is geheel gestructureerd volgens NEN/ISO 27001 en NEN/ISO 27002. De overheid is verplicht om hieraan te voldoen. De BIR beschrijft de invulling van NEN/ISO27001 en 27002 voor de rijksoverheid.
  • BIG :     De BIG is gebaseerd op de NEN/ISO 27001, de NEN/ISO 27002 en op de Baseline Informatiebeveiliging Rijksdienst (BIR). Voor gemeenten is een vertaalslag gemaakt naar een baseline voor de gemeentelijke markt.

De organisaties die zijn (of in de toekomst worden) aangesloten op de GeVS hebben te maken met ten minste twee normenkaders: het normenkader GeVS en de BIR, of het normenkader GeVS en de BIG. Deze normenkaders komen voor het overgrote deel overeen. De informatiebeveiligingsdienst voor gemeenten (IBD) heeft een vergelijking uitgevoerd tussen het normenkader GeVS en de BIG en de onderlinge verschillen beschreven. Het resultaat van deze vergelijking is terug te vinden via de website van de Informatie Beveiligingsdienst van KING.

8.1 Uitgangspunten

Informatiebeveiliging is meer dan techniek alleen. Informatiebeveiliging is de verzamelnaam voor de processen die ingericht worden om de betrouwbaarheid van processen, de gebruikte informatiesystemen en de daarin opgeslagen gegevens te beschermen tegen al dan niet opzettelijk onheil. Het begrip ‘informatiebeveiliging’ heeft betrekking op:

  • Beschikbaarheid / continuïteit: ervoor zorgen dat informatie en informatieverwerkende bedrijfsmiddelen op de juiste tijd en plaats voor de gebruikers beschikbaar
  • Exclusiviteit / vertrouwelijkheid: informatie beschermen tegen kennisname en mutatie door Informatie is alleen toegankelijk voor degenen die daarvoor geautoriseerd zijn.
  • Integriteit / betrouwbaarheid: het waarborgen van de correctheid, volledigheid, tijdigheid en controleerbaarheid van informatie en

Informatie is tegenwoordig één van de voornaamste bedrijfsmiddelen voor organisaties. Het verlies van gegevens, uitval van ICT, of het door onbevoegden kennisnemen of manipuleren van bepaalde informatie kan ernstige gevolgen hebben voor de bedrijfsvoering, maar kan ook leiden tot imagoschade. Hierdoor zal de focus vooral liggen op de beveiliging van informatie.

Het zorgdragen dat onbevoegden minder makkelijk toegang kunnen krijgen tot informatiesystemen en de informatie in die systemen is een belangrijk aspect van informatiebeveiliging. Tevens dient deze informatie beschikbaar, juist en volledig te zijn. De kapstok voor beveiliging in een organisatie is het informatiebeveiligingsbeleid.

Het doel van het informatiebeveiligingsbeleid is borging van betrouwbare dienstverlening en een aantoonbaar niveau van informatiebeveiliging dat voldoet aan de relevante wetgeving, algemeen wordt geaccepteerd door haar (keten)partners en er mede voor zorgt dat de kritische bedrijfsprocessen bij een calamiteit en incident voortgezet kunnen worden. In het informatiebeveiligingsbeleid horen ook de organisatorische en informatiebeveiligingsprincipes terug te komen.

De betrouwbaarheidsaspecten met betrekking tot informatiebeveiliging zijn beschikbaarheid, integriteit en vertrouwelijkheid. Deze drie betrouwbaarheidsaspecten kunnen verder worden gedifferentieerd:

  • Beschikbaarheid:
    • Tijdigheid: kan de informatie worden geleverd op het moment dat deze nodig is?
    • Continuïteit: kan de informatie ook in de toekomst worden geleverd?
    • Robuustheid: is de informatie bestand tegen storingen?
  • Integriteit:
    • Juistheid/Correctheid: klopt de informatie, wordt deze correct weergegeven?
    • Volledigheid: is de informatie volledig, ontbreekt er niets aan?
    • Geldigheid: is de informatie geldig, zijn alle procedures in acht genomen?
    • Authenticiteit: is de bron van de ontvangen informatie juist?
    • Onweerlegbaarheid: heeft de verzender de informatie inderdaad verzonden?
    • Nauwkeurigheid: de mate van detail en afronding van de
    • Controleerbaarheid: in hoeverre kan de informatie worden gecontroleerd?
  • Vertrouwelijkheid:
    • Exclusiviteit: kan de informatie kan worden afgeschermd voor onbevoegden?
    • Privacy: wordt er op een correcte manier omgegaan met persoonlijke gegevens?

Van de GeVS mag worden verwacht dat de uitwisseling van gegevens tussen bronhouder en afnemer op een veilige, betrouwbare en transparante wijze plaatsvindt. Om dit mogelijk te maken is voor de uitwisseling van informatie een aantal privacy-­‐ en informatiebeveiligingsaspecten vastgesteld. Deze aspecten bestrijken de niveaus:

  • Kaderstelling
  • Inrichten en verrichten
  • Monitoring en verantwoording Schematisch ziet dit er als volgt uit:

Aspecten m.b.t.

kaderstelling

Korte toelichting

Uitwerking

Het Normenkader
GeVS is
opgenomen in het
beveiligingsplan
Alle aangesloten partijen hebben
het Normenkader GeVS
ondergebracht in hun
beveiligingsplan.

Partijen die gebruik maken van de GeVS hebben (ten
minste) te maken met twee normenkaders: het
Normenkader GeVS en de Basisrichtlijn
Informatiebeveiliging Rijksdienst (BIR) of het Normenkader GeVS en de Baseline Informatiebeveiliging Nederlandse Gemeenten (BIG).


Men moet vaststellen welke informatiebeveiligingsmaatregelen
al zijn geïmplementeerd en wat daarvan nog
up to date is (soort nulmeting). Dit kan worden gedaan met een GAP-analyse: waar staat men ten opzichte van het Normenkader GeVS en de BIR- of BIG-maatregelen. Deze stap geeft ook inzicht hoe het nu geregeld is, wie feitelijk
welke informatiebeveiligingsmaatregelen uitvoert.

De focus moet hierbij vooral liggen op de normen die in het Normenkader GeVS als essentieel zijn gemarkeerd. Met betrekking tot de ontbrekende maatregelen moet men aangeven wanneer deze worden geïmplementeerd en wie hiervoor verantwoordelijk is.

Als door een aangesloten
partij risico’s worden geaccepteerd en als gevolg daarvan informatiebeveiligingsmaatregelen niet worden geïmplementeerd, moet dit worden geadministreerd en geaccordeerd door de verantwoordelijke.


De normen uit het Normenkader GeVS zijn voor een groot Karwei versie 2.5 Pagina | 67
deel ook in de BIR en de BIG opgenomen. Voor de BIG is een mapping opgenomen naar de belangrijkste wetgeving, waaronder SUWI.

 

Aspecten m.b.t. inrichten en verrichten

Korte toelichting

Uitwerking

Gegevens moeten integer en beschikbaar zijn

Een van de criteria voor gegevens is een betrouwbare registratie bij de bron, in dit verband de SUWI-

ketenpartner.

•           De bronhouder moet de processen zo inrichten dat

de integriteit en beschikbaarheid van de gegevens is geborgd.

•           De bronhouder moet de processen zo inrichten dat de beschikbaarheid conform afspraak is geborgd.

•           Wanneer een bron om wat voor reden dan ook geen gegevens kan leveren moet de afnemer (gebruiker)

gedurende deze ‘storing’ op de hoogte gehouden worden.

•           De melding wordt via een SUWI-bericht aan de afnemer (gebruiker) gestuurd en aan de professional, op een voor hem passende wijze.

•           Wanneer de bron om wat voor reden dan ook niet beschikbaar is, moet de beheerder van die bron direct hierover worden geïnformeerd.

Gegevens moeten veilig worden uitgewisseld

De GeVS zorgt voor een veilig berichtenverkeer tussen bronhouder en afnemer, om deze veiligheid te kunnen waarborgen.

•           De authenticiteit van de communicatiepartners moet vaststaan, bijvoorbeeld door het gebruik van certificaten.

•           Per service wordt vastgesteld of de geauthenticeerde afnemer (cliënt, dus een applicatie van een partij) geautoriseerd is om de service (berichttype) te gebruiken. De vertrouwelijkheid van de berichten moet zijn gewaarborgd en het gebruik van de uitgewisselde gegevens is beperkt tot geautoriseerde gebruikers.

•           Alleen de beoogde, dus geautoriseerde ontvanger kan berichten ontvangen en inzien.

•           De integriteit van berichten moet zijn gewaarborgd; ongeautoriseerde wijzigingen, toevoegingen en weglatingen door derden zijn niet mogelijk gedurende het transport.

•           Berichten mogen niet verloren raken zonder notificatie.

•           Ontkenning van verzending en/of ontvangst van meldingen mag niet mogelijk zijn.

•           Elke melding moet herhaalbaar, traceerbaar en opvraagbaar zijn binnen een nader vast te stellen periode. Dit moet uiteindelijk opgenomen worden in de Keten SLA.

•           Beschikbaarheid, integriteit en vertrouwelijkheid (inclusief het voldoen aan wettelijke en contractuele eisen wat betreft privacy en informatiebeveiliging), vereisen dat alle uitwisselingen worden gelogd. Het gaat om redenen als aantoonbaarheid van overdracht, ontvangst, detectie van storingen, diagnose en herstel en eventueel aanspreken op oneigenlijk gebruik of misbruik.

•           Het berichtenverkeer tussen organisaties moet 100% controleerbaar zijn. Door middel van tracking en tracing moeten berichtencycli kunnen worden gevolgd en geanalyseerd.

De toegang tot de gegevens wordt gecontroleerd

Voor toegang tot gegevens die via de GeVS beschikbaar worden gesteld, wordt voor burgers DigID (in de toekomst eID) als authenticatiemiddel vereist en voor professionals een authenticatie- en autorisatiemiddel centraal vereist.

Het betrouwbaarheidsniveau is hierbij afhankelijk van de risicoklasse van de gegevens. Voor de hoogste risicoklasse wordt Multifactor authenticatie (MFA) toegepast.

   

 

Single sign-on wordt ondersteund

Single sign-on stelt gebruikers in staat om eenmalig in te loggen waarna automatisch toegang wordt verschaft tot meerdere informatiesystemen en resources in het netwerk.

•           De gebruiker logt in op zijn werkplek en het resultaat van deze inlogactie is herbruikbaar op andere applicaties/systemen waardoor niet opnieuw ingelogd behoeft te worden.

Proportionaliteit wordt gewaarborgd

Bericht-op-maat en granulariteit zijn toepassingen om de proportionaliteit beter te waarborgen.

•           De bronhouder maakt een ‘bericht-op-maat’ op basis van de autorisatiematrix en stuurt het ‘bericht-op- maat’ rechtstreeks naar de afnemer via de SUWIBroker.

•           De SUWIbroker ontvangt het ‘maximaal’ bericht van de bronhouder en maakt hiervan een ‘bericht-op- maat’ en levert het aan de afnemer.

•           De SUWIbroker ontvangt het ‘maximaal’ bericht en genereert een ‘bericht-op-maat’ aan de hand van de autorisatiematrix.

•           De afnemer stelt de gegevens van de berichten op maat beschikbaar aan haar medewerker met behulp van vastgestelde autorisatieprofielen.

Er is een onderscheid tussen gegevens die in verschillende risicoklassen vallen

Gegevens die tot een hogere risicoklasse behoren worden in de uitwisseling gescheiden van de overige informatie, zodat de afnemer het gebruik van de informatie aan specifieke medewerkers kan toewijzen.

•           Gegevens die behoren tot een hogere risicoklasse worden afgescheiden van gegevens die behoren tot een lagere risicoklasse. Daar waar gegevens van verschillende risicoklassen worden samengevoegd (bv. in een bericht), geldt het regime van de gegevens met de hoogste risicoklasse. Voor het vaststellen van de risiconiveaus wordt gebruik gemaakt van de publicatie van het CBP https://cbpweb.nl/sites/default/files/downloads/av/av2 3.pdf.

•           Het autorisatiemodel maakt het mogelijk om afnemers individueel voor het gebruik te autoriseren en houdt rekening met proportionaliteit.

•           Voor elke GeVS-component geldt dat het beveiligingsmaatregelen implementeert die passen bij de gegevens met het hoogste risiconiveau.

/HR_Betrouwbaarheidsniveaus_WEB.pdf.

•           Voor de gegevensuitwisselingen die vallen in de hoogste risicoklasse worden extra maatregelen toegepast zoals certificaten en encryptie.

De beveiliging van gegevens in cache wordt gewaarborgd

Caching is een opslagplaats waarin opgevraagde gegevens tijdelijk worden opgeslagen om sneller toegang tot deze data mogelijk te maken

•           Caching mag alleen worden toegepast voor dezelfde gebruiker van dezelfde organisatie voor dezelfde taak.

•           Ook voor caching geldt dat het beveiligingsmaatregelen implementeert die passen bij de gegevens met het hoogste risiconiveau.

Filtering wordt toegepast om disproportionele gegevensgebruik te voorkomen

Met whitelisting en blacklisting kan sturing worden gegeven welke gegevens wel of niet mogen worden geraadpleegd.

•           Filters worden toegepast om disproportionele gegevensgebruik te voorkomen en oneigenlijk gebruik te beperken.

•           Een beheervoorziening stelt een afnemer in staat een filter voor de gehele organisatie, voor een rol of voor een medewerker toe te passen. Hiermee wordt disproportionele gegevenslevering op rol- en medewerkersniveau beperkt dan wel voorkomen.

•           Een filter moet in voorkomende situaties door de gebruiker – voor zover hiertoe geautoriseerd – buiten

werking gesteld kunnen worden.

•           Wanneer de gebruiker het filter voor een bepaalde bevraging buiten werking stelt, wordt dit gelogd en in de rapportage zichtbaar gemaakt.

•           Bronhouders kunnen het filter (blacklisting) inzetten om gegevens van bepaalde burgers niet beschikbaar te stellen.

 

Aspecten m.b.t. monitoring en verantwoording Korte toelichting Uitwerking
Het gebruik van gegevens wordt geregistreerd De burger moet de overheid kunnen
vertrouwen en heeft het recht te
weten wie welke gegevens,
wanneer en waarvoor verzamelt.
• Het berichtenverkeer wordt zo ingeregeld dat gelogd
wordt welke medewerker van welke organisatie voor
welke taak op welk moment welke gegevens van
welke burger heeft ingezien.
Gebruikers- rapportage is beschikbaar Voor bronhouders van de GeVS
moet het zichtbaar zijn welke
gegevens uit hun bron door welke
organisatie voor welke taken zijn
opgevraagd. Voor afnemers moet
het zichtbaar zijn welke gegevens
door welke medewerkers voor
welke burgers zijn opgevraagd.
• Een voorziening waarbij aangewezen
verantwoordelijken van een organisatie zelf
rapportages kunnen samenstellen en opvragen.
Voorbeelden zijn het bevragen door een bepaalde
medewerker, voor een bepaalde BSN, voor een
bepaalde taak, in een bepaalde periode, buiten een
bepaald werkgebied etcetera.
• Standaard rapportages die op aanvraag beschikbaar
worden gesteld.
• Ondersteuning bij doelgericht onderzoek.

Gebruikers worden meer betrokken in hun gebruik van gegevens

 

Zij moeten goed op de hoogte zijn
voor welke taak zij gebruik maken
van het stelsel.
De gebruiker ziet:
• Wie is ingelogd.
• Welke rol de gebruiker heeft.
• Een melding dat alle bevragingen worden gelogd.
• Het aantal bevragingen: per dag en per maand.
• Overzichtshistorie van het aantal bevragingen per
maand voor de achterliggende 12 maanden.
• Toegang tot de gebruikersvoorwaarden.

Elke organisatie verantwoordt

 

Alle partijen die gebruik maken van
de GeVS moeten zich
verantwoorden. De wijze waarop
verschilt per organisatie.
• De SUWI-ketenpartijen UWV en SVB inclusief het
BKWI en IB verantwoorden zich rechtstreeks aan de
minister van Sociale Zaken en Werkgelegenheid
(SZW).
• De SUWI-ketenpartij gemeente legt verantwoording
af aan de gemeenteraad.
• Alle overige partijen verantwoorden conform het
besluit dat door de bronhouder is verstrekt.

De bronhouder of stelsel-verantwoordelijke kan maatregelen nemen bij (ernstige) overtredingen

Een voorziening die de bronhouder
of de stelselverantwoordelijke in
staat stelt om bij ernstige
overtredingen van het gebruik
specifieke maatregelen te nemen,
bijvoorbeeld de Killswitch.
• De levering van een bepaalde bron naar een
bepaalde afnemer wordt gestopt.
• De levering van alle bronnen naar een bepaalde
afnemer wordt gestopt.
• De levering van een bepaalde bron naar alle
afnemers worden gestopt.
• De mogelijkheden moeten separaat kunnen worden
uitgevoerd op Suwinet-inkijk en Suwinet-inlezen.

8.2 Afspraken en eisen

Informatiebeveiliging is het geheel van preventieve, detecterende, repressieve en herstellende maatregelen die de risico’s en de eventuele gevolgschade van informatiebeveiligingsincidenten tot een acceptabel, vooraf bepaald niveau beperken.

Het doel van dit geheel aan informatiebeveiligingsmaatregelen is de beschikbaarheid, integriteit en vertrouwelijkheid van alle vormen van informatie te garanderen en zodoende een betrouwbare informatievoorziening te waarborgen. Hiervoor treft men de noodzakelijke organisatorische, procedurele, fysieke en technische maatregelen die gebaseerd zijn op een (organisatie-­‐ afhankelijke) risicoanalyse of een wettelijk verplichting.

Het uniforme niveau van betrouwbaarheid ligt vast in de vorm van afspraken en eisen in bijlage I van de Regeling SUWI en is nader ingevuld in (ketenbrede) afspraken. Concreet betekent dit dat de SUWI-­‐partijen onderling en gezamenlijk, met de beheerder van de centrale voorziening, eisen stellen en hierover nadere afspraken maken op de verschillende deelgebieden van informatie-­‐uitwisseling binnen de Suwiketen.

De vastgestelde eisen en de gemaakte afspraken vinden hun weerslag in diverse producten, bijvoorbeeld de Keten Service Level Agreement, de keten Bewerkersovereenkomst, het SUWI-­‐Gegevens Register, de SUWI-­‐ Ketenarchitectuur en de Verantwoordingsrichtlijn Privacy & Beveiliging GeVS.

De wettelijke voorschriften rond privacy en informatiebeveiliging zijn in de verantwoordingsrichtlijn van de GeVS verder uitgewerkt. De verantwoordingsrichtlijn bevat de normen, criteria en vormvereisten die nodig zijn voor de onderbouwing van het oordeel over de beveiliging of voor de verklaring van getrouwheid (ex. art 5.22 regeling SUWI) over de privacy en informatiebeveiliging van de GeVS in de Jaarverslagen van de op de GeVS aangesloten ontvangende partijen en de beheerder van de centrale voorziening.

H9. Aansluiten nieuwe partijen

De Gezamenlijke elektronische Voorzieningen SUWI (GeVS) is een stelsel van voorzieningen dat gegevens transporteert en beschikbaar stelt. De GeVS is wettelijk aangewezen als hulpmiddel voor de uitwisseling van gegevens die de medewerkers van de SUWI-­‐ketenpartijen nodig hebben voor de uitvoering van de wettelijke taken (artikel 5.21 van het Besluit SUWI).

De GeVS ontsluit meer informatie dan alleen die van de SUWI-­ketenpartijen zelf. SUWI‐ketenpartijen krijgen ook gegevens vanuit aanvullende bronnen, zoals de basisregistratie Voertuigen, Verificatie Informatie Systeem (VIS), de basisregistratie persoonsgegevens (BRP), studiefinancieringen, opleidingen, gegevens over vastgoed (eigendom en waarde) en informatie over ondernemingen en diens rechtspersonen.

Ook publieke organisaties die niet tot de SUWI-­‐partijen behoren, kunnen aansluiten op de GeVS en daarmee rechtstreeks toegang krijgen tot de gegevens die via de GeVS worden uitgewisseld. Voorwaarde voor aansluiting is dat zij het aansluitprotocol doorlopen zoals beschreven in bijlage III, behorende bij artikel 6.5 van de Regeling SUWI.

9.1 Procedure

De voorwaarden die van toepassing zijn op de aansluiting van afnemende partijen en de ontsluiting door leverende partijen (basis-­‐ en ketenregistraties) staan beschreven in het Aansluitprotocol (bijlage III van de regeling SUWI:

  1. Waar moet een applicatie van een afnemende partij aan voldoen om aan te kunnen sluiten? Conform het Suwinet-­‐Normenkader moeten de inlezende applicaties voldoen aan de normen die ook aan Suwinet-­‐Inkijk worden gesteld. Bijvoorbeeld het inregelen van autorisaties voor toegang tot de applicatie en de gegevens door gebruikmaking van gebruikersprofielen, wachtwoorden, rollen en functies en Verder moeten de organisaties minimaal achteraf door logging kunnen toetsen wie op welk moment welke informatie over een bepaalde burger heeft geraadpleegd.
  2. Waar moet een afnemende organisatie aan voldoen om gebruik te mogen maken van de gegevens? We gaan in op de organisatorische en fysieke beveiligingsmogelijkheden om doelbinding en privacy te waarborgen. We beschrijven hoe de verantwoording dient plaats te vinden. Bijvoorbeeld met een extra paragraaf in het jaarverslag
  3. Het Aansluitprotocol. Dit protocol geeft aan welke stappen een potentiële afnemende publieke partij moet zetten om toegang te krijgen tot de gegevens

9.2 Aansluiten op de GeVS

Via de GeVS kunnen de bronhouders de (geautoriseerde) gegevens via de voorzieningen Suwinet-­‐Inkijk of Suwinet-­‐Inlezen aan de afnemers beschikbaar stellen. De bronhouder is de verantwoordelijke in de zin van de Wbp voor het bewaren en verstrekken van persoonsgegevens aan de afnemer. Bij een verzoek van een afnemer om gegevens te verstrekken, voert de bronhouder een toets uit conform de Wbp:

  • Wettelijke grondslag: bestaat er een wettelijke grondslag om de gevraagde gegevens te leveren?
  • Doelbinding, proportionaliteit en subsidiariteit: zijn de gegevens nodig voor de uitvoering van wettelijke taken (worden er niet te veel gegevens gevraagd)?
  • Wijze van gegevensverstrekking: de bronhouder bepaalt in overleg met de afnemer de wijze van

Na een positieve toets worden de afspraken (over welke gegevens voor welke reden, via welke voorziening worden uitgewisseld) door de bronhouder in een besluit of overeenkomst vastgelegd. Op basis van dat besluit of die overeenkomst kan de gegevensverstrekking worden ingericht.

Voor de onderlinge uitwisseling tussen de SUWI­‐ketenpartijen is een apart besluit niet nodig, voor zover deze gegevens zijn opgenomen in bijlage II behorende bij artikel 5.2a van het Besluit SUWI. De daaraan voorafgaande procedure (de toetsing op wettelijke grondslag, doelbinding en proportionaliteit) uiteraard wel.

In feite komt het erop neer dat per verzoek voor gegevensverstrekking de bronhouder een besluit neemt over de verstrekking van gegevens. Dat besluit vermeldt:

  • De wettelijke grondslag voor de verstrekking.
  • De set gegevens en/of informatie (als uitkomst van de toets op doelbinding, proportionaliteit en subsidiariteit).
  • De toepasselijkheid van de Gedragscode UWV/SVB/VNG.
  • De wijze van verstrekking.

De gegevenslevering verloopt via de bewerkers BKWI of het IB. Dat betekent:

  • De bewerker krijgt een opdracht om in overleg met de afnemers uitvoering te geven aan het besluit tot verstrekking.
  • De bewerker krijgt een mandaat om afspraken met de afnemers te maken over de aansluitvoorwaarden.
  • De bronhouder brengt het besluit ter kennis van de afnemer.
  • Na ontvangst van de bevestiging wordt het besluit uitgevoerd.

Voor de aansluiting op de door de bewerker beschikbaar gestelde voorzieningen moet de afnemende organisatie de afspraken in de aansluitvoorwaarden ondertekenen en nakomen.

9.2.1.        Levering via Suwinet‐Inkijk

Bronhouders en afnemers kunnen onderling overeenkomen dat de gegevenslevering via Suwinet-­‐Inkijk verloopt. Via deze centrale webapplicatie kunnen geautoriseerde gebruikers persoonsgegevens van burgers raadplegen die bij verschillende organisaties of basisregistraties zijn opgeslagen. In overleg met de bronhouder en de afnemer(s) zorgt het BKWI ervoor dat de afgesproken gegevensset via één of meerdere inkijkpagina’s kan worden getoond. Het verzorgen van de toegang (autorisatie) tot deze applicatie en de inkijkpagina’s voor de individuele medewerkers is een verantwoordelijkheid van de individuele afnemers.

9.2.2.        Levering via Suwinet­‐Inlezen

Bronhouders kunnen besluiten de gevraagde gegevens via de GeVS voorziening ‘Inlezen’ direct af te leveren bij de afnemer. De afnemer verwerkt deze gegevens in de eigen bedrijfsapplicatie die daarvoor geschikt is gemaakt. Inlezen via de GeVS wordt op twee manieren mogelijk gemaakt:

  • De gegevenslevering verloopt via het BKWI (dit noemen we Suwinet-­‐Inlezen).
  • De gegevenslevering verloopt via het IB (dit noemen we DKD-­‐Inlezen).

Voor de (op dit moment) 393 gemeenten is een  speciale voorziening ontwikkeld (DKD-­‐Inlezen) die een optimale uitwisseling tussen gemeenten en de GeVS faciliteert. Deze speciale voorziening (IBIS-­‐ Inlichtingenbureau Informatie Systeem) is in beheer bij het Inlichtingenbureau dat hiermee ook de levering van en naar gemeenten (voor het domein werk en inkomen) verzorgt. In alle andere situaties vindt de levering plaats via het BKWI.

De technische aansluiting voor gemeenten wordt door het IB verzorgd. Het BKWI verzorgt de technische aansluiting voor de SUWI-­‐ketenpartijen SVB en UWV, en voor alle niet SUWI-­‐ketenpartijen. Voor de technische aansluitprocedure kan men contact opnemen met het IB of het BKWI.

9.3.         Afspraken over gegevens

De SUWI-­‐ketenpartijen kennen aanvullend op het besluit SUWI ook een SLA (de GeVS-­‐SLA) waarin de voorwaarden voor het gezamenlijk gebruik en beheer van de GeVS en de gegevens zijn vastgelegd.

De afspraken die een SUWI-­‐ketenpartij maakt met een partij buiten de keten, worden door de verstrekker van de gegevens vastgelegd in een besluit of in een gezamenlijke overeenkomst.

Afspraak 43       De registratiehouder en de afnemer komen onderling overeen welke gegevens tot een bepaalde uitwisseling horen.

 Hierbij hoort ook de toets op proportionaliteit en de mate waarin deze gegevens beschikbaar moeten zijn. De registratiehouder is als verantwoordelijke voor de registratie aanspreekbaar op het verwerken en het gebruik van de vastgelegde persoonsgegevens (ex art. 1 Wbp).

Afspraak 44       De afspraken tussen ketenpartijen onderling zijn vastgelegd in een Service Level Agreement (de GeVS-­‐SLA).

 Afspraak 45       Informatie die wordt aangeboden aan een afnemer moet voldoen aan de wettelijke bepalingen zoals vastgesteld in de Wbp, de Wet SUWI en andere materiewetgevingen. 

  • De afnemer

Na de verstrekking eindigt de Wbp-­‐verantwoordelijkheid van de bronhouder voor de verstrekte gegevens. De zorgplicht voor de naleving van de Wbp-­‐verplichtingen (art. 15 Wbp) brengt daar geen verandering in. De zorgplicht richt zich op de Wbp-­‐verantwoordelijke. Dit betekent dat de bronhouder als verstrekker niet verantwoordelijk is voor (en aanspreekbaar is op) de verwerking van de persoonsgegevens door de afnemer.

Dit betekent ook dat de bronhouder geen controlerende of handhavende taak heeft in de wijze waarop de afnemer als Wbp verantwoordelijke de ontvangen persoonsgegevens verwerkt.

De afnemer van gegevens is (volledig) verantwoordelijke in de zin van de Wbp voor de eigen verwerking van persoonsgegevens. Dat betekent dat hij zorgvuldig met die persoonsgegevens omgaat, conform de bepalingen van de Wbp met inachtneming van eventuele andere wettelijke verplichtingen. Deze verplichtingen gelden vanaf het moment dat hij de feitelijke macht verkrijgt over deze persoonsgegevens. De afnemer is volledig verantwoordelijk voor en aanspreekbaar op een rechtmatige verwerking van persoonsgegevens conform de Wbp.

  • Verantwoording

Een SUWI-­‐ketenpartij is verantwoordelijk voor en aanspreekbaar op de naleving van de Wbp-­‐verplichtingen, zowel in de hoedanigheid van verstrekker als in de hoedanigheid van gebruiker. Op basis van de huidige SUWI-­‐wetgeving moeten UWV, SVB, BKWI en het IB zich jaarlijks met een onafhankelijke audit aan de minister van SZW verantwoorden over de gegevensverstrekking via de GeVS. Gemeenten verantwoorden in principe aan de gemeenteraad, alhoewel er geen wettelijke verantwoordingsplicht voor de gemeenten in de wet SUWI is opgenomen.

Het toezicht op de naleving van de Wbp ligt bij de Inspectie SZW en bij het CBP.