BIO 12.01 ISO A.9.1

Veilig Applicatieontwerp Voor Azure Architectuur

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

💼 Management Samenvatting

Veilig applicatieontwerp vormt de fundamentele basis voor elke succesvolle cloudarchitectuur binnen Azure. In tegenstelling tot traditionele benaderingen waarbij beveiliging achteraf wordt toegevoegd, vereist moderne cloudarchitectuur dat beveiligingsprincipes vanaf het eerste ontwerp worden geïntegreerd in elke laag van de applicatiestack. Voor Nederlandse overheidsorganisaties betekent dit dat architecten, ontwikkelaars en security officers gezamenlijk verantwoordelijk zijn voor het creëren van een architectuur die niet alleen functioneel is, maar ook inherent veilig, schaalbaar en compliant met relevante wet- en regelgeving zoals de BIO, AVG en NIS2.

Aanbeveling
IMPLEMENT
Risico zonder
High
Risk Score
9/10
Implementatie
200u (tech: 80u)
Van toepassing op:
✓ Azure
✓ Cloud Architectuur
✓ Applicatieontwikkeling
✓ Security by Design

Zonder een fundamenteel veilig ontwerp ontstaan er architecturale zwakheden die later moeilijk of kostbaar zijn te herstellen. Veelvoorkomende problemen zijn applicaties die vertrouwen op perimeterbeveiliging alleen, waardoor een enkele compromittering leidt tot volledige toegang tot het systeem. Andere risico's omvatten onvoldoende scheiding tussen lagen, waardoor een kwetsbaarheid in de presentatielaag direct toegang geeft tot databases met gevoelige gegevens, of het ontbreken van defense-in-depth maatregelen waardoor een enkele beveiligingscontrole het falen betekent van de gehele beveiliging. Bovendien zien auditors regelmatig architecturen waarin authenticatie en autorisatie inconsistent zijn geïmplementeerd, logging en monitoring onvoldoende zijn ingericht voor forensisch onderzoek, en gegevens niet adequaat worden geclassificeerd en beschermd volgens hun gevoeligheid. Deze fundamentele ontwerpfouten leiden tot een verhoogd risico op datalekken, ongeautoriseerde toegang, serviceverstoringen en niet-naleving van compliance-vereisten. Voor organisaties die moeten voldoen aan de Baseline Informatiebeveiliging Overheid, de Algemene Verordening Gegevensbescherming en de NIS2 richtlijn is dit onacceptabel; deze frameworks vereisen expliciet dat beveiliging integraal onderdeel is van het ontwerpproces en dat risico's proactief worden geïdentificeerd en gemitigeerd.

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

Implementatie

Dit artikel beschrijft een compleet raamwerk voor veilig applicatieontwerp binnen Azure-omgevingen, specifiek gericht op de context van de Nederlandse Baseline voor Veilige Cloud. Het raamwerk combineert architecturale principes zoals defense-in-depth, least privilege, fail-secure defaults en security by design met concrete technische implementaties binnen Azure. We gaan in op het toepassen van threat modeling tijdens de ontwerpfase om potentiële aanvalsvectoren vroegtijdig te identificeren, het ontwerpen van gelaagde beveiligingsarchitecturen waarbij meerdere onafhankelijke beveiligingscontroles worden geïmplementeerd, en het implementeren van zero-trust principes waarbij geen enkele component automatisch wordt vertrouwd. Daarnaast behandelen we het correct ontwerpen van authenticatie- en autorisatiemechanismen, het implementeren van adequate logging en monitoring voor security events, het toepassen van dataclassificatie en encryptie op basis van gevoeligheid, en het ontwerpen van fouttolerante systemen die veilig falen zonder gevoelige informatie bloot te stellen. Het artikel bevat een PowerShell-script dat Azure-resources analyseert op basis van architecturale beveiligingsprincipes, zoals het controleren van netwerksegmentatie, het verifiëren van toegangsbeheerconfiguraties en het beoordelen van logging- en monitoring-instellingen, zodat organisaties kunnen aantonen dat hun architectuur voldoet aan de beveiligingsvereisten.

Fundamentele Beveiligingsprincipes voor Applicatieontwerp

Veilig applicatieontwerp begint met het begrijpen en toepassen van fundamentele beveiligingsprincipes die richting geven aan elke architecturale beslissing. Het eerste principe is defense-in-depth, ook wel gelaagde beveiliging genoemd. Dit principe stelt dat beveiliging nooit mag afhangen van een enkele controle, maar altijd moet bestaan uit meerdere onafhankelijke beveiligingslagen die elkaar aanvullen. In een Azure-architectuur betekent dit bijvoorbeeld dat netwerkbeveiliging via Network Security Groups wordt gecombineerd met applicatiebeveiliging via Web Application Firewalls, authenticatie via Azure Active Directory, autorisatie op applicatieniveau, en logging en monitoring voor detectie. Wanneer één laag faalt, blijven de andere lagen bescherming bieden, waardoor de totale beveiligingspostuur aanzienlijk wordt verbeterd. Voor Nederlandse overheidsorganisaties is dit essentieel omdat het voldoet aan de BIO-vereisten voor meervoudige beveiligingsmaatregelen en het risico op volledige compromittering bij een enkele kwetsbaarheid aanzienlijk reduceert.

