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

Azure API Management: Beveiligingspolicies Voor Een Robuuste API-laag

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

💼 Management Samenvatting

Beveiligingspolicies in Azure API Management bepalen in hoge mate hoe weerbaar uw API-landschap is tegen misbruik, fouten en aanvallen. Voor Nederlandse overheidsorganisaties, waar API’s steeds vaker worden ingezet voor gegevensuitwisseling met burgers, ketenpartners en andere bestuurslagen, vormen deze policies een cruciale schakel tussen architectuurprincipes op papier en daadwerkelijk geïmplementeerde beveiliging in de praktijk.

Aanbeveling
RICHT EEN CONSISTENT STELSEL VAN BEVEILIGINGSPOLICIES IN VOOR ALLE API MANAGEMENT-API’S
Risico zonder
High
Risk Score
8/10
Implementatie
100u (tech: 60u)
Van toepassing op:
✓ Azure
✓ Azure API Management
✓ API Gateway
✓ Microservices

Zonder expliciet ontworpen beveiligingspolicies groeit Azure API Management al snel uit tot een verzameling losse API’s met uiteenlopende beveiligingsniveaus. Sommige endpoints hebben wel rate limiting terwijl andere onbeperkt verkeer toestaan, CORS-configuraties worden project voor project ad hoc ingesteld en IP-filtering ontbreekt of is inconsistent. In zo’n situatie is het voor CISO’s, architecten en auditors vrijwel onmogelijk om aan te tonen dat alle API’s voldoen aan de eisen uit de BIO, ISO 27001 en NIS2. Daarnaast neemt het risico op incidenten snel toe: een vergeten test-endpoint kan massaal worden misbruikt, een te permissieve CORS-instelling maakt cross-site-aanvallen mogelijk en het ontbreken van inputvalidatie kan leiden tot injection-aanvallen of verstoring van achterliggende systemen. Voor publieke diensten, waar continuïteit, betrouwbaarheid en vertrouwelijkheid van gegevens centraal staan, zijn dit onacceptabele risico’s.

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

Implementatie

Dit artikel beschrijft hoe u binnen Azure API Management een consistent en toetsbaar stelsel van beveiligingspolicies inricht. De nadruk ligt op drie pijlers: bescherming tegen misbruik en overbelasting (rate limiting en quota), beperking van het aanvalsoppervlak (IP-filtering, netwerksegmentatie en integratie met WAF) en het gecontroleerd toestaan van browsertoegang (CORS-configuratie en header-hardenings). Daarnaast gaan we in op validatie- en transformatiepolicies die helpen om schadelijke payloads te blokkeren en gevoelige informatie te maskeren. Het artikel sluit inhoudelijk aan op de bestaande stukken over OAuth-configuratie en algemene policyinrichting, maar focust specifiek op de concrete beveiligingsmaatregelen die in policies moeten worden vastgelegd. Het gekoppelde PowerShell-script biedt een praktische manier om binnen uw tenant periodiek te controleren of API Management-instances ten minste aan een basisset van beveiligingspolicies voldoen en waar bijsturing nodig is.

Een uniforme beveiligingsbaseline voor API Management-policies

Het opzetten van effectieve beveiligingspolicies begint met het definiëren van een organisatiewijde baseline: een minimale set aan eisen waaraan elke productie-API in Azure API Management moet voldoen. Voor Nederlandse overheidsorganisaties is die baseline onlosmakelijk verbonden met de Nederlandse Baseline voor Veilige Cloud en de BIO. In de praktijk betekent dit dat voor elke API expliciet moet zijn vastgelegd hoe de identiteit van de aanroepende partij wordt vastgesteld, hoe misbruik en overbelasting worden voorkomen, hoe ongewenste herkomst wordt geblokkeerd en hoe data onderweg en in de logketen worden beschermd. De baseline moet niet alleen in beleid worden beschreven, maar vooral worden vertaald naar herbruikbare policies en policy fragments in API Management, zodat nieuwe API’s automatisch volgens dezelfde patronen worden beveiligd. Denk aan een set standaardpolicies voor authenticatie (bijvoorbeeld validate-jwt op basis van Microsoft Entra ID), rate limiting per abonnement, IP-filtering voor interne API’s en logging naar een centraal Log Analytics-werkruimte. Door deze bouwstenen te combineren tot een duidelijk gedefinieerde baseline, ontstaat een voor ontwikkelteams hanteerbaar kader dat tegelijkertijd sterk genoeg is om auditors en toezichthouders vertrouwen te bieden.

