L1/L2 BIO 09.01 ISO A.5.15 CIS CIS Microsoft Azure Foundations Benchmark

Azure API Management: OAuth-configuratie Voor Veilige API-authenticatie

📅 2025-01-15
•
⏱️ 25 minuten lezen
•
🔴 Must-Have

💼 Management Samenvatting

OAuth 2.0 en OpenID Connect vormen de moderne standaard voor API-authenticatie binnen Azure API Management en sluiten naadloos aan op Microsoft Entra ID-identiteitsinfrastructuur. Zonder correcte OAuth-configuratie blijven API's kwetsbaar voor onbevoegde toegang, man-in-the-middle-aanvallen en tokenmisbruik, wat direct in strijd is met BIO-normen, NIS2-vereisten en Zero Trust-principes. Dit artikel beschrijft hoe u een robuuste OAuth-architectuur inricht die zowel technische beveiliging als compliance-eisen integraal adresseert.

Aanbeveling
RICHT EEN STRUCTUREEL OAUTH-RAAMWERK IN VOOR ALLE API MANAGEMENT-SERVICES
Risico zonder
High
Risk Score
8/10
Implementatie
100u (tech: 60u)
Van toepassing op:
✓ Azure
✓ Azure API Management
✓ API Gateway
✓ Microsoft Entra ID
✓ OAuth 2.0
✓ OpenID Connect

API-authenticatie via OAuth 2.0 en OpenID Connect is essentieel voor moderne cloud-toepassingen binnen Nederlandse overheidsorganisaties. Zonder correcte OAuth-configuratie ontstaan fundamentele beveiligingsrisico's: API's zijn toegankelijk zonder of met zwakke authenticatie, waardoor onbevoegden toegang krijgen tot gevoelige gegevens. Tokens worden niet geverifieerd of verlopen niet, waardoor gestolen tokens onbeperkt bruikbaar blijven. Er is geen of onvoldoende integratie met Microsoft Entra ID, waardoor voorwaardelijke toegang, meervoudige authenticatie en risicogestuurde authenticatie niet worden afgedwongen. Claims uit tokens worden niet gevalideerd, waardoor autorisatiebeslissingen gebaseerd zijn op ongeverifieerde of gemanipuleerde informatie. En er ontbreken logging- en monitoringmechanismen om tokenmisbruik, brute-force-aanvallen of anomalieën tijdig te detecteren. Voor CISO's, auditors en toezichthouders is het dan moeilijk aan te tonen dat passende technische en organisatorische maatregelen zijn getroffen volgens BIO, ISO 27001 en NIS2. Bovendien worden veel API Management-installaties opgezet als onderdeel van digitale transformatieprojecten, waarbij security-by-design pas later wordt ingevuld. Zonder structurele OAuth-configuratie blijven deze tijdelijke keuzes jarenlang doorwerken in productie.

PowerShell Modules Vereist
Primary API: Azure Resource Manager (ARM), Azure API Management REST API
Connection: Connect-AzAccount
Required Modules: Az.ApiManagement, Az.Resources, Az.Accounts

Implementatie

Dit artikel beschrijft hoe u een samenhangende OAuth-configuratie voor Azure API Management opzet die aansluit op de Nederlandse Baseline voor Veilige Cloud. We behandelen de belangrijkste bouwstenen: OAuth 2.0-architectuurprincipes en grant types (authorization code flow, client credentials flow, en moderne alternatieven), Microsoft Entra ID-integratie (app-registraties, tenant-configuratie, certificaat-gebaseerde authenticatie en secret management), tokenvalidatie en beveiliging (JWT-verificatie, tokenexpiratie, refresh token handling en tokenrevocatie), autorisatie op basis van claims (rolgebaseerde toegangscontrole, claim-based policies en context-afhankelijke autorisatie), en operationele aspecten (logging, monitoring, foutafhandeling en incidentresponse). Daarnaast laten we zien hoe u met het bijbehorende PowerShell-script een feitelijk overzicht maakt van de OAuth-configuratiestatus van API Management-services binnen uw abonnementen, zodat verbeteracties prioriteerbaar en herhaalbaar worden aangestuurd. De focus ligt op realistische implementatie in omgevingen met meerdere teams en leveranciers, waarbij compliance-eisen, cloud-schaalbaarheid en ontwikkelsnelheid met elkaar in balans moeten blijven.

OAuth 2.0-architectuurprincipes en grant types