Het principe van least privilege stelt dat elke component, gebruiker en service alleen de minimale rechten en toegang moet hebben die nodig zijn om zijn functie uit te voeren. In Azure-architecturen betekent dit dat virtuele machines, applicaties en services worden geconfigureerd met specifieke, beperkte rollen in plaats van brede beheerdersrechten. Azure Role-Based Access Control wordt gebruikt om toegang te beperken op basis van de specifieke taken die een gebruiker of service moet uitvoeren, en applicaties worden ontworpen met een duidelijke scheiding tussen verschillende functionaliteiten zodat een compromittering van één onderdeel niet automatisch toegang geeft tot alle andere onderdelen. Dit principe wordt ook toegepast op netwerkniveau, waarbij Network Security Groups en Azure Firewall worden gebruikt om alleen noodzakelijke netwerkverkeer toe te staan tussen verschillende subnetten en services. Door least privilege consistent toe te passen, wordt het aanvalsoppervlak geminimaliseerd en wordt de impact van een potentiële compromittering beperkt.

Security by design betekent dat beveiliging vanaf het eerste moment wordt meegenomen in het ontwerpproces, in plaats van achteraf te worden toegevoegd. Dit vereist dat architecten, ontwikkelaars en security officers vanaf de initiatiefase samenwerken om beveiligingsvereisten te identificeren, threat models op te stellen en beveiligingscontroles te ontwerpen. In de praktijk betekent dit dat tijdens architectuursessies expliciet wordt besproken welke gegevens worden verwerkt, welke dreigingen relevant zijn, welke compliance-vereisten van toepassing zijn, en hoe beveiliging wordt geïmplementeerd in elke laag van de architectuur. Security by design voorkomt dat beveiliging wordt gezien als een technische detail dat later kan worden opgelost, en zorgt ervoor dat beveiligingsbeslissingen worden genomen op basis van risicoanalyses en best practices in plaats van ad-hoc oplossingen. Voor organisaties die moeten voldoen aan de BIO en NIS2 is dit essentieel, omdat deze frameworks expliciet vereisen dat beveiliging integraal onderdeel is van het ontwerpproces en dat risico's proactief worden beheerd.

Het principe van fail-secure defaults stelt dat systemen in een veilige staat moeten verkeren wanneer zij falen of wanneer configuraties onduidelijk zijn. Dit betekent dat standaardinstellingen altijd de meest restrictieve beveiligingsinstellingen moeten hebben, en dat expliciete actie vereist is om minder veilige configuraties in te schakelen. In Azure betekent dit bijvoorbeeld dat nieuwe resources standaard geen openbare toegang hebben, dat encryptie standaard is ingeschakeld, dat logging standaard is geactiveerd, en dat alleen expliciet geautoriseerde gebruikers en services toegang hebben. Wanneer een component faalt of wanneer een configuratie ontbreekt, moet het systeem terugvallen op deze veilige standaardinstellingen in plaats van onbeveiligde modi. Dit principe voorkomt dat onbedoelde configuratiefouten leiden tot beveiligingslekken en zorgt ervoor dat systemen altijd in een verdedigbare staat verkeren, zelfs wanneer er fouten optreden in het beheerproces.

Zero Trust is een modern beveiligingsparadigma dat stelt dat geen enkele component, gebruiker of service automatisch moet worden vertrouwd, ongeacht de locatie of het netwerk waarvan toegang wordt verkregen. In plaats daarvan moet elke toegangspoging worden geverifieerd, geautoriseerd en gemonitord, ongeacht of deze afkomstig is van binnen of buiten het traditionele netwerkperimeter. In Azure-architecturen betekent dit dat applicaties worden ontworpen met de veronderstelling dat het netwerk gecompromitteerd kan zijn, en dat beveiliging wordt geïmplementeerd op applicatieniveau in plaats van alleen op netwerkniveau. Dit omvat het gebruik van sterke authenticatie voor alle gebruikers en services, het implementeren van microsegmentatie waarbij verschillende applicatiecomponenten worden geïsoleerd, het gebruik van end-to-end encryptie voor alle communicatie, en het continu monitoren en valideren van alle toegangspogingen. Zero Trust is bijzonder relevant voor cloudomgevingen waar traditionele netwerkperimeters niet langer bestaan, en het sluit aan bij de BIO-vereisten voor continue verificatie en monitoring van toegang tot informatie.

Threat Modeling in de Ontwerpfase

Threat modeling is een gestructureerde aanpak voor het identificeren, kwantificeren en adresseren van beveiligingsrisico's tijdens de ontwerpfase van een applicatie of systeem. In tegenstelling tot reactieve beveiligingsbenaderingen waarbij kwetsbaarheden worden geïdentificeerd nadat een systeem is gebouwd, stelt threat modeling organisaties in staat om potentiële bedreigingen proactief te identificeren en beveiligingscontroles te ontwerpen die deze bedreigingen mitigeren voordat de implementatie begint. Voor Azure-architecturen is threat modeling essentieel omdat cloudomgevingen unieke bedreigingen introduceren, zoals misbruik van gedeelde verantwoordelijkheid, onjuiste configuratie van cloudservices, en risico's gerelateerd aan identiteits- en toegangsbeheer. Door threat modeling structureel toe te passen, kunnen organisaties aantonen dat zij proactief risico's beheren, wat vereist is voor compliance met de BIO, NIS2 en andere relevante frameworks.

