Expertgroep Identiteit en Toegang bijeenkomst januari 2026
Informatiebewerken
Op woensdag 28 januari 2026 , van 15:00 tot 16:30, organiseert Expertgroep Identiteit en Toegang (IAM) een online bijeenkomst via: Teamslink.
- Doel
- Het delen van kennis over de aanpak en de inhoud voor het opstellen van definities van begrippen die gebruikt worden voor Digitale Identificatie en Authenticatie, zodat eventueel andere thema's een vergelijkbare aanpak kunnen voeren en kennis over het onderwerp kunnen opdoen.
- Doelgroep
- Architecten en collega’s uit de publieke sector die zijn geïnteresseerd in het thema Identity & Access Management
- Contactpersoon
- Harro Kremer
- Gerelateerd aan
- Identiteit en Toegang (IAM), Onderwerp
- Type
- Kennissessie, Vergadering, Ontmoetingsmoment.
Beschrijving bijeenkomst
Reguliere bijeenkomst van de Expertgroep
Welkom (Harro)bewerken
Geconstateerd wordt dat we ons Identiteit en Toegang noemen, maar ook de aanduiding IAM.
- We missen een pagina waarin IAM wordt uitgelegd.
- Concept is aangemaakt met een vrij droge samenvatting die met toestemming is hergebruikt uit het concept GDI domeinarchitectuur Toegang.
- KeesJan toont een overzicht van welke onderwerpen allemaal onder IAM vallen.
Uitnodiging aan de expertgroepleden:
- ==> Wat zou er op deze pagina moeten staan en voor welke doelgroep?
- Voel je vrij om de tekst aan te passen (bewerken) of SmartComments te plaatsen
- Anita kan helpen bij account problemen
BIO2 controls gerelateerd aan IAM (Jule Hintzbergen)bewerken
Demonstratie hoe Jule NotebookLM (een dienst van Google) gebruikt heeft om de samenhang tussen NORA en BIO2 inzichtelijk te maken. En toont een filmpje van 7 minuten dat door AI gegenereerd is; er is ook een demografic gegenereerd. Niet duidelijk wat de verschillen zijn tussen betaalde en gratis versies.
De uitkomst is aan het einde van de verslag opgenomen.
Tips:
- geef in de prompt mee welk perspectief je wil zien
- vraag de tool om een prompt voor te stellen
- <<filmpje>>
Voortgang Begrippenkader (Harro)bewerken
Rondje langs de velden (iedereen)bewerken
- Stedin: thema federatieve toegang binnen de energiesector (leveranciers richting netbeheerders). DigiD mag niet; eHerkenning in pilot. Kijkt uit naar eWallet.
- Politie: Federatie is belangrijk (via Justid), eHerkenning is knelpunt omdat het niet handig is bij 35.000 mensen in 1 organisatie.
- RVO: kijkt naar wallets, heeft nog uitdaging met herkennen van buiten de Europese Ruimte (i.e. buiten eIDAS 2.0)
- Gemeenten: Begeleiding bij implementatie van BIO (34 gemeenten, gedurende 6 maand)
- GDI: thema: hoe BSN proliferatie verminderen. Project DigiD Digitaal Machtigen, scope op termijn is inclusief identiteiten van overheidsmedewerkers.
Uitwerking BIO in tekst vormbewerken
Onderstaande uitwerking is met NotebookLM gegenereerd.
Hier is de gedetailleerde analyse van de IAM-keten, waarin de definities uit de NORA en de maatregelen uit de BIO2 samenkomen. In deze analyse staat de interactie centraal tussen de Dienstafnemer (de entiteit of persoon die toegang zoekt) en de Dienstverlener (de partij die de bron of dienst beschermt). Deze interactie wordt gefaciliteerd door de uitwisseling van verifieerbare verklaringen (credentials).
Het Perspectief van de Dienstafnemer:
De Opbouw (Identiteit → Authenticatie)bewerken
Vanuit de dienstafnemer gezien is de IAM-keten een opbouwend proces. Voordat er toegang gevraagd kan worden, moet de actor een digitale identiteit verkrijgen en bewijzen wie hij is. Dit is de fase van registratie en provisioning.
Stap A: Identiteit & Registratie
De basis is de toekenning van een unieke identiteit aan een natuurlijk persoon (of entiteit).
NORA Begrippen: De Identiteit is de verzameling van kenmerkende eigenschappen van een object. De Identifier (bijv. BSN of accountnaam) is het unieke kenmerk dat hieraan gekoppeld is.
BIO2 Maatregel:
- OM 5.16.01: Er moet een sluitende formele registratie- en afmeldprocedure zijn. Dit borgt dat een digitale identiteit (Identifier) altijd te herleiden is naar een gevalideerd natuurlijk persoon.
- OM 5.16.02: Groepsaccounts zijn verboden; de unieke koppeling tussen persoon en identiteit is essentieel voor onweerlegbaarheid (non-repudiation).
Stap B: Uitgifte van Middelen (Identificatiemiddelen)
Na registratie ontvangt de dienstafnemer middelen om zijn identiteit later te kunnen bewijzen.
NORA Begrippen: Een Identificatiemiddel (bijv. smartcard, token, app) wordt gebruikt om de identiteit te claimen.
BIO2 Maatregel:
- OM 5.17.01 (Beheer): Authenticatie-informatie mag pas worden uitgegeven nadat de identiteit van de gebruiker met voldoende zekerheid is vastgesteld via formele procedures.
OM 5.17.02: De dienstafnemer wordt ondersteund met een wachtwoordmanager.
Stap C: Authenticatie (Het bewijs leveren) De dienstafnemer gebruikt zijn middelen om in te loggen.
NORA Begrippen: Het proces van Authenticatie leidt tot een Authenticatieverklaring. Dit is het bewijs dat de gebruiker succesvol heeft aangetoond wie hij is.
BIO2 Maatregel:
- OM 5.17.01: Het gebruik van Multi-factorauthenticatie (MFA) is verplicht voor primaire toegang en internet-facing systemen. De dienstafnemer moet dus een Authenticatieverklaring kunnen overleggen die gebaseerd is op minstens twee factoren.
Het Perspectief van de Dienstverlener:
De Verificatie (Machtiging → Authenticatie → Identiteit)bewerken
Wanneer de dienstafnemer aanklopt bij de Dienstverlener, draait de logica om. De dienstverlener hanteert een Zero Trust benadering: de poort blijft dicht, tenzij specifieke verklaringen worden gevalideerd. Dit proces verloopt logisch "achterstevoren" ten opzichte van de opbouw: eerst wordt gekeken wat er mag, dan of het bewijs klopt, en ten slotte wie het is.
Stap A: Validatie van de Machtiging (Bevoegdheidsverklaring) De dienstverlener controleert eerst of er überhaupt een recht bestaat voor de gevraagde actie op het object (de Resource). De Vraag: "Mag deze actie uitgevoerd worden?"
NORA Begrippen: De dienstverlener valideert de Bevoegdheidsverklaring (of machtiging) en toetst deze aan een Autorisatieregel.
BIO2 Maatregel:
- OM 8.03.02 (Need to know): De dienstverlener dwingt af dat alleen informatie wordt getoond die strikt noodzakelijk is voor de taak.
- OM 5.18.01 / 5.18.02: De dienstverlener vertrouwt de bevoegdheidsverklaring alleen als de rechten jaarlijks zijn herzien en speciale rechten gemonitord worden.
Stap B: Controle van de Authenticatieverklaring Als de actie is toegestaan, controleert de dienstverlener de betrouwbaarheid van het toegangsbewijs. De Vraag: "Is het bewijs dat deze gebruiker presenteert geldig en actueel?"
NORA Begrippen: De dienstverlener verifieert de Authenticatieverklaring. Is deze uitgegeven door een vertrouwde partij (Identity Provider)? Is de sessie nog geldig?
BIO2 Maatregel:
- OM 5.15.01: Toegang tot de vertrouwde zone wordt alleen verleend vanaf geauthentiseerde apparatuur of veilige schillen.
- OM 5.17.01: De dienstverlener moet technisch afdwingen dat de authenticatieverklaring gebaseerd is op MFA. Zwakke authenticatie (alleen wachtwoord) wordt geweigerd.
Stap C: Verificatie van de Identiteit (Logging & Accounting)
Als laatste stap legt de dienstverlener vast wie de actie heeft uitgevoerd. De identiteit is nu de "sluitpost" voor verantwoording. De Vraag: "Wie moet ik noteren in het logboek voor deze actie?"
NORA Begrippen: De unieke Identifier (onderdeel van de Identiteit) wordt vastgelegd.
BIO2 Maatregel:
- OM 8.15.01: De logregel moet de Actor bevatten: de identificatie van de persoon of het proces dat de gebeurtenis in gang heeft gezet. Zonder deze stap is de keten niet sluitend.
De Architecturale Randvoorwaardenbewerken
De architect moet de uitwisseling van deze verifieerbare verklaringen ontwerpen. De BIO2 stelt specifieke eisen aan de inrichting van deze architectuur om de betrouwbaarheid van de verklaringen te borgen.
Randvoorwaarde 1: Security by Default & Automatisering
De uitwisseling en controle van verklaringen mag niet afhankelijk zijn van menselijk handelen, maar moet in de architectuur ingebakken zijn.
- OM 5.17.03: Eisen aan wachtwoorden (en bij extensie authenticatiemiddelen) moeten geautomatiseerd worden afgedwongen.
- OM 7.07.01: De architectuur moet fysieke triggers (verwijderen token) direct vertalen naar logische acties (automatische vergrendeling). Dit borgt dat een authenticatieverklaring onmiddellijk vervalt bij fysieke afwezigheid.
Randvoorwaarde 2: Onweerlegbaarheid via Logging
De architectuur moet voorzien in een ononderbroken Audit Trail van de uitgewisselde verklaringen.
- OM 8.15.01: Elk systeem in de keten (zowel bij dienstafnemer als dienstverlener) moet loggen met de unieke Actor ID.
- OM 8.15.02: De architectuur moet borgen dat logbestanden zelf geen geheime informatie (zoals wachtwoorden uit de authenticatieverklaring) bevatten.
Randvoorwaarde 3: Beheersing van Externe Verklaringen
Wanneer de dienstafnemer en dienstverlener zich in verschillende domeinen bevinden (ketensamenwerking), gelden extra eisen.
- OM 8.05.01: Voor externe leveranciers/gebruikers moet vooraf een risicoafweging gemaakt zijn die de duur en voorwaarden van de toegang (de geldigheid van de verklaringen) vastlegt.
- OM 5.21.02: De dienstverlener (entiteit) moet inzicht hebben in de keten van toeleveranciers om de betrouwbaarheid van externe authenticatieverklaringen te kunnen wegen.
Samenvattend:
De architect ontwerpt het systeem zodanig dat de Dienstafnemer de juiste middelen krijgt (5.16.01, 5.17.01) om een Authenticatieverklaring te genereren. De Dienstverlener is ontworpen om deze verklaringen in omgekeerde volgorde te valideren (Machtiging > Authenticatie > Identiteit) en elke stap onweerlegbaar vast te leggen via logging (8.15.01), waarbij de principes van Security by Default (5.17.03) leidend zijn.
3 maart 2026 11:45:54
8 oktober 2025 09:42:35
3 maart 2026 11:45:54
7
Informatief
8 oktober 2025
