BIO 11.01 ISO A.8.25

Azure App Service: Secure Development Practices

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

💼 Management Samenvatting

Secure development practices voor Azure App Service vormen de ruggengraat van een volwassen cloudbeveiligingsstrategie. Waar traditionele beveiliging zich vooral richt op infrastructuur en netwerk, ligt in moderne cloudomgevingen een groot deel van het risico in de applicatiecode zelf: kwetsbaarheden in inputvalidatie, onveilige afhankelijkheden, geheimen in code en onvoldoende logging leiden rechtstreeks tot misbruik, datalekken en verstoringen. Nederlandse overheidsorganisaties moeten daarom een integraal beveiligd ontwikkelproces inrichten waarin security vanaf het eerste ontwerp tot en met productie-deployments consequent wordt meegenomen.

Aanbeveling
IMPLEMENTEER EEN VOLWASSEN SECURE DEVELOPMENT LIFECYCLE VOOR ALLE APP SERVICE-APPLICATIES
Risico zonder
High
Risk Score
8/10
Implementatie
180u (tech: 120u)
Van toepassing op:
✓ Azure App Service
✓ Azure Functions
✓ Web Apps

Zonder gestructureerde secure development practices ontstaat er een patroon van ad-hoc beveiligingsmaatregelen die vooral reactief zijn: kwetsbaarheden worden pas ontdekt na penetratietesten, audits of – erger nog – na een beveiligingsincident. Ontwikkelteams voelen druk om snel functionaliteit op te leveren en schuiven security-werkzaamheden voor zich uit, waardoor bekende OWASP Top 10-risico's zoals SQL-injectie, broken access control, onveilige authenticatie en blootgestelde API's in productie terechtkomen. In Azure App Service-omgevingen zien auditors regelmatig code met hardcoded secrets, niet-gevalideerde gebruikersinput die direct wordt doorgestuurd naar databases of achterliggende API's, onvoldoende foutafhandeling waardoor interne systeeminformatie in foutmeldingen zichtbaar wordt, en een gebrek aan structurele security reviews in het ontwikkelproces. Dit leidt tot een onoverzichtelijk risico-profiel: er is geen aantoonbare lijn tussen ontwerpbeslissingen, threat modeling, codekwaliteit, testresultaten en de configuratie van de productie-omgeving. Voor organisaties die moeten voldoen aan BIO, NIS2 en ISO 27001 is dit onhoudbaar; deze kaders vereisen expliciet dat beveiliging integraal onderdeel is van de levenscyclus van informatiesystemen en dat keuzes aantoonbaar zijn gedocumenteerd en beoordeeld.

PowerShell Modules Vereist
Primary API: Azure API
Connection: Connect-AzAccount
Required Modules: Az.Websites, Az.Resources, Az.Accounts

Implementatie

Dit artikel beschrijft een compleet raamwerk voor secure development practices specifiek gericht op applicaties die draaien op Azure App Service binnen de context van de Nederlandse Baseline voor Veilige Cloud. Het raamwerk combineert procesmatige maatregelen (zoals het inrichten van een Secure Development Lifecycle met vaste security gates), praktische technische maatregelen (zoals het standaard uitvoeren van statische code-analyse, dependency scanning, secret scanning en automatische beveiligingstesten in CI/CD pipelines), en organisatorische maatregelen (zoals het definiëren van duidelijke rollen en verantwoordelijkheden, het trainen van ontwikkelaars en het vastleggen van beslissingen in een security-architectuurdossier). Aan de hand van concrete stappen wordt uitgewerkt hoe organisaties threat modeling structureel kunnen toepassen bij nieuwe functionaliteiten, hoe code reviews worden uitgebreid met security-checklists, hoe open-source componenten en libraries continu op kwetsbaarheden worden gecontroleerd, en hoe bevindingen uit tooling worden vertaald naar verbeteracties met duidelijke prioriteiten. Bovendien wordt beschreven hoe deze secure development practices aansluiten op andere maatregelen in de Nederlandse Baseline voor Veilige Cloud, zoals het afdwingen van HTTPS-only, managed identities, Key Vault-integratie, logging en monitoring. Het artikel bevat een PowerShell-script dat App Services inventariseert en rapporteert of basisvoorwaarden voor secure development – zoals tagging, omgevingsscheiding en enkele beveiligingsinstellingen – aanwezig zijn, zodat security- en ontwikkelteams gericht kunnen verbeteren.