Bij het ontwerp van deze baseline is het essentieel om verschillende API-categorieën te onderscheiden. Publieke API’s die via het internet beschikbaar zijn vragen om een strakker beveiligingsregime dan interne API’s die uitsluitend binnen een specifiek netwerksegment gebruikt worden, maar ook interne API’s verdienen nadrukkelijke aandacht omdat misconfiguraties daar vaak langer onopgemerkt blijven. Voor elke categorie worden concrete eisen gedefinieerd: verplichte TLS-versie, minimale authenticatiestandaard, maximale requestgrootte, vereiste headers, loggingniveau en bewaartermijnen. Deze eisen worden vervolgens geïmplementeerd als policies die op product- of API-niveau worden toegepast. Een goed ontwerp zorgt ervoor dat ontwikkelteams zelden rechtstreeks in policy-XML hoeven te werken; in plaats daarvan kiezen zij bij het publiceren van een API uit een beperkt aantal vooraf gedefinieerde policyprofielen (bijvoorbeeld "publiek hoog risico", "ketenkoppeling vertrouwelijk", "intern beheerders-API"). Hierdoor wordt de kans klein dat individuele teams onbewust afwijken van de afgesproken baseline, terwijl uitzonderingen bewust en gedocumenteerd kunnen worden gemaakt via een governanceproces.

Een beveiligingsbaseline blijft alleen effectief als deze aantoonbaar wordt nageleefd. Dat vraagt om meer dan een eenmalige inrichting: periodieke controles, rapportages en verbetercycli zijn noodzakelijk om te voorkomen dat ad hoc-aanpassingen of tijdelijke uitzonderingen blijvend de kwaliteit ondergraven. De Nederlandse Baseline voor Veilige Cloud raadt daarom aan om de gekozen baseline niet alleen in architectuurdocumentatie en beleid vast te leggen, maar ook in een set geautomatiseerde checks, bijvoorbeeld via PowerShell-scripts en pipelines die de configuratie van API Management regelmatig scannen op afwijkingen. Zo kan worden gecontroleerd of alle productie-API’s de juiste policyprofielen gebruiken, of er endpoints zijn zonder rate limiting of IP-filtering, en of CORS-instellingen nog steeds overeenkomen met de actuele lijst van toegestane clients. De inzichten uit deze controles worden vervolgens gebruikt om prioriteiten te stellen in het verbeterportfolio en om bestuurders en CISO’s te informeren over de feitelijke staat van de API-beveiliging.

Bescherming tegen misbruik: rate limiting en quota

Rate limiting en quota zijn fundamentele middelen om API’s te beschermen tegen zowel kwaadwillend als onbedoeld overmatig gebruik. In Azure API Management worden deze maatregelen doorgaans in policies vastgelegd op product- of API-niveau. Voor Nederlandse overheidsorganisaties is het belangrijk om rate limiting niet alleen te zien als een technische instelling, maar als onderdeel van een bredere risicobenadering: voor welke diensten kan een groot aantal verzoeken in korte tijd schadelijk zijn, welke afhankelijkheden bestaan er in ketens, en hoe verhouden capaciteit en beschikbaarheidseisen zich tot het gedrag van afnemers? Een API die gegevens uit een bronregistratie ontsluit kan bijvoorbeeld al grote impact ervaren bij relatief lage volumina, zeker wanneer meerdere ketenpartners gelijktijdig gebruikmaken van dezelfde infrastructuur. Door in policies expliciet te definiëren hoeveel verzoeken per tijdvenster zijn toegestaan per abonnement, per client of per IP-adres, wordt het risico op overbelasting sterk verminderd en wordt misbruik sneller zichtbaar in monitoring en logging.

