BIO 09.01 ISO A.12.2.1

Azure API Management: Rate Limiting Voor Bescherming Tegen Misbruik En Overbelasting

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

💼 Management Samenvatting

Rate limiting vormt een essentiële beveiligingslaag voor API's in Azure API Management, gericht op het voorkomen van misbruik, overbelasting en denial-of-service-aanvallen. Voor Nederlandse overheidsorganisaties is het correct configureren van rate limiting niet alleen een technische maatregel, maar ook een verplichting vanuit BIO-vereisten voor beschikbaarheid en beveiliging van kritieke diensten.

Aanbeveling
IMPLEMENTEER COMPREHENSIEVE RATE LIMITING VOOR ALLE KRITIEKE API'S IN AZURE API MANAGEMENT
Risico zonder
High
Risk Score
8/10
Implementatie
65u (tech: 40u)
Van toepassing op:
✓ Azure
✓ Azure API Management
✓ API Gateway
✓ Microservices
✓ Integratieplatformen

Zonder rate limiting zijn API's kwetsbaar voor verschillende vormen van misbruik en overbelasting. Aanvallers kunnen API-endpoints overspoelen met aanvragen, waardoor legitieme gebruikers worden buitengesloten en de achterliggende systemen worden overbelast. Ook kunnen individuele clients of gecompromitteerde accounts onevenredig veel resources verbruiken, wat leidt tot onbillijke verdeling van capaciteit en mogelijke kostenoverschrijdingen. Daarnaast maken onbeperkte API-aanroepen het moeilijk om misbruik te detecteren; wanneer elke client onbeperkt kan aanroepen, valt een aanvallende client niet op tussen het normale verkeer. Voor overheidsorganisaties kan dit leiden tot uitval van burgerportalen, verstoring van ketenprocessen en onnodige cloudkosten. Bovendien is uit de BIO- en NIS2-vereisten duidelijk dat organisaties passende maatregelen moeten treffen om de beschikbaarheid van kritieke diensten te waarborgen, wat zonder rate limiting niet te realiseren is.

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

Implementatie

Dit artikel beschrijft hoe u rate limiting effectief implementeert in Azure API Management, afgestemd op de specifieke context van Nederlandse overheidsorganisaties. We behandelen de verschillende typen rate limiting die beschikbaar zijn, waaronder subscription-based throttling, key-based throttling en op JWT-claims gebaseerde limitering. Daarnaast bespreken we hoe u rate limits configureert op verschillende niveaus: globaal per API Management-service, per product of API, per subscription of zelfs per individuele client. Verder gaan we in op strategieën voor het bepalen van geschikte limietwaarden, het hanteren van burst-capaciteit, het implementeren van graceful degradation bij overschrijding van limieten en het monitoren van rate limit-gedrag. Het bijbehorende PowerShell-script helpt om de feitelijke rate limit-configuratie te inventariseren, te controleren of minimale beveiligingsstandaarden zijn toegepast en rapportages te genereren voor architecten, beheerders en auditors.

Fundamenten van rate limiting in API-beveiliging

Rate limiting is een beveiligings- en stabiliteitsmechanisme dat het aantal API-aanroepen per tijdseenheid beperkt voor specifieke clients, subscriptions of endpoints. Het principe is gebaseerd op de observatie dat legitieme gebruikers doorgaans een voorspelbaar gebruikspatroon hebben, terwijl misbruik en aanvallen worden gekenmerkt door abnormaal hoge volumes of repetitieve aanvragen. Door limieten te stellen aan het aantal toegestane aanvragen, kunnen organisaties de impact van aanvallen beperken, de beschikbaarheid waarborgen voor legitieme gebruikers en de kosten van cloudinfrastructuur beheersen. In de context van Azure API Management wordt rate limiting gerealiseerd door policies die worden toegepast op inkomende requests, waarbij het platform automatisch bijhoudt hoeveel aanvragen zijn gedaan binnen een bepaalde tijdspanne en aanvragen weigert wanneer de limiet is overschreden.

