Thema-architectuur Werken met API's: verschil tussen versies

Geen bewerkingssamenvatting
Geen bewerkingssamenvatting
 
(5 tussenliggende versies door dezelfde gebruiker niet weergegeven)
Regel 1: Regel 1:
{{Cocreatie
{{Publicatie
|Cocreatiepublicatie=Cocreatie
|Paginastatus=publiceren
|Redactiestatus=Actueel
|Redactiestatus=Actueel
|GEMMAOnlinebeheerder=GEMMA Beheer
|Wikibeheerder=GEMMA Beheer
}}[[Categorie:Thema-architecturen]][[Categorie:Landingspagina]]
}}[[Categorie:Thema-architecturen]][[Categorie:Landingspagina]]
__NOTOC__
__NOTOC__
== Aanleiding ==
In 2017 zijn gemeenten, VNG en leveranciers onder de naam ‘Common Ground’ een nieuwe informatiekundige weg ingeslagen. Een belangrijk doel daarbij was om data niet meer op te slaan binnen 'silo-systemen' maar om data (ook) op een gestandaardiseerde manier beschikbaar te stellen voor hergebruik. Ontsluiten van data uit registraties gebeurt via 'Application Programming Interfaces' (APIs): software-interfaces die andere software-applicaties kunnen gebruiken voor gebruik van data of functionaliteit. Meer gebruik van API's stelt nieuwe eisen aan de architectuur en daarop gebaseerde bedrijfsvoering en informatievoorziening.   


== Aanleiding ==
===Doel===
In 2017 zijn gemeenten, VNG en leveranciers onder de naam ‘Common Ground’ een nieuwe informatiekundige weg ingeslagen. Een belangrijk doel daarbij was om data niet meer op te slaan in 'silo-systemen' maar data voortaan op een gestandaardiseerde manier beschikbaar te stellen voor hergebruik. Ontsluiten van data uit registraties gebeurt via 'Application Programming Interfaces' (APIs): een soort software-interface voor andere stukjes software. Om te zorgen dat API's op dezelfde manier werken worden API-standaarden gebruikt.  
De thema-architectuur 'Werken met API's' heeft als doel om te beschrijven hoe architectuur om goed met API's te kunnen werken er uit ziet. Daarbij geldt dat veel vraagstukken niet gemeente-specifiek zijn. Reden om vaker te verwijzen naar bronnen waar al bruikbare informatie is te vinden. 
 
Gelet op het belang voor gemeenten is binnen de GEMMA als eerste uitgewerkt hoe API's verantwoord en veilig zijn te gebruiken. Klassiek identiteits- en toegangsbeheer, met de focus op authenticatie en autorisatie van medewerkers en applicaties, volstaat daarvoor niet. De GEMMA heeft als doel om voor gemeenten en leveranciers te beschrijven hoe met name authenticatie- en autorisatiebeheer daarvoor fundamenteel anders moeten worden ingericht.  


Werken met API's biedt mogelijkheden om de informatievoorziening te verbeteren maar stelt ook nieuwe eisen aan de inrichting daarvan. Zaken zoals authenticatie, autorisatie en beveiliging moeten op een andere manier worden geregeld dan voorheen het geval was. Wanneer data die elders is vastgelegd via API's beschikbaar komt moet zijn gegarandeerd dit betrouwbaar en voldoende snel gebeurt.    
Het is wenselijk dat API's op een vergelijkbare manier zijn te gebruiken. Overheidsbreed en specifiek voor gemeenten zijn daarvoor verschillende soorten (API-)standaarden ontwikkeld. De thema-architectuur beschrijft om wat voor standaarden het daarbij gaat, wat de meerwaarde ervan is en wat er zoal bij gebruik komt kijken.  


===Doel===
===Architectuur===
De thema-architectuur 'Werken met API's' werkt vraagstukken uit die naar boven komen als (meer) wordt gewerkt met API's. Een eerste vraagstuk dat is opgepakt is hoe de informatievoorziening moet worden ingericht om te zorgen dat gebruik van API's verantwoord plaats vindt. Het gaat daarbij om vragen zoals 'Is duidelijk wie data wil gebruiken?', 'Is er voldoende doelbinding aanwezig om gebruik toe te staan?', 'is te verantwoorden waarom bepaalde data is gebruikt?'. Daarbij speelt 'identiteit- en toegangsbeheer' een belangrijke rol: pas als er sprake is van een betrouwbare identiteit én een toegangsbevoegdheid op basis van vastgelegde toegangsregels mag toegang tot een API worden verleend.
De GEMMA gebruikt service-oriëntatie als leidende architectuurstijl. Daarbij maken applicatiecomponenten via, bij voorkeur gestandaardiseerde, API's gebruik van elkaars services. Gebruik van API's is daarbij niets nieuws. Maar de manier waarop en het toenemend gebruik ervan maakt het belangrijk om binnen de architectuur uit te werken.    


