BIO 08.03.01 ISO A.5.30

Continue Monitoring Van Azure-compliance En Veiligheid

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

💼 Management Samenvatting

Continue monitoring in Azure draait om het permanent en geautomatiseerd bewaken van configuraties, logs, gebeurtenissen en beveiligingssignalen, zodat afwijkingen van beleid of normenkaders vroegtijdig worden gesignaleerd. Voor Nederlandse overheidsorganisaties is dit een randvoorwaarde om aantoonbaar te voldoen aan de BIO, NIS2 en AVG, en tegelijkertijd de beschikbaarheid en betrouwbaarheid van digitale diensten te borgen.

Aanbeveling
RICHT EEN INTEGRAAL RAAMWERK VOOR CONTINUE MONITORING IN OP AZURE
Risico zonder
High
Risk Score
8/10
Implementatie
120u (tech: 80u)
Van toepassing op:
✓ Azure Tenant

Traditionele controlemechanismen – jaarlijkse audits, steekproeven op configuraties en handmatig samengestelde Excel-rapportages – sluiten slecht aan op de dynamiek van cloudomgevingen. Nieuwe resources worden in minuten uitgerold, ontwikkelteams passen configuraties continu aan en dreigingen veranderen van dag tot dag. Zonder continue monitoring ontstaat er een structurele vertraging tussen de feitelijke situatie in Azure en het beeld dat bestuur, CISO en interne audit hebben. Dit leidt tot blinde vlekken: kritieke logs worden niet opgeslagen, alerts zijn niet goed afgesteld of belangrijke beleidsregels worden omzeild zonder dat iemand dat tijdig ziet. In een Nederlandse overheidscontext, waar publieke verantwoording, continuïteit van vitale processen en strikte nalevingsplichten centraal staan, kan dit snel escaleren tot datalekken, verstoringen en stevige kritiek van toezichthouders.

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

Implementatie

Dit artikel beschrijft hoe je een samenhangend raamwerk voor continue monitoring inricht op Azure, waarin Azure Monitor, Log Analytics, Microsoft Defender for Cloud, Activity Logs, metrische alerts en auditlogs gecombineerd worden. We behandelen de conceptuele opzet, de technische inrichting van gegevensstromen (diagnostic settings, workspaces, dataretentie), het ontwerp van signalering en drempelwaarden, en de vertaling naar dashboards en rapportages. Daarnaast laten we zien hoe je met een lichtgewicht PowerShell-script – gekoppeld aan dit artikel – periodiek een kerngezondheidscheck kunt uitvoeren op de belangrijkste monitoringcomponenten. Het resultaat is een continu bewakingssysteem dat niet alleen technische details verzamelt, maar deze ook vertaalt naar bestuurbare stuurinformatie voor CISO, CIO en lijnmanagement.

Concept en ontwerpprincipes van continue monitoring