Er bestaan verschillende typen rate limiting, elk met eigen toepassingsgebieden. Subscription-based throttling beperkt het aantal aanvragen per subscription, waarbij een subscription meestal correspondeert met een abonnement dat is gekoppeld aan een specifieke client of applicatie. Dit is de meest voorkomende vorm van rate limiting in API Management en is geschikt voor het beheer van verschillende clienttypen met verschillende SLA-niveaus. Key-based throttling werkt vergelijkbaar maar is gebaseerd op API-sleutels in plaats van subscriptions, wat handig is voor eenvoudige scenario's of legacy-integraties. Daarnaast biedt Azure API Management de mogelijkheid om rate limiting toe te passen op basis van claims uit JWT-tokens, bijvoorbeeld om verschillende limieten te hanteren voor verschillende rollen of gebruikersgroepen. Dit laatste maakt het mogelijk om binnen een subscription fijnmazige limitering toe te passen op basis van de identiteit van de aanroepende gebruiker.

Voor Nederlandse overheidsorganisaties is rate limiting vooral relevant omdat publieke diensten vaak openbaar toegankelijk moeten zijn, wat ze kwetsbaar maakt voor automatische aanvallen en misbruik. Tegelijkertijd moeten deze diensten betrouwbaar beschikbaar zijn voor burgers en ketenpartners. Door rate limiting strategisch in te zetten, kan een organisatie voorkomen dat een enkele aanvallende client of gecompromitteerd account de volledige dienstverlening lamlegt, terwijl legitieme gebruikers onbelemmerd toegang behouden. Bovendien helpt rate limiting bij het naleven van BIO-vereisten voor beschikbaarheid en continuïteit, omdat het een concrete maatregel is die aantoonbaar bijdraagt aan het voorkomen van denial-of-service-situaties. Het is belangrijk om te beseffen dat rate limiting slechts één onderdeel is van een bredere beveiligingsstrategie; het moet worden gecombineerd met andere maatregelen zoals authenticatie, autorisatie, monitoring en incident response.

Configuratiestrategieën en best practices voor rate limiting

Gebruik PowerShell-script rate-limiting.ps1 (functie Invoke-Monitoring) – Inventariseert de rate limit-configuratie in Azure API Management en controleert of minimale beveiligingsstandaarden zijn toegepast op alle relevante API's en producten..

Het configureren van rate limiting begint met het bepalen van geschikte limietwaarden die balanceren tussen beveiliging en gebruikerservaring. Te strikte limieten frustreren legitieme gebruikers en kunnen leiden tot klachten en verlies van vertrouwen, terwijl te ruime limieten onvoldoende bescherming bieden tegen misbruik. Een veelgebruikte benadering is om te starten met conservatieve limieten op basis van verwacht normaal gebruik, en deze vervolgens aan te passen op basis van monitoring en feedback. Voor publieke API's in overheidscontext wordt vaak gekozen voor limieten zoals honderd aanvragen per minuut per subscription of duizend aanvragen per uur, waarbij hogere limieten worden toegekend aan geverifieerde ketenpartners of beheerders. Belangrijk is om niet alleen te kijken naar het totale aantal aanvragen, maar ook naar burst-capaciteit: hoeveel aanvragen mogen kort na elkaar worden gedaan voordat de limiet wordt afgedwongen. Dit voorkomt dat legitieme gebruikers worden geblokkeerd wanneer zij bijvoorbeeld een bulkoperatie uitvoeren die normaal gesproken verspreid is over meerdere minuten.

Rate limiting moet worden geconfigureerd op het juiste niveau binnen de API Management-hiërarchie. Globale limieten worden toegepast op alle verkeer dat door een API Management-service gaat en zijn nuttig als laatste verdedigingslinie tegen grootschalige aanvallen. Product-level throttling wordt toegepast op alle API's binnen een product en maakt het mogelijk om verschillende service levels te hanteren: bijvoorbeeld hoge limieten voor premium-abonnementen en lagere voor standaard-abonnementen. API-level throttling wordt toegepast op individuele API's en is handig wanneer bepaalde endpoints gevoeliger zijn voor misbruik of meer resources verbruiken. Subscription-level throttling tenslotte wordt toegepast op individuele subscriptions en vormt de basis voor klant-specifieke limitering. In de praktijk wordt vaak een combinatie van meerdere niveaus gebruikt, waarbij elk niveau zijn eigen limiet heeft en de meest restrictieve limiet wordt toegepast. Deze gelaagde aanpak zorgt ervoor dat bescherming op meerdere niveaus werkt en dat een enkele zwakke schakel niet direct leidt tot onvoldoende beveiliging.

