L1 BIO 12.04 ISO A.12.4.1 CIS 5.1.1

Activity Log Retentie In Azure: Strategie, Architectuur En Governance

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

💼 Management Samenvatting

Het Azure Activity Log is de primaire bron om te reconstrueren wie, wanneer en via welk kanaal een wijziging in een Azure-omgeving heeft aangebracht. Zonder doordachte retentiestrategie blijft deze informatie slechts een kortdurende momentopname in plaats van een robuuste audittrail voor forensisch onderzoek en compliance.

Aanbeveling
RICHT EEN GECENTRALISEERDE EN GELAAGDE ACTIVITY LOG-RETENTIE-INRICHTING IN MET MINIMAAL 365 DAGEN BEWAARTERMIJN EN AANSLUITING OP WETTELIJKE KADERS
Risico zonder
High
Risk Score
8/10
Implementatie
12u (tech: 8u)
Van toepassing op:
✓ Azure

Standaard bewaart Azure het activiteitenlogboek slechts 90 dagen. Voor Nederlandse overheidsorganisaties en andere gereguleerde sectoren is dat volstrekt onvoldoende. Incidenten rond misbruik van beheerdersrechten, misconfiguraties of datalekken worden regelmatig pas maanden later ontdekt, bijvoorbeeld tijdens een audit, een onderzoek door een toezichthouder of na signalen uit de keten. Wanneer de onderliggende loggegevens dan al zijn verwijderd, kan de organisatie niet meer aantonen wat er precies is gebeurd, wie verantwoordelijk was en of passende maatregelen tijdig zijn getroffen. Dit ondermijnt niet alleen forensische onderzoeken, maar leidt ook tot aantoonbare non-compliance met kaders zoals de BIO, ISO 27001, NIS2 en AVG Artikel 5 en 32. Daarnaast wordt het bijna onmogelijk om structureel te leren van incidenten, omdat er geen betrouwbare tijdlijn van gebeurtenissen meer voorhanden is. Een volwassen retentiestrategie voor het Activity Log is daarom geen luxe, maar een basisvoorwaarde voor transparante verantwoording en effectieve incidentrespons in de cloud.

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

Implementatie

Dit artikel beschrijft hoe organisaties een geïntegreerde retentie-architectuur voor het Azure Activity Log ontwerpen en implementeren. Daarbij wordt uitgelegd hoe loggegevens via diagnostic settings naar Log Analytics-workspaces, Event Hubs of Storage-accounts worden verstuurd, hoe bewaartermijnen worden gekozen die passen bij wettelijke vereisten en interne beleidskaders, en hoe kosten en prestaties in balans blijven. We behandelen de rol van centrale logplatformen, het gebruik van beheer- en beheergroepen (management groups) voor consistente configuratie, en de manier waarop retentiebeleid wordt gekoppeld aan dataclassificatie en risicoprofielen. Tot slot laten we zien hoe PowerShell-scripts en Azure Policy worden ingezet om naleving van retentiestrategie te controleren en te bewaken, zodat afdelingen en projecten niet ongemerkt kunnen afwijken van de afgesproken normen.

Architectuur en Ontwerp van Activity Log-retentie

