Expertgroep Digitale Identificatie en authenticatie/2019-09-03: verschil tussen versies

Uit NORA Online
Naar navigatie springen Naar zoeken springen
(Agenda toegevoegd)
k (afbeelding van left naar none)
 
(21 tussenliggende versies door 3 gebruikers niet weergegeven)
Regel 8: Regel 8:
|Publicatiedatum=
|Publicatiedatum=
|Nieuws=nee
|Nieuws=nee
|Beschrijving=Onderwerp: [[Bevoegdhedenbeheer]] c.q. autorisatiemanagement. <br>
Kees Jan Kolb van het Erasmus MC zal ervaringen delen over hoe je kunt omgaan met ABAC in relatie tot de bestaande implementaties van RBAC.
Mogelijk kunnen we dan ook al de 1e resultaten bespreken van de uitwerking van Authenticatie van natuurlijke personen i.r.t. de BRP.
}}
}}






==Huishoudelijk==
* Onze gastheer is Menno Stigter – tel. 0652098068
* Inloop vanaf 13.30 uur, begin 14.00 uur, einde rond 17.00 uur
* Bij de locatie zelf is geen parkeergelegenheid, maar je kan gratis parkeren op de Laakkade
(dit is aan de achterzijde van het kantoor, ca 5 minuten lopen)
* Internet: govroam en free-wifi Den Haag


==Agenda==
==Verslag==
Het was wederom een informatieve (en lange 😊) bijeenkomst.
Ditmaal bij de gemeente Den Haag, waar we zo’n anderhalf jaar geleden een van de eerste bijeenkomsten hielden met de expertgroep IAM.
Bijgaand is op hoofdlijnen aangegeven wat we met elkaar hebben besproken en afgesproken.


===Welkom en voorstelrondje 15 min===


===Verslag en actiepunten van vorige keer 15 min===
==Actiepunten==
Zie [Expertgroep Digitale Identificatie en authenticatie/2019-07-24]  
We hebben de actiepunten van de bijeenkomst van 24 juli doorgenomen, zie het verslag [[Expertgroep Digitale Identificatie en authenticatie/2019-07-24]]
* Eric Brouwer en Menno Stigter bespreken met GEMMA Beheer of en zo ja hoe ArchiMate modellen opgenomen kunnen worden bij de processen van Identiteitenbeheer.
Er waren nog 2 openstaande actiepunten en die zijn inmiddels opgepakt:
* Menno Stigter gaat na wie / welke organisatie een registratie voert voor “vreemdelingen” die niet in de BRP (RNI) worden geregistreerd.
* NORA Beheer is bij GEMMA Beheer nagegaan of, en zo ja hoe ArchiMate modellen opgenomen kunnen worden bij de processen van Identiteitenbeheer. Het lijkt er op dat in de GEMMA geen specifieke processen zijn beschreven voor het identiteitenbeheer. De GEMMA heeft wel meer algemene processen (typeringen), waar zo’n proces van Identiteitenbeheer onder zou kunnen vallen.  
''': → ACTIE: Afgesproken is e.e.a. nog met elkaar te gaan bespreken. Voorstel is om de plaatjes voorlopig op te nemen in de NORA.'''
* Het COA is de organisatie die een registratie voert voor “vreemdelingen” die niet in de BRP (RNI) worden geregistreerd. Deze informatie is inmiddels opgenomen in de beschrijving van het Identiteitenbeheer van natuurlijke personen.
 
