BIO 12.04 ISO A.12.4.1

API Management Logging: Uitgebreide Logging Voor API-verkeer En Beveiligingsmonitoring

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

💼 Management Samenvatting

Azure API Management logging vormt de fundamentele basis voor het monitoren, analyseren en beveiligen van API-verkeer binnen moderne cloudarchitecturen. Zonder uitgebreide logging beschikken organisaties niet over de benodigde zichtbaarheid om API-aanvallen te detecteren, prestatieproblemen te identificeren, compliance-vereisten na te komen en forensisch onderzoek uit te voeren naar beveiligingsincidenten die de integriteit, beschikbaarheid en vertrouwelijkheid van API-services kunnen schaden.

Aanbeveling
Richt diagnostische logging in voor alle Azure API Management-services en zorg dat GatewayLogs en WebApplicationFirewallLogs worden verzameld in Log Analytics-workspaces met minimaal 6–24 maanden retentie.
Risico zonder
High
Risk Score
8/10
Implementatie
9u (tech: 6u)
Van toepassing op:
✓ Azure

Azure API Management fungeert als de centrale gateway voor API-verkeer binnen veel Nederlandse overheidsorganisaties, waarbij kritieke diensten zoals burgerportalen, basisregistraties en digitale overheidsdiensten worden blootgesteld via REST- en GraphQL-API's. Zonder uitgebreide logging ontbreekt cruciale zichtbaarheid in wie welke API's aanroept, welke data wordt uitgewisseld, welke fouten optreden en welke beveiligingsgebeurtenissen plaatsvinden. Deze blinde vlek maakt het onmogelijk om API-aanvallen zoals brute force-aanvallen op authenticatie-endpoints, injection-aanvallen waarbij kwaadaardige payloads worden geïnjecteerd in API-verzoeken, denial-of-service-aanvallen waarbij API's worden overbelast met verzoeken, en misbruik van API-sleutels of OAuth-tokens te detecteren en te onderzoeken. Bovendien kunnen organisaties zonder logging niet voldoen aan compliance-vereisten zoals vastgelegd in de AVG, NIS2 richtlijn en de Baseline Informatiebeveiliging Overheid, die allemaal vereisen dat organisaties kunnen aantonen dat zij passende maatregelen hebben genomen om API-verkeer te monitoren en te loggen. Het ontbreken van adequate API-logging kan leiden tot niet-naleving van deze vereisten, wat kan resulteren in boetes, reputatieschade en juridische aansprakelijkheid. Voor organisaties in de publieke sector is API-logging bovendien essentieel voor het waarborgen van transparantie en verantwoording, waarbij bestuurders moeten kunnen aantonen dat zij passende controles hebben geïmplementeerd om de beveiliging van API-services te waarborgen.

PowerShell Modules Vereist
Primary API: Azure Monitor / API Management
Connection: Connect-AzAccount
Required Modules: Az.Accounts, Az.ApiManagement, Az.Monitor

Implementatie

Deze maatregel beschrijft hoe je diagnostische logging inricht voor Azure API Management-services, met specifieke aandacht voor GatewayLogs die alle API-verzoeken en -antwoorden vastleggen, WebApplicationFirewallLogs die beveiligingsgebeurtenissen registreren, en ApplicationInsights-integratie voor real-time monitoring en analyse. We behandelen hoe je diagnostic settings configureert voor alle API Management-services, welke logcategorieën moeten worden ingeschakeld, hoe je logs naar Log Analytics-workspaces stuurt voor centrale analyse, en hoe je bewaarbeleid afstemt op Nederlandse wet- en regelgeving. Vervolgens laten we zien hoe je de kwaliteit van de aangeleverde logs bewaakt, hoe je test of API-verkeer daadwerkelijk wordt gelogd, en hoe je rapportages opzet die aantonen dat de loggingdekking op orde is. Het bijbehorende PowerShell-script api-management-logging.ps1 voert gerichte controles uit op de aanwezigheid van diagnostic settings voor API Management-services en levert een samenvattend beeld van de mate waarin API-logging daadwerkelijk is geactiveerd.

Vereisten

Een robuuste inrichting van API Management logging start met een heldere scopebepaling: welke API Management-services vallen onder de verantwoordelijkheid van de organisatie en moeten daarom hun API-verkeer en beveiligingsgebeurtenissen centraal loggen? Voor een ministerie of grote uitvoeringsorganisatie betekent dit doorgaans alle productie- en preproductie-services, inclusief gedeelde API-gateways die worden gebruikt door meerdere afdelingen of applicaties. Zonder deze afbakening ontstaan ongedocumenteerde API-services waarin cruciale telemetrie ontbreekt. De eerste voorwaarde is daarom dat er een geautoriseerde lijst bestaat van alle relevante API Management-services, gekoppeld aan eigenaarschap, classificatie (bijvoorbeeld BBN2/BBN3) en Business Impact Analysis-resultaten. Deze lijst vormt de basis voor het bepalen welke services minimaal moeten worden aangesloten op Log Analytics.

