Deelprogramma Digitaal Stelsel Omgevingswet · 2019-10-31 · In hoofdstuk 8 wordt de roadmap...

Deelprogramma DSO

Deelprogramma

Digitaal Stelsel Omgevingswet

Globale Architectuur Schets

GAS IAM Versie 0.53 juni 2017

Met opmerkingen [BC1]: Knooppunt - Identity

Management

Met opmerkingen [BC2]: Notities op te nemen: - Machtigen

- eIDAS - ? Restricted API Keys

- ? Id. prop. Derden - BSN ?

- Beheerportaal ?

GAS PR29 IAM | 0.5 pagina 2 van 55

Deelprogramma DSO

Colofon

Titel : Globale Architectuur Schets

Beveiliging

Versie : 0.5

Datum : 6juni 2017

Opdrachtgever : Programma Implementatie Omgevingswet

Opdrachtnemer : Deelprogramma DSO

Auteurs : Bas Crompvoets

Domeinarchitect PDSO

Michael Stoelinga

Projectarchitect

Contactpersoon : Victorine Binkhorst

Lead architect PDSO

+31 6 5139 7648

[email protected]

Gebaseerd op : Visie 1.0

Programma van eisen 1.0

Doelarchitectuur 2.0

Overall GAS 1.34

Templateversie : 1.7

mailto:[email protected]


Deelprogramma DSO

Versiehistorie

Versie Status Datum Auteur(s) Toelichting

0.1 Concept Februari ‘17 M. Stoelinga Initiële versie

0.2 Concept Maart '17 M. Stoelinga Interne review projectteam

0.3 Briefing April '17 M. Stoelinga Besproken in briefing

0.4 Mei '17 M. Stoelinga Voor finale review

0.5 Juni '17 M. Stoelinga Na verwerking review

0.51 Juni '17 M. Stoelinga Na verwerking laatste minors

0.52 Juni '17 M. Stoelinga Wijziging n.a.v. bespreking in SAT

0.53 Juli '17 M. Stoelinga Aanvullend openstaand punt 15 toegevoegd

Goedkeuring

Functie Naam Versie Datum Handtekening

Stelselarchitect namens het

Opdrachtgevend Beraad

René Kint

Programmadirecteur

Implementatie Omgevingswet

namens de Programmaraad

Ineke van der Hee

Programma Manager PDSO Pieter Meijer

Lead architect programma Victorine Binkhorst

Distributie

Functie/Orgaan Versie Opmerkingen

Opdrachtgevend Beraad Omgevingswet

Programmaraad Implementatie Omgevingswet

Stelsel Architectuur Board (SAB)

Stelsel Architectuur Team (SAT)

Programma/Project Architectuur Team (PAT)


Deelprogramma DSO

Project

Strategische Ontwikkelpartners

Review

Naam Versies

PAT

SAT 0.51 d.d. 12 juni 2017


Deelprogramma DSO

Inhoudsopgave

1 INLEIDING ................................................................................ 7

1.1 Doelgroep ....................................................................... 7

1.2 Doel .............................................................................. 7

1.3 Resultaat ........................................................................ 8

1.4 Positionering .................................................................... 8

1.5 Samenhang andere documenten ............................................. 9

1.6 Organisatieonafhankelijk ..................................................... 9

1.7 Architectuurkader en principes .............................................. 9

1.8 Archimate-notatie ............................................................. 9

1.9 Afkortingen en begrippen .................................................... 10

1.10 Leeswijzer ...................................................................... 10

2 BUSINESS ARCHITECTUUR ............................................................. 11

2.1 Overzicht business architectuur ............................................ 11

2.1.1 IAM en Beveiliging in de Domein Overstijgende Processen ..... 12

2.1.2 IAM en Beveiliging in de Stelsel Ondersteunende Processen ... 12

2.1.3 Relevante weten regelgeving voor het aspect IAM ............. 13

2.2 Organisatie ..................................................................... 14

2.2.1 Welke identiteiten c.q. actoren zijn relevant? ................... 14

2.2.2 Verschil in rol .......................................................... 17

2.2.3 Machtigingen ........................................................... 20

2.2.4 Organisatorische verantwoordelijkheid voor IAM ................ 21

2.3 Diensten & Producten ........................................................ 22

2.4 Processen ....................................................................... 23

3 INFORMATIEARCHITECTUUR .......................................................... 28

3.1 Medewerkers en applicaties ................................................. 29

3.2 Gegevens ....................................................................... 32

3.2.1 DSO actor) .............................................................. 32

3.3 Informatie-uitwisseling ....................................................... 33

3.4 Herbruikbare bouwblokken .................................................. 34

3.4.1 Gebruiken .............................................................. 34

3.4.2 Opleveren .............................................................. 35


Deelprogramma DSO

4 BEHEER .................................................................................. 36

5 BEVEILIGING & PRIVACY .............................................................. 37

5.1 Beveiligingsclassificaties ..................................................... 37

5.2 Beschikbaarheid ............................................................... 38

5.3 Integriteit ...................................................................... 38

5.4 Vertrouwelijkheid ............................................................. 39

5.5 Betrouwbaarheidsniveaus .................................................... 40

6 PRINCIPES ............................................................................... 42

6.1 Overzicht ....................................................................... 42

6.2 Business architectuur ......................................................... 43

6.2.1 Organisatie ............................................................. 43

6.2.2 Diensten & Producten ................................................ 43

6.2.3 Processen ............................................................... 43

6.3 Informatiearchitectuur ....................................................... 44

6.3.1 Medewerkers en Applicaties ......................................... 44

6.3.2 Gegevens ............................................................... 44

6.3.3 Informatie-uitwisseling .............................................. 44

6.4 Beheer .......................................................................... 44

6.5 Beveiliging & privacy ......................................................... 44

7 STANDAARDEN .......................................................................... 45

7.1 Forum Standaardisatie ....................................................... 45

7.2 Overige standaarden .......................................................... 45

8 ROADMAP ................................................................................ 47

8.1 Huidige situatie: OLO2, AIM en LRO ........................................ 47

8.2 IAM realisatie volgt opbouw DSO platform ................................ 48

8.3 Eindsituatie (2024) ............................................................ 48

9 BIJLAGE A: OPENSTAANDE PUNTEN ................................................. 49

10 BIJLAGE B: BRONNEN ................................................................ 51

11 BIJLAGE C: AANVULLENDE SPECIFIEKE BEGRIPPEN .............................. 52


Deelprogramma DSO

1 Inleiding

Dit document bevat de Globale Architectuur Schets (GAS) voor het aspect Identity Access Management (IAM) van het project Beveiliging.

Het doel van een GAS is het beschrijven van de globale architectuur en

de keuzen die daarin voor het project Beveiliging gemaakt zijn. De GAS beschrijft het eindbeeld van de oplossing en hoe dit eindbeeld in een

aantal realiseerbare stappen bereikt wordt. Daarnaast zorgt de GAS dat de oplossing aansluit op architectuur van de interbestuurlijke partners

(Rijk, provincies, gemeenten en waterschappen). Dit geheel zorgt ervoor dat de veranderopgave in samenhang met andere veranderingen

wordt gerealiseerd en past binnen de gewenste toekomst vaste

informatievoorziening van het Digitaal Stelsel Omgevingswet (DSO).

Een GAS stelt de opdrachtgever in staat gedurende het opstellen ervan besluiten te nemen over onderkende architectuurkeuzen. De GAS

beperkt zich tot de bedrijfsarchitectuur en informatie architectuur. De GAS vormt het kader voor de verdere uitwerking in een Project Start

Architectuur (PSA) waar het zwaartepunt verschuift naar de technische architectuur. De PSA is gehouden aan de oplossingsrichting en de

kaders beschreven in deze GAS en kan hiervan niet afwijken zonder akkoord van de Stelsel Architectuur Board (SAB) van het DSO.

De Overall GAS (OGAS) is de overkoepelende kapstok met algemene

kaders en richtlijnen voor het stelsel waar elke GAS aan moet voldoen om een digitaal stelsel te realiseren dat werkt en op een eenduidige en

samenhangende manier is opgezet.

1.1 Doelgroep

De GAS richt zich op opdrachtgever en opdrachtnemer

(programmaraad). Daarnaast zijn ook interbestuurlijke partners, PSA-schrijvers, projectmanagers en business analisten belangrijke stake-

holders.

1.2 Doel

De GAS helpt in het scherp krijgen van: De context van de oplossing.

De belangrijkste requirements van de opdrachtgever. Criteria waaraan de oplossing wordt getoetst.


Deelprogramma DSO

1.3 Resultaat

De GAS is het startpunt voor de uitwerking van de PSA en geeft de

opdrachtgever het vertrouwen dat de vraag goed begrepen is en de oplossing passend zal zijn.

Met het resultaat van de GAS:

Tonen de domeinarchitect van het programma en de projectarchitect van de strategische ontwikkelpartij aan dat zij de architecten van de

opdrachtgever goed begrepen hebben. Is een gemeenschappelijk beeld over de kaders en de

oplossingsrichting. Is een gemeenschappelijk beeld met afhankelijke projecten en zijn

wederzijdse afhankelijkheden inzichtelijk en koppelvlakken bekend.

Zijn discussiepunten en onduidelijkheden naar boven gebracht en gezamenlijk opgelost.

Is een aanzet gegeven tot de belangrijkste onderdelen van de oplossingsrichting.

Beschikt de opdrachtgever over een begrijpelijk resultaat om te accorderen en op te sturen.

1.4 Positionering

Hieronder wordt de basis architectuurplaat van het DSO weergegeven.

Hierop is de positionering van deze GAS aangegeven.

Figuur 1. Positionering IAM op basis architectuurplaat DSO


Deelprogramma DSO

IAM is een randvoorwaarde bij het uitwisselen van gegevens. IAM functionaliteit wordt binnen het Digitaal Stelsel Omgevingswet

ingebouwd in het onderdeel "gegevensuitwisseling" dat met name wordt ingevuld door het Knooppunt. Gebruikers, gebruikerstoepassingen en de

andere onderdelen van het stelsel benutten deze functionaliteit.

IAM is ook een randvoorwaarde voor beveiliging, borgen van privacy en beheer. Daarom omvat IAM ook functionaliteit die los staat van de

dagelijkse operatie van het DSO en die hoort bij beheer.

1.5 Samenhang andere documenten

In de laatste versie van het document “DSO - Architectuur - Toelichting samenhang documenten” wordt toegelicht hoe een GAS samenhangt

met andere kader en architectuur documenten.

1.6 Organisatieonafhankelijk

De GAS is neutraal, dat wil zeggen niet ‘gekleurd’ door de strategie van een specifieke organisatie. De GAS is beperkt tot de Bedrijfsarchitectuur

en Informatiearchitectuur lagen, aangevuld met de Beheer en Beveiliging & Privacy aspecten van deze lagen. Er is bewust gekozen om

geen uitspraken te doen over de Technische Architectuur. De GAS schrijft geen techniek voor en is dus onafhankelijk van de techniek. De

strategische ontwikkelpartner verantwoordelijk voor de implementatie van een GAS behoudt zo de vrijheid haar eigen technologiekeuzen te

maken, maar met de OGAS en GAS zijn die keuzen nadrukkelijk verbonden aan de kaders, principes en meegegeven oplossingsrichting.

Uitzondering hierop zijn herbruikbare GDI- en DSO-bouwblokken. De GAS zal hier nadrukkelijk op sturen.

1.7 Architectuurkader en principes

In de laatste versie van het document “DSO - Architectuur - Toelichting architectuurkader en principes” wordt het gehanteerde architectuurkader toegelicht en de manier waarop principes beschreven worden.

1.8 Archimate-notatie

In de laatste versie van het document “DSO - Architectuur - Toelichting ArchiMate-notatie” staat een korte toelichting hoe ArchiMate versie 2.1 wordt toegepast en wordt de ArchiMate-notatie kort toegelicht.


Deelprogramma DSO

1.9 Afkortingen en begrippen

In de laatste versie van het document “DSO - Architectuur - Afkortingen Begrippen” staan de definities van begrippen en afkortingen die in het DSO gehanteerd worden. Deze begrippen worden ook opgenomen in de Stelselcatalogus. Afkortingen en begrippen die specifiek zijn voor het onderwerp van deze GAS en nog niet in de DSO begrippenlijst zijn opgenomen staan in bijlage C van dit document.

1.10 Leeswijzer

In hoofdstuk 2 wordt de business architectuur beschreven.

In hoofdstuk 3 wordt de informatiearchitectuur beschreven.

In hoofdstuk 4 worden de beheeraspecten beschreven.

In hoofdstuk 5 worden de beveiliging & privacy aspecten beschreven.