===Stand van zaken Identiteitenbeheer 15 min===
==Identiteitenbeheer==
Bob te Riele neemt ons mee naar de laatste versie en licht toe wat door RvIG is aangepast n.a.v. de eerder gemaakte opmerkingen.
Bob te Riele en enkele collega’s van RvIG (met name ook Frans Rijkers) hebben de teksten van het [[Identiteitenbeheer]] van natuurlijke personen al deels aangepast n.a.v. de eerder gemaakte opmerkingen. Ook is gekeken naar de opzet van de authenticatie van natuurlijke personen.  De aanvullingen die daarop van belang zijn, zullen worden verwerkt door de werkgroep Authenticatie, zie het kopje hieronder.  
Zie [https://www.noraonline.nl/wiki/Identiteitenbeheer| Identiteitenbeheer]
''': → ACTIE: Vanuit NORA Beheer gaan we na of alle gemaakte opmerkingen zijn verwerkt bij [[Identiteitenbeheer]]. Hierna kan de review kan plaatsvinden door Anne Schrijer (BZK) en Raymond Hofstra (Politie).  
'''
   
   
===Stand van zaken Authenticatie 15 min===
==Authenticatie==
Tijdens de vorige bijeenkomst hebben we de authenticatie van natuurlijke personen i.r.t. de BRP besproken en daar een soort werk-pakket van gemaakt, zie [https://www.noraonline.nl/wiki/Expertgroep_Digitale_Identificatie_en_authenticatie/2019-07-24#Authenticatie_van_natuurlijke_personen_i.r.t._de_BRP| Expertgroep Digitale Identificatie en authenticatie/2019-07-24]
Menno Stigter (gemeente Den Haag), Harro Kremer (DJI) en Anne Schrijer (BZK) hebben een eerste uitwerking gemaakt van de {{Bestand met info|Authenticatie_van_Natuurlijke_Personen_v022.pdf|Authenticatie van Natuurlijke Personen i.r.t de BRP}}. Deze uitwerking is plenair besproken.
Menno Stigter (gemeente Den Haag), Harro Kremer (DJI) en Anne Schrijer (BZK) hebben op basis daarvan een 1e uitwerking gemaakt (zie de 2 bijlagen) en lichten dat kort toe.
 
''': → ACTIE: De expertgroep zal de komende weken nog diverse aanpassingen doen, zoals:
* Omzetten naar het vijflaagsmodel van de NORA: om discussies te beslechten en vraagstukken te duiden;
* Dubbele tekststukken over natuurlijke personen en authenticatie verwijderen;
* Koppelvlakken van de voorzieningen toelichten;
* Op onderdelen de W&R toelichten: naast een analoge ID is nu ook een digitale ID nodig (denk aan de wet online identiteit en de pilot met virtuele ID’s);
* Een overzicht maken op het niveau van het IAM-kader en de relatie met de uitgewerkte pagina’s in de NORA over identiteitenbeheer en authenticatie;
* Antwoord geven op wat wordt bedoeld met het “proces van authenticatie op de BRP”.'''
 
 
==Identiteitenbeheer Bedrijven==
Jurriaan Raaijmakers (gemeente Almere), Wim Schut (Belastingdienst) en Henk Romein (DICTU) hebben een eerste uitwerking gemaakt van het document {{Bestand met info|NORA_-_Identiteitenbeheer_van_Bedrijven_versie_3sep19.pdf|Identiteitenbeheer van Bedrijven}}. Er wordt nog steeds gewerkt aan deze uitwerking, dus als je wilt kan je jouw opmerkingen nog toevoegen aan het document. Opmerkingen ontvangen we graag via [mailto:nora@ictu.nl nora@ictu.nl].
 
Uit de bespreking van dit document kwamen de volgende opmerkingen naar voren:
* We zijn op zoek naar de verschillende digitale identiteiten die in Nederland aan bedrijven worden toegekend en hoe dat proces verloopt;
* De opzet die nu is gemaakt gaan we z.s.m. publiceren, zodat we reacties daarop kunnen verkrijgen en verwerken;
* Vertegenwoordiging van de KvK zal daar expliciet bij worden betrokken;
* De begrippen en omschrijvingen zijn nog erg overlappend en onduidelijk. Het lijkt soms met name vanuit het perspectief van de Belastingdienst bezien;
* We willen meer als basis aanhouden hoe een register wordt onderhouden en door welke verantwoordelijke(n), zoals KvK met HandelsRegister (HR);
* De definities en nummers zullen worden uitgewerkt;
* Het OIN (door Logius beheerd) is een afspraak om uniciteit over alle domeinen heen te borgen, ook in de tijd gezien (meer info is te verkrijgen via Logius / Pieter Hering;
* De Handelsnaam is alleen unieke binnen een sector (zo’n sector is trouwens wat anders dan overheidsdomeinen!);
* De Statutaire Naam is waarschijnlijk wel uniek in Nederland;
* In het elektronische Toegangsdiensten (eTD) worden ook koppelvlakken en attributen / nummers beschreven;
* Internationaal: LEI en EORIE, De Legel Entity Identifier (LEI) wordt door KvK in NL en KvK’s in BL uitgegeven;
* eIDAS heeft ook een Legal Identifier: die lijkt op het OIN, maar wijkt af van de LEI;
* Een vraagstuk voor later: Hoe gaat een dienst-specifiek identificerend nummer werken (via pseudoniemen / BSNk e.d)?
 
Dat pakken we op irt “de wolk”: SSI, IRMA en DigitalMe, Attribute Services e.d., zie [[Hoe_pas_je_Identity_%26_Access_Management_toe%3F#Ontwikkelingen_waar_toepassing_in_de_toekomst_binnen_moet_passen| Ontwikkelingen waar toepassing in de toekomst binnen moet passen]].
* In het afsprakenstelsel eHerkenning is opgenomen aan welke kwaliteitseisen een digitale identiteit moet voldoen;
* PKIO heeft ook een normenkader voor digitale identiteiten;
* Een normenkader van het stelsel eID is er nog niet;


===Stand van zaken Identiteitenbeheer Bedrijven 15 min===
Tijdens de vorige bijeenkomst hebben we ook het identiteitenbeheer van bedrijven besproken en ook daar een werk-pakket van gemaakt, zie [https://www.noraonline.nl/wiki/Expertgroep_Digitale_Identificatie_en_authenticatie/2019-07-24#Identiteitenbeheer_van_bedrijven| Identiteitenbeheer van bedrijven]
Jurriaan Raaijmakers (gemeente Almere), Wim Schut (Belastingdienst) en Henk Romein (DICTU) hebben op basis daarvan een 1e opzet gemaakt en gaan die kort toelichten.
Er wordt nog steeds gewerkt aan deze opzet, ook komende week nog. Je kan die via Word Online bekijken en indien je dat wilt kan je jouw opmerkingen alvast toevoegen, zie  [https://1drv.ms/w/s!AuUxkCmyeBlcgYhBuw5YWTcDDYH0CQ| Word Online]
   
   
===Break 10 min===
==Beleidsstukken over IAM ==
Kees Jan Kolb (Erasmus MC) en Erik Kuijpers (UWV) hebben de Agenda Digitale Overheid / NL DIGIbeter en de beleidsbrief Regie op Gegevens (RoG) doorgenomen om na te gaan in hoeverre wij als expertgroep IAM invulling kunnen geven aan specifieke onderdelen van deze landelijke (beleids)kaders. Zie ook [[Expertgroep_Digitale_Identificatie_en_authenticatie/2019-07-24#Agenda_Digitale_Overheid_en_NL_DIGIbeter|Agenda Digitale Overheid en NL DIGIbeter]].
 
Hun bevindingen hebben ze gepresenteerd, {{Bestand met info|IAM_NORA_en_Wetgeving_Regie_op_gegevensv3.pdf|Wetgeving Regie op gegevens}} en we hebben daaruit het volgende geconcludeerd:
* Het gedachtegoed van NL DIGIbeter was ons op hoofdlijnen wel bekend, maar het was niet eerder zo expliciet en in samenhang benoemd;
* Naar onze inschatting is al veel beschikbaar van de benoemde toekomstbeelden;
* Met name van belang is een gemeenschappelijk beeld over digitale identiteiten van burgers en de wettelijke verankering ervan;.
* Regie op Gegevens (RoG) in de vorm van het op eigen initiatief van een burger laten delen van een basisset gegevens (of het door laten leveren) is nieuw, zeker via MijnOverheid.nl;
* RoG is een lopend programma dat zich daar op richt en IAM is daar een voorwaardelijk aspect voor. De vraag die bij ons voorligt is daarom: hoe gaan we RoG ondersteunen met onze kennis en ervaring?
 
* Hoe wordt omgegaan met “contacthistorie” (wie heeft wat namens jou gedaan met welke gegevens?);
* Is RoG zoals een blauwe knop: een onderdeel van een dienst digitaliseren? Dat is niet echt regie vanuit de burger.
* De huidige IAM uitgangspunten ondersteunen al grotendeels de uitgangspunten van RoG, echter hoe kan IAM er voor zorgen dat RoG op een veilige wijze verloopt?
* Wat is het ontwerp dat de architecten hierin voorstaan?
* Het zal waarschijnlijk niet alles linken aan een BSN.
* Mogelijk zal meer gedaan moeten worden met dataminimalisatie, polymorfe pseudoniemen en gebruiksregisters (audittrails);
* Het veilig gebruik van gegevens bevorderen;
* Faciliteren dat het doorleveren van gegevens wordt geregistreerd (gelogd).
 


===Stand van zaken beleidsstukken over IAM 15 min===
[[Afbeelding:Belang voor IAM.jpg|thumb|none|750px|Belang voor IAM|alt=”regie op gegevens IAM”|link=Expertgroep Digitale Identificatie en authenticatie/2019-09-03]]
Kees Jan Kolb (Erasmus MC) en Erik Kuijpers (UWV) hebben enkele beleidsstukken die IAM raken doorgenomen en zullen ons informeren over de zaken die zij van belang vinden.
Zie ook [https://www.noraonline.nl/wiki/Expertgroep_Digitale_Identificatie_en_authenticatie/2019-07-24#Agenda_Digitale_Overheid_en_NL_DIGIbeter| Agenda Digitale Overheid en NL DIGIbeter]
   
   
===Presentatie ABAC 60 min===
==ABAC==
Kees Jan Kolb van het Erasmus MC zal ervaringen delen over hoe je kunt omgaan met Attribute Based Access Control (ABAC) in relatie tot de bestaande implementaties van RBAC.
 
Hiermee oriënteren we ons dus op de nadere invulling van Bevoegdhedenbeheer c.q. autorisatiemanagement, zie [https://www.noraonline.nl/wiki/Bevoegdhedenbeheer| bevoegdhedenbeheer]
Kees Jan Kolb van het Erasmus MC heeft zijn ervaringen gedeeld over hoe je kunt omgaan met Attribute Based Access Control (ABAC) in relatie tot de bestaande implementaties van RBAC {{Bestand met info|IAM_NORA_bevoegdheden_RBAC_ABAC_model_V2_inc_notes.pdf|RBAC ABAC model}}. Hiermee oriënteren we ons dus op de nadere invulling van Bevoegdhedenbeheer c.q. autorisatiemanagement, zie [[Bevoegdhedenbeheer]].
De volgende zaken kwamen naar voren:
* De focus ligt op Identiteitenbeheer en Bevoegdhedenbeheer: welke identiteiten hebben bevoegdheden? zijn de bevoegdheden passend? Is men in control?
* Er is onderscheid tussen 1e orde en 2e orde bevoegdheden: 1e orde is wat mag een identiteit? 2e orde is voor welke data subset is de wat (1e orde) van toepassing?
* Toegang tot applicaties wordt nu geregeld o.b.v. de identiteit: usernaam / medewerkernummer;
* ABAC kan je eigenlijk niet goed binnen een applicatie regelen, wel erbuiten;
* Business rules tbv ABAC is goed toepasbaar buiten de applicaties mbv een IGA tool: veel rollen kunnen automatisch worden toegekend o.b.v. regels en attribuut-waarden;
* Erasmus MC gebruikt nu vooral nog attributen vanuit het HR systeem en Finance, maar in de toekomst worden mogelijk ook attributen uit andere systemen gebruikt;
* Naast de medewerkers uit HRM is de gedachte om op termijn ook andere federatieve bronnen voor identiteiten te gaan gebruiken we denken dan aan externen, studenten en zelfs patiënten als gebruikers van het IAM-systeem;
* Koppelen tussen het IAM-systeem en de applicaties kan op verschillende manieren, maar de voorkeur van Erasmus MC gaat uit naar SCIM (open source REST API): zie onder meer [http://www.simplecloud.info/ SCIM: System for Cross-domain Identity Management] en [https://www.forumstandaardisatie.nl/standaard/scim/ SCIM|Forum Standaardisatie];
* Flat RBAC wordt vaak gebruikt, maar heeft als nadeel dat er per identiteit bijna een rol moet worden gedefinieerd;
* Een 2 laags rollen model (Enterprise Roles vs Application Roles);
* Eigenaarschap van processen en de bijbehorende data dient goed belegd te zijn om op een verantwoorde manier de bevoegdheden tot functionaliteiten en data gecontroleerd te organiseren;
* Mogelijk dat deze aanpak ook werkt voor applicaties van andere organisaties?
* Zouden diensten aan burgers en bedrijven ook op zo’n manier ontsloten kunnen worden?
* De complexiteit van bevoegdhedenbeheer is zo groot, dat je niet alles kunt regelen met regels en rollen: je zult af en toe ook bevoegdheden / autorisaties moeten toekennen op persoonlijk niveau;
* Kunnen organisaties wel doorgaan met data bij elkaar te zetten (zoals in datawarehouses) en daar dezelfde rollen-structuur op los te laten?
* Of moeten we andere vormen van attribuut-uitwisseling gaan hanteren, zoals met (inter)nationale APi’s?
* Het scheiden van data en functionaliteiten wordt belangrijker.
''': → ACTIE Kees Jan stuurt binnenkort zijn geactualiseerde presentatie zodat die kan worden gepubliceerd.'''
 
 
==Volgende bijeenkomst 15 oktober 2019==
De volgende bijeenkomst is op 15 oktober 2019 bij het UWV te Amsterdam.
Erik Kuijpers is dan onze gastheer en we gaan -naast het aanhoren van de IAM-aanpak van het UWV- verder met de uitwerking van Bevoegdhedenbeheer en Machtigen.


===Volgende bijeenkomst 15 oktober 2019 10 min===
* we zijn dan te gast bij het UWV te Amsterdam
* welke resultaten willen we dan bespreken?


===Afsluiting 10 min===


===Bijlagen===
==Bijlagen==
* {{Bestand met info|NORA - voorstel Authenticatie van natuurlijke personen irt BRP.pdf| Voorstel Authenticatie van natuurlijke personen irt BRP}}
* {{Bestand met info|Identificatieplichten wetgeving 2012-20190117-01.ods|Identificatieplichten in wetgeving}}

Huidige versie van 21 nov 2019 om 12:00


Bijeenkomst van Expertgroep IAM op dinsdag 3 september 2019, 14-17u, locatie: Stadsdeelkantoor Laak (achter station Hollands Spoor), Slachthuisplein 25, 2521 EC Den Haag, Vergaderzaal LA 00.37.
Doel: Het wat en waarom van Digitale Identificatie en Authenticatie in kaart brengen, opdat we breed gedeelde kennis en beelden krijgen en daarmee onze vraagstukken beter en geprioriteerd kunnen uitwerken om tot gedeelde architectuur oplossingen te komen.
Doelgroep: architecten en collega’s uit de publieke sector actief betrokken op thema authenticatie en identificatie. .



Verslag[bewerken]

Het was wederom een informatieve (en lange 😊) bijeenkomst. Ditmaal bij de gemeente Den Haag, waar we zo’n anderhalf jaar geleden een van de eerste bijeenkomsten hielden met de expertgroep IAM. Bijgaand is op hoofdlijnen aangegeven wat we met elkaar hebben besproken en afgesproken.


Actiepunten[bewerken]

We hebben de actiepunten van de bijeenkomst van 24 juli doorgenomen, zie het verslag Expertgroep Digitale Identificatie en authenticatie/2019-07-24 Er waren nog 2 openstaande actiepunten en die zijn inmiddels opgepakt:

  • NORA Beheer is bij GEMMA Beheer nagegaan of, en zo ja hoe ArchiMate modellen opgenomen kunnen worden bij de processen van Identiteitenbeheer. Het lijkt er op dat in de GEMMA geen specifieke processen zijn beschreven voor het identiteitenbeheer. De GEMMA heeft wel meer algemene processen (typeringen), waar zo’n proces van Identiteitenbeheer onder zou kunnen vallen.

: → ACTIE: Afgesproken is e.e.a. nog met elkaar te gaan bespreken. Voorstel is om de plaatjes voorlopig op te nemen in de NORA.

  • Het COA is de organisatie die een registratie voert voor “vreemdelingen” die niet in de BRP (RNI) worden geregistreerd. Deze informatie is inmiddels opgenomen in de beschrijving van het Identiteitenbeheer van natuurlijke personen.


Identiteitenbeheer[bewerken]

Bob te Riele en enkele collega’s van RvIG (met name ook Frans Rijkers) hebben de teksten van het Identiteitenbeheer van natuurlijke personen al deels aangepast n.a.v. de eerder gemaakte opmerkingen. Ook is gekeken naar de opzet van de authenticatie van natuurlijke personen. De aanvullingen die daarop van belang zijn, zullen worden verwerkt door de werkgroep Authenticatie, zie het kopje hieronder. : → ACTIE: Vanuit NORA Beheer gaan we na of alle gemaakte opmerkingen zijn verwerkt bij Identiteitenbeheer. Hierna kan de review kan plaatsvinden door Anne Schrijer (BZK) en Raymond Hofstra (Politie).

Authenticatie[bewerken]

Menno Stigter (gemeente Den Haag), Harro Kremer (DJI) en Anne Schrijer (BZK) hebben een eerste uitwerking gemaakt van de Authenticatie van Natuurlijke Personen i.r.t de BRP (PDF, 498 kB). Deze uitwerking is plenair besproken.

: → ACTIE: De expertgroep zal de komende weken nog diverse aanpassingen doen, zoals:

  • Omzetten naar het vijflaagsmodel van de NORA: om discussies te beslechten en vraagstukken te duiden;
  • Dubbele tekststukken over natuurlijke personen en authenticatie verwijderen;
  • Koppelvlakken van de voorzieningen toelichten;
  • Op onderdelen de W&R toelichten: naast een analoge ID is nu ook een digitale ID nodig (denk aan de wet online identiteit en de pilot met virtuele ID’s);
  • Een overzicht maken op het niveau van het IAM-kader en de relatie met de uitgewerkte pagina’s in de NORA over identiteitenbeheer en authenticatie;
  • Antwoord geven op wat wordt bedoeld met het “proces van authenticatie op de BRP”.


Identiteitenbeheer Bedrijven[bewerken]

Jurriaan Raaijmakers (gemeente Almere), Wim Schut (Belastingdienst) en Henk Romein (DICTU) hebben een eerste uitwerking gemaakt van het document Identiteitenbeheer van Bedrijven (PDF, 309 kB). Er wordt nog steeds gewerkt aan deze uitwerking, dus als je wilt kan je jouw opmerkingen nog toevoegen aan het document. Opmerkingen ontvangen we graag via nora@ictu.nl.

Uit de bespreking van dit document kwamen de volgende opmerkingen naar voren:

  • We zijn op zoek naar de verschillende digitale identiteiten die in Nederland aan bedrijven worden toegekend en hoe dat proces verloopt;
  • De opzet die nu is gemaakt gaan we z.s.m. publiceren, zodat we reacties daarop kunnen verkrijgen en verwerken;
  • Vertegenwoordiging van de KvK zal daar expliciet bij worden betrokken;
  • De begrippen en omschrijvingen zijn nog erg overlappend en onduidelijk. Het lijkt soms met name vanuit het perspectief van de Belastingdienst bezien;
  • We willen meer als basis aanhouden hoe een register wordt onderhouden en door welke verantwoordelijke(n), zoals KvK met HandelsRegister (HR);
  • De definities en nummers zullen worden uitgewerkt;
  • Het OIN (door Logius beheerd) is een afspraak om uniciteit over alle domeinen heen te borgen, ook in de tijd gezien (meer info is te verkrijgen via Logius / Pieter Hering;
  • De Handelsnaam is alleen unieke binnen een sector (zo’n sector is trouwens wat anders dan overheidsdomeinen!);
  • De Statutaire Naam is waarschijnlijk wel uniek in Nederland;
  • In het elektronische Toegangsdiensten (eTD) worden ook koppelvlakken en attributen / nummers beschreven;
  • Internationaal: LEI en EORIE, De Legel Entity Identifier (LEI) wordt door KvK in NL en KvK’s in BL uitgegeven;
  • eIDAS heeft ook een Legal Identifier: die lijkt op het OIN, maar wijkt af van de LEI;
  • Een vraagstuk voor later: Hoe gaat een dienst-specifiek identificerend nummer werken (via pseudoniemen / BSNk e.d)?

Dat pakken we op irt “de wolk”: SSI, IRMA en DigitalMe, Attribute Services e.d., zie Ontwikkelingen waar toepassing in de toekomst binnen moet passen.

  • In het afsprakenstelsel eHerkenning is opgenomen aan welke kwaliteitseisen een digitale identiteit moet voldoen;
  • PKIO heeft ook een normenkader voor digitale identiteiten;
  • Een normenkader van het stelsel eID is er nog niet;


Beleidsstukken over IAM[bewerken]

Kees Jan Kolb (Erasmus MC) en Erik Kuijpers (UWV) hebben de Agenda Digitale Overheid / NL DIGIbeter en de beleidsbrief Regie op Gegevens (RoG) doorgenomen om na te gaan in hoeverre wij als expertgroep IAM invulling kunnen geven aan specifieke onderdelen van deze landelijke (beleids)kaders. Zie ook Agenda Digitale Overheid en NL DIGIbeter.

Hun bevindingen hebben ze gepresenteerd, Wetgeving Regie op gegevens (PDF, 386 kB) en we hebben daaruit het volgende geconcludeerd:

  • Het gedachtegoed van NL DIGIbeter was ons op hoofdlijnen wel bekend, maar het was niet eerder zo expliciet en in samenhang benoemd;
  • Naar onze inschatting is al veel beschikbaar van de benoemde toekomstbeelden;
  • Met name van belang is een gemeenschappelijk beeld over digitale identiteiten van burgers en de wettelijke verankering ervan;.
  • Regie op Gegevens (RoG) in de vorm van het op eigen initiatief van een burger laten delen van een basisset gegevens (of het door laten leveren) is nieuw, zeker via MijnOverheid.nl;
  • RoG is een lopend programma dat zich daar op richt en IAM is daar een voorwaardelijk aspect voor. De vraag die bij ons voorligt is daarom: hoe gaan we RoG ondersteunen met onze kennis en ervaring?
  • Hoe wordt omgegaan met “contacthistorie” (wie heeft wat namens jou gedaan met welke gegevens?);
  • Is RoG zoals een blauwe knop: een onderdeel van een dienst digitaliseren? Dat is niet echt regie vanuit de burger.
  • De huidige IAM uitgangspunten ondersteunen al grotendeels de uitgangspunten van RoG, echter hoe kan IAM er voor zorgen dat RoG op een veilige wijze verloopt?
  • Wat is het ontwerp dat de architecten hierin voorstaan?
  • Het zal waarschijnlijk niet alles linken aan een BSN.
  • Mogelijk zal meer gedaan moeten worden met dataminimalisatie, polymorfe pseudoniemen en gebruiksregisters (audittrails);
  • Het veilig gebruik van gegevens bevorderen;
  • Faciliteren dat het doorleveren van gegevens wordt geregistreerd (gelogd).


”regie op gegevens IAM”
Belang voor IAM

ABAC[bewerken]

Kees Jan Kolb van het Erasmus MC heeft zijn ervaringen gedeeld over hoe je kunt omgaan met Attribute Based Access Control (ABAC) in relatie tot de bestaande implementaties van RBAC RBAC ABAC model (PDF, 7,8 MB). Hiermee oriënteren we ons dus op de nadere invulling van Bevoegdhedenbeheer c.q. autorisatiemanagement, zie Bevoegdhedenbeheer. De volgende zaken kwamen naar voren:

  • De focus ligt op Identiteitenbeheer en Bevoegdhedenbeheer: welke identiteiten hebben bevoegdheden? zijn de bevoegdheden passend? Is men in control?
  • Er is onderscheid tussen 1e orde en 2e orde bevoegdheden: 1e orde is wat mag een identiteit? 2e orde is voor welke data subset is de wat (1e orde) van toepassing?
  • Toegang tot applicaties wordt nu geregeld o.b.v. de identiteit: usernaam / medewerkernummer;
  • ABAC kan je eigenlijk niet goed binnen een applicatie regelen, wel erbuiten;
  • Business rules tbv ABAC is goed toepasbaar buiten de applicaties mbv een IGA tool: veel rollen kunnen automatisch worden toegekend o.b.v. regels en attribuut-waarden;
  • Erasmus MC gebruikt nu vooral nog attributen vanuit het HR systeem en Finance, maar in de toekomst worden mogelijk ook attributen uit andere systemen gebruikt;
  • Naast de medewerkers uit HRM is de gedachte om op termijn ook andere federatieve bronnen voor identiteiten te gaan gebruiken we denken dan aan externen, studenten en zelfs patiënten als gebruikers van het IAM-systeem;
  • Koppelen tussen het IAM-systeem en de applicaties kan op verschillende manieren, maar de voorkeur van Erasmus MC gaat uit naar SCIM (open source REST API): zie onder meer SCIM: System for Cross-domain Identity Management en SCIM|Forum Standaardisatie;
  • Flat RBAC wordt vaak gebruikt, maar heeft als nadeel dat er per identiteit bijna een rol moet worden gedefinieerd;
  • Een 2 laags rollen model (Enterprise Roles vs Application Roles);
  • Eigenaarschap van processen en de bijbehorende data dient goed belegd te zijn om op een verantwoorde manier de bevoegdheden tot functionaliteiten en data gecontroleerd te organiseren;
  • Mogelijk dat deze aanpak ook werkt voor applicaties van andere organisaties?
  • Zouden diensten aan burgers en bedrijven ook op zo’n manier ontsloten kunnen worden?
  • De complexiteit van bevoegdhedenbeheer is zo groot, dat je niet alles kunt regelen met regels en rollen: je zult af en toe ook bevoegdheden / autorisaties moeten toekennen op persoonlijk niveau;
  • Kunnen organisaties wel doorgaan met data bij elkaar te zetten (zoals in datawarehouses) en daar dezelfde rollen-structuur op los te laten?
  • Of moeten we andere vormen van attribuut-uitwisseling gaan hanteren, zoals met (inter)nationale APi’s?
  • Het scheiden van data en functionaliteiten wordt belangrijker.

: → ACTIE Kees Jan stuurt binnenkort zijn geactualiseerde presentatie zodat die kan worden gepubliceerd.


Volgende bijeenkomst 15 oktober 2019[bewerken]

De volgende bijeenkomst is op 15 oktober 2019 bij het UWV te Amsterdam. Erik Kuijpers is dan onze gastheer en we gaan -naast het aanhoren van de IAM-aanpak van het UWV- verder met de uitwerking van Bevoegdhedenbeheer en Machtigen.


Bijlagen[bewerken]