BIO 12.04 ISO A.12.4.1

Log Analytics Security Logs: Centrale Beveiligingslogging Voor Azure-omgevingen

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

💼 Management Samenvatting

Log Analytics Security Logs vormen het fundament onder iedere moderne Azure-beveiligingsarchitectuur: zonder een centraal en betrouwbaar logplatform is geen enkel SOC, geen enkele audit en geen enkele forensische analyse echt effectief.

Aanbeveling
Richt één of meerdere Log Analytics-workspaces in als centrale hub voor beveiligingslogging en zorg dat alle kritieke Azure- en aanpalende workloads hun securitylogs daar gedurende minimaal 6–24 maanden aanleveren.
Risico zonder
High
Risk Score
8/10
Implementatie
12u (tech: 8u)
Van toepassing op:
✓ Azure

Veel Nederlandse overheidsorganisaties hebben wel ergens logs beschikbaar, maar niet op één plek, niet volledig en niet in een vorm die direct bruikbaar is voor dreigingsdetectie. Security-events worden verspreid opgeslagen in individuele resources, op servers of in applicatielogs, waardoor analisten tijdens een incident kostbare tijd verliezen met het verzamelen van losse fragmenten. In onderzoeken naar ransomware-incidenten en integriteitsbreuken bleek regelmatig dat cruciale gebeurtenissen – denk aan misbruik van privilege-rollen, verdachte Key Vault-toegangen of uitgaand verkeer naar command-and-control-domeinen – wel zijn vastgelegd, maar niet centraal doorzoekbaar waren op het moment dat het erom ging. Bovendien vereisen BIO, NIS2 en AVG dat beveiligingsrelevante gebeurtenissen reproduceerbaar kunnen worden geanalyseerd en dat de organisatie kan aantonen welke persoonsgegevens zijn geraakt. Zonder een Log Analytics-architectuur waarin security logs systematisch en langdurig worden opgeslagen, blijven deze verplichtingen grotendeels theoretisch. De impact is concreet: langere Mean Time To Detect, beperkte forensische diepgang en een sterk verhoogd risico dat auditors concluderen dat logging en monitoring niet volwassen zijn ingericht.

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

Implementatie

Deze maatregel beschrijft hoe je Log Analytics inricht als centrale beveiligingsloghub voor Azure en aanpalende workloads, met specifieke aandacht voor securityrelevante tabellen zoals SecurityEvent, AzureActivity, SigninLogs, AuditLogs en Defender-signalen. We behandelen hoe je diagnostic settings op schaal toepast, hoe je datastromen normaliseert en labelt, en hoe je bewaarbeleid afstemt op Nederlandse wet- en regelgeving. Vervolgens laten we zien hoe je de kwaliteit van de aangeleverde logs bewaakt, hoe je test of kritieke bronnen daadwerkelijk schrijven naar de juiste workspaces en hoe je rapportages opzet die aantonen dat de dekking op orde is. Het bijbehorende PowerShell-script log-analytics-security-logs.ps1 voert gerichte controles uit op de aanwezigheid van securitytabellen in Log Analytics-workspaces en levert een samenvattend beeld van de mate waarin security logging daadwerkelijk is geactiveerd.

Vereisten

Een robuuste inrichting van Log Analytics Security Logs start met een heldere scopebepaling: welke omgevingen, abonnementen en workloads vallen onder de verantwoordelijkheid van de organisatie en moeten daarom hun beveiligingslogs centraal afleveren? Voor een ministerie of grote uitvoeringsorganisatie betekent dit doorgaans alle productie- en preproductie-abonnementen, inclusief shared services zoals centrale identiteitsvoorzieningen, netwerk-hubs en key management. Zonder deze afbakening ontstaan ongedocumenteerde "schaduwlogboeken" waarin cruciale telemetrie ontbreekt. De eerste voorwaarde is daarom dat er een geautoriseerde lijst bestaat van alle relevante abonnementen en resourcegroepen, gekoppeld aan eigenaarschap, classificatie (bijvoorbeeld BBN2/BBN3) en Business Impact Analysis-resultaten. Deze lijst vormt de basis voor het bepalen welke logbronnen minimaal moeten worden aangesloten op Log Analytics.