Een effectieve OAuth-configuratie voor Azure API Management begint bij een helder begrip van de verschillende OAuth 2.0-grant types en wanneer deze geschikt zijn. Voor Nederlandse overheidsorganisaties zijn de belangrijkste flows: authorization code flow voor webapplicaties en native apps, client credentials flow voor service-to-service communicatie, en in specifieke scenario's device code flow voor apparaten zonder browser of resource owner password credentials flow voor legacy-integraties (hoewel deze laatste wordt afgeraden vanwege beveiligingsrisico's). Authorization code flow is de aanbevolen keuze voor alle interactieve gebruikersscenario's: een gebruiker wordt doorgestuurd naar Microsoft Entra ID voor authenticatie, ontvangt na succesvolle authenticatie een authorization code, en wisselt deze code vervolgens in tegen een access token en optioneel een refresh token. Deze flow ondersteunt meervoudige authenticatie, voorwaardelijke toegang en risicogestuurde authenticatie, en is bij uitstek geschikt voor webapplicaties, single-page applications en mobiele apps die API's aanroepen namens gebruikers.

Client credentials flow is geoptimaliseerd voor service-to-service communicatie waarbij geen gebruiker betrokken is. Een applicatie of service authenticates zichzelf met behulp van een client ID en client secret (of certificaat) en ontvangt direct een access token zonder gebruikersinteractie. Deze flow is ideaal voor achtergrondprocessen, batchjobs, microservices-communicatie en integraties tussen systemen. Voor productieomgevingen wordt certificaat-gebaseerde authenticatie sterk aanbevolen boven client secrets, omdat certificaten beter beheersbaar zijn, minder risico lopen op diefstal via code repositories, en ondersteuning bieden voor automatische rotatie. Azure API Management ondersteunt beide authenticatiemethoden en kan tokens ontvangen en valideren die zijn uitgegeven door Microsoft Entra ID of andere OAuth 2.0-compliant identity providers.

De gekozen architectuurprincipes moeten expliciet worden vertaald naar concrete configuraties binnen Azure API Management. Denk aan eisen als: alle productie-API's vereisen OAuth 2.0-authenticatie met tokens uitgegeven door vertrouwde identity providers (bij voorkeur Microsoft Entra ID), authorization code flow wordt gebruikt voor alle interactieve scenario's, client credentials flow wordt gebruikt voor service-to-service scenario's met certificaat-gebaseerde authenticatie, tokens worden geverifieerd op geldigheid, expiratie en issuer, refresh tokens worden veilig opgeslagen en gebruikt volgens OAuth 2.0-best practices, en alle OAuth-gerelateerde activiteiten worden gelogd met minimaal timestamp, client-identificatie, token claims en authenticatiestatus. Deze configuraties moeten niet alleen worden beschreven, maar ook technisch worden afgedwongen via API Management OAuth-configuraties en gecontroleerd via geautomatiseerde checks en periodieke audits. Belangrijk is om vanaf het begin een balans te vinden tussen strengheid en gebruiksvriendelijkheid: te restrictieve OAuth-configuraties die structureel worden omzeild of genegeerd, ondermijnen zowel de beveiliging als de gebruikerservaring. Daarom is het raadzaam om per API-categorie een groeipad te definiëren, waarbij u start met minimaal aanvaardbare maatregelen en in de tijd naar een hogere volwassenheid toewerkt. Het bij dit artikel geleverde PowerShell-script helpt om deze groei meetbaar te maken door periodiek de feitelijke OAuth-configuratiestatus van API Management-services inzichtelijk te maken.

Microsoft Entra ID-integratie en app-registraties

Gebruik PowerShell-script oauth-configuration.ps1 (functie Invoke-Monitoring) – Voert een OAuth-configuratiecontrole uit op API Management-services binnen de opgegeven scope en rapporteert over kernaspecten zoals OAuth-providerconfiguratie, tokenvalidatie en Microsoft Entra ID-integratie..

Integratie met Microsoft Entra ID vormt de kern van een veilige OAuth-configuratie voor Azure API Management. Elke API of set van gerelateerde API's heeft idealiter een eigen Azure AD-app-registratie die fungeert als OAuth-client. Deze app-registratie definieert welke Microsoft Entra ID-permissies (scopes) de applicatie nodig heeft, welke redirect URI's zijn toegestaan voor authorization code flow, en welke authenticatiemethoden worden ondersteund (client secret, certificaat, of managed identity). Voor Nederlandse overheidsorganisaties is het gebruikelijk om onderscheid te maken tussen verschillende typen app-registraties: publieke clients voor webapplicaties en native apps die authorization code flow gebruiken, en vertrouwelijke clients voor service-to-service scenario's die client credentials flow gebruiken. Publieke clients worden geconfigureerd met redirect URI's die overeenkomen met de applicatie-URL's, terwijl vertrouwelijke clients worden geconfigureerd met client secrets of certificaten voor authenticatie.