Naast het instellen van limieten is het belangrijk om na te denken over de respons die wordt gegeven wanneer een limiet wordt overschreden. Standaard retourneert Azure API Management een HTTP 429 Too Many Requests statuscode wanneer een rate limit wordt overschreden, wat de juiste respons is volgens HTTP-standaarden. Het is echter aan te raden om deze respons te verrijken met bruikbare informatie, zoals een indicatie van wanneer de limiet opnieuw beschikbaar komt of een Retry-After header die aangeeft hoeveel seconden de client moet wachten voordat een nieuwe poging wordt gedaan. Dit verbetert de gebruikerservaring en helpt client-ontwikkelaars om hun applicaties robuuster te maken. Daarnaast is het raadzaam om overschrijdingen van rate limits te loggen en te monitoren, omdat herhaalde overschrijdingen kunnen wijzen op misbruik, foutieve client-implementaties of een verkeerd ingeschatte behoefte aan hogere limieten. Door deze informatie te analyseren, kunnen organisaties hun rate limiting-strategie continu verbeteren en vroegtijdig problemen detecteren.

Geavanceerde scenario's en aanpassingen aan specifieke use cases

Binnen Nederlandse overheidsorganisaties bestaan verschillende typen API's en gebruiksscenario's die elk hun eigen rate limiting-behoeften hebben. Publieke burgerportalen moeten bijvoorbeeld beschermd zijn tegen grootschalige scraping en automated attacks, terwijl zij tegelijkertijd voldoende capaciteit moeten bieden voor piekmomenten zoals de aanvraagperiode voor uitkeringen of belastingaangiften. Voor deze scenario's is het belangrijk om rate limits dynamisch aan te passen op basis van de context: tijdens normale periodes kunnen strikte limieten worden gehanteerd, terwijl tijdens bekende piekmomenten de limieten tijdelijk kunnen worden verhoogd. Azure API Management biedt hiervoor mogelijkheden via policies en externe configuratie, hoewel volledig geautomatiseerde aanpassing op basis van voorspelbare patronen vaak nog handmatige interventie vereist of aanvullende automatisering.

Voor ketenintegraties tussen overheidsorganisaties gelden andere overwegingen. Deze API's worden doorgaans gebruikt door een beperkt aantal bekende partners en hebben vaak specifieke SLA's en capaciteitsafspraken. Rate limiting voor keten-API's moet daarom niet alleen gericht zijn op het voorkomen van misbruik, maar ook op het waarborgen van fair use en het naleven van afgesproken volumes. In deze context is het zinvol om per partner of per applicatie specifieke limieten te configureren, eventueel op basis van contractuele afspraken. Bovendien moet worden overwogen om voor kritieke ketenprocessen een whitelist-mechanisme te implementeren, waarbij bepaalde partners of applicaties hogere of zelfs onbeperkte limieten krijgen, terwijl andere clients worden beperkt. Dit vereist zorgvuldige afweging van beveiliging versus functionaliteit en moet worden vastgelegd in governanceafspraken en documentatie.

Interne API's die gebruikt worden door ontwikkelteams en beheerapplicaties hebben weer andere eisen. Hoewel deze API's minder kwetsbaar zijn voor externe aanvallen, kunnen zij nog steeds last hebben van misconfiguraties, foutieve scripts of onbeperkte retry-logica in clientapplicaties. Rate limiting voor interne API's is daarom vooral gericht op het voorkomen van accidentele overbelasting en het beschermen van gedeelde resources. Vaak worden voor interne API's hogere limieten gehanteerd dan voor publieke API's, maar nog steeds met redelijke bovengrenzen om te voorkomen dat een enkele misconfiguratie de volledige omgeving beïnvloedt. Daarnaast is het voor interne API's vaak nuttig om rate limiting te combineren met quota management, waarbij niet alleen het aantal aanvragen per tijdseenheid wordt beperkt, maar ook het totaal aantal aanvragen per dag of maand. Dit helpt bij het beheersen van cloudkosten en het identificeren van inefficiënte of misbruikende applicaties.

Monitoring, analyse en continue optimalisatie van rate limiting

Gebruik PowerShell-script rate-limiting.ps1 (functie Invoke-Remediation) – Genereert een overzicht van API Management-services met ontbrekende of onvoldoende rate limiting-configuratie en doet aanbevelingen voor verbetering..