Vervolgens zijn er technische randvoorwaarden aan de Log Analytics-workspaces zelf. Er moeten één of enkele centrale workspaces bestaan die expliciet zijn aangewezen als securitylog-hub, met een bewaartermijn die past bij de wettelijke en interne eisen – vaak minimaal 180 dagen voor operationele analyse en tussen 365 en 730 dagen voor audit en forensisch onderzoek. De workspaces worden beschermd met role-based access control zodat alleen SOC-analisten, security engineers en geautoriseerde auditors query-rechten hebben. Daarnaast moeten network access-beperkingen zijn ingeschakeld, bijvoorbeeld via private endpoints en IP-allowlists, om te voorkomen dat gevoelige logdata zomaar vanaf het internet kan worden benaderd. Zonder deze basisconfiguratie kan de organisatie niet geloofwaardig stellen dat security logs adequaat zijn beschermd.

Cruciaal is ook dat alle kernbronnen daadwerkelijk naar Log Analytics schrijven. Dit omvat ten minste Azure Activity Logs, administratieve en sign-in-logs uit Entra ID (via de Azure AD-diagnostische integratie), audit- en signaaldata uit Microsoft Defender for Cloud en Defender for Endpoint, relevante PaaS-diensten zoals Key Vault, Storage Accounts, App Service en SQL Database, en – waar van toepassing – on-premises of andere cloudbronnen via agents of Azure Arc. Voor elke resourcecategorie moet zijn vastgelegd welke logcategorieën (bijvoorbeeld Administrative, Policy, Security, Audit, ThreatProtection) naar welke workspace worden gestuurd. Deze mapping wordt vastgelegd in een datagovernanceregister zodat duidelijk is welke dreigingsscenario’s worden afgedekt en waar mogelijke blinde vlekken zitten. Een Log Analytics-omgeving zonder deze expliciete broninventarisatie is in de praktijk zelden compleet.

Naast technische inrichting spelen rechten en capaciteit een rol. Analisten hebben toegang nodig tot Kusto Query Language (KQL) en moeten getraind zijn in het schrijven van queries die over meerdere tabellen en tijdvensters heen zoeken naar patronen. De organisatie moet tooling beschikbaar stellen om query’s te delen en te versiebeheren – bijvoorbeeld via Git-repositories gekoppeld aan workbooks of notebooks – zodat kennis niet in persoonlijke profielen verdwijnt. Verder moeten afspraken bestaan over wie queries mag aanpassen die als bron dienen voor usecases in Sentinel, dashboards of managementrapportages. Deze governance voorkomt dat kritieke queries onbewust worden gewijzigd en dat de kwaliteit van detecties over tijd verwatert.

Tot slot is integratie met overige monitoringoplossingen een expliciete voorwaarde. In veel omgevingen fungeert Log Analytics als datalaag onder Microsoft Sentinel, Defender for Cloud, Azure Monitor en soms ook externe oplossingen zoals Splunk of QRadar. De inrichting van security logs moet daarom rekening houden met downstream-gebruik: retentie in Log Analytics mag niet korter zijn dan de forensische bewaarbehoefte uit het incident response-plan, en export- of replicatiemechanismen naar andere SIEM’s moeten worden gedocumenteerd en regelmatig getest. Zonder deze afstemming dreigt versnippering van data, dubbele opslagkosten en – belangrijker – inconsistentie tussen de cijfers die in audits of aan bestuurders worden gepresenteerd.

Implementatie

De implementatie van Log Analytics Security Logs verloopt idealiter in iteratieve stappen, beginnend met een kleinschalige pilot en eindigend in een volledig uitgerolde multi-abonnementsarchitectuur. In de eerste fase wordt een of enkele workspaces aangewezen als security-hub en worden bestaande datastromen in kaart gebracht. Met Azure Resource Graph en de Azure Portal wordt vastgesteld welke diagnostic settings al bestaan, naar welke bestemmingen zij schrijven (Storage, Event Hub, Log Analytics) en welke categorieën daarin zijn opgenomen. Op basis van deze nulmeting wordt bepaald welke bronnen direct kunnen worden aangesloten en waar aanvullende configuratie nodig is. In dezelfde fase worden naming conventions vastgelegd voor workspaces, resourcegroepen en data-collectie-regels zodat later duidelijk blijft welke configuraties tot het securitydomein behoren.