===Architectuur ===
Meer gebruik maken van API's vereist maatregelen op meerdere gebieden. In termen van architectuur raakt het zowel de bedrijfs-, informatie- als technische architectuur. Voor een overzicht en beschrijving van een veelheid aan benodigde generieke functies ('capability's') maken we gebruik van het 'API capability model' van de [https://docs.geostandaarden.nl/api/API-Strategie/ Nederlandse API Strategie]. Die functies beschrijven de bekwaamheden of vermogens waarover partijen moeten (gaan) beschikken om goed met API's te kunnen werken.   
De GEMMA gebruikt service-oriëntatie als leidende architectuurstijl. In lijn daarmee wordt gestreefd naar een informatielandschap waar applicatiecomponenten via gestandaardiseerde API's van elkaars services gebruik maken. Een belangrijke stap daarbij is het bepalen van grenzen. Welke component moet bij gebruik van API's welke functionaliteit leveren? Kan die gestandaardiseerd worden geleverd? Wordt daarvoor wel of niet gebruik gemaakt van 1 centrale voorziening?   


Het eerste aspect dat binnen deze thema-architectuur is uitgewerkt is hoe autorisatie plaats moet vinden binnen een landschap met API's. Vaak gebruikte mechanismen voor toegang en informatiebeveiliging zoals Role- en Attribute- based Access ('RBAC' en 'ABAC') zijn dan niet meer voldoende omdat ze te grofmazig van aard zijn en ongeschikt om te kunnen verantwoorden wie wanneer voor welk doel data heeft gebruikt. De benodigde fundamentele verbetering is te bereiken door autorisatie meer op basis van verschillende soorten bedrijfsregels in te gaan richten ('Policy Based Access'). Naast een aantal technische veranderingen betekent het ook dat 'autoriseren' iets wordt van de hele organisatie.     
De thema-architectuur werkt uit hoe toegangsbeheer plaats moet vinden binnen een applicatielandschap waar intensief van API's gebruik wordt gemaakt. Bekende mechanismen voor toegang en informatiebeveiliging, zoals Role- (RBAC) en Attribute- based Access (ABAC), zijn te grofmazig en bijvoorbeeld niet geschikt om te kunnen verantwoorden wie wanneer voor welk doel bepaalde data heeft gebruikt. Om de toegang tot systemen en bronnen via API's goed te kunnen beheren is een ontwikkeling richting 'Policy Based Access' nodig. Daarbij worden beleidsregels gedefinieerd waarmee betrouwbaar is vast te stellen of toegang tot een API geoorloofd is of niet. Invoeren hiervan vereist zowel technische als organisatorische veranderingen en zal langere tijd vergen.     


De ontkoppeling die werken met API's met zich meebrengt vereist een informatiearchitectuur die niet meer is gebaseerd op statische, netwerkgebaseerde grenzen (bijvoorbeeld op basis van locatie binnen of buiten het interne netwerk). Voordat toegang tot services of data wordt verleend moet op basis van het need-to-know principe altijd verificatie plaatsvinden. Dit type architectuur wordt aangeduid met de term 'Zero Trust architectuur'. Werken met Policy Based Access past goed bij de uitgangspunten van een Zero Trust architectuur.      
De ontkoppeling die werken met API's met zich meebrengt vereist een architectuur waarbij geen enkele gebruiker, systeem of API inherent vertrouwd wordt (ook  afnemers binnen dezelfde (netwerk)omgeving niet). Er moet altijd verificatie en autorisatie op basis van identiteit plaatsvinden, op basis waarvan toegang tot bronnen wordt bepaald. De thema-architectuur beschrijft naast een aantal beveiligingsrichtlijnen voor API's, het type architectuur dat wordt aangeduid met de term 'Zero Trust Architectuur'. Een architectuur waarbinnen het 'niets-en-niemand-vertrouwen principe' geldt. Algemene aspecten van een Zero Trust Architectuur worden uitgewerkt in de [[Thema-architectuur Privacy en Informatiebeveiliging]]. Hier wordt met name beschreven wat in relatie tot gebruik van API's relevant is.    


{{Landingspagina
{{Landingspagina
|titel1 = Product
|titel1 = Producten
|inhoud1 =
|inhoud1 =
* [[API Capability Model | API Capability Model]]
* [[WMA_Identiteit_en_Toegangbeheer | Inleiding identiteit- en toegangsbeheer]]
* [[WMA_Identiteit_en_Toegangbeheer | Inleiding identiteit- en toegangsbeheer]]
* [[WMA_RBAC_ABAC_en_PBAC | RBAC, ABAC en PBAC toegangscontrole]]
* [[WMA_RBAC_ABAC_en_PBAC | RBAC, ABAC en PBAC toegangscontrole]]
* [[WMA_Informatiearchitectuur | Werken met APIs informatiearchitectuur]]
* [[WMA_Informatiearchitectuur | Werken met APIs informatiearchitectuur]]
* [[Beveiligingsrichtlijnen_voor_API%27s_en_webservices|Beveiligingsrichtlijnen voor APIs]]
* [[WMA_Begrippenkader | Werken met APIs Begrippenkader]]
* [[WMA_Begrippenkader | Werken met APIs Begrippenkader]]
|titel2 = Meer informatie
|titel2 = Meer informatie

Huidige versie van 18 apr 2024 om 14:00


Aanleiding[bewerken]

In 2017 zijn gemeenten, VNG en leveranciers onder de naam ‘Common Ground’ een nieuwe informatiekundige weg ingeslagen. Een belangrijk doel daarbij was om data niet meer op te slaan binnen 'silo-systemen' maar om data (ook) op een gestandaardiseerde manier beschikbaar te stellen voor hergebruik. Ontsluiten van data uit registraties gebeurt via 'Application Programming Interfaces' (APIs): software-interfaces die andere software-applicaties kunnen gebruiken voor gebruik van data of functionaliteit. Meer gebruik van API's stelt nieuwe eisen aan de architectuur en daarop gebaseerde bedrijfsvoering en informatievoorziening.

Doel[bewerken]

De thema-architectuur 'Werken met API's' heeft als doel om te beschrijven hoe architectuur om goed met API's te kunnen werken er uit ziet. Daarbij geldt dat veel vraagstukken niet gemeente-specifiek zijn. Reden om vaker te verwijzen naar bronnen waar al bruikbare informatie is te vinden.

Gelet op het belang voor gemeenten is binnen de GEMMA als eerste uitgewerkt hoe API's verantwoord en veilig zijn te gebruiken. Klassiek identiteits- en toegangsbeheer, met de focus op authenticatie en autorisatie van medewerkers en applicaties, volstaat daarvoor niet. De GEMMA heeft als doel om voor gemeenten en leveranciers te beschrijven hoe met name authenticatie- en autorisatiebeheer daarvoor fundamenteel anders moeten worden ingericht.

Het is wenselijk dat API's op een vergelijkbare manier zijn te gebruiken. Overheidsbreed en specifiek voor gemeenten zijn daarvoor verschillende soorten (API-)standaarden ontwikkeld. De thema-architectuur beschrijft om wat voor standaarden het daarbij gaat, wat de meerwaarde ervan is en wat er zoal bij gebruik komt kijken.

Architectuur[bewerken]

De GEMMA gebruikt service-oriëntatie als leidende architectuurstijl. Daarbij maken applicatiecomponenten via, bij voorkeur gestandaardiseerde, API's gebruik van elkaars services. Gebruik van API's is daarbij niets nieuws. Maar de manier waarop en het toenemend gebruik ervan maakt het belangrijk om binnen de architectuur uit te werken.

Meer gebruik maken van API's vereist maatregelen op meerdere gebieden. In termen van architectuur raakt het zowel de bedrijfs-, informatie- als technische architectuur. Voor een overzicht en beschrijving van een veelheid aan benodigde generieke functies ('capability's') maken we gebruik van het 'API capability model' van de Nederlandse API Strategie. Die functies beschrijven de bekwaamheden of vermogens waarover partijen moeten (gaan) beschikken om goed met API's te kunnen werken.

De thema-architectuur werkt uit hoe toegangsbeheer plaats moet vinden binnen een applicatielandschap waar intensief van API's gebruik wordt gemaakt. Bekende mechanismen voor toegang en informatiebeveiliging, zoals Role- (RBAC) en Attribute- based Access (ABAC), zijn te grofmazig en bijvoorbeeld niet geschikt om te kunnen verantwoorden wie wanneer voor welk doel bepaalde data heeft gebruikt. Om de toegang tot systemen en bronnen via API's goed te kunnen beheren is een ontwikkeling richting 'Policy Based Access' nodig. Daarbij worden beleidsregels gedefinieerd waarmee betrouwbaar is vast te stellen of toegang tot een API geoorloofd is of niet. Invoeren hiervan vereist zowel technische als organisatorische veranderingen en zal langere tijd vergen.

De ontkoppeling die werken met API's met zich meebrengt vereist een architectuur waarbij geen enkele gebruiker, systeem of API inherent vertrouwd wordt (ook afnemers binnen dezelfde (netwerk)omgeving niet). Er moet altijd verificatie en autorisatie op basis van identiteit plaatsvinden, op basis waarvan toegang tot bronnen wordt bepaald. De thema-architectuur beschrijft naast een aantal beveiligingsrichtlijnen voor API's, het type architectuur dat wordt aangeduid met de term 'Zero Trust Architectuur'. Een architectuur waarbinnen het 'niets-en-niemand-vertrouwen principe' geldt. Algemene aspecten van een Zero Trust Architectuur worden uitgewerkt in de Thema-architectuur Privacy en Informatiebeveiliging. Hier wordt met name beschreven wat in relatie tot gebruik van API's relevant is.

Deze pagina is het laatst bewerkt op 18 apr 2024 om 14:00.