Azure Application Security: Overzicht, Basisprincipes En Implementatie

đź’Ľ Management Samenvatting

Azure Application Security vormt de schil rond alle publieke en interne toepassingen die via het internet of via hybride verbindingen worden ontsloten. Voor Nederlandse overheidsorganisaties is een robuuste applicatiebeveiliging essentieel om persoonsgegevens, vertrouwelijke beleidsinformatie en vitale diensten te beschermen tegen aanvallen via webapplicaties en API’s.

Aanbeveling
IMPLENTEER EEN GESTANDAARDISEERD AZURE APPLICATION SECURITY‑RAAMWERK VOOR ALLE KRITIEKE TOEPASSINGEN.
Risico zonder
High
Risk Score
8/10
Implementatie
88u (tech: 56u)
Van toepassing op:
âś“ Azure
âś“ Hybride omgevingen

Aanvallen verplaatsen zich steeds meer van klassieke infrastructuur naar de applicatielaag. SQL‑injectie, misbruik van zwakke authenticatie, misconfiguraties in App Service, ontbrekende TLS‑configuratie of open debugging‑endpoints zijn terugkerende oorzaken van incidenten in de publieke sector. Tegelijkertijd is het applicatielandschap versnipperd: maatwerkportalen, low‑code oplossingen, legacy‑services achter API‑gateways en SaaS‑koppelingen draaien naast en door elkaar. Zonder een samenhangende Azure Application Security‑aanpak ontstaan blinde vlekken: sommige applicaties worden wel achter een web application firewall geplaatst en volgen de referentie‑architectuur, andere zijn ooit als pilot gestart en groeien ongemerkt uit tot bedrijfskritische voorzieningen zonder structurele beveiligingscontroles. Dit leidt tot een onvoorspelbaar risicoprofiel, maakt audits complex en bemoeilijkt aantoonbare naleving van BIO, NIS2, AVG en sectorspecifieke kaders.

PowerShell Modules Vereist
Primary API: Azure Portal, Azure Resource Manager
Connection: Connect-AzAccount
Required Modules: Az.Accounts, Az.Resources, Az.Websites, Az.PolicyInsights, Az.Security

Implementatie

Dit overzichtsartikel beschrijft hoe u binnen de "Nederlandse Baseline voor Veilige Cloud" een integraal Azure Application Security‑raamwerk opzet. We behandelen de bouwstenen van een veilig applicatielandschap (identiteit, netwerk, data en monitoring), laten zien hoe u App Service, API Management, Application Gateway en Key Vault combineert tot een Zero Trust‑architectuur en geven richtlijnen voor veilige software‑ontwikkeling en deployment. De nadruk ligt op een praktische vertaling naar governance, standaardontwerpen en geautomatiseerde controles met PowerShell‑scripts. Het bijbehorende script `code/azure/application-security/index.ps1` ondersteunt beheerteams bij het inventariseren van webapplicaties, het beoordelen van basisbeveiliging (TLS, HTTPS‑only, managed identities, logging) en het genereren van een compacte managementsamenvatting die direct bruikbaar is in risk‑ en securityoverleggen.

Fundamenten van Azure Application Security en scopebepaling

Een volwassen aanpak voor Azure Application Security begint met een heldere definitie van wat precies onder 'applicatie' valt en welke diensten in scope zijn. In veel organisaties is het applicatielandschap historisch gegroeid: klassieke .NET‑applicaties op virtuele machines draaien naast moderne App Service‑webapps, containers op Azure Kubernetes Service, serverless componenten in Functions en publieke API’s achter Azure API Management. Daarnaast worden SaaS‑oplossingen via custom integraties of embedded iframes ontsloten. Zonder expliciete scopeafbakening bestaat het risico dat alleen de meest zichtbare publieksportalen een stevig beveiligingsontwerp krijgen, terwijl interne beheerportalen, integratiediensten of low‑code apps onder de radar blijven - precies de plekken waar aanvallers vaak hun eerste toegang verkrijgen.