Vervolgens zijn er technische randvoorwaarden aan de Log Analytics-workspaces zelf. Er moeten één of enkele centrale workspaces bestaan die expliciet zijn aangewezen als API-log-hub, met een bewaartermijn die past bij de wettelijke en interne eisen – vaak minimaal 180 dagen voor operationele analyse en tussen 365 en 730 dagen voor audit en forensisch onderzoek. De workspaces worden beschermd met role-based access control zodat alleen SOC-analisten, API-beheerders en geautoriseerde auditors query-rechten hebben. Daarnaast moeten network access-beperkingen zijn ingeschakeld, bijvoorbeeld via private endpoints en IP-allowlists, om te voorkomen dat gevoelige API-logdata zomaar vanaf het internet kan worden benaderd. Zonder deze basisconfiguratie kan de organisatie niet geloofwaardig stellen dat API-logs adequaat zijn beschermd.

Cruciaal is ook dat alle API Management-services daadwerkelijk naar Log Analytics schrijven. Dit omvat ten minste GatewayLogs die alle inkomende API-verzoeken en uitgaande antwoorden vastleggen, inclusief HTTP-headers, request- en response-bodies, statuscodes en timing-informatie. WebApplicationFirewallLogs registreren beveiligingsgebeurtenissen zoals geblokkeerde verzoeken, SQL-injectie-pogingen, cross-site scripting-aanvallen en andere OWASP Top 10-bedreigingen. Daarnaast kunnen ApplicationInsights-logs worden geconfigureerd voor real-time monitoring en prestatie-analyse. Voor elke API Management-service moet zijn vastgelegd welke logcategorieën naar welke workspace worden gestuurd. Deze mapping wordt vastgelegd in een datagovernanceregister zodat duidelijk is welke API-bedreigingsscenario's worden afgedekt en waar mogelijke blinde vlekken zitten. Een API Management-omgeving zonder deze expliciete loggingconfiguratie is in de praktijk zelden compleet.

Naast technische inrichting spelen rechten en capaciteit een rol. Analisten hebben toegang nodig tot Kusto Query Language (KQL) en moeten getraind zijn in het schrijven van queries die over API-logs zoeken naar patronen zoals verdachte verkeerspatronen, misbruik van API-sleutels, of ongebruikelijke data-uitwisseling. De organisatie moet tooling beschikbaar stellen om query's te delen en te versiebeheren – bijvoorbeeld via Git-repositories gekoppeld aan workbooks of notebooks – zodat kennis niet in persoonlijke profielen verdwijnt. Verder moeten afspraken bestaan over wie queries mag aanpassen die als bron dienen voor usecases in Sentinel, dashboards of managementrapportages. Deze governance voorkomt dat kritieke queries onbewust worden gewijzigd en dat de kwaliteit van API-detecties over tijd verwatert.

Tot slot is integratie met overige monitoringoplossingen een expliciete voorwaarde. In veel omgevingen fungeert Log Analytics als datalaag onder Microsoft Sentinel, Defender for Cloud, Azure Monitor en soms ook externe oplossingen zoals Splunk of QRadar. De inrichting van API-logs moet daarom rekening houden met downstream-gebruik: retentie in Log Analytics mag niet korter zijn dan de forensische bewaarbehoefte uit het incident response-plan, en export- of replicatiemechanismen naar andere SIEM's moeten worden gedocumenteerd en regelmatig getest. Zonder deze afstemming dreigt versnippering van data, dubbele opslagkosten en – belangrijker – inconsistentie tussen de cijfers die in audits of aan bestuurders worden gepresenteerd.

Implementatie

De implementatie van API Management logging verloopt idealiter in iteratieve stappen, beginnend met een kleinschalige pilot en eindigend in een volledig uitgerolde multi-service-architectuur. In de eerste fase wordt een of enkele Log Analytics-workspaces aangewezen als API-log-hub en worden bestaande API Management-services in kaart gebracht. Met Azure Resource Graph en de Azure Portal wordt vastgesteld welke diagnostic settings al bestaan, naar welke bestemmingen zij schrijven (Storage, Event Hub, Log Analytics) en welke logcategorieën daarin zijn opgenomen. Op basis van deze nulmeting wordt bepaald welke services direct kunnen worden aangesloten en waar aanvullende configuratie nodig is. In dezelfde fase worden naming conventions vastgelegd voor workspaces, resourcegroepen en diagnostic settings zodat later duidelijk blijft welke configuraties tot het API-loggingdomein behoren.