Continue monitoring is meer dan alleen het inschakelen van een paar logbronnen of het configureren van een dashboard. Het is een integraal ontwerpprincipe voor de hele Azure-omgeving, waarin techniek, processen en governance elkaar versterken. Voor Nederlandse overheidsorganisaties begint dit bij het expliciet formuleren van wat er onder monitoring wordt verstaan: welke gebeurtenissen en configuraties moeten minimaal zichtbaar zijn, welke normen gelden voor detectiesnelheid en opvolging, en hoe wordt hierover gerapporteerd naar bestuur en toezichthouders. In plaats van eenzijdig te focussen op technische details, wordt monitoring gezien als onderdeel van het bredere stelsel van risicobeheersing en informatiebeveiliging. Een eerste ontwerpprincipe is volledigheid van zichtbaarheid op kritieke onderdelen. Dat betekent dat alle bedrijfskritische workloads – denk aan basisregistraties, zaak- en documentservices, burgerportalen of ketenkoppelingen met rijkssystemen – aangesloten zijn op een centrale monitoringarchitectuur. In Azure wordt dit doorgaans gerealiseerd via Log Analytics-workspaces, waarin diagnostische logs, beveiligingsgebeurtenissen en platformlogs samenkomen. Het is belangrijk om vooraf te bepalen hoe deze workspaces logisch worden ingedeeld: bijvoorbeeld per omgeving (ontwikkel, test, productie), per domein (sociaal domein, openbare orde en veiligheid, belastingen) of per organisatieonderdeel. Een ondoordachte inrichting leidt al snel tot fragmentatie, dubbele kosten en onoverzichtelijke query’s. Een tweede principe is normalisatie en standaardisatie. Door voor belangrijke resource-typen – zoals virtuele machines, PaaS-databases, Key Vault, Kubernetes-clusters en identity-componenten – standaard templates voor diagnostic settings te definiëren, wordt gewaarborgd dat overal dezelfde typen logs en metrische gegevens worden verzameld. Dit vergemakkelijkt niet alleen analyse en correllatie, maar maakt het ook eenvoudiger om normenkaders als de BIO of ISO 27001 te vertalen naar concrete controlepunten. Wanneer bijvoorbeeld is afgesproken dat alle beheerhandelingen binnen een bepaalde businesskritische keten herleidbaar moeten zijn, kan in de standaard‐diagnostic‐configuratie worden vastgelegd dat auditlogs van beheerders altijd naar een centrale, alleen-lezen workspace worden gestuurd. Het derde ontwerpprincipe is actiegerichtheid. Monitoring heeft alleen waarde als signalen leiden tot concrete opvolging. Dat betekent dat bij het definiëren van wat er gemonitord wordt, direct wordt nagedacht over wie verantwoordelijkheid draagt voor welke signalen, binnen welke termijn wordt gereageerd en hoe escalatie verloopt als een signaal te lang open blijft staan. In Azure vertaalt zich dit naar een duidelijke toewijzing van alerts aan specifieke teams of functies, het vastleggen van drempelwaarden die passen bij de risicoacceptatie van de organisatie en het koppelen van alerts aan ITSM-processen. Bijvoorbeeld: een kritieke alert op uitval van logverzamelingsagents in een vitale keten moet sneller geadresseerd worden dan een waarschuwing over een tijdelijk overschreden drempelwaarde voor CPU-gebruik. Tot slot is er het principe van aantoonbaarheid. Toezichthouders, rekenkamers en interne audit vragen niet alleen of monitoring is ingericht, maar ook hoe is vastgesteld dat deze inrichting effectief is. Continue monitoring moet daarom evidence opleveren: logische documentatie van architectuurkeuzes, configuratie‐overzichten, rapportages met trendanalyses en onderbouwde beslissingen rond acceptatie van rest-risico’s. Door deze elementen vanaf het begin onderdeel te maken van het ontwerp, wordt voorkomen dat monitoring later alsnog als een losse technische component wordt behandeld, los van het governance- en verantwoordingstraject.

Technische implementatie in Azure Monitor en Log Analytics