Voor Nederlandse overheden is het logisch om alle intern en extern bereikbare HTTP(S)‑toepassingen die data met verhoogde gevoeligheid verwerken onder de Azure Application Security‑paraplu te brengen. Dat omvat publieke burgerportalen, B2B‑koppelingen met ketenpartners, interne beheerportalen, API’s voor mobiele apps, dashboards voor beleidsinformatie en integratiediensten die persoonsgegevens verwerken. Per toepassing wordt vastgelegd welke data‑classificatie geldt, welke gebruikersgroepen toegang hebben, of er hoge beschikbaarheidseisen zijn en of de applicatie onderdeel is van een vitale keten. Deze gegevens vormen de basis voor ontwerpbeslissingen over netwerksegmentatie, identiteitsmodellen, logging, encryptie en DDoS‑bescherming. Het is cruciaal dat deze scope en classificaties zijn vastgelegd in het ISMS en dat nieuwe applicaties formeel worden toegevoegd via change‑ en architectuurprocessen, zodat er geen schaduwapplicaties ontstaan buiten zicht van CISO en architectuurboard.

Op technisch vlak steunt Azure Application Security op enkele kernprincipes. Alle applicaties worden standaard ontsloten via TLS 1.2 of hoger, met HTTPS‑only afgedwongen aan de rand. Identiteit en autorisatie worden gecentraliseerd via Entra ID (voorheen Azure AD) of andere vertrouwde identiteitsproviders met moderne protocollen zoals OpenID Connect en OAuth 2.0; legacy‑mechanismen zoals basic authentication of onversleutelde sessiecookies worden uitgefaseerd. Inkomend verkeer loopt bij voorkeur via een centrale front‑laag met Application Gateway (met WAF‑functionaliteit) of Azure Front Door zodat inspectie, DDoS‑bescherming en wereldwijde routing op één plek worden geregeld. Gevoelige secrets, certificaten en encryptiesleutels worden nooit in configuratiebestanden of code opgeslagen maar in Key Vault beheerd, bij voorkeur met klantbeheerde sleutels en rotatiebeleid. Logging en monitoring zijn geen bijzaak: HTTP‑logs, applicatielogs en security‑telemetrie worden centraal verzameld in Log Analytics‑workspaces en gekoppeld aan Microsoft Defender for Cloud en Sentinel‑workbooks voor detectie en correlatie.

Naast deze technische fundamenten is governance bepalend voor de effectiviteit van het beveiligingsmodel. Er moet een helder onderscheid zijn tussen platformverantwoordelijkheden (cloudplatform‑ of infra‑teams die de generieke componenten zoals Application Gateway, Key Vault en beleidspakketten beheren) en productverantwoordelijkheden (applicatieteams die de code, configuratie en functioneel gedrag van hun toepassingen beheren). Een gemeenschappelijke referentiearchitectuur beschrijft welke componenten verplicht zijn voor ieder nieuw applicatielandschap, welke varianten zijn toegestaan (bijvoorbeeld regionale deployments, multi‑tenant of single‑tenant) en hoe uitzonderingen worden vastgelegd en beoordeeld. In de Nederlandse publieke sector, waar incidenten direct politieke en maatschappelijke impact kunnen hebben, is het belangrijk dat deze architectuur niet alleen op papier bestaat, maar actief wordt bewaakt via Azure Policy, CI/CD‑validaties en periodieke reviews van kritieke applicaties.

Implementatie van een veilig Azure‑applicatielandschap

Gebruik PowerShell-script index.ps1 (functie Invoke-Implementation) – Ondersteunt teams bij het uitvoeren van een lichte inventarisatie van App Service‑applicaties en het identificeren van snelle verbeterkansen rond HTTPS‑only, TLS‑versies, managed identities en logging..

De praktische implementatie van Azure Application Security start doorgaans met het vastleggen van een standaardontwerp voor nieuwe en bestaande applicaties. Dit ontwerp beschrijft bijvoorbeeld dat alle internet‑exposure via een centrale Application Gateway of Azure Front Door loopt, dat App Service‑plannen in beveiligde subnetten staan met private endpoints, en dat directe publieke toegang tot back‑end‑services wordt uitgesloten. Voor elke nieuwe applicatie‑keten wordt nagegaan of deze blueprint gevolgd kan worden of dat er gerechtvaardigde uitzonderingen nodig zijn, bijvoorbeeld bij specifieke SaaS‑integraties. Die uitzonderingen worden tijdelijk toegestaan, voorzien van mitigerende maatregelen en vastgelegd met een einddatum, zodat het beveiligingsniveau op termijn alsnog naar het standaardontwerp kan worden gebracht. Dit voorkomt een wildgroei aan unieke configuraties en maakt beheer en auditing overzichtelijker.