Het configureren van rate limiting is geen eenmalige activiteit, maar vereist continue monitoring en aanpassing op basis van werkelijke gebruikspatronen en incidenten. Azure API Management biedt uitgebreide logging en metrics die inzicht geven in het rate limiting-gedrag, waaronder het aantal aanvragen dat wordt toegestaan, het aantal dat wordt geblokkeerd wegens overschrijding van limieten, en gedetailleerde informatie over welke clients of subscriptions de limieten het meest benaderen of overschrijden. Deze informatie moet regelmatig worden geanalyseerd om trends te identificeren, zoals groeiende gebruikspatronen die wijzen op de noodzaak om limieten aan te passen, of herhaalde overschrijdingen door specifieke clients die mogelijk wijzen op misbruik of foutieve implementaties. Door deze analyses te koppelen aan incident response-processen, kunnen organisaties snel reageren op nieuwe dreigingen of gebruikspatronen en hun rate limiting-strategie proactief aanpassen.

Het PowerShell-script dat bij dit artikel hoort, kan worden ingezet als geautomatiseerde controle om periodiek te verifiëren of alle relevante API's en producten rate limiting hebben geconfigureerd en of deze configuratie voldoet aan minimale beveiligingsstandaarden. Het script kan bijvoorbeeld controleren of er geen API's zijn zonder rate limiting in productie, of alle publieke API's minimaal een bepaalde basislimiet hebben, en of de configuratie consistent is tussen verschillende omgevingen. De output van het script kan worden gekoppeld aan compliance-dashboards of risicoregisters, zodat afwijkingen snel zichtbaar worden en kunnen worden opgepakt. Voor Nederlandse overheidsorganisaties is dit vooral waardevol omdat het helpt om aan te tonen dat rate limiting niet alleen is geconfigureerd, maar ook structureel wordt bewaakt en onderhouden, wat belangrijk is voor audits en toezicht door de Autoriteit Persoonsgegevens, de NCTV of andere relevante toezichthouders.

