Domeinarchitectuur Toegang
#
Reference
#
https://minbzk.github.io/gdi-toegang/content/views/Domeinarchitectuur%20toegang.html#:~:text=lopen%20zijn%20het-,programma/stelsel%20toegang,-en%20het%20programma
Fragmenten
#
- De Generieke Digitale Infrastructuur (GDI) ondersteunt de digitale overheid met afspraken, standaarden en voorzieningen.
- Het domein toegang omvat alles dat nodig is om de identiteit en bevoegdheden van mensen, organisaties en apparaten te controleren.
- In de context van de GDI gaat het vooral over toegang tot overheidsdiensten voor burgers en organisaties. Dit staat relatief los van hoe organisaties hun eigen medewerkers toegang verlenen, alhoewel het ook gebruikt kan worden om medewerkers van de ene overheidsorganisatie toegang te geven tot andere overheidsorganisaties.
- Landelijke voorzieningen zoals DigiD en eHerkenning zijn belangrijke onderwerpen van gesprek, maar het toegangslandschap is tevens aan het veranderen.
- Daarnaast worden er in het kader van de herziene eIDAS verordening European Digital Identity Wallets geïntroduceerd die ook als identificatiemiddel kunnen worden ingezet.
- Bij adaptieve toegangscontrole kan er dynamisch rekening worden gehouden met veranderende risicoprofielen en gebruikersgedrag. Ongebruikelijke gebruikspatronen kunnen daarbij aanleiding zijn om toegang te weigeren. Zo is toegang vanuit een ander land en/of vanaf een ander apparaat verdacht en kan dat reden zijn om de toegang te weigeren, de gebruiker om aanvullende identificatiemiddelen te vragen en/of de toegang expliciet te signaleren aan een beheerder. Er kan ook dynamisch worden bepaald of aanvullende identificatiemiddelen nodig zijn als gegevens met een hoger beveiligingsrisico worden benaderd.
- Voor het verstrekken van toegang wordt steeds meer contextuele informatie over een gebruiker gebruikt. Denk daarbij bijvoorbeeld aan de locatie van de gebruiker, het tijdstip van toegang, het gebruikte apparaat, het type sessie en het aantal gelijktijdige sessies. Hierdoor kan toegang meer gericht worden verstrekt en wordt ongeautoriseerde toegang dus verder voorkomen. Contextuele toegangsregels kunnen op groepsniveau, maar ook individueel worden toegekend.
- Self Sovereign Identity (SSI) is een visie op identiteiten waarbij de gebruiker zelf centraal staat. Het basisprincipe is dat gebruikers zelf controle hebben over hun eigen identiteit. Identiteiten zijn dus niet gebonden aan een specifieke site of partij. Ze zijn en blijven ten alle tijden van de gebruiker en deze kan er altijd naar refereren, deze aanpassen of zelfs verbergen. Gebruikers kunnen hun identiteit voorzien van allerlei verklaringen, die deels van henzelf komen en die deels afkomstig zijn van anderen. Deze verklaringen en andersoortige gegevens die deel uitmaken van de identiteit zijn altijd eenvoudig voor gebruikers te raadplegen. Verklaringen zijn daarmee niet noodzakelijkerwijs ook aan te passen door gebruikers, maar ze zijn er altijd bewust van. Gebruikers bepalen zelf aan wie ze de verklaringen en gegevens verstrekken en er worden geen gegevens verstrekt die niet nodig zijn. Identiteiten blijven lang geldig, in ieder geval zolang de gebruiker dat wil. Ze kunnen breed gebruikt worden. Er is niet één gemeenschappelijke interpretatie van de term SSI. Er zijn vooral allerlei interpretaties die een mate van overlap vertonen. Een deel van de oplossingen zoals voorgesteld voor SSI maakt gebruik van Blockchain technologie.
- Daar waar in het verleden rechten van gebruikers vooral bepaald werden door hun rol, worden rechten tegenwoordig steeds meer bepaald door verklaringen (ook wel: claims of attestaties) van partijen. Deze verklaringen hoeven niet direct over een specifiek recht te gaan, maar kunnen over allerlei eigenschappen (ook wel: attributen) van de gebruiker gaan. Dit wordt ook wel Attribute Based Credentials (ABC) genoemd. Hiermee ontstaat een meer flexibele vorm van autorisatie, die gebruik kan maken van veel meer eigenschappen, die door allerlei partijen kunnen worden geleverd. Het leidt tot een veel minder centraal model voor het toekennen van autorisaties. Uitgevers van verklaringen hebben zelf geen zicht op het gebruik van de verklaringen. Verklaringen kunnen ook gericht zijn op het ondersteunen van specifieke informatiebehoeften, waardoor ze dataminimalisatie goed ondersteunen. Verklaringen zijn er in verschillende soorten, met een verschillend niveau van betrouwbaarheid. Verifieerbare verklaringen maken het mogelijk om de echtheid en geldigheid van de verklaring expliciet te controleren. In de context van de nieuwe eIDAS verordening wordt ook wel gesproken over verifieerbare verklaringen. Dat zijn verklaringen die voldoen aan hoge betrouwbaarheidseisen die zijn gesteld vanuit Europa. Ze staan juridisch gelijk aan een geschreven handtekening.
- Bij wachtwoordloos inloggen wordt in plaats van een wachtwoord een andere combinatie van authenticatiefactoren gebruikt. Dat is typisch een combinatie van een publieke identificatie (gebruikersnaam, telefoonnummer, emailadres, etc) en een geregistreerd apparaat of token, maar er kunnen ook andere authenticatiefactoren worden ingezet zoals biometrie. Hierdoor hoeven gebruikers dus geen wachtwoord meer te gebruiken. Het gebruik van wachtwoorden is in het verleden vaker bekritiseerd, onder meer omdat mensen wachtwoorden hergebruiken, mensen geneigd zijn ze te vergeten, ze periodiek aangepast moeten worden en ze hierdoor op minder veilige manieren worden vastgelegd. Wachtwoordloze inlogmethoden maken typisch gebruik van public-key cryptografie.
- Het is steeds minder duidelijk wie vertrouwd kan worden, bijvoorbeeld doordat het onderscheid tussen interne en externe medewerkers steeds minder scherp wordt en mensen steeds meer thuiswerken. In het zero trust model wordt ervan uitgegaan dat gebruikers, apparaten en het netwerk standaard niet vertrouwd kunnen worden, ook als apparaten verbonden zijn aan het lokale netwerk. Uitgangspunt is dan dat identiteiten altijd sterk worden gecontroleerd voorafgaand aan het verstrekken van toegang. Gebruikers krijgen ook alleen de minimaal noodzakelijke toegang. Het niveau van beveiliging wordt hierdoor verhoogd. Autorisatie dient plaatst te vinden op functionaliteiten en op basis van het need-to-know principle. Dit betekent dat de gebruiker alleen toegang krijgt tot tools, data en zones die daadwerkelijk noodzakelijk zijn voor het werk dat diegene doet.
- Er bestaan mogelijkheden om contractvoorwaarden om te zetten in autorisatieregels die geautomatiseerd gecontroleerd kunnen worden. Hiermee is verdergaande automatisering van contractering tussen aanbieders en afnemers mogelijk. Er is onderzoek nodig om te bepalen in hoeverre dit een bredere behoefte is bij overheidsorganisaties, hoe ver dit soort controles zouden moeten gaan en hoe dit technisch kan worden ingericht. Zo is het bijvoorbeeld mogelijk om ook aan de kant van de afnemer en gebruiker dergelijke controles uit te voeren. Verder zijn er verschillende standaarden die kunnen worden gebruikt zoals de XACML standaard, de ODRL standaard, de Rego taal van de Open Policy Agent (OPA), MYDATA of de Usage Contract Language van de International Data Spaces Association.
- Het is wenselijk om te onderzoeken hoe met (vrijwillig) machtigen in de toekomst zou moeten worden omgegaan. Er zijn allerlei behoeften aan meer uitbreide vormen van machtigen die nu niet worden ondersteund, zoals het machtigen voor een zaak. Is het wenselijk om eHerkenning en/of DigiD machtigen uit te breiden met alle veelvoorkomende vormen van machtigen? Het onderzoek zou zich moeten richten op het verzamelen van de eisen en wensen en het bepalen of een centrale of federatieve oplossing wenselijk is. Er moet expliciet rekening worden gehouden met de relatie met de EDI-wallet. Deze zal ook vertegenwoordiging en machtigen moeten ondersteunen voor burgers die andere burgers of bedrijven vertegenwoordigen.
- Professionele partijen die mogen handelen na het overlijden van iemand moeten toegang kunnen krijgen tot digitale diensten namens de overledene. Er is inmiddels een oplossing beschikbaar voor de Belastingdienst. Er is een bredere voorziening gewenst. De toegangsinfrastructuur moet op deze voorziening worden aangesloten.
See also
#