Fundament van een Secure Development Lifecycle voor Azure App Service

Een Secure Development Lifecycle (SDLC) is geen losstaand project, maar een permanent raamwerk dat bepaalt hoe software binnen de organisatie wordt ontworpen, gebouwd, getest en beheerd. Voor Azure App Service betekent dit dat elke webapplicatie en API – van idee tot productie – dezelfde beveiligingsstappen doorloopt. De basis begint bij een formeel vastgelegd SDLC-proces waarin security expliciet is opgenomen als onderdeel van elke fase: initiatie, ontwerp, ontwikkeling, testen, implementatie en beheer. Dit proces wordt beschreven in beleid en werkinstructies, zodat ontwikkelaars, product owners, security officers en beheerders exact weten welke beveiligingsacties op welk moment verplicht zijn. Het voorkomt dat security wordt gezien als een optionele controle "aan het einde", en borgt dat risico's vroegtijdig worden geïdentificeerd en gemitigeerd wanneer de kosten en impact nog relatief laag zijn.

In de initiatie- en ontwerpfase ligt de nadruk op het begrijpen van de bedrijfsdoelen, gegevensstromen en risico's. Voor Nederlandse overheidsorganisaties betekent dit onder andere dat dataclassificatie volgens de eigen BIO-implementatie direct gekoppeld wordt aan ontwerpbeslissingen: applicaties die persoonsgegevens of bijzondere categorieën gegevens verwerken, krijgen strengere eisen op het gebied van authenticatie, autorisatie, logging, encryptie en monitoring. Hierbij wordt een threat model opgesteld waarin dreigingen worden geanalyseerd voor elke belangrijke component: de gebruiker, de webapp op App Service, achterliggende API's, databases, integraties met externe partijen en beheervoorzieningen. Voorbeelden van dreigingen zijn misbruik van kwetsbare API-eindpunten, misbruik van debug-functionaliteit, privilege escalation via foutieve autorisatieregels, en datalekken via onvoldoende geanonimiseerde logging. Dit threat model wordt niet eenmalig geschreven, maar telkens geactualiseerd bij grote functionele wijzigingen.

In de ontwikkelfase wordt het threat model vertaald naar concrete ontwikkelrichtlijnen. Deze richtlijnen zijn vastgelegd in een organisatiebrede secure coding standaard die specifiek rekening houdt met Azure App Service. Zo wordt voorgeschreven dat alle geheime waarden (zoals connection strings, API-sleutels en certificaatgegevens) uitsluitend via Azure Key Vault en App Service settings worden beheerd en nooit in code of configuratiebestanden in source control mogen voorkomen. Verder omvat de standaard strikte inputvalidatie op alle invoerpunten, het gebruik van parameterized queries of ORM-lagen om SQL-injectie te voorkomen, robuuste foutafhandeling zonder gevoelige systeeminformatie in foutmeldingen, en een duidelijke scheiding tussen lagen in de applicatie-architectuur. Ontwikkelaars gebruiken referentie-implementaties en voorbeeldprojecten die deze patronen demonstreren zodat de kloof tussen beleid en praktijk zo klein mogelijk wordt.

Een essentieel onderdeel van de secure SDLC is dat code reviews nooit alleen door de oorspronkelijke ontwikkelaar worden uitgevoerd, maar altijd door minimaal één andere ontwikkelaar of security champion die specifiek ook naar beveiligingsaspecten kijkt. Hiervoor worden gestandaardiseerde reviewchecklists gebruikt die zijn afgestemd op de Nederlandse Baseline voor Veilige Cloud, met vragen zoals: worden alle externe invoerbronnen gevalideerd, worden rechten correct gecontroleerd op elke gevoelige actie, worden secrets uitsluitend via Key Vault opgehaald, is logging zo ingericht dat beveiligingsrelevante gebeurtenissen worden vastgelegd zonder vertrouwelijke gegevens te loggen, en wordt gebruikgemaakt van bestaande, onderhouden libraries in plaats van zelfgeschreven crypto of beveiligingsmechanismen. Deze checklists worden in het ontwikkelproces geïntegreerd via pull request-templates in Git-systemen, zodat elke wijziging automatisch langs dezelfde beveiligingslat wordt gelegd.