Op het niveau van individuele App Service‑webapps en API’s draait implementatie om een set concrete beveiligingscontroles. HTTPS‑only wordt afgedwongen, minimaal TLS 1.2 wordt geconfigureerd en, waar mogelijk, worden clientcertificaten of mTLS gebruikt voor machine‑koppelingen. Authenticatie en autorisatie worden via Entra ID of een centrale identity provider afgedwongen met modern tokenbeheer; hard‑coded API‑keys of gedeelde wachtwoorden worden uitgefaseerd. Managed identities worden ingezet voor toegang tot back‑end‑resources zoals databases, storage accounts en Key Vault, zodat secrets niet meer in configuratiebestanden of CI/CD‑pipelines hoeven te staan. Daarnaast wordt voor iedere applicatie een minimaal logging‑ en monitoringprofiel ingericht: HTTP‑logs, toepassingslogs, latencymetingen en security‑gebeurtenissen stromen richting Log Analytics en relevante Defender‑plannen worden geactiveerd. Infrastructure as Code (bijvoorbeeld Bicep of Terraform) en CI/CD‑pijplijnen borgen dat deze instellingen herhaalbaar en controleerbaar zijn en dat afwijkingen zichtbaar worden in code reviews en automatische controles.

Een belangrijk onderdeel van de implementatie is het integreren van application security in de ontwikkel‑ en changeprocessen. DevOps‑teams krijgen duidelijke richtlijnen en templates voor het aanmaken van nieuwe app‑services, API’s en function apps, inclusief standaard configuraties voor netwerk, identiteit, logging en key management. Security‑by‑design wordt verankerd door middel van pre‑deployment checks in pipelines (bijvoorbeeld het blokkeren van deployments die HTTPS‑only uitschakelen of downgraden naar een lagere TLS‑versie) en door gebruik te maken van code‑analyse‑tools voor OWASP Top 10‑risico’s. Voor bestaande applicaties wordt een migratiepad gedefinieerd: inventarisatie van huidige kwetsbaarheden, ordening naar risicoklasse, en een meerjarenplan waarin applicaties gefaseerd naar de doelarchitectuur worden gebracht. Het bijbehorende PowerShell‑script helpt hierbij door snel inzicht te geven in welke applicaties nog niet aan basisvereisten voldoen, zodat verbeteracties gericht kunnen worden ingepland.

ContinuĂŻteits- en securitymonitoring voor applicaties

Gebruik PowerShell-script index.ps1 (functie Invoke-Monitoring) – Voert een lichte read‑only controle uit over App Service‑applicaties en rapporteert de mate waarin basisbeveiligingsinstellingen zijn geconfigureerd..

Monitoring van Azure Application Security richt zich niet alleen op de beschikbaarheid van applicaties, maar vooral op de borging van beveiligingsstandaarden in de tijd. Instellingen zoals HTTPS‑only, minimale TLS‑versies, identity‑configuratie en logging zijn vaak correct bij de eerste oplevering, maar kunnen door wijzigingen in code, infrastructuur of configuratie ongemerkt worden teruggedraaid. Bovendien komen er voortdurend nieuwe applicaties bij, terwijl oude soms vergeten worden. Zonder structurele monitoring ontstaat sluipenderwijs een steeds heterogener landschap met uiteenlopende risiconiveaus. Dit is problematisch in het licht van de BIO en NIS2, die expliciet vragen om continue risicobeheersing en zicht op de effectiviteit van technische en organisatorische maatregelen.

Een effectief monitoringsmodel combineert meerdere bronnen. Azure Policy en Defender for Cloud geven een beleidsmatig beeld: welke beleidsregels zijn toegewezen en waar is sprake van non‑compliance. App Service‑specifieke metrics en diagnostische logs tonen hoe applicaties zich gedragen in de praktijk: foutpercentages, response‑tijden, ongebruikelijke verkeerspatronen en mislukte authenticatiepogingen. Log Analytics‑queries en Sentinel‑workbooks brengen loginformatie uit verschillende lagen (Application Gateway, App Service, Key Vault, identity logs) bij elkaar om verdacht gedrag te detecteren, zoals brute‑force pogingen, scanning, SQL‑injectiepogingen of misbruik van tokens. Het is belangrijk dat deze monitoring niet alleen in de technische teams blijft, maar wordt vertaald naar begrijpelijke dashboards en rapportages voor CISO, CIO en bestuur, zodat trends en risico’s tijdig worden besproken en prioriteiten kunnen worden bijgesteld.