Een doordacht ontwerp voor Activity Log-retentie begint met het expliciet maken van de doelstellingen: waarom worden loggegevens bewaard, hoe lang zijn ze nodig en wie gebruikt ze in de praktijk? Voor Nederlandse overheidsorganisaties gaat het in de kern om drie hoofddoelen: forensisch onderzoek na beveiligingsincidenten, aantoonbare naleving van wet- en regelgeving en ondersteuning van interne audits en kwaliteitsverbetering. Vanuit deze doelen wordt bepaald welke bewaartermijn per type loggegeven nodig is. Voor generieke beheergebeurtenissen is een termijn van minimaal 365 dagen doorgaans noodzakelijk, terwijl voor hoog-risico-processen of ketenvoorzieningen vaak termijnen van vijf tot zeven jaar worden verlangd om aan archief- en sectorspecifieke verplichtingen te voldoen. Deze keuzes worden vastgelegd in informatiebeveiligings- en loggingbeleid, zodat duidelijk is welke eisen gelden voor alle abonnementen en tenants onder de verantwoordelijkheid van de organisatie. Op basis van deze beleidskaders wordt een technische architectuur ontworpen waarin het Activity Log niet alleen in de standaard 90-dagenbuffer van Azure blijft staan, maar systematisch naar één of meerdere centrale logdoelen wordt geëxporteerd. In de praktijk kiezen veel organisaties voor een combinatie van Log Analytics en Azure Storage. Log Analytics biedt krachtige query- en correlatiemogelijkheden voor dagelijkse monitoring, terwijl Storage-accounts geschikt zijn voor langetermijnbewaring tegen lagere kosten. Via diagnostic settings op abonnementsniveau wordt het Activity Log daarom naar beide bestemmingen gestuurd. De Log Analytics-workspace krijgt een bewaartermijn die is afgestemd op operationele analyse (bijvoorbeeld 180 tot 730 dagen), terwijl het Storage-account wordt ingericht met immutability policies en lifecycle management om data langer te bewaren en automatisch naar koelere opslagklassen te verplaatsen. Zo ontstaat een gelaagd model waarin recente logs snel te doorzoeken zijn en oudere logs goedkoop maar veilig worden opgeslagen. Cruciaal in het ontwerp is centralisatie: in plaats van ieder abonnement zijn eigen willekeurige instellingen te laten beheren, wordt gekozen voor één of enkele organisatiebrede workspaces en storage-accounts. Deze worden beheerd door het centrale cloud- of SOC-team en gekoppeld aan management groups, zodat nieuwe abonnementen automatisch dezelfde logging- en retentieregels erven. Dit voorkomt versnippering en maakt het veel eenvoudiger om bij een incident tenant-brede analyses uit te voeren. Bovendien kunnen tagging-standaarden worden toegepast waarmee onderscheid wordt gemaakt tussen productie-, test- en ontwikkelomgevingen, zodat retentie gericht kan worden afgestemd op dataclassificatie en risico. Productieomgevingen met persoonsgegevens en kritieke processen krijgen bijvoorbeeld langere bewaartermijnen dan tijdelijke proof-of-concepts waarin uitsluitend synthetische data worden gebruikt. Naast de technische dataflow vereist het ontwerp aandacht voor governance en verantwoordelijkheden. Het is noodzakelijk om vast te leggen wie eigenaar is van het logplatform, wie retentie-instellingen mag wijzigen en hoe wijzigingen worden getoetst in het changeproces. In veel organisaties wordt het eigenaarschap belegd bij de CISO of het cloudcompetencecenter, terwijl uitvoering plaatsvindt door platformbeheerders. Iedere wijziging in bewaartermijn of exportdoel wordt via een change request beoordeeld op impact op compliance, kosten en prestaties. Ook worden procedures ingericht voor het tijdelijk verlengen van retentie na een groot incident of juridisch onderzoek, zodat relevante loggegevens niet per ongeluk worden verwijderd voordat onderzoeken zijn afgerond. Door deze governance expliciet op te nemen in beleid en processen, wordt voorkomen dat retentie ad-hoc wordt aangepast door individuele beheerders zonder overzicht over de keteneffecten.

Implementatie en Automatisering van Retentie-instellingen

