Projectstartarchitectuur Digilevering. Definitief versie 1.2

Projectstartarchitectuur Digilevering Definitief – versie 1.2

Projectstartarchitectuur Digilevering

•••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• Auteur Team RENOIR Versie 1.2 Den Haag, 11 maart 2010


3/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Versiebeheer

Versie

Datum

Auteur

Status

1.2

11 maart 2010

Team RENOIR

Definitief

1.1

26 februari 2010

Team RENOIR

Concept t.b.v. vooraankondiging offerteaanvraag Hoofdstuk 6 – Informatiebeveiliging nader gedetailleerd Paragraaf 4.3.4 – bericht-id en OIN afzender uit berichtspecificatie gehaald.

1.0

3 december 2009

Team RENOIR

0.7

24 november 2009 Team RENOIR

Definitieve versie Conceptversie ten behoeve van de oplevering aan de Stelsel Stuurgroep (1 december 2009).

0.6

30 oktober 2009

Team RENOIR

Conceptversie ten behoeve van de oplevering aan de opdrachtgever, Stelseloverleg, Stelselgebruikersoverleg, werkgroep en andere belanghebbenden.

0.5

26 oktober 2009

Rob Stovers,

'Bevroren' tussenversie tbv Risicoanalyse.

Roland Wessel

Reviewresultaten werkgroep Digilevering en impactanalyse mGBA verwerkt. Review door deelnemers werkgroep Digilevering.

0.4

5 augustus 2009

Rob Stovers

Resultaten werkgroep Autorisatie verwerkt. Hoofdstuk 2 toegevoegd. Versie t.b.v. Review door deelnemers werkgroep Digilevering

0.3

30 juli 2009

Rob Stovers

Versie ten behoeve van de werkgroep Digilevering m.b.t. autorisatie van 4 augustus 2009.

0.2

9 juli 2009

0.1

25 juni 2009

Rob Stovers,

2e versie ter bespreking met de werkgroep

Roland Wessel

Digilevering van 14 juli 2009.

Rob Stovers,

1e versie ter bespreking met de werkgroep

Roland Wessel

Digilevering van 30 juni 2009.


4/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Inhoud 1 1.1 1.2 1.3 2 2.1 2.2 2.3 2.4 3 3.1 3.2 3.2.1 3.2.2 3.2.3 3.2.4 3.3 3.3.1 3.3.2 3.4 3.4.1 3.4.2 3.4.3 4 4.1 4.2 4.2.1 4.2.2 4.2.3 4.2.4 4.3 4.3.1 4.3.2 4.3.3 4.3.4 4.4 4.4.1 4.4.2

Inleiding Doel en doelgroep Werkwijze Opbouw van dit document Project Beschrijving context Huidige situatie Digilevering op hoofdlijnen Uitgangspunten Bedrijfsarchitectuur Digilevering Organisatie Registratiehouders, houders landelijke voorziening en afnemers Serviceorganisatie Digilevering Verantwoordelijkheden Relevante NORA-principes Diensten, producten en services Relevante NORA-principes Services Processen Relevante NORA-principes Beschrijving primaire processen Ondersteunende (of secundaire) processen Informatie-architectuur Ontwerpbeslissingen Mensen en applicaties Toepassing relevante NORA-principes Interface: mens en/of applicatie? Functionaliteit Digilevering Autorisatie Berichten en gegevens Relevante NORA-principes Objecten Gegevens Berichten Informatie-uitwisseling Relevante NORA-principes Gebruik van OSB 2.0

6 6 6 7 8 8 11 12 16 17 17 18 18 19 20 21 22 23 24 26 26 28 33 35 35 40 40 42 43 46 49 49 52 55 63 68 68 68


5/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

5 5.1 5.2 5.2.1 5.3 5.3.1 5.3.2 5.3.3 5.3.4 5.3.5 5.4 5.4.1 5.4.2 5.4.3 5.4.4 5.4.5 5.4.6 5.5 5.6 5.6.1 6 6.1 6.2 6.2.1 6.2.2 6.2.3 6.3 6.3.1 6.3.2 6.3.3 6.3.4 6.3.5

Technische architectuur Relevante NORA-principes Applicatie architectuur Overzicht Digilevering Portaal Inleiding Overzicht Gebruikersinterface Beveiliging Koppeling met de Stelselcatalogus Digilevering Core Inleiding Overzicht Webservices Berichtvolgorde Beveiliging Koppelingen externe systemen Logische opbouw Technische infrastructuur Overzicht Beveiliging NORA Interne oriëntatie Bedrijfsstrategie en doelstellingen Informatieclassificatie Risico's voor de organisatie Externe oriëntatie Wet en regelgeving Contractuele eisen ISO/IEC 27002 NORA Algemene beveiligingsprincipes NORA-principes ICT-voorzieningen

70 70 71 71 72 73 73 73 73 74 74 75 75 75 75 76 76 77 78 79 82 82 83 83 83 84 85 85 86 86 87 91


6/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

1

Inleiding

1.1 Doel en doelgroep Dit document beschrijft de startarchitectuur van Digilevering (voorheen de GOB Abonnementenvoorziening). De startarchitectuur is bedoeld om de keuzes helder te maken die ten grondslag liggen aan het ontwerp. Daarmee geeft het inzicht in de functionele en technische (on)mogelijkheden. De startarchitectuur beschrijft de op te leveren producten en diensten, bedrijfsprocessen, informatiesystemen en ICT-infrastructuren. Dit document wordt gebruikt: • Om de uitgangspunten, principes en ontwerpkeuzes vast te stellen ten behoeve van functioneel en technisch ontwerp en verdere inrichting; • De gemaakte keuzes te valideren bij besluitvorming; • De ingezette richting en gemaakte keuzes te communiceren met registratiehouders en afnemers van Digilevering. De doelgroep bestaat uit: • programmamanagement RENOIR; • opdrachtgever; • stelseloverleg; • gebruikersoverleg stelsel; • strategisch stelselberaad; • werkgroep Digilevering (voorheen de werkgroep GOB Abonnementenvoorziening); • architecten en managers van registratiehouders en overheidsorganisaties die betrokken zijn bij de aansluiting op het stelsel van basisregistraties; • functioneel en technisch ontwerpers, betrokken bij de verdere ontwikkeling van Digilevering. 1.2 Werkwijze Tijdens het realiseren van deze projectstartarchitectuur (en ook het functioneel ontwerp) Digilevering heeft regelmatige afstemming plaatsgevonden met de werkgroep Digilevering, met daarin deelname van KvK (NHR), Belastingdienst, Logius (voorheen GBO.Overheid), Justitie, VROM (Kadaster en BAG), RDW, RNI, Waarderingskamer, mGBA en de opdrachtgever BZK/DRI. Bij het afronden van de projectstartarchitectuur in concept is een review uitgezet onder de leden van de werkgroep Digilevering, het Stelseloverleg en het Stelselgebruikersoverleg alvorens deze aan te bieden aan het Strategisch Stelselberaad voor advies aan de opdrachtgever BZK/DRI.


7/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

1.3 Opbouw van dit document De voorliggende startarchitectuur is opgebouwd volgens het architectuurraamwerk uit de NORA en bestaat daarom uit drie lagen, namelijk de bedrijfs-, informatie-, en technische architectuur. Daarnaast zijn er nog twee generieke dimensies binnen de Nederlandse Overheid Referentie Architectuur (NORA) onderkend: beveiliging en beheer. Deze dimensies hebben hun impact op alle drie de lagen. Hoofdstuk 2 beschrijft de positionering van Digilevering ten opzichte van de bouwstenen van de NORA en de onderkende GOB-componenten. Daarnaast wordt Digilevering op hoofdlijnen beschreven en de scope van het project Digilevering aangegeven. Het derde hoofdstuk beschouwt de bedrijfsarchitectuur van Digilevering. In dit hoofdstuk wordt Digilevering in termen als organisatie, diensten, producten, business services en processen beschreven. De informatie-architectuur van Digilevering beschrijft de functionele inrichting van de (geautomatiseerde) informatievoorziening, waarmee de in het voorgaande hoofdstuk beschreven business services en processen worden ondersteund dan wel volledig geautomatiseerd worden uitgevoerd (hoofdstuk 4). In hoofdstuk 5 is de technische architectuur van Digilevering beschreven. Er wordt een overzicht gegeven van de applicatie architectuur en ingezoomd op de onderkende applicaties. Ten slotte wordt de technische infrastructuur beschreven waarbinnen Digilevering geïmplementeerd kan gaan worden. In het laatste hoofdstuk (hoofdstuk 6) worden de risico's binnen de dienst Digilevering inzichtelijk gemaakt, alsmede de maatregelen om de risico's te reduceren tot een acceptabel niveau. De (NORA-)dimensie beheer is niet in deze projectstartarchitectuur opgenomen, maar nader uitgewerkt in de Usecase Model Digilevering en de betreffende Usecase-packages.


8/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

2

Project

2.1 Beschrijving context Burgers en bedrijven verwachten een goed functionerende, dienstverlenende overheid. Samenwerking tussen overheidsorganisaties is hiervoor een belangrijke voorwaarde. Daarbij stemmen zij processen af en maken gebruik van elkaars informatie. In de NORA [6], de Nederlandse Overheid Referentie Architectuur, zijn diverse bouwstenen benoemd en beschreven, die bij het realiseren van de samenwerking benodigd zijn. In onderstaande figuur zijn de onderkende bouwstenen benoemd. Contactfuncties Webrichtlijnen

MijnOverheid.nl

Samenwerkende Catalogi

Antwoord voor Bedrijven

Overheid heeft Antwoord

Basisregistraties Departement

Personen GBA RNI

Provincie

Identity management DigiD

Bedrijven

Waterschap

NHR

Gemeente machtigingen

Gebouwen BAG

Uitvoering

Percelen

BSN

Kadaster

etc PKI overheid

etc

etc

Informatieuitwisseling Overheids servicebus

Terugmeld faciliteit

Gemeenschappelijke ontsluiting basisregisters

Figuur 1: Overzicht bouwstenen e-overheid (NORA) Het inrichten en gebruiken van basisregistraties (weergegeven aan de rechterkant van het figuur) is een belangrijke voorwaarde om ervoor te zorgen dat alle overheidsinstellingen over de 'kerngegevens' van de Nederlandse overheid kunnen beschikken. Deze gegevens


9/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

worden slechts eenmalig uitgevraagd bij burgers en bedrijven. Overheidsinstellingen zijn verplicht de authentieke gegevens uit basisregistraties te gebruiken in hun processen. Het afnemen van (authentieke) gegevens uit basisregistraties gebeurt veelal via landelijke voorzieningen, waarin de gegevens van (decentrale) basisregistraties landelijk worden ontsloten. Naast een gebruiksplicht hebben overheidsinstellingen de plicht om bij gerede twijfel over de inhoud van gegevens uit een basisregistratie, dit terug te melden. Aldus ontstaan een proces van leveren van en terugmelden op basisregistratiegegevens. Schematisch is dit als volgt weer te geven: Landelijke voorzieningen

Afnemers

Basisregistraties BAG

LV-BAG

Levering

BAG BAG

LV-WOZ

●

Generieke Voorzieningen ●Diensten ●Standaarden

BAG

BRI NHR

NHR

Terugmelding LV-xx

Figuur 2: Levering en terugmelding van basisregistratiegegevens In het midden van de figuur staan de generieke voorzieningen, diensten en producten die, stapsgewijs, worden ontwikkeld om het gebruik van en terugmelden op gegevens van basisregistraties, te vereenvoudigen. Enkele voorzieningen zijn al operationeel, zoals Digimelding voor terugmeldingen en de Stelselcatalogus voor inzicht in de metagegevens van basisregistraties. De 'generieke bouwsteen' die de ontsluiting van basisregistraties ondersteunt is Gemeenschappelijke Ontsluiting Basisregistraties (GOB). GOB is een stelsel van standaarden, diensten en voorzieningen die de ontsluiting van basisregistraties uniform en eenduidig laat plaatsvinden. In de Startarchitectuur GOB [1] is uiteen gezet uit welke onderdelen de GOB bestaat. In onderstaande figuur (uit de startarchitectuur) zijn de GOBcomponenten benoemd1: 1

In de figuur zijn de verschillende GOB-componenten gekoppeld aan een fasemodel voor het bij elkaar brengen van vraag en aanbod. Indien componenten in de figuur meerdere keren zijn genoemd, betekent dit, dat ze voor meerdere fasen relevant zijn. Voor meer informatie over de fasen, zie de Startarchitectuur GOB (Bron [1]).


10/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Orientatiefase

Autorisatie fase

Definitie fase

Gebeurtenis fase

Productie fase

Leverings fase

GOB Diensten

BR

Hulp bij aansluiten

Vraag

Verbeteren

Toezien op

Monitoren markt Ondersteunen/initiëren nieuwe ontwikkelingen

GOB Voorzieningen Stelsel catalogus

Autorisatie registratie

Stelsel catalogus Abonnement specificatie

Enkelvoudige levering

Aanbod BR

Samengestelde levering Abonnement levering

BR

GOB Standaarden Afspraken/ leveringsvoorwaarden

Autorisatieproces

Granulariteit

Afspraken/ leveringsvoorwaarden

Berichtenstructuur

Granulariteit

Granulariteit

BR

Change procedures

Figuur 3: GOB-componenten In de Startarchitectuur GOB zijn twee componenten afgebakend op het gebied van abonnementen: • Abonnementspecificatie: voorziening waarin afnemers hun abonnementspecificaties kunnen specificeren en aanpassen; • Abonnementenlevering: voorziening die aan afnemers gegevens levert op basis van tussen afnemer en registratiehouder gemaakte abonnementsafspraken. Beide componenten maken onderdeel uit van Digilevering, zoals die in deze startarchitectuur nader is uitgewerkt. Digilevering heeft ook relaties met andere GOB-onderdelen (diensten, voorzieningen en standaarden). De relaties zijn als volgt te duiden: • De Stelselcatalogus, sinds april 2009 operationeel, bevat (meta)gegevens die relevant zijn voor Digilevering. Het betreft de door een registratiehouder onderkende gebeurtenissoorten, objecttypen en attribuuttypen. Een koppeling tussen Digilevering en de Stelselcatalogus is voorzien, zodat Digilevering gebruik kan maken van definities van gebeurtenissoorten; • De Afspraken/Leveringsvoorwaarden. In het eerste kwartaal van 2009 is een handreiking opgeleverd die door afnemers en registratiehouder kan worden gebruikt om tot afspraken te komen voor het gebruik van gegevens uit basisregistraties. Het leveren van gegevens door middel van abonnementen is één van de onderkende


11/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

•

•

leveringsvormen. De handreiking gebruiksvoorwaarden kan worden gebruikt bij het afsluiten van contracten; De (standaardisatie van de) berichtstructuur raakt ook het berichtenverkeer rondom abonnementen. In het standaardisatietraject is de inhoudelijke haalbaarheid van de combinatie StUF en NEN3610 als standaard berichtstructuur voor de ontsluiting van basisregistraties onderzocht. De GOB Berichtenstandaard zal niet tijdig beschikbaar zijn voor Digilevering. In overleg met registratiehouders en afnemers zal de structuur van de berichten van en naar Digilevering worden vastgesteld. Daarbij zal, voor zover mogelijk, worden bekeken hoe op de ontwikkeling van een GOB Berichtstructuur kan worden geanticipeerd; Binnen de GOB zijn onderdelen rondom autorisatie (autorisatieregistratie en standaardisatie autorisatieproces) onderkend. Op dit moment zijn er geen lopende initiatieven om te komen tot een generieke autorisatievoorziening. Aangezien Digilevering gerelateerd is aan autorisatie (zie paragraaf 4.2.4) zal, indien de autorisatieonderdelen worden opgepakt, de afstemming worden gezocht.

In het kader van het NUP (Nationaal Uitvoeringsprogramma dienstverlening en e-overheid) is afgesproken om voor eind 2010 de volgende stappen te zetten op dit terrein [10]: • alle bestuurslagen maken verplicht gebruik per 1-1-2010; • alle bestuurslagen maken gebruik van de GOB standaarden en voorzieningen; • alle bestuurslagen dragen bij aan de doorontwikkeling van de GOB standaarden en voorzieningen; • alle bestuurslagen ondersteunen de brede toepassing van de GOB standaarden en producten. 2.2 Huidige situatie In de vorige fase van het project Digilevering is onderzoek gedaan naar de op dit moment bestaande abonnementsystematieken en voorzieningen bij zowel registratiehouders als afnemers. Daaruit komt naar voren dat het verstrekken van gegevens op basis van abonnementen bij sommige registratiehouders sinds jaar en dag gemeengoed is en bij sommige registratiehouders (nog) niet is ingericht. Tevens zitten er verschillen in de manier van verstrekken en de frequentie waarmee afnemers mutaties geleverd krijgen. Zie [2] voor de resultaten van het onderzoek. Tevens is bij zowel registratiehouders als afnemers geïnventariseerd welke behoefte er is aan (onderdelen van) een generieke abonnementenvoorziening, op basis van de in de voorgaande fase van het project uitgevoerde definitiestudie. Op basis van de uit de inventarisatie gebleken behoefte, is door de opdrachtgever (BZK/DRI) besloten opdracht te geven voor de uitvoering van de fase architectuur en functioneel ontwerp.


12/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

2.3

Digilevering op hoofdlijnen

Afbakening: gebeurtenisgedreven enkelvoudige abonnementen In de Startarchitectuur GOB [1] zijn verschillende vormen van levering van basisregistraties aan afnemers onderkend. Onderstaande figuur2 geeft de typologie van leveringen weer. In de typologie staan twee dimensies centraal: • de inhoudelijke reikwijdte van de levering (enkelvoudig versus samengesteld) • het communicatiepatroon voor de levering (bevraging versus melding). BAG

LV-BAG

Levering Digilevering Generieke ●Voorzieningen ●Diensten ●Standaarden

Digimelding

BAG BAG

LV-WOZ BAG

BRI NHR

NHR

Terugmelding LV-xx

Communicatiepatroon Inhoudelijke reikwijdte

Enkelvoudig (1 BR nodig)

Samengesteld (meer BR’s nodig)

A

BR

Bevraging

A

BR Melding

Directe enkelvoudige levering

Uitgestelde enkelvoudige levering

Directe samengestelde levering

Uitgestelde samengestelde levering

Enkelvoudig abonnement Periodieke verstrekking

Gebeurtenisgedreven

Samengesteld abonnement

Figuur 4: Typologie van levering De dimensie 'inhoudelijke reikwijdte' kent als indeling: • Enkelvoudige levering: Een gegevenslevering door precies één basisregistratie in antwoord op een vraag van een afnemer3; • Samengestelde levering: Een gegevenslevering die wordt gecombineerd uit leveringen vanuit twee of meer basisregistraties in antwoord op een vraag van een afnemer. De dimensie 'communicatiepatroon' kent als indeling: 2

Legenda: A = Afnemer; BR = basisregistratie; pijl bovenlangs is de vraag van de afnemer, pijl onderlangs is het antwoord van de basisregistratie(houder). 3

De omvang (in aantallen objecten of attributen) van de gegevenslevering doet hier niet ter zake. Zolang één basisregistratie de levering kan verzorgen, is er sprake van enkelvoudige levering.


13/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

•

Bevraging: na de vraagstelling wordt het initiatief voor levering van gegevens niet overgedragen, wat inhoudt dat er geen functionele leveringscriteria zijn gesteld die onmiddellijke levering verhinderen;

•

Melding: na de vraagstelling wordt het initiatief voor levering van gegevens overgedragen waarbij het moment van leveren afhangt van vooraf overeengekomen functionele leveringscriteria.

De typen leveringsvormen zijn als volgt te omschrijven: • Directe enkelvoudige levering: een gegevenslevering door precies één basisregistratie, geleverd direct na de vraagstelling van een afnemer; • Directe samengestelde levering: een gegevenslevering die wordt gecombineerd uit leveringen vanuit twee of meer basisregistraties, geleverd direct na de vraagstelling van een afnemer; • Uitgestelde enkelvoudige levering: een gegevenslevering door precies één basisregistratie, geleverd op een tussen afnemer en leverancier overeengekomen tijdstip; • Uitgestelde samengestelde levering: een gegevenslevering die wordt gecombineerd uit leveringen vanuit twee of meer basisregistraties, geleverd op een tussen afnemer en leverancier overeengekomen tijdstip; • Enkelvoudig abonnement: een gegevenslevering door precies één basisregistratie, waarbij het (de) moment(en) van levering afhangt van overeengekomen functionele leveringscriteria. De functionele criteria kunnen tijdgestuurd of gebeurtenisgestuurd zijn; • Samengesteld abonnement: een gegevenslevering die wordt gecombineerd uit leveringen vanuit twee of meer basisregistraties, waarbij het (de) moment(en) van levering afhangt van overeengekomen functionele leveringscriteria. De functionele criteria kunnen tijdgestuurd of gebeurtenisgestuurd zijn. Digilevering richt zich alleen op de enkelvoudige, gebeurtenisgestuurde abonnementen. Het inrichten van een voorziening die alle leveringsvormen ondersteund is te complex. Aan ondersteuning van enkelvoudige gebeurtenisgestuurde abonnementen is door zowel registratiehouders als afnemers een hoog belang en een hoge urgentie toegekend. Andere vormen van levering worden dus niet door Digilevering ondersteund. In de komende jaren zullen ook voor de andere leveringsvormen (mogelijk) generieke voorzieningen worden ontwikkeld. Kernfunctionaliteit in vogelvlucht In de volgende hoofdstukken wordt Digilevering uitgebreid beschreven. De belangrijkste concepten en functionaliteiten van Digilevering worden hier alvast beschreven. Dit vormt het begrippenkader voor de verdere uitdieping in de volgende hoofdstukken.


14/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

De kernfunctionaliteit van Digilevering is het distribueren van door basisregistraties aangeleverde (berichten over) gebeurtenissen aan afnemers die daarop geabonneerd zijn. Gebeurtenissen zijn bijvoorbeeld: 'starten onderneming x' , 'geboorte persoon y' of 'nieuwe openbare ruimte z'. Afnemers zijn overheidsinstellingen of private instellingen met een publiekrechtelijke taak, die gebeurtenissen mogen en willen ontvangen in het kader van hun wettelijke taken. Afnemers en registratiehouders/houders landelijk voorziening sluiten een contract (juridische titel), waarin is vastgelegd van welke soorten gebeurtenissen een afnemer gebeurtenissen mag ontvangen en onder welke condities. De soorten gebeurtenissen (bijvoorbeeld: 'starten onderneming'; 'vaststellen inkomen'; 'sloop gekentekend voertuig') worden vastgesteld door de registratiehouder/houder landelijke voorziening. In Digilevering worden de contractuele afspraken dusdanig vastgelegd, dat de voorziening daarmee in staat is eenduidig vast te stellen of een door een registratiehouder/houder landelijke voorziening aangeboden gebeurtenis moet worden verstrekt aan een afnemer. In een abonnement wordt vastgelegd: • welke soorten gebeurtenissen (in beginsel) worden geleverd; • (indien van toepassing) welke gebeurtenisfiltering wordt toegepast. Indien een afnemer niet alle gebeurtenissen van een bepaalde soort mag of wil ontvangen, kan de levering van gebeurtenissen worden ingeperkt. Dit gebeurt door op één of meer eigenschappen van een gebeurtenis, condities aan te geven. Bijvoorbeeld een conditie op een geografisch gebied ('alleen de provincie Utrecht') of een geboortedatum ('geboortedatum < 01/01/1979'). De mogelijke condities zijn afhankelijk van de soort gebeurtenis; • (indien van toepassing) welke objectlijst wordt toegepast . Een afnemer kan een lijst met objecten definiëren waarin hij, gezien de taakuitvoering van de organisatie, geïnteresseerd is. Dit kan bijvoorbeeld een lijst zijn met personen (BSN's), gekentekende voertuigen (Kentekens) of ondernemingen (KvK-nummers). In het abonnement wordt opgenomen wat voor soort objectlijst wordt gebruikt; • welke gegevenselementen van een soort gebeurtenis geleverd (mogen) worden. Het gebeurtenisfilter en de objectlijst bepalen of een gebeurtenis wordt geleverd. Dat betekent niet, dat ook alle gegevens van een gebeurtenis geleverd (mogen) worden. In het abonnement is daarom ook opgenomen welke gegevenselementen van een soort gebeurtenis geleverd mogen worden. Dit is afhankelijk van de voor de taak van de afnemer benodigde gebeurtenisgegevens. Nadat het abonnement door zowel afnemer als registratiehouder/houder landelijke voorziening is goedgekeurd en vrijgegeven, kan de daadwerkelijke distributie van gebeurtenissen plaatsvinden. Van een aangeboden gebeurtenis wordt per abonnement vastgesteld of deze moet worden aangeboden aan de afnemer van het abonnement (de


15/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

abonnementhouder). Slechts indien is voldaan aan alle filtercondities en de toets met de objectlijst positief is, wordt de gebeurtenis geleverd, waarbij alleen de gebeurtenisgegevens waartoe de afnemer gerechtigd is ze te ontvangen, worden doorgestuurd. Gedurende de looptijd van het abonnement kan de objectlijst worden onderhouden. De afnemer kan zelf objecten toevoegen aan of verwijderen van de objectlijst. Daarnaast bestaat de mogelijkheid om bij gebeurtenissoorten waarbij nieuwe objecten ontstaan (bijvoorbeeld 'geboorte persoon'), in het abonnement aan te geven dat in zo'n geval het betreffende object automatisch wordt toegevoegd aan de lijst. Ook het verwijderen van objecten is via deze constructie mogelijk. Projectscope In de definitiestudie GOB Abonnementenvoorziening [3] zijn de volgende onderdelen van de voorziening onderkend: • registratie van basisregistraties en afnemers; • registratie van een abonnement; • verwerking van de gebeurtenissen; • initiële leveringen4; • verstrekken van informatie. De scope van de fase 'Architectuur en Functioneel ontwerp' (en daarmee van de Project Start Architectuur) is5: • registratie van basisregistraties en afnemers; • registratie van een abonnement; • verwerking van de gebeurtenissen; • verstrekken van verwerkingsinformatie. Dat betekent dat het onderdeel 'initiële levering' buiten scope van het project valt en dat 'verstrekken van informatie' beperkt is tot het verstrekken van verwerkingsinformatie6. Het verstrekken en ontsluiten van managementinformatie7 is daarmee buiten de scope geplaatst. 4

Een initiële levering is het leveren van de gegevens van een object (bijvoorbeeld een persoon) als gevolg van de uitbreiding van de objectlijst een bestaand abonnement door de afnemer. De objectlijst is een lijst van objecten waarin de afnemer, in het kader van een abonnement) is geïnteresseerd (zie paragraaf 3.4.2 voor een beschrijving van de werking van een objectlijst). 5

De scope van het project is gebaseerd op de 'Must-haves' zoals die in de definitiestudie [3] zijn opgenomen. 6