In hoofdstuk 6 wordt aangegeven welke principes uit de Overall GAS (OGAS) van toepassing zijn en hoe deze toegepast worden voor deze

GAS.

In hoofdstuk 7 worden de standaarden benoemd die van toepassing zijn

voor deze GAS.

In hoofdstuk 8 wordt de roadmap beschreven hoe het eindbeeld in controleerbare en haalbare stappen wordt gerealiseerd: van de huidige

situatie naar de eindsituatie met eventuele tussenstappen.

In Bijlage A zijn de nog openstaande punten opgenomen.

In Bijlage B de lijst met bronnen die voor het opstellen van deze GAS gebruikt zijn.

Tot slot is in Bijlage C een lijst met begrippen opgenomen aanvullende

op de huidige DSO begrippenlijst.


Deelprogramma DSO

2 Business architectuur

In dit hoofdstuk wordt de bedrijfsarchitectuur beschreven voor zover die van belang is voor de positie en rol van het aspect IAM binnen

Beveiliging. Het is een beschrijving in brede zin, dat wil zeggen de wat en hiermee onafhankelijk van de te kiezen oplossing.

De bedrijfsarchitectuur omvat de volgende aspecten: Welke weten regelgeving zijn van toepassing. Wie zijn betrokken (organisatie). Wat zijn de diensten en producten. Hoe verlopen de processen.

2.1 Overzicht business architectuur

Afbeelding 1. Toegangsservices benut door bedrijfsprocessen


Deelprogramma DSO

IAM is als onderdeel van Beveiliging op eerste gezicht geen "business" aspect. Het is ondersteunend en randvoorwaardescheppend aan de

bedrijfsfuncties van DSO. Hierboven is dat weergegeven door IAM te zien als een verzameling services die worden benut (used by) alle

bedrijfsprocessen conform de DOP1.

De business architectuur van IAM wordt in de volgende paragrafen uitgewerkt door aan te geven wat het wettelijk kader is, van wie

identiteiten beheerd worden in DSO, wat de scope is van het product "DSO-IAM" en de diensten die er onderdeel van uitmaken en hoe dit

verband houdt met de processen.

2.1.1 IAM en Beveiliging in de Domein Overstijgende Processen

Voor IAM is er onderscheid tussen "open" processen en "besloten"

processen. De "open" processen zijn toegankelijk zonder dat de gebruiker geauthenticeerd is. Toegankelijkheid voor eenieder zonder

drempels is een belangrijke eis voor DSO. Een belangrijk "open" bedrijfsproces is "Oriënteren". In sommige gevallen wordt echter ook

voor dit bedrijfsproces authenticatie benut, namelijk wanneer een Bevoegd Gezag zich oriënteert.

Voor de meeste Domein Overstijgende Processen is het altijd

noodzakelijk de Gebruiker te kennen, c.q. te authenticeren. Bovendien is er vervolgens veelal nadere autorisatie nodig en moet het mogelijk

zijn anderen te machtigen. Deze ondersteunende functies worden gerealiseerd door de verzameling toegangsservices.

2.1.2 IAM en Beveiliging in de Stelsel Ondersteunende Processen

De stelsel ondersteunende functies worden gebruikt vanuit twee

doelgroepen, eenieder en DSO-beheerders. Eenieder kan

terugmeldingen en verzoeken/storingen indienen. Hiervoor is tenminste personalisatie nodig. DSO zal immers in staat moeten zijn om de

indiener van het verzoek, de storingsmelding of de terugmelding op de hoogte te houden van de afhandeling ervan.

De stelselondersteunende functies zijn alleen toegankelijk voor daartoe

geautoriseerd DSO-beheerders. Daarbij worden dezelfde Toegangsservices benut als die van andere gebruikers. Daarnaast is er