Tot slot moet de secure SDLC stevig worden verankerd in governance en kwaliteitsborging. Dit betekent dat management expliciet eigenaarschap benoemt voor het ontwikkelproces, dat er periodieke evaluaties van de SDLC plaatsvinden (bijvoorbeeld jaarlijks of na grote incidenten), en dat bevindingen uit audits, pentests en incidentonderzoek leiden tot aanpassingen in richtlijnen, tooling en training. Rapportages over de volwassenheid van de secure SDLC – bijvoorbeeld op basis van OWASP SAMM of Microsoft SDL-principes – worden gedeeld met CISO's, CIO's en lijnmanagement zodat duidelijk is waar verbetering nodig is en welke teams vooroplopen. Zo groeit secure development van een "technische activiteit" naar een integraal onderdeel van risicomanagement en strategische besluitvorming.

Automatisering, Codekwaliteit en Scans in CI/CD

Handmatige controles alleen zijn niet voldoende om de beveiliging van moderne cloudapplicaties te borgen; er zijn te veel regels, afhankelijkheden en releases om alles met de hand te blijven beoordelen. Daarom vormt automatisering via CI/CD-pipelines een kernonderdeel van secure development practices voor Azure App Service. In een volwassen DevSecOps-omgeving start iedere commit naar de main- of develop-branch automatisch een pipeline die verschillende lagen van kwaliteits- en beveiligingscontroles uitvoert, nog voordat code wordt gedeployed naar een test- of staging-omgeving. Deze aanpak verkleint de feedbackloop voor ontwikkelaars: kwetsbaarheden, code smells en policy violations worden binnen minuten zichtbaar, in plaats van pas tijdens een jaarlijkse pentest of audit.

Een eerste pijler van deze automatisering is statische code-analyse. Tools zoals SonarQube, CodeQL of vergelijkbare oplossingen worden geïntegreerd in de pipeline en scannen bij elke build de volledige codebasis op bekende anti-patterns, kwetsbare constructies, onveilige API-aanroepen en potentiële injectiepunten. De resultaten worden niet alleen als rapport beschikbaar gesteld, maar vertaald naar kwaliteitsgateways: builds slagen alleen als er geen nieuwe kritieke of hoge bevindingen worden geïntroduceerd. Hierdoor wordt voorkomen dat technische schuld op beveiligingsgebied zich ophoopt. Voor Nederlandse overheidsorganisaties is dit belangrijk bewijs richting auditors: men kan laten zien dat beveiligingscontroles structureel en geautomatiseerd plaatsvinden, en dat er duidelijke acceptatiecriteria voor code gelden.

Naast statische analyse is dependency scanning cruciaal. Moderne webapplicaties leunen zwaar op open-source libraries en frameworks. Kwetsbaarheden in deze componenten zijn een van de belangrijkste oorzaken van incidenten wereldwijd. De pipeline moet daarom tools uitvoeren die alle gebruikte pakketten en versies inventariseren (bijvoorbeeld via Software Bill of Materials, SBOM) en deze vergelijken met publieke kwetsbaarheidsdatabases zoals NVD, Github Advisory Database of commerciële feeds. Wanneer kritieke kwetsbaarheden worden gevonden in bibliotheken die worden gebruikt door App Service-applicaties, moet de pipeline falen of minimaal een dwingende waarschuwing genereren, met concrete instructies welke versies moeten worden opgewaardeerd. Voor applicaties met hoge dataclassificatie kan worden geëist dat er geen bekende kwetsbaarheden met CVSS-score boven een ingestelde drempel in productie aanwezig zijn.

