BIO 09.01.01 ISO A.5.15

API-beveiliging In Azure: Ontwerp, Governance En Implementatie

📅 2025-11-26
•
⏱️ 22 minuten lezen
•
🔴 Must-Have

💼 Management Samenvatting

API's vormen de ruggengraat van moderne digitale diensten. Voor Nederlandse overheidsorganisaties zijn zij het toegangspunt voor burgerportalen, ketenkoppelingen en integratie met externe leveranciers. Juist daarom moet API-beveiliging in Azure niet worden gezien als een optionele technische laag, maar als een kernonderdeel van de totale informatiebeveiligingsarchitectuur.

Aanbeveling
RICHT EEN ZERO TRUST-GEBASEERD RAAMWERK VOOR API-BEVEILIGING IN AZURE IN
Risico zonder
High
Risk Score
8/10
Implementatie
120u (tech: 80u)
Van toepassing op:
✓ Azure Tenant
✓ Publieke API's
✓ Interne API's

Veel organisaties beginnen met het ontwerp van functionele API's en schuiven beveiliging naar de achtergrond. Authenticatie- en autorisatiemodellen worden ad hoc ingevuld, logging en monitoring blijven beperkt en documentatie over welke externe partijen toegang hebben ontbreekt. In de praktijk leidt dit tot API-endpoints die direct aan internet worden gepubliceerd met zwakke toegangscontrole, onvoldoende versleuteling of onduidelijke verantwoordelijkheden. Voor overheidsorganisaties is dit extra risicovol: API's ontsluiten vaak persoonsgegevens, vertrouwelijke beleidsinformatie of koppelingen met vitale ketenpartners. Een kwetsbare API kan leiden tot datalekken, verstoring van dienstverlening of misbruik van identiteiten, met directe gevolgen voor naleving van de AVG, BIO en NIS2. Daarnaast is het bij incidenten lastig om snel te reconstrueren wie wanneer welke API heeft aangeroepen en met welke rechten.

PowerShell Modules Vereist
Primary API: Azure API
Connection: Connect-AzAccount
Required Modules: Az.Accounts, Az.Resources, Az.ApiManagement, Az.Network

Implementatie

Dit artikel beschrijft een geïntegreerde benadering voor API-beveiliging in Azure, gebaseerd op Zero Trust-principes. We behandelen de rol van Azure API Management, Application Gateway/NGFW, identiteitsproviders (zoals Entra ID) en netwerksegmentatie. Vervolgens werken we uit hoe je sterke authenticatie en autorisatie inricht met OAuth2 en OpenID Connect, hoe je rate limiting en throttling toepast om misbruik te voorkomen, en hoe je end-to-end TLS en optioneel mTLS inzet voor vertrouwelijkheid en integriteit. Tot slot tonen we hoe je met een praktische PowerShell-control de configuratie van kritieke API-beveiligingsmaatregelen periodiek kunt toetsen, zodat bestuurders en auditors aantoonbaar inzicht krijgen in de staat van API-beveiliging binnen de Azure-tenant.

Architectuur van API-beveiliging in Azure volgens Zero Trust