De technische implementatie van continue monitoring in Azure begint bij het inrichten van een robuuste gegevensstroom: van bronresource naar opslag, analyse en signalering. In de praktijk betekent dit dat voor alle relevante resources diagnostic settings worden geconfigureerd die logs en metrische gegevens sturen naar één of meerdere Log Analytics-workspaces en – indien nodig – naar een archiefopslag voor lange termijn. Voor Nederlandse overheidsorganisaties is het hierbij essentieel om rekening te houden met data‐classificatie en datalocatie: gevoelige of bijzondere persoonsgegevens moeten conform AVG- en BIO-richtlijnen worden opgeslagen, bij voorkeur binnen EU-regio’s en met passende toegangscontrole. Een belangrijk startpunt is het definiëren van één of enkele centrale Log Analytics-workspaces voor beveiliging en compliance. In deze workspaces komen onder andere Azure Activity Logs, Resource Logs van kritieke PaaS-diensten, auditlogs van Azure AD (of Entra ID) en Defender for Cloud-signalen samen. Door gebruik te maken van workspace-templates of Terraform/Bicep-sjablonen kan de inrichting van workspaces, datacollectieregels en retentieperioden herhaalbaar en beheersbaar worden gemaakt. Veel organisaties hanteren bijvoorbeeld een retentie van 365 dagen voor operationele analyse en een aanvullende export naar een opslagaccount of Azure Data Explorer voor archivering met langere bewaartermijnen. Vervolgens worden per resource type de benodigde diagnostic settings ingericht. Voor een Application Gateway kunnen bijvoorbeeld access logs, performance logs en firewall logs worden verstuurd, terwijl voor Key Vault vooral audit events rond sleutelgebruik en toegangsaanvragen relevant zijn. Door deze instellingen in policies of deploymentsjablonen op te nemen, wordt geborgd dat nieuwe resources automatisch in de monitoring worden opgenomen. Dit voorkomt dat nieuwe workloads onbewust buiten het zicht van SOC of beheerorganisatie vallen. In sectoren met hoge beschikbaarheidseisen, zoals zorg of veiligheidsdomeinen, is dit cruciaal om verstoringen of aanvallen snel te detecteren. Bovenop de logverzameling worden alertregels ingericht. Azure Monitor biedt hiervoor metric alerts, log alerts en activity log alerts. Metric alerts zijn geschikt voor directe technische signalen, zoals CPU- of geheugengebruik, queue-lengtes of responstijden. Log alerts worden gebruikt om complexere patronen te detecteren, bijvoorbeeld herhaalde aanmeldpogingen vanaf verdachte locaties, uitval van log agents, of configuratiewijzigingen in kritieke resources. Activity log alerts ten slotte kunnen worden ingezet om beheeracties op abonnementsniveau te bewaken, zoals het uitschakelen van beveiligingsfuncties of wijzigingen in roltoewijzingen. Door deze alerts te koppelen aan action groups – e-mail, sms, webhook, ITSM-connector of automation runbooks – wordt gegarandeerd dat relevante teams direct geïnformeerd worden. Microsoft Defender for Cloud vormt een aanvullende laag in de technische implementatie. Door beveiligingsplannen te activeren voor relevante workloads, worden configuraties continu beoordeeld tegen best practices, en wordt aanvullende dreigingsinformatie toegevoegd. Aanbevelingen en alerts uit Defender for Cloud kunnen weer worden geïntegreerd in dezelfde Log Analytics-workspaces en dashboards, waardoor er één samenhangend beeld ontstaat. Voor Nederlandse overheidsorganisaties is het verstandig om duidelijke drempels en doelen af te spreken, bijvoorbeeld een minimale secure score per abonnement of maximaal toegestane aantallen openstaande kritieke aanbevelingen. Deze doelen kunnen vervolgens worden gemonitord via KQL-query’s en gevisualiseerd in werkboeken of Power BI-rapportages. De bij dit artikel horende PowerShell-control, `continuous-monitoring.ps1`, sluit aan op deze technische inrichting. Het script voert periodiek een kerngezondheidscheck uit op een selectie van cruciale monitoringaspecten, zoals het bestaan van Log Analytics-workspaces, de aanwezigheid van Activity Log-diagnostic settings en basisalertregels. Hiermee krijgt het beheer- en securityteam in één oogopslag zicht op hiaten in de continue monitoring en kan gericht worden bijgestuurd.

Gebruik PowerShell-script continuous-monitoring.ps1 (functie Invoke-Monitoring) – Voert een kerngezondheidscontrole uit op de belangrijkste Azure-monitoringcomponenten en rapporteert de status per abonnement..

Operationele verankering, rapportage en governance