Secret scanning vormt een derde belangrijke automatiseringslaag. Ondanks richtlijnen blijven ontwikkelaars per ongeluk API-sleutels, wachtwoorden of connection strings committen naar repository's. Door in de CI/CD-pipeline secret scanning-tools te gebruiken die bekende patronen voor sleutels, certificaten en tokens herkennen, kunnen deze fouten snel worden opgespoord. Wanneer een potentieel geheim wordt gedetecteerd, moet de pipeline de build blokkeren, de betrokken ontwikkelaar informeren en – waar mogelijk – automatisch een rotationproces starten voor het betreffende geheim in Key Vault of andere beheersystemen. Deze werkwijze verkleint de kans dat gelekte secrets jarenlang onopgemerkt in de geschiedenis van het versiebeheersysteem blijven staan.

Naast code- en dependencycontroles is het essentieel om ook infrastructuuropzet en App Service-configuratie in de pipeline te valideren. Infrastructure as Code-templates (bijvoorbeeld Bicep of ARM) worden geanalyseerd met linters en policy-as-code oplossingen om te verifiëren dat basisbeveiligingsinstellingen aanwezig zijn: HTTPS-only, minimale TLS-versie, uitschakelen van FTP/FTPS waar mogelijk, gebruik van managed identities, geen publiek toegankelijke beheerendpoints, en correcte integratie met Key Vault. De pipeline kan Azure Policy-evaluaties uitvoeren in een niet-productie-abonnement of via what-if-deployments om te controleren of geplande wijzigingen conform de Nederlandse Baseline voor Veilige Cloud zijn. Alleen wanneer alle checks slagen, wordt een deployment naar staging of productie toegestaan, idealiter in combinatie met deployment slots zodat nieuwe versies eerst in een gecontroleerde omgeving worden getest.

Tot slot moeten de resultaten van al deze geautomatiseerde controles zichtbaar en bruikbaar zijn voor zowel ontwikkelteams als security en management. Dit betekent dat pipeline-uitkomsten niet alleen in logbestanden staan, maar via dashboards, e-mailrapporten of integraties met issue trackers worden ontsloten. Kritieke bevindingen leiden automatisch tot tickets in systemen zoals Azure Boards, Jira of een ISMS-oplossing, met duidelijke eigenaar, prioriteit en doorlooptijd. Overzichten tonen trends in het aantal beveiligingsbevindingen, de gemiddelde oplostijd en het percentage builds dat de security gates haalt. Zo ontstaat een cultuur waarin beveiliging daadwerkelijk onderdeel is van continue verbetering en waarin teams worden afgerekend op meetbare kwaliteitsindicatoren.

Monitoring, Auditing en Doorlopende Borging

Gebruik PowerShell-script secure-development-practices.ps1 (functie Invoke-Monitoring) – Controleert basisindicatoren voor secure development practices op Azure App Service-resources.

Zelfs met een goed ingericht secure SDLC en krachtige CI/CD-pipelines blijft doorlopende monitoring noodzakelijk om zeker te stellen dat veilige ontwikkelpraktijken daadwerkelijk worden toegepast en volgehouden. Voor Azure App Service betekent dit dat organisaties niet alleen naar de broncode en pipelines kijken, maar ook naar de live configuratie van applicaties, de manier waarop releases plaatsvinden en de feitelijke gebruikspatronen. Monitoring richt zich daarbij op zowel technische signalen (zoals configuratiefouten en ontbrekende beveiligingsinstellingen) als procesindicatoren (zoals het wel of niet toepassen van tagging en het gebruik van deployment slots).

Een praktijkgerichte manier om dit te ondersteunen is het periodiek draaien van een controlescript dat alle App Services in een subscription inventariseert en controleert op een aantal basisvoorwaarden voor secure development. Denk hierbij aan het gebruik van omgevingsspecifieke tags (zoals Environment=Prod/Test/Dev en Owner of Application) die essentieel zijn voor impactanalyse en verantwoordelijkheidstoedeling, het afdwingen van HTTPS-only verbindingen en een minimale TLS-versie, en het gebruik van managed identities in plaats van hardcoded credentials. Hoewel deze controles geen volledig beeld geven van alle aspecten van secure development, bieden ze wel een laagdrempelige eerste indicatie van volwassenheid en maken zij het mogelijk om snel applicaties te identificeren die waarschijnlijk buiten het gewenste ontwikkelproces vallen.