Daarna volgt het systematisch inschakelen van diagnostic settings voor kernresources. Voor Azure Activity Logs wordt per abonnement een centrale instelling geconfigureerd die alle eventcategorieën – inclusief Administrative, Policy en Security – naar de security-workspace stuurt. Key Vaults, Storage Accounts en App Services krijgen per resource of via policy een diagnostic setting die audit- en securityrelevante logs uitsturen. Defender for Cloud wordt geconfigureerd om securityalerts en aanbevelingen door te sturen, terwijl Entra ID-diagnostiek zodanig wordt ingesteld dat sign-in- en auditlogs beschikbaar komen in Log Analytics. Tijdens deze uitrol wordt per wijziging gecontroleerd of de nieuwe datastroom daadwerkelijk resulteert in records in de beoogde tabellen, bijvoorbeeld door in de workspace te zoeken naar recente entries in SecurityEvent, SigninLogs of AzureActivity.

Gebruik PowerShell-script log-analytics-security-logs.ps1 (functie Invoke-Implementation) – Implementeren en controleren van basisconfiguratie.

Het PowerShell-script log-analytics-security-logs.ps1 ondersteunt deze implementatie door per Log Analytics-workspace te controleren of securityrelevante tabellen daadwerkelijk zijn gevuld. Het script maakt verbinding met Azure via Connect-AzAccount, haalt alle workspaces op en voert een lichte Kusto-query uit richting de SecurityEvent-tabel. Workspaces waarin deze tabel geen enkele rij bevat, worden als risicovol gemarkeerd omdat daar kennelijk geen endpoint- of serverlogging op is aangesloten. De uitvoer bevat zowel een totaalscore per tenant als een overzicht per workspace, waardoor teams gericht acties kunnen uitzetten naar de eigenaar van de betreffende omgeving. Het script kan herhaaldelijk worden gedraaid nadat nieuwe diagnostic settings of data-collectie-regels zijn toegevoegd om te verifiëren dat de verwachte gebeurtenissen inderdaad aankomen.

Wanneer de basis staat, verschuift de aandacht naar normalisatie en tagging. Log Analytics biedt mogelijkheden om via ingestie-time transform rules en custom fields metadata toe te voegen, bijvoorbeeld de classificatie van een workload, de verantwoordelijke afdeling of het bijbehorende proces uit de BIA. Door deze context aan security logs te koppelen, kunnen SOC-analisten sneller prioriteren en wordt het eenvoudiger om rapportages te maken die aansluiten op bestuurlijke dashboards. In deze fase wordt ook bepaald welke tabellen structureel worden gebruikt voor usecases in Sentinel of andere SIEM’s, zodat retentie en prestatie-optimalisaties zich concentreren op de belangrijkste datastromen.

De laatste implementatiestap omvat automatisering en kwaliteitsborging. Met behulp van Azure Policy, ARM/Bicep-sjablonen of Terraform wordt vastgelegd dat nieuwe subscriptions en resources automatisch de juiste diagnostic settings krijgen. Daarnaast worden periodieke scripts of workbooks ingericht die controleren of er geen nieuwe resources zijn ontstaan zonder logging, of dat er geen workspaces zijn waarin securitytabellen stilgevallen zijn. Deze controles worden opgenomen in de reguliere change- en releasekalender, zodat wijzigingen in architectuur of tooling niet ongemerkt leiden tot gaten in de loggingdekking. Door implementatie en borging op deze manier te combineren groeit Log Analytics Security Logs uit tot een stabiele pijler onder het security operating model.

Compliance en Auditing

Vanuit complianceperspectief vervult Log Analytics Security Logs een dubbele rol: enerzijds als technische voorziening om beveiligingsincidenten tijdig te detecteren en te onderzoeken, anderzijds als bron van bewijs dat de organisatie structureel voldoet aan gestelde normen. De Baseline Informatiebeveiliging Overheid (BIO) schrijft in hoofdstukken over logging en monitoring voor dat beveiligingsrelevante gebeurtenissen moeten worden vastgelegd, geanalyseerd en gekoppeld aan opvolgacties. Door security logs gecentraliseerd in Log Analytics beschikbaar te hebben, kan eenvoudig worden aangetoond welke gebeurtenissen worden verzameld, over welke periode, met welke toegangsbeperkingen en welke dashboards en usecases daarop draaien. Tijdens ENSIA- en interne audits kunnen query-uitdraaien, retentieconfiguraties en toegangsrechten rechtstreeks uit de workspace worden geëxporteerd als evidence.