Het PowerShell‑script bij dit artikel levert een aanvullende managementview door op regelmatige basis een samenvattend overzicht te genereren van alle App Service‑applicaties en enkele kernindicatoren: gebruik van HTTPS‑only, toegepaste TLS‑versies, aanwezigheid van managed identities en ingeschakelde logging. In lokale debugmodus kan hetzelfde script worden gebruikt voor snelle controles in ontwikkel‑ en testomgevingen, zonder verbinding te maken met productie‑API’s. De resultaten kunnen worden geëxporteerd naar JSON of CSV en vervolgens worden gekoppeld aan dashboards, ISMS‑rapportages of periodieke security‑reviews. Door deze technische monitoring te koppelen aan governanceprocessen – bijvoorbeeld kwartaalrapportages aan het security‑ en privacyoverleg – wordt Azure Application Security een vast onderdeel van de bredere risicosturing binnen de organisatie.

Remediatie, roadmap en volwassenwording

Gebruik PowerShell-script index.ps1 (functie Invoke-Remediation) – Identificeert applicaties die niet aan basisvereisten voldoen en genereert concrete aanbevelingen voor verbeteracties en prioritering..

Zelfs met een goed ontwerp en monitoring zullen er in de praktijk altijd applicaties zijn die (tijdelijk) niet aan alle veiligheidsstandaarden voldoen. Remediatie gaat erom deze achterstanden zichtbaar te maken, te prioriteren en planmatig weg te werken. Een pragmatische aanpak start met het vastleggen van een drempelset aan basisvereisten, bijvoorbeeld: alle internet‑exposed apps gebruiken HTTPS‑only en minimaal TLS 1.2, beschikken over een centrale identity‑koppeling, gebruiken managed identities voor achterliggende resources en hebben logging en alerting ingeregeld. Het PowerShell‑script bij dit artikel kan periodiek worden gebruikt om applicaties die niet aan deze basisvereisten voldoen te markeren en op te nemen in een remediatie‑backlog. Deze backlog wordt niet als puur technische lijst beheerd, maar gekoppeld aan proceseigenaren, risicoanalyses en planning in het reguliere change‑ en portfoliomanagement.

Voor prioritering wordt gekeken naar data‑classificatie, maatschappelijke impact, blootstelling aan internet en afhankelijkheden in ketens. Een burgerportaal of B2B‑API met gevoelige persoonsgegevens en hoge beschikbaarheidseisen zal bijvoorbeeld een hogere prioriteit krijgen dan een intern beheerportaal voor minder kritieke processen, al moeten ook die op termijn naar de doelarchitectuur worden gebracht. Voor de hoogste prioriteitsapplicaties worden in samenwerking tussen platform‑ en applicatieteams concrete verbeterplannen opgesteld: migratie naar een gestandaardiseerde landing zone, herinrichting van identity‑integratie, uitfasering van legacy‑protocollen en herconfiguratie van netwerkpaden. Bij iedere wijziging worden tests uitgevoerd (functioneel, performance en security) en wordt de nieuwe configuratie vastgelegd in code en documentatie. Door deze verbeteringen cyclisch te plannen – bijvoorbeeld in kwartaalwaves – groeit het totale applicatielandschap stap voor stap naar een hoger maturiteitsniveau.