Verwerkingsinformatie betreft de informatie voor de serviceorganisatie Digilevering over de werking van het informatiesysteem ten behoeve van het operationeel beheer (monitoring, oplossen problemen, etc.). 7

Managementinformatie betreft de informatie die door basisregistraties, afnemers of de serviceorganisatie Digilevering opgevraagd kan worden ten behoeve van hun bedrijfsvoering (sturing, procesoptimalisatie, etc.).


16/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Reden hiervoor is het beperken van de complexiteit van deze versie van Digilevering. De focus ligt op de verwerking van gebeurtenissen en de aanvullende functionaliteit die nodig is om dat te verwezenlijken. Initiële levering en het verstrekken van managementinformatie zijn daaraan aanvullend en zullen in een volgende versie worden geïmplementeerd. 2.4 Uitgangspunten In de definitiestudie GOB Abonnementenvoorziening [3] zijn uitgangspunten gedefinieerd. Deze zijn onverkort van toepassing op de, in deze architectuur, uitgewerkte voorziening. De belangrijkste uitgangspunten zijn: • De basisregistratie (en dus niet Digilevering) is verantwoordelijk voor de autorisatie van de afnemer; • Voordat een abonnement in Digilevering geregistreerd kan worden, moet er een contract tussen basisregistratie en afnemer zijn. In dit contract is formeel vastgelegd welke gegevens een afnemer geleverd mag krijgen in relatie tot de taken die worden uitgevoerd; • Uitwisseling tussen de verschillende organisaties (basisregistratie, afnemer en Digilevering) gaat op basis van elektronische berichten. Er is een betrouwbare levering van berichten (dit wordt gewaarborgd door toepassing van de OSB Koppelvlakstandaard ebMS). Daar waar Digilevering berichten verstuurt aan afnemers, is het vereist dat de afnemer hiervoor een (OSB Compliant) webservice implementeert; • De basisregistratie (en dus niet Digilevering) bepaalt de gebeurtenissoorten (bijvoorbeeld: life events, administratieve mutaties, etc.); • Digilevering levert berichten altijd direct (dat wil zeggen: zo spoedig mogelijk na ontvangst van het bericht) door aan de afnemer(s) die daar volgens hun abonnement recht op hebben. De berichten worden niet opgeslagen in Digilevering; • Gebeurtenissen die in de toekomst plaatsvinden, kunnen worden gemeld aan Digilevering8. . Gebeurtenissen die in de toekomst plaatsvinden worden door Digilevering hetzelfde behandeld als andere gebeurtenissen en derhalve direct na ontvangst doorgestuurd aan de afnemer. De afnemer moet hier in zijn informatievoorziening rekening mee houden. • Digilevering kent de relatie tussen gebeurtenissoorten van verschillende basisregistraties niet; • De basisregistratie bepaalt op basis van welke criteria (bijvoorbeeld: locatieaanduiding, branchecodering) afnemers kunnen selecteren welke gebeurtenissen van een bepaalde soort aan de afnemer worden geleverd (het zgn. gebeurtenisfilter); • Digilevering registreert (logt) veranderingen in de abonnementenspecificatie.

8

Voorbeeld van een gebeurtenis in de toekomst is: ‘onderneming start over 2 weken ’.


17/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

3

Bedrijfsarchitectuur

3.1 Digilevering Digilevering is een generieke voorziening, bestaande uit een geautomatiseerde voorziening en de daarbij behorende serviceorganisatie. Digilevering ondersteunt gebeurtenisgedreven verstrekkingen, waarbij de registratiehouder (of, indien van toepassing, de houder van de landelijke voorziening), via Digilevering gegevens over gebeurtenissen aan haar afnemers verstrekt. Dit kan als volgt schematisch worden gemodelleerd (waarbij de verstrekking van één gebeurtenis is weergegeven). Landelijke voorzieningen

Afnemers

Basisregistraties BAG

Digilevering

LV-BAG

Digilevering abonnementen

LV-WOZ

Levering ●

Generieke Voorzieningen ●Diensten ●Standaarden

BAG BAG

BAG

BRI NHR

Digimelding

NHR

Terugmelding LV-xx Starten onderneming xyz

Figuur 5: Digilevering en haar context Alvorens Digilevering de, door registratiehouders/houders landelijke voorziening aangeleverde gebeurtenissen, kan leveren aan afnemers, moeten de organisaties (registratiehouder/houder landelijke voorziening, afnemer) en hun onderlinge contractuele afspraken geregistreerd worden. Het abonnement (die de contractuele afspraken representeert in Digilevering) is de basis waarop Digilevering vaststelt welke afnemers welke gebeurtenissen geleverd krijgen. De registratiehouder/houder landelijke voorziening stuurt zijn gebeurtenissen9 in een bericht naar Digilevering. Digilevering bepaalt, op basis van de abonnementenregistratie, welke 9

Voorbeeld: Gebeurtenissoort is 'overlijden persoon'; gebeurtenis is 'overlijden van persoon X'.


18/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

afnemers geabonneerd zijn de betreffende gebeurtenissoort en stuurt deze gebeurtenis door naar de afnemers (de abonnementhouders). Daarnaast verstrekt Digilevering gegevens over de verwerking aan de beheerorganisatie (serviceorganisatie Digilevering). 3.2 Organisatie In keten van gebeurtenisgedreven verstrekkingen worden dus vier organisaties onderkend: • Registratiehouders; • Houders landelijke voorziening; • Afnemers; • Serviceorganisatie Digilevering. 3.2.1 Registratiehouders, houders landelijke voorziening en afnemers Registratiehouders, houders van landelijke voorziening en afnemers hebben taken en verantwoordelijkheden in de verstrekking van gebeurtenissen. Zij vormen de 'leveranciers' en 'klanten' van Digilevering. De rollen registratiehouder, houder landelijke voorziening en afnemer zijn als volgt te omschrijven: • Een registratiehouder is de bij wet aangewezen overheidsinstelling of groep van overheidsinstellingen, die houder en beheerder is van de basisregistratie. Een basisregistratie is een verzameling gegevens waarvan bij wet is bepaald dat deze een basisregistratie vormen. Voorbeeld: burgemeester en wethouders zijn registratiehouder van de basisregistratie adressen. • Een houder landelijke voorziening is een overheidsorganisatie die een landelijke voorziening beheert. Een landelijke voorziening is een voorziening waarin de gegevens uit één of meerdere basisregistraties zijn opgenomen, ten behoeve van het gebruik door afnemers. Voorbeeld: de dienst Kadaster is houder van de landelijke voorziening BAG. • Een afnemer is een publieke organisatie of private organisatie die voor het uitoefenen van een publieke taak gebruik maakt van gegevens uit een basisregistratie. Voorbeeld: het Ministerie van Justitie is afnemer van gegevens uit het Nieuw Handelsregister.

Digilevering communiceert met de houder landelijke voorziening (op organisatieniveau) en de landelijke voorziening (op systeemniveau). Hoewel formeel niet iedere basisregistratie een landelijke voorziening kent, is er de facto wel sprake van een voorziening die op landelijk niveau het gebruik van de basisregistratie verzorgt. In het vervolg spreken we


19/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

daarom van 'houder landelijke voorziening' en 'landelijke voorziening' om de organisatie respectievelijk het informatiesysteem aan te duiden waarmee Digilevering communiceert10. Op dit moment (oktober 2009) worden, bovenstaande interpretatie volgend, de volgende houders van landelijke voorzieningen onderscheiden: Houder landelijke voorziening

Basisregistratie(s)

Kadaster

BR Kadaster BR Topografie BR Adressen BR Gebouwen

BPR

BR GBA Persoonsgegevens, RNI

Belastingdienst

BR Inkomen

RDW

BR Voertuigen

KvK NL

Nieuw Handelsregister

Waarderingskamer

BR WOZ

3.2.2 Serviceorganisatie Digilevering Digilevering bestaat naast de geautomatiseerde (technische) systemen ook uit een serviceorganisatie (de Serviceorganisatie Digilevering) die nodig is om de systemen operationeel te houden en ondersteuning te bieden bij vragen of klachten vanuit de gebruikers (registratiehouders, houders landelijke voorziening en afnemers). Om deze taken te kunnen uitvoeren zijn twee organisatieonderdelen te onderkennen met elk hun eigen specifieke doelstelling: • een organisatieonderdeel dat verantwoordelijk is voor het afhandelen van vragen en klachten vanuit de gebruikers van de voorziening; • een organisatieonderdeel dat verantwoordelijk is om het operationele en tactische beheer uit te voeren, waaronder het functioneel beheer, technische beheer, applicatieontwikkeling, releasemanagement, etc. Dit beeld sluit aan bij de huidige indeling binnen de beoogde beheerpartij: Logius.

10

Zo kent bijvoorbeeld het NHR formeel geen landelijke voorziening, maar er is wel sprake van een voorziening voor het landelijk ontsluiten van de gegevens uit de basisregistratie en beschouwen we de NHR als landelijke voorziening en KvK NL als houder van deze landelijke voorziening.


20/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

3.2.3 Verantwoordelijkheden Het leveren van gegevens op basis van enkelvoudige, gebeurtenisgestuurde abonnementen gaat over alle hierboven onderkende organisaties heen. Dit vergt een goede afstemming en een duidelijke scheiding van verantwoordelijkheden tussen deze organisaties. Serviceorganisatie Digilevering De serviceorganisatie Digilevering is verantwoordelijk voor de (juiste en tijdige) distributie van de (gebeurtenis)berichten en voor de traceerbaarheid van deze (gebeurtenis)berichten. Dit betreft de verantwoordelijkheden met betrekking tot operationeel en/of tactisch beheer van de voorziening, zoals het functioneel beheer, technisch beheer, applicatieontwikkeling, releasemanagement, etc. Deze beheerrollen worden ingevuld door Logius en hun uitvoerende partners. Binnen Logius vervult het onderdeel Serviceorganisatie de eerstelijns ondersteuning voor zowel houders landelijke voorziening als afnemers. Aangezien één van de uitgangspunten is om de inhoudelijke kennis bij de serviceorganisatie Digilevering te beperken, betekent dit dat er (inhoudelijke) aanspreekpunten bij houders landelijke voorziening en afnemers moeten zijn waarmee afspraken over de kennislevering gemaakt worden. Daarnaast ondersteunen zij het aansluittraject voor nieuwe gebruikers. Registratiehouders, houders landelijke voorzieningen en afnemers Naast de serviceorganisatie Digilevering hebben ook registratiehouders, houders landelijke voorzieningen en afnemers hun taken en verantwoordelijkheden. De registratiehouders, houders landelijke voorzieningen en afnemers zijn geen organisaties waar Digilevering verantwoordelijk voor is, maar wel organisaties die een integraal onderdeel uitmaken van de keten waarbinnen Digilevering opereert. De registratiehouders en houders landelijke voorzieningen zijn (in juridische zin) verantwoordelijk voor de levering van gegevens aan afnemers. Daarnaast zijn de houders landelijke voorziening en afnemers verantwoordelijk voor de registratie en het beheer van de abonnementspecificaties. De houder landelijke voorziening is de partij die bepaalt op welke gebeurtenissoorten een abonnement genomen kan worden. De afnemer is de partij die zich op één of meer gebeurtenissoorten abonneert en de partij die de gebeurtenissen van Digilevering afneemt. Samenvattend zijn de (eind)verantwoordelijkheden als volgt belegd: Organisatie Registratiehouders en houders landelijke voorziening

(Eind)verantwoordelijk voor de volgende taken • •

Verstrekken van de gebeurtenis; Beheren gebeurtenissoorten (definities), inclusief


21/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Organisatie

(Eind)verantwoordelijk voor de volgende taken

•

gegevenselementen en filtermogelijkheden; Registreren (en onderhouden) abonnement (incl. filtering); Vrijgeven abonnement.

Afnemer

• •

Ontvangen van de gebeurtenis; Beheren van de objectlijst11.

Serviceorganisatie Digilevering

•

Operationeel en tactisch beheer van de voorziening (waaronder het verwerken/distribueren van de gebeurtenis en het verstrekken van verwerkingsinformatie); Ondersteunen van gebruik (waaronder het aansluitingenbeheer).

•

•

Het is denkbaar dat registratiehouders, houders landelijke voorziening of afnemers ervoor kiezen om bepaalde taken (bijvoorbeeld het beheren van gebeurtenissoorten of het beheren van de filtering of de objectlijst binnen een abonnement) te laten uitvoeren door één van de andere organisaties (mandateren). Hierbij mandateert de betreffende organisatie dan de andere organisatie om deze taken uit te voeren, maar de betreffende registratiehouder of afnemer blijft altijd eindverantwoordelijk voor de juiste uitvoering van deze taken. Digilevering voorziet in functionaliteit om taken te kunnen mandateren. 3.2.4 Relevante NORA-principes Digilevering gaat (daar waar van toepassing) uit van de architectuurprincipes en -richtlijnen zoals die in de NORA beschreven staan. Daarmee wordt gezorgd voor maximale interoperabiliteit op proces-, informatie-, juridisch en technisch niveau. Voor het onderdeel organisatie zijn de volgende principes van belang: Nr

Omschrijving

Toepassing in Digilevering

5.1.1

Overheidsorganisaties zijn

De relevante deelnemers (afnemers,

soevereine deelnemers binnen de e- registratiehouders, houders landelijke voorziening) overheid

hebben hun wettelijke taken en verantwoordelijkheden. De introductie van Digilevering verandert niets aan de verantwoordelijkheden, de houders landelijke

11

Met een objectlijst kan een afnemer de levering van gebeurtenissen binnen een abonnement inperken. Alleen

gebeurtenissen waarin een in de objectlijst opgenomen object (bv een persoon, gerepresenteerd door een BSN) voorkomt, worden geleverd. De werking van de objectlijst staat beschreven in paragraaf 3.4.2.


22/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Nr

Omschrijving

Toepassing in Digilevering voorziening zijn en blijven verantwoordelijk voor de verstrekking van gegevens aan afnemers.

5.1.1.1

De interne besturing van

De serviceorganisatie Digilevering wordt in haar

organisaties is gebaseerd op

bedrijfsvoering ondersteund door de verwerkings-

planning en controle met

en managementinformatie van Digilevering.

gebruikmaking van adequate prestatie-indicatoren. 5.1.2

De functies van

Van de registratiehouders, houders landelijke

overheidsorganisaties zijn

voorziening en de afnemers is het inzichtelijk welke

inzichtelijk.

functie zij vervullen. Digilevering levert (als organisatie) een service om gebeurtenisgegevens te distribueren naar geabonneerde afnemers. Deze functionaliteit wordt in deze projectstartarchitectuur inzichtelijk gemaakt.

5.1.3

5.1.4

Overheidsorganisaties werken

Digilevering opereert in een keten tussen (landelijke

binnen de e-overheid samen.

voorzieningen van) basisregistraties en afnemers.

De architectuur opbouw van

Alleen het tweede deel van dit principe (vanaf

overheidsorganisaties is gericht op

'evenals') is van toepassing (Digilevering levert

het verlenen van diensten aan

immers geen diensten aan burgers en bedrijven).

burgers en bedrijven via meerdere

Een (landelijke voorzieningen van een)

kanalen, evenals op onderlinge

basisregistratie levert eenmalig een gebeurtenis

samenwerking door het koppelen

aan Digilevering. Digilevering zorgt ervoor dat deze

van dienstverleningsprocessen en

gebeurtenis aan de geïnteresseerde afnemers (de

het gezamenlijk gebruiken van

abonnees) wordt gedistribueerd. Dit levert een

gegevens.

belangrijke bijdrage aan het gezamenlijk gebruiken van gegevens.

5.1.5

Overheidsorganisatie werken samen Digilevering biedt (geautomatiseerde) services aan aan diensten aan burgers en

de houders landelijke voorziening en afnemers voor

bedrijven op basis van een service

het distribueren van gebeurtenissen , alsmede het

geörienteerde architectuur.

registeren van de hiervoor benodigde gegevens.

3.3 Diensten, producten en services In de NORA wordt een onderscheid gemaakt tussen diensten en producten enerzijds en (business)services anderzijds. Hierbij worden diensten en producten aangeboden aan burgers en bedrijven, business services worden door/voor overheidsorganisaties onderling


23/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

aangeboden. Digilevering valt in deze (business services) categorie, aangezien er geen (directe) diensten worden geleverd aan burgers en bedrijven. 3.3.1 Relevante NORA-principes Voor het onderdeel diensten, producten en services zijn de volgende NORA-principes relevant: Nr

Omschrijving


5.2.1.7

Diensten12 kunnen ook in combinatie Combinatiediensten zijn niet aan de orde. Op het geleverd worden:

moment dat samengestelde abonnementen worden

combinatiediensten

ondersteund is sprake van een combinatiedienst en moeten afspraken worden gemaakt tussen de leverende partijen.

5.2.1.8

Dienstverlening gaat over

Deze versie van Digilevering faciliteert de distributie

organisatiegrenzen heen

van gebeurtenisberichten. Elk gebeurtenisbericht naar een afnemer is afkomstig van één landelijke voorziening. In die zin is geen sprake van dienstverlening die over organisatiegrenzen heen gaat.

5.2.1.17

Diensten die centraal worden

De diensten van Digilevering worden vastgelegd in

aangeboden vragen een

en ontsloten door het OSB Serviceregister.

overheidsbreed coördinatiemechanisme 5.2.1.18

5.2.2.1

Dienstverleningskanalen zijn

Met de komst van Digilevering krijgen afnemers één

ingericht vanuit het perspectief van

loket beschikbaar voor levering van gegevens van

de klant

basisregistraties op basis van abonnementen.

Diensten en services kunnen

Alle functionaliteit van Digilevering wordt

worden samengesteld door middel

beschikbaar gesteld in de vorm van services

van andere services.

(waarvan een aantal geïmplementeerd wordt in de vorm van webservices). Daarnaast zal Digilevering gebruik maken van een aantal 'interne' services. Er is geen sprake van samengestelde services.

5.2.2.2

Het centraal aanbieden van services De services (business services en webservices) wordt gecoördineerd door een

van Digilevering worden geregistreerd in het OSB

overheidsbreed

Serviceregister.

12

Strikt genomen levert Digilevering geen diensten zoals in NORA bedoeld (die worden geleverd aan burgers en

bedrijven), de principes met betrekking tot diensten, zijn ruim geïnterpreteerd en toegepast (voor zover relevant) op de services die worden geleverd aan afnemers en houders landelijke voorziening.


24/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Nr

Omschrijving


coördinatiemechanisme. 5.2.2.3

Overheidsorganisaties maken

De realisatie van Digilevering wordt (inhoudelijk)

afspraken over het verlenen van

begeleid en geaccordeerd door de Strategisch

services.

Stelselberaad, Gebruikersoverleg Stelsel, een begeleidingsgroep en werkgroepen. Daarmee zijn indirect de afspraken over het verlenen van services vastgesteld.

5.2.2.4

De eisen die worden gesteld aan

Alle stappen binnen en mutaties van gegevens in

diensten, zoals kwaliteit, telbaarheid Digilevering worden geregistreerd ten behoeve van en kostprijs, worden ook gesteld aan traceerbaarheid, het voldoen aan de nietservices.