Ook de AVG en NIS2 stellen impliciete en expliciete eisen aan logging. AVG Artikel 32 verlangt passende technische en organisatorische maatregelen om onder meer de vertrouwelijkheid, integriteit en beschikbaarheid van persoonsgegevens te waarborgen. Zonder goede logdata is het vrijwel onmogelijk om na een datalek vast te stellen welke gegevens precies zijn ingezien of geëxfiltreerd, wat de beoordeling van meldplicht en impact enorm bemoeilijkt. NIS2 en de Wet beveiliging netwerk- en informatiesystemen vragen bovendien om aantoonbaar en proportioneel incidentmanagement, inclusief forensische mogelijkheden. Een Log Analytics-omgeving waarin sign-in-logs, auditlogs en securityalerts over meerdere jaren beschikbaar zijn, vormt de basis om deze verplichtingen na te komen en om in rapportages richting toezichthouders overtuigend te laten zien wat er is gebeurd en hoe snel daarop is gereageerd.

Voor sectorale kaders, zoals de DigiD-beveiligingsrichtlijnen, de richtlijnen van het Nationaal Cyber Security Centrum (NCSC) of aanvullende eisen van toezichthouders in de gezondheidszorg en financiële sector, geldt eveneens dat logging en monitoring centraal staan. Log Analytics maakt het mogelijk om maatwerkrapporten te definiëren waarin bijvoorbeeld alle toegangspogingen tot hooggeclassificeerde systemen, wijzigingsacties op kritieke configuratie-items of policy-overtredingen in één overzicht worden samengebracht. Deze rapporten kunnen periodiek worden geëxporteerd en ondertekend, waardoor zij direct als auditstuk kunnen worden opgenomen in dossiers. Belangrijk is wel dat de queries en workbooks die hiervoor worden gebruikt onder versiebeheer staan, zodat auditteams kunnen controleren dat de gebruikte logica consistent is en dat resultaten herhaalbaar zijn.

Transparantie en dataminimalisatie blijven randvoorwaarden, ook bij security logging. Organisaties moeten onderbouwen waarom bepaalde persoonsgegevens – zoals IP-adressen, gebruikersnamen of apparaatnamen – in logs worden vastgelegd en hoe lang zij worden bewaard. Log Analytics ondersteunt deze verantwoording doordat retentie-instellingen per tabel kunnen worden vastgelegd en omdat exportstromen naar andere systemen zichtbaar zijn. Door deze configuraties te documenteren in het verwerkingsregister en in dataprotectie-effectbeoordelingen (DPIA’s), kan worden aangetoond dat logging proportioneel en doelgebonden is ingericht. Hiermee worden technische maatregelen direct gekoppeld aan juridische en organisatorische kaders, wat essentieel is binnen de Nederlandse Baseline voor Veilige Cloud.

Monitoring en Kwaliteitsbewaking

Zodra Log Analytics Security Logs in gebruik zijn, verschuift de focus naar de kwaliteit en continuïteit van de datastromen. Monitoring richt zich dan niet alleen op wat er met systemen gebeurt, maar ook op de vraag of logs zelf nog volledig en betrouwbaar zijn. Dit betekent dat er dashboards nodig zijn die het volume aan binnenkomende berichten per tabel en per bron visualiseren, met duidelijke drempelwaarden voor afwijkingen. Een plotselinge daling van het aantal entries in SigninLogs of SecurityEvent kan wijzen op een fout in diagnostic settings, een uitgevallen agent of een onbedoelde wijziging in netwerkconfiguratie. Het tijdig herkennen van dit soort afwijkingen voorkomt dat het SOC wekenlang werkt met een onzichtbare blinde vlek.

Gebruik PowerShell-script log-analytics-security-logs.ps1 (functie Invoke-Monitoring) – Controleren of beveiligingslogs daadwerkelijk aanwezig zijn in workspaces.