Wanneer architectuur en beleidskaders zijn vastgesteld, verschuift de aandacht naar een voorspelbare en reproduceerbare implementatie. Voor een volwassen Azure-omgeving geldt dat Activity Log-retentie niet handmatig per abonnement wordt aangeklikt, maar centraal wordt uitgerold via Azure Policy, PowerShell-scripts en Infrastructure as Code. Hiermee wordt geborgd dat nieuwe abonnementen direct de juiste instellingen meekrijgen en dat afwijkingen automatisch worden gedetecteerd. Een gangbaar implementatiepatroon is om voor de hoogste management group één of meerdere Azure Policy-definities te publiceren die diagnostic settings afdwingen. Deze policies controleren of elk abonnement het Activity Log exporteert naar de aangegeven Log Analytics-workspace en desgewenst naar een centraal Storage-account. Wanneer dit niet het geval is, markeert de policy de resource als non-compliant en kan optioneel een deployIfNotExists-actie worden gebruikt om automatisch een standaardconfiguratie aan te maken. Op die manier is het bijna onmogelijk dat een nieuw abonnement buiten beeld blijft van de centrale logging- en retentiestrategie. Voor organisaties die liever PowerShell gebruiken, kan een periodiek script alle abonnementen langsgaan, ontbrekende instellingen creëren en eventuele afwijkingen rapporteren via e-mail, Teams of een ticketingsysteem. De concrete configuratie van bewaartermijnen vindt plaats op het niveau van de Log Analytics-workspace en, indien gebruikt, het Storage-account. In de workspace wordt per tabel of op workspaceniveau een retentionDays-waarde gekozen die aansluit bij de eerder vastgestelde beleidstermijnen. Voor Activity Log-gegevens betekent dit minimaal 365 dagen, maar in de praktijk vaak langer als auditvereisten daarom vragen. Voor Storage-accounts wordt lifecycle management ingezet om data eerst enkele jaren in hot- of cool-storage te bewaren en daarna automatisch naar archive-tier te verplaatsen indien nog langere bewaring is vereist. Door deze instellingen vast te leggen in ARM-templates, Bicep of Terraform ontstaat versiebeheer en kunnen wijzigingen gecontroleerd worden uitgerold via CI/CD-pijplijnen. Het bijbehorende PowerShell-script in deze baseline, activity-log-retention.ps1, speelt een ondersteunende rol bij implementatie en controle. Het script inventariseert per abonnement welke diagnostic settings voor het Activity Log zijn geconfigureerd, naar welke bestemmingen de data worden verstuurd en welke retentie-instellingen zijn toegepast. Op basis hiervan wordt een compact compliance-rapport gegenereerd dat laat zien welke abonnementen volledig voldoen aan de afgesproken normen en waar nog hiaten zitten. Het script kan stand-alone worden uitgevoerd door cloudbeheerders, maar leent zich ook goed voor integratie in Azure Automation, GitHub Actions of andere orkestratietools. Door de uitvoer periodiek te bewaren in een centrale opslag of een rapportage-dashboard ontstaat bovendien direct auditbewijs dat de organisatie actief toezicht houdt op Activity Log-retentie.

Gebruik PowerShell-script activity-log-retention.ps1 (functie Invoke-Implementation) – Uitvoeren van een implementatie- en configuratiecontrole op Activity Log-retentie.

Monitoring, Governance en Continue Verbetering

Gebruik PowerShell-script activity-log-retention.ps1 (functie Invoke-Monitoring) – Periodiek controleren of Activity Log-retentie en diagnostic settings voldoen aan beleid.