een aantal ondersteunende beheerfuncties specifiek voor IAM (op dit niveau van beschouwing zijn die onderdeel van "beheren standaarden

en configuraties"). Het vastleggen van configuraties omvat ook de

1 In de OGAS in bijlage A zijn dezelfde used by relaties opgenomen (dit is momenteel nog in

bewerking).


Deelprogramma DSO

"dingen waartoe DSO Gebruikers toegang krijgen". Er moet bekend zijn wie de gebruiker is, maar er moet ook vastliggen waartoe de gebruiker

toegang krijgt, wat de functie, onderliggende service en/of bijbehorende gegevens zijn die de eindgebruiker benut.

Om IAM te gebruiken is voorafgaande registratie nodig. Voor IAM

worden overheidsbrede GDI bouwstenen2 gebruikt. De meeste Gebruikers zullen zich daar registreren. Dit gaat buiten DSO om en

vraagt dus geen registratiefuncties vanuit DSO. Er is een restgroep waarvoor een DSO eigen registratie en identity provider wordt ingericht.

Deze registratie kan gezien worden als een specifiek geval van "Indienen storing of verzoek".

2.1.3 Relevante weten regelgeving voor het aspect IAM

Bijlage B van de doelarchitectuur bevat een opsomming van voor DSO relevante wetten. Daarvan zijn voor IAM de volgende van toepassing:

- Algemene wet bestuursrecht (2) - Europese privacy verordening (Directive 95/46/EC on the protection

of individuals with regard to the processing of personal data and on the free movement of such data, Data Protection) (6)

- Wet bescherming persoonsgegevens (9) - Wet elektronisch bestuurlijk verkeer (10)

- Wet elektronische handtekening (11)

Waarbij de GDPR / AVG (6) de Wbp (9) in feite vervangt. Ten tweede geldt dat de Weh (11) inmiddels vervangen is door de Europese eIDAS

verordening. Daarmee is een wettelijk kader voor betrouwbaarheidsniveaus geschapen dat direct relevant is voor IAM. Dit

wettelijke kader omvat eisen aan authenticatiemiddelen en IAM

processen3.

Aanvullend op het overzicht in de doelarchitectuur is er een wetsvoorstel GDI in behandeling (consultatieversie) dat relevant is.

Onder andere omdat het de toepassing van GDI componenten voor authenticatie in DSO verplicht zal maken.

Daarnaast zal de wet GDI algemene verplichtingen omtrent

informatiebeveiliging zoals het voldoen aan de BIR, BIG, IBI en BIWA (de respectievelijke besluiten / baselines informatiebeveiliging van de

2 In het vervolg worden de huidige GDI voorzieningen als DigiD en eHerkenning genoemd. In

kader van eID stelsel, eIDAS en ETD ontwikkelen deze zich. DSO zal deze ontwikkeling volgen,

zie § 8.2. 3 Meer info over deze eisen, zie Handreiking betrouwbaarheidsniveaus versie 4

www.forumstandaardisatie.nl/thema/handreiking-betrouwbaarheidsniveaus


Deelprogramma DSO

bestuurslagen, verder "de baselines") en de DigiD beveiligingsrichtlijnen een directe wettelijke basis geven. Deze regels gelden echter nu ook al

voor OLO2 op grond van de lagere regelgeving.

Deze eisen uit weten regelgeving zijn zodanig dat gesteld kan worden dat IAM deel uitmaakt van het "robuuste" deel van het stelsel (zie

doelarchitectuur § 4.1).

Voor eIDAS, GDPR en wet GDI geldt dat deze op dit moment nog geen onderdeel zijn van het wettelijk kader. De eerste twee zijn al wel

aangenomen, maar vanwege diverse invoeringstermijnen nu nog niet (volledig) van toepassing. De laatste is nog slechts een wetsvoorstel.

Gezien de verwachte invoeringsdatum van DSO wordt echter rekening

gehouden met volledige inwerkingtreding van deze wetten voorafgaand aan in gebruik name DSO. Ze vormen dus onderdeel van het "wettelijk

minimum (scenario 1)".

2.2 Organisatie

In deze paragraaf wordt de business context (wat) beschreven en inzicht gegeven in welke organisatieonderdelen geraakt dan wel

geleverd worden na de uitvoering van het project. Dit betreft zowel de organisatie-onderdelen binnen DSO als de partijen daaromheen die

afnemer c.q. aanbieder op het DSO zijn. Omdat IAM "gaat over" de vraag wie wie is, is het specifiek voor IAM belangrijk een compleet

beeld van al die partijen te hebben.

2.2.1 Welke identiteiten c.q. actoren zijn relevant?

Alle bij DSO betrokken partijen moeten ondersteund worden en daarom zijn alle in de DSO visie onderkende afnemers, gebruikers en

aanbieders ook IAM actoren.

IAM identificeert partijen via de individuele eindgebruikers en systemen

waarmee deze partijen diensten afnemen (c.q. aanbieden). Voor een burger vallen deze samen met de juridische partij, voor bedrijven,

organisaties en overheden geldt dat niet. Daar omvat één juridische partij mogelijk vele individuele eindgebruikers. Evenzeer kunnen vele

verschillende systemen onder verantwoordelijkheid van één partij vallen.

Technisch gesproken kan gebruik van DSO alleen aan deze partijen

toegerekend worden door het gebruik van de individuele eindgebruikers die namens hen handelen te volgen binnen de DSO voorzieningen. Deze

toerekening is noodzakelijk om aan de wettelijke eisen te voldoen en


Deelprogramma DSO

conform "informatieveiligheid en privacybescherming zijn noodzakelijk" [D4]. Voor berichtenverkeer met systemen moet gelogd worden welk

bericht van welk systeem afkomstig is en zijn er afspraken met de verantwoordelijke voor die systemen.

Naast de afnemers, gebruikers en aanbieders vormen ook de DSO-

beheerders een groep voor IAM relevante partijen (GPvE § 2.8). DSO-beheerders zijn medewerkers van de beheerorganisatie DSO die

toegang hebben tot het DSO-platform en bijbehorende OTAP-straat en voorzieningen. Juridisch gesproken vallen zij onder verantwoordelijkheid

van de stelselbeheerder.

Tenslotte wordt in de visie en doelarchitectuur over derden gesproken,

te weten software-leveranciers en app ontwikkelaars. App ontwikkelaars zijn partijen die het open deel van DSO benutten om daarmee hun

eigen producten te ontwikkelen. Dit kunnen zowel individuen als medewerkers van software bedrijven zijn. De term software

leveranciers wordt tevens gebruikt voor partijen die in opdracht van bevoegd gezagen software ontwikkelen. Een scherp onderscheid is er

niet. Het komt voor dat bevoegd gezag deze software als cloud oplossing gebruikt zodat technisch gesproken deze software

leveranciers in opdracht van bevoegd gezagen gegevens uitwisselen met DSO.

In de visie en doelarchitectuur worden deze verschillende doelgroepen

globaal aangeduid. Voor IAM worden ze als volgt opgevat.

Actor Natuur

lijk

persoon

Mede

werker

van

Opmerkingen

Gebruikers Onder Gebruikers worden de onderstaande 4

doelgroepen verstaan. Gebruikers zijn afnemers van

DSO diensten.

Eenieder Kan Kan Eenieder moet de mogelijkheid hebben de open

informatie en services van DSO te gebruiken.

Hiervoor is het niet nodig dat DSO juridische

zekerheid heeft wie het betreft. Personalisatie is wel

mogelijk.

Initiatiefnemer Kan Kan Zodra initiatiefnemers een aanvraag of melding

indienen moeten er voldoende betrouwbaar juridisch

vast liggen wie het betreft (welke burger of

rechtspersoon het is). Al eerder in het proces is

personalisatie mogelijk. De initiatiefnemer kan

eerder beslissen zich bekend te maken en in te

loggen. Vanaf dat moment kan DSO zijn gegevens

betrouwbaar afschermen van anderen.

Belang-

hebbende

Kan Kan Van een belanghebbende moet voldoende

betrouwbaar juridisch vast liggen wie het betreft.


Deelprogramma DSO

Anonieme belanghebbenden bestaan niet. Alleen aan

identificeerbare belanghebbende kan toegang

gegeven worden tot gegevens over een bepaalde

zaak.

Bevoegd Gezag Nee Altijd Alle processtappen die Bevoegd Gezag uitvoert

vereisen dat vastligt welk Bevoegd Gezag het

betreft. Vanuit informatie-beveiligingseisen geldt dat

daarbij op medewerker niveau gelogd wordt wie wat

doet. Dat wil overigens niet zeggen dat anderen

moeten kunnen zien welke medewerker welke

handeling verricht heeft.

Rechterlijke

macht

Nee Altijd Geen afzonderlijke groep. Zie uitleg hieronder.

Andere

afnemers

Naast Gebruikers zijn er de onderstaande andere

afnemers, ook wel aangeduid als "derden".

Software-

leverancier

Kan (?) Kan Dit betreft makers en leveranciers van software voor

DSO gebruikers. Zij kunnen deze software aanbieden

als cloud dienst in opdracht van een bevoegd gezag

(zie KPN02). Er is geen wezenlijk verschil met app

bouwers.

App bouwers Kan Kan Dit betreft afnemers van de open gegevens en

services van DSO. Hun apps maken gebruik van

deze gegevens en services, het kan zijn dat

Gebruikers zich via deze apps authenticeren.

Daarnaast zijn App bouwers actor bij het aanmelden

van nieuwe (versies) van hun app. In dat proces

wordt de authenticatie van de app binnen DSO

vastgelegd. Er is geen wezenlijk verschil met

software leveranciers.

Overige actoren Onderstaande actoren zijn ook van belang voor DSO

IAM.

Stelselverant-

woordelijke

Nee Altijd De stelselverantwoordelijke heeft een eigen

identiteit. Afnemers van diensten moeten immers

zeker zijn dat diensten daadwerkelijk van DSO

afkomstig zijn. Indien dit een collectief van

overheden wordt, dan zal ergens vast moeten liggen

welke partijen het omvat. Deze

stelselverantwoordelijke richt een DSO-

beheerorganisatie in welke de tactische en

operationele beheerverantwoordelijkheid voor DSO

uitvoert

DSO-beheerder Altijd Nee Een individuele medewerker van de DSO-

beheerorganisatie. Voor het beheer van DSO worden

dezelfde IAM voorzieningen benut, mogelijk

aangevuld met infrastructurele

beveiligingsmaatregelen.

Aanbieder Nee Altijd Dit betreft (semi-)publieke organisaties, bijvoorbeeld

informatiehuizen en ontwikkelpartners als RWS en

Kadaster die informatie/functionaliteit binnen het

DSO aanbieden.


Deelprogramma DSO

In de visie (§3.1, wordt de rechterlijke macht als een afzonderlijke doelgroep genoemd. In GPvE en andere stukken worden voor deze

groep echter geen andere eisen gesteld dan wat al geldt voor belanghebbenden, namelijk de mogelijkheid om gegevens van een

bepaalde zaak enkel toegankelijk te maken voor een beperkte groep. Het kan zijn dat dit in het kader van verdere uitwerking van de eisen

vanuit vergunning, toezicht en handhavingsprocessen nog verandert. Voor dit moment wordt aangenomen dat er geen aanvullende eisen zijn.

2.2.2 Verschil in rol

Dezelfde partij kan voorkomen als verschillende van bovengenoemde

actoren (in de tabel). De medewerker van een bevoegd gezag kan bijvoorbeeld belanghebbende zijn inzake een situatie in zijn woonbuurt.

Een software-leverancier kan los van zijn rol als software-leverancier

initiatiefnemer zijn etc. Een overheidsorganisatie die optreedt als bevoegd gezag kan in andere rol zelf initiatiefnemer zijn of

belanghebbende. Ook kan iemand eerst DSO gebruiken als eenieder, enkel ter oriëntatie en zich pas verderop in het ketenproces kenbaar

maken als initiatiefnemer of belanghebbende.

In het algemeen wordt dit in IAM architecturen opgelost door de partij en diens rol, dat wil zeggen de hoedanigheid waarin de partij handelt,

te scheiden. De partij wordt dan op basis van één middel geauthenticeerd (wie je bent) en de rol bepaalt de autorisaties (dat wat

je mag) in de betreffende situatie. Voor de DSO is deze algemene oplossing echter niet helemaal geschikt. Dit omdat er situatie zijn

waarin het voor zo'n partij gewenst kan zijn voor heel verschillende rollen, verschillende typen authenticatiemiddelen toe te passen. Of –

van de kant van DSO gezien – er geen (juridische) reden is om het feit

dat achter de ene en de andere rol dezelfde partij schuil gaat, vast te leggen.

Dit is het beste te illustreren met Venn-diagrammen c.q.

verzamelingen. De verzameling partijen kan als volgt in deelverzamelingen worden opgedeeld:


Deelprogramma DSO

Het begrip "rol" wordt binnen het programma op verschillende manieren gebruikt. Er wordt gesproken over Gebruikers met verschillende rollen,

wanneer bijvoorbeeld bedoeld wordt dat een gemeente (die meestal de rol bevoegd gezag heeft) ook zelf initiatiefnemer kan zijn. Er wordt

gesproken over de verschillende rollen van bevoegd gezag, zoals planvorming, vergunningsverlening, toezicht en handhaving4.

Deze uitwerking start met het principe dat voor IAM de actoren in

bovenstaande doelgroepen los van elkaar staan. Dit echter met uitzondering van eenieder, belanghebbenden en initiatiefnemers. In het

Venn-diagram is te zien dat deze samenhangen. Daar wordt het principe van naadloze gebruikerservaring gevolgd (§ 3.8

doelarchitectuur, LOK10). Een eindgebruiker, burger of bedrijf, kan DSO

beginnen te gebruiken als eenieder zonder in te loggen. Vervolgens is het de keuze van de eindgebruiker of personalisatie wordt toegepast.

Wordt de eindgebruiker verderop in het proces initiatiefnemer of belanghebbende (die een zienswijze wil indienen of samenwerken) dan

is inloggen vereist. De eerdere personalisatie wordt "naadloos" overgenomen. De eindgebruiker kan ervoor kiezen eerder in te loggen.

De mogelijkheid de eigen gegevens af te schermen is alleen beschikbaar nadat er ingelogd is en vanaf dat moment zijn betreffende

gegevens zonder inloggen niet zichtbaar. In deze keten is er dus sprake van overgang van de ene groep actoren naar de andere (van eenieder,

naar belanghebbende of initiatiefnemer). Globaal kan wel gesteld worden dat oriëntatie volledig open is, checken een proces is waar

personalisatie al nut heeft en opstellen aanvraag / melding inloggen

4 En het architectuurbegrip Archimate-rol wordt toegepast, dat is van een andere orde.


Deelprogramma DSO

vereist. De eindgebruiker bepaalt echter het moment van overgang en kan al eerder personalisatie toepassen of inloggen en van bijbehorende

functies gebruik maken.

Een burger die apps bouwt zal in zijn hoedanigheid van app bouwer een andere identiteit hebben. Voor bijvoorbeeld een forum van app bouwers

is het onnodig (en niet toegestaan) om eindgebruikers met hun BSN te identificeren. App bouwers c.q. software-leveranciers en leden van het

developerforum vormen dus een aparte groep (en aparte deelverzamelingen in het Venn diagram).

Wanneer iemand als medewerker van bevoegd gezag of namens een bedrijf handelt dan is de machtiging5 bepalend (machtiging wordt dus

bewust gebruikt om preciezer te zijn dan de term "rol"). De machtiging bepaalt in welke groep de actor valt. De machtiging om als bevoegd

gezag vergunningen te verlenen zal een andere zijn dan de machtiging om de gemeente als initiatiefnemer te vertegenwoordigen. Bevoegd

gezag zal ook voor het proces oriënteren altijd ingelogd zijn en dan mogelijk meer gegevens zien. Het tweede Venn-diagram hierboven

toont welke rollen een overheidsorganisatie kan spelen.

Samengevat: Er is een overzichtelijke afbakening van business rollen. Maar de manier waarop mensen en organisaties deze rollen vervullen

varieert sterk. Er zijn allerlei combinaties mogelijk. De weergave van de doelgroepen voor IAM is daarom beter aan te duiden in de vorm van

deelverzamelingen, zie volgende figuur:

5 Voor precieze betekenis van "machtiging" en onderscheid met "autorisatie" zie begrippenlijst.


Deelprogramma DSO

2.2.3 Machtigingen

Voor eenieder, initiatiefnemers en belanghebbenden geldt dat zij het recht (LOK18) hebben een ander te machtigen c.q. zich door een derde

te laten vertegenwoordigen. Dit geldt zowel voor Burgers als voor Bedrijven.

Voor bevoegd gezagen geldt dat zij een andere overheidspartij kunnen

mandateren om namens hen hun taak uit te voeren en/of in een Gemeenschappelijke Regeling kunnen samenwerken.

Voor alle situaties waar een medewerker namens een rechtspersoon

gebruikt geldt dat ook sprake is van een machtiging. Ook de relatie

tussen een systeem (een applicatie of service) en degene die ervoor verantwoordelijk is kan gezien worden als een machtiging.

Voor al deze situaties hanteren we de term "machtigen" als algemene

term. Dit is in de eerste plaats een juridisch begrip.

In principe worden de GDI voorzieningen voor machtigingen zo breed mogelijk toegepast. Dat betekent dat:

Bevoegd gezagen eHerkenning toepassen. Iedere medewerker van een bevoegd gezag die DSO diensten benut moet voorzien worden

van een eHerkenningsmiddel waarbij de machtiging om namens het bevoegd gezag te handelen wordt geregistreerd.

Bedrijven, rechtspersonen en samenwerkingsverbanden passen eHerkenning toe. Iedere medewerker of bestuurder die namens deze

partijen DSO diensten benut moet voorzien worden van een


Deelprogramma DSO

eHerkenningsmiddel waarbij de machtiging om deze partij te vertegenwoordigen wordt geregistreerd.

Binnen DigiD Machtigen en eHerkenning een grofmazige machtiging vastgelegd moet kunnen worden met de betekenis: "deze partij is

gemachtigd mijn DSO zaken namens mij af te handelen". Die partij is dan ook degene die binnen DSO in mappen informatie kan delen

met anderen vanuit samenwerkprocessen. De afbakening van deze machtigingen wordt bepaald door de

afbakening van de diensten die vanuit DSO worden aangemeld bij eHerkenning en DigiD. Dit geeft ruimte voor enige differentiatie in

machtigingen.

Naast bovengenoemde machtigingen zijn er ook fijnmazige

machtigingen. Dit betreft het toegang geven tot dossiers in het kader van samenwerking. Functioneel is er weinig verschil tussen het verlenen

van toegang aan een eigen medewerker of aan een derde waarmee samengewerkt wordt. In alle gevallen is er iemand verantwoordelijk

voor het dossier en kan deze anderen autoriseren. Voor deze fijnmazige situatie spreken we verder van "fijnmazige autorisatie". Deze wordt als

onderdeel van het samenwerken gerealiseerd en niet door de GDI ondersteund.

2.2.4 Organisatorische verantwoordelijkheid voor IAM

IAM is als aspect van beveiliging onderdeel van de zorgplicht van de

stelselorganisatie van het DSO. Vanuit verantwoordelijkheden bezien is het voor de werking van IAM dus noodzakelijk dat er één

stelselorganisatie is aangewezen (conform APDSO01. "Eén stelselorganisatie voert regie op het digitaal stelsel.")

Omdat er sprake is van een stelsel houdt deze verantwoordelijkheid ook in dat alle gebruikers, aanbieders en afnemers gewezen worden op hun

verantwoordelijkheden. Sommige aspecten van beveiliging vereisen dat gebruikers zich aan de regels houden en toezicht daarop vanuit DSO

kan noodzakelijk zijn (zie visie D4 Informatieveiligheid en privacybescherming zijn noodzakelijk, LOK15). Wanneer een afnemer

van DSO intern toestaat dat medewerkers elkaars wachtwoorden gebruiken dan kan DSO niet in haar verantwoordelijkheid voorzien dat

ze weet welke gebruiker wanneer welke handeling verrichtte. IAM heeft dus organisatorische gevolgen. Deze beperken zich tot het invullen van

een algemene verantwoordelijkheid die op grond van de baselines ook los van IAM al geldt.

Deze verantwoordelijkheid van de stelselorganisatie doet niets af aan de

verantwoordelijkheid van iedere afnemer inzake beveiliging. Iedere

afnemer beheert zelf machtigingen voor samenwerking, bedrijven en


Deelprogramma DSO

bevoegd gezagen zijn zelf verantwoordelijk voor hun eHerkenningsmiddelen en beheer van bijbehorende machtigingen. Waar

nodig worden afnemers in gebruikersvoorwaarden op deze verantwoordelijkheden gewezen.

Daarnaast is er de specifieke organisatie van IAM. Hiervoor is de DSO

beheerorganisatie verantwoordelijk. Deze omvat: - Eigenaarschap van de IAM functies

- Verantwoordelijkheid voor relaties met GDI bouwstenen, zoals autorisatiebesluiten, gebruiksovereenkomsten, certificate policies

PKIoverheid e.d. - Organisatie van de supportlijnen naar achterliggende

beheerpartijen in de IAM keten (zoals Logius).

Het expliciet beleggen van deze verantwoordelijkheden is een

voorwaarde voor BIR compliancy van de stelselorganisatie.

2.3 Diensten & Producten

Een product is de verzameling van business en/ of applicatie services, al dan niet vergezeld van een contract of verzameling overeenkomsten,

die in zijn geheel wordt aangeboden aan (interne of externe) klanten.

Onder dienst in deze context verstaan we de “business service” ofwel “bedrijfsservice” binnen de ArchiMate-notatie. Een bedrijfsservice is een

dienst die voorziet in de behoefte van een klant binnen of buiten de organisatie. Het stelt functionaliteit van een businessproces beschikbaar

aan externe actoren zoals burgers, bedrijven en overheden of interne actoren zoals andere DSO-onderdelen.

IAM vormt als aspect van Beveiliging één product dat vanuit het DSO wordt aangeboden aan de DSO componenten. Het vormt één product

omdat het een samenhangende verzameling business- en applicatieservices is. Het is mogelijk de voor IAM benodigde afspraken

in één (onderdeel van) overeenkomst met de afnemers / gebruikers van IAM te vatten. Dit kan gezien worden als Identity as a Service (IDaaS)

hetgeen meer en meer de cloud-ready architectuur voor IAM wordt. DSO componenten en DSO afnemers / gebruikers moeten hun IAM

behoeften kunnen invullen met deze IDaaS dienst c.q. dit product; er worden geen andere IAM producten of diensten toegepast. Dit zorgt

ervoor dat IAM samen met andere faciliterende functies bijdraagt aan het DSO als "een samenhangend geheel" (visie A1, APDS006).

Capabilities in aanvulling op de doelenboom van het product DSO IAM:

- Toegang Burgers


Deelprogramma DSO

- Autorisatie - Toegang Bedrijven

- Toegang Bevoegd Gezagen - Machtigingen

- Toegang overige DSO gebruikers - App koppeling

Hierna volgt de beschrijving van de bedrijfsservices die door IAM

ondersteund moeten worden. Het servicemodel beschrijft welke diensten IAM levert aan externe doelgroepen. Aangezien IAM

ondersteunend is levert het geen extern zichtbare bedrijfsservices.

Alle IAM services liggen op het niveau van applicatieservices en IDaaS /

PaaS / IaaS omdat ze ondersteunend zijn aan andere DSO processen. Deze worden in het volgende hoofdstuk uitgewerkt.

2.4 Processen

Het processenmodel visualiseert en beschrijft de processen die IAM

levert aan haar doelgroepen. Hierin staan alle processen die van belang zijn voor IAM. Dit zijn op enkele uitzonderingen na ondersteunende

processen. Hiermee wordt in één oogopslag duidelijk wat de omvang van IAM is: welke processen zijn er nodig om de producten en diensten

te leveren en op welke manier komen die tot stand.

In het onderstaande procesmodel worden de processen visueel weergegeven.


Deelprogramma DSO

In het overzicht aan het begin van dit hoofdstuk in paragraaf 2 is de relatie tussen IAM services en de bedrijfsprocessen globaal

weergegeven. De genoemde processen hebben de granulariteit van een bedrijfsproces. In de laatste versie van het document “DSO -

Architectuur - Toelichting procesgranulariteiten” worden de procesgranulariteiten toegelicht. In de figuur hierboven wordt een

eerste verdere uitwerking gemaakt. Binnen IAM zijn de belangrijkste

IAM werkprocessen onderscheiden: registratie, gebruik en machtigen. Omdat voor het merendeel van de Gebruikers geldt dat deze buiten

DSO in de Generieke Digitale Infrastructuur van de overheid geregistreerd zijn en deze registratie door DSO wordt benut is de

betreffende GDI registratiedienst expliciet gemaakt.

Verder is de indeling in de DOP vervangen door de typering tussen open, gepersonaliseerde en besloten processen. In voorgaande


Deelprogramma DSO

paragraaf is uitgelegd dat het van de situatie (en de rol die Gebruiker in het betreffende proces speelt) afhangt of en op welke manier

toegangsservices benut worden.

Ook de informatiehuizen zullen IAM benutten. Vanuit DSO worden namelijk gegevens opgevraagd waarvoor doelbinding voor een bepaalde

burger of bedrijf vereist is. Om deze doelbinding aan te tonen zal een DSO autorisatie doorgegeven worden aan het informatiehuis (identity

propagation). Deze moet de bijbehorende controles implementeren en geeft op basis van de van DSO ontvangen autorisatie toegang tot de

gevraagde informatie.

Hierna volgt een beschrijving van de processen, actoren en

businessobjecten. # Proces Toelichting

Registreren IAM Voordat elektronische authenticatie mogelijk is vindt

registratie plaats. Het resultaat van deze registratie is dat de

Gebruiker, Afnemer of Aanbieder met een bepaalde

betrouwbaarheid uniek geïdentificeerd is, dat dit vast ligt in

een (basis)registratie en dat de eindgebruiker een

authenticatiemiddel verkregen heeft.

De restgroep "overige gebruikers" die niet in de

basisregistraties vastligt wordt binnen DSO geregistreerd. Er

wordt gecontroleerd dat een partij die wel in een

basisregistratie is geregistreerd niet als "overige" behandeld

wordt en niet apart geregistreerd wordt. Een deel van deze

overige gebruikers zijn de aanbieders waarvoor dit proces in

de GAS PR05 Knooppunt is beschreven6. Een ander deel

betreft buitenlandse gebruikers. Ook zodra er een eIDAS

koppelpunt7 komt als nieuwe GDI voorziening waarlangs

gebruikers uit andere EU landen toegang krijgen, dan blijven

er nog gebruikers uit niet EU landen over. Daarnaast zijn er

restgroepen als ambassades. Vanuit PR29 wordt er één

oplossing voor de gehele doelgroep "overige gebruikers"

gerealiseerd die ook omvat wat daarover in PR05 al voorzien

is.

Gebruiken IAM Iedere keer wanneer in een proces bekend moet zien "wie iets

doet" en "in hoeverre daar toestemming (autorisatie) voor

verleend is" wordt het authenticatiemiddel gebruikt en worden

geregistreerde machtigingen toegepast. In het proces dat de

toegangsservices benut is zeker dat er namens de Gebruiker,

afnemer of aanbieder iemand is ingelogd. Op grond daarvan

wordt in dat proces besloten om de eindgebruiker toe te

laten. Van de Gebruiker, afnemer of aanbieder wordt een

identificerend nummer beschikbaar gesteld.

6 (zie hfd. 2, GAS v1.51. Respectievelijk de bedrijfsservice "identiteit aanmelden" en de functie

"aanmelden organisatie / persoon") 7 Voorbeeld van eerste aansluitingen daarop, zie:

https://www.digitaleoverheid.nl/achtergrondartikelen/eidas-implementatie-nederlandse-

overheidsdienstverleners-sluiten-via-makelaars-aan-op-eidas/


Deelprogramma DSO

Naast authenticatie kan autorisatie plaatsvinden. Dan is voor

de toegang tot een service of informatie naast het feit dat

iemand ingelogd is een nadere toestemming nodig. Deze

toestemming is eerder door iemand geregistreerd of volgt uit

gegevens over de eindgebruiker.

Als voorwaarde voor het authenticeren van eindgebruikers en

voor alle systeem - systeem verbindingen vindt onderliggend

IAM gebruik plaats op basis van PKI-certificaten. Deze

vormen ook een authenticatiemiddel dat geregistreerd is bij

een betrouwbare derde (TTP van PKIoverheid).

"Iedere keer" authenticeren neemt niet weg dat single sign on

gewenst kan zijn in kader van "naadloze" gebruikerservaring.

Afnemen van producten van informatiehuizen mag niet tot

nieuwe inlog leiden. Ook voor een gebruiker die van- of naar

een voorziening van een bevoegd gezag of een GDI

voorziening als de berichtenbox gaat, is single sign on

gewenst.

Gebruiken IAM benut informatie over identiteiten uit

Registreren IAM en informatie over machtigingen uit

Machtigen.

Machtigen Juridisch gesproken zijn machtigingen vormvrij. Voor

elektronische diensten is het noodzakelijk dit vast te leggen.

Dat kan impliciet gebeurd zijn in de registratie (de bestuurder

die tekent voor een PKI-overheidsorganisatiecertificaat) of

expliciet in een machtigingsregister vastgelegd. In beide

gevallen is het relevant dat machtigingen een bepaalde scope

kunnen hebben. Een machtiging kan alleen gelden voor een

bepaalde situatie. Dit moet bij gebruik kunnen worden

gecontroleerd. Een elektronisch vastgelegde machtiging moet

kunnen worden ingetrokken. Soms kan een machtiging

doorgegeven worden aan een ander, maar dat is niet

vanzelfsprekend.

Nota bene: de samenhang met samenwerkingsfunctionaliteit

voor het ondersteunen van in vrije vorm (gescand papier)

toevoegen van machtigingen moet nader uitgewerkt worden.

Het is gewenst dat voor IAM tenminste vastgelegd is op welke

identiteiten er een dergelijke machtiging is opgenomen.

# Actor Toelichting

Eindgebruiker De mens die het authenticatiemiddel in de praktijk gebruikt.

Het kan zijn dat deze namens zichzelf handelt (een burger) of

namens een andere partij (medewerker van …)

DSO actor De partij voor wie DSO diensten gebruikt worden. Deze kan

een ander machtigen.

Gemachtigde Een partij aan wie een machtiging verleend is. Dit kan een

eindgebruiker (mens) zijn. Het kan ook een rechtspersoon

zijn, die vervolgens een medewerker moet machtigen om

loketdiensten af te nemen of een systeem met een PKI-

certificaat als authenticatiemiddel heeft om gebruik uit te

voeren.

Machtigingsverlener De mens die eindverantwoordelijk is om een machtiging te


Deelprogramma DSO

verlenen. Bij een burger is dat de burger zelf (uitzonderingen

daargelaten). Bij een bedrijf, bevoegd gezag of andere

rechtspersoon is dit een bestuurder of een medewerker die

expliciet door de bestuurder gemachtigd is (bij een overheid:

gemandateerd). Voor een machtigingenregistratie moet

controleerbaar zijn onder wiens eindverantwoordelijkheid een

machtiging verleend wordt.

# Organisatie Toelichting

Middelenuitgever De partij die verantwoordelijk is voor de IAM registratie.

Bijvoorbeeld Logius voor DigiD of Quovadis voor bepaalde

PKIoverheidscertificaten.

Machtigingsregister De partij die verantwoordelijk is voor de registratie van

machtigingen.

Toegangsverlener Degene die verantwoordelijk is voor het proces waarin de

toegang verleend wordt (dan wel voor de applicatie of service

waarmee dat proces gerealiseerd wordt). Dit is een DSO

verantwoordelijkheid die onder eindverantwoordelijkheid van

de stelselverantwoordelijke valt.

# Businessobject Toelichting

DSO externe partij Een DSO externe partij is de Gebruiker, Afnemer of Aanbieder

die DSO diensten benut conform een juridische afbakening

(een natuurlijk persoon, rechtspersoon of

samenwerkingsverband). In termen van de Omgevingswet is

een initiatiefnemer een partij (ongeacht of deze zelf een

aanvraag doet of dat iemand dat namens haar doet). Evenzeer

is een gemeente een partij (van type bevoegd gezag).

Betrouwbare authenticatie en autorisatie van DSO externe

partijen is een voorwaarde voor de werking van de primaire

DSO processen.

DSO interne partij Een DSO interne partij is DSO zelf als dienstverlener en/of de

partijen die als collectief de DSO diensten leveren aan DSO

externe partijen.

Betrouwbare authenticatie en autorisatie van de DSO interne

partijen is een voorwaarde voor het vertrouwen dat externe

partijen in DSO hebben en voor de DSO informatiebeveiliging.

Vertrouwde derde Partijen waarvan DSO voor informatiebeveiliging of IAM

afhankelijk is. Dit zijn o.a. de PKIoverheid CSPs en Logius voor

DigiD en eHerkenning.

Machtiging Een elektronisch vastgelegde machtiging is een relatie tussen

twee DSO externe partijen c.q. DSO actoren. Deze relatie is

hiërarchisch: de ene actor is machtigingsverlener, de ander

gemachtigde. De relatie heeft een scope: de machtiging kan

beperkt zijn tot bepaalde handelingen die de gemachtigde

namens de machtigingsverlener mag uitvoeren.

Resource Informatie of service waartoe in of via DSO toegang verleend

wordt aan partijen.


Deelprogramma DSO

3 Informatiearchitectuur

In dit hoofdstuk wordt de informatiearchitectuur beschreven van het aspect IAM van Beveiliging, deze is bepalend voor de te kiezen

oplossingen.

De informatiearchitectuur omvat de volgende aspecten: Wie voeren uit (medewerkers en applicaties). Wat zijn de gegevens en berichten. Hoe verloopt de informatie-uitwisseling.


Deelprogramma DSO

3.1 Medewerkers en applicaties

# Applicatiecomponent Toelichting

1 Sessiemanagement PR02. De sessiemanagementcomponent regelt de technische

connectie met een online gebruiker en is een voorwaarde voor

inloggen. Daarnaast levert sessiemanagement ook de

permalink en personalisatie op basis van b.v. cookies. Dat zijn

vormen van herkenning van gebruikers die voorafgaand aan

inloggen al voor kunnen komen. Bij inloggen moet de

gebruikerservaring "naadloos" zijn en worden

gepersonaliseerde gegevens dus hergebruikt. Alle informatie

over de gebruiker wordt daarom als één object "DSO externe

partij" gezien.

2 Gebruikersbeheer De gebruikersbeheercomponent verstrekt informatie over

ingelogde gebruikers. Indien mogelijk wordt deze informatie

opgehaald uit de basisregistraties (zie de interfaces). Dat

neemt niet weg dat er over alle gebruikers aanvullende

gegevens kunnen worden vastgelegd. Voor overige gebruikers

vindt ook registratie en middelenuitgifte plaats. Hoewel er

meerdere typen gebruikers (burgers, bedrijven, bevoegd

gezag etc.) zijn waarover gegevens bewaard worden, is de

werking voor al deze typen gelijk.

3 Platformservices De standaard IAM functies worden gerealiseerd door

infrastructuurservices van het standaardplatform. Voor

bepaalde functies werken deze samen met het knooppunt. Dit

levert authenticatietokens en autorisatietokens conform de

SAML of (voor apps) de OAuth standaard.


Deelprogramma DSO

4 Machtigingenbeheer Een component voor het vastleggen van machtigingen in DSO

kader. Deze heeft een (nader uit te werken) samenwerking

met mappenbeheer.

5 API manager Bij de API-manager worden (versies van) apps aangemeld /

geregistreerd voor gebruik in DSO. De ontwikkelaar ontvangt

daarbij een token dat in de app wordt opgenomen

(functionaliteit beschreven door PR05). De API-manager

ondersteunt ook het koppelen van de app aan een

eindgebruiker. OP runtime worden de tokens verwerkt door

de platform services (identity server).

# Applicatiefunctie Toelichting

1 Inloggen Inloggen omvat het authenticeren voor alle typen

eindgebruikers evenals het aanbieden van de

keuzemogelijkheid aan eindgebruikers om aan te geven in

welke hoedanigheid ze aanloggen en welk authenticatiemiddel

ze wensen te benutten.

2 Inloggen Burgers Interface naar DigiD

3 Inloggen Medewerker Interface naar de eHerkenning herkenningsmakelaar. Het

betreft medewerkers van zowel Bevoegd Gezag als van

Bedrijven, andere organisaties en niet-natuurlijke personen.

4 Autoriseren Dit omvat zowel standaardfunctionaliteit om een

autorisatietoken te leveren als een standaardcomponent die

in de applicatieserver een ontvangen autorisatietoken

verifieert.

5 Registreren overige gebruikers Voor gebruikers zonder DigiD of eHerkenning is een

registratie nodig waarin gegevens over hen worden

opgeslagen. Dit geldt zowel voor de restgroep als voor

buitenlandse gebruikers die weliswaar via een eIDAS

koppelpunt met het authenticatiemiddel dat ze in hun eigen

land (EU) gebruiken kunnen inloggen, maar daarna toch

gegevens zullen moeten registreren. DSO heeft namelijk geen

toegang tot de basisregistraties van de betreffende andere

landen.

6 Uitgeven authenticatiemiddel

overige gebruikers

Na controle wordt aan overige gebruikers een DSO

authenticatiemiddel verstrekt

7 Beheren gebruikersgegevens Waar nodig worden gegevens over ingelogde gebruikers aan

andere componenten doorgegeven. Daarmee wordt aan de eis

voldaan dat gebruikers hun gegevens maar één keer

aanleveren. Indien van toepassing kan doelbinding vanuit

betreffende proces een voorwaarde zijn voor het benutten

van gegevens zoals BSN en BRP-gegevens.

8 Beheren machtigingen Verleende machtigingen moeten in elektronische vorm

worden vastgelegd voordat ze benut kunnen worden.

9 Personaliseren De functie om voorafgaand aan inloggen al comfortgegevens

(bijvoorbeeld iemands naam zoals door hem of haar zelf

opgegeven) over de gebruiker vast te leggen en de gebruiker

in staat te stellen het proces te onderbreken en later zonder

gegevensverlies te vervolgen.

10 Beheren vertrouwde partijen Op diverse punten in de keten is vertrouwen in andere

partijen essentieel. Dit wordt gecontroleerd op basis van o.a.

PKIo certificaten. Er moet beheerd worden welke partijen op

een bepaald moment "vertrouwd" zijn en welke certificaten

benut worden om dat bij gebruik te controleren. Vertrouwde


Deelprogramma DSO

partijen omvatten zowel DSO interne partijen als DSO externe

partijen waarmee berichtenverkeer plaats vindt als

vertrouwde derden.

11 Koppelaar aangemelde app Deze functie stelt gebruikers in staat om in te loggen en

vervolgens een koppeling met een app tot stand te brengen,

zodanig dat deze app daarna toegang heeft tot bepaalde

gegevens die specifiek voor die gebruiker zijn. Dit doet een

gebruiker eenmalig, daarna kan hij of zij zich authenticeren

via de betreffende app. Het betreft enkel apps die al op basis

van het in PR05 beschreven mechanisme zijn aangemeld als

DSO app.


Deelprogramma DSO

3.2 Gegevens

# Dataobject Toelichting

1 DSO Partij Het centrale data-object voor IAM met de identificatie van

iedere DSO-actor (zowel interne als externe partijen) en (in

abstractie) ook van Vertrouwde derde partijen. Dit omvat alle

partijen die in het kader van DSO relevant zijn.

2 Machtiging Het data-object waarin de machtiging van de ene <DSO

externe partij> aan een andere <DSO externe partij> voor

een bepaalde <actie> wordt vastgelegd.

3 Resource Omvat zowel informatie resources (gegevensverzamelingen)

als services / applicaties / toepassingen c.q. componenten

van het DSO. Iedere resource hoort bij een bedrijfsfunctie,

dat wil zeggen dat er iemand verantwoordelijk voor is.

3.2.1 DSO actor)

Het centrale data-object is "DSO actor". Dit realiseert het business

object "DSO externe partij". Omdat DSO uit onderdelen bestaat die ook

in hun onderlinge relatie dezelfde IAM voorziening benutten worden "DSO interne partijen" ook als "DSO actor" vastgelegd. Het feit dat dit

één data-object is drukt uit dat alle actoren en partijen door DSO "gelijk" behandeld worden (visie A4 en C2). Iedere actor krijgt een

unieke identifier die binnen DSO gebruikt wordt. Verdere gebruikersgegevens en personalisatie-instellingen worden aan die

identifier gekoppeld. Deze identifier is voorbereid op het gebruik van pseudoniemen en de BSN-k.


Deelprogramma DSO

3.3 Informatie-uitwisseling

Voor IAM is de informatie-uitwisseling tussen de IAM voorziening en de

componenten die IAM benutten het meest van belang. Deze informatie-uitwisseling vindt plaats op basis van de SAML-standaard.

Het authenticatie- en autorisatieproces kent globaal de volgende

stappen: i. Doorverwijzen eindgebruiker naar een identity provider. Per

gebruikersgroep kan er onderscheid zijn of DigiD, eHerkenning of een andere identity provider relevant is.

ii. Inloggen en authenticatie eindgebruiker bij de identity provider.

De details hiervan worden bepaald door de Identity provider in kwestie.

iii. Bepalen namens welke Gebruiker gehandeld wordt (bij een burger zonder machtiging vervalt die stap) en dit teruggeven

aan het Bedrijfsproces dat de eindgebruiker wil doorlopen. iv. Doorgeven van de authenticatie in de verdere procesketen.

v. Controleren van toegang vanuit de verantwoordelijkheid van iedere losse schakel in de procesketen.

vi. Indien nodig, bepalen en ophalen van nadere autorisaties vii. Indien nodig, ophalen van gegevens over de Gebruiker (need to

know)

Daarbij wordt de volgende informatie uitgewisseld: i. SAML authenticatierequest

iii. SAML authenticatieresponse

iv. en vi. SAML autorisatietoken vii. Geen SAML. Bericht met gegevens over de gebruiker. Deze zijn

via de service Verstrekken gegevens gebruiker afkomstig uit de eigen gebruikersinformatie van DSO (business object externe partij)

of uit BRP of HR. Daarbij kan het nodig zijn eerst het BSN op te halen via het BSN-koppelregister.

De berichten iii, iv en vi dragen bij aan privacy by design doordat zij

geen privacy-gevoelige gegevens bevatten. Deze worden pas opgehaald in stap vii. Zo kan de controle of voldaan wordt aan de vereiste

doelbinding specifiek gedaan worden. Privacy by default totdat doelbinding voor een bepaald proces is aangetoond.

Voor app toepassingen zal er een variant op dit proces zijn, gebaseerd

op OAuth.


Deelprogramma DSO

Voor machine-machine berichtenverkeer geldt een ander verloop van de

informatie-uitwisseling (bepaald door PR05). Het IAM aspect daarbij is dat per bericht gecontroleerd wordt wie de afzender en wie de

ontvanger is. Dit gebeurt op basis van PKI-certificaten.

3.4 Herbruikbare bouwblokken

3.4.1 Gebruiken

Er wordt gestreefd naar efficiënt en effectief ontwikkelen van het DSO.

Om dit te realiseren wordt bij het ontwikkelen van stelsel componenten zoveel als mogelijk gebruik gemaakt van generieke bouwblokken.

Hierbij wordt expliciet gekeken naar GDI-bouwblokken, e-Overheid bouwblokken en DSO-bouwblokken. Als een bouwblok niet beschikbaar

is wordt deze eenmalig ontwikkeld voor het stelsel en hergebruikt door

andere stelsel componenten. Hierdoor wordt functionaliteit op één plek ontwikkeld en hergebruikt.

Er is een lijst met herbruikbare DSO-bouwblokken. Deze DSO-

bouwblokken kunnen door alle strategische ontwikkelpartners geleverd worden. Waar de functionaliteit van een DSO-bouwblok past binnen een

stelsel component is gebruik verplicht. Om hiervan af te wijken moet onderbouwd worden waarom er geen gebruik wordt gemaakt van het

DSO-bouwblok. Afwijkingen kan alleen na akkoord van de Stelsel Architectuur Board (SAB).

Op basis van een globale analyse zijn onderstaande herbruikbare

bouwblokken geselecteerd. De toelichting bij de bouwblokken is letterlijk overgenomen uit [Bouwblokken].

# Bouwblok Type Status Toelichting

1 DigiD GDI Productie SAML versie. Single sign on versie.

2 eHerkenning GDI Productie Versie bepalen

3 Idensys GDI Functioneert qua koppelvlak als nieuwere

versie van eHerkenning

4 BSN-koppelregister GDI *)