Een volwassen inrichting van rate limiting vraagt om differentiatie. Niet iedere afnemer, omgeving of use case is hetzelfde. API Management biedt de mogelijkheid om per product of abonnement andere limieten te hanteren, bijvoorbeeld door burgers via publieke portalen een relatief beperkte doorvoer te geven, terwijl interne batchprocessen in afgesproken vensters hogere limieten krijgen. Voor kritieke back-enddiensten kan bovendien een combinatie worden gemaakt van rate limiting in API Management en backpressure-mechanismen in de achterliggende applicaties, zodat overbelasting gecontroleerd wordt afgevangen in plaats van leidt tot harde fouten. Het is daarbij essentieel dat limieten worden afgeleid uit capaciteitsmetingen en loadtests, en periodiek worden geëvalueerd. Te strikte limieten leiden tot frustratie bij legitieme gebruikers, terwijl te ruime limieten de beoogde bescherming ondermijnen. In de context van de Nederlandse Baseline voor Veilige Cloud is het raadzaam om rate limiting te koppelen aan classificatie en risicoprofielen van API’s, zodat de strengheid van maatregelen aantoonbaar past bij de gevoeligheid en kritikaliteit van de dienst.

Naast momentane rate limiting is ook het gebruik van quota over langere perioden belangrijk. Quota-policies in Azure API Management kunnen het totale aantal verzoeken per dag, week of maand begrenzen, of bijvoorbeeld de hoeveelheid verwerkte data beperken. Dit is met name relevant wanneer contractuele afspraken zijn gemaakt over maximaal verbruik door externe partijen, of wanneer achterliggende systemen slechts een beperkt volume aan transacties kunnen verwerken zonder merkbare prestatieverlies. Door quota in policies vast te leggen, kunnen organisaties vroegtijdig signaleren wanneer afnemers structureel boven de afgesproken drempels uitkomen en hierover in gesprek gaan voordat incidenten optreden. Logging en rapportages over rate limiting- en quota-events vormen bovendien waardevolle auditinformatie: zij laten zien dat de organisatie actief maatregelen heeft getroffen om misbruik tegen te gaan en dat deze maatregelen daadwerkelijk effect sorteren in de praktijk.

Beperking van het aanvalsoppervlak: IP-filtering en netwerkcontroles

Naast volumegerichte maatregelen zijn ook brongebaseerde controles nodig om het aanvalsoppervlak van API’s te beperken. IP-filtering in Azure API Management biedt hiervoor een laagdrempelige maar krachtige mogelijkheid: policies kunnen expliciet vastleggen vanaf welke IP-adressen of IP-bereiken verkeer wordt geaccepteerd. Voor interne API’s die uitsluitend voor eigen medewerkers of specifieke ketenpartners bestemd zijn, is het in de context van de Nederlandse Baseline voor Veilige Cloud verstandig om standaard whitelisting toe te passen: alleen verkeer vanuit bekende, geautoriseerde netwerksegmenten wordt toegestaan. Dit kan bijvoorbeeld het kantoornetwerk zijn, het VPN-domein voor thuiswerkers, of de adresruimten van een ketenpartner waarmee contractueel afspraken zijn gemaakt. Publieke API’s, die toegang moeten bieden aan een breed scala aan clients, kunnen IP-filtering vooral gebruiken om bekende kwaadwillende adressen uit te sluiten en om bepaalde geografische regio’s te blokkeren wanneer daar geen legitiem gebruik vandaan wordt verwacht.