Het threat modeling proces begint met het creëren van een gedetailleerd diagram van de applicatiearchitectuur, inclusief alle componenten, gegevensstromen, externe afhankelijkheden en vertrouwensgrenzen. Voor Azure-applicaties betekent dit het documenteren van alle Azure-services die worden gebruikt, de manier waarop gegevens tussen services stromen, de authenticatie- en autorisatiemechanismen, en de integraties met externe systemen. Vervolgens worden voor elk component en elke gegevensstroom potentiële bedreigingen geïdentificeerd met behulp van gestructureerde methoden zoals STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege). Voor elke geïdentificeerde bedreiging wordt geanalyseerd wat de impact zou zijn als de bedreiging wordt gerealiseerd, wat de waarschijnlijkheid is dat de bedreiging optreedt, en welke beveiligingscontroles kunnen worden geïmplementeerd om het risico te mitigeren.

Een veelvoorkomende bedreiging in Azure-architecturen is onbevoegde toegang tot gegevens via gecompromitteerde identiteiten of onjuiste autorisatieconfiguraties. Dit kan worden gemitigeerd door het implementeren van multi-factor authenticatie, het gebruik van managed identities in plaats van gedeelde geheimen, het toepassen van least privilege access controls, en het implementeren van regelmatige toegangsreviews. Een andere belangrijke bedreiging is datalekken door onjuiste configuratie van opslagaccounts of databases, wat kan worden voorkomen door standaard encryptie in te schakelen, publieke toegang te blokkeren, en regelmatige security assessments uit te voeren. Denial of service-aanvallen kunnen worden gemitigeerd door het implementeren van rate limiting, het gebruik van Azure DDoS Protection, en het ontwerpen van schaalbare architecturen die automatisch kunnen reageren op verhoogde belasting.

Threat modeling moet een iteratief proces zijn dat wordt herhaald wanneer de architectuur significant verandert, nieuwe bedreigingen worden geïdentificeerd, of wanneer security incidents plaatsvinden die nieuwe inzichten opleveren. De resultaten van threat modeling moeten worden gedocumenteerd in een security architecture document dat beschrijft welke bedreigingen zijn geïdentificeerd, welke beveiligingscontroles zijn geïmplementeerd om deze bedreigingen te mitigeren, en welke resterende risico's zijn geaccepteerd met onderbouwing. Dit document vormt een essentieel onderdeel van de compliance-documentatie en kan worden gebruikt tijdens audits om aan te tonen dat beveiliging proactief wordt beheerd. Bovendien helpt threat modeling bij het prioriteren van beveiligingsinvesteringen door duidelijk te maken welke bedreigingen het grootste risico vormen en welke beveiligingscontroles de meeste waarde toevoegen.

Gelaagde Beveiligingsarchitectuur in Azure

Een gelaagde beveiligingsarchitectuur, ook wel defense-in-depth genoemd, implementeert meerdere onafhankelijke beveiligingscontroles op verschillende lagen van de applicatiestack. In Azure-omgevingen kan dit worden geïmplementeerd op verschillende niveaus: netwerkniveau, identiteitsniveau, applicatieniveau, gegevensniveau en beheerniveau. Elke laag biedt aanvullende bescherming, zodat wanneer één laag faalt, de andere lagen blijven beschermen tegen bedreigingen. Deze aanpak is essentieel voor het voldoen aan BIO-vereisten voor meervoudige beveiligingsmaatregelen en het minimaliseren van het risico op volledige compromittering bij een enkele kwetsbaarheid.

Op netwerkniveau wordt beveiliging geïmplementeerd via Azure Virtual Networks met Network Security Groups die inkomend en uitgaand verkeer filteren op basis van IP-adressen, poorten en protocollen. Azure Firewall of Network Virtual Appliances kunnen worden gebruikt voor geavanceerde netwerkbeveiliging, inclusief deep packet inspection, intrusion detection en prevention, en geavanceerde threat intelligence. Virtual Network peering en private endpoints worden gebruikt om communicatie tussen services te isoleren en te beveiligen, terwijl ExpressRoute of VPN-gateways worden gebruikt voor beveiligde connectiviteit met on-premises omgevingen. Network segmentation wordt toegepast om verschillende omgevingen en workloads te scheiden, waarbij productie-, test- en ontwikkelomgevingen worden geïsoleerd in verschillende subnetten of zelfs verschillende virtual networks.

Op identiteitsniveau wordt beveiliging geïmplementeerd via Azure Active Directory met multi-factor authenticatie, conditional access policies die toegang beperken op basis van gebruikerslocatie, apparaatstatus en risicofactoren, en privileged identity management voor het beheren van beheerdersaccounts. Managed identities worden gebruikt om services te authenticeren zonder het gebruik van gedeelde geheimen, en Azure Key Vault wordt gebruikt voor het veilig opslaan en beheren van certificaten, API-sleutels en andere geheimen. Role-based access control wordt toegepast op alle Azure-resources om toegang te beperken tot alleen wat nodig is voor specifieke taken, en regelmatige toegangsreviews worden uitgevoerd om te verifiëren dat gebruikers nog steeds de juiste toegang hebben.