5 BRP service GDI ??? Via Centraal Aansluitpunt

6 HR service GDI ??? Via Centraal Aansluitpunt

7 eIDAS koppelvoorziening GDI *) ???

8 PKIoverheid GDI Productie

9 DigiKoppeling OIN register GDI Productie


Deelprogramma DSO

3.4.2 Opleveren

De volgende bouwblokken worden opgeleverd als herbruikbare DSO-

bouwblok. # Bouwblok Toelichting

1 Controleren autorisatie Component die in een applicatieserver wordt opgenomen om op basis

van ontvangen tokens toegangsbesluiten te nemen.

2 Identity Provider overige

gebruikers

Component die op basis van standaard SP infrastructuurservices een

identity provider voor overige gebruikers biedt

3 Controleren trust relatie /

veilige verbinding

Component om veilige verbindingen te controleren (in samenhang met

PR05 Knooppunt)


Deelprogramma DSO

4 Beheer

In dit hoofdstuk worden de relevante beheer aspecten beschreven als een van de pijlers van een betrouwbare dienstverlening.

Er zijn twee aspecten aan beheer en IAM. Enerzijds vormt IAM een

belangrijke randvoorwaarde voor beheer. Anderzijds worden de IAM voorzieningen zelf beheerd en is de kwaliteit van dat beheer van belang