Naast deze technische controles moeten overheidsorganisaties ook op procesniveau monitoren of beveiligingsactiviteiten daadwerkelijk worden uitgevoerd volgens plan. Dit omvat het periodiek evalueren van code review-statistieken (bijvoorbeeld het percentage pull requests waarbij minimaal één extra reviewer is betrokken en het aandeel daarvan door een security champion), het bijhouden van de doorlooptijd van het oplossen van kritieke beveiligingsbevindingen uit tooling, en het monitoren van uitzonderingen op standaardprocessen. Afwijkingen, zoals noodhotfixes die buiten de reguliere SDLC om in productie zijn gebracht, worden expliciet gelogd en geëvalueerd in post-incident reviews. Op basis hiervan worden verbeteracties vastgelegd, zoals het aanpassen van testplannen, het uitbreiden van monitoringregels of het aanscherpen van releasecriteria.

Auditing vormt de derde pijler van borging. Interne en externe auditors toetsen periodiek of de beschreven secure development practices daadwerkelijk worden nageleefd en aantoonbaar zijn. Voor Azure App Service-applicaties betekent dit dat organisaties concrete auditbewijzen moeten kunnen overleggen: beleidsdocumenten en procesbeschrijvingen van de secure SDLC, voorbeelden van threat models en security-architectuurdocumenten voor kritieke applicaties, rapporten van code-analyse- en dependency scanningtools inclusief opvolging, change- en release-dossiers met verwijzing naar security gates, en overzichten van training en awarenessactiviteiten voor ontwikkelteams. De uitkomsten van audits worden niet alleen gebruikt om tekortkomingen te corrigeren, maar ook om management inzicht te geven in de mate waarin secure development daadwerkelijk is ingebed in de organisatiecultuur.