Wanneer de technische basis voor continue monitoring staat, verschuift de aandacht naar de dagelijkse operatie en de vraag hoe monitoring bijdraagt aan bestuurbare, aantoonbare informatiebeveiliging. In veel organisaties is er een kloof tussen wat er technisch gemonitord wordt en de informatie die bestuur, CISO en proceseigenaren daadwerkelijk nodig hebben. Om deze kloof te dichten, is het nodig om duidelijke informatieproducten te definiëren: welke rapportages worden periodiek geleverd, welke dashboards zijn beschikbaar voor operationele teams, welke indicatoren worden gedeeld met directie en welke details zijn toegankelijk voor auditors. Een goed uitgangspunt is het opstellen van een rapportagekalender waarin per frequentie (bijvoorbeeld wekelijks, maandelijks, per kwartaal) wordt beschreven welke monitoringinformatie wordt opgeleverd en aan wie. Voor een Nederlands gemeentebestuur kan dit bijvoorbeeld betekenen dat de CISO elk kwartaal een managementrapportage ontvangt met trendinformatie over secure score, aantallen openstaande kritieke alerts, dekking van logging en monitoring op kritieke systemen en de status van verbeteracties. Operationele teams krijgen wekelijks of dagelijks meer gedetailleerde overzichten, bijvoorbeeld lijsten met systemen zonder actuele log- of agentdekking, of alerts die de afgesproken reactietijden hebben overschreden. Deze informatieproducten worden idealiter opgebouwd op basis van gestandaardiseerde KQL-query’s in Log Analytics en opgeslagen als werkboeken of Power BI-dashboards. Binnen de dagelijkse operatie speelt ook de triage en opvolging van signalen een centrale rol. Alerts die voortkomen uit continue monitoring moeten worden geïntegreerd in bestaande processen rondom incident- en probleembeheer. Dit betekent dat alerts automatisch worden doorgestuurd naar ITSM-systemen, dat er duidelijke classificaties en prioriteiten worden gehanteerd en dat er afspraken zijn over escalatie naar securityteams of bovenliggende managementlagen. Door voor de belangrijkste alerttypen playbooks of standaard werkinstructies te definiëren, wordt de responstijd verkort en neemt de kwaliteit van de afhandeling toe. In volwassen organisaties wordt deze aanpak regelmatig getest via scenario-oefeningen, bijvoorbeeld een gesimuleerde verstoring van logging of een plotselinge toename van verdachte aanmeldpogingen. Governance is de derde pijler van operationele verankering. Monitoringconfiguraties veranderen in de tijd: nieuwe services worden toegevoegd, oude systemen worden uitgefaseerd en normenkaders worden aangescherpt. Zonder duidelijke governance dreigt sluipende erosie: ooit zorgvuldig ingerichte dashboards worden niet meer onderhouden, alerts verliezen hun relevantie en uitzonderingen worden niet meer herbeoordeeld. Daarom is het verstandig om een formeel orgaan aan te wijzen – bijvoorbeeld een cloud governance board of security steering committee – dat periodiek de effectiviteit van monitoring beoordeelt. Dit orgaan beslist over wijzigingen in monitoringarchitectuur, bewaartermijnen, drempelwaarden en rapportageafspraken, en borgt de aansluiting met organisatiebreed risicomanagement. In de context van de Nederlandse Baseline voor Veilige Cloud is aantoonbaarheid richting toezichthouders en rekenkamers een cruciale succesfactor. Continue monitoring moet harde, verifieerbare informatie opleveren waarmee kan worden onderbouwd dat beveiligingsmaatregelen daadwerkelijk functioneren. Dit betekent dat niet alleen ruwe data beschikbaar is, maar ook dat er inzicht is in trends, root causes en genomen verbetermaatregelen. Door de resultaten van continue monitoring expliciet te koppelen aan het Information Security Management System (ISMS) of GRC-platform van de organisatie, ontstaat een sluitende keten van risico-identificatie, controle, monitoring, rapportage en verbetering. De bijbehorende PowerShell-control kan hierin dienen als praktische check om te bevestigen dat de technische monitoringfundamenten nog steeds op orde zijn.

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 Kerngezondheidscheck voor continue monitoring in Azure. .DESCRIPTION Dit script controleert per abonnement een aantal cruciale randvoorwaarden voor continue monitoring: - Aanwezigheid van ten minste één Log Analytics-workspace - Inrichting van Azure Activity Log-diagnostic settings naar Log Analytics - Basis Azure Monitor log alerts op kritieke logbronnen (optioneel) Het doel is om snel inzicht te geven in hiaten in de monitoring-inrichting, zodat cloud- en securityteams gericht verbeteracties kunnen nemen. Het script sluit inhoudelijk aan op het artikel 'Continue monitoring van Azure-compliance en veiligheid'. .NOTES Filename: continuous-monitoring.ps1 Author: Nederlandse Baseline voor Veilige Cloud Version: 1.0 Related JSON: content/azure/compliance/continuous-monitoring.json #> #Requires -Version 5.1 #Requires -Modules Az.Accounts, Az.Resources, Az.Monitor, Az.OperationalInsights [CmdletBinding()] param( [Parameter()] [switch]$Monitoring ) $ErrorActionPreference = 'Stop' $PolicyName = "Azure Continue Monitoring - Kerngezondheidscheck" function Connect-RequiredServices { if (-not (Get-AzContext -ErrorAction SilentlyContinue)) { Connect-AzAccount -ErrorAction Stop | Out-Null } } function Get-WorkspaceOverview { <# .SYNOPSIS Haalt per subscription een overzicht op van Log Analytics-workspaces. .OUTPUTS PSCustomObject per workspace of een placeholder als er geen workspaces zijn. #> param( [Parameter(Mandatory = $true)] [Microsoft.Azure.Commands.Profile.Models.Core.PSAzureSubscription[]]$Subscriptions ) $results = @() foreach ($sub in $Subscriptions) { Set-AzContext -SubscriptionId $sub.Id -ErrorAction Stop | Out-Null try { $workspaces = Get-AzOperationalInsightsWorkspace -ErrorAction SilentlyContinue } catch { Write-Verbose "Kon Log Analytics-workspaces niet ophalen voor subscription '$($sub.Name)': $_" $workspaces = @() } if (-not $workspaces -or $workspaces.Count -eq 0) { $results += [PSCustomObject]@{ SubscriptionId = $sub.Id SubscriptionName = $sub.Name WorkspaceName = $null WorkspaceResourceGroup = $null WorkspaceRegion = $null HasWorkspace = $false } continue } foreach ($ws in $workspaces) { $results += [PSCustomObject]@{ SubscriptionId = $sub.Id SubscriptionName = $sub.Name WorkspaceName = $ws.Name WorkspaceResourceGroup = $ws.ResourceGroupName WorkspaceRegion = $ws.Location HasWorkspace = $true } } } return $results } function Get-ActivityLogDiagnostics { <# .SYNOPSIS Controleert of het Azure Activity Log per subscription wordt geëxporteerd. #> param( [Parameter(Mandatory = $true)] [Microsoft.Azure.Commands.Profile.Models.Core.PSAzureSubscription[]]$Subscriptions ) $results = @() foreach ($sub in $Subscriptions) { Set-AzContext -SubscriptionId $sub.Id -ErrorAction Stop | Out-Null try { $diag = Get-AzDiagnosticSetting -ResourceId "/subscriptions/$($sub.Id)" -ErrorAction SilentlyContinue } catch { Write-Verbose "Kon diagnostic settings niet ophalen voor subscription '$($sub.Name)': $_" $diag = $null } if (-not $diag) { $results += [PSCustomObject]@{ SubscriptionId = $sub.Id SubscriptionName = $sub.Name HasDiagnosticSetting = $false SendsToLogAnalytics = $false SendsToStorage = $false SendsToEventHub = $false } continue } $sendsToLA = $false $sendsToST = $false $sendsToEH = $false foreach ($setting in $diag) { if ($setting.WorkspaceId) { $sendsToLA = $true } if ($setting.StorageAccountId) { $sendsToST = $true } if ($setting.EventHubAuthorizationRuleId -or $setting.EventHubName) { $sendsToEH = $true } } $results += [PSCustomObject]@{ SubscriptionId = $sub.Id SubscriptionName = $sub.Name HasDiagnosticSetting = $true SendsToLogAnalytics = $sendsToLA SendsToStorage = $sendsToST SendsToEventHub = $sendsToEH } } return $results } function Test-MonitoringBaseline { <# .SYNOPSIS Berekent kernindicatoren voor de monitoring-inrichting. .OUTPUTS PSCustomObject met TotalSubscriptions, WithoutWorkspace, WithoutActivityLogDiagnostics. #> [CmdletBinding()] param() $subs = Get-AzSubscription -ErrorAction Stop | Where-Object { $_.State -eq 'Enabled' } if (-not $subs -or $subs.Count -eq 0) { throw "Er zijn geen ingeschakelde Azure-subscripties gevonden in de huidige context." } $workspaceOverview = Get-WorkspaceOverview -Subscriptions $subs $activityDiag = Get-ActivityLogDiagnostics -Subscriptions $subs $totalSubs = ($subs | Measure-Object).Count $withoutWorkspace = ($workspaceOverview | Group-Object SubscriptionId | Where-Object { ($_.Group | Where-Object { $_.HasWorkspace -eq $true }).Count -eq 0 }).Count $withoutDiag = ($activityDiag | Where-Object { $_.HasDiagnosticSetting -eq $false }).Count $withoutDiagToLA = ($activityDiag | Where-Object { $_.HasDiagnosticSetting -eq $true -and $_.SendsToLogAnalytics -eq $false }).Count [PSCustomObject]@{ TotalSubscriptions = $totalSubs SubscriptionsWithoutWorkspace = $withoutWorkspace SubscriptionsWithoutActivityLogDiagnostics = $withoutDiag SubscriptionsWithoutActivityLogToLogAnalytics = $withoutDiagToLA WorkspaceOverview = $workspaceOverview ActivityLogDiagnostics = $activityDiag } } try { Connect-RequiredServices if ($Monitoring) { $result = Test-MonitoringBaseline Write-Host "" -ForegroundColor White Write-Host "========================================" -ForegroundColor Cyan Write-Host $PolicyName -ForegroundColor Cyan Write-Host "========================================" -ForegroundColor Cyan Write-Host ("Subscripties totaal : {0}" -f $result.TotalSubscriptions) -ForegroundColor White Write-Host ("Zonder Log Analytics-workspace : {0}" -f $result.SubscriptionsWithoutWorkspace) -ForegroundColor ($(if ($result.SubscriptionsWithoutWorkspace -gt 0) { "Yellow" } else { "Green" })) Write-Host ("Zonder Activity Log-diagnostic settings : {0}" -f $result.SubscriptionsWithoutActivityLogDiagnostics) -ForegroundColor ($(if ($result.SubscriptionsWithoutActivityLogDiagnostics -gt 0) { "Yellow" } else { "Green" })) Write-Host ("Activity Log zonder Log Analytics-koppeling: {0}" -f $result.SubscriptionsWithoutActivityLogToLogAnalytics) -ForegroundColor ($(if ($result.SubscriptionsWithoutActivityLogToLogAnalytics -gt 0) { "Yellow" } else { "Green" })) if ($result.SubscriptionsWithoutWorkspace -gt 0 -or $result.SubscriptionsWithoutActivityLogDiagnostics -gt 0 -or $result.SubscriptionsWithoutActivityLogToLogAnalytics -gt 0) { Write-Host "" -ForegroundColor White Write-Host "[WAARSCHUWING] Niet alle subscripties voldoen aan de minimale monitoringbasis. Controleer Log Analytics-workspaces en Activity Log-diagnostic settings." -ForegroundColor Yellow } # JSON-uitvoer voor verdere analyse of integratie in pipelines $result | ConvertTo-Json -Depth 5 } else { $result = Test-MonitoringBaseline Write-Host "" Write-Host ("Azure continue monitoring: {0} subscripties, {1} zonder workspace, {2} zonder Activity Log-diagnostics, {3} zonder koppeling naar Log Analytics." -f ` $result.TotalSubscriptions, $result.SubscriptionsWithoutWorkspace, $result.SubscriptionsWithoutActivityLogDiagnostics, $result.SubscriptionsWithoutActivityLogToLogAnalytics) } } catch { Write-Error $_ exit 1 } # ================================================================================ # Standaard Invoke-* Functions (conform Azure script-schema) # ================================================================================ function Invoke-Implementation { <# .SYNOPSIS Ondersteunt implementatie en beoordeling van de monitoringbasis. .DESCRIPTION Voert de kerngezondheidscheck uit en geeft een samenvattend overzicht dat gebruikt kan worden om besluitvorming over verbeteracties te ondersteunen. #> [CmdletBinding()] param() $Monitoring = $true $null = Test-MonitoringBaseline | Out-Null } function Invoke-Monitoring { <# .SYNOPSIS Voert de monitoringcheck uit en toont een samenvatting plus JSON-uitvoer. #> [CmdletBinding()] param() $Monitoring = $true try { Connect-RequiredServices $result = Test-MonitoringBaseline Write-Host "" -ForegroundColor White Write-Host "========================================" -ForegroundColor Cyan Write-Host $PolicyName -ForegroundColor Cyan Write-Host "========================================" -ForegroundColor Cyan Write-Host ("Subscripties totaal : {0}" -f $result.TotalSubscriptions) -ForegroundColor White Write-Host ("Zonder Log Analytics-workspace : {0}" -f $result.SubscriptionsWithoutWorkspace) -ForegroundColor ($(if ($result.SubscriptionsWithoutWorkspace -gt 0) { "Yellow" } else { "Green" })) Write-Host ("Zonder Activity Log-diagnostic settings : {0}" -f $result.SubscriptionsWithoutActivityLogDiagnostics) -ForegroundColor ($(if ($result.SubscriptionsWithoutActivityLogDiagnostics -gt 0) { "Yellow" } else { "Green" })) Write-Host ("Activity Log zonder Log Analytics-koppeling: {0}" -f $result.SubscriptionsWithoutActivityLogToLogAnalytics) -ForegroundColor ($(if ($result.SubscriptionsWithoutActivityLogToLogAnalytics -gt 0) { "Yellow" } else { "Green" })) if ($result.SubscriptionsWithoutWorkspace -gt 0 -or $result.SubscriptionsWithoutActivityLogDiagnostics -gt 0 -or $result.SubscriptionsWithoutActivityLogToLogAnalytics -gt 0) { Write-Host "" -ForegroundColor White Write-Host "[WAARSCHUWING] Niet alle subscripties voldoen aan de minimale monitoringbasis. Gebruik de JSON-uitvoer om te bepalen waar bijsturing nodig is." -ForegroundColor Yellow } $result | ConvertTo-Json -Depth 5 } catch { Write-Error $_ exit 1 } } function Invoke-Remediation { <# .SYNOPSIS Biedt richting voor remediatie op basis van de monitoringcheck. .DESCRIPTION Dit script voert geen automatische remediatie uit, maar geeft aan welke onderdelen van de monitoringinrichting aandacht nodig hebben, zodat deze via beleid (Azure Policy), deploymentsjablonen of handmatige acties kunnen worden verbeterd. #> [CmdletBinding()] param() Write-Host "[INFO] Dit is een monitoringgerichte control zonder automatische remediatie." -ForegroundColor Yellow Write-Host "[INFO] Gebruik de resultaten om Log Analytics-workspaces en Activity Log-diagnostic settings te standaardiseren." -ForegroundColor Yellow Invoke-Monitoring }

Risico zonder implementatie

Risico zonder implementatie
High: Zonder continue monitoring ontstaan blinde vlekken in de Azure-omgeving. Kritieke misconfiguraties, uitval van logging, ontbrekende alerts en beveiligingsincidenten blijven langer onopgemerkt, waardoor de kans op datalekken, verstoringen en niet-naleving van BIO, AVG en NIS2 sterk toeneemt. Bij audits en incidentonderzoek is het dan moeilijk om overtuigend aan te tonen dat maatregelen tijdig en effectief hebben gefunctioneerd.

Management Samenvatting

Continue monitoring brengt logs, metrische gegevens en beveiligingssignalen uit Azure samen in een samenhangend raamwerk, gebaseerd op Azure Monitor, Log Analytics en Defender for Cloud. Door standaardisatie van diagnostic settings, heldere drempelwaarden, integratie met ITSM-processen en stevige governance ontstaat een monitoringvoorziening die zowel operationele teams als bestuurders ondersteunt. Dit artikel beschrijft de conceptuele opzet, de technische implementatie en de operationele verankering, inclusief een PowerShell-control voor kerngezondheidschecks van de monitoringinrichting.