voor goede informatiebeveiliging. Beveiligingsbeheer is het meest effectief indien deze categorie van beheerprocessen integraal onderdeel

vormt van de reguliere beheerprocessen. Dit is dan ook het uitgangspunt.

Binnen de DSO beheerorganisatie dient allereerst de strategische eigenaarsfunctie van de IAM functies structureel te worden belegd.

Gezien de vele veranderingen in de nabije toekomst en de wetgevingsaanpassingen is deze de basis voor de beheerinrichting.

Voor de invulling van het DOP proces ‘Beheer standaarden en

configuraties’ en voor de verantwoordelijkheid voor de relaties met GDI bouwstenen, zijn er een reeks beheeractiviteiten en objecten die

specifiek zijn voor IAM. Hieronder vallen onder andere autorisatiebesluiten, gebruiks- en aansluitovereenkomsten en certificate

policies PKIoverheid.

De een-loket gedachte is niet houdbaar voor de registratie van authenticatiemiddelen (Digid, eHerkenning). Dit is algemeen

geaccepteerd, want nu al de praktijk. Echter dit maakt een goede

inrichting van de supportlijnen naar de achterliggende beheerpartijen in de IAM keten (zoals Logius) ter invulling van het DOP proces ‘Indienen

Storing of Verzoek’ noodzakelijk.