Het PowerShell-script log-analytics-security-logs.ps1 ondersteunt deze kwaliteitsbewaking door per workspace te controleren of de SecurityEvent-tabel recent data bevat. De uitvoer geeft een overzicht van het aantal workspaces, hoeveel daarvan securitylogs bevatten en in welke workspaces deze ontbreken. Deze informatie kan worden gebruikt als input voor periodieke rapportages richting het Cloud Competence Center of het Security Operations Center. Door het script bijvoorbeeld dagelijks of wekelijks via Azure Automation uit te voeren en de resultaten in Log Analytics terug te schrijven, ontstaat bovendien een historisch beeld van de loggingdekking, wat weer input levert voor trendanalyses en maturity-assessments.

Naast het meten van datavolume is het belangrijk om de prestaties van query’s te monitoren. Complexe KQL-query’s die regelmatig time-outs veroorzaken of veel resources verbruiken, kunnen dashboards en usecases vertragen en zo de effectiviteit van het SOC verminderen. Door queryduur, resource consumption en foutpercentages op te nemen in monitoringdashboards, kunnen teams gericht optimaliseren: tabellen partitioneren, indexen gebruiken, query’s herschrijven of data-aggregaties toepassen. Deze optimalisaties zijn extra relevant in omgevingen waar Log Analytics ook fungeert als datalaag voor Sentinel, omdat performance-impact daar direct invloed heeft op detectiesnelheid.

Tot slot maakt monitoring ook de menselijke factor zichtbaar. Door KPI’s vast te leggen zoals het aantal uitgevoerde huntsessies per maand, het aantal verbeterde queries of het percentage incidenten waarin Log Analytics daadwerkelijk is geraadpleegd, ontstaat een beeld van hoe volwassen het gebruik van security logs in de praktijk is. Deze cijfers kunnen worden meegenomen in managementrapportages en opleidingsplannen, zodat duidelijk wordt waar extra training, tooling of capaciteit nodig is. Zo wordt Log Analytics Security Logs geen eenmalig technisch project, maar een doorlopend verbeterprogramma dat bijdraagt aan de weerbaarheid van de hele organisatie.

Remediatie en Verbetering

Wanneer monitoring uitwijst dat één of meerdere workspaces geen securitylogs bevatten of dat bepaalde bronnen niet langer schrijven, is snelle remediatie noodzakelijk. In de praktijk gaat het vaak om verkeerd toegepaste diagnostic settings, verwijderde workspacekoppelingen of wijzigingen in netwerkconfiguraties waardoor agents geen verbinding meer kunnen maken. Een effectief remediatieproces begint daarom met een duidelijke beslisboom: is het probleem beperkt tot één resource of een hele resourcegroep, is het tijdelijk (bijvoorbeeld onderhoud) of structureel, en welke processen zijn afhankelijk van de betreffende logging? Deze analyse bepaalt welke prioriteit het issue krijgt en wie moet worden betrokken bij de oplossing.

Gebruik PowerShell-script log-analytics-security-logs.ps1 (functie Invoke-Remediation) – Ondersteunen bij het herstellen van ontbrekende securitylogs.

De functie Invoke-Remediation in het bijbehorende PowerShell-script is bewust terughoudend: in plaats van automatisch configuraties aan te passen, markeert het script workspaces zonder SecurityEvent-gegevens en geeft het gerichte aanbevelingen om logging te herstellen. Deze aanpak sluit aan bij de realiteit dat veel organisaties gebruikmaken van infrastructuur-as-code voor definitieve configuratie en dat directe wijzigingen in productie via scripts soms onwenselijk zijn. Het script helpt beheerders door concrete acties te suggereren, zoals het controleren van policy-assignments, het herstarten van agents of het synchroniseren van instellingen met de gewenste staat in Git. Waar mogelijk kunnen aanvullende helperfuncties worden toegevoegd om standaard-diagnostic settings voor veelvoorkomende resourcetypen voor te bereiden, die vervolgens via het reguliere changeproces worden uitgerold.