Op applicatieniveau wordt beveiliging geïmplementeerd via Web Application Firewalls die beschermen tegen veelvoorkomende webaanvallen zoals SQL-injectie, cross-site scripting en andere OWASP Top 10-risico's. Applicaties worden ontworpen met inputvalidatie, output encoding, en secure coding practices om kwetsbaarheden te voorkomen. API Management wordt gebruikt voor het beheren, beveiligen en monitoren van API's, inclusief rate limiting, authenticatie en autorisatie. Application Insights en Azure Monitor worden gebruikt voor het detecteren van afwijkende gedragspatronen en potentiële beveiligingsincidenten. Code signing en secure deployment practices worden toegepast om te verzekeren dat alleen geautoriseerde en geverifieerde code wordt uitgerold naar productieomgevingen.

Op gegevensniveau wordt beveiliging geïmplementeerd via encryptie in transit en at rest. Azure Storage Services en Azure SQL Database bieden standaard encryptie, en Azure Key Vault wordt gebruikt voor het beheren van encryptiesleutels. Gegevensclassificatie wordt toegepast om gegevens te categoriseren op basis van gevoeligheid, en verschillende beveiligingsmaatregelen worden toegepast op basis van deze classificatie. Azure Information Protection en Azure Purview worden gebruikt voor het labelen, classificeren en beschermen van gevoelige gegevens. Back-ups worden regelmatig gemaakt en getest om te verzekeren dat gegevens kunnen worden hersteld in geval van verlies of corruptie, en back-ups worden versleuteld en opgeslagen op veilige locaties.

Op beheerniveau wordt beveiliging geïmplementeerd via Azure Policy voor het afdwingen van organisatiebrede beveiligingsstandaarden, Azure Blueprints voor het standaardiseren van omgevingen, en Azure Security Center voor het continu monitoren en beoordelen van de beveiligingspostuur. Logging en monitoring worden geïmplementeerd op alle lagen om beveiligingsgebeurtenissen te detecteren en te onderzoeken, en Security Information and Event Management oplossingen zoals Azure Sentinel worden gebruikt voor geavanceerde threat detection en response. Regelmatige security assessments en penetration tests worden uitgevoerd om de effectiviteit van beveiligingscontroles te verifiëren en nieuwe kwetsbaarheden te identificeren.

Authenticatie en Autorisatie Architectuur

Authenticatie en autorisatie vormen de hoeksteen van beveiliging in elke applicatiearchitectuur. Authenticatie verifieert de identiteit van gebruikers en services, terwijl autorisatie bepaalt welke acties geauthenticeerde entiteiten mogen uitvoeren. In Azure-omgevingen worden deze mechanismen geïmplementeerd via Azure Active Directory en aanvullende Azure-services, waarbij moderne protocollen zoals OAuth 2.0, OpenID Connect en SAML worden gebruikt voor veilige authenticatie. Voor Nederlandse overheidsorganisaties is het essentieel dat authenticatie- en autorisatie-architecturen voldoen aan de BIO-vereisten voor toegangsbeheer en de AVG-vereisten voor gegevensbescherming.

Authenticatie-architectuur begint met het correct configureren van Azure Active Directory als de centrale identiteitsprovider. Alle gebruikers en services worden beheerd via Azure AD, waarbij single sign-on wordt geïmplementeerd om gebruikerservaring te verbeteren en beveiliging te versterken door het elimineren van meerdere wachtwoorden. Multi-factor authenticatie wordt verplicht gesteld voor alle gebruikers, met name voor beheerdersaccounts en accounts met toegang tot gevoelige gegevens. Conditional Access policies worden geconfigureerd om toegang te beperken op basis van verschillende factoren, zoals gebruikerslocatie, apparaatstatus, applicatierisico en gebruikersrisico. Deze policies kunnen bijvoorbeeld vereisen dat gebruikers alleen toegang hebben vanaf vertrouwde netwerken, dat alleen beheerde en compatibele apparaten toegang hebben, en dat aanvullende verificatie wordt vereist voor risicovolle activiteiten.

Voor service-to-service authenticatie worden managed identities gebruikt in plaats van gedeelde geheimen of API-sleutels. Managed identities elimineren de noodzaak om credentials op te slaan in code of configuratiebestanden, wat het risico op compromittering aanzienlijk reduceert. Wanneer managed identities niet beschikbaar zijn, worden service principals gebruikt met certificaten die worden opgeslagen in Azure Key Vault. Azure Key Vault wordt gebruikt voor het veilig opslaan en beheren van alle geheimen, inclusief wachtwoorden, API-sleutels, certificaten en connection strings. Toegang tot Key Vault wordt gecontroleerd via Azure RBAC en Key Vault access policies, en alle toegang wordt gelogd voor auditdoeleinden.

Autorisatie-architectuur wordt geïmplementeerd op meerdere niveaus: op Azure-resourceniveau via Role-Based Access Control, op applicatieniveau via op rollen gebaseerde of op claims gebaseerde autorisatie, en op gegevensniveau via row-level security en dynamic data masking. Azure RBAC wordt gebruikt om toegang tot Azure-resources te beheren, waarbij gebruikers en services worden toegewezen aan specifieke rollen die alleen de benodigde rechten bevatten. Custom roles worden gemaakt wanneer standaardrollen niet voldoen aan specifieke vereisten, en regelmatige toegangsreviews worden uitgevoerd om te verifiëren dat gebruikers nog steeds de juiste toegang hebben. Op applicatieniveau wordt autorisatie geïmplementeerd via claims-based autorisatie waarbij applicaties beslissingen nemen op basis van claims die zijn opgenomen in tokens die zijn uitgegeven door Azure AD. Deze claims kunnen informatie bevatten over gebruikersrollen, afdelingen, of andere attributen die relevant zijn voor autorisatiebeslissingen.