Daarna volgt het systematisch inschakelen van diagnostic settings voor alle API Management-services. Per service wordt een diagnostic setting geconfigureerd die GatewayLogs en WebApplicationFirewallLogs naar de security-workspace stuurt. GatewayLogs bevatten alle inkomende API-verzoeken en uitgaande antwoorden, inclusief HTTP-methoden, URL-paden, statuscodes, response-tijden, client-IP-adressen en gebruikersidentiteiten. WebApplicationFirewallLogs registreren beveiligingsgebeurtenissen zoals geblokkeerde verzoeken, detectie van kwaadaardige payloads en firewall-regelmatches. Tijdens deze uitrol wordt per wijziging gecontroleerd of de nieuwe datastroom daadwerkelijk resulteert in records in de beoogde tabellen, bijvoorbeeld door in de workspace te zoeken naar recente entries in ApiManagementGatewayLogs of ApiManagementWebApplicationFirewallLogs.

Gebruik PowerShell-script api-management-logging.ps1 (functie Invoke-Implementation) – Implementeren en controleren van API Management logging configuratie.

Het PowerShell-script api-management-logging.ps1 ondersteunt deze implementatie door per API Management-service te controleren of diagnostic settings daadwerkelijk zijn geconfigureerd en of logs worden gegenereerd. Het script maakt verbinding met Azure via Connect-AzAccount, haalt alle API Management-services op en controleert of diagnostic settings bestaan die GatewayLogs en WebApplicationFirewallLogs naar Log Analytics sturen. Services zonder diagnostic settings of zonder de juiste logcategorieën worden als risicovol gemarkeerd omdat daar kennelijk geen API-logging op is aangesloten. De uitvoer bevat zowel een totaalscore per tenant als een overzicht per service, waardoor teams gericht acties kunnen uitzetten naar de eigenaar van de betreffende API-gateway. Het script kan herhaaldelijk worden gedraaid nadat nieuwe diagnostic settings zijn toegevoegd om te verifiëren dat de verwachte gebeurtenissen inderdaad aankomen.

Wanneer de basis staat, verschuift de aandacht naar normalisatie en tagging. Log Analytics biedt mogelijkheden om via ingestie-time transform rules en custom fields metadata toe te voegen, bijvoorbeeld de classificatie van een API, de verantwoordelijke afdeling of het bijbehorende proces uit de BIA. Door deze context aan API-logs te koppelen, kunnen SOC-analisten sneller prioriteren en wordt het eenvoudiger om rapportages te maken die aansluiten op bestuurlijke dashboards. In deze fase wordt ook bepaald welke tabellen structureel worden gebruikt voor usecases in Sentinel of andere SIEM's, zodat retentie en prestatie-optimalisaties zich concentreren op de belangrijkste datastromen.

De laatste implementatiestap omvat automatisering en kwaliteitsborging. Met behulp van Azure Policy, ARM/Bicep-sjablonen of Terraform wordt vastgelegd dat nieuwe API Management-services automatisch de juiste diagnostic settings krijgen. Daarnaast worden periodieke scripts of workbooks ingericht die controleren of er geen nieuwe services zijn ontstaan zonder logging, of dat er geen services zijn waarin API-logs stilgevallen zijn. Deze controles worden opgenomen in de reguliere change- en releasekalender, zodat wijzigingen in architectuur of tooling niet ongemerkt leiden tot gaten in de loggingdekking. Door implementatie en borging op deze manier te combineren groeit API Management logging uit tot een stabiele pijler onder het security operating model.

Compliance en Auditing

Vanuit complianceperspectief vervult API Management logging een dubbele rol: enerzijds als technische voorziening om API-aanvallen tijdig te detecteren en te onderzoeken, anderzijds als bron van bewijs dat de organisatie structureel voldoet aan gestelde normen. De Baseline Informatiebeveiliging Overheid (BIO) schrijft in hoofdstukken over logging en monitoring voor dat beveiligingsrelevante gebeurtenissen moeten worden vastgelegd, geanalyseerd en gekoppeld aan opvolgacties. Door API-logs gecentraliseerd in Log Analytics beschikbaar te hebben, kan eenvoudig worden aangetoond welke API-verzoeken worden verzameld, over welke periode, met welke toegangsbeperkingen en welke dashboards en usecases daarop draaien. Tijdens ENSIA- en interne audits kunnen query-uitdraaien, retentieconfiguraties en toegangsrechten rechtstreeks uit de workspace worden geëxporteerd als evidence.