IP-filtering is echter geen op zichzelf staande maatregel; de effectiviteit hangt sterk samen met de netwerkarchitectuur rond API Management. In veel moderne opzetten wordt API Management via private endpoints gekoppeld aan een virtueel netwerk en wordt internettoegang alleen via een Application Gateway of andere reverse proxy met Web Application Firewall (WAF) toegestaan. In dat scenario geven WAF- en firewallcomponenten een betrouwbaarder beeld van de werkelijke client-IP dan API Management zelf, dat anders vooral het IP-adres van de tussenliggende proxy zou zien. Het is daarom cruciaal dat architecten en beheerders goed begrijpen waar in de keten IP-filtering wordt toegepast en welke headers of attributen worden gebruikt om het oorspronkelijke clientadres door te geven. Wanneer meerdere lagen IP-controles uitvoeren, moeten deze consistent worden geconfigureerd om te voorkomen dat legitiem verkeer ten onrechte wordt geblokkeerd of dat kwaadwillenden via een omweg alsnog toegang krijgen.

Voor Nederlandse overheidsorganisaties, die vaak te maken hebben met complexe ketens en meerdere leveranciers, is het verstandig om IP-filteringbeleid expliciet op te nemen in architectuurdocumentatie en contracten. In beleid wordt beschreven voor welke API-categorieën whitelisting verplicht is, hoe uitzonderingen worden aangevraagd en beoordeeld, en hoe regelmatig wordt gecontroleerd of toegestane IP-bereiken nog actueel zijn. In contracten met ketenpartners wordt vastgelegd vanuit welke netwerken zij koppelen en welke beveiligingsmaatregelen zij zelf nemen om misbruik vanuit hun domein te voorkomen. Rollen en verantwoordelijkheden voor het beheren van IP-lijsten, het doorvoeren van wijzigingen en het reageren op incidenten moeten helder zijn belegd. Deze afspraken worden in de technische laag vertaald naar concrete policies in API Management en naar configuratie in firewalls en WAF’s, zodat er een sluitende keten ontstaat van beleid naar uitvoering.

Veilige browsertoegang: CORS en header-hardenings

Veel moderne webapplicaties communiceren rechtstreeks vanuit de browser met API’s in Azure API Management. Zonder correcte CORS-configuratie (Cross-Origin Resource Sharing) zullen browsers dergelijke aanroepen blokkeren, maar te permissieve CORS-instellingen kunnen leiden tot ernstige beveiligingsproblemen. In plaats van de verleiding te volgen om tijdens ontwikkeltrajecten een wildcard-configuratie (`*`) te gebruiken die alles toestaat, is het binnen de Nederlandse Baseline voor Veilige Cloud essentieel om CORS altijd zo restrictief mogelijk in te richten. Dat betekent dat in policies expliciet wordt vastgelegd welke origins toegang mogen hebben, welke HTTP-methoden en headers zijn toegestaan, en of credentials (zoals cookies of autorisatie-headers) vanuit de browser mogen worden meegestuurd. Deze instellingen worden idealiter per product of API afgestemd op de concrete clientapplicaties die gebruikmaken van de API, en worden regelmatig herzien wanneer nieuwe clients worden toegevoegd of oude vervallen.

Naast CORS spelen ook HTTP-headers een belangrijke rol in de beveiliging van browsergebaseerde API-toegang. Beveiligingsheaders zoals `Strict-Transport-Security`, `X-Content-Type-Options`, `X-Frame-Options`, `Referrer-Policy` en `Content-Security-Policy` helpen om bekende aanvalsvectoren zoals clickjacking, MIME-sniffing, ongewenste framing en datalekken via referer-informatie te beperken. Hoewel veel van deze headers vaak worden geconfigureerd op het niveau van webservers of omgekeerde proxies, kan Azure API Management via policies aanvullende headers toevoegen, overschrijven of afdwingen. In een volwassen inrichting worden deze header-hardenings onderdeel van een standaardpolicyprofiel dat op alle publieke API’s wordt toegepast, zodat clients overal hetzelfde beveiligingsniveau ervaren. Tegelijk moet worden voorkomen dat onnodig strikte instellingen legitieme functionaliteit blokkeren; daarom is nauwe samenwerking nodig tussen security, architectuur en ontwikkelteams om per dienst de juiste balans te vinden.