Door monitoring, rapportage en auditing structureel te combineren ontstaat een feedbacklus waarin secure development geen momentopname is, maar een continu verbeterproces. Incidenten, bijna-incidenten en bevindingen uit tooling en audits worden teruggekoppeld naar ontwerp- en ontwikkelteams, die hun standaarden, voorbeelden en pipelines hierop aanpassen. Op deze manier ontwikkelt de organisatie stap voor stap een volwassen secure development capability: niet alleen voor individuele Azure App Service-applicaties, maar als integraal onderdeel 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
<# ================================================================================ AZURE POWERSHELL SCRIPT - Nederlandse Baseline voor Veilige Cloud ================================================================================ .SYNOPSIS Azure App Service: Secure Development Practices .DESCRIPTION Voert een lichte controle uit op Azure App Services om basisindicatoren voor secure development practices te beoordelen, zoals: - Gebruik van HTTPS-only en minimale TLS-versie - Aanwezigheid van omgevings- en eigenaars-tags - Gebruik van managed identity in plaats van geheimen in code Dit script is bedoeld als ondersteunende monitoring voor het artikel 'Secure Development Practices' en geeft ontwikkel- en securityteams inzicht in waar de basisconfiguratie van App Services nog versterkt moet worden. Het script wijzigt zelf niets aan resources. .NOTES Filename: secure-development-practices.ps1 Author: Nederlandse Baseline voor Veilige Cloud Created: 2025-11-26 Last Modified: 2025-11-26 Version: 1.0 Related JSON: content/azure/app-service/secure-development-practices.json .PARAMETER WhatIf Toont wat het script zou doen zonder verbinding met Azure te maken. Handig voor lokale tests of om impact in te schatten. .PARAMETER Monitoring Voert de uitgebreide monitoringweergave uit met samenvatting en details. .EXAMPLE .\secure-development-practices.ps1 Voert een basiscontrole uit en retourneert een object met resultaten. .EXAMPLE .\secure-development-practices.ps1 -Monitoring Toont een leesbaar overzicht in de console. .EXAMPLE .\secure-development-practices.ps1 -WhatIf Voert alleen een dry-run uit zonder Azure-verbinding (voor snelle lokale test). #> # ============================================================================ # REQUIREMENTS # ============================================================================ #Requires -Version 5.1 #Requires -Modules Az.Accounts #Requires -Modules Az.Websites # ============================================================================ # PARAMETERS # ============================================================================ [CmdletBinding()] param( [Parameter()][switch]$WhatIf, [Parameter()][switch]$Monitoring ) # ============================================================================ # GLOBAL SETTINGS # ============================================================================ $ErrorActionPreference = 'Stop' $VerbosePreference = 'SilentlyContinue' $PolicyName = "Azure App Service: Secure Development Practices" # ============================================================================ # FUNCTION: Test-ModuleAvailability # ============================================================================ function Test-ModuleAvailability { <# .SYNOPSIS Controleert of vereiste Az-modules beschikbaar zijn. #> [CmdletBinding()] param() $requiredModules = @('Az.Accounts', 'Az.Websites') $missing = @() foreach ($m in $requiredModules) { if (-not (Get-Module -ListAvailable -Name $m)) { $missing += $m } } return $missing } # ============================================================================ # FUNCTION: Connect-IfNeeded # ============================================================================ function Connect-IfNeeded { <# .SYNOPSIS Maakt verbinding met Azure indien nog geen context actief is. #> [CmdletBinding()] param() if ($WhatIf) { Write-Verbose "WhatIf is ingeschakeld - geen Azure-verbinding maken." return } try { $context = Get-AzContext -ErrorAction SilentlyContinue if (-not $context) { Write-Host "Verbinding maken met Azure..." -ForegroundColor Yellow Connect-AzAccount -ErrorAction Stop | Out-Null $context = Get-AzContext Write-Host "Verbonden met Azure als $($context.Account.Id)" -ForegroundColor Green } else { Write-Verbose "Reeds verbonden met Azure als $($context.Account.Id)" } } catch { Write-Error "Kon niet verbinden met Azure: $_" throw } } # ============================================================================ # FUNCTION: Get-AppServiceConfigurationInfo # ============================================================================ function Get-AppServiceConfigurationInfo { <# .SYNOPSIS Haalt basisconfiguratiegegevens op voor een App Service. #> [CmdletBinding()] param( [Parameter(Mandatory = $true)] [Microsoft.Azure.Commands.WebApps.Models.PSSite]$WebApp ) $config = $null try { $config = Get-AzWebApp -ResourceGroupName $WebApp.ResourceGroup -Name $WebApp.Name -ErrorAction Stop } catch { Write-Verbose "Kon configuratie voor $($WebApp.Name) niet ophalen: $_" } # HTTPS-only en TLS-minimum $httpsOnly = $false $minTls = $null try { $siteConfig = Get-AzWebAppSlotConfigName -ResourceGroupName $WebApp.ResourceGroup -Name $WebApp.Name -ErrorAction SilentlyContinue } catch { # optioneel, niet kritisch } try { $webConfig = Get-AzWebApp -ResourceGroupName $WebApp.ResourceGroup -Name $WebApp.Name -ErrorAction SilentlyContinue if ($webConfig -and $webConfig.SiteConfig) { $httpsOnly = [bool]$webConfig.HttpsOnly $minTls = $webConfig.SiteConfig.MinTlsVersion } } catch { Write-Verbose "Kon SiteConfig voor $($WebApp.Name) niet ophalen: $_" } # Managed identity $hasManagedIdentity = $false if ($config -and $config.Identity -and $config.Identity.Type -ne 'None') { $hasManagedIdentity = $true } # Tags $tags = $WebApp.Tags $environmentTag = $null $ownerTag = $null if ($tags) { if ($tags.ContainsKey('Environment')) { $environmentTag = $tags['Environment'] } if ($tags.ContainsKey('Owner')) { $ownerTag = $tags['Owner'] } } [PSCustomObject]@{ Name = $WebApp.Name ResourceGroup = $WebApp.ResourceGroup Location = $WebApp.Location HttpsOnly = $httpsOnly MinTlsVersion = $minTls HasManagedIdentity= $hasManagedIdentity EnvironmentTag = $environmentTag OwnerTag = $ownerTag } } # ============================================================================ # FUNCTION: Test-SecureDevelopmentPractices # ============================================================================ function Test-SecureDevelopmentPractices { <# .SYNOPSIS Voert basiscontroles uit op App Services. .OUTPUTS PSCustomObject met samenvatting en details. #> [CmdletBinding()] param() $result = [PSCustomObject]@{ ScriptName = "secure-development-practices" PolicyName = $PolicyName IsCompliant = $false TotalResources = 0 CompliantCount = 0 NonCompliantCount = 0 Details = @() MissingTags = @() MissingHttpsOnly = @() MissingManagedId = @() Recommendations = @() } $missingModules = Test-ModuleAvailability if ($missingModules.Count -gt 0) { $result.Details += "Vereiste Az-modules ontbreken: $($missingModules -join ', '). Installeer deze modules om de controle volledig uit te voeren." # We retourneren hier een niet-fatal resultaat zodat het script lokaal getest kan worden. $result.IsCompliant = $false return $result } Connect-IfNeeded try { $webApps = Get-AzWebApp -ErrorAction SilentlyContinue if (-not $webApps) { $result.Details += "Geen App Services gevonden in de huidige context." $result.IsCompliant = $true return $result } $webApps = @($webApps) $result.TotalResources = $webApps.Count foreach ($app in $webApps) { Write-Verbose "Analyseren van App Service: $($app.Name)" $info = Get-AppServiceConfigurationInfo -WebApp $app $appIssues = @() if (-not $info.HttpsOnly) { $appIssues += "HTTPS-only is niet ingeschakeld" $result.MissingHttpsOnly += $info } if (-not $info.MinTlsVersion -or $info.MinTlsVersion -lt 1.2) { $appIssues += "Minimale TLS-versie is lager dan 1.2 of niet ingesteld" } if (-not $info.HasManagedIdentity) { $appIssues += "Geen managed identity geconfigureerd (aanbevolen i.p.v. geheimen in code)" $result.MissingManagedId += $info } if (-not $info.EnvironmentTag -or -not $info.OwnerTag) { $tagInfo = @{ Name = $info.Name ResourceGroup = $info.ResourceGroup Environment = $info.EnvironmentTag Owner = $info.OwnerTag } $result.MissingTags += $tagInfo $appIssues += "Ontbrekende tags (Environment en/of Owner)" } if ($appIssues.Count -eq 0) { $result.CompliantCount++ $result.Details += "✓ App Service '$($info.Name)' voldoet aan de basiscontroles voor secure development practices." } else { $result.NonCompliantCount++ $issueText = $appIssues -join "; " $result.Details += "✗ App Service '$($info.Name)': $issueText (ResourceGroup: $($info.ResourceGroup))" } } $result.IsCompliant = ($result.NonCompliantCount -eq 0) if ($result.MissingHttpsOnly.Count -gt 0) { $result.Recommendations += "Schakel HTTPS-only in voor alle App Services om onbeveiligde HTTP-verkeer te voorkomen." } if ($result.MissingManagedId.Count -gt 0) { $result.Recommendations += "Configureer managed identities voor App Services en verplaats geheimen naar Key Vault." } if ($result.MissingTags.Count -gt 0) { $result.Recommendations += "Zorg dat alle App Services voorzien zijn van minimaal de tags 'Environment' en 'Owner' voor traceerbaarheid." } } catch { $result.Details += "Fout tijdens controle: $($_.Exception.Message)" Write-Error $_ } return $result } # ============================================================================ # FUNCTION: Invoke-Monitoring # ============================================================================ function Invoke-Monitoring { <# .SYNOPSIS Toont een leesbaar overzicht van de secure development controles. #> [CmdletBinding()] param() Write-Host "`nSecure Development Practices Monitoring" -ForegroundColor Cyan Write-Host "Nederlandse Baseline voor Veilige Cloud" -ForegroundColor Cyan Write-Host "=======================================" -ForegroundColor Cyan $result = Test-SecureDevelopmentPractices Write-Host "`nSamenvatting:" -ForegroundColor Yellow Write-Host (" Totaal App Services : {0}" -f $result.TotalResources) -ForegroundColor Cyan Write-Host (" Compliant : {0}" -f $result.CompliantCount) -ForegroundColor Green Write-Host (" Non-compliant : {0}" -f $result.NonCompliantCount) -ForegroundColor (if ($result.NonCompliantCount -gt 0) { "Yellow" } else { "Green" }) if ($result.Details) { Write-Host "`nDetails:" -ForegroundColor Yellow foreach ($d in $result.Details) { $c = if ($d -like "✓*") { "Green" } elseif ($d -like "✗*") { "Red" } else { "Gray" } Write-Host " $d" -ForegroundColor $c } } if ($result.Recommendations) { Write-Host "`nAanbevelingen:" -ForegroundColor Yellow foreach ($r in $result.Recommendations) { Write-Host " → $r" -ForegroundColor Cyan } } if ($result.IsCompliant) { Write-Host "`n✅ Alle gecontroleerde App Services voldoen aan de basisvoorwaarden voor secure development practices." -ForegroundColor Green } else { Write-Host "`n⚠️ Er zijn App Services waar basisvoorwaarden voor secure development ontbreken. Zie aanbevelingen voor vervolgstappen." -ForegroundColor Yellow } return $result } # ============================================================================ # MAIN # ============================================================================ try { if ($PSBoundParameters.ContainsKey('WhatIf') -and $WhatIf) { Write-Host "`n=== WHATIF MODE ===" -ForegroundColor Yellow Write-Host "Het script zou de volgende controles uitvoeren:" -ForegroundColor Yellow Write-Host " - Verbinding maken met Azure (indien nog niet verbonden)" -ForegroundColor Yellow Write-Host " - Alle App Services inventariseren in de huidige context" -ForegroundColor Yellow Write-Host " - Controleren op HTTPS-only, minimale TLS-versie, managed identities en basis-tags" -ForegroundColor Yellow Write-Host "===================`n" -ForegroundColor Yellow return } if ($Monitoring) { Invoke-Monitoring | Out-Null } else { # Standaard: retourneer alleen het object, zonder uitgebreide console-output. Test-SecureDevelopmentPractices } } catch { Write-Error ("Er is een fout opgetreden in {0}: {1}" -f $PolicyName, $_) exit 1 }