Ook de AVG en NIS2 stellen impliciete en expliciete eisen aan API-logging. AVG Artikel 32 verlangt passende technische en organisatorische maatregelen om onder meer de vertrouwelijkheid, integriteit en beschikbaarheid van persoonsgegevens te waarborgen. Zonder goede API-logdata is het vrijwel onmogelijk om na een datalek vast te stellen welke gegevens precies zijn uitgewisseld via API's, wat de beoordeling van meldplicht en impact enorm bemoeilijkt. NIS2 en de Wet beveiliging netwerk- en informatiesystemen vragen bovendien om aantoonbaar en proportioneel incidentmanagement, inclusief forensische mogelijkheden. Een Log Analytics-omgeving waarin API-logs, beveiligingsgebeurtenissen en prestatiemetrics over meerdere jaren beschikbaar zijn, vormt de basis om deze verplichtingen na te komen en om in rapportages richting toezichthouders overtuigend te laten zien wat er is gebeurd en hoe snel daarop is gereageerd.

Voor sectorale kaders, zoals de DigiD-beveiligingsrichtlijnen, de richtlijnen van het Nationaal Cyber Security Centrum (NCSC) of aanvullende eisen van toezichthouders in de gezondheidszorg en financiële sector, geldt eveneens dat logging en monitoring centraal staan. Log Analytics maakt het mogelijk om maatwerkrapporten te definiëren waarin bijvoorbeeld alle toegangspogingen tot hooggeclassificeerde API's, misbruik van API-sleutels of policy-overtredingen in één overzicht worden samengebracht. Deze rapporten kunnen periodiek worden geëxporteerd en ondertekend, waardoor zij direct als auditstuk kunnen worden opgenomen in dossiers. Belangrijk is wel dat de queries en workbooks die hiervoor worden gebruikt onder versiebeheer staan, zodat auditteams kunnen controleren dat de gebruikte logica consistent is en dat resultaten herhaalbaar zijn.