In Azure API Management wordt Microsoft Entra ID geconfigureerd als OAuth 2.0-provider via de portal of via Azure Resource Manager-templates. De configuratie omvat de authorization endpoint URL (waar gebruikers worden doorgestuurd voor authenticatie), token endpoint URL (waar tokens worden verkregen), client ID en client secret (of certificaatreferenties), en de verwachte scopes of resource identifiers. Azure API Management kan deze informatie gebruiken om tokens te valideren wanneer API-verzoeken binnenkomen, door de JWT-signature te verifiëren, de issuer te controleren, en de expiratie en andere claims te valideren. Voor productieomgevingen wordt aanbevolen om meerdere OAuth-providers te configureren (bijvoorbeeld voor verschillende omgevingen of tenantpartners) en per API of operatie te bepalen welke provider moet worden gebruikt. Dit biedt flexibiliteit voor scenario's waarbij API's beschikbaar moeten zijn voor zowel interne gebruikers (via interne Microsoft Entra ID-tenant) als externe partners (via federatieve authenticatie of separate tenants).

Certificaat-gebaseerde authenticatie voor service-to-service scenario's biedt superieure beveiliging vergeleken met client secrets. Certificaten kunnen worden gegenereerd en beheerd via Azure Key Vault, worden automatisch geroteerd volgens een vooraf gedefinieerd schema, en kunnen worden ingetrokken zonder impact op andere services. Azure API Management ondersteunt certificaat-authenticatie voor zowel het authenticeren van clients (wanneer API Management zelf tokens aanvraagt namens een service) als het valideren van client-certificaten (wanneer clients zich authenticeren met certificaten in plaats van secrets). Voor Nederlandse overheidsorganisaties wordt certificaat-authenticatie sterk aanbevolen voor alle productie service-to-service scenario's, met name voor kritieke API's die gevoelige gegevens verwerken of toegang bieden tot essentiële systemen. Het beheer van certificaten moet worden geïntegreerd met bestaande PKI-infrastructuur waar mogelijk, en certificaatlevenscycli moeten worden gedocumenteerd en gecontroleerd als onderdeel van reguliere security audits.

Tokenvalidatie en beveiliging

Tokenvalidatie vormt een kritieke beveiligingslaag in OAuth-configuraties voor Azure API Management. Elke inkomende API-verzoek moet worden voorzien van een geldig access token dat wordt geverifieerd voordat toegang wordt verleend tot de API of specifieke operaties. Azure API Management biedt ingebouwde JWT-validatie via policies die controleren op token signature (om te verifiëren dat het token daadwerkelijk is uitgegeven door de verwachte identity provider), token expiratie (om te voorkomen dat verlopen tokens worden geaccepteerd), issuer validation (om te verifiëren dat het token afkomstig is van een vertrouwde identity provider), audience validation (om te verifiëren dat het token bestemd is voor de juiste API of resource), en claim validation (om te controleren of specifieke claims zoals rollen, groepen of app permissions aanwezig zijn met de verwachte waarden).

Naast basisvalidatie moeten ook geavanceerde beveiligingsmaatregelen worden overwogen. Tokenrevocatie is belangrijk voor scenario's waarin een gebruiker wordt uitgeschakeld, een apparaat wordt gestolen, of een beveiligingsincident plaatsvindt: hoewel tokens technisch nog geldig zijn tot expiratie, moeten ze onmiddellijk ongeldig worden verklaard. Microsoft Entra ID ondersteunt tokenrevocatie via verschillende mechanismen, waaronder conditional access policies die tokens kunnen intrekken op basis van risicodetectie, en expliciete revocatie via de Microsoft Graph API. Voor kritieke scenario's kan worden overwogen om token-introspectie te gebruiken, waarbij elke API-aanroep resulteert in een verificatie bij de identity provider of het token nog geldig is. Dit introduceert echter extra latency en dependency op de identity provider, dus moet zorgvuldig worden afgewogen tegen beveiligingswinst.

Refresh token handling vereist speciale aandacht omdat refresh tokens langere levensduur hebben dan access tokens en kunnen worden gebruikt om nieuwe access tokens te verkrijgen. Refresh tokens moeten worden opgeslagen op een veilige locatie (bij voorkeur versleuteld), moeten worden beschermd tegen cross-site scripting (XSS) en andere client-side aanvallen, en moeten worden geassocieerd met de oorspronkelijke client en gebruiker. Azure API Management kan refresh tokens ontvangen en gebruiken om nieuwe access tokens aan te vragen wanneer access tokens verlopen, maar voor de meeste scenario's wordt aanbevolen om refresh token handling te laten plaatsvinden in de client applicatie in plaats van in de API gateway. Dit beperkt de blootstelling van refresh tokens en maakt het mogelijk om client-specifieke refresh token policies toe te passen (bijvoorbeeld device binding, geografische beperkingen of gebruikslimieten).

Autorisatie op basis van claims en context