Gegevensniveau autorisatie wordt geïmplementeerd via row-level security in Azure SQL Database, waarbij gebruikers alleen toegang hebben tot rijen die voldoen aan specifieke criteria, en via dynamic data masking om gevoelige gegevens te verbergen voor gebruikers die geen volledige toegang nodig hebben. Azure Information Protection wordt gebruikt voor het labelen en classificeren van gegevens, en Azure Purview wordt gebruikt voor het beheren van gegevensrechten en toegangsbeleid. Alle autorisatiebeslissingen worden gelogd voor auditdoeleinden, en regelmatige reviews worden uitgevoerd om te verifiëren dat autorisatieconfiguraties correct zijn en dat er geen overbodige toegang is verleend.

Monitoring en Logging voor Beveiliging

Gebruik PowerShell-script secure-application-design.ps1 (functie Invoke-Monitoring) – Analyseert Azure-resources op basis van architecturale beveiligingsprincipes, inclusief netwerksegmentatie, toegangsbeheer en logging-configuraties.

Effectieve monitoring en logging zijn essentieel voor het detecteren, onderzoeken en reageren op beveiligingsincidenten. In Azure-omgevingen worden monitoring en logging geïmplementeerd via Azure Monitor, Log Analytics, Azure Security Center en Azure Sentinel, waarbij alle beveiligingsrelevante gebeurtenissen worden vastgelegd en geanalyseerd. Voor Nederlandse overheidsorganisaties is dit essentieel voor het voldoen aan BIO-vereisten voor logging en monitoring, AVG-vereisten voor gegevensbescherming, en NIS2-vereisten voor incidentdetectie en -response.

Logging-architectuur begint met het inschakelen van diagnostische logging voor alle Azure-services en resources. Activity Logs worden gebruikt voor het vastleggen van beheeracties op Azure-resources, zoals het maken, wijzigen of verwijderen van resources. Resource Logs worden gebruikt voor het vastleggen van operationele gebeurtenissen binnen resources, zoals authenticatiepogingen, API-aanroepen en fouten. Alle logs worden verzameld in een centrale Log Analytics workspace, waar zij kunnen worden opgeslagen voor langere perioden en geanalyseerd met behulp van KQL-queries. Log retention policies worden geconfigureerd op basis van compliance-vereisten, waarbij logs voor kritieke systemen worden bewaard voor minimaal zeven jaar in overeenstemming met Nederlandse archiefwetgeving.

Security monitoring wordt geïmplementeerd via Azure Security Center, dat continu de beveiligingspostuur van Azure-resources beoordeelt en waarschuwingen genereert wanneer beveiligingsproblemen worden gedetecteerd. Azure Sentinel wordt gebruikt als Security Information and Event Management oplossing voor geavanceerde threat detection, waarbij machine learning en analytics worden gebruikt om afwijkende gedragspatronen te identificeren en potentiële beveiligingsincidenten te detecteren. Custom detection rules worden geconfigureerd op basis van organisatiespecifieke bedreigingen en risico's, en playbooks worden geautomatiseerd voor het reageren op veelvoorkomende beveiligingsincidenten. Integraties met externe threat intelligence feeds worden gebruikt om up-to-date informatie te krijgen over bekende bedreigingen en aanvalspatronen.

Het PowerShell-script dat bij dit artikel hoort, analyseert Azure-resources op basis van architecturale beveiligingsprincipes. Het script controleert of netwerksegmentatie correct is geïmplementeerd door te verifiëren dat resources zijn georganiseerd in verschillende subnetten of virtual networks, of Network Security Groups zijn geconfigureerd, en of private endpoints worden gebruikt waar mogelijk. Het script verifieert ook toegangsbeheerconfiguraties door te controleren of RBAC correct is geconfigureerd, of managed identities worden gebruikt in plaats van gedeelde geheimen, en of Key Vault correct is geconfigureerd voor het beheren van geheimen. Daarnaast beoordeelt het script logging- en monitoring-instellingen door te verifiëren dat diagnostische logging is ingeschakeld voor alle resources, dat logs worden verzameld in een centrale Log Analytics workspace, en dat Security Center is ingeschakeld voor alle subscriptions. De resultaten van het script kunnen worden gebruikt om verbeteracties te prioriteren en om compliance te demonstreren tijdens audits.

Remediatie van Architecturale Beveiligingsproblemen

Gebruik PowerShell-script secure-application-design.ps1 (functie Invoke-Remediation) – Genereert aanbevelingen voor het verbeteren van architecturale beveiligingsconfiguraties op basis van monitoringresultaten.

Wanneer monitoring en assessments architecturale beveiligingsproblemen identificeren, is het essentieel om deze problemen gestructureerd aan te pakken via een remediatieproces. Dit proces begint met het prioriteren van bevindingen op basis van risico-impact, waarbij kritieke problemen die direct kunnen leiden tot datalekken of serviceverstoringen de hoogste prioriteit krijgen. Voor elke bevinding wordt een remediatieplan opgesteld dat beschrijft welke wijzigingen moeten worden doorgevoerd, welke resources worden beïnvloed, en wat de verwachte impact is op beschikbaarheid en functionaliteit.