Transparantie en dataminimalisatie blijven randvoorwaarden, ook bij API-logging. Organisaties moeten onderbouwen waarom bepaalde persoonsgegevens – zoals IP-adressen, gebruikersnamen of API-sleutels – in logs worden vastgelegd en hoe lang zij worden bewaard. Log Analytics ondersteunt deze verantwoording doordat retentie-instellingen per tabel kunnen worden vastgelegd en omdat exportstromen naar andere systemen zichtbaar zijn. Door deze configuraties te documenteren in het verwerkingsregister en in dataprotectie-effectbeoordelingen (DPIA's), kan worden aangetoond dat logging proportioneel en doelgebonden is ingericht. Hiermee worden technische maatregelen direct gekoppeld aan juridische en organisatorische kaders, wat essentieel is binnen de Nederlandse Baseline voor Veilige Cloud.

Monitoring en Kwaliteitsbewaking

Zodra API Management logging in gebruik is, verschuift de focus naar de kwaliteit en continuïteit van de datastromen. Monitoring richt zich dan niet alleen op wat er met API's gebeurt, maar ook op de vraag of logs zelf nog volledig en betrouwbaar zijn. Dit betekent dat er dashboards nodig zijn die het volume aan binnenkomende API-verzoeken per service en per endpoint visualiseren, met duidelijke drempelwaarden voor afwijkingen. Een plotselinge daling van het aantal entries in ApiManagementGatewayLogs kan wijzen op een fout in diagnostic settings, een uitgevallen API Management-service of een onbedoelde wijziging in netwerkconfiguratie. Het tijdig herkennen van dit soort afwijkingen voorkomt dat het SOC wekenlang werkt met een onzichtbare blinde vlek.

Gebruik PowerShell-script api-management-logging.ps1 (functie Invoke-Monitoring) – Controleren of API Management logging daadwerkelijk is geconfigureerd en actief.

Het PowerShell-script api-management-logging.ps1 ondersteunt deze kwaliteitsbewaking door per API Management-service te controleren of diagnostic settings bestaan en of logs daadwerkelijk worden gegenereerd. De uitvoer geeft een overzicht van het aantal services, hoeveel daarvan logging hebben geconfigureerd en in welke services deze ontbreekt. Deze informatie kan worden gebruikt als input voor periodieke rapportages richting het Cloud Competence Center of het Security Operations Center. Door het script bijvoorbeeld dagelijks of wekelijks via Azure Automation uit te voeren en de resultaten in Log Analytics terug te schrijven, ontstaat bovendien een historisch beeld van de loggingdekking, wat weer input levert voor trendanalyses en maturity-assessments.

Naast het meten van datavolume is het belangrijk om de prestaties van query's te monitoren. Complexe KQL-query's die regelmatig time-outs veroorzaken of veel resources verbruiken, kunnen dashboards en usecases vertragen en zo de effectiviteit van het SOC verminderen. Door queryduur, resource consumption en foutpercentages op te nemen in monitoringdashboards, kunnen teams gericht optimaliseren: tabellen partitioneren, indexen gebruiken, query's herschrijven of data-aggregaties toepassen. Deze optimalisaties zijn extra relevant in omgevingen waar Log Analytics ook fungeert als datalaag voor Sentinel, omdat performance-impact daar direct invloed heeft op detectiesnelheid.

Tot slot maakt monitoring ook de menselijke factor zichtbaar. Door KPI's vast te leggen zoals het aantal uitgevoerde API-huntsessies per maand, het aantal verbeterde queries of het percentage incidenten waarin API-logs daadwerkelijk zijn geraadpleegd, ontstaat een beeld van hoe volwassen het gebruik van API-logs in de praktijk is. Deze cijfers kunnen worden meegenomen in managementrapportages en opleidingsplannen, zodat duidelijk wordt waar extra training, tooling of capaciteit nodig is. Zo wordt API Management logging geen eenmalig technisch project, maar een doorlopend verbeterprogramma dat bijdraagt aan de weerbaarheid van de hele organisatie.

Remediatie en Verbetering

Wanneer monitoring uitwijst dat één of meerdere API Management-services geen logging hebben geconfigureerd of dat bepaalde services niet langer logs genereren, is snelle remediatie noodzakelijk. In de praktijk gaat het vaak om verkeerd toegepaste diagnostic settings, verwijderde workspacekoppelingen of wijzigingen in netwerkconfiguraties waardoor logs niet meer kunnen worden verzonden. Een effectief remediatieproces begint daarom met een duidelijke beslisboom: is het probleem beperkt tot één service of een hele resourcegroep, is het tijdelijk (bijvoorbeeld onderhoud) of structureel, en welke processen zijn afhankelijk van de betreffende logging? Deze analyse bepaalt welke prioriteit het issue krijgt en wie moet worden betrokken bij de oplossing.

Gebruik PowerShell-script api-management-logging.ps1 (functie Invoke-Remediation) – Ondersteunen bij het herstellen van ontbrekende API Management logging.

De functie Invoke-Remediation in het bijbehorende PowerShell-script is bewust terughoudend: in plaats van automatisch configuraties aan te passen, markeert het script services zonder diagnostic settings en geeft het gerichte aanbevelingen om logging te herstellen. Deze aanpak sluit aan bij de realiteit dat veel organisaties gebruikmaken van infrastructuur-as-code voor definitieve configuratie en dat directe wijzigingen in productie via scripts soms onwenselijk zijn. Het script helpt beheerders door concrete acties te suggereren, zoals het controleren van policy-assignments, het herconfigureren van diagnostic settings of het synchroniseren van instellingen met de gewenste staat in Git. Waar mogelijk kunnen aanvullende helperfuncties worden toegevoegd om standaard-diagnostic settings voor API Management-services voor te bereiden, die vervolgens via het reguliere changeproces worden uitgerold.

Na iedere remediatie-actie volgt een verificatiefase waarin opnieuw wordt gecontroleerd of de beoogde logs daadwerkelijk binnenkomen. Dit gebeurt door zowel het PowerShell-script als handmatige KQL-query's te gebruiken, bijvoorbeeld een time-window search over de laatste uren in ApiManagementGatewayLogs. De resultaten worden vastgelegd in het incident- of wijzigingsdossier, inclusief de grondoorzaak van het probleem en de maatregelen die zijn genomen om herhaling te voorkomen. Denk aan het aanscherpen van Azure Policy-definities, het toevoegen van controles aan CI/CD-pijplijnen of het uitbreiden van monitoring op logvolumes. Door deze feedbacklus consequent te sluiten, groeit de betrouwbaarheid van API Management logging en neemt het risico op onopgemerkte gaten in logging sterk af.

Voor grote incidenten, bijvoorbeeld wanneer wekenlang geen API-logs zijn verzameld uit een kritieke service, wordt remediatie gekoppeld aan bredere herstel- en verbeterprogramma's. Hierbij worden forensische onderzoeksresultaten, juridische beoordelingen en managementrapportages samengebracht om maatregelen te definiëren die verder gaan dan puur technische fixes. Dit kan variëren van aanvullende bewustwordingscampagnes voor API-beheerders tot herontwerp van de API Management-architectuur. API Management logging levert in zulke trajecten het feitenmateriaal dat nodig is om overtuigende businesscases te bouwen en om te laten zien dat investeringen in monitoring daadwerkelijk bijdragen aan lagere risico's en betere naleving van de Nederlandse Baseline voor Veilige Cloud.

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 API Management Logging: Uitgebreide logging voor API-verkeer en beveiligingsmonitoring .DESCRIPTION Controleert of Azure API Management-services correct zijn geconfigureerd met diagnostische logging voor GatewayLogs en WebApplicationFirewallLogs. Deze logging is essentieel voor het monitoren, analyseren en beveiligen van API-verkeer binnen moderne cloudarchitecturen. .NOTES Filename: api-management-logging.ps1 Author: Nederlandse Baseline voor Veilige Cloud Created: 2025-01-15 Last Modified: 2025-01-15 Version: 1.0 Related JSON: content/azure/logging-monitoring/api-management-logging.json Category: logging-monitoring Workload: azure .LINK https://github.com/m365-tenant-best-practise .EXAMPLE .\api-management-logging.ps1 -Monitoring Check compliance status van API Management logging .EXAMPLE .\api-management-logging.ps1 -Remediation Genereert een overzicht van API Management-services zonder logging en aanbevelingen voor herstel .EXAMPLE .\api-management-logging.ps1 -Remediation -WhatIf Show what would be changed without applying #> #Requires -Version 5.1 #Requires -Modules Az.Accounts, Az.ApiManagement, Az.Monitor [CmdletBinding()] param( [Parameter(HelpMessage = "Monitor current configuration status")] [switch]$Monitoring, [Parameter(HelpMessage = "Apply recommended configuration")] [switch]$Remediation, [Parameter(HelpMessage = "Revert to previous configuration")] [switch]$Revert, [Parameter(HelpMessage = "Show what would happen without making changes")] [switch]$WhatIf ) $ErrorActionPreference = 'Stop' # ============================================================================ # HEADER # ============================================================================ Write-Host "`n========================================" -ForegroundColor Cyan Write-Host "API Management Logging" -ForegroundColor Cyan Write-Host "Nederlandse Baseline voor Veilige Cloud" -ForegroundColor Cyan Write-Host "========================================`n" -ForegroundColor Cyan # ============================================================================ # VARIABLES # ============================================================================ $PolicyName = "API Management Logging" $PolicyDescription = "Controleert of Azure API Management-services voorzien zijn van diagnostische logging voor GatewayLogs en WebApplicationFirewallLogs." # ============================================================================ # FUNCTIONS # ============================================================================ function Connect-RequiredServices { <# .SYNOPSIS Maakt verbinding met Azure als dat nog niet is gebeurd. #> [CmdletBinding()] param() 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-ApiManagementServices { <# .SYNOPSIS Haalt alle API Management-services op via Azure Resource Graph. .OUTPUTS Array van API Management-service objecten. #> [CmdletBinding()] param() Write-Verbose "Ophalen van API Management-services via Azure Resource Graph..." $query = @' resources | where type == "microsoft.apimanagement/service" | project id, name, location, subscriptionId, resourceGroup, properties '@ $services = Search-AzGraph -Query $query return $services } function Test-ApiManagementLogging { <# .SYNOPSIS Controleert of API Management-services logging hebben geconfigureerd. .OUTPUTS Array van PSCustomObject met logging status per service. #> [CmdletBinding()] param() $services = Get-ApiManagementServices $results = @() foreach ($service in $services) { $serviceName = $service.name $resourceGroup = $service.resourceGroup $resourceId = $service.id Write-Verbose "Controleren van API Management-service: $serviceName" try { # Controleer of diagnostic settings bestaan $diagnosticSettings = Get-AzDiagnosticSetting -ResourceId $resourceId -ErrorAction SilentlyContinue $hasGatewayLogs = $false $hasWafLogs = $false $hasLogAnalytics = $false $workspaceId = $null if ($diagnosticSettings) { foreach ($setting in $diagnosticSettings) { # Controleer of Log Analytics workspace is geconfigureerd if ($setting.WorkspaceId) { $hasLogAnalytics = $true $workspaceId = $setting.WorkspaceId } # Controleer welke logcategorieën zijn ingeschakeld foreach ($log in $setting.Logs) { if ($log.Category -eq "GatewayLogs" -and $log.Enabled) { $hasGatewayLogs = $true } if ($log.Category -eq "WebApplicationFirewallLogs" -and $log.Enabled) { $hasWafLogs = $true } } } } $isCompliant = $hasLogAnalytics -and ($hasGatewayLogs -or $hasWafLogs) $results += [PSCustomObject]@{ SubscriptionId = $service.subscriptionId SubscriptionName = (Get-AzSubscription -SubscriptionId $service.subscriptionId -ErrorAction SilentlyContinue).Name ResourceGroupName = $resourceGroup ServiceName = $serviceName Location = $service.location HasLogging = $hasLogAnalytics HasGatewayLogs = $hasGatewayLogs HasWafLogs = $hasWafLogs WorkspaceId = $workspaceId IsCompliant = $isCompliant } } catch { Write-Warning "Fout bij controleren van API Management-service '$serviceName': $_" } } return $results } function Test-Compliance { <# .SYNOPSIS Tests if current configuration meets compliance requirements .DESCRIPTION Wrapper function that calls monitoring and returns compliance status .OUTPUTS Returns monitoring result object with isCompliant property #> [CmdletBinding()] param() $services = Test-ApiManagementLogging if (-not $services -or $services.Count -eq 0) { return [PSCustomObject]@{ ScriptName = "api-management-logging" IsCompliant = $true Timestamp = Get-Date Details = "Er zijn geen API Management-services gevonden in de huidige scope." Recommendations = @() Services = @() } } $nonCompliant = $services | Where-Object { -not $_.IsCompliant } $isCompliant = ($nonCompliant.Count -eq 0) $details = if ($isCompliant) { "Alle gevonden API Management-services hebben logging geconfigureerd." } else { "Een of meer API Management-services missen logging configuratie en voldoen niet aan de minimale compliance-eisen." } $recommendations = @() if (-not $isCompliant) { $recommendations += "Configureer diagnostic settings voor alle API Management-services zonder logging." $recommendations += "Schakel GatewayLogs in om alle API-verzoeken en -antwoorden te loggen." $recommendations += "Schakel WebApplicationFirewallLogs in om beveiligingsgebeurtenissen te registreren." $recommendations += "Configureer Log Analytics workspace als bestemming voor centrale analyse." $recommendations += "Documenteer logging configuraties en zorg voor periodieke reviews." } return [PSCustomObject]@{ ScriptName = "api-management-logging" IsCompliant = $isCompliant Timestamp = Get-Date Details = $details Recommendations = $recommendations Services = $services } } function Invoke-Monitoring { <# .SYNOPSIS Monitors and reports current configuration status .DESCRIPTION Checks current configuration against security baseline requirements. Reports compliance status and identifies non-compliant settings. .OUTPUTS Returns hashtable with: - isCompliant: Boolean indicating overall compliance - details: Detailed findings - services: Array of service status objects #> [CmdletBinding()] param() try { 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.IsCompliant) { "Green" } else { "Red" } $statusText = "Logging: $(if ($service.HasLogging) { 'Ja' } else { 'Nee' }), " + "GatewayLogs: $(if ($service.HasGatewayLogs) { 'Ja' } else { 'Nee' }), " + "WAF Logs: $(if ($service.HasWafLogs) { 'Ja' } else { 'Nee' })" Write-Host ("- {0}/{1} ({2}) - {3}" -f $service.SubscriptionName, $service.ServiceName, $service.Location, $statusText) -ForegroundColor $statusColor } } else { Write-Host "`nGeen API Management-services gevonden in de huidige scope." -ForegroundColor Cyan } Write-Host "`n========================================" -ForegroundColor Cyan Write-Host "SUMMARY:" -ForegroundColor Cyan Write-Host " Totaal services: $($services.Count)" -ForegroundColor White Write-Host " Met logging: $(($services | Where-Object { $_.HasLogging }).Count)" -ForegroundColor White Write-Host " Compliant: $(($services | Where-Object { $_.IsCompliant }).Count)" -ForegroundColor White if ($result.IsCompliant) { Write-Host "`n[OK] COMPLIANT" -ForegroundColor Green Write-Host "Alle API Management-services voldoen aan de basisvoorwaarden voor logging." -ForegroundColor Green } else { Write-Host "`n[FAIL] NON-COMPLIANT" -ForegroundColor Red Write-Host "Eén of meer API Management-services missen logging configuratie." -ForegroundColor Red Write-Host "`nAanbevolen acties:" -ForegroundColor Yellow foreach ($rec in $result.Recommendations) { Write-Host (" - {0}" -f $rec) -ForegroundColor Yellow } } return $result } catch { Write-Host "`n[FAIL] ERROR during monitoring: $_" -ForegroundColor Red throw } } function Invoke-Remediation { <# .SYNOPSIS Applies recommended security configuration .DESCRIPTION Genereert een overzicht van API Management-services zonder logging en aanbevelingen voor herstel. In plaats van automatisch configuraties aan te passen, markeert het script services zonder diagnostic settings en geeft gerichte aanbevelingen om logging te herstellen. .PARAMETER WhatIf Shows what would be changed without making actual changes #> [CmdletBinding(SupportsShouldProcess)] param() try { Write-Host "`nRemediatie: $PolicyName" -ForegroundColor Yellow Write-Host "==============================================================" -ForegroundColor Yellow $result = Test-Compliance $services = $result.Services | Where-Object { -not $_.IsCompliant } if (-not $services -or $services.Count -eq 0) { Write-Host "Alle API Management-services beschikken over logging configuratie. Geen remediatie nodig." -ForegroundColor Green return $result } Write-Host "`nNiet-conforme API Management-services (logging ontbreekt of onvolledig):" -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 (" Logging: $(if ($service.HasLogging) { 'Gedeeltelijk' } else { 'Niet geconfigureerd' })") -ForegroundColor Red Write-Host "" } Write-Host "Aanbevolen vervolgstappen:" -ForegroundColor Yellow Write-Host "1. Bepaal per service welke logcategorieën vereist zijn op basis van het risicoprofiel en compliance-eisen." -ForegroundColor Yellow Write-Host "2. Configureer diagnostic settings met GatewayLogs en WebApplicationFirewallLogs ingeschakeld." -ForegroundColor Yellow Write-Host "3. Stel Log Analytics workspace in als bestemming voor centrale analyse en monitoring." -ForegroundColor Yellow Write-Host "4. Verifieer dat logs daadwerkelijk worden gegenereerd door KQL-query's uit te voeren op ApiManagementGatewayLogs." -ForegroundColor Yellow Write-Host "5. Documenteer logging configuraties en zorg voor periodieke reviews 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 } else { Write-Host "`nNOTE: Dit script genereert alleen een rapport. Configureer diagnostic settings handmatig via Azure Portal of gebruik infrastructuur-as-code (ARM/Bicep/Terraform) voor definitieve configuratie." -ForegroundColor Cyan } return $result } catch { Write-Host "`n[FAIL] ERROR during remediation: $_" -ForegroundColor Red throw } } function Invoke-Revert { <# .SYNOPSIS Reverts configuration to previous state .DESCRIPTION Reverts changes made by remediation to restore previous configuration. Voor API Management logging is revert niet aanbevolen omdat dit beveiligingsrisico's introduceert. #> [CmdletBinding(SupportsShouldProcess)] param() try { Write-Host "`nRevert:" -ForegroundColor Yellow Write-Host "WARNING: Het verwijderen van API Management logging is een SECURITY RISK!" -ForegroundColor Red Write-Host "Dit zal beveiligingsmonitoring en incidentonderzoek belemmeren.`n" -ForegroundColor Red Write-Host "Dit script ondersteunt geen automatische revert van logging configuratie." -ForegroundColor Yellow Write-Host "Als revert noodzakelijk is, verwijder dan handmatig diagnostic settings via Azure Portal." -ForegroundColor Yellow Write-Host "Houd er rekening mee dat dit kan leiden tot niet-naleving van compliance-vereisten." -ForegroundColor Yellow } catch { Write-Host "`n[FAIL] ERROR during revert: $_" -ForegroundColor Red throw } } # ============================================================================ # MAIN EXECUTION # ============================================================================ try { Connect-RequiredServices # Determine which action to perform if ($Revert) { if ($WhatIf) { Write-Host "WhatIf: Would revert configuration" -ForegroundColor Yellow } else { Invoke-Revert } } elseif ($Remediation) { if ($WhatIf) { Write-Host "WhatIf: Would apply remediation" -ForegroundColor Yellow } else { Invoke-Remediation } } elseif ($Monitoring) { $result = Invoke-Monitoring # Exit with appropriate code for automation if ($result.IsCompliant) { exit 0 # Success - Compliant } else { exit 1 # Warning - Non-compliant } } else { # No parameters - show usage Write-Host "Available parameters:" -ForegroundColor Yellow Write-Host " -Monitoring : Check current configuration status" -ForegroundColor Gray Write-Host " -Remediation : Generate report and recommendations" -ForegroundColor Gray Write-Host " -Revert : Revert to previous configuration (NOT RECOMMENDED!)" -ForegroundColor Gray Write-Host " -WhatIf : Preview changes without applying" -ForegroundColor Gray Write-Host "`nExample: .\api-management-logging.ps1 -Monitoring" -ForegroundColor Cyan } } catch { Write-Error "Script execution failed: $_" exit 2 # Error } finally { Write-Host "`n========================================`n" -ForegroundColor Cyan } # ============================================================================ # EXIT CODES # ============================================================================ # 0 = Success / Compliant # 1 = Warning / Non-compliant # 2 = Error / Execution failed

Risico zonder implementatie

Risico zonder implementatie
High: Zonder API Management logging kan de organisatie API-aanvallen moeilijk detecteren, blijft het onduidelijk welke data via API's wordt uitgewisseld en is het vrijwel onmogelijk om richting BIO, NIS2 en AVG aan te tonen dat API-monitoring volwassen is ingericht.

Management Samenvatting

Centraliseer alle API-logs in Log Analytics, borg retentie en toegangsbeheer en gebruik scripts en dashboards om continu te controleren of GatewayLogs en WebApplicationFirewallLogs daadwerkelijk worden gegenereerd.