Naast het monitoren van de technische configuratie is het belangrijk om regelmatig de effectiviteit van rate limiting te evalueren. Dit betekent niet alleen kijken naar metrics, maar ook naar incidenten: zijn er denial-of-service-situaties geweest die rate limiting niet heeft kunnen voorkomen, zijn er klachten van legitieme gebruikers over onterechte blokkades, en zijn er nieuwe aanvalstactieken geïdentificeerd waartegen bestaande rate limiting onvoldoende bescherming biedt. Door deze evaluaties structureel uit te voeren, bijvoorbeeld als onderdeel van periodieke security reviews of na significante incidenten, kunnen organisaties hun rate limiting-strategie continu verbeteren en ervoor zorgen dat deze effectief blijft in een veranderende dreigingsomgeving. Daarnaast is het waardevol om rate limiting te koppelen aan bredere security monitoring en threat intelligence, zodat nieuwe aanvalstactieken snel kunnen worden herkend en mitigeerbaar gemaakt via aanpassingen aan rate limiting-configuraties.

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 de rate limiting-configuratie van Azure API Management-services. .DESCRIPTION Dit script inventariseert Azure API Management-services en controleert of rate limiting correct is geconfigureerd conform de uitgangspunten van de Nederlandse Baseline voor Veilige Cloud. In monitoringmodus wordt een samenvatting weergegeven; in remediatiemodus worden gerichte aanbevelingen gegeven. .NOTES Filename: rate-limiting.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/rate-limiting.json .LINK https://github.com/[org]/m365-tenant-best-practise .EXAMPLE .\rate-limiting.ps1 -Monitoring Voert een controle uit op alle toegankelijke abonnementen en toont de rate limiting-status per API Management-service. .EXAMPLE .\rate-limiting.ps1 -Remediation Genereert een overzicht van API Management-services zonder of met onvoldoende rate limiting-configuratie en aanbevelingen voor herstel. .EXAMPLE .\rate-limiting.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 rate limiting correct geconfigureerd" $PolicyDescription = "Controleert of Azure API Management-services zijn voorzien van adequate rate limiting-configuratie om misbruik, overbelasting en denial-of-service-aanvallen te voorkomen." 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') 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-DebugRateLimitingData { [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" HasGlobalRateLimiting = $true HasProductLevelLimiting = $true HasApiLevelLimiting = $false HasSubscriptionLevelLimiting = $true MinRateLimitConfigured = 100 RateLimitComplianceScore = 85 }, [PSCustomObject]@{ SubscriptionId = "00000000-0000-0000-0000-000000000020" SubscriptionName = "DBG-Overheid-Prod" ResourceGroupName = "rg-apim-prod" ServiceName = "apim-prod-01" Location = "westeurope" Sku = "Premium" HasGlobalRateLimiting = $true HasProductLevelLimiting = $true HasApiLevelLimiting = $true HasSubscriptionLevelLimiting = $true MinRateLimitConfigured = 50 RateLimitComplianceScore = 100 }, [PSCustomObject]@{ SubscriptionId = "00000000-0000-0000-0000-000000000030" SubscriptionName = "DBG-Overheid-Test" ResourceGroupName = "rg-apim-test" ServiceName = "apim-test-legacy" Location = "westeurope" Sku = "Developer" HasGlobalRateLimiting = $false HasProductLevelLimiting = $false HasApiLevelLimiting = $false HasSubscriptionLevelLimiting = $false MinRateLimitConfigured = 0 RateLimitComplianceScore = 0 } ) } function Get-ApiManagementRateLimitingStatus { <# .SYNOPSIS Haalt API Management-services op en bepaalt of rate limiting is geconfigureerd. .OUTPUTS PSCustomObject met rate limiting-configuratiestatus. #> [CmdletBinding()] param() if ($LocalDebug) { Write-Verbose "Gebruik van gesimuleerde rate limiting-configuratiedata (LocalDebug)." return Get-DebugRateLimitingData } 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 rate limiting-configuratie voor API Management-service: $serviceName" try { $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 } # In een volledige implementatie zouden hier de daadwerkelijke policies worden opgehaald via de API Management REST API. # Voor deze referentie-implementatie gebruiken we pragmatische indicatoren. $hasGlobalRateLimiting = $false $hasProductLevelLimiting = $false $hasApiLevelLimiting = $false $hasSubscriptionLevelLimiting = $false $minRateLimitConfigured = 0 # Placeholder-logica: in een echte omgeving zou je hier management API-calls gebruiken om policies uit te lezen # en te analyseren op rate limiting-configuraties. Deze implementatie biedt een veilig uitgangspunt zonder wijzigingen door te voeren. $rateLimitScore = 0 if ($hasGlobalRateLimiting) { $rateLimitScore += 25 } if ($hasProductLevelLimiting) { $rateLimitScore += 25 } if ($hasApiLevelLimiting) { $rateLimitScore += 25 } if ($hasSubscriptionLevelLimiting) { $rateLimitScore += 25 } $results += [PSCustomObject]@{ SubscriptionId = $subscriptionIdValue SubscriptionName = (Get-AzSubscription -SubscriptionId $subscriptionIdValue -ErrorAction SilentlyContinue).Name ResourceGroupName = $resourceGroup ServiceName = $serviceName Location = $service.location Sku = $service.sku.name HasGlobalRateLimiting = $hasGlobalRateLimiting HasProductLevelLimiting = $hasProductLevelLimiting HasApiLevelLimiting = $hasApiLevelLimiting HasSubscriptionLevelLimiting = $hasSubscriptionLevelLimiting MinRateLimitConfigured = $minRateLimitConfigured RateLimitComplianceScore = $rateLimitScore } } catch { Write-Warning "Fout bij controleren van rate limiting-configuratie voor '$serviceName': $_" } } return $results } function Test-RateLimitingCompliance { <# .SYNOPSIS Bepaalt de compliancestatus voor rate limiting-configuratie in API Management. .OUTPUTS PSCustomObject met samenvatting van resultaten. #> [CmdletBinding()] param() $services = Get-ApiManagementRateLimitingStatus if (-not $services -or $services.Count -eq 0) { Write-Verbose "Geen API Management-services gevonden in de geselecteerde scope." return [PSCustomObject]@{ ScriptName = "rate-limiting" IsCompliant = $true Timestamp = Get-Date Details = "Er zijn geen API Management-services gevonden in de huidige scope." Recommendations = @() Services = @() } } $nonCompliant = $services | Where-Object { $_.RateLimitComplianceScore -lt 75 } $isCompliant = ($nonCompliant.Count -eq 0) $details = if ($isCompliant) { "Alle gevonden API Management-services hebben rate limiting geconfigureerd op meerdere niveaus." } else { "Een of meer API Management-services missen adequate rate limiting-configuratie op één of meer niveaus." } $recommendations = @() if (-not $isCompliant) { $recommendations += "Configureer rate limiting op minimaal drie niveaus: globaal, product-niveau en subscription-niveau." $recommendations += "Zorg ervoor dat alle publieke API's minimaal een basislimiet hebben van bijvoorbeeld 100 aanvragen per minuut per subscription." $recommendations += "Implementeer burst-capaciteit om kortdurende pieken te accommoderen zonder legitieme gebruikers te blokkeren." $recommendations += "Monitor rate limiting-gedrag regelmatig en pas limieten aan op basis van werkelijke gebruikspatronen." $recommendations += "Documenteer de gehanteerde rate limit-waarden en de motivatie daarvoor in architectuur- en beveiligingsdocumentatie." } return [PSCustomObject]@{ ScriptName = "rate-limiting" IsCompliant = $isCompliant Timestamp = Get-Date Details = $details Recommendations = $recommendations Services = $services } } function Invoke-Monitoring { <# .SYNOPSIS Voert een monitoring-run uit en toont de rate limiting-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-RateLimitingCompliance $services = $result.Services if ($services.Count -gt 0) { Write-Host "`nGevonden API Management-services:" -ForegroundColor Cyan foreach ($service in $services) { $statusColor = if ($service.RateLimitComplianceScore -ge 75) { "Green" } else { "Red" } $statusText = "Rate Limit Score: $($service.RateLimitComplianceScore)% - " + "Globaal: $(if ($service.HasGlobalRateLimiting) { 'Ja' } else { 'Nee' }), " + "Product: $(if ($service.HasProductLevelLimiting) { 'Ja' } else { 'Nee' }), " + "API: $(if ($service.HasApiLevelLimiting) { 'Ja' } else { 'Nee' }), " + "Subscription: $(if ($service.HasSubscriptionLevelLimiting) { '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 adequate rate limiting-configuratie." -ForegroundColor Green } else { Write-Host "`n❌ NON-COMPLIANT - Eén of meer API Management-services missen adequate rate limiting-configuratie." -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 rate limiting-configuratie. #> [CmdletBinding()] param() Write-Host "`nRemediatie: $PolicyName" -ForegroundColor Yellow Write-Host "==============================================================" -ForegroundColor Yellow $result = Test-RateLimitingCompliance $services = $result.Services | Where-Object { $_.RateLimitComplianceScore -lt 75 } if (-not $services -or $services.Count -eq 0) { Write-Host "Alle API Management-services beschikken over adequate rate limiting-configuratie. Geen remediatie nodig." -ForegroundColor Green return $result } Write-Host "`nNiet-conforme API Management-services (rate limiting-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 (" Rate Limit Score: {0}%" -f $service.RateLimitComplianceScore) -ForegroundColor Red Write-Host "" } Write-Host "Aanbevolen vervolgstappen:" -ForegroundColor Yellow Write-Host "1. Configureer rate limiting op globaal niveau voor alle verkeer door de API Management-service." -ForegroundColor Yellow Write-Host "2. Voeg product-level rate limiting toe voor alle API-producten, met verschillende limieten voor premium en standaard-abonnementen." -ForegroundColor Yellow Write-Host "3. Implementeer API-level rate limiting voor individuele API's die gevoelig zijn voor misbruik of veel resources verbruiken." -ForegroundColor Yellow Write-Host "4. Zorg voor subscription-level rate limiting om individuele clients of applicaties te beperken." -ForegroundColor Yellow Write-Host "5. Stel geschikte limietwaarden in die balanceren tussen beveiliging en gebruikerservaring, bijvoorbeeld 100 aanvragen per minuut per subscription voor publieke API's." -ForegroundColor Yellow Write-Host "6. Implementeer burst-capaciteit om kortdurende pieken te accommoderen zonder legitieme gebruikers te blokkeren." -ForegroundColor Yellow Write-Host "7. Monitor rate limiting-gedrag regelmatig en pas limieten aan op basis van werkelijke gebruikspatronen en incidenten." -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: rate-limiting" -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-RateLimitingCompliance 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 rate-limiting.ps1: $_" throw } finally { Write-Host "`n========================================`n" -ForegroundColor Cyan }

Risico zonder implementatie

Risico zonder implementatie
High: Zonder adequate rate limiting blijven API's kwetsbaar voor denial-of-service-aanvallen, misbruik en overbelasting, wat kan leiden tot uitval van publieke diensten, verstoring van ketenprocessen en onnodige cloudkosten. Bovendien voldoen organisaties dan niet aan BIO- en NIS2-vereisten voor beschikbaarheid en beveiliging van kritieke systemen.

Management Samenvatting

Configureer rate limiting op meerdere niveaus binnen Azure API Management voor alle kritieke API's, met geschikte limieten die balanceren tussen beveiliging en gebruikerservaring. Monitor rate limiting-gedrag regelmatig en pas configuraties aan op basis van werkelijke gebruikspatronen en incidenten. Gebruik het bijbehorende PowerShell-script om periodiek te controleren of rate limiting correct is geconfigureerd en voldoet aan minimale beveiligingsstandaarden.