Remediatie van architecturale problemen vereist vaak wijzigingen aan meerdere lagen van de architectuur. Bijvoorbeeld, wanneer netwerksegmentatie onvoldoende is, kunnen Network Security Groups moeten worden geconfigureerd, subnetten moeten worden herorganiseerd, of private endpoints moeten worden geïmplementeerd. Wanneer toegangsbeheer onvoldoende is, kunnen RBAC-rollen moeten worden aangepast, managed identities moeten worden geïmplementeerd, of Key Vault-configuraties moeten worden verbeterd. Het is belangrijk dat deze wijzigingen worden getest in een testomgeving voordat zij worden toegepast in productie, en dat wijzigingen worden gedocumenteerd en gecommuniceerd naar relevante stakeholders.

Het PowerShell-script dat bij dit artikel hoort, kan worden gebruikt om aanbevelingen te genereren voor het verbeteren van architecturale beveiligingsconfiguraties. Het script analyseert de huidige configuratie en vergelijkt deze met best practices en compliance-vereisten, en genereert specifieke aanbevelingen voor verbetering. Deze aanbevelingen kunnen worden gebruikt als input voor remediatieplannen en kunnen worden geïntegreerd in bestaande change management processen. Door remediatie gestructureerd aan te pakken en te documenteren, kunnen organisaties aantonen dat zij proactief werken aan het verbeteren van hun beveiligingspostuur en het voldoen aan compliance-vereisten.

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 Veilig Applicatieontwerp voor Azure Architectuur .DESCRIPTION Analyseert Azure-resources op basis van architecturale beveiligingsprincipes, inclusief: - Netwerksegmentatie en isolatie - Toegangsbeheerconfiguraties (RBAC, managed identities) - Logging- en monitoring-instellingen - Key Vault-configuraties voor geheimenbeheer - Network Security Groups en firewall-regels Dit script is bedoeld als ondersteunende monitoring voor het artikel 'Veilig Applicatieontwerp voor Azure Architectuur' en geeft architecten, security officers en beheerteams inzicht in waar de architecturale beveiligingsconfiguratie nog versterkt moet worden. .NOTES Filename: secure-application-design.ps1 Author: Nederlandse Baseline voor Veilige Cloud Created: 2025-01-15 Last Modified: 2025-01-15 Version: 1.0 Related JSON: content/azure/architecture/secure-application-design.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. .PARAMETER Remediation Genereert aanbevelingen voor het verbeteren van architecturale beveiligingsconfiguraties. .EXAMPLE .\secure-application-design.ps1 Voert een basiscontrole uit en retourneert een object met resultaten. .EXAMPLE .\secure-application-design.ps1 -Monitoring Toont een leesbaar overzicht in de console. .EXAMPLE .\secure-application-design.ps1 -Remediation Genereert specifieke aanbevelingen voor verbetering. #> # ============================================================================ # REQUIREMENTS # ============================================================================ #Requires -Version 5.1 #Requires -Modules Az.Accounts #Requires -Modules Az.Resources #Requires -Modules Az.Network # ============================================================================ # PARAMETERS # ============================================================================ [CmdletBinding()] param( [Parameter()][switch]$WhatIf, [Parameter()][switch]$Monitoring, [Parameter()][switch]$Remediation ) # ============================================================================ # GLOBAL SETTINGS # ============================================================================ $ErrorActionPreference = 'Stop' $VerbosePreference = 'SilentlyContinue' $PolicyName = "Veilig Applicatieontwerp voor Azure Architectuur" # ============================================================================ # FUNCTION: Test-ModuleAvailability # ============================================================================ function Test-ModuleAvailability { <# .SYNOPSIS Controleert of vereiste Az-modules beschikbaar zijn. #> [CmdletBinding()] param() $requiredModules = @('Az.Accounts', 'Az.Resources', 'Az.Network') $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: Test-NetworkSegmentation # ============================================================================ function Test-NetworkSegmentation { <# .SYNOPSIS Controleert netwerksegmentatie en isolatie. #> [CmdletBinding()] param() $findings = @() $compliant = $true try { $vnets = Get-AzVirtualNetwork -ErrorAction SilentlyContinue if (-not $vnets) { $findings += "Geen Virtual Networks gevonden" return @{ IsCompliant = $false; Findings = $findings } } foreach ($vnet in $vnets) { $subnets = Get-AzVirtualNetworkSubnetConfig -VirtualNetwork $vnet -ErrorAction SilentlyContinue if ($subnets.Count -lt 2) { $findings += "Virtual Network '$($vnet.Name)' heeft minder dan 2 subnetten - segmentatie kan worden verbeterd" $compliant = $false } foreach ($subnet in $subnets) { $nsg = Get-AzNetworkSecurityGroup -ResourceGroupName $vnet.ResourceGroupName -Name $subnet.NetworkSecurityGroup.Id.Split('/')[-1] -ErrorAction SilentlyContinue if (-not $nsg) { $findings += "Subnet '$($subnet.Name)' in VNet '$($vnet.Name)' heeft geen Network Security Group geconfigureerd" $compliant = $false } } } } catch { $findings += "Fout bij controle netwerksegmentatie: $_" $compliant = $false } return @{ IsCompliant = $compliant; Findings = $findings } } # ============================================================================ # FUNCTION: Test-AccessControl # ============================================================================ function Test-AccessControl { <# .SYNOPSIS Controleert toegangsbeheerconfiguraties. #> [CmdletBinding()] param() $findings = @() $compliant = $true try { # Controleer Key Vault configuraties $keyVaults = Get-AzKeyVault -ErrorAction SilentlyContinue if ($keyVaults) { foreach ($kv in $keyVaults) { $accessPolicies = Get-AzKeyVaultAccessPolicy -VaultName $kv.VaultName -ResourceGroupName $kv.ResourceGroupName -ErrorAction SilentlyContinue if (-not $accessPolicies -or $accessPolicies.Count -eq 0) { $findings += "Key Vault '$($kv.VaultName)' heeft geen access policies geconfigureerd" $compliant = $false } } } # Controleer op resources met publieke toegang $storageAccounts = Get-AzStorageAccount -ErrorAction SilentlyContinue if ($storageAccounts) { foreach ($sa in $storageAccounts) { $networkRules = Get-AzStorageAccountNetworkRuleSet -ResourceGroupName $sa.ResourceGroupName -Name $sa.StorageAccountName -ErrorAction SilentlyContinue if ($networkRules -and $networkRules.DefaultAction -eq 'Allow') { $findings += "Storage Account '$($sa.StorageAccountName)' staat publieke toegang toe (DefaultAction = Allow)" $compliant = $false } } } } catch { $findings += "Fout bij controle toegangsbeheer: $_" $compliant = $false } return @{ IsCompliant = $compliant; Findings = $findings } } # ============================================================================ # FUNCTION: Test-LoggingMonitoring # ============================================================================ function Test-LoggingMonitoring { <# .SYNOPSIS Controleert logging- en monitoring-instellingen. #> [CmdletBinding()] param() $findings = @() $compliant = $true try { # Controleer Log Analytics Workspaces $workspaces = Get-AzOperationalInsightsWorkspace -ErrorAction SilentlyContinue if (-not $workspaces -or $workspaces.Count -eq 0) { $findings += "Geen Log Analytics Workspaces gevonden - centrale logging ontbreekt" $compliant = $false } # Controleer Activity Log diagnostische instellingen $subscriptions = Get-AzSubscription -ErrorAction SilentlyContinue foreach ($sub in $subscriptions) { Set-AzContext -SubscriptionId $sub.Id | Out-Null $diagSettings = Get-AzDiagnosticSetting -ResourceId "/subscriptions/$($sub.Id)" -ErrorAction SilentlyContinue if (-not $diagSettings) { $findings += "Subscription '$($sub.Name)' heeft geen diagnostische instellingen voor Activity Log" $compliant = $false } } } catch { $findings += "Fout bij controle logging en monitoring: $_" $compliant = $false } return @{ IsCompliant = $compliant; Findings = $findings } } # ============================================================================ # FUNCTION: Test-SecureApplicationDesign # ============================================================================ function Test-SecureApplicationDesign { <# .SYNOPSIS Voert architecturale beveiligingscontroles uit. .OUTPUTS PSCustomObject met samenvatting en details. #> [CmdletBinding()] param() $result = [PSCustomObject]@{ ScriptName = "secure-application-design" PolicyName = $PolicyName IsCompliant = $false NetworkSegmentation = $null AccessControl = $null LoggingMonitoring = $null Details = @() 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." $result.IsCompliant = $false return $result } Connect-IfNeeded try { # Test netwerksegmentatie Write-Verbose "Controleren netwerksegmentatie..." $networkResult = Test-NetworkSegmentation $result.NetworkSegmentation = $networkResult if (-not $networkResult.IsCompliant) { $result.Details += "Netwerksegmentatie: Niet compliant" $result.Details += $networkResult.Findings } else { $result.Details += "Netwerksegmentatie: Compliant" } # Test toegangsbeheer Write-Verbose "Controleren toegangsbeheer..." $accessResult = Test-AccessControl $result.AccessControl = $accessResult if (-not $accessResult.IsCompliant) { $result.Details += "Toegangsbeheer: Niet compliant" $result.Details += $accessResult.Findings } else { $result.Details += "Toegangsbeheer: Compliant" } # Test logging en monitoring Write-Verbose "Controleren logging en monitoring..." $loggingResult = Test-LoggingMonitoring $result.LoggingMonitoring = $loggingResult if (-not $loggingResult.IsCompliant) { $result.Details += "Logging en monitoring: Niet compliant" $result.Details += $loggingResult.Findings } else { $result.Details += "Logging en monitoring: Compliant" } # Bepaal overall compliance $result.IsCompliant = $networkResult.IsCompliant -and $accessResult.IsCompliant -and $loggingResult.IsCompliant # Genereer aanbevelingen if (-not $networkResult.IsCompliant) { $result.Recommendations += "Implementeer netwerksegmentatie door Virtual Networks te organiseren in meerdere subnetten met Network Security Groups" $result.Recommendations += "Gebruik private endpoints waar mogelijk om publieke toegang te voorkomen" } if (-not $accessResult.IsCompliant) { $result.Recommendations += "Configureer Key Vault access policies voor alle Key Vaults" $result.Recommendations += "Schakel publieke toegang uit voor Storage Accounts en gebruik private endpoints" $result.Recommendations += "Gebruik managed identities in plaats van gedeelde geheimen waar mogelijk" } if (-not $loggingResult.IsCompliant) { $result.Recommendations += "Richt een centrale Log Analytics Workspace in voor alle resources" $result.Recommendations += "Schakel diagnostische instellingen in voor Activity Logs op alle subscriptions" $result.Recommendations += "Configureer Azure Security Center voor continue monitoring van de beveiligingspostuur" } } 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 architecturale beveiligingscontroles. #> [CmdletBinding()] param() Write-Host "`nVeilig Applicatieontwerp Monitoring" -ForegroundColor Cyan Write-Host "Nederlandse Baseline voor Veilige Cloud" -ForegroundColor Cyan Write-Host "======================================" -ForegroundColor Cyan $result = Test-SecureApplicationDesign Write-Host "`nSamenvatting:" -ForegroundColor Yellow $networkStatus = if ($result.NetworkSegmentation.IsCompliant) { "✓ Compliant" } else { "✗ Niet compliant" } $accessStatus = if ($result.AccessControl.IsCompliant) { "✓ Compliant" } else { "✗ Niet compliant" } $loggingStatus = if ($result.LoggingMonitoring.IsCompliant) { "✓ Compliant" } else { "✗ Niet compliant" } Write-Host (" Netwerksegmentatie : {0}" -f $networkStatus) -ForegroundColor (if ($result.NetworkSegmentation.IsCompliant) { "Green" } else { "Red" }) Write-Host (" Toegangsbeheer : {0}" -f $accessStatus) -ForegroundColor (if ($result.AccessControl.IsCompliant) { "Green" } else { "Red" }) Write-Host (" Logging en monitoring: {0}" -f $loggingStatus) -ForegroundColor (if ($result.LoggingMonitoring.IsCompliant) { "Green" } else { "Red" }) if ($result.Details) { Write-Host "`nDetails:" -ForegroundColor Yellow foreach ($d in $result.Details) { $c = if ($d -like "*Compliant*") { "Green" } elseif ($d -like "*Niet compliant*" -or $d -like "*ontbreekt*" -or $d -like "*geen*") { "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✅ Architecturale beveiligingsconfiguratie voldoet aan de basisvereisten." -ForegroundColor Green } else { Write-Host "`n⚠️ Er zijn architecturale beveiligingsproblemen geïdentificeerd. Zie aanbevelingen voor vervolgstappen." -ForegroundColor Yellow } return $result } # ============================================================================ # FUNCTION: Invoke-Remediation # ============================================================================ function Invoke-Remediation { <# .SYNOPSIS Genereert aanbevelingen voor het verbeteren van architecturale beveiligingsconfiguraties. #> [CmdletBinding()] param() Write-Host "`nRemediatie: Veilig Applicatieontwerp" -ForegroundColor Cyan Write-Host "Nederlandse Baseline voor Veilige Cloud" -ForegroundColor Cyan Write-Host "======================================" -ForegroundColor Cyan $result = Test-SecureApplicationDesign Write-Host "`nRemediatieplan op basis van bevindingen:" -ForegroundColor Yellow if ($result.Recommendations.Count -gt 0) { $priority = 1 foreach ($rec in $result.Recommendations) { Write-Host "`n[$priority] $rec" -ForegroundColor Cyan $priority++ } Write-Host "`nOpmerking: Dit script genereert alleen aanbevelingen." -ForegroundColor Gray Write-Host "Implementeer wijzigingen via Azure Portal, Azure CLI of Infrastructure as Code." -ForegroundColor Gray } else { Write-Host "`n✅ Geen remediatie nodig - architectuur voldoet aan alle basisvereisten." -ForegroundColor Green } 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 " - Netwerksegmentatie controleren (Virtual Networks, Subnets, NSGs)" -ForegroundColor Yellow Write-Host " - Toegangsbeheer controleren (Key Vault, Storage Accounts)" -ForegroundColor Yellow Write-Host " - Logging en monitoring controleren (Log Analytics, Diagnostic Settings)" -ForegroundColor Yellow Write-Host "===================`n" -ForegroundColor Yellow return } if ($Remediation) { Invoke-Remediation | Out-Null } elseif ($Monitoring) { Invoke-Monitoring | Out-Null } else { # Standaard: retourneer alleen het object, zonder uitgebreide console-output. Test-SecureApplicationDesign } } catch { Write-Error ("Er is een fout opgetreden in {0}: {1}" -f $PolicyName, $_) exit 1 }

Risico zonder implementatie

Risico zonder implementatie
High: Kritiek - Zonder fundamenteel veilig applicatieontwerp ontstaan architecturale zwakheden die leiden tot verhoogd risico op datalekken, ongeautoriseerde toegang, serviceverstoringen en niet-naleving van compliance-vereisten zoals BIO, AVG en NIS2.

Management Samenvatting

Implementeer veilig applicatieontwerp als fundamentele basis voor Azure-architecturen. Combineer defense-in-depth, least privilege, security by design en zero-trust principes met concrete technische implementaties. Voer threat modeling uit tijdens ontwerpfase, implementeer gelaagde beveiliging op alle niveaus, en zorg voor adequate logging en monitoring. Essentieel voor compliance met BIO, AVG en NIS2.