đź’Ľ 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.
âś“ 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.
Connection:
Connect-AzAccountRequired 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
- CIS M365: Control 4.1 (L1) - Bescherm publieke en interne applicaties met gestandaardiseerde beveiligingsmaatregelen, waaronder sterke authenticatie, versleutelde verbindingen en centrale logging.
- BIO: 12.03, 12.04, 13.01 - Zorgt voor veilige ontsluiting van informatiesystemen via internet en interne netwerken, met aandacht voor toegangsbeveiliging, logging, monitoring en mitigatie van kwetsbaarheden in applicaties.
- ISO 27001:2022: A.8.16, A.8.23, A.5.15 - Beveiliging van applicatiediensten via een combinatie van ontwerpprincipes, configuratiebeheer, monitoring en kwetsbaarheidsbehandeling.
- NIS2: Artikel - Draagt bij aan de vereiste technische en organisatorische maatregelen voor de beveiliging van netwerk‑ en informatiesystemen voor essentiële en belangrijke entiteiten.
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).
Risico zonder implementatie
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.
- Implementatietijd: 88 uur
- FTE required: 0.12 FTE