Een retentie-inrichting is geen statische configuratie die na oplevering kan worden vergeten. Dreigingsbeelden, wetgeving en cloudservices veranderen voortdurend, waardoor monitoring en governance rond Activity Log-retentie een doorlopend proces moeten zijn. Zonder structurele controle bestaat het risico dat nieuwe abonnementen niet worden aangesloten, dat beheerders per ongeluk diagnostic settings verwijderen of dat wijzigingen in kostenoptimalisatie leiden tot onbedoelde verkorting van bewaartermijnen. Daarom is het essentieel om retentie expliciet onderdeel te maken van de bredere governance rond logging en monitoring. Monitoring begint met zicht op de actuele configuratie. Het PowerShell-script kan wekelijks of maandelijks worden gedraaid om per abonnement een overzicht te genereren van diagnostic settings, bestemmingen en bewaartermijnen. De resultaten worden bij voorkeur opgeslagen in een centrale Log Analytics-workspace of een governance-database, waarin dashboards laten zien welke abonnementen compliant zijn, welke afwijkingen hebben en hoe de trend zich ontwikkelt. Door deze informatie te koppelen aan management groups, business-units en dataclassificaties ontstaat direct inzicht in waar de grootste risico’s liggen en welke teams actie moeten ondernemen. Alerts kunnen worden ingericht die een signaal sturen naar het cloudplatformteam of de CISO zodra een abonnement niet langer voldoet aan de minimale retentie-eisen. Naast technische monitoring is procesmatige borging nodig. In change- en releaseprocessen wordt vastgelegd dat elke wijziging aan logging- of retentie-instellingen expliciet moet worden beoordeeld door de security- of compliancefunctie. Dit geldt bijvoorbeeld voor voorstellen om bewaartermijnen te verkorten vanwege kosten, of om bepaalde logcategorieën niet langer te exporteren. Bij grote wijzigingen, zoals een migratie naar een nieuwe Log Analytics-workspace of het samenvoegen van abonnementen, wordt vooraf een impactanalyse uitgevoerd op forensische mogelijkheden en compliance-verplichtingen. De uitkomsten worden gedocumenteerd en afgestemd met de privacy officer, de CISO en eventuele ketenpartners. Continue verbetering krijgt vorm via periodieke evaluaties, bijvoorbeeld in het kader van de jaarlijkse BIO- of ISO 27001-cyclus. Tijdens deze evaluaties wordt geanalyseerd of de gekozen bewaartermijnen nog aansluiten bij actuele risico’s en wettelijke kaders, of incidenten voldoende kunnen worden gereconstrueerd en of auditors aanvullende eisen stellen aan de diepgang van logging. Op basis van lessons learned uit incidenten, audits en oefeningen kan worden besloten om retentie te verlengen, extra logdoelen toe te voegen of aanvullende metadata op te nemen in het Activity Log door middel van tagging en standaardisatie van resource-namen. Door deze evaluaties te koppelen aan een formele besluitvormingsstructuur, zoals een Cloud Risk Board of informatiebeveiligingsberaad, blijft Activity Log-retentie een levend onderwerp dat meegroeit met de organisatie en het dreigingslandschap.

Compliance, Audit en Verantwoording

Activity Log-retentie staat rechtstreeks in verbinding met meerdere wettelijke en normatieve kaders die van toepassing zijn op Nederlandse organisaties. Voor de publieke sector is de Baseline Informatiebeveiliging Overheid (BIO) leidend. Met name de normen rond logging en monitoring vereisen dat beveiligingsrelevante gebeurtenissen worden vastgelegd, gedurende een voldoende lange periode beschikbaar blijven en kunnen worden betrokken in incidentonderzoek en audits. Een retentiestrategie waarin het Activity Log minimaal 365 dagen beschikbaar is in een centrale logomgeving, en langer indien noodzakelijk voor specifieke processen, vormt in de praktijk een noodzakelijke voorwaarde om aan deze normen te voldoen. Tijdens ENSIA- of interne audits kan de organisatie met configuratie-exporten, rapportages van het PowerShell-script en voorbeelden van uitgevoerde onderzoeken aantonen dat logging structureel en aantoonbaar wordt beheerd. Ook ISO 27001 en de onderliggende controls rond logbeheer en audittrails stellen eisen aan bewaartermijnen. Hoewel de norm geen vaste aantallen dagen voorschrijft, verwachten auditors dat de gekozen termijn is onderbouwd op basis van risicobeoordelingen en wettelijke kaders, en dat deze consequent wordt toegepast in alle relevante systemen. Door Activity Log-retentie expliciet op te nemen in het informatiebeveiligingsbeleid en in het Statement of Applicability, wordt zichtbaar dat de organisatie heeft nagedacht over de balans tussen privacy, kosten en forensische mogelijkheden. De combinatie van technische inrichting (diagnostic settings, workspaces, storage) en organisatorische maatregelen (procedures, rollen, evaluaties) levert overtuigend auditbewijs op dat de norm in de praktijk wordt nageleefd. De NIS2-richtlijn legt voor essentiële en belangrijke entiteiten nadruk op het tijdig detecteren en onderzoeken van incidenten. Zonder langdurige logbewaring is het onmogelijk om complexe aanvalspatronen over meerdere maanden te reconstrueren of om aan te tonen dat passende maatregelen zijn getroffen. Door Activity Log-gegevens lang genoeg te bewaren en centraal te correleren met andere logbronnen, zoals identiteit-, netwerk- en applicatielogs, kunnen organisaties aantonen dat zij de vereiste mate van weerbaarheid en transparantie realiseren. Voor ketenvoorzieningen en samenwerkingsverbanden is het daarbij belangrijk om afspraken over logdeling en retentie op te nemen in contracten, verwerkersovereenkomsten en convenanten. In het kader van de AVG speelt het Activity Log een belangrijke rol bij accountability. Loggegevens helpen aantonen wie welke configuratie heeft gewijzigd, wanneer bepaalde beveiligingsmaatregelen zijn ingeschakeld en hoe is gereageerd op incidenten met persoonsgegevens. Tegelijkertijd moeten organisaties zorgvuldig omgaan met de persoonsgegevens die in logbestanden kunnen voorkomen, zoals IP-adressen, gebruikersnamen of resource-identificaties die naar individuen herleidbaar zijn. Dit betekent dat retentieafspraken moeten worden afgestemd met de privacy officer en dat waar mogelijk pseudonimisering, toegangsbeperking en strikte autorisatie worden toegepast. Door deze waarborgen op te nemen in het verwerkingsregister en in privacy by design-documentatie, kunnen organisaties richting toezichthouders onderbouwen dat zij een zorgvuldige balans hebben gevonden tussen transparantie, opsporingsmogelijkheden en gegevensbescherming.