Voor auditors en toezichthouders is het belangrijk dat organisaties kunnen aantonen welke CORS- en headerconfiguraties gelden voor kritieke API’s en hoe deze aansluiten op breder vastgesteld web- en API-beveiligingsbeleid. Dit vraagt om documentatie die verder gaat dan een losse opsomming van policies: er moet een duidelijke verhaallijn zijn waarin wordt uitgelegd waarom bepaalde origins zijn toegestaan, waarom bepaalde headers worden toegevoegd of juist geblokkeerd, en hoe uitzonderingen worden beheerd. In de praktijk betekent dit dat elke wijziging in CORS- of headerbeleid een formele wijziging is met een risicoafweging en, waar relevant, betrokkenheid van privacy officers (bijvoorbeeld wanneer het delen van informatie tussen domeinen privacyrisico’s introduceert). Door deze governance vast te leggen en te koppelen aan concrete configuratie in API Management, ontstaat een transparante en controleerbare inrichting die bestand is tegen zowel technische als juridische toetsing.

Validatie, monitoring en governance van beveiligingspolicies

Gebruik PowerShell-script api-management-security-policies.ps1 (functie Invoke-Monitoring) – Voert een tenant-brede controle uit op basisbeveiligingspolicies in Azure API Management, waaronder rate limiting, IP-filtering en diagnostische logging..

Beveiligingspolicies hebben alleen waarde als ze daadwerkelijk zijn ingeschakeld, correct functioneren en actief worden bewaakt. Voor Nederlandse overheidsorganisaties is het daarom noodzakelijk om validatie en monitoring van API Management-beveiligingspolicies structureel in te bedden in de reguliere security- en operationsprocessen. Dat begint met goede diagnostische logging: alle relevante gebeurtenissen rond rate limiting, quota-overschrijdingen, geblokkeerde IP-adressen, CORS-fouten en validatieproblemen moeten worden vastgelegd in een centrale logvoorziening, zoals een Log Analytics-werkruimte of een SIEM-oplossing. Vanuit deze logging worden dashboards en alerts ingericht die operations- en securityteams helpen om tijdig afwijkingen te herkennen, bijvoorbeeld een plotselinge toename van geblokkeerde verzoeken uit een bepaald IP-bereik of een structureel patroon van quota-overschrijdingen bij een specifieke afnemer. Deze signalen vormen vervolgens input voor zowel technische maatregelen (bijvoorbeeld het aanscherpen van rate limits) als organisatorische acties (bijvoorbeeld het herzien van contractafspraken met een ketenpartner).

Validatie gaat verder dan monitoring van runtime-gedrag; ook de configuratie zelf moet regelmatig worden getoetst aan de afgesproken baseline. Het bij dit artikel behorende PowerShell-script leest via Azure Resource Graph en management-API’s de configuratie van API Management-instances en beoordeelt of minimaal vereiste beveiligingspolicies zijn ingericht. In eerste instantie richt het script zich op pragmatische indicatoren, zoals de aanwezigheid van diagnostische instellingen, het gebruik van standaard policyprofielen of specifieke tagging die aangeeft dat rate limiting en IP-filtering zijn toegepast. In meer volwassen omgevingen kan de scriptlogica worden uitgebreid met gedetailleerde analyse van policy-XML, zodat concreet wordt vastgesteld welke rules per API gelden. Belangrijk is dat het script geen directe wijzigingen aanbrengt, maar rapportages genereert die gebruikt kunnen worden in changeprocessen en IaC-pipelines. Zo blijft de verantwoordelijkheid voor configuratiewijzigingen bij de daarvoor ingerichte teams, terwijl de CISO-organisatie wel beschikt over een objectief en herhaalbaar beeld van de feitelijke beveiligingsstatus.