Volwassenwording betekent tot slot dat Azure Application Security volledig verweven raakt met andere domeinen binnen de "Nederlandse Baseline voor Veilige Cloud". Architectuurboards toetsen nieuwe initiatieven standaard aan de referentiearchitectuur voor applicaties; inkoop en contractmanagement borgen dat externe leveranciers zich aan dezelfde veiligheidsstandaarden houden; en security‑operations‑teams gebruiken de monitoringgegevens als input voor dreigingsanalyses en incidentrespons. De uitkomsten van het remediatie‑script en de bijbehorende dashboards worden periodiek gedeeld met bestuur en toezichthouders als onderdeel van bredere rapportages over digitale weerbaarheid. Zo wordt Azure Application Security geen losstaand project, maar een doorlopend onderdeel van professioneel risicobeheer in de Nederlandse publieke sector.

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 Azure Application Security posturecontrole voor web- en API-workloads .DESCRIPTION Dit script ondersteunt Nederlandse overheidsorganisaties bij het uitvoeren van een read-only security posturecontrole op applicaties die draaien op Azure App Service, API Management en gerelateerde componenten zoals Application Gateway met WAF. Het script controleert onder andere: - Gebruik van HTTPS-only en minimale TLS-versie - Ingeschakelde authenticatie via Entra ID (Azure AD) - Basislogging en diagnostics naar Log Analytics - Aanwezigheid van Web Application Firewall (WAF) voor internetgerichte workloads Het script is ontworpen om veilig lokaal of vanuit een beheerde automation-runner te draaien met READ-ONLY rechten. Het voert GEEN wijzigingen door in de omgeving. .NOTES Filename: index.ps1 Author: Nederlandse Baseline voor Veilige Cloud Created: 2025-11-26 Version: 1.0 Related JSON: content/azure/application-security/index.json CIS Control: CIS Microsoft Azure Foundations Benchmark Category: application-security Workload: azure .LINK https://github.com/m365-tenant-best-practise .EXAMPLE .\index.ps1 -Monitoring Voert een read-only security posturecontrole uit op applicaties in de huidige subscription. .EXAMPLE .\index.ps1 -Remediation -WhatIf Genereert een rapport met concrete aanbevelingen zonder wijzigingen aan te brengen. .EXAMPLE .\index.ps1 -ExportPath .\app-security-report.json Exporteert de bevindingen en aanbevelingen naar een JSON-bestand. #> #Requires -Version 5.1 #Requires -Modules Az.Accounts, Az.Resources, Az.Monitor [CmdletBinding()] param( [Parameter(HelpMessage = "Voer een read-only security posturecontrole uit")] [switch]$Monitoring, [Parameter(HelpMessage = "Genereer aanbevelingen en high-level roadmap (GEEN wijzigingen)")] [switch]$Remediation, [Parameter(HelpMessage = "Reserve-optie, in dit script worden geen wijzigingen teruggedraaid")] [switch]$Revert, [Parameter(HelpMessage = "Toon welke acties zouden worden uitgevoerd zonder deze echt uit te voeren")] [switch]$WhatIf, [Parameter(HelpMessage = "Optioneel pad om resultaten als JSON te exporteren")] [string]$ExportPath ) $ErrorActionPreference = 'Stop' # ============================================================================ # HEADER # ============================================================================ Write-Host "`n========================================" -ForegroundColor Cyan Write-Host "Azure Application Security – Posturecontrole" -ForegroundColor Cyan Write-Host "Nederlandse Baseline voor Veilige Cloud" -ForegroundColor Cyan Write-Host "========================================`n" -ForegroundColor Cyan # ============================================================================ # HULPFUNCTIES # ============================================================================ function Connect-NbvvcAzContext { <# .SYNOPSIS Zorgt voor een geldige Az-context voor leesacties .DESCRIPTION Probeert eerst een bestaande context te gebruiken. Als er geen context is, wordt Connect-AzAccount aangeroepen. Dit is geschikt voor lokale debug- scenario's met een interactieve sessie of een managed identity. #> [CmdletBinding()] param() try { $context = Get-AzContext -ErrorAction SilentlyContinue if (-not $context) { Write-Host "Geen actieve Azure-context gevonden. Probeer te verbinden..." -ForegroundColor Yellow Connect-AzAccount -ErrorAction Stop | Out-Null $context = Get-AzContext -ErrorAction Stop } Write-Host "Actieve Azure-context: $($context.Subscription.Name) [$($context.Subscription.Id)]" -ForegroundColor Gray return $context } catch { Write-Host "[FAIL] Kon geen geldige Azure-context verkrijgen: $_" -ForegroundColor Red throw } } function Get-NbvvcAppSecurityInventory { <# .SYNOPSIS Verzamelt een lichte inventarisatie van applicatiebeveiliging .DESCRIPTION Haalt een selectie van resources op die relevant zijn voor application security: App Services, API Management en Application Gateways met WAF. De inventarisatie is read-only en bedoeld als input voor security reviews. .OUTPUTS Hashtable met inventarisgegevens #> [CmdletBinding()] param() $inventory = @{ timestamp = Get-Date subscriptionId = (Get-AzContext).Subscription.Id appServices = @() apiManagement = @() appGateways = @() findings = @() } Write-Host "`nInventarisatie van applicatie-resources (read-only)..." -ForegroundColor Yellow # App Services try { $apps = Get-AzWebApp -ErrorAction SilentlyContinue foreach ($app in $apps) { $config = $null try { $config = Get-AzWebApp -Name $app.Name -ResourceGroupName $app.ResourceGroup -ErrorAction SilentlyContinue } catch { # Config-opties zijn optioneel; voeg een finding toe indien nodig $inventory.findings += "Kon configuratie niet ophalen voor App Service '$($app.Name)'." } $httpsOnly = $config.SiteConfig.HttpsOnly $minTls = $config.SiteConfig.MinTlsVersion $authEnabled = $false try { $authSettings = Get-AzWebAppAuthSettingsV2 -Name $app.Name -ResourceGroupName $app.ResourceGroup -ErrorAction SilentlyContinue if ($authSettings -and $authSettings.Platform.ClientId) { $authEnabled = $true } } catch { # oude omgevingen of ontbrekende cmdlet; geen harde fout } $inventory.appServices += [PSCustomObject]@{ Name = $app.Name ResourceGroup = $app.ResourceGroup Location = $app.Location HttpsOnly = $httpsOnly MinTls = $minTls AuthEnabled = $authEnabled } } Write-Host " App Services gevonden: $($inventory.appServices.Count)" -ForegroundColor Gray } catch { Write-Host " [WARN] Kon App Services niet opvragen: $_" -ForegroundColor Yellow $inventory.findings += "Kon App Services niet inventariseren; controleer rechten en Az.Websites-module." } # API Management (optioneel; vereist Az.ApiManagement als deze aanwezig is) try { if (Get-Module -ListAvailable -Name Az.ApiManagement) { $apis = Get-AzApiManagement -ErrorAction SilentlyContinue foreach ($api in $apis) { $inventory.apiManagement += [PSCustomObject]@{ Name = $api.Name ResourceGroup = $api.ResourceGroupName Location = $api.Location Sku = $api.Sku.Name } } Write-Host " API Management-instanties gevonden: $($inventory.apiManagement.Count)" -ForegroundColor Gray } else { $inventory.findings += "Az.ApiManagement-module niet gevonden; API Management wordt niet meegenomen in de inventarisatie." } } catch { Write-Host " [WARN] Kon API Management niet opvragen: $_" -ForegroundColor Yellow $inventory.findings += "Kon API Management niet inventariseren; controleer rechten en Az.ApiManagement-module." } # Application Gateways (voor WAF-controle) try { $gateways = Get-AzApplicationGateway -ErrorAction SilentlyContinue foreach ($gw in $gateways) { $wafConfig = $gw.Sku.Tier -like "*WAF*" $inventory.appGateways += [PSCustomObject]@{ Name = $gw.Name ResourceGroup = $gw.ResourceGroupName Location = $gw.Location Sku = $gw.Sku.Name IsWafEnabled = $wafConfig } } Write-Host " Application Gateways gevonden: $($inventory.appGateways.Count)" -ForegroundColor Gray } catch { Write-Host " [WARN] Kon Application Gateways niet opvragen: $_" -ForegroundColor Yellow $inventory.findings += "Kon Application Gateways niet inventariseren; controleer rechten en Az.Network-module." } return $inventory } function Invoke-Monitoring { <# .SYNOPSIS Voert een read-only application security-check uit .DESCRIPTION Gebruikt een lichte inventarisatie om inzicht te geven in de basisbeveiliging van applicaties: TLS-configuratie, HTTPS-only, authenticatie en WAF-dekking. .OUTPUTS Hashtable met samenvattende metrics en inventarisatie #> [CmdletBinding()] param() $null = Connect-NbvvcAzContext $inventory = Get-NbvvcAppSecurityInventory $summary = @{ subscriptionId = $inventory.subscriptionId timestamp = $inventory.timestamp appServiceCount = $inventory.appServices.Count insecureTlsApps = @() noHttpsOnlyApps = @() noAuthApps = @() appGatewayCount = $inventory.appGateways.Count wafGateways = ($inventory.appGateways | Where-Object { $_.IsWafEnabled }).Count findings = $inventory.findings } foreach ($app in $inventory.appServices) { if (-not $app.HttpsOnly) { $summary.noHttpsOnlyApps += $app.Name } if ($app.MinTls -lt 1.2) { $summary.insecureTlsApps += $app.Name } if (-not $app.AuthEnabled) { $summary.noAuthApps += $app.Name } } Write-Host "`n========================================" -ForegroundColor Cyan Write-Host "SAMENVATTING APPLICATION SECURITY" -ForegroundColor Cyan Write-Host " App Services totaal : $($summary.appServiceCount)" -ForegroundColor White Write-Host " Application Gateways : $($summary.appGatewayCount)" -ForegroundColor White Write-Host " Gateways met WAF-tier : $($summary.wafGateways)" -ForegroundColor White if ($summary.noHttpsOnlyApps.Count -gt 0) { Write-Host "`nApp Services zonder HTTPS-only:" -ForegroundColor Yellow foreach ($name in $summary.noHttpsOnlyApps) { Write-Host " - $name" -ForegroundColor Gray } } else { Write-Host "`nAlle App Services forceren HTTPS-only (op basis van inventarisatie)." -ForegroundColor Green } if ($summary.insecureTlsApps.Count -gt 0) { Write-Host "`nApp Services met TLS-versie lager dan 1.2:" -ForegroundColor Yellow foreach ($name in $summary.insecureTlsApps) { Write-Host " - $name" -ForegroundColor Gray } } else { Write-Host "Geen App Services gevonden met een minimale TLS-versie lager dan 1.2." -ForegroundColor Green } if ($summary.noAuthApps.Count -gt 0) { Write-Host "`nApp Services zonder ingeschakelde authenticatie (App Service Authentication/AAD):" -ForegroundColor Yellow foreach ($name in $summary.noAuthApps) { Write-Host " - $name" -ForegroundColor Gray } $summary.findings += "Een of meer App Services lijken geen platform-authenticatie te gebruiken; beoordeel of dit acceptabel is binnen de referentiearchitectuur." } else { Write-Host "Voor alle geïnventariseerde App Services is platform-authenticatie gedetecteerd (voor zover ondersteund door de omgeving)." -ForegroundColor Green } if ($summary.findings.Count -gt 0) { Write-Host "`nAandachtspunten tijdens inventarisatie:" -ForegroundColor Yellow foreach ($f in $summary.findings) { Write-Host " - $f" -ForegroundColor Yellow } } return @{ summary = $summary inventory = $inventory } } function Invoke-Remediation { <# .SYNOPSIS Genereert application security-aanbevelingen en optioneel een JSON-rapport .DESCRIPTION Op basis van de inventarisatie worden concrete aanbevelingen gegenereerd voor vervolgstappen zoals het afdwingen van HTTPS-only, verhoging van de minimale TLS-versie, inzet van WAF en het configureren van centrale logging. Het script voert zelf geen wijzigingen door. #> [CmdletBinding(SupportsShouldProcess)] param( [string]$ReportPath ) if ($WhatIf) { Write-Host "`nWhatIf: er wordt een aanbevelingsrapport gegenereerd op basis van inventarisatiegegevens, maar er vinden geen wijzigingen plaats." -ForegroundColor Yellow } $result = Invoke-Monitoring $summary = $result.summary $inventory = $result.inventory $recommendations = @() if ($summary.noHttpsOnlyApps.Count -gt 0) { $recommendations += "Configureer HTTPS-only voor alle publieke App Services zodat onversleuteld HTTP-verkeer wordt geblokkeerd." } if ($summary.insecureTlsApps.Count -gt 0) { $recommendations += "Verhoog de minimale TLS-versie naar minimaal 1.2 (bij voorkeur 1.3) voor alle App Services die nu een lagere versie toestaan." } if ($summary.noAuthApps.Count -gt 0) { $recommendations += "Evalueer App Services zonder platform-authenticatie en implementeer Entra ID-based authenticatie of API Management waar passend." } if ($summary.wafGateways -eq 0 -and $summary.appServiceCount -gt 0) { $recommendations += "Plaats internetgerichte webapplicaties achter een Web Application Firewall (bijvoorbeeld Application Gateway WAF of Front Door WAF)." } if ($recommendations.Count -eq 0) { $recommendations += "Geen directe high-level verbeterpunten gedetecteerd op basis van deze lichte scan; voer een diepgaand architectuur- en code-review uit voor kernapplicaties." } Write-Host "`nAanbevolen vervolgstappen:" -ForegroundColor Cyan foreach ($rec in $recommendations) { Write-Host " - $rec" -ForegroundColor White } $report = @{ generatedAt = Get-Date subscriptionId = $summary.subscriptionId applicationSecurity = @{ indicators = @{ noHttpsOnlyApps = $summary.noHttpsOnlyApps insecureTlsApps = $summary.insecureTlsApps noAuthApps = $summary.noAuthApps appGatewayCount = $summary.appGatewayCount wafGateways = $summary.wafGateways } recommendations = $recommendations } inventory = $inventory } $targetPath = $null if ($PSBoundParameters.ContainsKey("ReportPath") -and $ReportPath) { $targetPath = $ReportPath } elseif ($ExportPath) { $targetPath = $ExportPath } if ($targetPath) { if ($PSCmdlet.ShouldProcess($targetPath, "Schrijf application security-rapport naar JSON-bestand")) { $report | ConvertTo-Json -Depth 6 | Out-File -FilePath $targetPath -Encoding UTF8 Write-Host "`n[OK] Rapport geschreven naar: $targetPath" -ForegroundColor Green } } } function Invoke-Revert { <# .SYNOPSIS Placeholder voor revert-logica .DESCRIPTION Dit script voert geen configuratiewijzigingen uit, daarom is er geen revert-implementatie nodig. De functie is aanwezig voor consistentie met andere scripts binnen de Nederlandse Baseline voor Veilige Cloud. #> [CmdletBinding(SupportsShouldProcess)] param() Write-Host "`nEr zijn geen wijzigingen aangebracht door dit script; revert is niet van toepassing." -ForegroundColor Green } # ============================================================================ # MAIN EXECUTION # ============================================================================ try { if ($Revert) { Invoke-Revert } elseif ($Remediation) { Invoke-Remediation -ReportPath $ExportPath } elseif ($Monitoring) { $null = Invoke-Monitoring } else { Write-Host "Beschikbare parameters:" -ForegroundColor Yellow Write-Host " -Monitoring : Voer een read-only security posturecontrole uit" -ForegroundColor Gray Write-Host " -Remediation : Genereer application security-aanbevelingen (geen wijzigingen)" -ForegroundColor Gray Write-Host " -Revert : Niet van toepassing (geen wijzigingen)" -ForegroundColor Gray Write-Host " -WhatIf : Toon welke acties logisch zouden zijn zonder uitvoer" -ForegroundColor Gray Write-Host " -ExportPath : Optioneel pad voor JSON-rapport" -ForegroundColor Gray Write-Host "`nVoorbeeld: .\index.ps1 -Monitoring" -ForegroundColor Cyan } } catch { Write-Error "Scriptuitvoering mislukt: $_" exit 2 } finally { Write-Host "`n========================================`n" -ForegroundColor Cyan } # Exitcodes: # 0 = Succesvolle uitvoering # 2 = Fout tijdens uitvoering

Risico zonder implementatie

Risico zonder implementatie
High: Zonder een samenhangende Azure Application Security‑aanpak ontstaat een versnipperd applicatielandschap waarin kwetsbare webapps en API’s eenvoudig kunnen worden misbruikt. Dit vergroot de kans op datalekken, service‑onderbrekingen, juridische aansprakelijkheid en negatieve publiciteit, en maakt het vrijwel onmogelijk om aantoonbaar te voldoen aan BIO, NIS2, AVG en sectorspecifieke kaders.

Management Samenvatting

Azure Application Security bundelt architectuur, configuratie en monitoring tot een uniform beveiligingsmodel voor alle webapplicaties en API’s. Door basisprincipes zoals HTTPS‑only, moderne identity‑integratie, managed identities, centrale logging en periodieke controles te standaardiseren en te automatiseren, verlaagt u structureel het aanvalsoppervlak en verhoogt u de voorspelbaarheid van security‑prestaties.