Een solide architectuur voor API-beveiliging in Azure begint bij het uitgangspunt dat geen enkele verbinding standaard wordt vertrouwd, ongeacht of deze vanuit het internet, een ketenpartner of een interne workload komt. Dit sluit aan bij het Zero Trust-principe "never trust, always verify" en is essentieel voor Nederlandse overheidsorganisaties die steeds meer afhankelijk zijn van digitale ketensamenwerking. In plaats van API's rechtstreeks te publiceren op een webapplicatieserver of container, worden zij ontsloten via een dedicated beheers- en beveiligingslaag met Azure API Management als centrale toegangspoort. API Management fungeert daarbij als policy-engine, identity-aware proxy en centraal beheerplatform voor versiebeheer, documentatie en toegangsbeheer. Alle inkomende API-calls worden eerst langs deze beveiligingslaag geleid, waar authenticatie, autorisatie, validatie en logging plaatsvinden voordat het verzoek wordt doorgestuurd naar de achterliggende back-end service. Binnen deze architectuur is segmentatie van netwerkverkeer cruciaal. Publieke API's worden doorgaans ontsloten via een combinatie van Front Door of Application Gateway met Web Application Firewall (WAF) functionaliteit, die beschermt tegen veelvoorkomende webaanvallen zoals SQL-injectie en cross-site scripting. API Management-instanties kunnen in een dedicated subnet worden geplaatst, waarbij network security groups (NSG's) en eventueel Azure Firewall of een derde partij NGFW het inkomende en uitgaande verkeer fijnmazig reguleren. Back-end services – zoals App Services, containers in AKS of Functions – worden bij voorkeur alleen intern benaderbaar gemaakt, bijvoorbeeld via private endpoints of interne load balancers. Hierdoor ontstaat een gelaagde verdedigingsstructuur waarin een aanvaller meerdere, verschillend geconfigureerde verdedigingslagen moet passeren voordat kernsystemen kunnen worden bereikt. Identiteit en toegangsbeheer vormen de derde pijler van de architectuur. In plaats van API-sleutels die statisch worden uitgedeeld en moeilijk te beheren zijn, wordt authenticatie zo veel mogelijk ingericht via tokens op basis van OpenID Connect en OAuth2. Hiervoor wordt Entra ID (voorheen Azure AD) gebruikt als centrale identity provider, eventueel aangevuld met federatie naar andere identiteitsbronnen voor ketenpartners. Clients (zoals webportalen, mobiele apps of machine-to-machine services) registreren zich als applicatie in Entra ID en verkrijgen op gecontroleerde wijze toegangstokens met beperkte scopes. API Management valideert bij elk verzoek het token, controleert of de gevraagde scopes passen bij het doel van de API en kan aanvullende beleidstoetsen uitvoeren, zoals IP-restricties of verificatie van certificaten. Daarmee wordt identiteit een dynamisch en controleerbaar onderdeel van de API-beveiliging in plaats van een statische configuratie-instelling. Tot slot moet de architectuur expliciet rekening houden met beheer en lifecycle. API's veranderen in de tijd: nieuwe versies worden uitgerold, oude versies worden uitgefaseerd en toegang voor bepaalde partijen moet worden ingetrokken. Een volwassen architectuur voorziet daarom in versiebeheer in API Management, gescheiden producties en testomgevingen met eigen toegangspolicies, en duidelijke procedures voor onboarding en offboarding van consumenten. Deze procedures worden bij voorkeur vastgelegd in een governancekader waarin rollen en verantwoordelijkheden zijn benoemd (product owner, API-beheerder, security officer) en waarin is beschreven hoe wijzigingen worden beoordeeld op gevolgen voor risico's en compliance. Door deze elementen vanaf het begin in het ontwerp op te nemen, ontstaat een API-beveiligingsarchitectuur die niet alleen technisch robuust is, maar ook bestuurlijk beheersbaar.

Sterke authenticatie, autorisatie en bescherming tegen misbruik

Na het neerzetten van de basisarchitectuur is het inrichten van sterke authenticatie en autorisatie de belangrijkste stap om API's daadwerkelijk te beveiligen. Voor overheidsorganisaties betekent dit dat toegang tot API's altijd moet zijn gekoppeld aan een identificeerbare entiteit: een eindgebruiker, een technische client of een ketenpartner. Met OpenID Connect en OAuth2 kunnen toegangstokens worden uitgegeven die expliciet beschrijven welke rechten (scopes of rollen) zijn toegekend en hoelang deze gelden. In Azure wordt hiervoor Entra ID ingezet, waarbij per API een resource zijn eigen scopes definieert, bijvoorbeeld voor alleen-lezen toegang, schrijfoperaties of administratieve acties. Door per client alleen de minimaal noodzakelijke scopes toe te wijzen, wordt het risico beperkt dat een compromis van één applicatie leidt tot ongecontroleerde toegang tot andere gevoelige functies. Naast authenticatie en autorisatie is bescherming tegen misbruik en overbelasting essentieel. Brute force-aanvallen op tokens, credential stuffing of volumetrische aanvallen kunnen zowel de beschikbaarheid als de vertrouwelijkheid van diensten bedreigen. Azure API Management biedt daarom mogelijkheden voor rate limiting, quota's en throttling op basis van abonnementen, IP-ranges of andere kenmerken. Door harde limieten te definiëren voor publieke API's en strengere, afgestemde limieten voor interne of keten-API's, kan worden voorkomen dat een foutief geconfigureerde integratie of een kwaadwillende actor de back-end overbelast. WAF-regels op Application Gateway of Front Door filteren daarnaast bekende aanvalspatronen nog voordat zij API Management bereiken, waardoor het totale aanvalsoppervlak verder wordt verkleind. End-to-end versleuteling is een derde pijler in de bescherming tegen misbruik. API-verkeer dient altijd te worden versleuteld met TLS 1.2 of hoger, bij voorkeur TLS 1.3, waarbij zwakke ciphersuites worden uitgeschakeld conform actuele richtlijnen. Voor hoogrisico-API's, bijvoorbeeld voor het uitwisselen van gezondheidsgegevens of strafvorderlijke informatie, kan bovendien wederzijdse TLS (mTLS) worden toegepast, waarbij zowel client als server zich met een certificaat authentiseren. In Azure kan mTLS worden afgedwongen op API Management of Application Gateway, waarbij certificaatbeheer wordt geïntegreerd met Key Vault voor veilige opslag en geautomatiseerde vernieuwing. Voor Nederlandse publieke organisaties is het belangrijk om deze keuzes expliciet vast te leggen in architectuur- en beveiligingsdocumentatie, zodat bij audits duidelijk is welke vormen van versleuteling zijn toegepast en hoe certificaatbeheer is georganiseerd. Ten slotte mogen inputvalidatie en foutafhandeling niet worden onderschat. API Management en de achterliggende services moeten inkomende verzoeken nauwkeurig valideren op formaat, lengte en inhoud om te voorkomen dat onverwachte invoer leidt tot injectieaanvallen of informatielekken. Foutmeldingen richting clients horen geen interne details te onthullen, zoals stacktraces, databasefouten of configuratiepaden, maar wel voldoende informatie te bieden voor correcte foutafhandeling. Door deze technische maatregelen te combineren met duidelijke gebruiksvoorwaarden, acceptabele gebruikspolicies en contractuele afspraken met ketenpartners ontstaat een consistent en afdwingbaar raamwerk voor veilige API-consumptie.

Monitoring, governance en continue verbetering van API-beveiliging

Gebruik PowerShell-script index.ps1 (functie Invoke-Monitoring) – Voert een lichte API-beveiligingscheck uit op configuratie van API Management en netwerkbeveiliging..

API-beveiliging is geen eenmalig project, maar een continu proces van monitoren, bijsturen en verbeteren. Voor Nederlandse overheidsorganisaties is het essentieel dat de staat van API-beveiliging regelmatig en aantoonbaar wordt gerapporteerd aan CISO, CIO en eventueel externe toezichthouders. Azure biedt hiervoor verschillende bouwstenen. Allereerst genereren API Management, Application Gateway, WAF en achterliggende workloads uitgebreide logbestanden die kunnen worden opgeslagen in Log Analytics of een SIEM-oplossing. Door gestandaardiseerde dashboards in te richten – bijvoorbeeld in Azure Monitor workbooks of Power BI – ontstaat een actueel overzicht van succes- en foutpercentages, authenticatiefouten, afgewezen verzoeken door WAF-regels en het gebruik van specifieke API-versies of clients. Deze gegevens vormen de basis voor zowel operationele sturing als strategische rapportages over trends en risico's. Naast technische monitoring is governance rondom API-beveiliging cruciaal. Dit begint met een helder overzicht van alle in gebruik zijnde API's, inclusief eigenaar, doel, gevoeligheid van de verwerkte gegevens en betrokken ketenpartners. Dit overzicht wordt bij voorkeur beheerd als onderdeel van het bredere informatiebeveiligingsmanagementsysteem (ISMS) of een GRC-oplossing. Voor elke API wordt vastgelegd welke beveiligingsmaatregelen vereist zijn, zoals het verplichten van mTLS, het afdwingen van specifieke authenticatiestandaarden of het toepassen van IP-whitelisting voor bepaalde ketenpartners. Wijzigingen in API's – bijvoorbeeld nieuwe endpoints, scopes of toegangsmodellen – doorlopen een formeel changeproces waarin ook security en privacy worden betrokken. Daarmee wordt voorkomen dat nieuwe kwetsbaarheden ongemerkt worden geïntroduceerd. Voor continue verbetering is het tenslotte nodig om bevindingen uit monitoring, penetratietesten, code reviews en incidenten structureel terug te koppelen naar architectuur en implementatie. Regelmatige security assessments op API's, inclusief tests op OWASP API Security Top 10-risico's, helpen om kwetsbaarheden vroegtijdig te identificeren. Resultaten van dergelijke assessments worden vertaald naar concrete verbeteracties, zoals het aanscherpen van WAF-regels, het toevoegen van extra validatiemechanismen of het herzien van autorisatiemodellen. Een lichtgewicht PowerShell-script, zoals in dit artikel beschreven, kan worden gebruikt om periodiek te verifiëren of cruciale randvoorwaarden nog steeds zijn ingevuld: is API Management correct gekoppeld aan Log Analytics, zijn WAF-policies nog actief, en staan er geen onverwachte publieke endpoints open. Door deze controles te automatiseren en te koppelen aan rapportages ontstaat een cyclus van meten, verbeteren en borgen die past bij de eisen uit BIO, ISO 27001 en NIS2.

Compliance & Frameworks

Automation

Gebruik het onderstaande PowerShell script om deze security control te monitoren en te implementeren. Het script bevat functies voor zowel monitoring (-Monitoring) als remediation (-Remediation).

PowerShell
<# ================================================================================ AZURE POWERSHELL SCRIPT - Nederlandse Baseline voor Veilige Cloud ================================================================================ .SYNOPSIS Lichte controle van API-beveiliging in Azure (API Management en netwerklaag) .DESCRIPTION Dit script voert een praktische API-beveiligingscheck uit rond: - Aanwezigheid van Azure API Management-instanties - Basisconfiguratie van diagnostische logging naar Log Analytics - TLS-configuratie (minimale protocolversie indien beschikbaar) - Koppeling met een virtueel netwerk (indien van toepassing) Het doel is een snel, reproduceerbaar overzicht te geven van de staat van API-beveiliging in Azure als ondersteuning bij het artikel 'API-beveiliging in Azure: ontwerp, governance en implementatie'. .NOTES Filename: index.ps1 Author: Nederlandse Baseline voor Veilige Cloud Version: 1.0 Related JSON: content/azure/api-security/index.json #> #Requires -Version 5.1 #Requires -Modules Az.Accounts, Az.Resources, Az.ApiManagement, Az.Network [CmdletBinding()] param( [Parameter(Mandatory = $false)] [string[]]$SubscriptionId, [Parameter(Mandatory = $false)] [switch]$Detailed ) $ErrorActionPreference = 'Stop' $CheckName = "Azure API-beveiliging - Basischeck" function Connect-RequiredServices { if (-not (Get-AzContext -ErrorAction SilentlyContinue)) { Connect-AzAccount -ErrorAction Stop | Out-Null } } function Get-TargetSubscriptions { param( [string[]]$Ids ) if ($Ids -and $Ids.Count -gt 0) { return Get-AzSubscription -SubscriptionId $Ids -ErrorAction Stop } return Get-AzSubscription -ErrorAction Stop | Where-Object { $_.State -eq 'Enabled' } } function Test-ApiSecurityBasic { <# .SYNOPSIS Haalt kerninformatie op over API Management- en netwerkconfiguratie. .OUTPUTS PSCustomObject per subscription met basis-API-beveiligingsstatus. #> [CmdletBinding()] param( [Parameter(Mandatory = $true)] [AllowNull()] $Subscriptions ) $results = @() foreach ($sub in $Subscriptions) { Set-AzContext -SubscriptionId $sub.Id -ErrorAction Stop | Out-Null $apims = @() try { $apims = Get-AzApiManagement -ErrorAction SilentlyContinue } catch { Write-Verbose "Kon API Management-gegevens niet ophalen voor '$($sub.Name)': $_" } if (-not $apims -or $apims.Count -eq 0) { $results += [PSCustomObject]@{ SubscriptionName = $sub.Name SubscriptionId = $sub.Id ApiManagementInstances = 0 HasDiagnosticsConfigured = $false HasVNetIntegration = $false MinimumTlsVersion = $null } continue } foreach ($apim in $apims) { $hasDiag = $false $hasVnet = $false $minTls = $null try { $service = Get-AzApiManagement -ResourceGroupName $apim.ResourceGroupName -Name $apim.Name -ErrorAction Stop if ($service.Sku -and $service.Sku.Capacity -ge 0) { # Controleer of VNet-integratie is geconfigureerd if ($service.VirtualNetworkType -and $service.VirtualNetworkType -ne "None") { $hasVnet = $true } } # TLS-instellingen zijn beschikbaar via CustomProperties if ($service.CustomProperties.ContainsKey("Microsoft.WindowsAzure.ApiManagement.Gateway.Security.Protocols.Tls11") -or $service.CustomProperties.ContainsKey("Microsoft.WindowsAzure.ApiManagement.Gateway.Security.Protocols.Tls12")) { # Eenvoudige inschatting: als TLS 1.0 en 1.1 uit staan en 1.2 aan, is minimum TLS 1.2 $tls10Enabled = $false $tls11Enabled = $false $tls12Enabled = $true if ($service.CustomProperties.ContainsKey("Microsoft.WindowsAzure.ApiManagement.Gateway.Security.Protocols.Tls10")) { $tls10Enabled = [bool]::Parse($service.CustomProperties["Microsoft.WindowsAzure.ApiManagement.Gateway.Security.Protocols.Tls10"]) } if ($service.CustomProperties.ContainsKey("Microsoft.WindowsAzure.ApiManagement.Gateway.Security.Protocols.Tls11")) { $tls11Enabled = [bool]::Parse($service.CustomProperties["Microsoft.WindowsAzure.ApiManagement.Gateway.Security.Protocols.Tls11"]) } if (-not $tls10Enabled -and -not $tls11Enabled) { $minTls = "TLS1.2-or-higher" } else { $minTls = "LegacyProtocolsEnabled" } } # Diagnostische instellingen via Monitor Diagnostic Settings try { $diag = Get-AzDiagnosticSetting -ResourceId $service.Id -ErrorAction SilentlyContinue if ($diag -and ($diag.Logs | Where-Object { $_.Enabled -eq $true })) { $hasDiag = $true } } catch { Write-Verbose "Kon diagnostische instellingen niet ophalen voor API Management '$($apim.Name)': $_" } } catch { Write-Verbose "Fout bij ophalen details voor API Management '$($apim.Name)': $_" } $results += [PSCustomObject]@{ SubscriptionName = $sub.Name SubscriptionId = $sub.Id ApiManagementInstances = 1 HasDiagnosticsConfigured = $hasDiag HasVNetIntegration = $hasVnet MinimumTlsVersion = $minTls ApiManagementName = $apim.Name ResourceGroupName = $apim.ResourceGroupName } } } return $results } try { Connect-RequiredServices $subs = Get-TargetSubscriptions -Ids $SubscriptionId $data = Test-ApiSecurityBasic -Subscriptions $subs if (-not $Detailed) { Write-Host "" -ForegroundColor White Write-Host "========================================" -ForegroundColor Cyan Write-Host $CheckName -ForegroundColor Cyan Write-Host "========================================" -ForegroundColor Cyan $grouped = $data | Group-Object SubscriptionId foreach ($g in $grouped) { $sample = $g.Group | Select-Object -First 1 $hasApim = ($g.Group | Measure-Object).Count -gt 0 -and $g.Group.ApiManagementInstances -contains 1 $hasDiag = $g.Group.HasDiagnosticsConfigured -contains $true $hasVNet = $g.Group.HasVNetIntegration -contains $true Write-Host "" Write-Host ("Subscription : {0}" -f $sample.SubscriptionName) -ForegroundColor White Write-Host ("API Mgmt : {0}" -f ($(if ($hasApim) { "Aanwezig" } else { "Niet aangetroffen" }))) -ForegroundColor White Write-Host ("Diagnostics : {0}" -f ($(if ($hasDiag) { "Geconfigureerd" } else { "Niet geconfigureerd" }))) -ForegroundColor ($(if ($hasDiag) { "White" } else { "Yellow" })) Write-Host ("VNet-koppeling: {0}" -f ($(if ($hasVNet) { "Ja (ten minste één instantie)" } else { "Nee of niet van toepassing" }))) -ForegroundColor White } if ($grouped.Count -eq 0) { Write-Host "" Write-Host "Geen relevante API Management-configuraties gevonden in de geselecteerde subscripties." -ForegroundColor Yellow } } else { $data } } catch { Write-Error $_ exit 1 } # ================================================================================ # Standaard Invoke-* functions (conform Azure script-schema) # ================================================================================ function Invoke-Implementation { <# .SYNOPSIS Plaatsvervanger voor implementatie (geen automatische configuratiewijzigingen). .DESCRIPTION Dit script voert geen remediatie uit. Gebruik de resultaten van de monitoring om concrete verbeteracties in te plannen. #> [CmdletBinding()] param() Invoke-Monitoring } function Invoke-Monitoring { <# .SYNOPSIS Voert de basis-API-beveiligingscheck uit. #> [CmdletBinding()] param( [string[]]$SubscriptionId ) try { Connect-RequiredServices $subs = Get-TargetSubscriptions -Ids $SubscriptionId $null = Test-ApiSecurityBasic -Subscriptions $subs | Out-Null # Voor de monitoring-functie tonen we standaard de compacte weergave & $MyInvocation.MyCommand.Path -SubscriptionId $SubscriptionId } catch { Write-Error $_ exit 1 } } function Invoke-Remediation { <# .SYNOPSIS Ondersteunt remediatie door monitoringresultaten als uitgangspunt te nemen. .DESCRIPTION Het script voert geen automatische wijzigingen door, maar geeft richting aan verbeteracties: - Configureer API Management-diagnostiek naar Log Analytics - Beoordeel de noodzaak van VNet-integratie en private endpoints - Herzie TLS-instellingen om verouderde protocollen uit te faseren #> [CmdletBinding()] param( [string[]]$SubscriptionId ) Write-Host "[INFO] Dit script voert geen automatische remediatie uit." -ForegroundColor Yellow Write-Host "[INFO] Gebruik de monitoringoutput om concrete verbeteracties te definiëren." -ForegroundColor Yellow Invoke-Monitoring -SubscriptionId $SubscriptionId }

Risico zonder implementatie

Risico zonder implementatie
High: Zonder een samenhangend raamwerk voor API-beveiliging in Azure lopen organisaties een aanzienlijk risico op datalekken, misbruik van identiteiten en verstoring van kritieke digitale diensten. Onvoldoende beschermde API's kunnen een zwakke schakel vormen in ketens met burgers, leveranciers en andere overheidsinstanties, met mogelijke gevolgen zoals AVG-rapportageplichtige incidenten, sancties van toezichthouders, reputatieschade en langdurige hersteltrajecten.

Management Samenvatting

Dit artikel beschrijft hoe Nederlandse overheidsorganisaties API-beveiliging in Azure kunnen vormgeven vanuit een Zero Trust-benadering, met Azure API Management, WAF, sterke identiteit en netwerksegmentatie als kernbouwstenen. Door sterke authenticatie en autorisatie met OAuth2/OpenID Connect te combineren met rate limiting, mTLS en uitgebreide logging ontstaat een robuust verdedigingsmodel. Monitoring, governance en een periodieke PowerShell-controle zorgen ervoor dat de staat van API-beveiliging aantoonbaar onder controle blijft en structureel wordt verbeterd.