functionele eisen, verwerkings- en (in de toekomst) managementinformatie, kostenberekening, etc. Daarmee is het mogelijk om te toetsen of aan het serviceniveau (vastgelegd in SLA's) wordt voldaan.

3.3.2 Services Een business service is het geheel aan processen dat zich afspeelt tussen de vraag naar een dienst, product of service en het leveren daarvan. Digilevering levert de volgende business services aan houders landelijke voorziening, afnemers en de serviceorganisatie Digilevering: • Beheren gebeurtenissoort: met deze business service kan de houder landelijke voorziening beheren welke gebeurtenissoort(en) hij aan afnemers wil kunnen aanbieden in abonnementsvorm. Daarnaast kunnen de gegevenselementen van een gebeurtenissoort worden vastgelegd en kan worden aangeven op welke manier filtering op deze gegevenselementen mogelijk is; • Beheren abonnement: met deze business service kan de afnemer (of de houder landelijke voorziening of de serviceorganisatie Digilevering) beheren van welke gebeurtenissoort(en) hij gebeurtenissen wilt ontvangen. Daarnaast kan een objectlijst en/of gebeurtenisfilter gedefinieerd worden om de levering van gebeurtenissen binnen een abonnement in te perken. Tevens kan worden geregistreerd welke gegevenselementen (bijvoorbeeld op basis van autorisatieafspraken) van een gebeurtenis geleverd gaan worden. De houder landelijke voorziening geeft, tot slot, het abonnement vrij; • Beheren objectlijst: met deze business service kan de afnemer de objectlijst beheren door objectidentificaties aan de lijst toe te voegen of van de lijst te verwijderen; • Verstrekken gebeurtenis: deze business service stelt de houder landelijke voorziening in staat gebeurtenissen aan Digilevering te verstrekken (met het doel


25/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

• • •

dat deze gebeurtenissen vervolgens aan alle afnemers worden gedistribueerd, die er volgens de abonnementspecificaties recht op hebben); Ontvangen gebeurtenis: deze business service stelt afnemers in staat gebeurtenissen te ontvangen; Verstrekken verwerkingsinformatie: deze business service verstrekt informatie omtrent de (ver)werking van Digilevering aan de serviceorganisatie Digilevering; Ondersteunen gebruik: deze business service stelt houders landelijke voorziening en afnemers in staat vragen en klachten over het gebruik van Digilevering bij de serviceorganisatie Digilevering in te dienen.

Onderstaande figuur geeft een overzicht van aan welke organisaties, welke van de onderkende business services moeten kunnen worden geleverd, ervan uitgaande dat een aantal taken (kunnen) worden gemandateerd. De 'te mandateren' business services zijn geplaatst in de overlappende gebieden.

SERVICEORGANISATIE DIGILEVERING Verstrekken verwerkingsinformatie

Beheren gebeurtenissoort

Beheren objectlijst

Beheren abonnement

A F N E M E R

Ondersteunen gebruik

Ontvangen gebeurtenis

Figuur 6: Overzicht van de onderkende business services

Verstrekken gebeurtenis

R E G I S T R A T I E

H O U D E R


26/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

3.4 Processen Een proces bestaat uit een serie processtappen die begint naar aanleiding van een concrete aanleiding bij de registratiehouder, de afnemer of serviceorganisatie Digilevering en eindigt met een concreet resultaat voor de registratiehouder, de afnemer of de serviceorganisatie Digilevering. Digilevering maakt onderscheid tussen primaire processen (draagt bij aan de doelstelling) en ondersteunende (of secundaire) processen (ondersteunt het primaire proces). 3.4.1 Relevante NORA-principes Voor het onderdeel processen zijn de volgende NORA-principes relevant: Nr

Omschrijving

5.3.1

Services triggeren elkaar en kunnen Binnen de keten houder Landelijke Voorzieninghierdoor processen verbinden.


Digilevering-Afnemer worden processen verbonden door middel van services.

5.3.2

De procesarchitectuur is bij voorkeur Decompositie wordt gehanteerd. gebaseerd op de decompositie ketenproces, bedrijfsproces, werkproces, processtap of handeling.

5.3.3

De besturing van ketenprocessen

De houder landelijke voorziening is verantwoordelijk

dient door de betrokken organisaties voor de levering van gebeurtenisgegevens en eenduidig geregeld te worden.

daarmee voor de sturing van het ketenproces. Digilevering garandeert (binnen de keten) de levering van door houders landelijke voorziening gestuurde gebeurtenisberichten aan de juiste afnemers. Houder landelijke voorziening en Digilevering maken hierover afspraken.

5.3.4

Klanten hebben de mogelijkheid zich Klanten van Digilevering (houders landelijke op de hoogte te stellen van de stand voorziening en afnemers) kunnen in deze versie van zaken van de uitvoering van de

van Digilevering niet rechtstreeks voortgang in de

dienstverlening.

uitvoering van de dienstverlening bekijken13. De serviceorganisatie Digilevering kan dit wel en kan hiermee vragen van klanten beantwoorden.

5.3.5

13

Een administratief proces is

Het proces 'verwerken gebeurtenis' binnen

opgesplitst in een invoer-,

Digilevering voldoet aan dit principe. Invoer gebeurt

Dit is een afbakeningskeuze. Inzicht in de afhandeling (gebeurtenisverwerking) is naar verwachting alleen

nodig in geval van calamiteiten.


27/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Nr

Omschrijving


verwerkingen uitvoerproces.

door een houder landelijke voorziening die een gebeurtenisbericht aanbiedt aan Digilevering. Vervolgens wordt zo'n bericht verwerkt (bepalen welke afnemers het bericht mogen ontvangen), waarna gebeurtenisberichten worden aangeboden (uitvoer) aan één of meerdere afnemers.

5.3.6

Informatie wordt éénmalig

Digilevering ondersteunt de distributie van

uitgevraagd

gebeurtenisberichten. Dat levert een bijdrage aan eenmalige uitvraag en meervoudig gebruik (alle geabonneerde afnemers zijn op de hoogte van relevante gebeurtenissen).

5.3.7

Processen dienen te worden

Door Digilevering neemt de uniformiteit en

beschreven op basis van algemeen

standaardisatie van processen, services,

geaccepteerde en open

handleidingen, etc. over basisregistraties en

standaarden.

afnemers heen, toe. Het proces van Digilevering zelf wordt in deze versie van de PSA beschreven door middel van procesflowdiagrammen. In een latere versie zal een open standaard (BPMN) worden gebruikt

5.3.8

Processen die geautomatiseerd

De geautomatiseerde processen zijn in deze versie

worden uitgevoerd, dienen

van de PSA nog niet beschreven met behulp van

beschreven te worden met behulp

een algemeen erkende standaard. In een volgende

van een algemeen erkende (open)

versie zal BPMN worden gehanteerd.

standaard. 5.3.9

Processen worden zodanig

Alle stappen binnen en mutaties van gegevens in

ontworpen dat procesgegevens

Digilevering worden geregistreerd ten behoeve van

systematisch kunnen worden

traceerbaarheid, het voldoen aan de niet-

vastgelegd.

functionele eisen, managementinformatie, kostenberekening, etc.

5.3.10

Maak bij het kiezen van

Bij Digilevering is de kwaliteit van de

overdrachtsmomenten in processen

dienstverlening (het betrouwbaar afleveren van

een expliciete afweging tussen

gebeurtenissen bij de juiste abonnees) belangrijker

doorlooptijd en kwaliteit van het

dan de doorlooptijd van een gebeurtenis binnen

proces.

Digilevering (het is niet erg als de afnemers de gebeurtenissen een paar minuten na aanlevering van de gebeurtenis door de basisregistratie, ontvangen).


28/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Nr

Omschrijving


5.3.12

Ketenprocessen kunnen ontworpen

Het interactieperspectief is toegepast door de

worden door middel van het

koppelvlakken (bedrijfsservices, webservices)

interactieperspectief14.

expliciet te onderkennen en beschrijven én de benodigde webservices bij houder landelijke voorziening en afnemer te benoemen. Zo ontstaat zicht op de keten, zonder dat inzicht in de interne werking van Digilevering nodig is.

3.4.2 Beschrijving primaire processen Om de onderkende business services te kunnen leveren aan houders landelijke voorziening, afnemers en de serviceorganisatie Digilevering, voert Digilevering de volgende primaire processen uit: • beheren basisregistratie-info • beheren gebeurtenissoort • beheren afnemers-info • beheren abonnement • beheren objectlijst • verwerken gebeurtenis. Deze primaire processen worden ondersteund door de volgende secundaire (of ondersteunende) processen: • uitvoeren servicemanagement • uitvoeren operationeel en tactisch beheer.

14

Om te kunnen borgen dat de keten als geheel goed functioneert, is het aan te raden om hiervan vooraf een ontwerp te maken. Hierbij kan het interactieperspectief goede diensten bewijzen.


29/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Verstrekken Verwerkingsinfo Verstrekken Verwerkingsinfo

Uitvoeren operationeel en tactisch beheer

16. Uitvoeren servicemanagement

15. Verstrekken verwerkingsinfo

17. Uitvoeren Oper. en tact. beheer

Beheren Abonnement

6. Selecteren gebeurtenissoort

7. Definiëren objectlijst

8. Beheren selectie op gegevenselement

2. Beheren gebeurtenissoort

3. Beheren gegevenselementen

9. Beheren gebeurtenisfilter

4. Beheren criteria filtering

10. Check op contract en vrijgeven

Beheren objectlijst

Beheren Objectlijst

Beheren Afnemer-info

Beheren Basisregistratie-info

11. Beheren objectlijst

5. Beheren afnemer-info

1. Beheren basisregistratieinfo


Verwerken Gebeurtenis 14. Versturen bericht

13. Bepalen afnemer(s)

12. Ontvangen bericht

Beheren Gebeurtenissoort


Beheren Abonnement



Uitvoeren Servicemanagement

Figuur 7: Business services, primaire en ondersteunende processen Digilevering Beheren basisregistratie-info Het beheren van informatie over basisregistraties vindt plaats in binnen één processtap: 1. Beheren basisregistratie-info: Alvorens de landelijke voorziening gebeurtenissen aan Digilevering kan leveren, moet de basisregistratie (en de landelijke voorziening) bekend/geregistreerd zijn binnen Digilevering. Het gaat hierbij om de registratie van administratieve gegevens als identificatie houder landelijke voorziening (OIN), naam landelijke voorziening, adresgegevens, contactgegevens, naam basisregistratie, etc. In deze processtap wordt de informatie over de landelijke voorziening/basisregistratie geregistreerd en beheerd in Digilevering. Beheren gebeurtenissoort Het beheren van de gebeurtenissoorten waar afnemers abonnementen op kunnen nemen, vindt plaats binnen een aantal processtappen.


30/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

2. Beheren gebeurtenissoort: De houder landelijke voorziening bepaalt de verschillende gebeurtenissoorten waarop afnemers zich kunnen abonneren. In deze processtap worden de gebeurtenissoorten geregistreerd en beheerd in Digilevering. 3. Beheren gegevenselementen: In deze processtap legt de houder landelijke voorziening van een gebeurtenissoort vast uit welke (groepen van) gegevenselementen deze bestaat. Daarmee wordt gedefinieerd welke gegevens (maximaal) met een gebeurtenis worden geleverd. Dit vormt de basis voor het vaststellen van de filtermogelijkheden die aan afnemers wordt geboden (zie processtap 4). 4. Beheren criteria filtering: In deze processtap definieert de houder landelijke voorziening de mogelijkheden van filtering die beschikbaar is voor afnemers. Daarbij kan er voor worden gekozen om op alle gegevenselementen filtering toe te staan of de mogelijkheden daarin te beperken tot één of enkele gegevenselementen. Beheren afnemers-info Het beheren van informatie over afnemers vindt plaats in binnen één processtap. 5. Beheren afnemers-info: Alvorens de afnemer gebeurtenissen van Digilevering kan ontvangen, moet de afnemer bekend/geregistreerd zijn binnen Digilevering. Het gaat hierbij zowel om de registratie van administratieve gegevens als om de (technische) adresgegevens, contactgegevens, etc. In deze processtap wordt de informatie over de afnemer geregistreerd en beheerd in Digilevering. Beheren abonnement Een abonnement is een inschrijving, op basis van een tussen afnemer en registratiehouder afgesloten contract (gebaseerd op doelbinding), voor de geregelde levering van gebeurtenissen van één of meerdere gebeurtenissoorten. Afnemers en houders landelijke voorziening kunnen, na initiële vastlegging van het abonnement, het abonnement beheren door objecten toe te voegen of te verwijderen en de gebeurtenisfilter(s) aan te passen. Dit alles binnen de grenzen van het afgesloten contract. Daarnaast heeft de afnemer de mogelijkheid om de te leveren gebeurtenissen verder in te perken. Hiervoor kan de afnemer vastleggen: • in welke specifieke objecten (bijvoorbeeld: natuurlijke personen, verblijfsobjecten, etc.) hij geïnteresseerd is; • welke filters hij over de gebeurtenissen wil leggen (bijvoorbeeld: 'alle gemeenten binnen de provincie Utrecht'); • een combinatie van deze mogelijkheden. Het proces 'beheren van abonnementen' is onderverdeeld in een aantal processtappen. 6. Selecteren gebeurtenissoort: In deze processtap worden de gebeurtenissoorten geselecteerd (en beheerd) waarin de afnemer geïnteresseerd is, en toegevoegd aan


31/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

een abonnement. Dit kunnen alleen gebeurtenissoorten zijn die door de houder landelijke voorziening geregistreerd zijn (zie processtap 2). 7. Definiëren objectlijst: Veelal zal een afnemer geïnteresseerd zijn in gebeurtenissen voor zover ze betrekking hebben op de verzameling objecten die in zijn context relevant is. Voorbeelden zijn: een verzameling natuurlijke personen (gespecificeerd door een lijst met BSN's), een verzameling voertuigen, een verzameling verblijfsobjecten, etc. Een objectlijst wordt gedefinieerd per abonnement. Een abonnement wordt afgesloten voor een bepaalde taak van de afnemer. In de meeste gevallen zal er sprake zijn van een populatie objecten die voor de betreffende taak van belang zijn. Mochten verschillende populaties relevant zijn, dan kunnen daarvoor verschillende abonnementen, elk met hun eigen objectlijst, voor worden gebruikt. In deze processtap wordt vastgelegd: • of een objectlijst bij het abonnement van toepassing is en • (indien van toepassing) van welke objecttypen er objecten in de objectlijst opgenomen kunnen worden en • de (soort) identificatie van het objecttype (bv BSN, kenteken). Het daadwerkelijk 'vullen' van de objectlijst gebeurt in processtap 11. 8. Beheren selectie op gegevenselement: In deze processtap wordt per (groepering van) gegevenselement(en) aangegeven of de afnemer deze (groepering van) gegevenselement(en) wil of mag ontvangen. Daarmee wordt vastgelegd welke gegevens van een gebeurtenis bij uitoefening van het abonnement worden geleverd. Dit kan zijn op basis van een autorisatiebesluit (bepaalde gegevenselementen worden dan niet geleverd omdat dit niet is toegestaan door de houder landelijke voorziening) of op basis van een keuze van de afnemer (bepaalde gegevenselementen worden dan niet geleverd omdat de afnemer dit zelf niet wil). In de eerste release van Digilevering (met NHR en BAG) zullen er vanuit de landelijke voorziening waarschijnlijk geen beperkingen worden opgelegd in de te verstrekken gegevens. In dat geval kan de landelijke voorziening de afnemer mandateren om zelf de gegevenselementen te selecteren die ze wil ontvangen15. 9. Beheren gebeurtenisfilter: Daarnaast is het binnen een abonnement mogelijk dat een afnemer aangeeft niet alle gebeurtenissen van een gebeurtenissoort te willen ontvangen, maar slechts een deelverzameling daarvan. Bijvoorbeeld: alleen de gebeurtenissen van gebeurtenissoort 'starten onderneming' binnen de provincie Utrecht in plaats van alle gebeurtenissen van de betreffende soort. Een dergelijke inperking op de levering van gebeurtenissen is een gebeurtenisfilter. Een gebeurtenisfilter kan voor elke soort gebeurtenis binnen een abonnement worden gespecificeerd. De houder landelijke voorziening bepaalt op basis van welke criteria kan worden gefilterd (zie processtap 4). De afnemer beheert in deze processtap de 15

In een toekomstige release, waarbij basisregistraties met niet-openbare gegevens aansluiten, wordt expliciet

onderscheid tussen beperking vanuit autorisatie en beperking vanuit gebruikerswensen belangrijk. Voorwaarde daarvoor is dat autorisatie op stelselniveau verder is ontwikkeld.


32/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

waarden voor deze criteria. De restrictie hierbij is dat een gebeurtenisfilter alleen geplaatst kan worden op de gegevenselementen die geselecteerd zijn in de voorgaande processtap. Bijvoorbeeld: als een afnemer het gegevenselement 'nationaliteit' niet mag ontvangen, mag de afnemer niet filteren op 'nationaliteit'. 10. Check op contract en vrijgeven: In deze processtap wordt (onder verantwoordelijkheid van de houder landelijke voorziening) het geregistreerde of gemuteerde abonnement gecontroleerd op de afspraken in het contract tussen houder landelijke voorziening en afnemer. Het complete abonnement wordt daarbij bekeken: zijn de geselecteerde gebeurtenissoorten akkoord? Is de filtering akkoord? Is de selectie op gegevenselementen akkoord? Na vaststelling dat de abonnementspecificatie overeenstemt met het contract, wordt het abonnement vrijgegeven door de registratiehouder. Het abonnement is vanaf dat moment 'operationeel', gebeurtenissen kunnen daadwerkelijk worden geleverd. Beheren objectlijst Indien in een abonnement wordt gewerkt met een objectlijst (gedefinieerd in processtap 7), dan zal deze lijst aan verandering onderhevig zijn. In het proces 'beheren objectlijst' kan de lijst met objectidentificaties worden onderhouden. Dit proces bestaat uit één processtap. 11. Beheren objectlijst: het toevoegen of verwijderen van objectidentificaties. De objectlijst kan op deze manier actueel gehouden worden met de verzameling objecten waarin een afnemer geïnteresseerd is. De objectlijst kan op twee manieren worden onderhouden: • de afnemer voegt zelf objectidentificaties toe of verwijdert ze óf • een objectidentificatie wordt toegevoegd of verwijderd naar aanleiding van het verwerken van een gebeurtenis (bijvoorbeeld: indien een gebeurtenis 'geboorte' volgens het abonnement wordt verstrekt, wordt de daarin genoemde objectidentificatie toegevoegd aan de objectlijst). Verwerken gebeurtenis Digilevering verzorgt de distributie van gebeurtenissen, die aangeleverd zijn door de basisregistraties, naar de geabonneerde afnemers. Dit gebeurt in het proces: 'verwerken gebeurtenis'. Dit proces is onderverdeeld in de volgende processtappen: 12. Ontvangen bericht: Indien bij een landelijke voorziening een gebeurtenis (gebaseerd op een 'life event', administratieve gebeurtenis, etc.) optreedt, stuurt deze een


33/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

bericht (met daarin de gegevens betreffende de gebeurtenis) naar Digilevering. Na ontvangst van het bericht verwerkt Digilevering het bericht meteen16. 13. Bepalen afnemer(s): Per ontvangen bericht bepaalt Digilevering, op basis van de abonnementenregistratie, welke afnemers op de betreffende gebeurtenis geabonneerd zijn. Dit wordt als volgt (voor één abonnement) afgeleid: • bepaal of de gebeurtenissoort is opgenomen in het abonnement; • bepaal, indien van toepassing, of de gebeurtenis voldoet aan de in het gebeurtenisfilter opgenomen criteria; • bepaal, indien van toepassing, of de aan de gebeurtenis gerelateerde objecten voorkomen in de objectlijst van het abonnement. Indien aan alle drie de criteria is voldaan, dan is vastgesteld dat de gebeurtenis volgens de abonnementspecificatie mag worden verstuurd aan de afnemer. Met behulp van de geregistreerde afnemers-info wordt een bericht per afnemer samengesteld. Bij het samenstellen van het bericht worden de gegevenselementen waar de afnemer geen recht op heeft of die hij niet wenst te ontvangen (zie processtap 9) leeg gelaten. Dit kan leiden tot berichten met uitsluitend lege gegevenselementen. Deze berichten worden ook verstuurd aan de betreffende afnemer. 14. Versturen bericht: Vervolgens stuurt Digilevering het bericht, met de betreffende gebeurtenis, (meteen) door aan de betreffende afnemers. De afnemer ontvangt de gebeurtenis en gebruikt de gebeurtenis in zijn bedrijfsvoering. Verstrekken verwerkingsinformatie Van alle be- en verwerkingen binnen bovengenoemde processtappen wordt informatie vastgelegd in Digilevering. Deze verwerkingsinformatie moet door Digilevering aan de houders landelijke voorziening, hun afnemers en/of de serviceorganisatie Digilevering ontsloten kunnen worden. Dit proces bevat de volgende processtap: 15. Verstrekken verwerkingsinformatie: Binnen deze processtap wordt verwerkingsinformatie (bijvoorbeeld: doorlooptijden, fouten, etc.) verzameld en, desgevraagd, aan de betreffende houders landelijke voorziening, afnemers en/of serviceorganisatie Digilevering ontsloten. 3.4.3 Ondersteunende (of secundaire) processen Naast de primaire processen zijn de volgende ondersteunende processen onderkend: 16. Uitvoeren van servicemanagement: In dit proces worden vragen, klachten, etc. van gebruikers van Digilevering (houders landelijke voorziening en afnemers) afgehandeld; 16

Dit is bedoeld in functionele zin: er is geen functionele reden om gebeurtenissen niet direct door te sturen. Uiteraard kan om technische redenen buffering nodig zijn.


34/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

17. Uitvoeren van operationeel en tactisch beheer: In dit proces wordt het operationele en tactische beheer (waaronder het functioneel beheer, technisch beheer, applicatieontwikkeling, releasemanagement, etc.) uitgevoerd voor Digilevering. De ondersteunende processen worden uitgevoerd door de serviceorganisatie Digilevering. De serviceorganisatie Digilevering zal ingevuld worden door Logius. De beheerprocessen van Logius zijn beschreven aan de hand van het BiSL-beheerraamwerk voor Functioneel beheer en vastgelegd in het document 'Beschrijvingen van de beheer processen van GBO.Overheid' (versie 1.0, 25 april 2008) [4]. Voor de ondersteunende processen van Digilevering wordt dan ook m.n. naar de volgende hoofdstukken in voornoemd document verwezen: Ondersteunend proces

Hoofdstuk

Uitvoeren van servicemanagement

8. Afhandelen vragen en klachten

Uitvoeren van operationeel en tactisch beheer 1. Gebruiksbeheer 2. Verbindende processen 3. Verbindende processen: Sub-processen 4. Functionaliteitenbeheer 5. Functionaliteitenbeheer: Sub-processen


35/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

4

Informatie-architectuur

De informatie-architectuur beschrijft de functionele inrichting van de (geautomatiseerde) informatievoorziening, waarmee de in het vorige hoofdstuk beschreven business services en processen worden ondersteund dan wel volledig geautomatiseerd worden uitgevoerd. De informatievoorziening wordt beschreven aan de hand van drie aspecten (conform de indeling van NORA): • Mensen en applicaties: geeft zicht op de wijze waarop (delen van) de geautomatiseerde voorziening wordt ingezet (waar vindt interactie met mensen plaats; wat wordt volledig geautomatiseerd uitgevoerd); • Berichten en gegevens: beschrijft de onderliggende gegevenshuishouding (objecten, gegevens) en een functionele beschrijving van de berichtuitwisseling tussen Digilevering en de omgeving; • Informatie-uitwisseling: beschrijft de afspraken over structuur en de vorm van berichten. Aan de beschrijving van de drie aspecten ligt een aantal ontwerpbeslissingen ten grondslag. Deze staan beschreven in paragraaf 4.1. Ze vormen een verdere verdieping op de werking van en de ontwerpprincipes achter Digilevering. 4.1 Ontwerpbeslissingen In hoofdstuk 3 zijn de (business)services en processen van Digilevering beschreven. Om te komen tot de inrichting van de (geautomatiseerde) voorziening, is een aantal ontwerpbeslissingen genomen. Deze beslissingen zijn in deze paragraaf beschreven en, daar waar zinvol, aangevuld met voorbeelden. De ontwerpbeslissingen vormen de basis voor de functionele inrichting van Digilevering. 1.

Een afnemer kan meerdere abonnementen afsluiten die betrekking hebben op één basisregistratie Toelichting: een afnemer heeft doorgaans verschillende taken. Per taak is er een bepaalde behoefte aan gegevens uit een basisregistratie. Digilevering is zodanig ingericht dat een afnemer meerdere abonnementen kan afsluiten die betrekking hebben op één basisregistratie. Het is aan afnemers en houders van landelijke voorzieningen om in onderling overleg de afbakening van abonnementen vast te stellen.


36/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

2.

Een gebeurtenissoort kan opgenomen zijn in meerdere abonnementen van één afnemer Toelichting: indien een afnemer meerdere abonnementen heeft afgesloten die betrekking hebben op één basisregistratie, dan is het toegestaan dat een gebeurtenissoort is opgenomen in meerdere abonnementen. Daarmee is het voor afnemers mogelijk om per abonnement een andere filtering op de betreffende gebeurtenissoort toe te passen, die aansluit op de taak c.q. het proces waarvoor het abonnement is afgesloten. Denk bijvoorbeeld aan een filtering op regio, waarbij elke regio een eigen abonnement afsluit.

3.

Eén abonnement is één aansluiting Toelichting: Alle gebeurtenissen die in het kader van één abonnement worden verstuurd aan een afnemer, worden op één (fysiek) adres bezorgd. Een abonnement vormt de afbakening van een aansluiting op Digilevering. Het is wel mogelijk om in meerdere abonnementen hetzelfde afleveradres te gebruiken. In het gebeurtenisbericht wordt aangegeven bij welk abonnement het hoort.

4.

Er vindt geen ontdubbeling van leveringen van gebeurtenissen plaats over abonnementen heen. Toelichting: indien een gebeurtenissoort is opgenomen in meerdere abonnementen van één afnemer, dan kan het voorkomen dat een bepaalde gebeurtenis op grond van verschillende abonnementen geleverd wordt. Digilevering levert de gebeurtenis dan per abonnement, en ontdubbelt de levering niet.

5.

In (een bericht over) een gebeurtenis kunnen identificerende gegevens van objecten van verschillende objecttypen voorkomen. Toelichting: een gebeurtenis is gerelateerd aan één of meerdere objecten. Van elk aan de gebeurtenis gerelateerd object, wordt de identificerende eigenschap opgenomen. Eén gebeurtenis kan betrekking hebben op objecten van verschillende objecttypen. Voorbeeld: de gebeurtenis(soort) 'starten onderneming' heeft betrekking op drie objecttypen: persoon (met als identificerend gegeven een BSN), onderneming/maatschappelijke activiteit (met als identificerend gegeven een KvKnummer) en een vestiging (met als identificerend gegeven een vestigingsnummer).


37/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

6.

De objectlijst, die wordt gebruikt voor het filteren, kan identificerende gegevens van objecten van verschillende objecttypen bevatten. Toelichting: in een (bericht over) een gebeurtenis kunnen identificerende gegevens van objecten van meerdere objecttypen voorkomen (zie ontwerpbeslissing 5). Op al deze identificerende gegevens kan worden gefilterd door middel van de objectlijst. De objectlijst kan dus identificerende gegevens bevatten van objecten van verschillende objecttypen. Dit is beperkt tot de objecttypen die gerelateerd zijn aan de gebeurtenissoort(en) van het abonnement. Voorbeeld: Bij het hernoemen van een openbare ruimte neemt de BAG in de gebeurtenis (mutatie openbare ruimte) naast de identificatie van de openbare ruimte, ook de identificaties van alle aan de openbare ruimte gerelateerde adresseerbare objecten (verblijfsobjecten, ligplaatsen). In de objectlijst kunnen in dit geval dus identificaties voorkomen van zowel openbare ruimten als adresseerbare objecten. Filtering vindt plaats op de identificaties van beide soorten objecten.

7.

Bij het filteren van een gebeurtenis op basis van objectidentificaties is één match tussen de objectlijst en de objectidentificaties behorende bij een gebeurtenis, voldoende voor het versturen van de gebeurtenis. Toelichting: In (een bericht over) een gebeurtenis kunnen identificerende gegevens van objecten van verschillende objecttypen voorkomen (ontwerpbeslissing 5). De objectlijst, die wordt gebruikt voor het filteren, kan identificerende gegevens van objecten van verschillende objecttypen bevatten (ontwerpbeslissing 6). Dit leidt tot een situatie waarin de objectidentificaties die bij een gebeurtenis zijn opgenomen nul, één of meer keer matchen met de objectidentificaties uit de bij het abonnement behorende objectlijst. Bij het filteren is één match voldoende om de gebeurtenis te versturen. Voorbeeld: een afnemer is geabonneerd op de gebeurtenissoort 'hernoemen openbare ruimte'. Bij de gebeurtenis wordt niet alleen de identificerende gegevens van de openbare ruimte gestuurd, maar ook object-identificaties van gerelateerde adresseerbare objecten. In de objectlijst heeft de afnemer de identificaties '11111001', '11111002', '11111003', '11111012' en '11111013' opgenomen. Indien in de gebeurtenis minimaal één van deze identificaties voorkomt, wordt de gebeurtenis aan de betreffende afnemer gestuurd.


38/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

8.

Digilevering filtert alleen aan de hand van door een landelijke voorziening aangeleverde gebeurtenisgegevens. Digilevering hoeft hiervoor geen gegevens af te leiden of vertaalslagen uit te voeren. Toelichting: filtering (op basis van object-identificaties of op basis van gegevens van een gebeurtenis) vindt alleen plaats op basis van wat een landelijke voorziening aan gegevens levert. Digilevering hoeft dus geen bewerking uit te voeren voordat kan worden gefilterd. Staat een houder landelijke voorziening bijvoorbeeld filtering op 'provincie' toe, dan is de landelijke voorziening ook verplicht de provincie(code) bij elke gebeurtenis aan te leveren. Digilevering gaat dit niet afleiden uit andere gegevens17.

9.

In een gebeurtenisfilter kunnen alleen gegevenselementen worden opgenomen die volgens het abonnement ook geleverd mogen worden. In een abonnement is, per gebeurtenissoort, aangegeven welke gegevenselementen geleverd mogen worden (zie processtap 9). Alleen deze gegevenselementen mogen worden gebruikt in een gebeurtenisfilter. Dit om te voorkomen dat door middel van filtering informatie wordt ontvangen waartoe de afnemer niet gerechtigd is. Bijvoorbeeld: als de afnemer niet gerechtigd is de nationaliteit van een persoon te ontvangen, maar daarop wel kan filteren, kan indirect de nationaliteit worden vastgesteld. Deze constructie wordt uitgesloten.

10.

Het gegevenselement dat bij een gebeurtenissoort de identificatie van een object representeert, is uitgesloten voor gebruik als gegevenselement in een gegevenselementfilter. Toelichting: filtering kan op twee manieren plaatsvinden: (1) op basis van objectidentificaties (een lijst met objectidentificaties, geldend voor het hele abonnement) en (2) op basis van gegevenselementen van een gebeurtenis (vastgesteld per gebeurtenissoort van een abonnement). Elk, bij een gebeurtenis meegestuurd, gegevenselement wordt exclusief voor één van deze twee filtermechanismen gebruikt. Door de houder landelijke voorziening wordt per gegevenselement van een gebeurtenissoort vastgesteld: (1) of hierop filtering mogelijk is en (2) welk filtermechanisme van toepassing is.

17

In een volgende versie van Digilevering is het denkbaar dat dergelijke afleidingen wel worden geïmplementeerd. Bijvoorbeeld door een service aan te roepen die een postcode omzet in een provinciecode. Voor de eerste versie van Digilevering wordt geen gebruik gemaakt van deze mogelijkheid en is de ontwerpbeslissing onverkort van toepassing.


39/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

11.

Digilevering gaat uit van gebeurtenissen die in de Stelselcatalogus zijn gedefinieerd. Toelichting: in de Stelselcatalogus worden twee soorten concepten onderscheiden met betrekking tot gebeurtenissen: levensgebeurtenis en gebeurtenis. Een levensgebeurtenis is in de Stelselcatalogus omschreven als “een in de realiteit optredende gebeurtenis welke in de regel zal leiden tot een aanpassing van de verzameling vastgelegde gegevenswaarden in het stelsel van basisregistraties.” Een gebeurtenis is omschreven als “een implementatie van een levensgebeurtenis in een basisregistratie.” Het is dus een 'vertaling' van de verwerking van een levensgebeurtenis door een basisregistratie. Een gebeurtenis hoeft overigens niet te zijn gerelateerd aan een levensgebeurtenis, het kan ook een administratieve vaststelling zijn die niet direct te relateren is aan één (of meer) gebeurtenis(sen). Digilevering maakt gebruik van de gebeurtenissen zoals gedefinieerd in de Stelselcatalogus. De voor Digilevering specifieke gegevens over een gebeurtenissoort (bijvoorbeeld het beheren van filtercriteria) zullen wél in Digilevering worden beheerd. Deze ontwerpbeslissing heeft de volgende consequenties: • gebeurtenissoorten moeten in de Stelselcatalogus zijn onderkend, voordat ze kunnen worden gebruikt in Digilevering; • de versie/release frequentie van Stelselcatalogus moet worden afgestemd met de voorzieningen die gebruik maken van de gegevens uit de Stelselcatalogus (naast Digilevering gaat bijvoorbeeld ook Digimelding gebruik maken van de Stelselcatalogus).

12.

Bij een gebeurtenisbericht kunnen geen bijlagen worden toegevoegd. Toelichting: In de eerste versie van Digilevering kunnen bijlagen niet worden toegevoegd. Bijlagen maken geen deel uit van de gegevensuitwisseling over gebeurtenissen van en naar Digilevering. Houders landelijke voorziening en afnemers zullen, indien er behoefte is aan het verstrekken van bijlagen, voorzieningen moeten treffen buiten Digilevering om.

13.

De volgorde van levering door Digilevering van gebeurtenissen betreffende één basisregistratie is gegarandeerd. Toelichting: een landelijke voorziening stuurt de gebeurtenissen in een bepaalde volgorde naar Digilevering. Voor afnemers is het van belang dat de gebeurtenissen


40/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

in dezelfde volgorde dan waarin de landelijke voorziening ze heeft gestuurd, worden ontvangen. Digilevering garandeert dat de volgorde van ontvangst van gebeurtenissen van één landelijke voorziening, betreffende één basisregistratie, ook de volgorde is waarin gebeurtenissen worden verstuurd aan een afnemer. 4.2 Mensen en applicaties De in paragraaf 3.4 onderkende primaire processen binnen Digilevering worden allen geautomatiseerd ondersteund. De geautomatiseerde ondersteuning voor een deel van secundaire (beheer)processen (m.n. uitvoeren servicemanagement) valt buiten de scope van het project Digilevering. Dit is ingericht bij Logius en wordt hier verder niet beschreven. Met betrekking tot de geautomatiseerde ondersteuning van Digilevering wordt in deze paragraaf aangegeven: • welke NORA-principes op welke manier zijn gehanteerd; • welke vorm(en) van geautomatiseerde ondersteuning wordt aangeboden aan de 'buitenkant' van Digilevering; • wat de belangrijkste functionele componenten zijn van Digilevering en hoe hun samenhang is. 4.2.1 Toepassing relevante NORA-principes Voor het onderdeel mens en applicaties zijn de volgende NORA-principes relevant: Nr

Omschrijving


6.1.1.2

Applicaties voeren services van

Digilevering heeft een duidelijke functie:

slechts één functioneel domein uit

distribueren van gebeurtenisberichten aan daarop geabonneerde afnemers. In de technische architectuur is Digilevering uitgewerkt in twee applicaties: Digilevering-core en Digileveringportaal. Daarbij is ook aangegeven welke applicatie welke functionaliteit ondersteunt.

6.1.1.3

Organisaties en applicaties die in

Alle functionaliteit van Digilevering wordt

verschillende functionele domeinen

beschikbaar gesteld in de vorm van services. In

werkzaam zijn, werken met elkaar

paragraaf 4.2.2 wordt beschreven welke

samen op basis van services.

implementatievorm (webservice (t.b.v. een applicatie-applicatie koppeling) of mens-machine interface (MMI)) elke service kent.

6.1.1.8

Applicaties maken gebruik van de

Voor Digilevering zal daar waar mogelijk gebruik

standaard faciliteiten van

worden gemaakt van kant-en-klare producten voor

hun omgeving.

standaard faciliteiten. De beschikbaarheid van opensource producten zal daarbij nadrukkelijk worden onderzocht. In ieder geval wordt gebruik


41/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Nr

Omschrijving

Toepassing in Digilevering gemaakt van Stelselcatalogus, OSB Serviceregister en OSB-standaarden.

6.1.2.2

Websites van overheidsorganisaties Voor te ontwikkelen portaalonderdelen wordt de eis zijn ontwikkeld en ingericht conform

gesteld dat die voldoen aan de webrichtlijnen.

de ‘overheidswebrichtlijnen’. 6.1.2.6

Inkomende en uitgaande

Alle berichtuitwisseling tussen landelijke

communicatie met klanten wordt

voorziening, Digilevering en afnemer wordt gelogd.

gearchiveerd 6.1.3.2

Services zorgen voor losse

De applicatie-applicatie koppelingen worden

koppelingen tussen gebruiker en

gebaseerd op een dialoog die bestaat uit

leverancier.

berichtenuitwisseling. Voor de functionaliteit die wordt uitgevoerd met een mens-machine interface zal een dialoog tussen de gebruiker en Digilevering worden opgebouwd.

6.1.3.3

Bij services die deel uitmaken van

De (geautomatiseerde) services worden geheel of

een bedrijfs- of werkproces

geheel niet uitgevoerd (zie ook hoofdstuk

koppeling van transactionele aard is

beveiliging).

een transactieprotocol (met compenserende acties) aanwezig. 6.1.3.4

Service-informatie is landelijk

De webservices die worden ontwikkeld, zullen

beschikbaar.

worden geregistreerd in het OSB Serviceregister. Daarmee is de service-informatie landelijk beschikbaar.


42/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

4.2.2 Interface: mens en/of applicatie? De functionaliteit van Digilevering wordt deels uitgevoerd als applicatie-applicatie koppelingen (A2A, geen menselijke interactie) en deels uitgevoerd met een mens-machine interface (MMI, wel menselijke interactie). In onderstaand schema is op het procesmodel afgebeeld welke vorm(en) van interface van toepassing is (zijn) voor de diverse procesonderdelen die de interface met de omgeving vormen. Verstrekken Verwerkingsinfo

MMI

Verstrekken Verwerkingsinfo





Beheren Abonnement




8. 8. Beheren Beheren selectie op gebeurtenisfilter gegevenselement

9. 9. Beheren Beheren selectie op gebeurtenisfilter gegevenselement




Beheren objectlijst

A2A

Beheren Objectlijst




MMI

Beheren Basisregistratie-info 1. Beheren basisregistratieinfo

MMI


Verwerken Gebeurtenis

A2A



Beheren Abonnement

MMI

14. Versturen bericht



MMI




Figuur 8: Interfaces Digilevering Toelichting: Proces

MMI en/of A2A?

Toelichting

Beheren abonnement

MMI

Voor alle onderdelen (selecteren gebeurtenissoorten, definiëren objectlijst,

A2A


43/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Proces

MMI en/of A2A?

Toelichting beheren gebeurtenisfilters, beheren selectie op gegevenselement en check op contract en vrijgeven) is een MMI-variant beschikbaar.

Beheren objectlijst

A2A

Voor het beheren van de objectlijst (toevoegen en verwijderen van objectidentificaties aan de objectlijst) is een A2A-variant beschikbaar, gezien de verwachte grote omvang van de mutaties en de verwachting dat afnemers dit geautomatiseerd willen verwerken.

Beheren gebeurtenissoort

MMI

Vanwege de lage mutatiegraad wordt deze functionaliteit als MMI-variant uitgevoerd. Met behulp van deze MMI kunnen de gegevens over gebeurtenissoorten, die specifiek zijn voor Digilevering, worden beheerd.

Beheren afnemer-info

MMI

Vanwege de lage mutatiegraad wordt deze functionaliteit als MMI-variant uitgevoerd.

Beheren basisregistratie-info MMI

Vanwege de lage mutatiegraad wordt deze functionaliteit als MMI-variant uitgevoerd

Verwerken gebeurtenis

Zowel het aanleveren van een gebeurtenis (van landelijke voorziening naar Digilevering) als versturen van een gebeurtenis (van Digilevering naar afnemer) verloopt zonder menselijke interactie.

A2A

4.2.3 Functionaliteit Digilevering Digilevering kent op hoofdlijnen de onderstaande functionaliteiten voor het ondersteunen van c.q. het volledig uitvoeren van de processen. De onderkende functionaliteiten worden in het functioneel ontwerp verder beschreven door middel van use-cases. Elke beschreven functionaliteit vormt een zogenaamd use-case package. Het UP-nummer tussen haakjes verwijst naar het use-case package uit het functioneel ontwerp. •

Aansluitingenbeheer (UP100): functionaliteit voor het vastleggen van gegevens van afnemers en houders landelijke voorzieningen. Het betreft hier alleen gegevens die relevant zijn voor de registratie van abonnementen en het verwerken van gebeurtenissen. Denk hierbij aan het vastleggen van de technische aansluiting(en)


44/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

die nodig zijn voor het berichtenverkeer tussen Digilevering en afnemers c.q. landelijke voorzieningen. •

Beheer catalogi gebeurtenissoorten (UP200): functionaliteit om per basisregistratie de onderkende gebeurtenissoorten vast te leggen en te beheren. Per gebeurtenissoort wordt geregistreerd welke gegevenselementen er zijn en worden de mogelijkheden voor filtering op de gegevenselementen geregistreerd.

•

Abonnementenbeheer (UP300): functionaliteit voor het, op basis van een tussen afnemer en registratiehouder afgesloten contract, vastleggen van de inhoud van abonnementen. Vastgelegd wordt welke gebeurtenissoorten binnen het abonnement vallen, van welke objecten de abonnementhouder gebeurtenissen wil ontvangen, de te hanteren gebeurtenisfilter(s) en de selectie van gegevenselementen per gebeurtenissoort die de afnemer mag/wil ontvangen. Na het specificeren van een abonnement kent Digilevering functionaliteit om het abonnement vrij te geven. Pas na vrijgave worden ook daadwerkelijk gebeurtenissen geleverd.

•

Gebeurtenisverwerking (UP400): functionaliteit om door de landelijke voorziening aan Digilevering geleverde gebeurtenissen, op basis van in abonnementen opgenomen specificaties, te sturen aan afnemers. Hiertoe wordt per binnengekomen gebeurtenis: • vastgesteld in welke abonnementen de aan de gebeurtenis gerelateerde gebeurtenissoort is opgenomen; • vastgesteld of het object (de objecten) waarop de gebeurtenis betrekking heeft voorkomt in de objectlijst van het abonnement (voor zover van toepassing); • vastgesteld of de gebeurtenis valt binnen de gebeurtenisfilter van de betreffende gebeurtenissoort binnen het abonnement (voor zover van toepassing). Digilevering verstuurt vervolgens de gebeurtenis aan alle afnemers van abonnementen waarvan is vastgesteld dat de gebeurtenis volgens de abonnementspecificatie geleverd moet worden. Bij het samenstellen van het bericht worden alleen die gegevenselementen opgenomen, waar de afnemer voor is geautoriseerd. Indien het voorkomt dat een bericht ontstaat zonder gegevenselementen, dan wordt dit bericht verstuurd. Onder gebeurtenisverwerking valt ook het beheren van de objectlijst18. Dat kan door de afnemer worden geïnitieerd, of objectidentificaties kunnen worden toegevoegd of verwijderd naar aanleiding van het verwerken van een gebeurtenis.

18

Het beheren van de objectlijst is opgenomen in UP400 omdat deze functionaliteit qua dynamiek (relatief veel

mutaties, acuut bijwerken) meer gelijkenis vertoont met gebeurtenisverwerking, dan met abonnementenbeheer (relatief stabiel, wijzigingen gaan veelal pas op een later tijdstip werken).


45/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

•

Vastlegging en verantwoording (UP500): functionaliteit voor het vastleggen van en rapporteren over verwerkingen binnen Digilevering. Dit betreft enerzijds het vastleggen van het ontvangen en versturen van gebeurtenisberichten, anderzijds worden auditttrail vastgelegd van wijzigingen in onder meer de gebeurtenissoorten en abonnementen.

•

Gebruikers- en mandatenbeheer (UP600): functionaliteit voor het toekennen van rechten aan gebruikers van afnemers, landelijke voorzieningen en serviceorganisatie Digilevering, voor het gebruik van functionaliteit van Digilevering, inclusief het mandateren van taken.

•

Operationeel beheer (UP900): functionaliteit voor het operationeel beheer op Digilevering. Denk hierbij aan monitoring berichtenverkeer, monitoring databases, beheer certificaten, monitoring hardware en capaciteit.

In onderstaande figuur is aangegeven welke functionaliteit welke processen ondersteunt dan wel volledig geautomatiseerd uitvoert. Daarbij moet worden opgemerkt dar het proces Uitvoeren servicemanagement weliswaar wordt ondersteund, maar dat deze ondersteuning al is geïmplementeerd bij de serviceorganisatie Digilevering (Logius) en derhalve in het project niet wordt gespecificeerd en ontworpen.


46/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Verstrekken

Uitvoeren Servicemanagement 16. Uitvoeren servicemanagement

Gebruikersen Uitvoeren operationeel mandaten en tactisch beheer Beheer

17.(UP600) Uitvoeren Oper. en tact. beheer


Operationeel Beheer (UP900)

Beheren Abonnement



Abonnementenbeheer 8. 9. 8. Beheren Beheren 9. Beheren Beheren selectie op selectie op (UP300) gebeurtenisfilter gebeurtenisfilter gegevenselement gegevenselement




4. Beheren

criteria Beheer filtering Catalogi Gebeurtenissoorten (UP200)

Beheren objectlijst

Beheren Objectlijst






Aansluitingenbeheer (UP100)



Gebeurtenisverwerking 13. Bepalen afnemer(s) (UP400)




Beheren Abonnement



Verwerkingsinfo Vastlegging en Verstrekken Verantwoording Verwerkingsinfo (UP500)

Figuur 9: Functionaliteit Digilevering 4.2.4 Autorisatie Voor het gebruik van niet-openbare (persoonsgerelateerde) gegevens uit basisregistraties, geldt een regime van autorisatie, gebaseerd op doelbinding. Afnemers mogen (nietopenbare) gegevens uit basisregistraties slechts gebruiken voorzover dit noodzakelijk is voor de uitoefening van hun taken (doelbinding). Het leveren van gegevens over gebeurtenissen door middel van abonnementen valt onder dit regime. Het is derhalve belangrijk dat Digilevering de juiste faciliteiten bezit om de, in het contract tussen houder landelijke voorziening en afnemer, vastgelegde afspraken (de feitelijke juridische titel voor de autorisatie) te kunnen vastleggen (in de vorm van een abonnement) en uitvoeren. Dan is gegarandeerd dat de vastlegging van deze afspraken niet door onbevoegde personen kan worden veranderd. Dat betekent dat autorisatie binnen Digilevering twee aspecten kent:


47/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

1. Vastlegging (en vrijgave) van de rechten van een afnemer op de levering van gebeurtenis(gegevens) zoals vastgelegd in contracten (in Digilevering geregistreerd als abonnement); 2. Rechten op het gebruik van functionaliteit van Digilevering. Vastlegging van de rechten van een afnemer in een abonnement Een uitgangspunt voor Digilevering is, dat afnemer en houder landelijke voorziening een contract afsluiten waarin formeel is vastgesteld welke gebeurtenissen en gegevens een afnemer geleverd mag krijgen, in relatie tot de taken die worden uitgevoerd. De autorisatie in juridische zin is dus in contracten buiten Digilevering vastgelegd. Om ervoor te zorgen dat een afnemer geleverd krijgt waar hij recht op heeft (en niet meer dan dat), zijn er in Digilevering diverse mogelijkheden om dit te garanderen. Deze mogelijkheden variëren van maatregelen die betrekking hebben op alle abonnementen, tot maatregelen die betrekking hebben op een individueel gegevenselement binnen een abonnement. De volgende maatregelen met betrekking tot autorisatie zijn beschikbaar (van grof naar fijn): Niveau 1: Abonnementoverstijgend •

Beschikbaar stellen van gebeurtenissoorten Een houder landelijke voorziening bepaalt welke soorten gebeurtenissen beschikbaar zijn voor opname in abonnementen. Onderkent een houder landelijke voorziening een gebeurtenissoort, maar wil ze die niet beschikbaar stellen door middel van een abonnement, dan kan dit worden aangegeven in Digilevering. De gebeurtenissoort is dan simpelweg niet op te nemen in een abonnement en zal derhalve nooit geleverd worden.

•

Beschikbaar stellen van gegevenselementen Een houder landelijke voorziening kan per soort gebeurtenis vastleggen welke gegevenselementen (of groepen gegevenselementen) ervan, beschikbaar zijn om in abonnementen op te nemen. Onderkent een houder landelijke voorziening dus een gegevenselement, maar wil ze die niet beschikbaar stellen door middel van een abonnement, dan kan dit worden aangegeven in Digilevering. Het gegevenselement is dan simpelweg niet op te nemen in een abonnement en zal derhalve nooit geleverd worden.

Niveau 2: Binnen een abonnement •

Opnemen van een gebeurtenissoort in een abonnement


48/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Door het opnemen van een gebeurtenissoort in een abonnement, wordt aangeduid dat een afnemer gebeurtenissen van die soort in beginsel mag ontvangen (gegeven de beperkingen, waarover hieronder meer). Alleen de gebeurtenissoorten die in het contract zijn afgesproken, worden opgenomen in het abonnement. Hiermee wordt dus autorisatie op het niveau van gebeurtenissoort geregistreerd. •

Definiëren van een selectie op gegevenselementen Binnen een abonnement kan voor elke, in het abonnement opgenomen, gebeurtenissoort worden vastgelegd welke (groepen van) gegevenselementen geleverd worden. Op deze manier worden gegevens over gebeurtenissen, die volgens het contract niet geleverd mogen worden, geblokkeerd. Een door de landelijke voorziening geleverde gebeurtenis kan op deze manier door Digilevering voor elke afnemer 'op maat' worden doorgestuurd, afhankelijk van de gemaakte afspraken.

•

Definiëren van een filter op gegevenselementen De levering van gebeurtenissen kan worden ingeperkt door het definiëren van een filter op gegevenselementen. Voor elke gebeurtenissoort kan een filterexpressie worden gedefinieerd die ervoor zorgt dat alleen die gebeurtenissen die aan de expressie voldoen, worden doorgestuurd. Op deze manier kan de levering van gebeurtenissen worden beperkt op bijvoorbeeld geografisch gebied, administratief gebied, branchecode en geboortedatum, afhankelijk van wat een houder landelijke voorziening hierin toestaat.

•

Definiëren van objectlijst De levering van gebeurtenissen kan worden ingeperkt door het definiëren en beheren van een lijst met objectidentificaties (objectlijst) waarop een gebeurtenis wordt getoetst. Komt een objectidentificatie voor in de gebeurtenis, dan wordt de gebeurtenis verstrekt. In het contract kan omschreven zijn voor welke (verzameling van) objecten het abonnement geldig is. Dit is gerelateerd aan de taakstelling van de afnemer.

•

Check op contract en vrijgeven abonnement Als aparte processtap is het vrijgeven van een abonnement onderkend. Alleen op basis van vrijgegeven abonnementen worden door Digilevering daadwerkelijk gebeurtenissen verstrekt. Bij het vrijgeven van een abonnement wordt, door zowel de houder landelijke voorziening als de afnemer, bekeken of de in Digilevering vastgelegde abonnementspecificaties, een juiste weerslag zijn van de contractuele afspraken die tussen afnemer en houder landelijke voorziening zijn gemaakt.

Rechten op het gebruik van functionaliteit van Digilevering


49/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Bovenstaand zijn de functionaliteiten benoemd die in Digilevering beschikbaar zijn om autorisatie vast te leggen in abonnementen, om ervoor te zorgen dat een afnemer precies die gegevens krijgt, waar hij gezien de taken waarvoor de gegevens gebruikt worden, recht op heeft. Om ervoor te zorgen dat alleen daartoe gerechtigde gebruikers de functionaliteiten van Digilevering kunnen benaderen, wordt gebruikersen mandatenbeheer ingericht. Hiervan worden hieronder de belangrijkste uitgangspunten en de hoofdlijnen van de inrichting beschreven. In het functioneel ontwerp wordt het rechtenbeheer gedetailleerd uitgewerkt (UP600). De belangrijkste hoofdlijnen van gebruikersen mandatenbeheer zijn: •

Houder landelijke voorziening is verantwoordelijk voor beheer en vrijgave van abonnementen De houder landelijke voorziening heeft de verantwoordelijkheid voor het beheer en de vrijgave van abonnementen. In Digilevering liggen de daaruit voortvloeiende rechten daarmee automatisch bij die houder landelijke voorziening.

•

Mandateren taken aan organisatie Een organisatie kan mandateren aan een andere organisatie. De organisatie waaraan is gemandateerd is slechts uitvoerend. Het werken met mandaten is ingegeven door het feit dat niet elke landelijke voorziening de noodzaak voelt om de taken waarvoor ze verantwoordelijk zijn, ook daadwerkelijk zelf uit te voeren. Met name bij openbare registraties bestaat de wens om de uitvoering van taken te mandateren. De organisatie aan wie een taak wordt gemandateerd, dient dit mandaat formeel te aanvaarden.

•

Rechtenbeheerder per organisatie De invulling van rollen binnen een organisatie, evenals het delegeren van rollen aan andere organisaties is een taak voor een expliciet aangewezen rechtenbeheerder binnen die organisatie.

4.3 Berichten en gegevens De in paragraaf 4.2 beschreven functionaliteit van de Abonnementenvoorziening brengt met zich mee dat berichten worden uitgewisseld met de omgeving (i.c. landelijke voorzieningen en applicaties bij afnemers) en dat administratieve- en stuurgegevens worden vastgelegd in Digilevering. In deze paragraaf wordt beschreven welke gegevens in Digilevering worden vastgelegd en wat hun structuur is, en wordt de berichtuitwisseling (in functionele zin) beschreven. Dit vormt het kader voor de verdere uitwerking hiervan in het functioneel en technisch ontwerp. 4.3.1 Relevante NORA-principes Voor het onderdeel berichten en gegevens zijn de volgende NORA-principes relevant:


50/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Nr

Omschrijving


6.2.3.1

Binnen de e-overheid worden

Van alle ontvangen en verstuurde berichten worden

metagegevens geregistreerd

in Digilevering metagegevens (zoals identificaties,

op het moment dat brongegevens

datumtijdstempels etc.) systematisch en

worden ontvangen of

geautomatiseerd vastgelegd.

zaakgegevens wijzigen. Bij voorkeur geschiedt dit automatisch. 6.2.3.3

Gegevens, berichten en

Digilevering kent een audittrail voor

documenten worden voorzien van

gegevensmutaties en berichtenverkeer. Voor elke

metagegevens ten behoeve van

gegevensmutatie wordt datum/tijdstip, identificatie

beheer.

van gebruiker en geautomatiseerd proces vastgelegd. Van het berichtenverkeer wordt elke ontvangst en verstrekking vastgelegd, dit betreft alle relevante identificaties en contextinformatie.

6.2.3.5

De eigenaar van een gegeven is

Digilevering is niet verantwoordelijk voor de

verantwoordelijk voor de

kwaliteit van de inhoud van berichten. Houders

kwaliteit (actualiteit,

landelijke voorzieningen en afnemers zijn

betrouwbaarheid) van een gegeven. verantwoordelijk voor de inhoud van de uitgewisselde berichten. 6.2.3.7

Van geleverde gegevens is de

Afspraken over de kwaliteit van de geleverde

kwaliteit bekend

gegevens (i.c. gegevens betreffende een gebeurtenis) worden gemaakt tussen houder landelijke voorziening en afnemer.

6.2.4.1

Gegevens- en procesinhoudelijke

Gegevensinhoudelijk is de in de Stelselcatalogus

communicatiestandaarden moeten

beschreven semantiek leidend.

een semantisch model bevatten of verwijzen naar een zodanig semantisch model. 6.2.4.4

Waar haalbaar onderscheidt een

Het semantisch model voor Digilevering kent zowel

semantisch model

objecten als gebeurtenissen.

expliciet objecten en gebeurtenissen. 6.2.4.5

De definitie en taxonomie van

Principe wordt gehanteerd.

gegevens die zijn opgenomen in nationale basisregistraties zijn leidend. 6.2.6.1

Overheidsorganisaties maken

Digilevering voorziet in generieke en centrale


51/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Nr

6.2.6.2

Omschrijving


gebruik van de (Nederlandse)

ondersteuning voor de levering van (mutaties van)

basisregistraties.

gegevens, gebaseerd op abonnementsafspraken.

Bij elk gegeven dat wordt gebruikt

De basisregistratie is leidend voor bij wet

door meerdere

vastgestelde authentieke gegevens. Daar waar

overheidsorganisaties moet duidelijk afnemers kopiebestanden hanteren, worden deze zijn welke organisatie leidend is.

door middel van het doorgeven van mutaties (op

Deze organisatie bepaalt of een

abonnementsbasis) onderhouden.

wijziging doorgevoerd mag worden. 6.2.6.3

Een verandering in de

Digilevering biedt hiervoor een generieke oplossing.

administratieve werkelijkheid wordt ter attentie gebracht van alle partijen die daar belang bij hebben. 6.2.6.5

Objecten worden op een

In het PSA worden de relevante objecttypen

systematische wijze beschreven

beschreven in het objectmodel. In het functioneel ontwerp is een Object Relation Model (ORM) opgenomen met nadere specificaties.

6.3.1

Het berichtenverkeer binnen de e-

Dit principe wordt gevolgd, de OSB-standaarden

overheid wordt vooralsnog

(versie 2.0) zijn een vereiste.

gebaseerd op standaarden conform ofwel de ebXML-familie ofwel de webservice familie 6.3.2

Een bericht bevat een header en

Dit principe wordt gevolgd.

payload gedeelte 6.3.3

Versiebeheer van

Van elk berichttype worden maximaal 2 versies

berichtstandaarden wordt

tegelijkertijd ondersteund. Een oude versie van het

ondersteund

berichttype wordt minstens 1 jaar ondersteund nadat een nieuwe versie beschikbaar is. Indien er 2 versies van een berichttype naast elkaar zijn geïmplementeerd, worden beide versies (in verschillende berichten), door de landelijke voorziening aangeboden en verwerkt door Digilevering.


52/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

4.3.2 Objecten Het objectmodel beschrijft de belangrijkste soorten (business)objecten19 en hun onderlinge relaties, die worden onderkend voor Digilevering. Het objectmodel heeft primair als doel de belangrijkste begrippen rondom Digilevering te verduidelijken en de gekozen uitgangspunten en ontwerpbeslissingen te concretiseren in een logisch model. De onderkende objecten, en hun onderlinge samenhang, zijn weergegeven in het objectmodel.

Basisregistratie

Afnemer

onderkent

sluit af

1,n

1,n waarin opgenomen

Gebeurtenis soort

1,n 1

1 Beperkt de levering van gebeurtenissen voor

Beperkt de te leveren gegevens van gebeurtenissen voor

Gegevensselectie

Abonnement

waarin opgenomen 0,n

Gebeurtenis filter

Object identificatie

Figuur 10: Objectmodel Basisregistratie Voor de werking van Digilevering is het allereerst nodig Basisregistraties te onderkennen. Van elke basisregistratie worden die administratieve gegevens geregistreerd (of, indien mogelijk, uit een andere generieke voorziening opgevraagd), die nodig zijn voor het (technisch) functioneren van Digilevering. Dit betreft bijvoorbeeld de gegevens van de aansluiting die de landelijke voorziening hanteert voor de communicatie met Digilevering. Gebeurtenissoort 19

De (business)objecten zoals bedoeld in deze paragraaf, moeten niet worden verward met de objecten die

worden opgenomen in een objectlijst van een abonnement. Deze paragraaf beschrijft alle objecten/concepten van Digilevering, de objectidentificaties van een objectlijst is één van die concepten.


53/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Elke basisregistratie onderkent (1 of meerdere) Gebeurtenissoorten. De houder landelijke voorziening is verantwoordelijk voor het bepalen en definiëren van de soorten gebeurtenissen waarvan de verstrekking door middel van een abonnement kan plaatsvinden. Voorbeelden van gebeurtenissoorten zijn: 'starten onderneming', 'slopen voertuig', 'overlijden persoon'. De gebeurtenissoorten staan geregistreerd in de Stelselcatalogus en worden gebruikt door Digilevering.

Afnemer Digilevering heeft vervolgens gegevens nodig over Afnemers. Een afnemer is een publieke organisatie of private organisatie die voor het uitoefenen van een publieke taak gebruik maakt van gegevens uit een basisregistratie. Digilevering legt de administratieve gegevens over afnemers (zoals aansluitgegevens) vast, die nodig zijn voor de afhandeling van de levering van gebeurtenissen op basis van een abonnement. Abonnement Een afnemer heeft 1 of meerdere Abonnementen. Dit is een inschrijving, op basis van een tussen afnemer en basisregistratie afgesloten contract, voor de geregelde levering van gegevens over gebeurtenissen van 1 of meerdere Gebeurtenissoorten. Het abonnement vormt de basis voor het vaststellen (door Digilevering) naar welke afnemers een door een landelijke voorziening aangeleverde gebeurtenis20 moet worden (door)gestuurd. Het contract tussen afnemer en registratiehouder, dat de basis vormt voor een abonnement, wordt niet in Digilevering vastgelegd. Gebeurtenisfilter Binnen een abonnement is het mogelijk dat afnemers aangeven niet alle gebeurtenissen van een gebeurtenissoort te willen ontvangen, maar slechts een deelverzameling daarvan. Bijvoorbeeld: alleen de gebeurtenissen van gebeurtenissoort 'starten onderneming' binnen de provincie Utrecht in plaats van alle gebeurtenissen van die soort. Een dergelijke beperking op de levering van gebeurtenissen wordt een Gebeurtenisfilter genoemd. De registratiehouder bepaalt bij elke gebeurtenissoort op basis van welke gegevenselementen kan worden gefilterd. Een gebeurtenisfilter kan voor elke soort gebeurtenis binnen een abonnement worden gespecificeerd. Een gebeurtenisfilter is niet verplicht. Objectidentificatie Daarnaast bestaat de mogelijkheid om bij een abonnement een verzameling Objectidentificaties te definiëren die de objecten waarop het abonnement betrekking heeft aanduiden. Veelal zal een afnemer geïnteresseerd zijn in gebeurtenissen voor zover ze betrekking hebben op de verzameling objecten die in hun context relevant zijn. Voorbeelden 20

Strikt genomen wordt er geen gebeurtenis gestuurd, maar een bericht waarin gegevens over de gebeurtenis is opgenomen.


54/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

zijn: een verzameling natuurlijke personen (gespecificeerd door een lijst met BSN's), een verzameling voertuigen, een verzameling verblijfsobjecten, etc. Digilevering zal in dat geval een gebeurtenis pas doorsturen naar een afnemer, indien de gebeurtenis betrekking heeft op een object dat in de verzameling gespecificeerd is. Gebeurtenisfilter en Objectidentificatie zijn derhalve de mechanismen waarmee de levering van gebeurtenissen van een gebeurtenissoort wordt ingeperkt. Indien beiden niet zijn gespecificeerd zullen alle gebeurtenissen van een in een abonnement opgenomen gebeurtenissoort worden geleverd aan de afnemer. Als beide mechanismen worden gecombineerd, wordt een gebeurtenis pas geleverd indien aan zowel de Objectidentificatie als de Gebeurtenisfilter is voldaan. Gegevensselectie Met Gebeurtenisfilter en Objectidentificatie wordt dus bepaald of een gebeurtenis wordt geleverd aan een afnemer (of niet). Dat wil nog niet zeggen dat dan ook de volledige gebeurtenisgegevens geleverd mag of moet worden. Met de Gegevensselectie kan worden aangegeven welke gegevens(elementen) van een gebeurtenis worden geleverd. Dit kan enerzijds te maken hebben met autorisatie (beperking van gegevenselementen op grond van doelbinding), anderzijds kan een afnemer zelf kiezen niet alle gegevens van een gebeurtenis te willen ontvangen. Op basis van een gedefinieerde gegevensselectie wordt door Digilevering, als laatste stap in het verwerkingsproces, het bericht voor de afnemer samengesteld. Het hierboven beschreven objectmodel bevat de soorten objecten waarmee de gebeurtenisverwerking kan worden geconfigureerd. Als de gegevensuitwisseling zelf (de uitwisseling van berichten met landelijke voorzieningen en afnemers) wordt toegevoegd, ontstaat het volgende model:


55/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

krijgt

verstrekt

Basisregistratie

1,n

leidt tot 0,n

Gebeurtenisbericht (van BR)

onderkent

Gebeurtenisbericht (aan afnemer)

1,n behoort tot Gebeurtenis 1,1 soort

waarin opgenomen

sluit af

Wordt verstrekt op basis van 1,1

1,n 1

1,n

Abonnement

1 Beperkt de levering van gebeurtenissen voor

Beperkt de te leveren gegevens van gebeurtenissen voor

Gegevensselectie

Afnemer

0,n

waarin opgenomen 0,n

Gebeurtenis filter

Object identificatie

Figuur 11: Objectmodel inclusief berichten Gebeurtenisbericht (van BR) Een gebeurtenisbericht (van BR) is een bericht van een (landelijke voorziening van) een basisregistratie. Het bericht bevat een beschrijving van een gebeurtenis, volgens de specificatie van de soort gebeurtenis. Een gebeurtenisbericht van een BR kan leiden tot gebeurtenisberichten aan (één of meer) afnemers. Dit wordt afgeleid uit de specificatie van de abonnementen. Gebeurtenisbericht (aan afnemer) Een gebeurtenisbericht (aan afnemer) is een bericht, bestemd voor één afnemer, met een beschrijving van een gebeurtenis. Een gebeurtenisbericht aan een afnemer is afgeleid van een gebeurtenisbericht (van BR), maar hoeft niet identiek te zijn. Op basis van de abonnementspecificatie kunnen in een gebeurtenisbericht aan de afnemer gegevenselementen zijn leeggelaten die in het oorspronkelijke bericht van de basisregistratie wel gevuld zijn. 4.3.3 Gegevens Deze paragraaf beschrijft de logische structuur van de gegevens die worden geadministreerd in Digilevering. De beschreven gegevens zijn benodigd voor de juiste werking van Digilevering, dan wel vastlegging van verwerking door Digilevering en om de


56/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

relatie met andere voorzieningen (zoals Stelselcatalogus en OSB Serviceregister) te kunnen vaststellen. Onderstaand gegevensmodel (in de notatievorm ERD (EntiteitRelatieDiagram)) geeft de logische gegevensstructuur weer, gevolgd door een uitleg per entiteittype (beschrijving, voorbeelden, gegevens). Daarbij wordt het model zo veel mogelijk van boven naar beneden beschreven. NB: omwille van de leesbaarheid van het model is het entiteittype 'objecttype' twee keer getekend. Het gaat hier echter om hetzelfde entiteittype. Basisregistratie

Afnemer

Gebeurtenisbericht (van BR)

Gebeurtenisbericht (aan afnemer)

Gebeurtenissoort

Objecttype

Abonnement

Gebeurtenissoort van abonnement

Gebeurtenissoort gegevenselement

GebeurtenisFilter

Gegevenselement in Filter

Selectie Gegevenselement

Figuur 12: Gegevensmodel Digilevering

Basisregistratie

Objectidentificatie

Objecttype


57/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Omschrijving

Een basisregistratie is een verzameling gegevens waarvan bij wet is bepaald dat deze een basisregistratie vormen.

Voorbeelden Gegevens

Basisregistratie Adressen, Basisregistratie Voertuigen, Nieuw Handelsregister. •

naam basisregistratie

•

OIN houder landelijke voorziening

•

naam houder landelijke voorzieningen

•

contactgegevens houder landelijke voorziening

•

aansluiting(en) landelijke voorziening

Afnemer Omschrijving

Een afnemer is een overheidsinstantie of een privaatrechtelijke instantie met een publieke taak die gegevens afneemt van een basisregistratie.

Voorbeelden Gegevens

Gemeente Heusden, SVB, Provincie Gelderland. •

OIN afnemer

•

naam afnemer

•

contactgegevens afnemer

•

aansluiting(en) afnemer

Gebeurtenisbericht (van BR) Omschrijving

Een bericht van een (landelijke voorziening van een) basisregistratie waarin een gebeurtenis is beschreven.

Voorbeelden

Het bericht van NHR waarin melding gemaakt wordt van de gebeurtenis 'starten onderneming xyz', inclusief alle relevante gegevens over deze gebeurtenis.

Gegevens

•

Identificatie bericht (van BR)

•

OIN afnemer

•


•


•

identificatie gebeurtenissoort

•

gegevens van de gebeurtenis

Gebeurtenisbericht (aan afnemer) Omschrijving

Een bericht aan een afnemer waarin een gebeurtenis is beschreven.

Voorbeelden

Het bericht aan Gemeente Heusden waarin melding gemaakt wordt van de gebeurtenis 'starten onderneming xyz', inclusief alle relevante gegevens over


58/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

deze gebeurtenis. Gegevens

•

Identificatie gebeurtenisbericht (aan afnemer)

•


•


•


•

identificatie abonnement

•

identificatie gebeurtenisbericht (van BR)

•

gegevens van de gebeurtenis

Gebeurtenissoort Omschrijving

Een gebeurtenissoort is een binnen een basisregistratie onderkende typering van een gebeurtenis die de registratie beïnvloedt (muteert) dan wel uit de registratie is af te leiden.

Voorbeelden

'Starten onderneming', 'Mutatie verblijfsobject', 'Persoon bereikt 65-jarige leeftijd'.

Gegevens

•


•

identificatie basisregistratie

•

naam gebeurtenissoort

•

omschrijving gebeurtenissoort

•

begindatum geldigheid

•

einddatum geldigheid

Abonnement Omschrijving

Een abonnement is een inschrijving, op basis van een tussen afnemer en houder landelijke voorziening afgesloten contract, voor de geregelde levering van gebeurtenissen van 1 of meerdere gebeurtenissoorten.

Voorbeelden

Het abonnement van de Gemeente Heusden (afnemer) voor de geregelde levering van gebeurtenissen van de soort 'starten onderneming' van de basisregistratie NHR.

Gegevens

•


•

identificatie afnemer

•

referentie naar contract

•

aansluitgegevens

•

begindatum geldigheid

•

einddatum geldigheid

•

geautoriseerd j/n


59/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

•

autorisatiedatum

Gebeurtenissoort van abonnement Omschrijving

Een gebeurtenissoort van abonnement representeert een in een abonnement opgenomen gebeurtenissoort.

Voorbeelden

De gebeurtenissoort 'starten onderneming' die onderdeel uitmaakt van het abonnement van de Gemeente Heusden. De gebeurtenissoort 'starten onderneming' die onderdeel uitmaakt van het abonnement van de Provincie Gelderland.

Gegevens

•


•


Gebeurtenissoort gegevenselement Omschrijving

Een beschrijving van een bij een gebeurtenissoort onderkend gegeven.

Voorbeelden

De gebeurtenissoort 'starten onderneming' kent (o.a.) de volgende gegevenselementen: 'KvK-nummer', 'naam onderneming', 'vestigingsnummer'.

Gegevens

•


•

identificatie gegevenselement

•

naam gegevenselement

•

kardinaliteit (mogelijk aantal voorkomens)

•

objectidentificatie j/n

•

identificatie objecttype (indien objectidentificatie = 'j')

•

filtering toegestaan op gegevenselement j/n

•

type toegestane filtering21

Objecttype Omschrijving

Een objecttype is een typering van een concreet ding, concept of gebeurtenis in de werkelijkheid, waarover in een basisregistratie gegevens worden geadministreerd.

Voorbeelden 21

'Vestiging' (objecttype van NHR), 'gekentekend voertuig' (objecttype van BRV),

In het functioneel ontwerp wordt nader gespecificeerd welke typen toegestane filtering worden onderkend.


60/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

'verblijfsobject' (objecttype van BGR). Gegevens

•

identificatie objecttype

•

naam objecttype

Gebeurtenisfilter Omschrijving

Een gebeurtenisfilter is een specificatie van de toe te passen filtering (selectie van gebeurtenissen die moeten worden doorgestuurd) behorende bij een gebeurtenissoort van een abonnement.

Voorbeelden

De filterregel 'gemeente = “Heusden”' bij de gebeurtenissoort 'starten onderneming' van het abonnement van de gemeente Heusden.

Gegevens

•


•


•

filterspecificatie

Gegevenselement in filter Omschrijving

Een 'gegevenselement in filter' is een aanduiding van het gebruik van een gegevenselement in een filter.

Voorbeelden

Het gegevenselement 'gemeente' van de gebeurtenissoort 'starten onderneming' is opgenomen in het filter van het abonnement van de gemeente Heusden.

Gegevens

•


•


•


Selectie gegevenselement Omschrijving

Aanduiding of een gegevenselement van een gebeurtenissoort geselecteerd moet worden voor verzending aan de afnemer, binnen de kaders van één abonnement.

Voorbeelden

Aanduiding dat het gegevenselement 'aantal werkzame personen' niet tot de selectie van te versturen gegevens van de gebeurtenissoort 'starten onderneming' behoort binnen het abonnement van de Gemeente Heusden. De aanduiding kan het resultaat zijn van een (niet) toegekende autorisatie of een door de afnemer zelf aangebrachte beperking.


61/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Gegevens

•


•


•


•

geselecteerd j/n

•

reden selectie

•

verwijzing naar (autorisatie)besluit

Objectidentificatie Omschrijving

Identificatie van een in het stelsel van basisregistraties voorkomend object, als onderdeel van een abonnement. Indien objectidentificaties bij een abonnement zijn opgenomen worden alleen de gebeurtenissen betreffende deze objectidentificaties naar de afnemer gestuurd.

Voorbeelden

'152664993' (identificatie natuurlijk persoon); '82RFVF' (identificatie gekentekend voertuig).

Gegevens

•


•

objectidentificatie

•

identificatie objecttype

Tijdversies Voor twee entiteitypen, gebeurtenissoort en abonnement, is het belangrijk tijdversies te onderkennen. De definitie van een gebeurtenissoort kan in de loop van de tijd veranderen. Het is belangrijk om te weten welke versie van een gebeurtenissoort in een abonnement is opgenomen. Zolang er geldige abonnementen zijn met een bepaalde versie van een gebeurtenissoort, zal de landelijke voorziening (minimaal 1 jaar) moeten zorg dragen voor de levering van gebeurtenissen volgens de definitie van die versie van de gebeurtenissoort. Voor een abonnement is het van belang de begindatum en einddatum geldigheid vast te stellen. Hiermee kunnen abonnementen worden gespecificeerd die pas op een latere datum ingaan en kan een abonnement van een einddatum worden voorzien. Indien er iets veranderd aan de specificatie van het abonnement (uitgezonderd de objectlijst), dan wordt dit beschouwd als een nieuwe (tijd)versie van abonnement, dat geldig wordt op het moment dat het oude abonnement ongeldig wordt verklaard.


62/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Relatie met de Stelselcatalogus: gebeurtenissen In de Stelselcatalogus kunnen twee typen gebeurtenissen worden vastgelegd [5]: levensgebeurtenis en gebeurtenis. Een levensgebeurtenis is in de Stelselcatalogus omschreven als “een in de realiteit optredende gebeurtenis welke in de regel zal leiden tot een aanpassing van de verzameling vastgelegde gegevenswaarden in het stelsel van basisregistraties.” Een gebeurtenis is omschreven als “een implementatie van een levensgebeurtenis in een basisregistratie.” Het is dus een 'vertaling' van de verwerking van een levensgebeurtenis door een basisregistratie. Een gebeurtenis hoeft overigens niet te zijn gerelateerd aan een levensgebeurtenis, het kan ook een administratieve vaststelling zijn die niet direct te relateren is aan één (of meer) gebeurtenis(sen). Bijvoorbeeld: het 'vaststellen ven een inkomen' is niet (direct) gerelateerd aan een gebeurtenis in de werkelijkheid. Voor Digilevering zijn de gebeurtenissen uit de Stelselcatalogus gelijk aan de gebeurtenissoorten zoals hiervoor gedefinieerd. Relatie met de Stelselcatalogus: objecttypen Een tweede relatie met de Stelselcatalogus betreft objecttypen. In de Stelselcatalogus zijn per basisregistratie de objecttypen gedefinieerd. In Digilevering bestaat de mogelijkheid om bij een abonnement een objectlijst te definiëren. Dit is een lijst met objectidentificaties (bijvoorbeeld BSN's) die objecten van een bepaald type aanduiden (in het voorbeeld een persoon). Hoe verhouden zicht de objecttypen uit de Stelselcatalogus met de objecttypen zoals bedoeld in een objectlijst? Die relatie is als volgt: De objecttypen waarvoor een objectlijst kan worden gedefinieerd is een deelverzameling van de objecttype uit de Stelselcatalogus. Niet voor elk objecttype uit de Stelselcatalogus is het zinvol of mogelijk daar een objectlijst voor te definiëren. Het is aan de basisregistratie om de deelverzameling vast te stellen. Het komt voor dat in een basisregistratie een gegeven is opgenomen dat verwijst naar een objecttype uit een andere basisregistratie (bv de bestuurder van een gekentekend voertuig verwijst naar een persoon). Het is dus ook mogelijk dat in een abonnement bij een basisregistratie een objectlijst wordt opgenomen, waarbij objecttypen uit een andere basisregistratie worden gebruikt. Een verwijzing naar dat objecttype moet dan wel zijn opgenomen in de Stelselcatalogus. Relatie met OSB Service Register Voor de juiste werking van Digilevering is het nodig gegevens vast te leggen van landelijke voorzieningen en afnemers. In het OSB Serviceregister worden gegevens vastgelegd van


63/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

serviceproviders en servicerequesters. Afnemers en landelijke voorzieningen moeten, voordat ze gebruik kunnen maken van Digilevering, geregistreerd zijn in het OSB Serviceregister. Ze krijgen daar een identificerend nummer (OIN) en er worden enkele administratieve gegevens vastgelegd. Digilevering gebruikt deze gegevens en voegt daar enkele specifieke gegevens voor de juiste werking van de voorziening aan toe (bijvoorbeeld gegevens over de aansluitingen). 4.3.4 Berichten In paragraaf 4.2.2 is de interface van Digilevering met haar omgeving beschreven. Daarin is aangegeven, dat een deel van de interface bestaat uit mens-machine-interfaces (MMI) en een deel uit applicatie-applicatie koppelingen (A2A). De A2A-koppelingen worden uitgevoerd als webservice. Dat betekent dat er drie webservices worden onderkend: •

WS-1: Verstrek gebeurtenis Deze webservice wordt geïmplementeerd bij Digilevering en kan door een landelijke voorziening worden gebruikt om een gebeurtenisbericht te verstrekken aan Digilevering.

•

WS-2: Ontvang gebeurtenis Deze webservice wordt geïmplementeerd bij de afnemer en kan Digilevering worden gebruikt om een gebeurtenisbericht naar een afnemer te sturen.

•

WS-3: Beheer objectlijst Deze webservice wordt geïmplementeerd bij Digilevering en kan door de afnemer worden gebruikt om objectidentificaties aan de objectlijst toe te voegen of te verwijderen.

In alle drie de gevallen gaat het om webservices met als interactievorm “melding”, hetgeen betekent dat het berichtenverkeer gebaseerd zal zijn op de ebMS-standaard binnen de OSBstandaard22 (zie ook paragraaf 4.4). De webservices en bijbehorende berichttypen zijn als volgt weer te geven:

22

De onderkende interactievormen en de keuze voor de daarbij te gebruiken koppelvlakstandaard, zijn beschreven in de OSB Architectuur [11]


64/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Verstrekken Verwerkingsinfo Verstrekken Verwerkingsinfo





Beheren Abonnement



8. Beheren 8. Beheren selectie op gebeurtenisfilter gegevenselement


9. Beheren 9. Beheren selectie op gebeurtenisfilter gegevenselement




Digilevering BT-3 Objectidentificatie

Beheer objectlijst


WS-2 Ontvang Gebeur- Digilevering tenis BT-2 Gebeurtenis afnemer

Beheren objectlijst

WS-3

Beheren Objectlijst











Beheren Abonnement




WS-1 Verstrek Gebeurtenis

Figuur 13: Webservices en berichttypen Digilevering Onderstaand worden de berichttypen functioneel en op hoofdlijnen beschreven. De webservices en berichttypen worden in het functioneel en technisch ontwerp nader uitgewerkt.

Digilevering BT-1 Gebeurtenis LV


65/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Berichttypenummer

Digilevering BT-1

Berichttypenaam

Gebeurtenis landelijke voorziening

Van

Landelijke voorziening

Naar

Digilevering

Functie

Met dit berichttype kan een landelijke voorziening een gebeurtenis verstrekken aan Digilevering, zodat deze het bericht kan verstrekken aan de geabonneerde afnemers.

Gebruikt in webservice

WS-1: Verstrekken gebeurtenis

Standaard

ebMS volgens OSB 2.0

Berichtinhoud

Element

Betekenis

Datumtijdstempel LV

Door de landelijke voorziening aangebrachte datum + tijdstip waarop de gebeurtenis is verstuurd.

Kenmerk LV

Door de landelijke voorziening aangebracht uniek kenmerk van het gebeurtenisbericht.

Versie berichttype

Aanduiding van de versie van het berichttype (versie van de berichtdefinitie waarop het bericht is gedefinieerd).

Basisregistratie

Aanduiding van de basisregistratie waarvan de gebeurtenis afkomstig is.

Gebeurtenissoort

Aanduiding van de gebeurtenissoort (naam en versie) waarop de gebeurtenis betrekking heeft.

Gebeurtenisinhoud

Specificatie van de inhoud van de gebeurtenis. Inhoud is afhankelijk van de gebeurtenissoort.


66/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Berichttypenummer

Digilevering BT-2

Berichttypenaam

Gebeurtenis afnemer

Van

Digilevering

Naar

Afnemer

Functie

Met dit berichttype kan Digilevering een gebeurtenis verstrekken aan de afnemer.


WS-2: Ontvang gebeurtenis

Standaard


Berichtinhoud

Element

Betekenis

Datumtijdstempel Digilevering Door Digilevering aangebrachte datum + tijdstip waarop de gebeurtenis is verstuurd. Datumtijdstempel LV

Door de landelijke voorziening aangebrachte datum+ tijdstip waarop de gebeurtenis (oorspronkelijk) is verstuurd aan Digilevering.

Kenmerk Digilevering

Door Digilevering aangebracht uniek kenmerk van het gebeurtenisbericht.

Kenmerk LV

Door de landelijke voorziening aangebracht uniek kenmerk van het oorspronkelijke gebeurtenisbericht.

Versie berichttype


Abonnement

Aanduiding van het abonnement op basis waarvan de gebeurtenis wordt verstrekt.

Basisregistratie

Aanduiding van de basisregistratie waarvan de gebeurtenis afkomstig is.

Gebeurtenissoort

Aanduiding van de gebeurtenissoort (naam en versie) waarop de gebeurtenis betrekking heeft.

Gebeurtenisinhoud

Specificatie van de inhoud van de gebeurtenis. Inhoud is afhankelijk van de gebeurtenissoort en de toegepaste autorisatieregels.


67/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Berichttypenummer

Digilevering BT-3

Berichttypenaam

Objectidentificatie

Van

Afnemer

Naar

Digilevering

Functie

Met dit berichttype kan de afnemer mutaties op de bij een abonnement behorende objectlijst doorgeven, zodat Digilevering de objectlijst kan bijwerken.


WS-3: Beheren objectlijst

Standaard


Berichtinhoud

Element

Betekenis

Datumtijdstempel afzender Door de afnemer aangebrachte datum + tijdstip waarop de objectidentificaties zijn verstuurd. Kenmerk afnemer

Door de afnemer aangebracht kenmerk van het bericht.

Versie berichttype


Abonnement

Aanduiding van het abonnement waarop de objectlijst betrekking heeft.

Gewenste mutatie

Aanduiding van de gewenste mutatiesoort (toevoegen of verwijderen). Dit bepaalt de door Digilevering uit te voeren actie.

Objectidentificatie(s)

Eén of meer objectidentificaties (inclusief typering).


68/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

4.4 Informatie-uitwisseling In paragraaf 4.3.4 is uiteengezet welke webservices en berichten zijn onderkend voor de gegevensuitwisseling tussen Digilevering en landelijke voorziening respectievelijk afnemer. In deze paragraaf wordt ingegaan op de manier waarop en de standaarden waarmee het berichtenverkeer (tussen applicaties) wordt geregeld. 4.4.1 Relevante NORA-principes Voor het onderdeel informatie-uitwisseling zijn de volgende NORA-principes relevant: Nr

Omschrijving


6.4.2

Voor berichtentransport worden

Voor berichttransport maakt Digilevering gebruik

naast elkaar meerdere

van HTTP met SSL.

protocollen toegepast, waaronder

Mogelijk is voor het transport van bijlagen OSB

HTTP en FTP. Voor

Grote Berichten (nog in ontwikkeling) nodig. In dat

transportroutering wordt DNS

geval wordt ook FTP gebruikt.

gebruikt. 6.4.4

Doorlooptijd van berichtenverkeer is

De niet-functionele eisen zullen worden getoetst

onderwerp van

aan de mogelijkheden van de OSB c.q. KPS.

expliciete afspraak tussen servicebussen en hun gebruikers. 6.4.5

Vorige versies van

Voor Digilevering betreft dit de OSB-standaard

communicatieprotocollen binnen de

ebMS. Indien deze standaard een nieuwe versie

e-overheid worden gedurende twaalf implementeert die invloed heeft op de maanden nog ondersteund

communicatie van Digilevering, zal dit principe worden gehanteerd.

4.4.2 Gebruik van OSB 2.0 De OSB maakt berichtenuitwisseling mogelijk op basis van de ebXML/ebMS en WUS families van standaarden. De berichtuitwisseling van Digilevering met de omgeving (landelijke voorziening en afnemers) vindt bilateraal plaats, gestandaardiseerd op ebMS. Dat betekent dat de berichtuitwisseling voldoet aan de koppelvlakstandaard ebMS 2.0 (beschreven in [6]). In de berichtuitwisseling tussen Digilevering en de omgeving wordt geen servicebus ingezet in de zin van een voorziening (software) met ESB-functionaliteit. De OSB kan gebruikt worden bij reeds bestaande transportvoorzieningen (eigen lijnen, Gemnet, Suwinet, internet), maar ook bij toekomstige overheidsbrede voorzieningen als het Koppelnet Publieke Sector (KPS), dat gerealiseerd wordt in het project Bundeling Landelijke Netwerken.


69/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Authenticatie gebeurt op basis van een PKIoverheid-certificaat. Dit certificaat kan worden aanvraagd bij een Certificate Service Provider (CSP). De basis van dit certificaat is een OIN: een overheidsidentificatienummer. Dit OIN is de identiteit van de overheidsorganisatie. Een OIN wordt ontvangen na inschrijving van een organisatie in het OSB Serviceregister van Logius.


70/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

5

Technische architectuur

In dit hoofdstuk wordt de technische architectuur van Digilevering beschreven. Eerst wordt een overzicht gegeven van de applicatie architectuur. Daarna wordt ingezoomd op de onderkende applicaties. Ten slotte wordt de technische infrastructuur beschreven waarbinnen Digilevering geïmplementeerd kan gaan worden. 5.1 Relevante NORA-principes Digilevering gaat (daar waar van toepassing) uit van de architectuurprincipes en -richtlijnen zoals die in de NORA beschreven staan. Daarmee wordt gezorgd voor maximale interoperabiliteit op proces-, informatie-, juridisch en technisch niveau. Voor het onderdeel technische architectuur zijn de volgende principes van belang: Nr

Omschrijving


7.1.1

Met in achtneming van het belang

Digilevering biedt een open gestandaardiseerde

van beschikbaarheid,

interface aan de aansluitende

interoperabiliteit en beveiliging, zijn

overheidsorganisaties. Derhalve zijn deze

overheidsorganisaties

organisaties vrij in het kiezen van geschikte

relatief vrij in het kiezen van

technische componenten die deze open

technische componenten.

standaarden implementeren.

Organisaties die 7*24

Digilevering wordt in een omgeving neergezet

dienstverlening aanbieden, zorgen

waarbij de componenten meervoudig zijn

ook voor een bijpassende hoge

uitgevoerd en waarbij gebruik wordt gemaakt van

technische beschikbaarheid van de

load balancing. Daarnaast wordt een backup-/-

onderliggende machines en

restore voorziening vereist en een bijbehorende

platformen.

procedure (disaster recovery plan).

De Basisregistraties zijn leidend.

Digilevering maakt alleen gebruik van

7.1.2

7.2.3

brongegevens die door de landelijke voorzieningen van de basisregistraties worden aangeleverd. 7.3.1

Communicatie tussen

Digilevering wordt gekoppeld aan KPS. KPS is een

overheidsorganisaties verloopt via

besloten overheidsnetwerk. Daarnaast is de

besloten, separate netwerken of

verbinding beveiligd door middel van SSL / TLS op

door middel van een virtual private

basis van PKIoverheid certificaten.

network verbinding via netwerken van particuliere bedrijven. 7.3.2

Communicatie e-overheid en

Digilevering wordt ook gekoppeld aan internet.

burgers/bedrijven via een beveiligde Deze verbinding wordt beveiligd door middel van


71/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Nr

7.3.3

Omschrijving


Internetverbinding of VPN.

SSL / TLS op basis van PKIoverheid certificaten.

Het interne netwerk van

Digilevering kent één koppeling met internet en één

overheidsorganisaties is via één

koppeling met KPS. Deze koppelingen worden

redundant en veilig uitgevoerde

redundant uitgevoerd.

koppeling aangesloten op het publieke netwerk.

5.2 Applicatie architectuur De kernfunctionaliteit van Digilevering is tweeledig. Enerzijds moet het systeem aan de gebruikers (afnemers, landelijke voorzieningen en serviceorganisatie Digilevering) een mechanisme bieden via welke de gebruiker zich kan abonneren op één of meerdere gebeurtenissoorten van een basisregistratie. Anderzijds moet het systeem voorzien in een mechanisme waaraan de landelijke voorzieningen van basisregistraties hun gebeurtenissen kunnen aanbieden en waardoor die gebeurtenissen worden gedistribueerd naar de afnemers die geabonneerd zijn op de gebeurtenissen. Beide kernfunctionaliteiten kunnen in afzonderlijke applicaties geïmplementeerd worden. Wat beide applicaties delen zijn de gegevens over een abonnement en de verwerkingsinformatie over een gebeurtenis. De applicaties zijn: 1. Digilevering Portaal – een webapplicatie welke een gebruikersinterface aanbiedt aan de gebruikers van Digilevering waarin abonnementen en gebeurtenissoorten beheerd kunnen worden. Daarnaast kunnen beheer activiteiten zoals gebruikersbeheer en aansluitingenbeheer in het Digilevering Portaal worden uitgevoerd. 2. Digilevering Core – een applicatie waarin de centrale gebeurtenisverwerking van Digilevering plaatsvindt. Deze applicatie ontvangt gebeurtenisberichten van de verschillende landelijke voorzieningen en distribueert deze, op basis van de beschikbare abonnementen, naar de voor de gebeurtenissoort geabonneerde afnemers. De applicatie biedt hiervoor een machine naar machine koppeling, in de vorm van webservices, aan de afnemers en landelijke voorzieningen. 5.2.1 Overzicht In onderstaand figuur wordt een schets gegeven van de onderkende applicaties en hun context.


72/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Afnemer

Serviceorganisatie Digilevering


Beheer Stelsel Catalogus Serviceorganisatie Digilevering

OSB Digilevering <<Webapplicatie>> Digilevering

UP200 Catalogibeheer

UP100 Aansluitingenbeheer UP600 Gebruikers- en mandatenbeheer

Afnemer

Abonnementen Register

Gebeurtenisverwerking

<<ebMS service>> WS-3 Beheer Objectlijst

UP400 Gebeurtenisverwerking UP500. Vastlegging & Verantwoording

<<ebMS service>> WS-1 Verstrek Gebeurtenis

OSB

<<ebMS service>> WS-2 Ontvang Gebeurtenis

Gebeurtenissen Register

<<Applicatie>> Digilevering Core

OSB

<<Systeem afnemer>>

Houder landelijke voorziening

UP500 Vastlegging & Verantwoording

UP300 Abonnementen beheer

<<Systeem Landelijke Voorziening>>

Figuur 13: Applicatiecontext In het figuur zijn de verschillende organisaties te onderkennen: • Afnemer • Landelijke voorziening • Serviceorganisatie Digilevering • Digilevering Daarnaast een opsplitsing gemaakt naar kernfunctionaliteit (Beheer en Gebeurtenisverwerking). Van de applicaties Digilevering Core en Digilevering Portaal worden de use case packages opgesomd die door de applicaties worden geïmplementeerd. Het raakvlak tussen de twee applicaties zijn de databases waarin de abonnementen (Abonnementen Register) en gebeurtenissen (Gebeurtenissen Register) worden opgeslagen.

5.3 Digilevering Portaal In deze paragraaf wordt de context van het Digilevering Portaal beschreven. De onderwerpen die aan bod komen zijn: gebruikersinterface, beveiliging en de koppeling met


73/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

de Stelselcatalogus. De infrastructuur waarbinnen het Digilevering Portaal wordt geïmplementeerd, staat beschreven in de laatste paragraaf van deze technische architectuur. 5.3.1 Inleiding Het Digilevering Portaal biedt de gebruikers van Digilevering (afnemers, houders landelijke voorzieningen en de service organisatie) één gebruikersinterface naar de beheerschermen (gebruikersen mandatenbeheer, abonnementenbeheer, catalogibeheer, aansluitingenbeheer en vastlegging & verantwoording) van Digilevering. 5.3.2

Overzicht

Gebruiker Serviceorganisatie

Gebruiker Landelijke voorziening

Gebruiker Afnemer

Internet / KPS

Digilevering Portaal systeem <<Webapplicatie>> Digilevering Portaal

Figuur 14: Digilevering Portaal 5.3.3 Gebruikersinterface Het Digilevering Portaal wordt aan de gebruikers van het systeem gepresenteerd in de vorm van HTML pagina´s. De gebruiker krijgt via een webbrowser toegang tot het systeem. De transport laag is HTTP 1.1 over TCP/IP welke is beveiligd middels SSL 3.0 / TLS1.0. 5.3.4 Beveiliging De toegang tot het Digilevering Portaal wordt op verschillende niveaus beveiligd:


74/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

1. door middel van een firewall worden alleen verbindingen toegestaan van systemen waarvan het IP bij de firewall bekend is. Daarnaast wordt alleen toegang tot poort 443 toegestaan; 2. authenticatie en encryptie middels SSL 3.0 / TLS 1.0. De verbinding waarover de gegevens van en naar afnemers, landelijke voorzieningen en de serviceorganisatie Digilevering worden getransporteerd is beveiligd middels SSL 3.0 / TLS 1.0 op basis van PKIoverheid certificaten. Deze PKIoverheid certificaten zijn gebonden aan een organisatie die vanuit zijn taak gebruik maakt van Digilevering; 3. door middel van autorisatie op basis van gebruikersnaam en wachtwoord. Alleen bij Digilevering Portaal geregistreerde gebruikers mogen gebruik maken van het Digilevering Portaal. De gebruiker krijgt nadat hij geautoriseerd is alleen toegang tot die functionaliteit waartoe hij is gerechtigd. Naast toegangsbeveiliging moet de informatie in de Digilevering Portaal beveiligd worden opgeslagen. Dit betekent dat alle gegevens in het Digilevering Portaal versleuteld worden opgeslagen in de bronsystemen (database, filesysteem). 5.3.5 Koppeling met de Stelselcatalogus Binnen de context van Digilevering is er een koppeling met de Stelselcatalogus. De Stelselcatalogus is een door Logius gehoste centrale voorziening. In de Stelselcatalogus worden de datamodellen van de verschillende basisregistraties gepubliceerd. De datamodellen bestaan uit objecten met attributen. Daarnaast worden ook de gebeurtenissoorten van een basisregistratie in de Stelselcatalogus vastgelegd. Vanuit het Digilevering Portaal wordt gebruik gemaakt van de volgende informatie uit de Stelselcatalogus: 1. Lijst met gebeurtenissoorten, waarbij per gebeurtenissoort inzichtelijk is bij welke basisregistratie deze toebehoord. Een gebeurtenissoort is niet uniek over basisregistraties. Een gebeurtenissoort is binnen een basisregistratie echter wel uniek. De combinatie gebeurtenissoort met basisregistratiecode maakt de gebeurtenissoort uniek identificeerbaar; 2. Lijst met objecttypen, waarbij per objecttype inzichtelijk is bij welke basisregistratie deze hoort. Een objecttype is niet uniek over basisregistraties heen. Een objecttype is echter wel uniek binnen een basisregistratie. De combinatie objecttype en basisregistratiecode maakt het objecttype uniek identificeerbaar. De informatie uit de Stelselcatalogus is via het OSB WUS koppelvlak van de Stelselcatalogus bevraagbaar. 5.4

Digilevering Core


75/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

5.4.1 Inleiding De Digilevering Core is de applicatie waarbinnen de centrale gebeurtenisverwerking wordt uitgevoerd. Het distribueert gebeurtenisberichten die van een landelijke voorziening zijn ontvangen naar de op de gebeurtenissoort geabonneerde afnemers. Daarnaast biedt het functionaliteit om objectlijsten, waarop gefilterd mag worden, te onderhouden. 5.4.2

Overzicht <<Systeem Landelijke Voorziening >>

<>

OSB ebMS

<<ebMS service>> WS-2 Ontvang Gebeurtenis

Internet / KPS

Digilevering Core systeem <<ebMS service>> WS-1 Verstrek Gebeurtenis

<<ebMS service>> WS-3 Beheer Objectlijst

Figuur 15: Digilevering Core 5.4.3 Webservices De Digilevering Core wordt in de vorm van OSB ebMS webservices ontsloten met systemen van de afnemers en van de landelijke voorzieningen. OSB ebMS is het standaard koppelvlak op basis waarvan overheidsorganisatie onderling betrouwbaar berichten kunnen uitwisselen. OSB ebMS zorgt ervoor dat berichten eenmalig en gegarandeerd afgeleverd worden. 5.4.4 Berichtvolgorde De gebeurtenisberichten die door de landelijke voorziening per basisregistratie naar de Digilevering Core worden verzonden moeten in volgorde worden ontvangen door de Digilevering Core. De gebeurtenisberichten die vervolgens naar een afnemer worden gestuurd moeten in dezelfde volgorde worden verstuurd als dat ze van de landelijke


76/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

voorziening per basisregistratie zijn ontvangen. Om de berichtvolgorde te garanderen moet het volgende worden gerealiseerd: •

•

De landelijke voorziening levert zijn berichten in de juiste volgorde af bij zijn ebMS adapter. De ebMS adapters van de landelijke voorziening en de ebMS adapter van de Digilevering Core zorgen er vervolgens voor dat de berichten in de juiste volgorde bij de Digilevering Core worden afgeleverd. De Digilevering Core levert de berichten in dezelfde volgorde af bij zijn ebMS adapter ten behoeve van verzending richting een geabonneerde afnemer . De ebMS adapter van de Digilevering Core en de ebMS adapter van de afnemer zorgen ervoor dat de berichten in dezelfde volgorde worden afgeleverd.

5.4.5 Beveiliging De toegang tot de Digilevering Core wordt op verschillende niveaus beveiligd: 1. door middel van een firewall worden alleen verbindingen geaccepteerd van systemen waarvan het IP nummer bekend is. Daarnaast wordt alleen toegang tot poort 443 toegestaan; 2. authenticatie en encryptie middels SSL 3.0 / TLS 1.0. De verbinding waarover de gegevens van en naar de afnemers en de landelijke voorzieningen worden getransporteerd is beveiligd middels SSL 3.0 / TLS 1.0 op basis PKIoverheid certificaten, waarbij de certificaten gebonden zijn aan de organisatie die vanuit zijn taak gebruik maakt van Digilevering; 3. autorisatie op basis van OIN. Iedere organisatie is door de Digilevering Core te identificeren door middel van zijn OIN welke is opgenomen in zijn PKI-Overheid certificaat. De Digilevering Core autoriseert de afnemers of houder landelijke voorziening op basis van zijn OIN. Naast toegangsbeveiliging moet de informatie in de Digilevering Core beveiligd worden opgeslagen. Dit betekent dat alle gegevens in de Digilevering Core versleuteld worden opgeslagen in de bronsystemen (database, filesysteem). 5.4.6 Koppelingen externe systemen De Digilevering Core koppelt aan de systemen van de landelijke voorziening en van de afnemers. Van de landelijke voorziening ontvangt de Digilevering Core gebeurtenisberichten via zijn OSB ebMS adapter. Deze gebeurtenisberichten worden vervolgens in de Digilevering Core verwerkt tot gebeurtenisberichten die ten slotte naar de afnemer systemen gestuurd worden via OSB ebMS. De afnemer systemen en landelijke voorziening systemen worden respectievelijk door de afnemers en houders landelijke voorziening zelf ontwikkeld en geïmplementeerd. Deze systemen vallen derhalve buiten de scope van deze technische architectuur.


77/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

5.5 Logische opbouw De Digilevering Portaal applicatie en de Digilevering Core applicatie kennen dezelfde logische opbouw. Deze opbouw bestaat uit vier lagen én één domein laag, met de uitzondering dat de Digilevering Core applicatie geen presentatie laag kent. Presentatie laag - HTML - Controllers - Invoer validatie

Service laag - Authenticatie & Autorisatie - Data Transfer Objects - Service Protocol(EJB, SOAP...) - DTO <=> Domein model

Domein model

Business laag - Business validaties - Delegeren Business Rules naar Domein laag - Aanroepen Data Access laag

Abonnement

Gegevens element


Gebeurtenis soort

Catalogus

Afnemer

Gegevens element Filter

Autorisatie Filter

Gebeurtenis

Data Access laag - Persisteren en ophalen domein model uit Data Access Laag

Gebeurtenissen Register

Domein laag

Business Rules

Abonnementen Register

ObjectIdLijst Filter

OSB Service Register

Autorisatie

Stelsel Catalogus

Figuur 16: Logische opbouw van lagen Presentatie laag De Presentatie laag is verantwoordelijk voor het verwerken (valideren invoer, bepalen volgende pagina, ophalen gegevens, opslaan gegevens, verwijderen gegevens etc.) van alle verzoeken van een gebruiker. De Presentatie laag delegeert een deel van zijn taken aan de Service laag. De Presentatie laag wordt alleen onderkend in de Digilevering Portaal applicatie.


78/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Service laag De Service laag isoleert de Business laag van de verschillende protocollen (SOAP, REST, EJB, RMI) via welke de service laag ontsloten kan worden. Daarnaast vindt in deze laag authenticatie en autorisatie plaats. Deze laag wordt in Digilevering Portaal applicatie aangeroepen vanuit de presentatie laag. Deze laag is de ingang voor de Digilevering Core applicatie. Hierin worden de ebMS service requests afgehandeld. Business laag De Business laag implementeert de business logica van het systeem. Hier worden bijvoorbeeld filter expressies gevalideerd en abonnementen gevalideerd. De Business laag kan zijn business logica delegeren aan de Domein laag indien deze logica in meerdere processen wordt gebruikt. Deze laag kan gedeeld worden door beide applicaties, Digilevering Core en Digilevering Portaal. Data Access laag De Data Access laag is verantwoordelijk voor de communicatie met bronsystemen zoals databases, het OSB Service Register en de Stelselcatalogus. De informatieverzoeken ontvangt deze laag vanuit de Business laag. Deze laag kan gedeeld worden door beide applicaties, Digilevering Core en Digilevering Portaal. Domein laag Deze laag implementeert het domein model van Digilevering. Het domein model bestaat uit de objecten (Catalogus, Abonnement, Gebeurtenissoort, Gegevenselement etc.) en business logica (Filterregels, Abonnementenregels etc.) van Digilevering. Deze laag kan vanuit verschillende lagen (Service, Business en Data Access laag) benaderd worden. Deze laag kan gedeeld worden door beide applicaties, Digilevering Core en Digilevering Portaal. 5.6 Technische infrastructuur De Digilevering Core en Digilevering Portaal applicaties zijn beide beschikbaar in dezelfde infrastructuur. Dit heeft voordelen voor onder andere de beheerlasten van het systeem.


79/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Overzicht

Internet / KPS

Cluster

Load balancer & SSL Accelerator (redundant)

Webserver (redundant) + Digilevering Core + Digilevering Portaal

LAN1 Firewall intern 1 (redundant)

Gebruiker bij Afnemer / Landelijke voorziening / Serviceorganisatie

Firewall extern (redundant)

DMZ LAN

Cluster

Applicatie Server (redundant) + Gebeurtenis verwerking + Afhandeling portaal verzoeken

Systeem bij Afnemer / Landelijke voorziening

LAN2

Firewall intern 2 (redundant)

5.6.1

Cluster

Database Server (redundant) + Abonnementen register + ebMS adapter + Gebeurtenis register

S A N 1 (r e d u n d a n t)

Firewall intern 3 (redundant)

Logserver (redundant)

LAN3 SAN 2 (Digilevering)

Figuur 17: Technische Infrastructuur Externe netwerken Digilevering moet zowel aan internet als aan KPS gekoppeld worden. Beide verbindingen moeten minimaal twee keer uitgevoerd worden. Indien ten gevolge van bijvoorbeeld een kabelbreuk de primaire verbinding eruit ligt, moet het mogelijk zijn om via een alternatieve verbinding Digilevering te benaderen. Hiervoor moeten afspraken gemaakt worden met de netwerkleveranciers. Externe firewall De firewall zorgt ervoor dat netwerkverkeer dat niet voor Digilevering bedoeld is geblokkeerd wordt. De firewall wordt geconfigureerd met de IP-adressen van de systemen van de afnemers, landelijke voorzieningen en van de serviceorganisatie Digilevering die toegang mogen krijgen tot Digilevering. Voor deze IP-adressen wordt alleen poort 443 opengezet. Ten behoeve van beschikbaarheid moet de firewall redundant worden uitgevoerd. Load balancer en SSL offloader Het externe dataverkeer met Digilevering wordt door een load balancer verdeeld over de achterliggende webservers. De load balancer stuurt alleen load naar servers die beschikbaar zijn. Daarnaast verdeelt deze de last over de beschikbare webservers. Verdere voordelen van het inzetten van een load balancer is dat op rustige momenten onderhoud op applicatie servers plaats kan vinden. Het dataverkeer tussen de externe systemen (van afnemers en de houders landelijke voorzieningen) en Digilevering wordt versleuteld door middel van SSL encryptie op basis van


80/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

PKIoverheid certificaten. Voor het ontsleutelen en authenticeren van het dataverkeer kan gebruik gemaakt worden van een hardwarematige SSL accelerator. Dit versnelt de SSL ontsleuteling met 8x tot 18x. Ten behoeve van beschikbaarheid moet de SSL offloader dubbel uitgevoerd zijn. Interne firewall 1 Deze firewall zorgt ervoor dat alleen verkeer vanaf de webservers worden toegelaten tot de achterliggende applicatie servers. Interne firewall 2 Deze firewall zorgt ervoor dat alleen verkeer vanaf de applicatie servers worden toegelaten tot de achterliggende database servers. Interne firewall 3 Deze firewall filtert het netwerkverkeer tussen de logserver en de overige servers waaruit het systeem is opgebouwd. Webserver De webservers hosten de webservices van de Digilevering Core alsmede de webapplicatie van het het Digilevering Portaal. Deze applicaties moeten zonder aanpassingen opgenomen kunnen worden in een clusterconfiguratie zodat de applicaties horizontaal geschaald kunnen worden en daarmee ook de beschikbaarheid van het systeem wordt vergroot. Applicatie server De applicatie servers hosten de Digilevering Core gebeurtenisverwerking en de Digilevering Portaal verwerkingen. Deze processen moeten zonder aanpassingen opgenomen kunnen worden in een clusterconfiguratie ten behoeve van het verhogen van de schaalbaarheid en beschikbaarheid van de processen. Database server De database servers hosten de databases van de Digilevering Core en het Digilevering Portaal. Ten behoeve van beschikbaarheid en schaalbaarheid van de databases moeten de databases zonder aanpassingen opgenomen kunnen worden in een clusterconfiguratie. Logserver Log-events worden weggeschreven op een aparte logserver. Deze logserver is alleen toegankelijk voor medewerkers met een controletaak en niet voor de beheerders van de infrastructuur die onderwerp is van de logging. Voor het verwijderen van de loggings (na de gestelde bewaartermijn) zijn twee personen noodzakelijk. De inhoud van de logserver wordt meegenomen in het back-up proces. (Zie ook eis Nr 825.2 van het beveiligingshoofdstuk in dit document)


81/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Ten behoeve van beschikbaarheid moet de Logserver dubbel uitgevoerd worden. SAN 1 (Storage Area Network) Vanwege de hogere betrouwbaarheid en de relatief eenvoudige uitbreidbaarheid van SAN´s word hiervoor gekozen. De SAN´s kunnen eenvoudig worden geschaald, wat direct de capaciteit van alle afnemende servers vergroot. Het SAN moet ten behoeve van beschikbaarheid dubbel uitgevoerd worden. In SAN 1 wordt alle relevante Digilevering informatie vastgelegd met uitzondering van Log-events (Zie ook eis Nr 825.2 van het beveiligingshoofdstuk in dit document) SAN 2 (SAN) Log-events worden in dit aparte SAN vastgelegd (Zie ook eis Nr 825.2 van het beveiligingshoofdstuk in dit document)


82/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

6

Beveiliging

Digilevering is een dienst waarbij het uitwisselen van informatie tussen verschillende partijen centraal staat. Hiervoor is het vertrouwen nodig van de landelijke voorzieningen en afnemers in deze dienst en in de informatie die binnen de dienst verwerkt wordt. Twee voorwaarden om dit vertrouwen te verdienen zijn: • de juiste beveiliging; • transparantie hierover naar alle betrokken partijen. Om voor Digilevering de juiste beveiliging met transparantie te kunnen beschrijven dient de informatiebeveiliging aan de hand van een standaard beschreven te worden. Deze standaard moet door alle betrokken partijen begrepen en toegepast worden. De Nederlandse overheid gebruikt hiervoor NORA – de Nederlandse Overheid Referentie Architectuur. Informatiebeveiliging is een apart domein in deze architectuur. Binnen Digilevering wordt de architectuur volgens NORA opgetekend. 6.1 NORA De voorliggende architectuur van Digilevering is beschreven met gebruikmaking van de architectuurprincipes zoals die binnen NORA 2.0 gedefinieerd zijn. Voor informatiebeveiliging wordt er specifiek gebruik gemaakt van het NORA katern Informatiebeveiliging [7]23, zoals dit binnen NORA 3.0 is gedefinieerd. De reden hiervoor is dat de kwaliteit van de nieuwe versie, ook al is het een reviewversie, door specialisten als aanzienlijk beter wordt gezien. Het NORA katern Informatiebeveiliging is voor een belangrijk deel gebaseerd op de Code voor Informatiebeveiliging (ISO/IEC 27002) en het Voorschrift Informatiebeveiliging Rijksdienst (VIR). Beide standaarden liggen dus ook ten grondslag aan de gedefinieerde maatregelen binnen Digilevering. NORA voorziet in de bepaling van een baseline voor informatiebeveiliging van Digilevering op basis van interne en externe oriëntatie. Onder interne oriëntatie vallen: • Bedrijfsstrategie en -doelstellingen; • Risico's voor de organisatie. Onder externe oriëntatie vallen: • Wet- en regelgeving; 23

Het Katern Informatiebeveiliging bevind zich op het moment in de review fase. Binnen dit document is versie

1.0 van 01-10-2009 is gebruikt.


83/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

• •

Contractuele eisen; De beveiligingsstandaarden: • ISO/IEC 27002 en • NORA katern Informatiebeveiliging.

Middels een vertaalslag worden hieruit de beveiligingsmaatregelen bepaald. Omdat voor de dienst Digilevering geen geen algemene baseline van toepassing verklaard is, dient deze specifiek opgezet te worden. Er wordt gebruik gemaakt van elementen uit het IB-plan van Logius. Dit betekent wel dat voor Digilevering een compleet pakket aan maatregelen geïmplementeerd moet worden. Het pakket omvat niet alleen de ICT-maatregelen die binnen de informatiesystemen en ICT-infrastructuur vallen, maar ook de operationele context waarbinnen deze maatregelen moeten functioneren, zoals de organisatie, bedrijfsprocessen en ondersteunende processen. NORA onderkent algemene principes voor informatiebeveiliging en beveiligingsprincipes voor ICT-voorzieningen. Deze laatsten worden binnen NORA logisch gegroepeerd in negen IB-functies. Deze groepering is in dit hoofdstuk overgenomen. Eerst wordt de relevantie van de andere bovengenoemde oriëntatieaspecten kort besproken. Uiteindelijk vallen alle beveiligingsmaatregelen in te delen onder de algemene principes of onder één van de IB-functies. 6.2

Interne oriëntatie

6.2.1 Bedrijfsstrategie en doelstellingen Zie de contextbeschrijving in paragraaf 2.1 in het PSA. 6.2.2 Informatieclassificatie In Digilevering kunnen vier soorten informatie onderscheiden worden: 1. Inhoudelijke berichten 2. Registratie van abonnementen 3. Registratie van gebruikers 4. Registratie van gebeurtenissen (Loginfo) Volgens het classificatiemodel van Logius valt de waardering van alle informatiesoorten voor alle kwaliteitsaspecten op Niveau 2, met uitzondering van beschikbaarheid van alle informatiesoorten (Niveau 1) en exclusiviteit van berichten (Niveau 1). Dit laatste geldt voor de eerste aansluiters. Bij aansluiting van het GBA stijgt dit niveau zeker een stap tot niveau 2, wellicht meer.


84/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Waardering Kwaliteitsaspect Niveau 0 Niveau 1 Niveau 2 Algemeen Openb. Orde, Financ. Juridisch Imago Beschikbaarheid Openb. Orde, Financ. Juridisch, Imago Exclusiviteit Openb. Orde, Financ. Berichten: Juridisch Abonnementen, Gebruikers, Loginfo: Juridisch Integriteit Openb. Orde, Financ. Juridisch Imago

6.2.3

Niveau 3

Risico's voor de organisatie

Digilevering levert de volgende business services, zie PSA 3.3.2. Hierbij zijn de informatieentiteiten genoemd die bij die service van belang zijn: 1. Beheren gebeurtenissoort – catalogus, gebeurtenissoort, gegevenselement, filterexpressie 2. Beheren abonnementen – abonnement, mandaat, zie ook beheren gebeurtenissoort 3. Beheren objectlijst – objectlijst 4. Verstrekken gebeurtenis – gebeurtenis 5. Ontvangen gebeurtenis – gebeurtenis 6. Verstrekken verwerkingsinformatie – programma-logs, rapporten 7. Ondersteunen gebruik – organisaties, gebruikers, rechten, systeem, aansluiting, certificaat ICTU heeft een risico analyse uitgevoerd m.b.t. Digilevering, waarbij Logius betrokken is geweest. Hieruit volgen de volgende dreigingen met hoog risico, van toepassing op de PSA: A. Ongeautoriseerde toegang (tot apparatuur, programmatuur, gegevens) B. Opzettelijke gegevensmanipulatie C. Internetkoppeling (zwakheden in gekoppelde onderdelen) D. Overbelasting en capaciteitsgebrek E. Systeemontwikkeling (ontbreken van standaarden hiervoor) F. Controle op informatiebeveiligingsmaatregelen (onvoldoende) Niet iedere dreiging heeft een gelijke impact op alle business services. In de volgende tabel is aangegeven hoe deze impact verdeeld is. In de kolom maatregelen is aangegeven welke NORA IB-functies voornamelijk van toepassing zijn bij de aanpak van deze dreigingen. Belangen Dreigingen

A

1

2

3

4

5

6

7

Maatregelen (NORA IB-functies) qeprogrammeerde controles identificatie, authenticatie, autorisatie

B

vastleggen van gebeurtenissen


85/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Belangen

1

2

3

4

5

6

7

Maatregelen

Dreigingen

(NORA IB-functies)

C

zonering en filtering

D

continuiteitsvoorzienigen

E

secure development process

F

vastleggen van gebeurtenissen controle, alarmering en rapportering systeemintegriteit

Impact van dreigingen op business services (rood = hoog, geel = middelmatig) 6.3

Externe oriëntatie

6.3.1 Wet en regelgeving Voor de dienst Digilevering is een juridische scan uitgevoerd, en bijgewerkt [@@Jrdd.28-1009@@]. Hierin staan de juridische randvoorwaarden die er aan de realisatie van Digilevering moeten worden verbonden. Er wordt een onderscheid gemaakt tussen privaatrechtelijke randvoorwaarden en publiekrechtelijke randvoorwaarden. Privaatrechtelijk Leveringsvoorwaarden worden bepaald tussen de landelijke voorziening en de afnemer buiten de dienst Digilevering om. Op termijn zal wellicht een set van algemene leveringsvoorwaarden van toepassing moeten zijn. Dit aspect heeft op dit moment dus geen consequenties voor de inrichting van de dienst Digilevering. Publiekrechtelijk De landelijke voorziening is volledig verantwoordelijk voor alles wat met haar informatie gebeurt in de communicatie naar de afnemer. Meervoudige of samengestelde informatiepakketten zijn nog niet gepland en in de scan niet beoordeeld. De volgende wetten en voorschriften zijn van toepassing: • WBP – Wet Bescherming Persoonsgegevens Archiefwet (voor loggegevens) Voor Digilevering is er sprake van een reguliere bewerkerssituatie, behalve voor die basisregistraties wiens gebruik wettelijk verplicht is, zoals het GBA. Er dient een bewerkersovereenkomst afgesloten te worden tussen de landelijke voorziening en de dienst Digilevering en dient er melding gemaakt te worden door de betreffende landelijke voorziening. Dit heeft geen directe gevolgen voor de realisatie.


86/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

• •

•

Wel is er sprake van verscherpte eisen voor loggegevens. Met name de bewaartermijn is een punt van aandacht, met inachtname van de archiefwet. Beschikbaarheid van de loggegevens dienen redelijk en variabel te zijn met een termijn in de orde van een half jaar tot een jaar. Na het verstrijken van de bewaartermijn dient vernietiging plaats te vinden. Deze eisen zijn in de desbetreffende IB-functies verwerkt. Een ander aandachtspunt is de termijn waarbinnen recht van inzage gegeven wordt en de verantwoordingstermijn. Dit is geen gepland onderdeel van de dienstverlening van Digilevering. De landelijke voorziening zal hier aparte regelingen voor moeten treffen. WOB – Wet Openbaarheid Bestuur Niet relevant. AWB – Algemene Wet Bestuursrecht WEBV – Wet Elektronisch Bestuurlijk Verkeer WEH – Wet Elektronische Handel Deze wetten zijn van toepassing, zonder dat dit leidt tot extra beveiligingsmaatregelen. VIR 2007 – Voorschrift Informatiebeveiliging Rijksoverheid VIR-BI – Voorschrift Informatiebeveiliging Rijksoverheid Bijzondere Informatie Deze voorschriften zijn van toepassing. Toepassing van het NORA-katern Informatiebeveiliging en de noodzaak tot uitvoering van een risicoanalyse sluiten hier goed bij aan. Deze architectuurbeschrijving volgt NORA.

6.3.2 Contractuele eisen Digilevering is een bewerker van informatie van de aangesloten houders landelijke voorzieningen. Contractuele eisen tussen de houder landelijke voorziening en afnemers zijn geen onderdeel van de dienst Digilevering. Houders en afnemers kunnen middels abonnementen en mandaten zelf abonnementen aanvragen en goedkeuren, conform contractuele afspraken. 6.3.3 ISO/IEC 27002 De ISO/IEC 27002 standaard wordt samen met de ISO/IEC 27001 standaard ook wel de “Code voor Informatiebeveiliging” genoemd. Dit document heeft als basis gediend voor NORA en hierin staan algemene beveiligingsmaatregelen beschreven, met overwegingen bij de vertaling naar specifieke maatregelen bij implementatie en uitvoering. In die vorm is het een bruikbaar referentiedocument bij de implementatie en uitvoering van de dienst Digilevering.


87/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

De Code voor Informatiebeveiliging beschrijft in 11 hoofdstukken 133 normen en maatregelen, die van belang zijn voor het realiseren van een afdoende niveau van informatiebeveiliging. Deze standaarden maken deel uit van een brede serie, de ICO/IEC 27000-Series van standaarden over informatiebeveiliging, vergelijkbaar met de ISO 9000 series over kwaliteitsbeheer. Waar relevant zijn in dit hoofdstuk verwijzingen opgenomen naar de ISO/IEC 27001 en 27002. Niet alle informatie uit de ISO/IEC 27002 norm is in scope voor behandeling in deze PSA. Niet alle verwijzingen zijn een complete invulling van het betreffende onderwerp. Geheel niet in scope zijn: • Hoofdstuk 6 Organization of information security: 6.1.4 Authorization process for information processing facilities 6.1.5 Confidentiality agreements 6.1.6 Contact with authorities 6.1.7 Contact with special interest groups • Hoofdstuk 8 Human resources security • Hoofdstuk 9 Physical and environmental security • Hoofdstuk 10 Communications and operations management 10.3 System planning and acceptance 10.9 Electronic commerce services • Hoofdstuk 12 Information systems acquisition, development and maintenance 12.4.2 Protection of system test data 12.4.3 Access control to program source code 12.5 Security in development and support processes • Hoofdstuk 13 Information security incident management • Hoofdstuk 15 Compliance Deze elementen worden beschreven in het IB-plan. 6.3.4 NORA Algemene beveiligingsprincipes Uit het NORA katern: Algemene beveiligingsprincipes zijn principes, die in het algemeen gelden voor organisaties, waarin vertrouwen gesteld moet kunnen worden in het kader van dienstverlening aan burgers, bedrijven en andere overheidsorganisaties.


88/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Hoofdverantwoordelijke (principe 813) Nr

Omschrijving


813.1

De hoogstverantwoordelijke bij de

De serviceorganisatie Digilevering valt onder het

dienstverlener is ook

beheer van Logius. Op de uitvoering van de dienst

verantwoordelijk voor het

Digilevering is het informatiebeveiligingsbeleid van

informatiebeveiligingsbeleid.

Logius van toepassing.

[ISO/IEC 27002: 6.1.3]

Ontwerpkeuzes die tijdens de realisatie gemaakt worden worden door Renoir getoetst op toepasbaarheid, met betrekking van de relevante belanghebbenden.

Afleggen verantwoording (principe 814) Nr

Omschrijving


814.1

Het jaarverslag van de

Renoir levert een werkend systeem op. De

dienstverlener bevat een

ontwerpkeuzes tijdens de realisatie moeten voldoen

verantwoording over het

aan principes 815 en 816. Dit resulteert in een

informatiebeveiligingsbeleid in de

werkend systeem met integrale beveiliging.

vorm van een 'in control statement'.

Continuering van deze werking in productie stelt de

[ISO/IEC 27002: 6.1.8 en ook 5.1.1;

serviceorganisatie Digilevering in staat om

5.1.2; 6.1.1; 6.1.2]

voldoende bewijs te leveren voor de aantoonbaarheid van de werking bij een toetsing voor een 'in control statement'.

Managementsysteem voor informatiebeveiliging (principe 815) Nr

Omschrijving


815.1

Dienstverleners voldoen aan

De PSA is opgesteld volgens de reviewversie van

ISO/IEC 27001 [Code1].

het Katern Informatiebeveiliging in NORA 3.0 en

[ISO/IEC 27002: 6.2.3 en ook 5.1.1;

relevante secties in de ISO/IEC 27002 norm.

5.1.2; 6.2.1; 6.2.2; 10.2; 12.1]

De uitvoerder van de realisatie dient hieraan te voldoen middels het werken volgens hoofdstuk 12 in de ISO/IEC norm 27002 en het Renoir document 'IB-implicaties ontwikkelproces'. Voor additionele informatie, zie de tekst volgend op deze tabel. De uitvoerder van de productie, de serviceorganisatie Digilevering, dient hieraan te voldoen middels het werken volgens het Renoir


89/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Nr

Omschrijving

Toepassing in Digilevering document 'IB-plan Digilevering' en hoofdstuk 11, 13 en 14 in de ISO/IEC norm 27002. Indirect heeft het tot gevolg dat voor de realisatie onder een aantal IB-functies specifieke eisen gesteld zijn.

IB-implicaties ontwikkelproces Om te kunnen garanderen dat informatiebeveiliging binnen Digilevering voldoende is gewaarborgd, dienen deze te kunnen worden gecontroleerd en gevalideerd. Het is aan de ontwikkelende partij om te bepalen hoe dit gebeurt gedurende de realisatie van Digilevering. Indien er gebruik worden gemaakt van een “Secure Development Process” moet dit process zijn beschreven, inclusief de implementatie en borging binnen Digilevering. De opgeleverde applicatie geldt dat deze minimaal moet voldoen aan de OWASP ASVS Level 3 (http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Stan dard_Project ). Aanvullend worden de volgende eisen gesteld aan de ontwikkelende partij: Het ontwikkelteam dient een opleiding te hebben gehad met betrekking tot veilig ontwikkelen van applicaties. Hierin moet minimaal worden behandeld: • De OWASP Top 10 2007, met de meest voorkomende beveiliging zwakheden van software applicaties en hoe deze kunnen worden voorkomen; • De SANS Top 25, de meest gemaakte programmeerfouten en hoe deze te voorkomen; • Secure development principles zoals de CLASP Core Principles (http://www.owasp.org/index.php/CLASP_Security_Principles). • De voor het ontwikkelen van het op Digilevering toegepaste Secure Development Proces. Binnen de opgeleverde documentatie door de ontwikkelaars moeten de keuzes en de implementatie met betrekking tot applicatie beveiliging en het implementeren van de technische maatregelen voor informatiebeveiliging expliciet worden beschreven. Bij elke release van Digilevering moet het volgende worden opgeleverd: • Een rapport van de uitgevoerde Static Code Analyse (SCA). Hier moeten alle bevindingen in worden genoemd, inclusief de relevantie en gekozen oplossing; • Een rapport van een White Box penetratietest op een productiegelijke omgeving. Binnen deze test is zowel de functionele als de technische beveiliging en


90/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

configuratie is gevalideerd. De dekking van de uitgevoerde test moet zijn vermeld evenals de gebruikte scripts. Baseline (principe 816) Nr

Omschrijving


816.1

De baseline beveiliging is gebaseerd De baseline informatiebeveiliging dient voor de op standaarden en best practices, in dienst Digilevering specifiek opgezet te worden. het bijzonder ISO/IEC 27002

Hiertoe is een risicoanalyse uitgevoerd. Voor de

[Code2].

realisatie betekent dit dat voor principes 819 t/m

[ISO/IEC 27002: 4.2]

827 op bepaalde onderwerpen ruime kaders bestaan en dat maatregelen specifiek ontworpen en afgestemd dienen te worden. Bij maatregelen die als baseline-maatregelen aangemerkt zouden kunnen worden is de markering [BASELINE] toegevoegd, met verwijzing naar de ISO/IEC 27002 norm.

Treffen maatregelen (principe 817) Nr

Omschrijving


817.1

Maatregelen voor

Er is geen baseline van toepassing verklaard op de

informatiebeveiliging worden

dienst Digilevering. Voor de realisatie betekent dit

getroffen op basis van de interne

dat het voldoen aan principe 816 ook voldoende is

baseline, aangevuld met een

voor principe 817.

risicoanalyse in afwijkende situaties. [ISO/IEC 27002: 4.1]

Verantwoordelijken informatiesystemen (principe 818) Nr

Omschrijving


818.1

Lijnmanagers zijn verantwoordelijk

Lijnmanagers wordt in de context van Digilevering

voor de beveiliging van

ingevuld als operationeel uitvoerende managers

informatiesystemen.

binnen de service organisatie Digilevering en de

[ISO/IEC 27002: 6.1.3 en ook 7.1;

aangesloten partijen (landelijke voorzieningen en

7.2]

afnemers). De verdeling van die verantwoordelijkheden tussen deze partijen wordt apart gedocumenteerd in een RACI document.


91/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

6.3.5 NORA-principes ICT-voorzieningen In dit hoofdstuk zijn de ICT-principes, zoals vermeld in NORA, opgesomd en aangevuld met de invulling die er binnen Digilevering aan gegeven is. De principes, behalve die gaan over geprogrammeerde controles, hebben betrekking op de instelmogelijkheden van algemeen, op de markt verkrijgbare, ICT-componenten. Continuïteitsvoorzieningen (principe 819) De ICT-voorzieningen voldoen aan het voor de diensten overeengekomen niveau van beschikbaarheid. Nr

Omschrijving


819.1

Door dubbele uitvoering van ICT-

[BASELINE]

voorzieningen of onderdelen

De volgende componenten binnen de infrastructuur

daarvan worden single points of

zijn dubbel uitgevoerd:

failure vermeden.

•

[ISO/IEC 27002: 14]

Externe netwerkverbindingen, zowel voor de internet als de KPS verbinding;

•

Externe Firewall;

•

Load Balancer en SSL-Offloader;

•

Storage Arean Network (SAN).

Een aantal componenten zijn niet dubbel uitgevoerd, maar hebben wel de eis dat deze eenvoudig moeten kunnen worden opgenomen in een clusterconfiguratie, ten behoeve van de beschikbaarheid en schaalbaarheid. Dit betreffen: •

De webserver;

•

De applicatieserver; De Databaseserver.

Zie verder paragraaf 5.6 van de PSA.


92/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Nr

Omschrijving


819.2

Verwerkingen zijn herstelbaar.

Communicatie:

[ISO/IEC 27002: 14]

Voor het ontvangen van versturen van gebeurtenissen maakt Digilevering gebruik van eBMS, wat onderdeel is van de OSB 2.0 standaard. Onderdeel van eBMS is dat een instelbaar aantal pogingen wordt ondernomen om een gebeurtenis af te leveren. Mocht het na deze pogingen nog niet gelukt zijn om de gebeurtenis af te leveren dan is er een handmatige actie nodig om het proces opnieuw te starten. Bewerking: [BASELINE] Het verwerken van gebeurtenissen binnen Digilevering zelf voldoet aan de ACID principes24. Kort gezegd komt dit erop neer dat transacties volledig en onomkeerbaar worden uitgevoerd of in zijn geheel niet. Het is mogelijk dat er een component binnen Digilevering uitvalt waardoor de verwerking van gebeurtenissen stil komt te liggen. Hier wordt de beheerder automatisch van de op hoogte gesteld. In geen geval mogen er gebeurtenissen verloren gaan. Zie paragraaf 5.4.3 en verder van de PSA

819.3

ICT-voorzieningen anticiperen op

[BASELINE]

dreigende discontinuïteit van die

Er moeten backups gemaakt kunnen worden via

voorzieningen.

een gestructureerd backupplan van dagelijkse

[ISO/IEC 27002: 10.5; 14]

backups. Tijdens de backup zijn de systeemonderdelen gebeurtenisverwerking en beheerobjectlijsten beschikbaar zijn. Het maken van een backup duurt maximaal 8 uur. Aanvullende maatregelen zorgen dat bij discontinuïteit de data die gewijzigd is sinds de backup ook beschikbaar is.

24

Reuter, Andreas; Haerder, Theo (December 1983). "Principles of Transaction-Oriented Database

Recovery". ACM Computing Surveys 15 (4): 287–317.


93/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Nr

Omschrijving

Toepassing in Digilevering Het moet mogelijk zijn om zowel een gehele als een partiële restore uit te voeren van systeemonderdelen of individuele bestanden als een structurele activiteit binnen een tijdvak van maximaal 4 uur onbeschikbaarheid van de dienst. Het moet mogelijk zijn om op een gestopt systeem een partiële restore of een volledige restore van de meest recente backup uit te voeren zonder verlies aan data. Het moet mogelijk zijn om op een gestopt systeem een partiële restore of een volledige restore uit te voeren naar een beschikbare oudere backup. Voor calamiteiten dient een uitwijksysteem op een uitwijklocatie beschikbaar gemaakt worden. Wanneer uitgeweken wordt, dient de uitwijk in 24 uur operationeel te zijn (RTO = 24 uur), zonder verlies aan data (RPO = 0).

Geprogrammeerde controles (principe 820) In toepassingsprogrammatuur worden geprogrammeerde controles opgenomen, gericht op invoer, verwerking en uitvoer. Nr

Omschrijving


820.1

Niemand in een organisatie of

[BASELINE]

proces mag op uitvoerend niveau in

Autorisaties zijn regelbaar conform de RACI matrix

staat worden gesteld om een gehele van Digilevering [@@ref RACI document@@]. cyclus van handelingen te

Elke functie in het systeem wordt aan een

beheersen.

functiespecifieke autorisatiecontrole onderworpen.

[ISO/IEC 27002: 12.2]

Functie-autorisaties kunnen functioneel of middels configuratie gegroepeerd worden in autorisatierollen of -groepen. De autorisatierollen of -groepen kunnen functioneel toegewezen worden aan gebruikers. Elke functie ter uitvoering door een houder landelijke voorziening of afnemer (organisatie) wordt aan een data-autorisatiecontrole onderworpen, waarbij de gebruiker en de data aan dezelfde organisatie geassocieerd moeten zijn.


94/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Nr

Omschrijving

Toepassing in Digilevering Organisaties worden functioneel of contextueel toegewezen aan gebruikers of data bij toevoeging. Functionele toewijzing van organisatie is alleen mogelijk door een geautoriseerde beheerder van de serviceorganisatie. Er zijn geen specifieke noodzaak tot geprogrammeerde controle op functiescheiding geïdentificeerd in de beschreven functionaliteit. Mogelijk dat additionele functionaliteit die in de ontwerpen geïntroduceerd wordt wel een noodzaak heeft tot functiescheiding, zoals autorisatiebeheerprocessen.

820.2

Alle ingevoerde gegevens vanuit

[BASELINE]

een systeemvreemde omgeving

Binnen de presentatielaag van de applicatie wordt

worden op juistheid, tijdigheid en

er op input gevalideerd, zie paragraaf 5.5. binnen

volledigheid gecontroleerd voordat

de PSA. Input validatie bestaat uit de volgende

verdere verwerking plaatsvindt.

onderdelen:

[ISO/IEC 27002: 12.2]

•

Gebruiker is aangemeld en aanmelding is nog geldig;

•

Gebruiker is geautoriseerd tot het leveren van de aangeboden invoer;

•

Invoer wordt slechts eenmaal verwerkt, ook al wordt het meermaals aangeboden (bestand tegen 'replay attack');

•

Invoer is gecontroleerd op het juiste formaat (syntax), (met name bestand tegen 'SQL-injection attack').

Semantische validaties in de context van de transactie worden in de business laag uitgevoerd; de business laag controleert of de betekenis van de ingevulde waardes correct is. Zie ook principe 815. 820.3

Toepassingen bieden mogelijkheden [BASELINE] om te constateren dat alle ter

Verwerkingen van gebeurtenissen worden geheel

verwerking aangeboden invoer juist, of geheel niet uitgevoerd en hebben geen invloed volledig en tijdig is verwerkt.

op elkaar. Zie eis 819.2.

[ISO/IEC 27002: 12.2]

Additioneel dient het ontwerp middels tellingen of soortgelijke mechanismen ervoor te zorgen dat er


95/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Nr

Omschrijving

Toepassing in Digilevering verantwoording kan worden afgelegd over de correcte verwerking per component. Bijvoorbeeld in een bepaald tijdvak dient het totaal aan gecreëerde berichten gelijk te zijn aan de som van berichten verstuurd aan alle afnemers.

820.5

In applicaties zijn geen functies

Voor berichtuitwisseling wordt er gebruik gemaakt

opgenomen, waarvoor kwalitatief

van de OSB 2.0 standaard. OSB vereist het gebruik

betere generieke voorzieningen

van certificaten om diverse partijen te identificeren.

beschikbaar zijn, zoals die voor

Binnen Digilevering wordt er gebruik gemaakt van

identificatie, authenticatie,

TLS met PKI.Overheid certificaten.

autorisatie, onweerlegbaarheid en

Zie PSA paragraaf 5.1, NORA eis 7.3.1.

encryptie. [ISO/IEC 27002: 12.2]

Digilevering gebruikt gebruikerscode/wachtwoord als authenticatiemiddel, op basis van exclusiviteitswaardering niveau 1. Deze component hoort vervangbaar te zijn door een component met een sterker authenticatiemiddel middels configuratieaanpassing van de component, dus zonder geprogrammeerde aanpassing in de aanroep van de component. Digilevering specificeert het gebruik van een transactieverwerkende database. Deze dient middels een generiek database product gerealiseerd te worden.

Zonering (principe 821) ICT-voorzieningen zijn in zones ingedeeld. Nr

Omschrijving


821.1

De indeling van zones binnen de

De zonering van de technische infrastructuur wordt

technische infrastructuur vindt plaats besproken in paragraaf 5.6 van de PSA. volgens een operationeel

Hiernaast is er een functionele scheiding tussen

beleidsdocument waarin is

een Business to Business (B2B) laag en een

vastgelegd welke uitgangspunten

Human to Business laag (H2B). Zie hiervoor PSA

voor zonering worden gehanteerd.

paragraaf 5.2.

[ISO/IEC 27002: 10.6] 821.2

Zones zijn als eenheid van

Binnen Digilevering worden de volgende zones


96/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Nr

Omschrijving


beveiliging en beheer gedefinieerd.

onderkent:

[ISO/IEC 27002: 10.6]

•

Gekoppelde partij; een landelijke voorziening of afnemer. Zie PSA paragraaf 2.3.

•

Digilevering: het Portaal of de Core. Zie PSA paragraaf 5.2.

•

Het transportnetwerk (Hierbij wordt voor Digilevering geen onderscheid gemaakt tussen KPS of het internet). Zie paragraaf 5.6.

821.3

De communicatie en de opslag van

Communicatie:

gegevens die buiten de

Alle gegevens worden van en naar Digilevering

invloedssfeer van de logische en

versleuteld verzonden met TLS op basis van

fysieke toegangsbeveiliging vallen of PKI.overheid certificaten aan beide zijden, zie waarvoor deze maatregelen

paragraaf 5.3.4 en 5.4.5 van de PSA.

onvoldoende zijn, zijn door encryptie Opslag: beschermd.

Alle gegevens worden binnen Digilevering

[ISO/IEC 27002: 10.6; 11; 12.3;

versleuteld opgeslagen op het bronsysteem, zie paragraaf 5.3.4 van de PSA.

821.4

De sterkte van de

[BASELINE]

encryptiemechanismen voldoet aan

Er wordt uitsluitend gebruik gemaakt van

eisen van de tijd.

encryptiemechanismen die op dit moment veilig

[ISO/IEC 27002: 12.3.1]

worden geacht door GOVCERT.nl voor publiekelijk gebruik. De implementatie van deze mechanismen is zo gedaan dat het eenvoudig is additionele encryptiemechanismen te implementeren. Voor het eBMS berichtenverkeer wordt er voldaan aan de eisen van de Koppelvlakstandaard eBMS [6].

821.5

De vertrouwelijkheid en integriteit

Communicatie:

van geheime cryptografische

Conform de eisen van PKI.Overheid worden

sleutels is gewaarborgd tijdens het

geheime cryptografische sleutels geleverd en

gehele proces van generatie,

geïnstalleerd middels PKCS#11 interface formaat.

transport en opslag van de sleutels.

Opslag en bewerking op EAL4 gecertificeerde

[ISO/IEC 27002: 12.3.2]

hardware/software of beter25. Algemeen: [BASELINE]

25

http://www.pkioverheid.nl/voor-certificaatverleners/programma-van-eisen/


97/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Nr

Omschrijving

Toepassing in Digilevering Een effectief beheersproces van cryptografische sleutels voor de versleutelde opslag van gegevens is onderdeel van de realisatie. De aanpak van het sleutelbeheer bevat: •

de aanmaak van cryptografische sleutels

•

de methodes voor beveiliging van de sleutels en het herstel van versleutelde informatie in het geval de sleutel verloren is, bekend is geworden of beschadigd is geraakt.

Filtering (principe 822) Op het koppelvlak tussen zones zijn filterfuncties gepositioneerd voor het gecontroleerd doorlaten van gegevens. Nr

Omschrijving


822.1

In koppelpunten met externe of

Er worden alleen verbindingen geaccepteerd vanaf

onvertrouwde zones worden

vooraf geconfigureerde netwerkadressen en een

maatregelen getroffen om aanvallen vooraf bepaalde netwerkpoort. Zie PSA paragraaf te signaleren en te kunnen

5.3.4 en paragraaf 5.4.5.

blokkeren de erop gericht zij de

Tevens wordt voor het gebruik van het portaal een

verwerkingscapaciteit zodanig te

gebruikerscode en wachtwoord vereist en voor het

laten vollopen, dat onbereikbaarheid gebruik van de Core functionaliteit een passend

822.2

of uitval van de computers het

OIN.

gevolg is

Zie ook implicaties 825.1..3 en paragraaf 5.4.4 van

[ISO/IEC 27002: 10.6.2]

het PSA

Al het gegevensverkeer vanuit

Alleen connecties via poort 443 worden toegestaan.

externe of onvertrouwde zones

Misbruik van poort 443 wordt middels intrusion

wordt real-time inhoudelijk

detection/prevention techniek tegengegaan.

geïnspecteerd op inbraakpogingen.

Ontvangen gebeurtenissen mogen alleen uit XML-

Een update van de aanvalspatronen code bestaan en worden alleen verwerkt als het vind frequent geautomatiseerd

bericht op de juiste manier geformatteerd is en

plaats

gevalideerd is.

[ISO/IEC 27002: 10.6.2]

Input validatie wordt uitgevoerd op bericht niveau (grootte bericht en inhoud) en middels het monitoren van in- en uitgaand berichtenverkeer. Monitoren van in en uitgaande verkeer op netwerk (TCP/IP) niveau door middels van IDS/IPS


98/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Nr

Omschrijving

Toepassing in Digilevering (Intrusion detection/prevention system) Zie ook PSA paragraaf 5.3.4 en paragraaf 5.4.5. Zie ook implicaties 825.1..3

822.8

Alle PC-servers worden periodiek

[BASELINE]

geautomatiseerd gecontroleerd op

Alle IT-servers worden periodiek geautomatiseerd

virussen, nadat een update van de

gecontroleerd op kwaadaardige software (virussen,

virusdefinities en/of

wormen, trojaanse paarden, ...), nadat een update

antivirusprogrammatuur

van de virusdefinities en/of antivirusprogrammatuur

geautomatiseerd plaats heeft

geautomatiseerd heeft plaatsgevonden. De controle

gevonden. De controle moet op

moet op ieder gewenst tijdstip ook handmatig

ieder gewenst tijdstip ook handmatig gestart kunnen worden. gestart kunnen worden.

Bij detectie van kwaadaardige software dienen de

[ISO/IEC 27002: 10.4]

beheerders gealarmeerd te worden. Correctie mag pas na expliciet goedkeuren van beheerders uitgevoerd worden. Het moet mogelijk zijn alarmering op specifieke detecties tijdelijk uit te zetten. NORA implicaties voor antivirusscanning en spamfiltering van emailverkeer zijn niet van toepassing binnen Digilevering.

Bewijsbaarheid berichtuitwisseling (principe 823) Bij berichtuitwisseling wordt de bewijsbaarheid van verzending en ontvangst geborgd. Nr

Omschrijving


823.1

Bij berichtuitwisseling waaruit

Voor berichten uitwisseling wordt er gebruik

rechten en plichten ontstaan tussen

gemaakt van eBMS. EBMS is onderdeel van de

partijen bestaat de zekerheid dat het OSB 2.0 standaard en maakt altijd gebruik van ontvangen bericht afkomstig is van

TLS.

de verzender en dat de inhoud niet

Zie paragraaf 4.4.2 van de PSA voor meer

door derden is beïnvloed.

informatie over het gebruik van OSB 2.0.

[ISO/IEC 27002: 10.8.2] 823.2

Bij berichtuitwisseling waaruit

Om berichtaflevering te garanderen wordt er

rechten en plichten ontstaan tussen

gebruik gemaakt van eBMS, wat onderdeel van de

partijen kan de ontvanger van het

OSB 2.0 standaard is. EBMS vereist het gebruik

bericht niet ontkennen het bericht te

van bilaterale TLS authenticatie, waardoor het voor

hebben ontvangen van de afzender

de verzendende partij niet mogelijk is te ontkennen

[ISO/IEC 27002: 10.8.2]

dat een gebeurtenis verstuurd is.


99/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Nr

Omschrijving

Toepassing in Digilevering TLS authenticatie vind plaats op basis van PKI.Overheid certificaten, waarmee digitale handtekeningen worden gezet. Daarnaast is binnen eBMS een transactie alleen afgerond als de verzendende partij een bevestiging (“acknowledgement”) heeft ontvangen van de ontvangende partij. [6]

823.3

De beschikbaarheid van bewijs is

De termijn van dit bewijs kan per landelijke

gewaarborgd binnen de termijn

voorziening verschillen. Hierom moet het voor de

waarin de aantoonbaarheid van dat

systeemeigenaar mogelijk zijn per landelijke

bewijs noodzakelijk wordt geacht

voorziening de termijn voor het bewaren dit bewijs

door de systeemeigenaar.

instelbaar is.

[ISO/IEC 27002: 10.8.2]

Op basis van het juridisch rapport is minstens instelbaarheid in dagen van 180 t/m 365 dagen nodig. Gewenst is instelbaarheid in de reeks 1..999 dagen. Na afloop van de bewaartermijn dienen bewijzen automatisch gewist te worden.

Identificatie, authenticatie en autorisatie (principe 824) Vóór het gebruiken van ICT-voorzieningen vindt logische toegangscontrole plaats. Nr

Omschrijving


824.1

Alle toegangsvragers tot een geheel Portaal: van ICT-voorzieningen zijn uniek

Toegang wordt alleen verstrekt aan bekende IP-

herleidbaar tot één natuurlijk

adressen met een geldige gebruikerscode en

persoon, organisatie of ICT-

wachtwoord combinatie. Per aangesloten partij

voorziening.

(landelijke voorziening / afnemer) kunnen

[ISO/IEC 27002: 11]

gebruikerscodes in eigen beheer worden aangemaakt, aangepast en verwijderd. Een aangesloten partij ontvangt bij aansluiting een initiële gebruikerscode met wachtwoord met beheersrechten voor eigen beheer. Core: Toegang wordt alleen verstrekt aan bekende IPadressen met een certificaat met overeenkomend OIN.


100/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Nr

Omschrijving

Toepassing in Digilevering Zie paragraaf 5.4.3 en 5.4.5 van het PSA.

824.2

Alvorens een systeem toegang

Portaal:

verleent, wordt de authenticiteit van

Het systeem verleend de een gebruiker toegang na

de gebruiker vastgesteld op basis

identificatie en authenticatie op basis van een

van de identificatie.

gebruikersnaam en wachtwoord. Zie paragraaf

[ISO/IEC 27002: 11]

5.3.4 van de PSA Core: Het Core-component binnen Digilevering verleend alleen toegang als er een succesvolle bilaterale TLS identificatie en authenticatie wordt doorlopen op basis van PKI.Overheid certificaten. Zie paragraaf 5.4.5 van de PSA.

824.3

Het systeem dwingt het gebruik van

[BASELINE]

sterke wachtwoorden af.

In 820.5 is al aangegeven dat het gebruik van

[ISO/IEC 27002: 11]

gebruikerscodes/wachtwoorden in Digilevering modulair aanpasbaar dient te zijn. Deze eis is op deze module van toepassing. In het ontwerp dient aangegeven te worden in hoeverre de wachtwoorden voldoen aan NIST SP 800-6326 en Microsoft Technet Strong Passwords specificatie27.

824.4

Instellingen met betrekking tot het

[BASELINE]

aanmelden op een systeem zijn erop Van de volgende maatregelen wordt gebruik gericht te voorkomen dat iemand

gemaakt om te voorkomen dat een gebruiker onder

werkt onder een andere dan de

een andere gebruikersnaam werkt dan zijn eigen:

eigen gebruikersnaam.

•

[ISO/IEC 27002: 11]

Er wordt voorkomen dat gebruiker zich meerdere malen moeten aanmelden voor verschillende systemen

•

Na 3 mislukte inlogpogingen wordt het account geblokkeerd

•

Wachtwoorden worden versleuteld over het netwerk verzonden

•

Het wachtwoord wordt niet in het invulveld getoond (er verschijnen sterretjes)

824.5 26 27

Op alle ICT-voorzieningen is

[BASELINE]

http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf http://technet.microsoft.com/en-us/library/cc756109(WS.10).aspx


101/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Nr

Omschrijving


toegangsbeveiliging van toepassing

Alle acties waartoe een gebruiker bevoegd is

op basis van: “Niets mag, tenzij dit is moeten expliciet toekenbaar zijn in de toegestaan”.

autorisatieconfiguratie.

[ISO/IEC 27002: 11]

Acties waar een gebruiker niet toe is bevoegd worden niet getoond in de voor hem beschikbare interfaces.

824.6

Er zijn maatregelen getroffen die

[BASELINE]

onbedoeld gebruik van toegekende

Het is niet mogelijk rechten van een actieve

autorisaties voorkomen.

gebruiker over te nemen, middels b.v. 'session

[ISO/IEC 27002: 11]

hijacking'. Het ontwerp dient aan te geven hoe hiertegen beschermd wordt. Dit dient expliciet goedgekeurd te worden en in test gedemonstreerd te worden. Er is een geautomatiseerd proces in werking dat sessies van een gebruiker beëindigt na verloop van een configureerbare periode (1..60 minuten) van inactiviteit.

824.7

Handelingen worden uitgevoerd met [BASELINE] zo weinig mogelijk rechten.

Het systeem of de gebruiker krijgt alleen die

[ISO/IEC 27002: 11]

rechten toegewezen die noodzakelijk zijn voor het uitvoeren van haar taak. In de basis moeten gebruikersrechten apart instelbaar zijn per transactie. (zie ook eis 824.5 en 824.8.).

824.8

Verleende toegangsrechten zijn

[BASELINE]

inzichtelijk en beheersbaar.

Autorisaties zijn regelbaar conform de RACI matrix

[ISO/IEC 27002: 11]

van Digilevering [@@ref RACI document@@], zowel functioneel als per informatiedomein. Een externe partij kan alleen toegang tot eigen functionaliteit en informatie regelen in de autorisatieconfiguratie. De autorisatieconfiguratie functies geven een transparant overzicht van toegekende rechten per gebruiker en de mogelijke modificaties. Het is mogelijk rapportages te verkrijgen van:

• •

Ontvangen mandaten; de gebruikers onder een specifieke gebruikersbeheerder;


102/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Nr

Omschrijving


• •

Ontvangen gebeurtenissen; Verstrekte gebeurtenissen.

Vastleggen van gebeurtenissen (principe 825) Handelingen in en meldingen van ICT-voorzieningen in de technische infrastructuur worden vastgelegd in logging. Nr

Omschrijving


825.1

In de logging wordt informatie

Hierop zijn de eisen uit het Logius IB-plan van

vastgelegd waarmee

toepassing. De relevante passage hieruit is

reproduceerbaar is wie waar en

opgenomen volgend aan deze tabel. In toevoeging

wanneer welke cruciale handelingen hierop gelden voor Digilevering de volgende eisen: heeft verricht.

Bij de volgende acties wordt er een beschrijvende

[ISO/IEC 27002: 10.10]

regel opgenomen in logbestanden: •

Het aanmaken, wijzigen of verwijderen van instellingen op server- en applicatieniveau;

•

Het gebruik van de beheerinterface en gebruikeracties op de systemen;

•

Het ontvangen of versturen van berichten.

Logregels zijn tenminste voorzien van een unieke identificatie (soort transactie en onderwerp – wat), een datum en tijdstip (wanneer) en een onweerlegbare relatie met de uitvoerende partij (wie). 825.2

De integriteit van opgeslagen

Hierop zijn de eisen uit het Logius IB-plan van

logbestanden is gewaarborgd.

toepassing. De relevante passage hieruit is

[ISO/IEC 27002: 10.10]

opgenomen volgend aan deze tabel. In toevoeging hierop gelden voor Digilevering de volgende eisen: Logregels binnen een logbestand zijn opvolgend genummerd, zodat het herkenbaar is als er logregels verwijderd zijn. Logs worden dagelijks op een configureerbaar tijdstip afgesloten, bij afsluiting wordt een hash gemaakt waarmee de integriteit van het logbestand aangetoond kan worden.

825.3

De beschikbaarheid van

In afwijking van regel 18 uit het Logius IB-plan

loginformatie is gewaarborgd binnen geldt: de termijn waarin loganalyse

De termijn van dit bewijs verschilt per landelijke

noodzakelijk wordt geacht.

voorziening, zie ook eis 823.3. Logs worden dus


103/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Nr

Omschrijving


[ISO/IEC 27002: 10.10]

weggeschreven per landelijke voorziening, aangevuld door een systeemlog voor activiteiten die niet gebonden zijn aan een landelijke voorziening. Het ontwerp dient voor realisatie expliciet getoetst te worden door ICTU op juiste adressering van deze implicatie.

In het Informatiebeveiligingsplan van Logius (v 0.92 dd. 7-8-2008, §2.7, bullets 15 t/m 19) staan de volgende eisen opgenomen m.b.t. Logging [BASELINE]: (15) De volgende gebeurtenissen worden minimaal vastgelegd: • geautoriseerde toegang; • handelingen met speciale bevoegdheden (zoals root toegang); • opstarten en afsluiten van het systeem; • pogingen tot ongeautoriseerde toegang: • mislukte of geweigerde gebruikersacties • overtredingen van het toegangsbeleid • meldingen aan netwerkcomponenten en firewalls • alarmeringen voor het opsporen van inbraak (IDS, honeypots); • systeemwaarschuwingen of –fouten; • veranderingen van of pogingen tot verandering van de systeembeveiligingsinstellingen; • veranderingen in log-instelingen, wissen van logbestanden en vollopen van logbestanden (16) Van de gelogde gebeurtenissen wordt minimaal vastgelegd: • het tijdstip waarop een gebeurtenis (succesvol of storing) is opgetreden; • informatie over de gebeurtenis (bijvoorbeeld de bestanden die zijn behandeld) of storing (bijvoorbeeld fout opgetreden en corrigerende handeling uitgevoerd); • welke account en welke beheerder of operator erbij was betrokken; • welke processen erbij waren betrokken; • welk IP-adres, poort en bronsysteem erbij waren betrokken. (17) Gegevens die uit logfiles voortkomen kunnen op elk gegeven moment in bewaring genomen worden indien daar aanleiding toe is voor onder meer forensische activiteiten, controle en interne beheersingsdoeleinden.


104/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

(18) De gegevens uit de logging worden gearchiveerd voor een termijn die vastgesteld is op jaar. Binnen deze vastgestelde termijn zijn de gegevens toegankelijk en benaderbaar.28 (19) Log-events worden weggeschreven op een aparte logserver. Deze logserver is alleen toegankelijk voor medewerkers met een controletaak en niet voor de beheerders van de infrastructuur die onderwerp is van de logging. Voor het verwijderen van de loggings (na de gestelde bewaartermijn) zijn twee personen noodzakelijk. De inhoud van de logserver wordt meegenomen in het back-up proces. Controle, alarmering en rapportering (principe 826) In de technische infrastructuur zijn signaleringsfuncties werkzaam ter controle op operationeel beveiligingsbeleid. Nr

Omschrijving


826.1

Instellingen van functies die voor de

Binnen Digilevering worden er geen automatische

informatiebeveiliging van belang zijn controles uitgevoerd. Om een procedurele controle en wijzigingen daarin worden

mogelijk te maken moet de volgende informatie

automatisch gecontroleerd.

inzichtelijk gemaakt kunnen worden per

[ISO/IEC 27002: 10.10]

aangesloten partij (landelijke voorziening of afnemer):

826.2

•

Overzicht van uitgedeelde autorisaties;

•

Overzicht log instellingen;

•

Overzicht alarmeringsinstellingen;

Tevoren gespecificeerde afwijkende

[BASELINE]

gebeurtenissen volgens de

Het is mogelijk logregels te laten signaleren, d.w.z.

loginformatie worden tijdig

verschijnen op een centraal bewakingsdashboard.

gesignaleerd en zo nodig

Het is mogelijk gesignaleerde logregels naar

gealarmeerd.

alarmstatus te brengen, d.w.z. email uitsturen en/of

[ISO/IEC 27002: 10.10]

SMS sturen vaan de beheerder(s). Per type logregel dient signalering en alarmering middels configuratie of functioneel ingesteld te kunnen worden.

826.3

Logbestanden worden periodiek

[BASELINE]

geanalyseerd en gecorreleerd ten

Middels bijgeleverde programmatuur kunnen

einde beveiligingsincidenten dan wel logbestanden geanalyseerd worden. de juiste werking van het systeem te De volgende informatie moet inzichtelijk gemaakt detecteren. [ISO/IEC 27002: 10.10] 28

kunnen worden: •

Het maken/breken van een connectie met

Deze eis is niet van toepassing op Digilevering, vanwege specifieke inperking uit de Juridische scan.


105/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Nr

Omschrijving

Toepassing in Digilevering een gekoppeld systeem (succesvol en niet succesvol); •

Het aan- en afloggen van gebruikers (succesvol en niet succesvol);

•

Alle core activiteit m.b.t. één gekoppeld systeem;

•

Alle portaalactiviteit m.b.t. gebruikers van één organisatie;

•

Alle activiteit in een gegeven tijdvak, tot op de seconde bepaald.

Systeemintegriteit (principe 827) In de technische infrastructuur zijn functies werkzaam, die de systeemintegriteit ondersteunen. Nr

Omschrijving


827.1

De instellingen (parametrisering) van [BASELINE] de programmatuur doorbreken –

De instellingen van de componenten van de

voor zover ze niet bepaald zijn door

technische infrastructuur dienen in

de andere principes - de

overeenstemming te zijn met de operationele

beschikbaarheid, integriteit,

productstandaards van de bij voorkeur

vertrouwelijkheid en

onafhankelijke instellingen, zoals die van NIST,

controleerbaarheid niet.

voor zover de instellingen niet door andere IB-

[ISO/IEC 27002: 12.4.1 en ook 10.1; functies van dit document zijn geadresseerd. 10.7; 10.8]

Digilevering geeft geen informatie prijs die niet noodzakelijk is voor het uitvoeren van de gevraagde functionaliteit. Denk hier bijvoorbeeld aan configuratiebestanden.

827.2

Programmatuurpakketten zijn

[BASELINE]

ingesteld volgens de aanwijzingen

De integriteit van programmatuur en instellingen

van de leverancier.

kan op ieder gewenst moment gecontroleerd

[ISO/IEC 27002: 12.4.1; 12.6.1 en

worden, bijvoorbeeld d.m.v. een hashcontrole of

ook 10.1; 10.7; 10.8]

een andere procedurele controle. Systemen zijn geconfigureerd om beheerst updates van de leverancier (patches) aan te kunnen brengen. Beheerders moeten binnen een dag gesignaleerd worden op het voorkomen van bekende zwakheden in de configuratie en/of het


106/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Nr

Omschrijving

Toepassing in Digilevering beschikbaar zijn van nieuwe kritieke updates. Beheerders moeten updates specifiek vrij kunnen geven voor automatische installatie op een configureerbaar tijdstip. Zie ook implicatie 826.1.

827.3

Als gebruik van ‘mobile code’ is

[BASELINE]

toegelaten, zorgt de configuratie

Digilevering is een web-based dienst en geen

ervoor dat de geautoriseerde ‘mobile client-server dienst, zeker niet met een 'heavy' code’ functioneert volgens een

client.

duidelijk vastgesteld

Onder het gebruik van 'mobile code' vallen

beveiligingsbeleid en voorkomt de

mechanismen die de uitvoering van code afkomstig

configuratie dat onbevoegde ‘mobile van een ander systeem dan het systeem waar de code’ wordt uitgevoerd.

code uitgevoerd wordt. Java, ActiveX en scripting

[ISO/IEC 27002: 10.4.2]

zijn voorbeelden van zulke mechanismen. Digilevering mag geen mobile code afkomstig van een bron buiten Digilevering accepteren. In het berichtverkeer tussen Digilevering en de afnemer of landelijke voorziening mag geen mobile code worden gebruikt.

827.4

De technische infrastructuur is

[BASELINE]

zodanig ontworpen en ingericht, dat

Foutbestanden worden niet gebruikt als (tijdelijke)

foutsituaties worden voorkomen of

opslagruimte.

herkend en dat functioneel beheer

Het doorwerken van fouten (fout op fout) wordt

over foutbestanden mogelijk is.

voorkomen door toepassing van automatische

[ISO/IEC 27002: 12.5 en ook 10.1]

'noodstop' mechanismen. Alle infrastructuur componenten van Digilevering moeten volledig en eenduidig worden gemonitord. Problemen of het mogelijk optreden van problemen moet tijdig en geautomatiseerd worden gesignaleerd. Hierbij moet er gedacht worden aan het vollopen van een harde schijf, het niet kunnen versturen van een gebeurtenis of het hoop oplopen van de belasting van de CPU. Drempelwaarden voor alarmering moet instelbaar zijn.

827.5

Bij batchverwerking borgen de

Digilevering maakt gebruik van de OSB 2.0

generieke productieplannings- en/of

standaard. Deze standaard voorziet in het


107/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Nr

Omschrijving


bewakingssystemen dat

“ontdubbelen” van berichten. Zie paragraaf 4.4.2

invoerbestanden niet of dubbel

van de PSA.

worden verwerkt, dat uitvoerbestanden niet of dubbel worden verzonden en dat onderlinge afhankelijkheid van de verwerkingen niet wordt doorbroken. [ISO/IEC 27002: 12.2 en ook 10.1; 10.7; 10.8]


108/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Bijlage 1: Bronnen

Nr

Bron

[1]

Startarchitectuur GOB, programma ODP, versie 1.0, 22 september 2008.

[2]

Inventarisatie bestaande Abonnementsystematieken, programma ODP, versie 0.3, 31 maart 2009

[3]

Definitiestudie Abonnementenvoorziening GOB, programma ODP, versie 1.0, 9 april 2009

[4]

Voorschrift Informatiebeveiliging Rijksdienst

[5]

Functioneel Ontwerp Stelselcatalogus, BeInformed, versie 1.1, 18 december 2008

[6]

OSB 2.0 Koppelvlakstandaard ebMS, versie 1.0, maart 2009.

[7]

NORA (Nederlandse Overheids Referentie Architectuur), versie 2.0, Kenniscentrum, april 2007.

[8]

NORA Katern Informatiebeveiliging, versie 1.0, 01-10-2009.

[9]

Juridische randvoorwaarden Digilevering, 28 oktober 2009.

[10]

Nationaal Uitvoeringsprogramma dienstverlening en e-overheid, versie 2.0

[11]

OSB Architectuur, versie 1.0, 5 juni 2008


109/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Bijlage 2: Begrippenlijst

Begrip

Omschrijving

Afnemer

Publieke organisatie of private organisatie die voor het uitoefenen van een publieke taak gebruik maakt van gegevens uit een basisregistratie. Bron: SBG

Basisregistratie

Verzameling gegevens waarvan bij wet is bepaald dat deze een basisregistratie vormen. Bron:(o.a.) Wet basisregistratie adressen en gebouwen. Toelichting: Een basisregistratie is een kwalitatief hoogwaardig en met expliciete garanties voor de borging van die kwaliteit omkleed bestand van, gezien het geheel van wettelijke taken, vitale en/of veelvuldig en om uiteenlopende redenen benodigde gegevens over personen, instellingen, zaken, verrichtingen of gebeurtenissen, die bij wet als de enig officieel erkende registratie voor de betreffende gegevens is aangemerkt en in het gehele land verplicht wordt gebruikt door alle overheidsinstanties, alsook zo mogelijk door private organisaties, tenzij het gebruik om zwaarwegende redenen zoals privacybescherming expliciet is uitgesloten. Bron: SBG

Houder landelijke

Een houder landelijke voorziening is een overheidsorganisatie die een

voorziening

landelijke voorziening beheert.


Een landelijke voorziening is een voorziening waarin de gegevens uit één of meerdere basisregistraties zijn opgenomen, ten behoeve van het gebruik door afnemers. Voorbeeld: de dienst Kadaster is houder van de landelijke voorziening BAG

Least Privilege-

Het Least Privilege-principe gaat er vanuit dat een gebruiker of proces

principe

standaard niets mag, tenzij dit expliciet is toegestaan.

OTAP-principe

Door gebruik te maken van een gescheiden Ontwikkel, Test, Acceptatie en Productie omgevingen worden de verschillende stadia die de applicatie moet doorlopen expliciet gemaakt. Daarnaast wordt er voorkomen dat er informatie terecht komt op een verkeerde omgeving (productie informatie in de test-omgeving bijvoorbeeld). De verschillende componenten binnen OTAP behoren identiek aan elkaar te zijn om zo een betrouwbaar ontwikkelingstraject te kunnen volgen.

Registratiehouder

De bij wet aangewezen overheidsinstelling of groep van overheidsinstellingen, die houder en beheerder is van de basisregistratie. Bron: SBG


110/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Bijlage 3: Afkortingen

Afkorting

Betekenis

A2A

Application-to-application

BAG

Basisregistratie Adressen en gebouwen

BiSL

Business information Services Library

BRV

Basisregistratie Voertuigen

BSN

Burger Service Nummer

BIV

Beschikbaarheid, Integriteit, Vertrouwelijkheid

BPR

Basisadministratie Persoongegevens en Reisdocumenten

BR

Basisregistratie

CPA

Collaberative Protocol Agreement

CSP

Certificate Service Provider

ebMS

ebXML Message Service

ebXML

Electronic Business using eXtensible Markup Language

ERD

Entiteit Relatie Diagram

ESB

Enterprise Service Bus

FTP

File Transfer Protocol

GBA

Gemeentelijke Basis Administratie

GOB

Gemeenschappelijke Ontsluiting Basisregistraties

HTTP

Hypertext Transfer Protocol

HTML

Hyper Text Markup Language

IP

Internet Protocol

ISMS

Information Security Management System

KPS

Koppelnet Publieke Sector

KvK

Kamer van Koophandel

LV

Landelijke Voorziening

MMI

Mens-machine-interface

NEN

Nederlands Normalisatie-instituut


111/112

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Afkorting

Betekenis

NHR

Nieuw Handelsregister

NORA

Nederlandse Overheids Referentie Architectuur

OIN

Overheids Identificatie Nummer

OSB

Overheidsservicebus

OTAP

Ontwikkeling-, Test-, Acceptatie- en Productie(omgeving)

PKI

Public Key Infrastructure

RENOIR

Regie E-overheid NUP Ondersteuning Implementatie Realisatie

REST

Representational State Transfer

RDW

RijksDienst voor het Wegverkeer

RNI

Registratie Niet-Ingezetenen

SAN

Storage Area Network

SBG

Stroomlijning Basis Gegevens (voormalig ICTU-programma)

SSL

Secure Sockets Layer

SVB

Sociale Verzekeringsbank

StUF

Standaard Uitwisselings Formaat

TLS

Transport Layer Security

TCP/IP

Transmission Control Protocol / Internet Protocol

VIR

Voorschrift Informatiebeveiliging Rijksdienst

VIR-BI

Voorschrift Informatiebeveiliging Rijksdienst – Bijzondere Informatie

WOZ

Waardering Onroerende Zaken

WBP

Wet Bescherming Persoonsgegevens

WSDL

Web Service Definition Language

WUS

Webservices UDDI SOAP

XSD

XML Schema Definition

Wilhelmina van Pruisenweg 104 2595 AN Den Haag Postbus 84011 2508 AA Den Haag T +31 (070) 888 77 22 F +31 (070) 888 78 88 www.e-overheid.nl/renoir

Projectstartarchitectuur Digilevering. Definitief versie 1.2

Recommend Documents