De grote hoeveelheid persoonsgegevens die binnen het DSO worden beheerd (ondanks de architecturele dataminimalisatie) en omdat

toegang tot DSO (voor personen middels inloggen) grotendeels afhankelijk is van andere overheidspartijen, is calamiteitenbeheer ivm

datalekken en in de keten met ketenpartijen een randvoorwaarde voor livegang.

Voor IAM geldt dat het expliciet beleggen van de beheer-

verantwoordelijkheden een voorwaarde is voor BIR compliancy.


Deelprogramma DSO

5 Beveiliging & privacy

In dit hoofdstuk worden de relevante beveiliging en privacy aspecten beschreven als een pijler voor een betrouwbare serviceverlening.

Betrouwbaarheid is in de context van beveiliging en privacy het inbouwen van die mechanismen die bescherming van informatie tot

doel hebben.

Aangezien IAM zelf een onmisbare schakel vormt in beveiliging en in het borgen van privacy wordt niet alleen ingegaan op de beveiligings- en

privacy aspecten van IAM maar ook op de rol die IAM speelt in de beveiliging- en privacyborging van het gehele DSO.

5.1 Beveiligingsclassificaties

Informatiebeveiliging wordt in drie beveiligingsclassificaties onderverdeeld: beschikbaarheid, integriteit, en vertrouwelijkheid.

Classificatie Toelichting

Beschikbaarheid Hoe vaak en wanneer een component toegankelijk is en kan worden gebruikt.

Integriteit

Het in overeenstemming zijn van informatie met het afgebeelde deel van de

werkelijkheid en dat niets ten onrechte is achtergehouden of verdwenen (juistheid,

volledigheid en tijdigheid). Het gaat hier om de integriteit van gegevens waarop en

waarmee een component werkt.

Vertrouwelijkheid Het beperken van de bevoegdheden en de mogelijkheden tot muteren, kopiëren,

toevoegen, vernietigen of kennisnemen van informatie tot een gedefinieerde groep

van gerechtigden.

Waarde Niet voldoen leidt tot

Zeer Hoog Vragen in de Tweede Kamer; maatschappelijke onrust; levensbedreigende

situaties; grote financiële gevolgen voor de Nederlandse overheid.

Hoog Financiële consequenties (op den duur); vragen/klachten bij het management;

vragen in de Raad van Toezicht of door de Minister; negatieve publiciteit.

Midden Vragen/klachten bij gebruikers/klanten; vragen/klachten bij het management.

Laag Geen gevolgen (alleen vervelend).

Zeer Laag Niet relevant/niet van toepassing.

De overall classificatie van IAM voorzieningen wordt bepaald door de

overall classificatie van de andere DSO voorzieningen. Voor de delen van IAM waarin beheer van identiteiten en autorisaties plaats vindt is de

classificatie minstens even hoog.


Deelprogramma DSO

5.2 Beschikbaarheid

De beschikbaarheid van alle producten die IAM gebruiksfuncties

realiseren / het proces gebruiken IAM realiseren moet worden geclassificeerd als tenminste even hoog als de hoogste geclassificeerde

toepassing die IAM gebruikt. Als de beschikbaarheid van IAM het laat afweten zal dit de beschikbaarheid van iedere component / toepassing

die IAM nodig heeft raken.

Van de IAM registratiefuncties kan een lagere beschikbaarheid worden geaccepteerd. Dat neemt niet weg dat ook voor het kunnen aansluiten

van nieuwe apps, voor het registreren van machtigingen etc. een hoge beschikbaarheid wordt verwacht die aansluit bij

gebruikersverwachtingen (duidelijk meer dan kantoortijden).

In de volgende tabel wordt per bedrijfsservices de classificatie geduid

waarbij afgeweken kan worden bovenstaande algemene insteek.

Bedrijfsservice Classificatie Toelichting

Alle bedrijfsservices

die

toegangsservices

benutten.

Hoog De hoogste huidige classificatie van een bedrijfsservice die

IAM benut.

5.3 Integriteit

De integriteit van het alle IAM functies en componenten moet worden

geclassificeerd op de hoogste integriteitsclassificatie die binnen DSO voorkomt. Integriteit van "wie wat gedaan heeft" is een schakel in de

gehele beveiliging en privacyborging. IAM mag niet de zwakste schakel

zijn.

Bepaalde IAM gegevens zijn erg gevoelig voor gebreken in de integriteit. Voor deze gegevens zijn aanvullende integriteitschecks

belangrijk:

Unieke nummers Tokens

Publieke delen sleutelmateriaal Certificaten

Vastgelegde autorisaties

Deze gegevens worden grotendeels beheerd binnen het Standaard Platform en vallen dus onder de BIR compliancy daarvan. Alle

bovengenoemde IAM gegevens worden in de componenten die


Deelprogramma DSO

toegangsservices benutten verwerkt op basis van ondertekende berichten, hetzij SAML tokens, hetzij certificaten. Als onderdeel van de

secure coding richtlijnen dient zorgvuldige omgang met gegevens die uit deze beveiligde berichten komen te worden gecontroleerd.

Controle van de beveiligde berichten zelf vindt in principe weer plaats in

applicatieservers binnen SP. Waar dit uitbesteed is aan andere infrastructuren, ook voor wat betreft informatiehuizen, dient de

verantwoordelijkheid voor deze controle te zijn overgedragen.

In de volgende tabel wordt per bedrijfsservices de classificatie geduid waarbij afgeweken kan worden bovenstaande algemene insteek.


Standaard platform

infrastructuur

Hoog Dit is strikt genomen geen "DSO" bedrijfsservice maar een

bedrijfsservice van de Alliantie / SP die wordt benut en

waarvan DSO afhankelijk is.

Infrastructuren van

DSO partners en

informatiehuizen

Hoog De classificatie en bijbehorende eisen vanuit DSO moeten

opgelegd worden aan deze partners in de zin dat zijn

verantwoordelijk moeten zijn voor controle van beveiligde

berichten en veilige omgang met de daarin opgenomen

gegevens.

Ontsluiten

samenwerkmap

Hoog De samenwerking met de diensten rond samenwerking ten

aanzien van machtigingen stelt eisen aan de integriteit van de

onderliggende componenten. Deze componenten moeten

beveiligd zijn tegen het zodanig wijzigen van credentials en

autorisaties dat toegang verkregen wordt tot gegevens

waartoe geen autorisatie bestaat.

Ontsluiten content Midden Deze componenten moeten beveiligd zijn tegen het zodanig

wijzigen van credentials en autorisaties dat toegang

verkregen wordt tot gegevens waartoe geen autorisatie

bestaat.

Zoeken Hoog Aangezien zoeken ook betrekking heeft op het zoeken in

gegevens waartoe toegang beperkt is tot geautoriseerden.

Deze componenten moeten beveiligd zijn tegen het zodanig

wijzigen van credentials en autorisaties dat toegang

verkregen wordt tot gegevens waartoe geen autorisatie

bestaat.

5.4 Vertrouwelijkheid

De vertrouwelijkheid van de IAM functies en componenten betreft met name bepaalde gegevens(groepen). In IAM worden persoonsgegevens

verwerkt. Als de vertrouwelijkheid het laat afweten is er al snel sprake

van een datalek dat gemeld moet worden, bovendien vormt inbreuk in de vertrouwelijkheid van IAM gegevens een opzet naar andere

inbreuken.


Deelprogramma DSO

IAM gegevensgroep Classificatie Toelichting

Persoonsgegevens

algemeen

Hoog Geen bijzondere persoonsgegevens

BSN Hoog

Credentials die

toegang geven tot

gevoelige

bedrijfsinfo

Hoog

Nota bene: openheid en openbaarheid worden wel gezien als

tegengesteld aan vertrouwelijkheid. Openbaarheid kan echter ook aanleiding geven tot nieuwe eisen. Openbaarheid in DSO [verwijs naar

GPvE nummers] wordt opgevat als: - Alle gebruikers hebben toegang tot dezelfde openbare gegevens

- De presentatie van de gegevens kan worden aangepast aan de doelgroep. Dit mag echter niet leiden tot het filteren van

gegevens of het moeilijk toegankelijk maken van openbare gegevens

- Er is geen sprake van gegarandeerde anonimiteit. Het feit dat een bepaalde partij op een bepaald moment bepaalde gegevens inziet

is niet vertrouwelijk. - Er is geen sprake van rapportageverplichtingen die het

noodzakelijk maken om te registreren welke partij welke openbare gegevens wanneer inziet.

- Er kan sprake zijn van verschillende service levels voor

verschillende doelgroepen. Deze eisen gelden voor de aanvullende classificatie "openbaar".

Door per bedrijfsservice te bepalen waar bovengenoemde

gegevensgroepen verwerkt worden ontstaat de classificatie bedrijfsservice.


Alle Hoog De secure coding en DSO beveiligingseisen moeten volstaan

om vertrouwelijkheid van IAM gegevens binnen de

componenten te garanderen.

5.5 Betrouwbaarheidsniveaus

Uit bovengenoemde beveiligingsclassificaties van producten en

gegevens in het DSO volgen de betrouwbaarheidsniveaus die gevraagd moeten worden voor de authenticatie van gebruikers.

Op grond van eIDAS verordening (zie § 2.1.3) zijn deze

betrouwbaarheidsniveaus gestandaardiseerd op drie niveaus:


Deelprogramma DSO

Laag

Substantieel Hoog

De criteria om het vereiste niveau te bepalen moeten toegepast worden

op iedere DSO dienst (bedrijfsservice) afzonderlijk. Op grond van BSN verwerking in combinatie met andere persoonsgegevens en op grond

van mogelijk economisch belang geldt voor een aantal DSO diensten en doelgroepen de classificatie substantieel.

Wanneer deze toegepast worden op DSO dan leidt dit tot de volgende

classificatie:


Services voor

Bevoegd Gezagen

Substantieel Op grond van baselines is 2 factor authenticatie vereist.

Services voor

samenwerking

Substantieel Voor Gebruikers (Burgers en Bedrijven) die dat wensen moet

Substantieel mogelijk zijn. Nader te bepalen of het vanuit

DSO geaccepteerd wordt indien Gebruikers zelf voor lager

betrouwbaarheidsniveau kiezen.

Qua technische uitvoering moet het betrouwbaarheidsniveau als

parameter worden doorgegeven zodat het mogelijk blijft diensten op

een lager niveau aan te bieden en zodat – indien nodig – later ook een dienst op hoger betrouwbaarheidsniveau ingericht kan worden.


Deelprogramma DSO

6 Principes

Kaders- en richtlijnen waaraan de realisatie en beheer van het Digitaal Stelsel Omgevingswet gehouden is worden als principes geformuleerd.

Afwijken van de principes is alleen toegestaan na akkoord van de lead architect PDSO. Dit hoofdstuk beschrijft de principes.

De principes volgen het NORA 9+2 vlaksmodel, een raamwerk dat ook

gehanteerd wordt in de Nederlandse Overheid Referentie Architectuur (NORA) en afgeleide architecturen. Zie de laatste versie van het

document “DSO - Architectuur - Toelichting principes” voor een toelichting hoe principes beschreven zijn.

6.1 Overzicht

Hieronder worden de principes opgesomd die in het DSO worden gehanteerd. In deze lijst is aangegeven welke van toepassing zijn voor

deze GAS.

De principes zijn gewogen naar het belang dat ze hebben voor deze voorziening.

Codering Omschrijving