Governance tenslotte zorgt ervoor dat bevindingen uit monitoring en validatie leiden tot duurzame verbeteringen. De Nederlandse Baseline voor Veilige Cloud adviseert om beveiligingspolicies voor API Management te verankeren in een bredere cloud governance-structuur, bijvoorbeeld door een API governance board of cloud security board. In zo’n overleg worden periodiek de rapportages uit scripts en monitoring besproken, worden uitzonderingen op de baseline geëvalueerd en wordt besloten over de prioritering van verbetermaatregelen. Daarbij is het belangrijk om zowel technische als niet-technische aspecten te adresseren: naast het aanscherpen van policies kunnen bijvoorbeeld ook ontwikkelstandaarden, opleidingsprogramma’s of leverancierscontracten moeten worden aangepast. Door beveiligingspolicies op deze manier te verbinden met governance en risicomanagement, groeit de volwassenheid van het API-landschap stap voor stap en neemt de kans op herhaling van dezelfde kwetsbaarheden af. API Management wordt daarmee niet alleen een technische gateway, maar een aantoonbaar geborgd onderdeel van de weerbaarheid van de digitale overheid.

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 basisbeveiligingspolicies voor Azure API Management-services. .DESCRIPTION Dit script inventariseert Azure API Management-services en controleert op een aantal kernindicatoren voor beveiligingspolicies, zoals het gebruik van diagnostische logging (als proxy voor actieve policies), en biedt een uitbreidbaar kader voor aanvullende controles op rate limiting, IP-filtering en andere beveiligingsmaatregelen. Het script is bewust defensief opgezet: het voert GEEN wijzigingen uit in Azure-resources, maar levert een feitelijk overzicht met bevindingen en aanbevelingen in lijn met de Nederlandse Baseline voor Veilige Cloud. .NOTES Filename: api-management-security-policies.ps1 Author: Nederlandse Baseline voor Veilige Cloud Created: 2025-11-26 Last Modified: 2025-11-26 Version: 1.0 Related JSON: content/azure/api-management/api-management-security-policies.json .LINK https://github.com/[org]/m365-tenant-best-practise .EXAMPLE .\api-management-security-policies.ps1 -Monitoring Voert een controle uit op alle toegankelijke abonnementen en toont een samenvatting van de basisbeveiligingsstatus per API Management-service. .EXAMPLE .\api-management-security-policies.ps1 -Remediation Genereert een overzicht van API Management-services met ontbrekende of zwakke beveiligingsindicatoren en aanbevelingen voor herstel. .EXAMPLE .\api-management-security-policies.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 beveiligingspolicies ingericht" $PolicyDescription = "Controleert of Azure API Management-services zijn voorzien van basisbeveiligingsindicatoren zoals diagnostische logging en voorbereide policykaders voor rate limiting en IP-filtering." 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 indien nodig. #> [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', 'Az.Monitor') 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-DebugSecurityPolicyData { [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" HasDiagnosticLogging = $true HasBaselinePolicyProfile = $true HasIpFilteringIndicators = $true HasRateLimitIndicators = $true SecurityPolicyScore = 85 }, [PSCustomObject]@{ SubscriptionId = "00000000-0000-0000-0000-000000000020" SubscriptionName = "DBG-Overheid-Prod" ResourceGroupName = "rg-apim-prod" ServiceName = "apim-prod-01" Location = "westeurope" Sku = "Premium" HasDiagnosticLogging = $true HasBaselinePolicyProfile = $true HasIpFilteringIndicators = $true HasRateLimitIndicators = $true SecurityPolicyScore = 100 }, [PSCustomObject]@{ SubscriptionId = "00000000-0000-0000-0000-000000000030" SubscriptionName = "DBG-Overheid-Test" ResourceGroupName = "rg-apim-test" ServiceName = "apim-test-dev" Location = "westeurope" Sku = "Developer" HasDiagnosticLogging = $false HasBaselinePolicyProfile = $false HasIpFilteringIndicators = $false HasRateLimitIndicators = $false SecurityPolicyScore = 40 } ) } function Get-ApiManagementSecurityPolicyStatus { <# .SYNOPSIS Haalt API Management-services op en bepaalt of basisbeveiligingsindicatoren aanwezig zijn. .OUTPUTS PSCustomObject met beveiligingspolicy-informatie. #> [CmdletBinding()] param() if ($LocalDebug) { Write-Verbose "Gebruik van gesimuleerde beveiligingspolicydata (LocalDebug)." return Get-DebugSecurityPolicyData } 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 '@ $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 beveiligingsindicatoren voor API Management-service: $serviceName" $hasDiagLogging = $false $hasBaselineProfile = $false $hasIpIndicators = $false $hasRateIndicators = $false try { $diag = Get-AzDiagnosticSetting -ResourceId $service.id -ErrorAction SilentlyContinue if ($diag) { $hasDiagLogging = $true } } catch { Write-Verbose "Kon diagnostische instellingen niet ophalen voor '$serviceName': $_" } $securityScore = 0 if ($hasDiagLogging) { $securityScore += 40 } if ($hasBaselineProfile) { $securityScore += 30 } if ($hasIpIndicators) { $securityScore += 15 } if ($hasRateIndicators) { $securityScore += 15 } $results += [PSCustomObject]@{ SubscriptionId = $subscriptionIdValue SubscriptionName = (Get-AzSubscription -SubscriptionId $subscriptionIdValue -ErrorAction SilentlyContinue).Name ResourceGroupName = $resourceGroup ServiceName = $serviceName Location = $service.location Sku = $service.sku.name HasDiagnosticLogging = $hasDiagLogging HasBaselinePolicyProfile = $hasBaselineProfile HasIpFilteringIndicators = $hasIpIndicators HasRateLimitIndicators = $hasRateIndicators SecurityPolicyScore = $securityScore } } return $results } function Test-SecurityPolicyCompliance { <# .SYNOPSIS Bepaalt de compliancestatus voor basisbeveiligingspolicies rond API Management. .OUTPUTS PSCustomObject met samenvatting van de resultaten. #> [CmdletBinding()] param() $services = Get-ApiManagementSecurityPolicyStatus if (-not $services -or $services.Count -eq 0) { Write-Verbose "Geen API Management-services gevonden in de geselecteerde scope." return [PSCustomObject]@{ ScriptName = "api-management-security-policies" IsCompliant = $true Timestamp = Get-Date Details = "Er zijn geen API Management-services gevonden in de huidige scope." Recommendations = @() Services = @() } } $nonCompliant = $services | Where-Object { $_.SecurityPolicyScore -lt 75 } $isCompliant = ($nonCompliant.Count -eq 0) $details = if ($isCompliant) { "Alle gevonden API Management-services beschikken over basisbeveiligingsindicatoren (diagnostische logging en voorbereid policykader)." } else { "Een of meer API Management-services missen belangrijke beveiligingsindicatoren (diagnostische logging, baseline-policyprofiel, IP- of rate limiting-indicatoren)." } $recommendations = @() if (-not $isCompliant) { $recommendations += "Schakel diagnostische logging in op alle Azure API Management-services en stuur logs naar een centrale Log Analytics-werkruimte of SIEM-oplossing." $recommendations += "Definieer en documenteer een beveiligingsbaseline voor API Management (policyprofielen voor rate limiting, IP-filtering, CORS en headerhardenings) en pas deze toe op alle productie-API’s." $recommendations += "Valideer periodiek of alle kritieke API’s voorzien zijn van passende rate limiting en quota-instellingen." $recommendations += "Beperk toegang tot interne API’s waar mogelijk via IP-filtering en netwerksegmentatie, in lijn met Zero Trust-principes." $recommendations += "Koppel bevindingen uit deze controles aan een formeel verbeterportfolio en changeproces zodat kwetsbaarheden structureel worden opgepakt." } return [PSCustomObject]@{ ScriptName = "api-management-security-policies" IsCompliant = $isCompliant Timestamp = Get-Date Details = $details Recommendations = $recommendations Services = $services } } function Invoke-Monitoring { <# .SYNOPSIS Voert een monitoring-run uit en toont de beveiligingspolicystatus per API Management-service. #> [CmdletBinding()] param() Write-Host "`nMonitoring: $PolicyName" -ForegroundColor Yellow Write-Host "Beschrijving: $PolicyDescription" -ForegroundColor Yellow Write-Host "==============================================================" -ForegroundColor Yellow $result = Test-SecurityPolicyCompliance $services = $result.Services if ($services.Count -gt 0) { Write-Host "`nGevonden API Management-services:" -ForegroundColor Cyan foreach ($service in $services) { $statusColor = if ($service.SecurityPolicyScore -ge 75) { "Green" } else { "Red" } $statusText = "Security Score: $($service.SecurityPolicyScore)% - " + "Diag logging: $(if ($service.HasDiagnosticLogging) { 'Ja' } else { 'Nee' }), " + "Baseline-profiel: $(if ($service.HasBaselinePolicyProfile) { 'Ja' } else { 'Nee' }), " + "IP-indicatoren: $(if ($service.HasIpFilteringIndicators) { 'Ja' } else { 'Nee' }), " + "Rate limit-indicatoren: $(if ($service.HasRateLimitIndicators) { '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 beschikken over basisbeveiligingsindicatoren." -ForegroundColor Green } else { Write-Host "`n❌ NON-COMPLIANT - Eén of meer API Management-services missen essentiële beveiligingsindicatoren." -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 beveiligingspolicies. .DESCRIPTION Voert zelf geen configuratiewijzigingen uit, maar biedt tekstuele aanbevelingen die gebruikt kunnen worden in change- en IaC-processen. #> [CmdletBinding()] param() Write-Host "`nRemediatie: $PolicyName" -ForegroundColor Yellow Write-Host "==============================================================" -ForegroundColor Yellow $result = Test-SecurityPolicyCompliance $services = $result.Services | Where-Object { $_.SecurityPolicyScore -lt 75 } if (-not $services -or $services.Count -eq 0) { Write-Host "Alle API Management-services beschikken over adequate basisbeveiligingsindicatoren. Geen remediatie nodig." -ForegroundColor Green return $result } Write-Host "`nNiet-conforme API Management-services (beveiligingspolicies 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 (" SecurityScore: {0}%" -f $service.SecurityPolicyScore) -ForegroundColor Red Write-Host "" } Write-Host "Aanbevolen vervolgstappen:" -ForegroundColor Yellow foreach ($rec in $result.Recommendations) { Write-Host (" - {0}" -f $rec) -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-security-policies" -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-SecurityPolicyCompliance 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 api-management-security-policies.ps1: $_" throw } finally { Write-Host "`n========================================`n" -ForegroundColor Cyan }

Risico zonder implementatie

Risico zonder implementatie
High: Wanneer beveiligingspolicies in Azure API Management ad hoc of helemaal niet worden ingericht, ontstaat een versnipperd en moeilijk beheersbaar API-landschap. API’s kunnen dan zonder adequate bescherming tegen misbruik, overbelasting en ongeautoriseerde toegang in productie draaien, met een reëel risico op datalekken, verstoringen en negatieve auditbevindingen.

Management Samenvatting

Definieer een organisatiebrede beveiligingsbaseline voor Azure API Management met minimaal rate limiting, IP-filtering, CORS- en headerhardenings en diagnostische logging, en vertaal deze naar herbruikbare policyprofielen. Gebruik het bijbehorende PowerShell-script om periodiek te controleren of API Management-instances aan deze baseline voldoen en stuur verbetermaatregelen via governance- en changeprocessen. Zo wordt API-beveiliging een aantoonbaar geborgd onderdeel van de Nederlandse Baseline voor Veilige Cloud.