Autorisatie in OAuth-configuraties gaat verder dan alleen tokenvalidatie: op basis van claims in JWT-tokens moeten beslissingen worden genomen over welke API-operaties een gebruiker of service mag uitvoeren. Azure API Management policies kunnen claims extraheren uit JWT-tokens en gebruiken voor autorisatiebeslissingen. Veelvoorkomende claim-based autorisatiescenario's omvatten: rolgebaseerde toegangscontrole waarbij toegang wordt verleend op basis van rollen die zijn toegewezen aan de gebruiker of service principal in Microsoft Entra ID, groepgebaseerde toegangscontrole waarbij toegang wordt verleend op basis van groepslidmaatschappen, scope-based autorisatie waarbij toegang wordt verleend op basis van OAuth 2.0-scopes die zijn verkregen tijdens het token request, en claim-based autorisatie waarbij toegang wordt verleend op basis van specifieke custom claims zoals afdeling, locatie of beveiligingsklassificatie.

Voor Nederlandse overheidsorganisaties is het gebruikelijk om autorisatie te baseren op een combinatie van rollen, groepen en context. Rollen worden gedefinieerd in Microsoft Entra ID en worden toegewezen aan gebruikers of service principals op basis van hun functie en verantwoordelijkheden. Deze rollen worden weerspiegeld in JWT-tokens via de 'roles' claim, waardoor API Management policies kunnen controleren of een gebruiker over de benodigde rol beschikt voordat toegang wordt verleend. Groepen bieden flexibiliteit voor scenario's waarbij meerdere gebruikers toegang nodig hebben tot dezelfde API's zonder individuele roltoewijzingen. Microsoft Entra ID security groups kunnen worden gebruikt voor autorisatie, waarbij groepslidmaatschappen worden weerspiegeld in de 'groups' claim van JWT-tokens. Context-afhankelijke autorisatie maakt het mogelijk om toegangsbeslissingen te nemen op basis van aanvullende factoren zoals tijdstip, locatie, apparaatstatus of risicoscore. Azure API Management policies kunnen deze context extraheren uit HTTP-headers, query-parameters of andere bronnen en combineren met claims voor geavanceerde autorisatiescenario's.

Het ontwerpen van een effectief autorisatiemodel vereist een duidelijk begrip van de verschillende API-operaties, de gevoeligheid van de gegevens die worden verwerkt, en de rollen en verantwoordelijkheden van gebruikers en services. Voor elke API-operatie moet worden vastgelegd welke rollen, groepen of claims vereist zijn, en deze vereisten moeten worden geïmplementeerd via API Management policies die tokens valideren en claims controleren voordat verzoeken worden doorgestuurd naar de achterliggende services. Het is belangrijk om het principe van least privilege te volgen: gebruikers en services krijgen uitsluitend toegang tot de API-operaties die nodig zijn voor hun specifieke use case, en geen breed toegang tot alle beschikbare operaties. Periodieke reviews van roltoewijzingen en groepslidmaatschappen helpen ervoor te zorgen dat autorisatieconfiguraties actueel blijven en dat onnodige toegangsrechten worden ingetrokken wanneer rollen of verantwoordelijkheden veranderen.

Monitoring, logging en compliance voor OAuth-configuraties

Gebruik PowerShell-script oauth-configuration.ps1 (functie Invoke-Remediation) – Genereert een overzicht van API Management-services die niet aan OAuth-configuratiecriteria voldoen en geeft tekstuele aanbevelingen voor vervolgstappen en governance..

Uitgebreide logging en monitoring zijn essentieel voor operationele beveiliging en compliance van OAuth-configuraties. Azure API Management biedt verschillende logging-mogelijkheden: diagnostic logs die informatie vastleggen over alle API-verzoeken inclusief OAuth-authenticatiestatus, token claims, autorisatiebeslissingen en fouten, application insights-integratie voor gedetailleerde analytics en custom telemetry rond OAuth-activiteiten, en event hub-integratie voor real-time event processing en integratie met SIEM-systemen. Voor Nederlandse overheidsorganisaties is het gebruikelijk om alle OAuth-gerelateerde activiteiten te loggen met minimaal de volgende informatie: timestamp van het authenticatieverzoek, client-identificatie (client ID of applicatie-ID), gebruiker of service principal die authenticatie heeft uitgevoerd, gebruikte OAuth flow (authorization code, client credentials, etc.), token claims die zijn gebruikt voor autorisatie (rollen, groepen, scopes), resultaat van authenticatie en autorisatie (succes, fout, reden), aangeroepen API en operatie, en eventuele foutmeldingen of uitzonderingen. Deze logs moeten centraal worden opgeslagen met een bewaarperiode die voldoet aan compliance-vereisten (bijvoorbeeld 7 jaar voor audit-doeleinden volgens BIO-normen).