X Aan voldoen zonder aanvullende eisen zie verder overall gas.

XX Aanvullende eisen formuleren

XXX Belangrijk voor deze voorziening

Leeg Niet relevant voor dit project

Identificatie Statement Van toepassing

DSO2 - BA Het stelsel functioneert als 1 geheel voor zowel personen als

systemen.

XXX

Continuïteit en compliance is geborgd XXX

DSO4 - IA Oplossingen zijn eenvoudig, generiek en kosten effectief. X

DSO5 - IA Alles is een service. X

DSO7 - IA Hergebruik voor koop voor maak X

DSO10 - BH Beheerfunctionaliteit is primaire functionaliteit XX

DSO09 - BP Passende beveiliging & privacy op basis van reële risico’s. XX

Hierna wordt voor elke principe die van toepassing is, aangegeven hoe

deze ingevuld wordt voor deze GAS. Om duplicatie van teksten in de OGAS te voorkomen worden op de identificatie, statement en eisen na


Deelprogramma DSO

de andere standaard onderdelen van een principe weggelaten. Hiervoor kan de OGAS geraadpleegd worden.

6.2 Business architectuur

6.2.1 Organisatie

Identificatie DSO2 - BA

Statement Het stelsel functioneert als 1 geheel voor zowel personen als systemen.

Eisen Eindgebruikers hoeven maar één keer in te loggen, ook als er voor het proces dat ze

doorlopen gegevens uitgewisseld worden met informatiehuizen.

Naadloze overgang van personalisatie naar functies achter de inlog

Identificatie DSO8 - BP

Statement Continuïteit en compliance is geborgd

Eisen Betrouwbare authenticatie van partijen, weten wat deze partijen wel en niet mogen en

dit kunnen controleren en aantonen is voor een digitaal stelsel wezenlijk. De IAM

voorziening is daarvoor noodzakelijk.

6.2.2 Diensten & Producten

Identificatie DSO4 - IA

Statement Oplossingen zijn eenvoudig, generiek en kosten effectief.

Eisen IAM wordt (vrijwel) geheel ingevuld met GDI en standaard infrastructuur componenten,

aangevuld met platformservices die door het Knooppunt geleverd worden. Daardoor zijn

er geen diensten op bedrijfsniveau. IAM vormt één product dat ondersteunend is aan het

DSO.

6.2.3 Processen

Identificatie DSO10 - BH

Statement Beheerfunctionaliteit is primaire functionaliteit

Eisen Voor het beheer van IAM gegevens, identiteiten en authenticatiemiddelen van overige

gebruikers en machtigingen met een fijnmazigheid die verder gaat dan de GDI zijn

registratieprocessen onderdeel van het algemene DSO beheerproces.


Deelprogramma DSO

6.3 Informatiearchitectuur

6.3.1 Medewerkers en Applicaties

Identificatie DSO5 - IA

Statement Alles is een service.

Eisen Toegangsservices zijn services. Deze zijn ieder beperkt in scope. Er is een losstaande

service voor authenticatie, voor autorisatie en voor het ophalen van gebruikersgegevens.

6.3.2 Gegevens

De voor IAM relevante gegevens betreffen niet de primaire DSO gegevens waarvoor het principe

van openheid relevant is.

6.3.3 Informatie-uitwisseling

DSO7 - IA

Statement Hergebruik voor koop voor maak

Eisen Bij keuzes aangaande informatie-uitwisselingsstandaarden is niet alleen de formele

standaard (SAML) het uitgangspunt maar ook de vraag welke delen daarvan "standaard"

(plain vanilla) geleverd worden in relevante open source componenten en veel gebruikte

componenten op de markt.

6.4 Beheer

Identificatie DSO10 - BH

Statement Beheerfunctionaliteit is primaire functionaliteit

Eisen De IAM functionaliteit kan gezien worden als onderdeel van deze "primaire"

beheerfunctionaliteit.

6.5 Beveiliging & privacy

Identificatie DSO9 - BP

Statement Passende beveiliging & privacy op basis van reële risico’s.

Eisen Baseline conforme IAM


Deelprogramma DSO

7 Standaarden

In dit hoofdstuk worden de standaarden benoemd die van toepassing zijn bij het ontwikkelen van GAS IAM.

7.1 Forum Standaardisatie

De volgende standaarden van de lijst van het Forum Standaardisatie

(http://www.forumstandaardisatie.nl) worden toegepast voor IAM:

Naam Omschrijving Bron Beherende

organisatie

Versie Informatie

SAML Security Assertion Markup Language

PTOLU OASIS 2.0 T.b.v. uitwisseling

van authenticatie-

en

autorisatietokens

ISO 27001 /

27002

Informatiebeveiliging. Van

toepassing op

toegangsbeleid

PTOLU ISO / NEN 2013 In samenhang met

de baselines van

toepassing. Via

deze baselines zal

ook nieuwe versie

worden

doorgevoerd.

Digitale Toe-

gankelijkheid

(Webrichtlijne

n)

Toegankelijkheid user

interface

PTOLU ETSI EN 301

549

Wordt ook

onderdeel van

wettelijke GDI

verplichting.

W3C WGAC

2.0

Er zijn geen andere standaarden op de Pas-toe-of-leg-uit lijst met een voor IAM binnen DSO relevant toepassingsgebied. Bovengenoemde

standaarden worden onderdeel van de wettelijke verplichting op grond

van de wet GDI.

7.2 Overige standaarden

Dit zijn aanvullende standaarden die niet bij het Forum Standaardisatie voorgeschreven worden, met uitzondering van XACML betreft het

standaarden die voorkomen op de lijst van gangbare standaarden.

Naam Omschrijving Bron Beherende

organisatie

Versie Informatie

https Onderliggende standaard

voor SAML

IETF TLS 1.2

XML SAML is XML W3C 1.1

http://www.forumstandaardisatie.nl/


Deelprogramma DSO

OAuth Voor authenticatie en

autorisatie vanuit Apps

IETF 2.0

XACML Standaard voor autorisatie- en

rol informatie in samenhang

met SAML

Oasis Alleen relevant

indien voor

toepassing van

deze standaard

binnen GDI

gekozen wordt. Dat

is niet de

verwachte richting.

PKIoverheid Voorgeschreven standaard

voor PKI certificaten binnen

Nederlandse Overheid.

Voorschrift volgt o.a. uit

diverse andere standaarden

zoals DigiKoppeling en

aansluitvoorwaarden van GDI.

Logius Logius 4.4 Het PvE PKI

overheid is niet

statisch. Als

standaard geldt

steeds de meest

recente versie plus

de gepubliceerde

wijzigingen, zie

https://www.logius.

nl/ondersteuning/p

kioverheid/aansluit

en-als-

tsp/programma-

van-eisen/actuele-

wijzigingen/


Deelprogramma DSO

8 Roadmap

In dit hoofdstuk wordt de roadmap beschreven om het eindbeeld in controleerbare en haalbare stappen te realiseren: van IST naar SOLL

met de tussenstappen. Per situatie wordt kort beschreven wat het verschil is met de voorgaande stap en toegelicht waarom deze stap

nodig is. Tussenstappen zijn expliciet gemaakt en er wordt aangegeven of het een logische tussenstap is of een afwijking. Indien het een

afwijking is, wordt aangegeven wanneer deze afwijking weer in lijn gebracht moet worden met het eindbeeld.

[B1] Het Digitaal Stelsel Omgevingswet wordt interbestuurlijk en

stapsgewijs ontwikkeld.

[B2] Investeringen vinden plaats waar deze het meest renderen. [B4] Minimaliseren beheerlast bronhouders en bevoegd gezagen

[B5] Er is ruimte voor innovatie en flexibiliteit [D1] Gebruik van referentiearchitecturen

[D2] Hergebruik van functies [D3] Standaardisatie

[IAM]: IAM benut een standaard platform voor infrastructuur (IaaS), ontwikkelstraat (PaaS) en zoveel mogelijk bijbehorende

generieke ICT voorzieningen. Benutten van GDI bouwblokken vindt zo standaard mogelijk via dit standaard platform plaats.

Het toe te passen standaard platform is SP van de Alliantie / IenM In hoeverre moet rekening gehouden worden (in de architectuur)

met vervanging van dit standaardplatform door een andere implementatie ervan?

8.1 Huidige situatie: OLO2, AIM en LRO

De huidige situatie wordt bepaald door OLO2, AIM,

ruimtelijkeplannen.nl en LRO loket. Op OLO2 kan zowel met DigiD als met eHerkenning worden aangelogd. Daarnaast is er een

gebruikersnaam - wachtwoord voor overige gebruikers. Er is echter geen sprake van toegang voor bevoegd gezagen voor planvormings-,

vergunningsverlenings- of VTH-processen.

Voor DSO wordt dezelfde werkwijze voortgezet. Zowel voor DigiD als voor eHerkenning geldt dat daarbij nieuwe ontwikkelingen worden

meegenomen: mogelijk hogere betrouwbaarheidsniveaus, striktere eisen aan BSN gebruik en privacy enhancing, single sign on, volledige

toepassing SAML standaard, machtigen, eIDAS.


Deelprogramma DSO

8.2 IAM realisatie volgt opbouw DSO platform

Omdat IAM een ondersteunende functie is wordt deze gedurende 2017

parallel aan de primaire DSO functionaliteit ontwikkeld. Non functionele requirements en architectuur zijn daarbij de bepalende drijfveren. Zodra

de eerste voorzieningen van DSO daadwerkelijk in productie gaan, moet de basis van IAM gerealiseerd zijn.

Als tussenstap worden IAM voorzieningen voor de pre-productie

omgeving gerealiseerd. Voor goede ketentesten is het noodzakelijk dat IAM voorzieningen in pre-productie "productie-conform" zijn.

De capabilities worden in de volgende volgorde gerealiseerd:

1. Toegang Burgers

2. Toegang overige (DSO) Gebruikers 3. Autorisatie

4. Toegang Bevoegd Gezagen 5. Toegang Bedrijven

6. App koppeling 7. Machtigingen

Het toepassen van privacy enhancing via de BSN-koppelvoorziening en

het aansluiten van nieuwe versies van DigiD en eHerkenning / Idensys volgt het ontwikkeltempo van deze GDI. Hetzelfde geldt voor de eIDAS

voorzieningen voor Gebruikers vanuit andere EU landen.

Het volgen van het ontwikkeltempo van de GDI betekent dat DSO geen eigen koppeling zal maken met bijvoorbeeld iDIN, maar zal wachten

totdat dergelijke voorzieningen toegankelijk worden via aangepaste

versies van de huidige GDI componenten.

8.3 Eindsituatie (2024)

In de eindsituatie is sprake van volledig gebruik en blijvende doorontwikkeling die meebeweegt met de ontwikkeling van de GDI

voorzieningen rond het eID stelsel. DigiD en eHerkenning zullen daarin opgaan, evenals de eIDAS voorzieningen.

De groep overige gebruikers wordt daarbij zo klein mogelijk gehouden.

Onzeker is op welke termijn er binnen de overheid standaardisatie van

authenticatie vanuit een app plaats vindt. Zolang dat niet het geval is en geen onderdeel van de GDI zal DSO daarvoor eigen voorzieningen

leveren.


Deelprogramma DSO

9 Bijlage A: Openstaande punten

In deze bijlage worden de nog openstaande punten opgesomd. Referentie Openstaand punt Maatregel

1 Uitwerking naadloze gebruikerservaring ten

aanzien van personalisatie en inloggen.

Samenhang met sessiemanagement en

permalink.

Bespreken met PR02, PR12

2 Bestaan er specifieke afschermingseisen

voor informatie die alleen de rechterlijke

macht mag inzien? Dat is bepalend voor de

vraag of dit voor IAM een actor is met

specifieke eisen.

On-hold tot specfieke eisen bij

opdrachtgever bekend zijn..

3 Uitwerking samenwerking en machtigingen.

Bestaat fijnmazige machtigen ook los van

samenwerking in mappen? Of kan alle

machtigingsbehoefte die niet aan mappen zit

uitbesteed worden aan DigiD Machtigen en

eHerkenning (dan vervalt de business

service registreren machtiging als

afzonderlijke service).

Bespreken met PR02

4 Uitwerking samenwerking en autorisaties, in

het bijzonder voor samenwerking door

Bevoegd Gezagen. Rollenmodel.

Definitiestudie afwachten

5 Consequenties van de keuze dat Bevoegd

Gezagen in principe op basis van

eHerkenning inloggen en hun medewerkers

machtigen. Is er intern voldoende aandacht

voor mandatering.

Bespreken in kader van GAS review

6 Consequenties van architectuur die

voorbereid is op BSN-k pseudoniemen in

plaats van BSN


7 Standaarden voor opvragen van gegevens

waarvoor doelbinding vereist is bij

informatiehuizen


8 Scope van single sign on (wanneer wel en

niet) in relatie tot gebruikerservaring en

eIDAS eisen


9 Welk betrouwbaarheidsniveau voor DSO?

Eén of meer? Consequenties van keuze voor

Substantieel en openstelling voor EU.

Bespreken met PR02, PR12, PR08, PR30

10 Wijze waarop vertrouwen tussen partijen die

in kader van DSO een overheidstaak

vervullen wordt vastgelegd. Dit betreft zowel

de partijen die DSO leveren, als de bevoegd

gezagen (en dienstverleners die taken voor

hen uitvoeren). Wat is het aanmeldproces?

Welke verantwoordelijkheden? Is enkel PKIo

voldoende?

Bespreken met Manager Integratie (Chris

Boeije). Aspect voor domeinarchitecten. Zie

risico's als geconstateerd in risicosessie

PR29.

11 Uitwerking machtigingen in geval van

systeem - systeem gegevensuitwisseling.

Bespreken met PR05

Met opmerkingen [BC3]: Gedaan.Geen GAS onderwerp meer.

Met opmerkingen [BC4]: Geen onderdeel

basisniveau,schrappen.

Met opmerkingen [BC5]: Opnemen in beschijving

Machtigen

Met opmerkingen [BC6]: Zie GAS Samenwerken

Met opmerkingen [BC7]: Voldoende ingedaald nu. Geen open punt.

Met opmerkingen [BC8]: Blijft open

Met opmerkingen [BC9]: Geen vervolgactie.

Met opmerkingen [BC10]: Geen basisniveau.

Met opmerkingen [BC11]: Wordt op beleidsniveau bepaald.

Met opmerkingen [BC12]: Vooralsnog PKIO voldoende.

Met opmerkingen [BC13]: Is onderdeel Logius Machtigen Systeem-Systeem


Deelprogramma DSO

12 Bepalen welke gebruikersgegevens nodig

zijn en welke autorisatiebesluiten daarvoor

vereist zijn.

Bespreken met PR12, PR08, PR30

13 Hoe moet het principe om standaard IaaS en

PaaS bouwblokken te gebruiken worden

opgevat: hoe dan ook benutten Standaard

Platform of architectuur gericht op open

standaarden zodat migratie naar andere

implementaties van vergelijkbare IaaS en

PaaS platformen mogelijk is? Let wel: er is

niet één standaard, er zijn hoe dan ook

afhankelijkheden van gekozen

technologiestack.

Verduidelijking vragen aan stelselarchitecten

14 Bepalen afbakening DSO diensten ten

behoeve van het opgeven van machtigingen

via DigiD / eHerkenning GDI.

Bespreken met o.a. met project UIVO-i

15 Bepalen of het wenselijk is Priviliged Access

/ Account / Identity Management toe te

passen voor DSO-beheerders en andere

specifieke functionarissen.

Bespreken met SP en inrichting beheer.

Met opmerkingen [BC14]: Afgerond

Met opmerkingen [BC15]: Afsluiten

Met opmerkingen [BC16]: Vooralsnog 1 dienst Opstellen en Indienen gedefinieerd.

Met opmerkingen [BC17]: Open, afstemmen Beheer, is beleid OBO


Deelprogramma DSO

10 Bijlage B: Bronnen

In deze bijlage worden de voor dit document gebruikte bronnen beschreven.

Referentie Document Omschrijving

Handreiking betrouwbaarheidsniveaus versie 4

www.forumstandaardisatie.nl/thema/handreiking-

betrouwbaarheidsniveaus

Overall GAS versie 1.34

Globaal Programma van Eisen 1.0

Doelarchitectuur 2.0

Met opmerkingen [BC18]: Notities Machtigen en eIDAS.


Deelprogramma DSO

11 Bijlage C: Aanvullende specifieke begrippen

Uit DSO - Architectuur - Afkortingen Begrippen is slechts een beperkt aantal begrippen relevant, te weten:

Term Definitie Opmerking

Aanbieders Aanbieders leveren gegevens of

besluiten aan die via het DSO

toegankelijk zijn.

(§ 5.1.2 visie)

Het betreft o.a. bronhouders,

beheerders overige

registraties en generieke

gegevensverzamelingen,

informatiehuizen,

zorgdragers

Afnemer Afnemers van het Digitale

Stelsel Omgevingswet.

Doelarchitectuur § 5.1.2. stelt

dat de afnemers onder te

verdelen zijn in:

- eenieder

- initiatiefnemers

- belanghebbenden

- bevoegd gezagen

In visie is afnemer breder

dan gebruiker, uitdrukkelijk

incl. softwareleveranciers en

andere derden (§5). In

OGAS 1.34 is dat ook het

geval: "Afnemers (binnen en

buiten het stelsel) zijn