Risico zonder implementatie

Risico zonder implementatie
High: Zonder structurele secure development practices ontstaan applicaties waarvan het beveiligingsniveau volledig afhangt van individuele ontwikkelaars in plaats van een gecontroleerd proces. Kwetsbaarheden in code, onveilige open-source afhankelijkheden en gelekte secrets worden pas laat of helemaal niet ontdekt, waardoor Azure App Service-applicaties een aantrekkelijk doelwit worden voor aanvallers. Dit leidt tot een verhoogde kans op datalekken, dienstonderbrekingen en misbruik van API's, met directe impact op burgers en ketenpartners. Daarnaast kan de organisatie niet aantonen dat zij voldoet aan BIO, NIS2 en ISO 27001-verplichtingen rond beveiliging in de softwarelevenscyclus, waardoor auditors structurele tekortkomingen zullen constateren en toezichthouders kunnen ingrijpen.

Management Samenvatting

Secure development practices voor Azure App Service verankeren beveiliging in elke fase van de softwarelevenscyclus: van threat modeling en secure design, via code reviews, statische analyse, dependency- en secret scanning in CI/CD, tot monitoring en auditing in productie. Door deze aanpak worden kwetsbaarheden vroegtijdig ontdekt en opgelost, neemt de voorspelbaarheid en kwaliteit van releases toe en kan de organisatie aantonen dat zij voldoet aan relevante wet- en regelgeving en normen. Implementatie vraagt om een combinatie van procesinrichting, tooling en training (circa 180 uur initiële inspanning) maar levert een structurele risicoreductie op voor alle cloudapplicaties die onder de Nederlandse Baseline voor Veilige Cloud vallen.