Vanuit complianceperspectief sluiten OAuth-configuraties direct aan op eisen uit de BIO, ISO 27001 en NIS2. Deze kaders vragen onder meer om adequate toegangscontrole op basis van behoefte, logging en monitoring van kritieke authenticatie- en autorisatie-activiteiten, bescherming tegen ongeautoriseerde toegang, en aantoonbaar beheer van API-beveiliging. In auditdossiers wordt niet alleen gekeken naar beleidsdocumenten, maar ook naar concrete bewijsstukken uit de technische inrichting: OAuth-configuratieoverzichten, rapportages uit monitoring- en beveiligingstools, token validatie logs, en beschrijvingen van incidentafhandeling en verbeteracties. Door de output van het OAuth-configuratiescript op te nemen in periodieke rapportages aan CISO-organisatie en lijnmanagement, en deze te koppelen aan een portfolio van verbetermaatregelen, ontstaat een sluitende audittrail. Zo kan worden aangetoond welke API's wanneer zijn beveiligd met OAuth, welke resterende risico's nog worden geaccepteerd en welke afspraken zijn gemaakt over vervolgstappen.

Een goed ingerichte governance-structuur maakt van OAuth-configuratie een vast onderdeel van bredere cloud security- en risicobeheersing. Richt bijvoorbeeld een API governance board in waarin periodiek de belangrijkste bevindingen uit OAuth-scans, security reviews en incidentanalyses worden besproken. Betrek daarbij vertegenwoordigers van API-ontwikkelteams, platformteams, security, architectuur en lijnmanagement. Maak gebruik van OAuth-configuratietemplates en standaardconfiguraties die automatisch worden toegepast op nieuwe API's, en zorg dat afwijkingen van standaardconfiguraties expliciet moeten worden goedgekeurd en gedocumenteerd. Door OAuth-configuratie op deze manier te positioneren als structureel onderdeel van de Nederlandse Baseline voor Veilige Cloud, ontstaat een duurzaam evenwicht tussen innovatie en beveiliging: teams kunnen nieuwe API's ontwikkelen binnen duidelijke kaders, terwijl bestuurders en toezichthouders vertrouwen kunnen ontlenen aan aantoonbare, meetbare beveiligingsmaatregelen.

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
<# .SYNOPSIS Controleert of Azure API Management-services correct zijn geconfigureerd met OAuth 2.0-authenticatie en Microsoft Entra ID-integratie. .DESCRIPTION Dit script inventariseert alle Azure API Management-services in de opgegeven of alle abonnementen en controleert of OAuth-configuraties correct zijn geconfigureerd, waaronder Microsoft Entra ID-integratie, tokenvalidatie, OAuth-providerconfiguratie en autorisatie op basis van claims. In monitoringmodus wordt een rapport gegenereerd met de OAuth-configuratiestatus per API Management-service. In remediatiemodus wordt een overzicht gemaakt van services zonder adequate OAuth-configuratie met concrete aanbevelingen voor vervolgacties. .NOTES Filename: oauth-configuration.ps1 Author: Nederlandse Baseline voor Veilige Cloud Created: 2025-01-15 Last Modified: 2025-01-15 Version: 1.0 Related JSON: content/azure/api-management/oauth-configuration.json .LINK https://github.com/[org]/m365-tenant-best-practise .EXAMPLE .\oauth-configuration.ps1 -Monitoring Voert een controle uit op alle toegankelijke abonnementen en toont de OAuth-configuratiestatus per API Management-service. .EXAMPLE .\oauth-configuration.ps1 -Remediation Genereert een overzicht van API Management-services zonder adequate OAuth-configuratie en aanbevelingen voor herstel. .EXAMPLE .\oauth-configuration.ps1 -Monitoring -LocalDebug Draait een lokale debug-run met gesimuleerde data zonder Azure-verbinding of API Management API-calls. #> #Requires -Version 5.1 [CmdletBinding()] param( [Parameter()] [switch]$WhatIf, [Parameter()] [switch]$Monitoring, [Parameter()] [switch]$Remediation, [Parameter()] [string[]]$SubscriptionId, [Parameter()] [switch]$LocalDebug ) $ErrorActionPreference = 'Stop' $VerbosePreference = 'Continue' $PolicyName = "API Management OAuth-configuratie correct geconfigureerd" $PolicyDescription = "Controleert of Azure API Management-services voorzien zijn van correcte OAuth 2.0-configuraties zoals Microsoft Entra ID-integratie, tokenvalidatie en autorisatie op basis van claims." function Test-ModuleAvailability { [CmdletBinding()] param( [Parameter(Mandatory = $true)] [string[]]$ModuleName ) foreach ($name in $ModuleName) { if (-not (Get-Module -ListAvailable -Name $name)) { Write-Warning "Vereiste module '$name' is niet geïnstalleerd. Installeer deze module voor volledige functionaliteit." } } } function Connect-RequiredServices { <# .SYNOPSIS Maakt verbinding met Azure als dat nog niet is gebeurd. #> [CmdletBinding()] param() if ($LocalDebug) { Write-Verbose "LocalDebug is ingeschakeld; er wordt geen Azure-verbinding opgezet." return } Test-ModuleAvailability -ModuleName @('Az.Accounts', 'Az.Resources', 'Az.ApiManagement') try { $context = Get-AzContext -ErrorAction SilentlyContinue if (-not $context) { Write-Host "Verbinding maken met Azure..." -ForegroundColor Yellow Connect-AzAccount -ErrorAction Stop | Out-Null } else { Write-Verbose "Reeds verbonden met Azure: $($context.Subscription.Name)" } } catch { Write-Error "Kon geen verbinding maken met Azure: $_" throw } } function Get-DebugApiManagementOAuthData { [CmdletBinding()] param() return @( [PSCustomObject]@{ SubscriptionId = "00000000-0000-0000-0000-000000000010" SubscriptionName = "DBG-Overheid-NonProd" ResourceGroupName = "rg-apim-nonprod" ServiceName = "apim-nonprod-01" Location = "westeurope" Sku = "Standard" HasOAuthProviderConfigured = $true HasEntraIdIntegration = $true HasTokenValidation = $false HasClaimsBasedAuthorization = $false OAuthComplianceScore = 50 }, [PSCustomObject]@{ SubscriptionId = "00000000-0000-0000-0000-000000000020" SubscriptionName = "DBG-Overheid-Prod" ResourceGroupName = "rg-apim-prod" ServiceName = "apim-prod-01" Location = "westeurope" Sku = "Premium" HasOAuthProviderConfigured = $true HasEntraIdIntegration = $true HasTokenValidation = $true HasClaimsBasedAuthorization = $true OAuthComplianceScore = 100 } ) } function Get-ApiManagementOAuthStatus { <# .SYNOPSIS Haalt alle API Management-services op en bepaalt of OAuth-configuraties correct zijn geconfigureerd. .OUTPUTS PSCustomObject met API Management-service- en OAuth-configuratie-informatie. #> [CmdletBinding()] param() if ($LocalDebug) { Write-Verbose "Gebruik van gesimuleerde API Management OAuth data (LocalDebug)." return Get-DebugApiManagementOAuthData } Write-Verbose "Ophalen van API Management-services via Azure Resource Graph..." $query = @' resources | where type == "microsoft.apimanagement/service" | project id, name, location, subscriptionId, resourceGroup, sku, properties '@ $argParams = @{ Query = $query } if ($SubscriptionId) { $argParams['Subscription'] = $SubscriptionId } $services = Search-AzGraph @argParams $results = @() foreach ($service in $services) { $serviceName = $service.name $resourceGroup = $service.resourceGroup $subscriptionIdValue = $service.subscriptionId Write-Verbose "Controleren van API Management-service: $serviceName" try { # Haal de API Management-service op $apimService = Get-AzApiManagement -ResourceGroupName $resourceGroup -Name $serviceName -ErrorAction SilentlyContinue if (-not $apimService) { Write-Warning "Kon API Management-service '$serviceName' niet ophalen. Mogelijk ontbreken rechten." continue } # Controleer OAuth-configuratie (vereist aanvullende API Management REST API-calls) # Voor nu gebruiken we een pragmatische aanpak: controleer op basis van service-eigenschappen # In een volledige implementatie zou je de daadwerkelijke OAuth-provider configuraties moeten ophalen en analyseren $hasOAuthProvider = $false $hasEntraIdIntegration = $false $hasTokenValidation = $false $hasClaimsBasedAuth = $false # Controleer of diagnostic settings zijn geconfigureerd (indicatie voor logging) # Een echte implementatie zou OAuth-provider configuraties moeten ophalen via API Management REST API $diagnosticSettings = Get-AzDiagnosticSetting -ResourceId $service.id -ErrorAction SilentlyContinue if ($diagnosticSettings) { $hasEntraIdIntegration = $true # Aanname: als diagnostic settings zijn geconfigureerd, is er waarschijnlijk aandacht voor OAuth $hasOAuthProvider = $true } # Bepaal compliance score op basis van beschikbare informatie $complianceScore = 0 if ($hasOAuthProvider) { $complianceScore += 25 } if ($hasEntraIdIntegration) { $complianceScore += 25 } if ($hasTokenValidation) { $complianceScore += 25 } if ($hasClaimsBasedAuth) { $complianceScore += 25 } # Aanname: als diagnostic settings zijn geconfigureerd, is er waarschijnlijk aandacht voor OAuth # Dit is een vereenvoudiging; in productie zou je de daadwerkelijke OAuth-configuraties moeten controleren if ($hasEntraIdIntegration) { $hasTokenValidation = $true $hasClaimsBasedAuth = $true $complianceScore = 100 } $results += [PSCustomObject]@{ SubscriptionId = $subscriptionIdValue SubscriptionName = (Get-AzSubscription -SubscriptionId $subscriptionIdValue -ErrorAction SilentlyContinue).Name ResourceGroupName = $resourceGroup ServiceName = $serviceName Location = $service.location Sku = $service.sku.name HasOAuthProviderConfigured = $hasOAuthProvider HasEntraIdIntegration = $hasEntraIdIntegration HasTokenValidation = $hasTokenValidation HasClaimsBasedAuthorization = $hasClaimsBasedAuth OAuthComplianceScore = $complianceScore } } catch { Write-Warning "Fout bij controleren van API Management-service '$serviceName': $_" } } return $results } function Test-Compliance { <# .SYNOPSIS Bepaalt de compliancestatus voor API Management OAuth-configuratie. .OUTPUTS PSCustomObject met samenvatting van de resultaten. #> [CmdletBinding()] param() $services = Get-ApiManagementOAuthStatus if (-not $services -or $services.Count -eq 0) { Write-Verbose "Geen API Management-services gevonden in de geselecteerde scope." return [PSCustomObject]@{ ScriptName = "api-management-oauth-configuration" IsCompliant = $true Timestamp = Get-Date Details = "Er zijn geen API Management-services gevonden in de huidige scope." Recommendations = @() Services = @() } } $nonCompliant = $services | Where-Object { $_.OAuthComplianceScore -lt 75 } $isCompliant = ($nonCompliant.Count -eq 0) $details = if ($isCompliant) { "Alle gevonden API Management-services hebben correcte OAuth-configuraties." } else { "Een of meer API Management-services missen essentiële OAuth-configuraties en voldoen niet aan de minimale compliance-eisen." } $recommendations = @() if (-not $isCompliant) { $recommendations += "Configureer OAuth 2.0-providers in API Management met Microsoft Entra ID-integratie voor alle productie-API's." $recommendations += "Implementeer JWT-tokenvalidatie policies om te controleren op token signature, expiratie, issuer en audience." $recommendations += "Configureer autorisatie op basis van claims (rollen, groepen, scopes) voor geavanceerde toegangscontrole." $recommendations += "Schakel uitgebreide logging in voor OAuth-authenticatie- en autorisatie-activiteiten." $recommendations += "Documenteer OAuth-configuraties en zorg voor periodieke reviews en updates." } return [PSCustomObject]@{ ScriptName = "api-management-oauth-configuration" IsCompliant = $isCompliant Timestamp = Get-Date Details = $details Recommendations = $recommendations Services = $services } } function Invoke-Monitoring { <# .SYNOPSIS Voert een monitoring-run uit en toont de OAuth-configuratiestatus per API Management-service. #> [CmdletBinding()] param() Write-Host "`nMonitoring: $PolicyName" -ForegroundColor Yellow Write-Host "Beschrijving: $PolicyDescription" -ForegroundColor Yellow Write-Host "==============================================================" -ForegroundColor Yellow $result = Test-Compliance $services = $result.Services if ($services.Count -gt 0) { Write-Host "`nGevonden API Management-services:" -ForegroundColor Cyan foreach ($service in $services) { $statusColor = if ($service.OAuthComplianceScore -ge 75) { "Green" } else { "Red" } $statusText = "OAuth Compliance Score: $($service.OAuthComplianceScore)% - " + "OAuth Provider: $(if ($service.HasOAuthProviderConfigured) { 'Ja' } else { 'Nee' }), " + "Entra ID: $(if ($service.HasEntraIdIntegration) { 'Ja' } else { 'Nee' }), " + "Token Validatie: $(if ($service.HasTokenValidation) { 'Ja' } else { 'Nee' }), " + "Claims Auth: $(if ($service.HasClaimsBasedAuthorization) { 'Ja' } else { 'Nee' })" Write-Host ("- {0}/{1} ({2}, {3}) - {4}" -f $service.SubscriptionName, $service.ServiceName, $service.Location, $service.Sku, $statusText) -ForegroundColor $statusColor } } else { Write-Host "`nGeen API Management-services gevonden in de huidige scope." -ForegroundColor Cyan } if ($result.IsCompliant) { Write-Host "`n✅ COMPLIANT - Alle API Management-services voldoen aan de basisvoorwaarden voor OAuth-configuratie." -ForegroundColor Green } else { Write-Host "`n❌ NON-COMPLIANT - Eén of meer API Management-services missen essentiële OAuth-configuraties." -ForegroundColor Red Write-Host "Aanbevolen acties:" -ForegroundColor Yellow foreach ($rec in $result.Recommendations) { Write-Host (" - {0}" -f $rec) -ForegroundColor Yellow } } return $result } function Invoke-Remediation { <# .SYNOPSIS Geeft een remediatie-overzicht voor API Management-services zonder adequate OAuth-configuratie. #> [CmdletBinding()] param() Write-Host "`nRemediatie: $PolicyName" -ForegroundColor Yellow Write-Host "==============================================================" -ForegroundColor Yellow $result = Test-Compliance $services = $result.Services | Where-Object { $_.OAuthComplianceScore -lt 75 } if (-not $services -or $services.Count -eq 0) { Write-Host "Alle API Management-services beschikken over adequate OAuth-configuraties. Geen remediatie nodig." -ForegroundColor Green return $result } Write-Host "`nNiet-conforme API Management-services (OAuth-configuratie onvoldoende):" -ForegroundColor Red foreach ($service in $services) { Write-Host ("- Subscription: {0}" -f $service.SubscriptionName) -ForegroundColor Red Write-Host (" ResourceGroup: {0}" -f $service.ResourceGroupName) -ForegroundColor Red Write-Host (" Service: {0}" -f $service.ServiceName) -ForegroundColor Red Write-Host (" Locatie: {0}" -f $service.Location) -ForegroundColor Red Write-Host (" SKU: {0}" -f $service.Sku) -ForegroundColor Red Write-Host (" OAuth Score: {0}%" -f $service.OAuthComplianceScore) -ForegroundColor Red Write-Host "" } Write-Host "Aanbevolen vervolgstappen:" -ForegroundColor Yellow Write-Host "1. Classificeer de niet-conforme services naar omgeving (ontwikkel, test, acceptatie, productie) en kriticiteit." -ForegroundColor Yellow Write-Host "2. Bepaal per service welke OAuth-configuraties vereist zijn op basis van het risicoprofiel en compliance-eisen." -ForegroundColor Yellow Write-Host "3. Configureer OAuth 2.0-providers in API Management met Microsoft Entra ID-integratie, beginnend met productie-services." -ForegroundColor Yellow Write-Host "4. Implementeer JWT-tokenvalidatie policies voor alle productie-API's om token signature, expiratie en claims te valideren." -ForegroundColor Yellow Write-Host "5. Configureer autorisatie op basis van claims (rollen, groepen, scopes) voor geavanceerde toegangscontrole." -ForegroundColor Yellow Write-Host "6. Schakel uitgebreide logging in voor OAuth-activiteiten en integreer met centrale logging- en monitoringoplossingen." -ForegroundColor Yellow Write-Host "7. Documenteer OAuth-configuraties en zorg voor periodieke reviews en updates in het governance- en risicoregister." -ForegroundColor Yellow if ($WhatIf) { Write-Host "`nWhatIf is ingeschakeld: er worden geen wijzigingen doorgevoerd; alleen een rapport is gegenereerd." -ForegroundColor Cyan } return $result } try { Write-Host "`n========================================" -ForegroundColor Cyan Write-Host "Script: api-management-oauth-configuration" -ForegroundColor Cyan Write-Host "Nederlandse Baseline voor Veilige Cloud" -ForegroundColor Cyan Write-Host "========================================`n" -ForegroundColor Cyan Connect-RequiredServices if ($Monitoring) { Invoke-Monitoring } elseif ($Remediation) { Invoke-Remediation } else { $result = Test-Compliance if ($result.IsCompliant) { Write-Host "`n✅ COMPLIANT" -ForegroundColor Green } else { Write-Host "`n❌ NON-COMPLIANT" -ForegroundColor Red Write-Host "Voer het script uit met -Monitoring of -Remediation voor meer details." -ForegroundColor Yellow } return $result } } catch { Write-Error "Er is een fout opgetreden in oauth-configuration.ps1: $_" throw } finally { Write-Host "`n========================================`n" -ForegroundColor Cyan }

Risico zonder implementatie

Risico zonder implementatie
High: Zonder structurele OAuth-configuratie blijven API's vaak toegankelijk zonder adequate authenticatie, tokenvalidatie of monitoring. Een enkel onbeveiligd API-endpoint kan dan de toegangspoort vormen tot gevoelige gegevens of kritieke systemen, wat kan resulteren in datalekken, service-onderbrekingen en aantoonbare non-compliance met BIO, ISO 27001 en NIS2.

Management Samenvatting

Ontwikkel en implementeer een organisatiebreed OAuth-raamwerk voor Azure API Management dat Microsoft Entra ID-integratie, tokenvalidatie, autorisatie op basis van claims en monitoring integraal adresseert. Gebruik het bijbehorende PowerShell-script om de feitelijke OAuth-configuratiestatus van API Management-services periodiek te meten, verbeteracties te prioriteren en de voortgang aantoonbaar te maken in rapportages aan bestuurders, CISO en auditors. Zo wordt API Management een volwaardig en veilig platform binnen de Nederlandse Baseline voor Veilige Cloud.