Na iedere remediatie-actie volgt een verificatiefase waarin opnieuw wordt gecontroleerd of de beoogde logs daadwerkelijk binnenkomen. Dit gebeurt door zowel het PowerShell-script als handmatige KQL-query’s te gebruiken, bijvoorbeeld een time-window search over de laatste uren in SecurityEvent of AzureActivity. De resultaten worden vastgelegd in het incident- of wijzigingsdossier, inclusief de grondoorzaak van het probleem en de maatregelen die zijn genomen om herhaling te voorkomen. Denk aan het aanscherpen van Azure Policy-definities, het toevoegen van controles aan CI/CD-pijplijnen of het uitbreiden van monitoring op logvolumes. Door deze feedbacklus consequent te sluiten, groeit de betrouwbaarheid van Log Analytics Security Logs en neemt het risico op onopgemerkte gaten in logging sterk af.

Voor grote incidenten, bijvoorbeeld wanneer wekenlang geen securitylogs zijn verzameld uit een kritieke omgeving, wordt remediatie gekoppeld aan bredere herstel- en verbeterprogramma’s. Hierbij worden forensische onderzoeksresultaten, juridische beoordelingen en managementrapportages samengebracht om maatregelen te definiëren die verder gaan dan puur technische fixes. Dit kan variëren van aanvullende bewustwordingscampagnes voor beheerders tot herontwerp van de Azure-landingzone. Log Analytics Security Logs leveren in zulke trajecten het feitenmateriaal dat nodig is om overtuigende businesscases te bouwen en om te laten zien dat investeringen in monitoring daadwerkelijk bijdragen aan lagere risico’s en betere naleving 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 Log Analytics Security Logs .DESCRIPTION Controleert of Log Analytics-workspaces securityrelevante logs bevatten door te testen of de SecurityEvent-tabel data oplevert. .NOTES Filename: log-analytics-security-logs.ps1 Author: Nederlandse Baseline voor Veilige Cloud Version: 1.0 Category: logging-monitoring Workload: azure .LINK https://github.com/m365-tenant-best-practise .EXAMPLE .\log-analytics-security-logs.ps1 Toont een korte samenvatting van de status .EXAMPLE .\log-analytics-security-logs.ps1 -Monitoring Geeft een uitgebreid overzicht per workspace #> #Requires -Version 5.1 #Requires -Modules Az.Accounts, Az.OperationalInsights [CmdletBinding()] param( [Parameter(HelpMessage = "Uitgebreide monitoring-uitvoer tonen")] [switch]$Monitoring ) $ErrorActionPreference = 'Stop' $PolicyName = "Log Analytics Security Logs" function Connect-RequiredServices { if (-not (Get-AzContext)) { Connect-AzAccount -ErrorAction Stop | Out-Null } } function Test-LogAnalyticsSecurityLogs { [CmdletBinding()] param() $workspaces = Get-AzOperationalInsightsWorkspace -ErrorAction SilentlyContinue if (-not $workspaces) { return @{ TotalWorkspaces = 0 WithSecurityEventData = 0 WithoutSecurityEventData = 0 Details = @() } } $details = @() foreach ($ws in $workspaces) { $hasData = $false try { # Lichte query: alleen controleren of er minimaal één rij in SecurityEvent aanwezig is $queryResult = Invoke-AzOperationalInsightsQuery -WorkspaceId $ws.CustomerId -Query "SecurityEvent | take 1" -ErrorAction Stop if ($queryResult.Tables.Rows.Count -gt 0) { $hasData = $true } } catch { # Als de query faalt (bijvoorbeeld omdat de tabel niet bestaat), beschouwen we dit als geen securitydata $hasData = $false } $details += [pscustomobject]@{ WorkspaceName = $ws.Name ResourceGroup = $ws.ResourceGroupName Location = $ws.Location HasSecurity = $hasData } } $withData = ($details | Where-Object { $_.HasSecurity }).Count $withoutData = ($details | Where-Object { -not $_.HasSecurity }).Count return @{ TotalWorkspaces = $workspaces.Count WithSecurityEventData = $withData WithoutSecurityEventData = $withoutData Details = $details } } try { Connect-RequiredServices $result = Test-LogAnalyticsSecurityLogs if ($Monitoring) { Write-Host "`n========================================" -ForegroundColor Cyan Write-Host $PolicyName -ForegroundColor Cyan Write-Host "========================================" -ForegroundColor Cyan Write-Host "Log Analytics workspaces : $($result.TotalWorkspaces)" -ForegroundColor White Write-Host "Met SecurityEvent-data : $($result.WithSecurityEventData)" -ForegroundColor $(if ($result.WithSecurityEventData -gt 0) { 'Green' } else { 'Yellow' }) Write-Host "Zonder SecurityEvent-data : $($result.WithoutSecurityEventData)" -ForegroundColor $(if ($result.WithoutSecurityEventData -eq 0) { 'Green' } else { 'Yellow' }) if ($result.TotalWorkspaces -gt 0) { Write-Host "`nDetails per workspace:" -ForegroundColor Cyan foreach ($item in $result.Details) { $color = if ($item.HasSecurity) { 'Green' } else { 'Yellow' } Write-Host ("- {0} (rg: {1}, locatie: {2}) -> SecurityEvent-data: {3}" -f ` $item.WorkspaceName, $item.ResourceGroup, $item.Location, ` ($(if ($item.HasSecurity) { 'JA' } else { 'NEE' }))) -ForegroundColor $color } } if ($result.WithoutSecurityEventData -gt 0) { Write-Host "`nLet op: één of meer workspaces hebben geen SecurityEvent-data. Controleer diagnostic settings en datacollectie." -ForegroundColor Yellow } } else { Write-Host "`n$PolicyName: $($result.WithSecurityEventData)/$($result.TotalWorkspaces) workspaces met SecurityEvent-data" -ForegroundColor White } } catch { Write-Error $_ exit 1 } # ================================================================================ # Standaard Invoke-* Functions (voor integratie met content JSON) # ================================================================================ function Invoke-Implementation { <# .SYNOPSIS Ondersteunt implementatie door de huidige status te tonen #> [CmdletBinding()] param() # Voor deze maatregel voert implementatie geen automatische wijzigingen uit, # maar levert het script feitelijke informatie voor de implementatiebesluiten. & $PSCommandPath -Monitoring } function Invoke-Monitoring { <# .SYNOPSIS Controleert de huidige configuratiestatus #> [CmdletBinding()] param() & $PSCommandPath -Monitoring } function Invoke-Remediation { <# .SYNOPSIS Ondersteunt herstelacties door niet-gedekte workspaces in beeld te brengen .DESCRIPTION Dit script past geen configuraties aan, maar geeft een actielijst voor beheerders om ontbrekende securitylogs te herstellen. #> [CmdletBinding()] param() $result = Test-LogAnalyticsSecurityLogs Write-Host "`nWorkspaces zonder SecurityEvent-data:" -ForegroundColor Cyan if ($result.WithoutSecurityEventData -eq 0) { Write-Host "Alle gevonden workspaces bevatten SecurityEvent-data." -ForegroundColor Green return } foreach ($item in $result.Details | Where-Object { -not $_.HasSecurity }) { Write-Host ("- {0} (rg: {1}, locatie: {2})" -f ` $item.WorkspaceName, $item.ResourceGroup, $item.Location) -ForegroundColor Yellow } Write-Host "`nAanbevolen vervolgstappen (handmatig of via IaC):" -ForegroundColor Yellow Write-Host "1. Controleer of servers/agents die SecurityEvent genereren gekoppeld zijn aan deze workspaces." -ForegroundColor White Write-Host "2. Valideer diagnostic settings voor kritieke bronnen (bijvoorbeeld Azure AD, Defender, Key Vault)." -ForegroundColor White Write-Host "3. Werk Azure Policy of IaC-sjablonen bij zodat nieuwe resources automatisch beveiligingslogging inschakelen." -ForegroundColor White }

Risico zonder implementatie

Risico zonder implementatie
High: Zonder centrale Log Analytics Security Logs kan de organisatie beveiligingsincidenten moeilijk reconstrueren, blijft het onduidelijk welke systemen en persoonsgegevens zijn geraakt en is het vrijwel onmogelijk om richting BIO, NIS2 en AVG aan te tonen dat logging en monitoring volwassen zijn ingericht.

Management Samenvatting

Centraliseer alle securityrelevante logs in Log Analytics, borg retentie en toegangsbeheer en gebruik scripts en dashboards om continu te controleren of kritieke tabellen zoals SecurityEvent, SigninLogs en AzureActivity daadwerkelijk worden gevuld.