<p>Dit hoofdstuk gaat dieper in op hoe systemen toegang kunnen krijgen tot andere systemen. Het is een onderwerp waarvoor relatief weinig aandacht is, maar dat steeds relevanter wordt door toenemende uitwisseling van gegevens tussen organisaties. Het beschrijft een aantal standaarden en technische mogelijkheden die daarbij gebruikt kunnen worden. Het beschrijft zowel huidige standaarden als een aantal nieuwe standaarden die gebruikt zouden moeten worden. Het geeft ook in meer algemene zin uitleg aan gegevensruimtes, de EDI wallets en het EDI-stelsel NL.</p> <h3>Public Key Infrastructure</h3> <p> Voor de veilige uitwisseling van gegevens tussen systemen wordt gebruik gemaakt van certificaten. Een certificaat is een combinatie van een identiteit en een openbare sleutel die gewaarmerkt is door de uitgever, een certificaatautoriteit. Met deze openbare sleutel kan een ontvanger de identiteit van de zender vaststellen. Certificaten zijn dus gebaseerd op asymetrische cryptografie, waarbij alleen de eigenaar van het certificaat beschikt over een privésleutel en de openbare sleutel wordt gedeeld met anderen. De certificaatautoriteit waarborgt de integriteit en authenticiteit van het certificaat en staat dus in voor de identiteit van de certificaatbezitter. Een public key infrastructure (PKI) is een systeem waarmee uitgiften en beheer van digitale certificaten kan worden gerealiseerd. </p> <p> PKIoverheid is de public key infrastructure (PKI) van de Nederlandse overheid, waarbij de Staat der Nederlanden de certificaatautoriteit is en verantwoordelijk is voor het stamcertificaat. Hierdoor is PKIoverheid niet afhankelijk van (buitenlandse) commerciële partijen. Dit stelsel is afgestemd op Europese en wereldwijde afspraken en standaarden. PKIoverheid wordt beheerd door Logius. Logius geeft zelf geen certificaten uit; hiervoor zijn commerciële partijen als qualified trust service provider benoemd. PKIoverheid stelt eisen aan de uitgifte van certificaten. Zo moet bijvoorbeeld naar organisaties in een PKIoverheid certificaat worden verwezen met een OIN. Deze OIN systematiek maakt het mogelijk om organisaties te voorzien van een unieke identificatie, ook als ze niet zijn opgenomen in het Handelsregister. Op dit moment zijn er echter bepaalde organisaties (restgroepen) die geen OIN kunnen krijgen en dus ook geen gebruik kunnen maken van PKIoverheid certificaten, zoals buitenlandse bedrijven. </p> <p>De herziene eIDAS verordening onderkent verschillende soorten PKI certificaten, los van het onderscheid tussen wel of niet gekwalificeerde certificaten. Een Electronic Signature certificaat kan door een persoon gebruikt worden voor het ondertekenen van documenten. Een Electronic Seal (eSeal) certificaat kan door organisaties gebruikt worden voor het verzegelen van documenten. Een Qualified Website Authentication Certificate (QWAC) is bedoeld voor het aantonen van de authenticiteit van een website. Deze QWAC-certificaten zouden ook gebruikt kunnen worden voor het beschermen van communicatie tussen systemen. Er zijn op dit moment echter onvoldoende afspraken tussen lidstaten over organisatie-identificaties om dit praktisch uit te kunnen voeren.</p> <p> In het algemeen kost het (tijdig) aanvragen en configureren van certificaten relatief veel aandacht van organisaties. Het Automatic Certificate Management Environment (ACME) is een protocol voor het geautomatiseerd uitgeven en vernieuwen van beveiligingscertificaten en kan de gevraagde beheerslast verminderen. Deze standaard is aangemeld bij het Forum Standaardisatie en er zal onderzocht worden of deze standaard formeel onderdeel zou moeten zijn van één van de lijsten van het forum. Het NCSC raadt het gebruik van de standaard reeds aan. </p> <p> PKIoverheid is ook een belangrijke basis onder de Digikoppeling standaard. Deze richt zich specifiek op beveiligde uitwisseling van gegevens. Onderdeel daarvan zijn afspraken over hoe wordt omgegaan met authenticatie bij gegevensuitwisseling. Daarbij vooral wordt verwezen naar het gebruik van PKIoverheid certificaten en het tweezijdig gebruik van TLS. Dat betekent dat zowel het zendende systeem als het ontvangende systeem moet beschikken over een PKIoverheid certificaat. Er zijn ook afspraken en standaarden voor het inhoudelijk versleutelen en ondertekenen van berichten die worden uitgewisseld, als aanvullende beveiligingsmaatregelen nodig zijn. </p> <h3>OpenID Connect en OAuth</h3> <p> De OpenID Connect en OAuth standaarden worden tegenwoordig veel gebruikt om namens een gebruiker een ander systeem te benaderen. Dat is dus altijd in de context van een interactie die is gestart door en gebruiker. OpenID Connect is een protocol dat specifiek gericht is op authenticatie en gezien kan worden als een extensie van OAuth. OAuth is een protocol voor autorisatie en specifiek gericht op het autoriseren van het systeem waarmee een gebruiker interacteert, om namens die gebruiker gegevens van die gebruiker op te halen bij een ander systeem. </p> <p> Er zijn Nederlandse profielen opgesteld voor OpenID Connect en OAuth: OpenID.NLGov en NL GOV Assurance profile for OAuth 2.0. Beiden staan op de "pas toe of leg uit" lijst van Forum Standaardisatie. Het Overheidsbreed Beleidsoverleg Digitale Overheid (OBDO) heeft besloten dat er een transitie van SAML naar OpenID.NLGov moet worden ingezet. Het OAuth profiel wordt op dit moment doorontwikkeld, waardoor het beter zal aansluiten op de FSC standaard (zie verderop) en ondersteuning zal bieden voor token exchange waarmee identiteiten van eindgebruikers kunnen worden doorgegeven in de keten. </p> <p> Het gebruik van OpenID Connect en OAuth werkt ongeveer als volgt. Een gebruiker voert gebruikersnaam en wachtwoord in en deze worden gecontroleerd bij een OpenID Connect Provider. Na succesvolle authenticatie met OpenID Connect ontstaan er drie tokens: een ID-token dat een beschrijving geeft van de ingelogde gebruiker, een access token dat gezien kan worden als de authenticatieverklaring en een refresh token dat gebruikt kan worden om het access token te vernieuwen als het is verlopen. De tokens worden door het systeem dat ze heeft verkregen doorgegeven aan het systeem dat wordt aangeroepen. Deze heeft daarmee toegang tot gegevens over de identiteit van de eindgebruiker en weet dat persoonsgegevens die daarbij horen kunnen worden geleverd aan het aanroepende systeem. </p> <p> Op dit moment ondersteunen DigiD en eHerkenning nog geen OpenID Connect, maar de SAML standaard. Dat betekent dat het gebruik van OpenID Connect en OAuth vooralsnog alleen gebruikt kan worden in scenario’s waarin geen DigiD of eHerkenning wordt gebruikt. Denk daarbij bijvoorbeeld aan scenario’s om toegang te geven aan medewerkers voor het gebruik van systemen van de werkgever van deze medewerker (en daarmee de daaronder liggende systemen). </p> <h3>Federated Service Connectivity</h3> <p> De Federated Service Connectivity (FSC) standaard is ontwikkeld in de context van het Common Ground programma voor gemeenten. Het standaardiseert de werking van tussenliggende componenten dat het gebruik van API’s vereenvoudigt. De standaard wordt inmiddels ondersteund door verschillende leveranciers en is gepositioneerd als een brede standaard die door alle overheidsorganisaties kan worden gebruikt. Het is voorgesteld als onderdeel van het Digikoppeling profiel voor REST API’s, maar kan in bredere zin worden gebruikt voor gegevensuitwisseling tussen systemen over HTTP. </p> <p> De kern van de FSC standaard is dat het een vertrouwensnetwerk kan creëren tussen systemen door het creëren van contracten tussen partijen. De API's die worden aangeboden en de bijbehorende contracten worden geregistreerd in een directory, waarvan er meerdere kunnen zijn. In een directory kunnen API's worden gezocht en op basis daarvan kunnen ze worden aangeroepen door systemen, waarbij het resulterende berichtenverkeer verloopt over tussenliggende FSC componenten. Er is een tussenliggend componenten bij het zendende systeem (outway) en een tussenliggend component bij het ontvangende systeem (inway). In deze componenten kan ook extra functionaliteit worden aangeroepen, zoals het loggen van de berichten. Hiervoor wordt een transactie-identificatie gegenereerd, die bij elkaar behorende berichten kan correleren. Daarnaast zijn er manager componenten die vooral verantwoordelijk zijn voor de contractafhandeling. Vanuit het perspectief van toegang is met name relevant dat authenticatie en autorisatie van afnemers door aanbieders een integraal onderdeel is van de standaard. Verder is het mogelijk om machtigingen tussen systemen toe te kennen. Hierdoor kan een systeem van een derde partij (bijvoorbeeld een SaaS leverancier) een machtiging ontvangen om namens een overheidsorganisatie gebruik te maken van een ander systeem. Dit voorkomt dat er certificaten en/of sleutels aan deze derde partij moeten worden verstrekt, wat vanuit beveiligingsperspectief onwenselijk is. FSC gaat zelf ook uit van het gebruik van certificaten, waarbij voor de communicatie over organisatiegrenzen gebruik moet worden gemaakt van PKIoverheid certificaten. Het gaat ervan uit dat er een eenduidig vertrouwensraamwerk van certificaten bestaat. Het maakt verder gebruik van de OAuth standaard voor authenticatie van verzoeken.</p> <p><img src="https://minbzk.github.io/gdi-toegang/images/fsc.svg"></p> <h3>Gegevensruimtes</h3> <p> Gedreven vanuit de Europese datastrategie is er veel aandacht voor gegevensruimtes (data spaces). Er moet een Europese gegevensruimte komen, een interne markt voor data, waar zowel overheidsorganisaties als bedrijven gebruik van kunnen maken. Binnen deze Europese gegevensruimte ziet de Europese Commissie negen gemeenschappelijke gegevensruimtes ontstaan voor specifieke sectoren. De precieze inrichting van veel van deze gegevensruimtes is nog onduidelijk. Veel van de ideeën en ontwikkelingen rondom gegevensruimtes kunnen we breder omarmen. Je kunt gegevensruimtes zien als afsprakenstelsels en vertrouwensnetwerken waarbinnen gegevens tussen systemen kunnen worden uitgewisseld. Er zijn inmiddels allerlei referentie-architecturen voor gegevensruimtes beschikbaar van bijvoorbeeld <a href="https://www.opendei.eu/">OpenDEI</a>, de <a href="https://docs.internationaldataspaces.org/ids-knowledgebase/v/ids-ram-4/">International Data Spaces Association (IDSA)</a>, en het <a href="https://dssc.eu/page/knowledge-base">Data Spaces Support Center (DSSC)</a>. Er zijn verschillende partijen die hierop zijn ingesprongen en die oplossingen bieden om gegevensruimtes te ondersteunen. De referentie-architectuur van IDSA wordt ondersteund door generieke softwarecomponenten en een uitwisselprotocol. Daarnaast zijn er andere initiatieven zoals iShare en GAIA-X die oplossingen bieden. Een <a href="https://docs.geostandaarden.nl/eu/VerkenningDataspaces/">uitgebreider overzicht</a> van dit soort initiatieven is beschikbaar in de verkenning die Geonovum heeft uitgevoerd. </p> <p> Een gemeenschappelijk vertrekpunt bij al deze initiatieven is datasoevereiniteit, wat betekent dat gegevenseigenaren zelf willen kunnen beslissen over het beschikbaar stellen van hun gegevens. Als gevolg daarvan bieden ze allemaal gemeenschappelijke diensten voor toegang, waarbij vooral gebruik wordt gemaakt van (profielen op) internationale standaarden. Uitgangspunt daarbij is dat voorwaarden en regels van data-aanbieders zoveel mogelijk geautomatiseerd worden gecontroleerd als een afnemer om gegevens vraagt. Een aantal initiatieven biedt daarbij ondersteuning voor Policy Based Access Control, waarbij voorwaarden zoveel mogelijk in machineleesbare vorm als autorisatieregels zijn beschreven zodat ze geautomatiseerd kunnen worden getoetst. Het is daarmee te zien als een uitbreiding op attribute based access control, waarbij er autorisatieregels worden toegepast op de beschikbare attributen. In onderstaande figuur is de essentie van Policy Based Access Control beschreven aan de hand van de begrippen in de veelgebruikte XACML standaard. Naast de XACML standaard bestaat ook de ODRL standaard, die meer vanuit Digital Rights Management komt maar erg vergelijkbaar is met XACML en die ook breder wordt omarmd. Policy Based Access Control is ook een belangrijk aspect van een Zero Trust architectuur. </p> <p><img src="https://minbzk.github.io/gdi-toegang/images/xacml.svg"></p> <p> In Policy Based Access Control zijn er verschillende componenten. De autorisatieregels (policies) worden beheerd in een Policy Administration Point (PAP). Ze worden gebruikt in een Policy Decision Point (PDP) die ze interpreteert om er een autorisatiebeslissing op te baseren. Deze beslissing wordt afgedwongen in een Policy Enforcement Point (PEP) naar aanleiding van een verzoek dat wordt gesteld door een systeem. Het Policy Information Point (PIP) stelt hiervoor identiteitsgegevens beschikbaar. Naast een autorisatiebeslissing levert het PDP ook verplichtingen (obligations) op, die leiden tot specifieke acties die randvoorwaardelijk zijn om toegang te kunnen krijgen. Voorgaande begrippen worden vaak ook breder gebruikt in de context van toegang. Ze vormen een soort referentie-architectuur voor toegang. Wat verder belangrijk is in de context van Policy Based Access Control is dat er ook allerlei eigenschappen van de identiteit, de actie, de resource en de context kunnen worden gebruikt om autorisatiebeslissingen op te baseren. Denk bijvoorbeeld aan de tijd waarop de beslissing wordt genomen of de locatie van de identiteit. Het ondersteunt daarmee contextuele en adaptieve toegangscontrole. </p> <p> In de <a href="https://docs.internationaldataspaces.org/ids-knowledgebase/v/ids-ram-4">IDS RAM</a> wordt aanvullend op access control gesproken over usage control. Dit is een uitgebreidere vorm van toegangscontrole waarbij controles ook aan de kant van de afnemer plaats vinden. Deze verregaande vorm van controle stelt dus allerlei eisen aan de afnemer. Deze worden in die architectuur voor een belangrijk deel geborgd in de connector van de afnemer. Connectoren zijn een kernonderdeel van die architectuur en de plaats waar aan de kant van aanbieder en afnemer allerlei functionaliteit zoals controles kunnen worden ingebouwd. Naar verwachting zal usage control alleen in hele specifieke contexten relevant zijn, waarin hele hoge eisen worden gesteld aan de beveiliging van gegevens. </p> <h3>EDI Wallet</h3> <p> European Digital Identity wallets zullen in de toekomst ook gebruikt kunnen worden door organisaties. Hoe dit precies zal werken is nog niet duidelijk, maar naar verwachting zal dat grotendeels analoog werken aan hoe deze wallets door burgers gebruikt zullen worden. De vraag is of zij ook gebruikt kunnen worden voor communicatie tussen systemen van organisaties. Dat is op dit moment ook nog niet duidelijk. </p> <p> Het EDI-stelsel NL dient toe te groeien naar een stelsel waarin in ieder geval de uit de eIDAS-revisie voortvloeiende rollen en voorzieningen functioneren. Het betreft onder meer: <ul> <li>id-wallets die door Nederland zijn toegelaten en gecertificeerd,</li> <li>id-wallets die door andere lidstaten zijn toegelaten en gecertificeerd,</li> <li>publieke en private (authentieke) bronnen,</li> <li>publieke en private dienstverleners die voor dienstverlening vertrouwen op (gegevens uit) id-wallets,</li> <li>gekwalificeerde verleners van vertrouwensdiensten voor het uitgeven van verifieerbare verklaringen, elektronisch ondertekenen en verzegelen,</li> <li>registraties van leveranciers van identiteiten, leveranciers van wallets en vertrouwende partijen,</li> <li>validatie- en authenticatiemechanismen voor dienstverleners, id-wallets, digitale identiteiten en gekwalificeerde verifieerbare verklaringen.</li> </ul> Er is voor de borging van de veiligheid en betrouwbaarheid nodig dat er geaccrediteerde conformiteitsbeoordelingsinstanties zijn voor de certificering van id-wallets (en vertrouwensdiensten) en dat er één of meerdere toezichthouders worden aangewezen om toezicht te houden op de veiligheid en betrouwbaarheid in het stelsel. </p> <p> Ook reeds bestaande (nationale) voorzieningen zijn van belang voor het stelsel. Er moet gezocht worden naar samenhang tussen het EDI-stelsel NL en wat er onder de Wdo en in het stelsel toegang is voorzien. </p>