Gebruik PowerShell-script activity-log-retention.ps1 (functie Invoke-Remediation) – Ondersteunen van remediatie door configuratiefouten in kaart te brengen en advies te geven voor herstel.

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 Inventory en controle van Azure Activity Log-retentie en diagnostic settings. .DESCRIPTION Dit script inventariseert per abonnement of het Azure Activity Log via diagnostic settings wordt geëxporteerd naar Log Analytics en/of Storage en welke retentie-instellingen daarbij horen. Het script is bedoeld als lichte control waarmee cloud- en securityteams snel kunnen zien of de retentiestrategie voor het Activity Log aansluit bij de beleidsafspraken (bijvoorbeeld minimaal 365 dagen). .NOTES Filename: activity-log-retention.ps1 Author: Nederlandse Baseline voor Veilige Cloud Version: 1.0 Related JSON: content/azure/logging-monitoring/activity-log-retention.json #> #Requires -Version 5.1 #Requires -Modules Az.Accounts, Az.Monitor [CmdletBinding()] param( [Parameter()] [switch]$Monitoring, [Parameter()] [int]$MinimumRetentionDays = 365 ) $ErrorActionPreference = 'Stop' $PolicyName = "Activity Log Retention - Inventory and Compliance" function Connect-RequiredServices { if (-not (Get-AzContext)) { Connect-AzAccount -ErrorAction Stop | Out-Null } } function Get-ActivityLogSettings { <# .SYNOPSIS Haalt per abonnement de diagnostic settings voor het Activity Log op. #> $subscriptions = Get-AzSubscription -ErrorAction Stop $results = @() foreach ($sub in $subscriptions) { Set-AzContext -SubscriptionId $sub.Id -ErrorAction Stop | Out-Null # Diagnostic settings op abonnementsniveau voor het Activity Log $diagSettings = Get-AzDiagnosticSetting -ResourceId "/subscriptions/$($sub.Id)" -ErrorAction SilentlyContinue if (-not $diagSettings) { $results += [PSCustomObject]@{ SubscriptionId = $sub.Id SubscriptionName = $sub.Name HasDiagnosticSetting = $false LogAnalyticsTargets = 0 StorageTargets = 0 EventHubTargets = 0 MinRetentionInDays = 0 NonCompliant = $true Notes = "Geen diagnostic settings voor Activity Log gevonden." } continue } foreach ($setting in $diagSettings) { $laCount = 0 $stCount = 0 $ehCount = 0 $minRet = $null if ($setting.WorkspaceId) { $laCount = 1 } if ($setting.StorageAccountId) { $stCount = 1 } if ($setting.EventHubAuthorizationRuleId -or $setting.EventHubName) { $ehCount = 1 } # Retentie op diagnostic setting-niveau (indien geconfigureerd) if ($setting.RetentionPolicy -and $setting.RetentionPolicy.Enabled) { $minRet = $setting.RetentionPolicy.Days } $isNonCompliant = $false $note = "Retentie voldoet aan ingestelde minimum." if (-not $minRet -or $minRet -lt $MinimumRetentionDays) { $isNonCompliant = $true $note = "Retentie korter dan gewenste minimum of niet expliciet ingesteld." } $results += [PSCustomObject]@{ SubscriptionId = $sub.Id SubscriptionName = $sub.Name HasDiagnosticSetting = $true LogAnalyticsTargets = $laCount StorageTargets = $stCount EventHubTargets = $ehCount MinRetentionInDays = $minRet NonCompliant = $isNonCompliant Notes = $note } } } return $results } function Test-Compliance { $data = Get-ActivityLogSettings $totalSubs = ($data | Select-Object -ExpandProperty SubscriptionId -Unique).Count $withoutDiag = ($data | Where-Object { -not $_.HasDiagnosticSetting }).Count $nonCompliant = ($data | Where-Object { $_.NonCompliant -eq $true }).Count return [PSCustomObject]@{ TotalSubscriptions = $totalSubs SubscriptionsWithoutDS = $withoutDiag NonCompliantSettings = $nonCompliant MinimumRetentionDays = $MinimumRetentionDays Details = $data } } try { Connect-RequiredServices if ($Monitoring) { $result = Test-Compliance Write-Host "" -ForegroundColor White Write-Host "========================================" -ForegroundColor Cyan Write-Host $PolicyName -ForegroundColor Cyan Write-Host "========================================" -ForegroundColor Cyan Write-Host ("Abonnementen totaal : {0}" -f $result.TotalSubscriptions) -ForegroundColor White if ($result.SubscriptionsWithoutDS -gt 0) { Write-Host ("Zonder diagnostic setting (Activity) : {0}" -f $result.SubscriptionsWithoutDS) -ForegroundColor Yellow } else { Write-Host ("Zonder diagnostic setting (Activity) : {0}" -f $result.SubscriptionsWithoutDS) -ForegroundColor Green } if ($result.NonCompliantSettings -gt 0) { Write-Host ("Niet-conforme configuraties : {0}" -f $result.NonCompliantSettings) -ForegroundColor Yellow } else { Write-Host ("Niet-conforme configuraties : {0}" -f $result.NonCompliantSettings) -ForegroundColor Green } Write-Host ("Minimale gewenste retentie (dagen) : {0}" -f $result.MinimumRetentionDays) -ForegroundColor White if ($result.SubscriptionsWithoutDS -gt 0 -or $result.NonCompliantSettings -gt 0) { Write-Host "" -ForegroundColor White Write-Host "[WAARSCHUWING] Eén of meer abonnementen voldoen niet aan de gewenste Activity Log-retentiestrategie." -ForegroundColor Yellow Write-Host " Gebruik de details-uitvoer om te bepalen waar diagnostic settings moeten worden toegevoegd" -ForegroundColor Yellow Write-Host " of waar retentie minimaal $MinimumRetentionDays dagen moet worden ingesteld." -ForegroundColor Yellow } # Gedetailleerde tabel als JSON voor verdere verwerking $result.Details | ConvertTo-Json -Depth 4 } else { $result = Test-Compliance Write-Host "" Write-Host ("Activity Log-retentie: {0} abonnement(en) gecontroleerd, {1} zonder diagnostic settings, {2} niet-conform." -f ` $result.TotalSubscriptions, $result.SubscriptionsWithoutDS, $result.NonCompliantSettings) } } catch { Write-Error $_ exit 1 } # ================================================================================ # Standaard Invoke-* Functions # ================================================================================ function Invoke-Implementation { <# .SYNOPSIS Voert een implementatie- en configuratiecontrole uit voor Activity Log-retentie. .DESCRIPTION Deze functie voert geen automatische remediatie uit, maar levert een gedetailleerd overzicht van diagnostic settings en retentie-instellingen. Gebruik deze informatie om policies, scripts of handmatige configuratie aan te scherpen. #> [CmdletBinding()] param() $Monitoring = $true $null = Test-Compliance | Out-Null } function Invoke-Monitoring { <# .SYNOPSIS Voert een monitoringcontrole uit en toont een samenvatting plus JSON-uitvoer. #> [CmdletBinding()] param() $Monitoring = $true try { Connect-RequiredServices $result = Test-Compliance Write-Host "" -ForegroundColor White Write-Host "========================================" -ForegroundColor Cyan Write-Host $PolicyName -ForegroundColor Cyan Write-Host "========================================" -ForegroundColor Cyan Write-Host ("Abonnementen totaal : {0}" -f $result.TotalSubscriptions) -ForegroundColor White Write-Host ("Zonder diagnostic setting (Activity) : {0}" -f $result.SubscriptionsWithoutDS) -ForegroundColor (if ($result.SubscriptionsWithoutDS -gt 0) { 'Yellow' } else { 'Green' }) Write-Host ("Niet-conforme configuraties : {0}" -f $result.NonCompliantSettings) -ForegroundColor (if ($result.NonCompliantSettings -gt 0) { 'Yellow' } else { 'Green' }) Write-Host ("Minimale gewenste retentie (dagen) : {0}" -f $result.MinimumRetentionDays) -ForegroundColor White if ($result.SubscriptionsWithoutDS -gt 0 -or $result.NonCompliantSettings -gt 0) { Write-Host "" -ForegroundColor White Write-Host "[WAARSCHUWING] Eén of meer abonnementen voldoen niet aan de gewenste Activity Log-retentiestrategie." -ForegroundColor Yellow } $result.Details | ConvertTo-Json -Depth 4 } catch { Write-Error $_ exit 1 } } function Invoke-Remediation { <# .SYNOPSIS Ondersteunt remediatie door niet-conforme abonnementen zichtbaar te maken. .DESCRIPTION Deze functie past geen configuraties aan, maar geeft duidelijke instructies welke abonnementen en diagnostic settings moeten worden verbeterd om aan de retentie-eisen te voldoen. #> [CmdletBinding()] param() try { $result = Test-Compliance Write-Host "" -ForegroundColor Yellow Write-Host "[INFO] Dit script voert geen automatische remediatie uit." -ForegroundColor Yellow Write-Host "[INFO] Gebruik onderstaande informatie om policies en configuraties bij te werken." -ForegroundColor Yellow $nonCompliant = $result.Details | Where-Object { $_.NonCompliant -eq $true -or -not $_.HasDiagnosticSetting } if ($nonCompliant) { Write-Host "" -ForegroundColor White Write-Host "Abonnementen met ontbrekende of onvoldoende retentie-instellingen:" -ForegroundColor Yellow $nonCompliant | Select-Object SubscriptionName, SubscriptionId, HasDiagnosticSetting, MinRetentionInDays, Notes | Format-Table -AutoSize } else { Write-Host "Alle gecontroleerde abonnementen voldoen aan de minimale retentie-eisen." -ForegroundColor Green } } catch { Write-Error $_ exit 1 } }

Risico zonder implementatie

Risico zonder implementatie
High: Zonder structurele retentie en centrale opslag van het Azure Activity Log kan de organisatie ernstige beveiligingsincidenten niet volledig reconstrueren, ontbreekt aantoonbaarheid richting auditors en toezichthouders en ontstaat een significant risico op non-compliance met BIO, ISO 27001, NIS2 en AVG. Dit leidt tot hogere schade bij incidenten, langdurige onderzoeken met beperkte bewijslast en verlies van vertrouwen bij burgers en ketenpartners.

Management Samenvatting

Bepaal beleidsmatig welke bewaartermijnen gelden voor Activity Log-gegevens, exporteer het logboek tenant-breed via diagnostic settings naar centrale Log Analytics-workspaces en Storage-accounts, en borg via automatisering en periodieke controles dat alle abonnementen aan deze eisen blijven voldoen. Gebruik het PowerShell-script activity-log-retention.ps1 om configuraties te inventariseren, afwijkingen zichtbaar te maken en remediatie te ondersteunen.