gebruikers van het stelsel

en/of ontwikkelen applicaties

die services uit het stelsel

afnemen. Afnemers zijn

Eenieder (anonieme

toegang), Initiatiefnemer,

Belanghebbende, Bevoegd

gezag, Derden en

Rechterlijke macht."

Term wordt ook benut in de

definitie van dienst en in de

zin van afnemer en

aanbieder aan beide zijden

van het stelsel/platform.

Afnemers van DSO zijn dus

bevoegd gezagen in hun rol

in een keten, hun software

leveranciers, derden die

software maken etc.

Belanghebbende Degene wiens belang

rechtstreeks bij een besluit is

betrokken.

Artikel 1:2 lid 1 Awb

Bevoegd gezag Het bestuursorgaan dat

bevoegd is een bepaald besluit

te nemen of een handeling uit

te voeren.

Artikel 1:1 lid 1 Awb

Derden Softwareleveranciers die

applicatie services van het

stelsel afnemen. Dit kunnen

leveranciers van app’s zijn die

Zijn er nog andere derden

dan softwareleveranciers en

app bouwers, aangenomen

wordt van niet.


Deelprogramma DSO

waarde toevoegende diensten

leveren of leveranciers van zaak

systemen aan de bevoegd

gezagen (OGAS 1.34).

Omvat ook app bouwers, deze

apps nemen immers applicatie

services af.

In § 3.1 van de visie worden

derden en

softwareleveranciers juist

onderscheiden. Daar zijn de

softwareleveranciers als

gemachtigden van b.v.

bevoegd gezagen actief, daar

betreft het een andere groep

softwareleveranciers die

uitvoerend optreden namens

een overheidsorganisatie,

veelal met een clouddienst.

Eenieder Iedere persoon voor wie de

Omgevingswet relevant is.

Personen met een andere rol

zullen DSO soms ook als

"eenieder" gebruiken.

Gebruiker Gebruikers van DSO zijn

eenieder, initiatiefnemers,

belanghebbenden en bevoegd

gezagen.

Deze zijn onderscheiden van

derden die onder het bredere

begrip afnemer vallen en ook

softwareleveranciers etc.

omvatten.

Gebruikers zijn afnemers

Initiatiefnemer Burgers, bedrijven en

overheidsorganisaties die iets

willen in de fysieke

leefomgeving (OGAS 1.34).

Zie ook begrippen in visie

Begrip Toelichting

Authenticatie Authenticatie is het proces waarbij iemand nagaat of een

gebruiker, een andere computer of applicatie daadwerkelijk

is wie hij beweert te zijn. Bij de authenticatie wordt

gecontroleerd of een opgegeven bewijs van identiteit

overeenkomt met echtheidskenmerken, bijvoorbeeld een in

het systeem geregistreerd bewijs. De authenticiteit van het

object moet worden nagegaan. Een digitaal systeem met

daarvoor ontworpen toepassingen kan hierbij helpen.

Authenticatie volgt op identificatie, bij de voorbeelden

aldaar:

Authenticatie is de controle dat een ingevoerd

wachtwoord overeenkomt met het geregistreerde

wachtwoord en hoort bij de opgegeven gebruikersnaam.

Authenticatie is dat een getoonde vingerafrduk

overeenkomt met de geregistreerde vingerafdruk van de

gebruiker.


Deelprogramma DSO

Authenticatie is dat het door de token gegenereerde

cryptografische geheim overeenkomt met het voor die

token verwachtte geheim.

Autorisatie Autorisatie is het proces onder verantwoordelijkheid van een

dienstverlener waarin bepaald wordt of een subject (een

persoon of een proces) toegang krijgt tot een object (een

bestand, een systeem).

Het subject kan daarbij een menselijke eindgebruiker zijn of

een technisch systeem of proces.

Bij autorisatie zijn twee partijen relevant: de dienstverlener

en het subject. De verantwoordelijkheden liggen bij de

dienstverlener, het betreft een proces dat zich afspeelt

binnen deze dienstverlener.

In een ICT voorziening wordt een autorisatie vastgelegd in

toegangsrechten. Het verlenen van toegang zal gebaseerd

zijn op de in toegangsrechten vastgelegde autorisatie.

Het (vooraf) vastleggen van autorisatie is taalkundig moeilijk

te onderscheiden van het moment waarop iedere keer dat de

gebruiker de dienst benaderd gecontroleerd wordt of hij een

geldige autorisatie bezit. Daarom is het voor dat laatste

duidelijker te spreken over „toegang verlenen” of „een

toegangsbeslissing nemen”. Met verlenen van autorisatie

bedoelen we dan het vastleggen van een autorisatie in

toegangsrechten zodat deze steeds gebruikt kan worden.

Dienst Een afgebakende prestatie van een persoon of organisatie

(de dienstverlener), die voorziet in een behoefte van haar

omgeving (de afnemers).

[NORA]

Identificatie Identificatie is het kenbaar maken van de identiteit van een

subject (een gebruiker, gegeven of een proces) in de

informatietechnologie. De identiteit wordt gebruikt in de

vervolgstappen van IAM: authenticatie en autorisatie. Een

object is bijvoorbeeld een computerbestand of een regel in

een database.

Identificatie kan op verschillende manieren plaatsvinden:

in een inlogscherm invoeren van een gebruikersnaam,

userid, DigiD, Idensys

gebruik van een vingerafdruk of een ander biometrisch

kenmerk

gebruik van een token (een smartcard of een ander

apparaatje, zoals een usb stick).

Knooppunt Een voorziening of organisatie die het afnemers makkelijk

maakt aan te sluiten op beschikbare gegevensbronnen

[NORA]

Machtiging Machtiging is een herroepbaar recht van een persoon om een

handeling te verrichten in naam van een andere persoon;


Deelprogramma DSO

een recht dat door deze ander (de vertegenwoordigde)

verleend wordt aan eerstgenoemde persoon (de

gemachtigde).

Een machtiging kan algemeen of bijzonder zijn. Een

bijzondere machtiging is beperkt tot bepaalde

(rechts)handelingen of een bepaalde relevante omvang ten

aanzien van (rechts)handelingen.

Machtiging kan worden gezien als synoniem aan volmacht zij

het dat de term machtiging voornamelijk in

bestuursrechtelijke context wordt gebruikt.

Machtiging is een meer juridisch begrip. Bij machtiging zijn

drie partijen relevant: de vertegenwoordigde, de

gemachtigde en derden (de dienstverlener). Het gaat om de

verantwoordelijkheden van vertegenwoordiger en

gemachtigde. Voor derden „maakt het niet uit” wie van

beiden een dienst afneemt, zolang vertegenwoordiger en

gemachtigde het onderling geregeld hebben. De focus van

de verantwoordelijkheden ligt dus heel anders dan bij

autorisatie.

Nota bene: als de vertegenwoordigde dezelfde partij is als de

dienstverlener dan lijkt een machtiging heel erg op een

autorisatie. Dat is het geval wanneer een organisatie een

medewerker machtigt. Juridisch is die machtiging vaak

impliciet, maar in het geval van een formele

mandateringsstructuur is het juist heel expliciet. De

autorisatie is dan het technische effect in een ICT systeem

van een machtiging. Maar een machtiging van een niet

digitaal vaardige burger aan een familielid is een voorbeeld

waar machtiging die duidelijk onderscheiden is van

autorisatie.

Partij Natuurlijk persoon, rechtspersoon of samenwerkingsverband

van personen. In de DSO context zijn o.a. Aanbieders,

Afnemers, Derden, Verstrekkers en de DSO

Stelselverantwoordelijke partijen.

Deelprogramma Digitaal Stelsel Omgevingswet · 2019-10-31 · In hoofdstuk 8 wordt de roadmap...

Documents

Transcript of Deelprogramma Digitaal Stelsel Omgevingswet · 2019-10-31 · In hoofdstuk 8 wordt de roadmap...