Log Retentiebeleid In Azure: Strategie, Implementatie En Governance

💼 Management Samenvatting

Log retentiebeleid vormt de ruggengraat van elke volwassen loggingstrategie in Azure. Zonder doordachte retentiebeleidsregels verliezen organisaties kritieke auditdata, kunnen zij niet voldoen aan compliance-vereisten en ontbreekt de basis voor forensische onderzoeken na beveiligingsincidenten.

Aanbeveling
ONTWIKKEL EN IMPLEMENTEER EEN GESTANDAARDISEERD LOG RETENTIEBELEID DAT RETENTIEPERIODES KOPPELT AAN DATACLASSIFICATIE EN COMPLIANCE-FRAMEWORKS, EN DWIJG DIT BELEID TECHNISCH AF VIA AZURE POLICY EN PERIODIEKE CONTROLES
Risico zonder
High
Risk Score
8/10
Implementatie
20u (tech: 12u)
Van toepassing op:
Azure
Log Analytics
Azure Monitor

Het ontbreken van gestructureerd log retentiebeleid leidt tot verschillende kritieke problemen voor Nederlandse overheidsorganisaties. Allereerst ontstaat er inconsistentie in bewaartermijnen tussen verschillende resources en services, waardoor sommige logs slechts 30 dagen worden bewaard terwijl andere 365 dagen beschikbaar blijven. Deze inconsistentie maakt het onmogelijk om tijdens audits aan te tonen dat alle relevante data voldoende lang wordt bewaard volgens de vereisten van frameworks zoals de Baseline Informatiebeveiliging Overheid (BIO), ISO 27001 en de NIS2-richtlijn. Ten tweede leidt het ontbreken van centraal beleid tot onbedoelde dataverwijdering wanneer individuele beheerders retentie-instellingen wijzigen zonder overzicht over de compliance-impact. Dit kan resulteren in situaties waarin cruciale auditdata verloren gaat voordat incidenten worden ontdekt of audits worden uitgevoerd. Bovendien ontstaan er onnodige kosten wanneer logs langer worden bewaard dan noodzakelijk, of juist compliance-risico's wanneer logs te vroeg worden verwijderd. Het ontbreken van gestandaardiseerd retentiebeleid maakt het ook onmogelijk om automatisch te controleren of alle resources voldoen aan de afgesproken normen, waardoor handmatige controles nodig zijn die tijdrovend en foutgevoelig zijn. Tot slot leidt inconsistent retentiebeleid tot problemen bij forensische onderzoeken, omdat analisten niet kunnen vertrouwen op de beschikbaarheid van historische data en niet weten welke periode van logs beschikbaar is voor welke resource. Een doordacht log retentiebeleid biedt organisaties een gestandaardiseerde aanpak voor het bepalen van bewaartermijnen op basis van dataclassificatie, compliance-vereisten en operationele behoeften. Het beleid definieert expliciet welke retentieperiodes gelden voor verschillende typen logs, zoals activiteitenlogs, resource logs, security logs en audit trails. Door deze retentieperiodes te koppelen aan dataclassificatie en risicoprofielen ontstaat een logische en onderbouwde strategie die zowel compliance als kostenbeheer ondersteunt. Het beleid wordt technisch afgedwongen via Azure Policy, waardoor nieuwe resources automatisch de juiste retentie-instellingen meekrijgen en bestaande resources kunnen worden gecontroleerd en gecorrigeerd. Automatisering via PowerShell-scripts maakt het mogelijk om periodiek te verifiëren of alle resources voldoen aan het beleid en om afwijkingen automatisch te rapporteren. Door retentiebeleid expliciet op te nemen in governanceprocessen en change management wordt voorkomen dat individuele beheerders onbedoeld afwijken van de afgesproken normen. Tot slot maakt gedocumenteerd retentiebeleid het mogelijk om tijdens audits aan te tonen dat de organisatie een volwassen aanpak heeft voor logbeheer en dat alle relevante data voldoende lang wordt bewaard voor compliance- en forensische doeleinden.

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

Implementatie

Dit artikel beschrijft hoe organisaties een log retentiebeleid ontwikkelen en implementeren voor Azure-omgevingen. We behandelen de strategische overwegingen bij het bepalen van retentieperiodes, hoe retentiebeleid wordt gekoppeld aan dataclassificatie en compliance-frameworks, en welke technische mechanismen beschikbaar zijn voor het afdwingen van retentiebeleid via Azure Policy en PowerShell-automatisering. Daarnaast leggen we uit hoe retentiebeleid wordt geïntegreerd in governanceprocessen, hoe kosten worden beheerd via archive tiers en lifecycle management, en hoe organisaties kunnen monitoren en rapporteren over compliance met retentiebeleid. Tot slot laten we zien hoe retentiebeleid wordt gebruikt voor forensische onderzoeken en hoe het bijdraagt aan het voldoen aan vereisten van BIO, ISO 27001, NIS2 en andere relevante frameworks voor de Nederlandse publieke sector.

Ontwikkeling van Log Retentiebeleid

Het ontwikkelen van log retentiebeleid begint met het expliciet maken van de doelstellingen en de context waarin het beleid moet functioneren. Voor Nederlandse overheidsorganisaties zijn er drie primaire doelstellingen: het voldoen aan wettelijke en normatieve vereisten zoals vastgelegd in de BIO, ISO 27001 en NIS2, het ondersteunen van forensische onderzoeken na beveiligingsincidenten, en het waarborgen van transparantie en verantwoording richting burgers, toezichthouders en bestuurders. Deze doelstellingen worden vertaald naar concrete retentievereisten die per type log en per dataclassificatie worden vastgelegd. Activiteitenlogs die alle beheeractiviteiten in Azure vastleggen, moeten bijvoorbeeld minimaal 365 dagen worden bewaard voor algemene compliance-doeleinden, maar voor hoog-risico-processen of ketenvoorzieningen kunnen termijnen van vijf tot zeven jaar worden vereist om aan archief- en sectorspecifieke verplichtingen te voldoen. Security logs die informatie bevatten over bedreigingen, waarschuwingen en incidenten, hebben vaak langere retentieperiodes nodig omdat deze essentieel zijn voor het detecteren van geavanceerde persistente bedreigingen (APT) die maanden kunnen duren voordat zij worden ontdekt. Resource logs die operationele informatie bevatten over de werking van individuele resources, hebben doorgaans kortere retentieperiodes omdat deze minder relevant zijn voor compliance-doeleinden, maar moeten nog steeds voldoende lang worden bewaard voor troubleshooting en performance-analyse.

De koppeling tussen retentiebeleid en dataclassificatie is essentieel voor een logische en onderbouwde strategie. Data die is geclassificeerd als 'Geheim' of 'Zeer Vertrouwelijk' vereist langere retentieperiodes omdat toegang tot deze data kritiek is en eventuele incidenten uitgebreid moeten worden onderzocht. Data die is geclassificeerd als 'Openbaar' of 'Intern' kan kortere retentieperiodes hebben, maar moet nog steeds voldoen aan minimale compliance-vereisten. Deze koppeling zorgt ervoor dat retentiebeleid aansluit bij de risicoprofielen van verschillende data en dat resources met hoog-risico data automatisch langere retentieperiodes krijgen toegewezen. Het beleid moet expliciet vastleggen welke retentieperiodes gelden voor welke dataclassificaties, zodat beheerders en auditors kunnen verifiëren dat het beleid correct wordt toegepast. Daarnaast moet het beleid rekening houden met sectorspecifieke vereisten, zoals de archiefwet die voor bepaalde overheidsdata retentieperiodes van zeven jaar of langer vereist. Door deze verschillende lagen van vereisten te combineren ontstaat een gelaagd retentiebeleid dat zowel compliance als praktische haalbaarheid ondersteunt.

Compliance-frameworks vormen een belangrijke input voor het ontwikkelen van retentiebeleid. De Baseline Informatiebeveiliging Overheid (BIO) norm 12.04 vereist dat organisaties gebeurtenissen loggen en audittrails bijhouden voor alle kritieke systemen en processen, waarbij de bewaartermijn moet aansluiten bij de risicobeoordeling en wettelijke kaders. ISO 27001 controle A.12.4.1 vereist eveneens logging van gebeurtenissen en het bijhouden van audittrails, waarbij auditors verwachten dat de gekozen retentieperiode is onderbouwd op basis van risicobeoordelingen en wettelijke kaders. De NIS2-richtlijn Artikel 21 stelt specifieke eisen aan essentiële en belangrijke entiteiten met betrekking tot incident reporting en logging van beveiligingsgebeurtenissen, waarbij organisaties moeten kunnen aantonen dat zij beschikken over adequate logging en monitoring capaciteiten. De Algemene Verordening Gegevensbescherming (AVG) Artikel 32 verplicht organisaties om passende technische en organisatorische maatregelen te treffen om persoonsgegevens te beveiligen, waarbij logging en monitoring van toegang tot persoonsgegevens een essentieel onderdeel vormt. Het retentiebeleid moet expliciet verwijzen naar deze frameworks en aangeven hoe de gekozen retentieperiodes aansluiten bij de vereisten van elk framework. Door deze koppeling te documenteren kunnen organisaties tijdens audits aantonen dat het beleid is ontwikkeld op basis van een grondige analyse van relevante wet- en regelgeving en dat de gekozen retentieperiodes onderbouwd zijn.

Het ontwikkelen van retentiebeleid vereist ook aandacht voor operationele praktijk en kostenbeheer. Langere retentieperiodes bieden meer data voor forensische onderzoeken en compliance-audits, maar leiden tot hogere opslagkosten. Het is daarom belangrijk om een balans te vinden tussen compliance-vereisten en kostenbeheer, waarbij wordt overwogen om oudere logs naar archive tiers te verplaatsen voor kostenoptimalisatie terwijl de data nog steeds beschikbaar blijft voor query's. Het beleid moet expliciet vastleggen wanneer data kan worden gearchiveerd en welke archive tiers beschikbaar zijn, zodat beheerders weten hoe zij kosten kunnen optimaliseren zonder compliance te schaden. Daarnaast moet het beleid rekening houden met de praktische haalbaarheid van het beheren van lange retentieperiodes, waarbij wordt overwogen of de organisatie beschikt over de benodigde capaciteit en expertise om lange retentieperiodes effectief te beheren. Door deze praktische overwegingen op te nemen in het beleid ontstaat een realistisch en haalbaar retentiebeleid dat zowel compliance als operationele praktijk ondersteunt.

Technische Implementatie van Retentiebeleid

Gebruik PowerShell-script log-retention-policies.ps1 (functie Invoke-Implementation) – Implementeren en configureren van log retentiebeleid voor Azure resources.

De technische implementatie van retentiebeleid begint met het configureren van retentie-instellingen op het niveau van Log Analytics Workspaces. Elke workspace kan worden geconfigureerd met een standaard retentieperiode die van toepassing is op alle tabellen binnen de workspace, of met specifieke retentie-instellingen per tabel voor meer gedetailleerde controle. De retentie-instellingen worden geconfigureerd via de Azure Portal door te navigeren naar de Log Analytics Workspace, te selecteren op 'Usage en estimated costs' en vervolgens 'Data retention' te kiezen. Hier kan de retentieperiode worden ingesteld van 30 tot 730 dagen, waarbij 365 dagen de minimale aanbevolen waarde is voor compliance-doeleinden. Voor organisaties die langere retentieperiodes nodig hebben, kunnen logs worden geëxporteerd naar Azure Storage-accounts met immutable storage, waardoor data voor langere periodes kan worden bewaard zonder de beperkingen van de standaard 730 dagen retentie in Log Analytics. Deze export functionaliteit maakt het mogelijk om logs voor periodes van vijf tot zeven jaar te bewaren, wat essentieel kan zijn voor organisaties die moeten voldoen aan archiefwet-vereisten of sectorspecifieke compliance-frameworks.

Azure Policy vormt het primaire mechanisme voor het afdwingen van retentiebeleid tenant-breed. Policy-definities kunnen worden gemaakt die controleren of Log Analytics Workspaces de juiste retentie-instellingen hebben, of die diagnostic settings afdwingen die logs exporteren naar workspaces met de juiste retentie-configuratie. Deze policies worden toegewezen aan management groups of subscriptions, waardoor nieuwe resources automatisch de juiste retentie-instellingen meekrijgen en bestaande resources kunnen worden gecontroleerd op compliance. Wanneer een resource niet voldoet aan het retentiebeleid, markeert de policy de resource als non-compliant en kan optioneel een deployIfNotExists-actie worden gebruikt om automatisch de juiste configuratie aan te maken. Deze automatische remediatie zorgt ervoor dat afwijkingen van het beleid snel worden opgelost zonder handmatige interventie. Voor organisaties die liever PowerShell gebruiken, kan een periodiek script alle resources langsgaan, retentie-instellingen controleren en eventuele afwijkingen rapporteren via e-mail, Teams of een ticketingsysteem. Het PowerShell-script log-retention-policies.ps1 dat bij deze baseline hoort, biedt functionaliteit voor het inventariseren van retentie-instellingen, het controleren van compliance met beleid en het ondersteunen van remediatie door niet-conforme configuraties zichtbaar te maken.

Diagnostic settings vormen een kritieke component van retentiebeleid-implementatie, omdat deze bepalen welke logs worden geëxporteerd naar Log Analytics Workspaces en hoe lang deze logs beschikbaar blijven. Diagnostic settings kunnen worden geconfigureerd op verschillende niveaus: subscription-niveau voor activiteitenlogs, resource-niveau voor resource logs, en service-niveau voor specifieke Azure-services zoals Key Vault, Storage Accounts of Virtual Machines. Elke diagnostic setting moet worden geconfigureerd om logs door te sturen naar een Log Analytics Workspace met de juiste retentie-configuratie, waarbij wordt gekozen welke logcategorieën worden geëxporteerd op basis van de dataclassificatie en het risicoprofiel van de resource. Voor hoog-risico resources moeten alle beschikbare logcategorieën worden geëxporteerd, terwijl voor laag-risico resources kan worden volstaan met alleen security-relevante logs. De retentie-instellingen op de diagnostic setting zelf kunnen worden gebruikt voor aanvullende controle, waarbij een retention policy wordt geconfigureerd die bepaalt hoe lang logs worden bewaard voordat zij automatisch worden verwijderd. Deze retention policy werkt in combinatie met de retentie-instellingen op de Log Analytics Workspace, waarbij de kortste retentieperiode van toepassing is.

Archive tiers en lifecycle management bieden mogelijkheden voor kostenoptimalisatie terwijl lange retentieperiodes worden behouden. Azure Log Analytics ondersteunt archive tiers waarbij oude logs automatisch worden verplaatst naar goedkopere opslagklassen wanneer zij niet langer frequent worden geraadpleegd. Deze archive tiers bieden dezelfde query-mogelijkheden als reguliere logs, maar met iets langere responsetijden en aanzienlijk lagere opslagkosten. Lifecycle management kan worden geconfigureerd om logs automatisch te verplaatsen naar archive tiers na een bepaalde periode, bijvoorbeeld na 90 dagen voor logs die niet langer nodig zijn voor dagelijkse monitoring maar nog wel beschikbaar moeten blijven voor forensische onderzoeken. Voor nog langere retentieperiodes kunnen logs worden geëxporteerd naar Azure Storage-accounts met immutable storage, waarbij lifecycle management wordt gebruikt om data automatisch te verplaatsen van hot- naar cool- naar archive-storage tiers naarmate de data ouder wordt. Deze gelaagde aanpak zorgt ervoor dat organisaties lange retentieperiodes kunnen realiseren tegen geoptimaliseerde kosten, waarbij recente logs snel beschikbaar zijn voor query's en oudere logs goedkoop maar veilig worden opgeslagen voor compliance-doeleinden.

Governance, Monitoring en Continue Verbetering

Gebruik PowerShell-script log-retention-policies.ps1 (functie Invoke-Monitoring) – Periodiek controleren of retentie-instellingen voldoen aan beleid.

Governance rond log retentiebeleid vereist expliciete processen en verantwoordelijkheden om te waarborgen dat het beleid correct wordt toegepast en dat afwijkingen snel worden gedetecteerd en opgelost. Het is belangrijk om vast te leggen wie eigenaar is van het retentiebeleid, 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 retentie-instellingen moet via een change request worden beoordeeld op impact op compliance, kosten en forensische mogelijkheden. Deze governance-processen moeten worden gedocumenteerd in het informatiebeveiligingsbeleid en worden geïntegreerd in bestaande change management-processen, zodat retentie-instellingen niet ad-hoc worden aangepast zonder overzicht over de keteneffecten. Daarnaast moeten procedures worden 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.

Monitoring van retentiebeleid-compliance is essentieel om te waarborgen dat alle resources voldoen aan de afgesproken normen en dat afwijkingen snel worden gedetecteerd. Het PowerShell-script log-retention-policies.ps1 kan wekelijks of maandelijks worden gedraaid om per resource een overzicht te genereren van retentie-instellingen en compliance-status. De resultaten worden bij voorkeur opgeslagen in een centrale Log Analytics-workspace of een governance-database, waarin dashboards laten zien welke resources 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 resource niet langer voldoet aan de minimale retentie-eisen. Deze proactieve monitoring voorkomt dat compliance-problemen onopgemerkt blijven en zorgt ervoor dat afwijkingen snel worden opgelost voordat zij leiden tot dataverlies of compliance-schendingen.

Continue verbetering krijgt vorm via periodieke evaluaties van het retentiebeleid, bijvoorbeeld in het kader van de jaarlijkse BIO- of ISO 27001-cyclus. Tijdens deze evaluaties wordt geanalyseerd of de gekozen retentieperiodes 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 retentieperiodes te verlengen, extra logdoelen toe te voegen of aanvullende metadata op te nemen in logs 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 retentiebeleid een levend onderwerp dat meegroeit met de organisatie en het dreigingslandschap. Daarnaast moeten kosten regelmatig worden geëvalueerd om te verifiëren dat retentiebeleid kosteneffectief wordt geïmplementeerd en dat archive tiers en lifecycle management optimaal worden benut voor kostenoptimalisatie.

Rapportage over retentiebeleid-compliance is essentieel voor verantwoording richting bestuurders, auditors en toezichthouders. Maandelijkse of driemaandelijkse rapportages moeten worden gegenereerd die laten zien welke resources compliant zijn met het retentiebeleid, welke afwijkingen zijn gedetecteerd en opgelost, en welke trends zichtbaar zijn in compliance-status over tijd. Deze rapportages moeten worden gepresenteerd aan het management en worden gebruikt als input voor besluitvorming over investeringen in logging-infrastructuur en compliance-initiatieven. Tijdens audits moeten deze rapportages beschikbaar zijn om aan te tonen dat de organisatie actief toezicht houdt op retentiebeleid en dat afwijkingen systematisch worden gedetecteerd en opgelost. Door deze rapportages te koppelen aan compliance-frameworks zoals BIO, ISO 27001 en NIS2 ontstaat direct inzicht in hoe retentiebeleid bijdraagt aan het voldoen aan deze vereisten en waar nog verbeteringen mogelijk zijn.

Compliance, Audit en Verantwoording

Gebruik PowerShell-script log-retention-policies.ps1 (functie Invoke-Remediation) – Ondersteunen van remediatie door niet-conforme retentie-instellingen zichtbaar te maken.

Log retentiebeleid 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 retentiebeleid waarin logs minimaal 365 dagen beschikbaar zijn 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 retentiebeleid structureel en aantoonbaar wordt beheerd. Het is belangrijk om tijdens audits te kunnen demonstreren dat het retentiebeleid is ontwikkeld op basis van een grondige analyse van relevante wet- en regelgeving, dat de gekozen retentieperiodes zijn onderbouwd op basis van risicobeoordelingen en dat het beleid technisch wordt afgedwongen via Azure Policy en periodieke controles.

Ook ISO 27001 en de onderliggende controls rond logbeheer en audittrails stellen eisen aan retentiebeleid. Hoewel de norm geen vaste aantallen dagen voorschrijft, verwachten auditors dat de gekozen retentieperiode is onderbouwd op basis van risicobeoordelingen en wettelijke kaders, en dat deze consequent wordt toegepast in alle relevante systemen. Door retentiebeleid 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 (retentie-instellingen, Azure Policy, monitoring) en organisatorische maatregelen (procedures, rollen, evaluaties) levert overtuigend auditbewijs op dat de norm in de praktijk wordt nageleefd. Tijdens ISO 27001-certificering audits moeten organisaties kunnen aantonen dat retentiebeleid is gedocumenteerd, dat retentie-instellingen correct zijn geconfigureerd en dat periodieke controles worden uitgevoerd om compliance te verifiëren.

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 logs lang genoeg te bewaren en centraal te correleren met andere logbronnen, kunnen organisaties aantonen dat zij de vereiste mate van weerbaarheid en transparantie realiseren. Retentiebeleid moet expliciet rekening houden met de vereisten van NIS2, waarbij wordt overwogen of langere retentieperiodes nodig zijn voor essentiële en belangrijke entiteiten dan voor reguliere organisaties. Voor ketenvoorzieningen en samenwerkingsverbanden is het daarbij belangrijk om afspraken over logdeling en retentie op te nemen in contracten, verwerkersovereenkomsten en convenanten. Tijdens NIS2-compliance-controles moeten organisaties kunnen aantonen dat retentiebeleid is ontwikkeld met specifieke aandacht voor de vereisten van de richtlijn en dat retentie-instellingen voldoen aan de minimale eisen voor essentiële en belangrijke entiteiten.

In het kader van de AVG speelt retentiebeleid 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 retentiebeleid moet worden afgestemd met de privacy officer en dat waar mogelijk pseudonimisering, toegangsbeperking en strikte autorisatie worden toegepast. Retentieperiodes voor logs die persoonsgegevens bevatten moeten worden gebaseerd op de noodzaak voor beveiliging en compliance, waarbij wordt overwogen of kortere retentieperiodes mogelijk zijn zonder de beveiligingsdoelstellingen te schaden. 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.

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 Inventarisatie en controle van log retentie-instellingen in Azure. .DESCRIPTION Dit script inventariseert per Log Analytics Workspace en diagnostic setting welke retentie-instellingen zijn geconfigureerd en controleert of deze voldoen aan het vastgestelde retentiebeleid (bijvoorbeeld minimaal 365 dagen). Het script is bedoeld als controle waarmee cloud- en securityteams snel kunnen zien of retentie-instellingen aansluiten bij de beleidsafspraken en compliance-vereisten. .NOTES Filename: log-retention-policies.ps1 Author: Nederlandse Baseline voor Veilige Cloud Version: 1.0 Related JSON: content/azure/logging-monitoring/log-retention-policies.json #> #Requires -Version 5.1 #Requires -Modules Az.Accounts, Az.Monitor, Az.OperationalInsights [CmdletBinding()] param( [Parameter()] [switch]$Monitoring, [Parameter()] [switch]$Remediation, [Parameter()] [int]$MinimumRetentionDays = 365 ) $ErrorActionPreference = 'Stop' $PolicyName = "Log Retention Policies - Inventory and Compliance" function Connect-RequiredServices { if (-not (Get-AzContext)) { Connect-AzAccount -ErrorAction Stop | Out-Null } } function Get-LogAnalyticsRetentionSettings { <# .SYNOPSIS Haalt retentie-instellingen op voor alle Log Analytics Workspaces. #> $workspaces = Get-AzOperationalInsightsWorkspace -ErrorAction Stop $results = @() foreach ($workspace in $workspaces) { try { $retentionDays = $workspace.RetentionInDays $isNonCompliant = $false $note = "Retentie voldoet aan ingestelde minimum." if (-not $retentionDays -or $retentionDays -lt $MinimumRetentionDays) { $isNonCompliant = $true $note = "Retentie korter dan gewenste minimum van $MinimumRetentionDays dagen of niet expliciet ingesteld." } $results += [PSCustomObject]@{ WorkspaceName = $workspace.Name ResourceGroupName = $workspace.ResourceGroupName Location = $workspace.Location RetentionInDays = $retentionDays NonCompliant = $isNonCompliant Notes = $note } } catch { Write-Warning "Fout bij ophalen retentie-instellingen voor workspace $($workspace.Name): $_" } } return $results } function Get-DiagnosticSettingsRetention { <# .SYNOPSIS Haalt retentie-instellingen op voor diagnostic settings op subscription-niveau. #> $subscriptions = Get-AzSubscription -ErrorAction Stop $results = @() foreach ($sub in $subscriptions) { try { Set-AzContext -SubscriptionId $sub.Id -ErrorAction Stop | Out-Null $diagSettings = Get-AzDiagnosticSetting -ResourceId "/subscriptions/$($sub.Id)" -ErrorAction SilentlyContinue if (-not $diagSettings) { $results += [PSCustomObject]@{ SubscriptionId = $sub.Id SubscriptionName = $sub.Name HasDiagnosticSetting = $false RetentionEnabled = $false RetentionDays = 0 NonCompliant = $true Notes = "Geen diagnostic settings voor Activity Log gevonden." } continue } foreach ($setting in $diagSettings) { $retentionEnabled = $false $retentionDays = 0 if ($setting.RetentionPolicy -and $setting.RetentionPolicy.Enabled) { $retentionEnabled = $true $retentionDays = $setting.RetentionPolicy.Days } $isNonCompliant = $false $note = "Retentie voldoet aan ingestelde minimum." if (-not $retentionEnabled -or $retentionDays -lt $MinimumRetentionDays) { $isNonCompliant = $true $note = "Retentie niet ingeschakeld of korter dan gewenste minimum van $MinimumRetentionDays dagen." } $results += [PSCustomObject]@{ SubscriptionId = $sub.Id SubscriptionName = $sub.Name HasDiagnosticSetting = $true RetentionEnabled = $retentionEnabled RetentionDays = $retentionDays NonCompliant = $isNonCompliant Notes = $note } } } catch { Write-Warning "Fout bij ophalen diagnostic settings voor subscription $($sub.Name): $_" } } return $results } function Test-Compliance { $workspaceResults = Get-LogAnalyticsRetentionSettings $diagnosticResults = Get-DiagnosticSettingsRetention $totalWorkspaces = $workspaceResults.Count $nonCompliantWorkspaces = ($workspaceResults | Where-Object { $_.NonCompliant -eq $true }).Count $totalSubscriptions = ($diagnosticResults | Select-Object -ExpandProperty SubscriptionId -Unique).Count $nonCompliantSubscriptions = ($diagnosticResults | Where-Object { $_.NonCompliant -eq $true }).Count return [PSCustomObject]@{ TotalWorkspaces = $totalWorkspaces NonCompliantWorkspaces = $nonCompliantWorkspaces TotalSubscriptions = $totalSubscriptions NonCompliantSubscriptions = $nonCompliantSubscriptions MinimumRetentionDays = $MinimumRetentionDays WorkspaceDetails = $workspaceResults DiagnosticDetails = $diagnosticResults } } 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 ("Log Analytics Workspaces totaal : {0}" -f $result.TotalWorkspaces) -ForegroundColor White if ($result.NonCompliantWorkspaces -gt 0) { Write-Host ("Niet-conforme workspaces : {0}" -f $result.NonCompliantWorkspaces) -ForegroundColor Yellow } else { Write-Host ("Niet-conforme workspaces : {0}" -f $result.NonCompliantWorkspaces) -ForegroundColor Green } Write-Host ("Abonnementen totaal : {0}" -f $result.TotalSubscriptions) -ForegroundColor White if ($result.NonCompliantSubscriptions -gt 0) { Write-Host ("Niet-conforme abonnementen : {0}" -f $result.NonCompliantSubscriptions) -ForegroundColor Yellow } else { Write-Host ("Niet-conforme abonnementen : {0}" -f $result.NonCompliantSubscriptions) -ForegroundColor Green } Write-Host ("Minimale gewenste retentie (dagen) : {0}" -f $result.MinimumRetentionDays) -ForegroundColor White if ($result.NonCompliantWorkspaces -gt 0 -or $result.NonCompliantSubscriptions -gt 0) { Write-Host "" -ForegroundColor White Write-Host "[WAARSCHUWING] Eén of meer resources voldoen niet aan het log retentiebeleid." -ForegroundColor Yellow Write-Host " Gebruik de details-uitvoer om te bepalen waar retentie-instellingen moeten worden aangepast" -ForegroundColor Yellow Write-Host " naar minimaal $MinimumRetentionDays dagen." -ForegroundColor Yellow } # Gedetailleerde uitvoer als JSON voor verdere verwerking $output = @{ Summary = @{ TotalWorkspaces = $result.TotalWorkspaces NonCompliantWorkspaces = $result.NonCompliantWorkspaces TotalSubscriptions = $result.TotalSubscriptions NonCompliantSubscriptions = $result.NonCompliantSubscriptions MinimumRetentionDays = $result.MinimumRetentionDays } WorkspaceDetails = $result.WorkspaceDetails DiagnosticDetails = $result.DiagnosticDetails } $output | ConvertTo-Json -Depth 4 } else { $result = Test-Compliance Write-Host "" Write-Host ("Log retentiebeleid: {0} workspace(s) en {1} abonnement(en) gecontroleerd, {2} workspace(s) en {3} abonnement(en) niet-conform." -f ` $result.TotalWorkspaces, $result.TotalSubscriptions, $result.NonCompliantWorkspaces, $result.NonCompliantSubscriptions) } } catch { Write-Error $_ exit 1 } # ================================================================================ # Standaard Invoke-* Functions # ================================================================================ function Invoke-Implementation { <# .SYNOPSIS Voert een implementatie- en configuratiecontrole uit voor log retentiebeleid. .DESCRIPTION Deze functie voert geen automatische remediatie uit, maar levert een gedetailleerd overzicht van retentie-instellingen voor Log Analytics Workspaces en diagnostic settings. Gebruik deze informatie om policies, scripts of handmatige configuratie aan te scherpen. #> [CmdletBinding()] param() try { Connect-RequiredServices $result = Test-Compliance Write-Host "" -ForegroundColor White Write-Host "========================================" -ForegroundColor Cyan Write-Host "Log Retentiebeleid - Implementatiecontrole" -ForegroundColor Cyan Write-Host "========================================" -ForegroundColor Cyan Write-Host ("Log Analytics Workspaces: {0} totaal, {1} niet-conform" -f $result.TotalWorkspaces, $result.NonCompliantWorkspaces) -ForegroundColor White Write-Host ("Abonnementen: {0} totaal, {1} niet-conform" -f $result.TotalSubscriptions, $result.NonCompliantSubscriptions) -ForegroundColor White Write-Host ("Minimale gewenste retentie: {0} dagen" -f $result.MinimumRetentionDays) -ForegroundColor White if ($result.NonCompliantWorkspaces -gt 0) { Write-Host "" -ForegroundColor Yellow Write-Host "Niet-conforme Log Analytics Workspaces:" -ForegroundColor Yellow $result.WorkspaceDetails | Where-Object { $_.NonCompliant -eq $true } | Select-Object WorkspaceName, ResourceGroupName, RetentionInDays, Notes | Format-Table -AutoSize } if ($result.NonCompliantSubscriptions -gt 0) { Write-Host "" -ForegroundColor Yellow Write-Host "Niet-conforme abonnementen (diagnostic settings):" -ForegroundColor Yellow $result.DiagnosticDetails | Where-Object { $_.NonCompliant -eq $true } | Select-Object SubscriptionName, RetentionEnabled, RetentionDays, Notes | Format-Table -AutoSize } Write-Host "" -ForegroundColor Cyan Write-Host "Aanbevelingen:" -ForegroundColor Cyan Write-Host "1. Configureer retentie-instellingen op Log Analytics Workspaces naar minimaal $($result.MinimumRetentionDays) dagen" -ForegroundColor Gray Write-Host "2. Zorg dat diagnostic settings retentiebeleid hebben ingeschakeld met minimaal $($result.MinimumRetentionDays) dagen" -ForegroundColor Gray Write-Host "3. Overweeg Azure Policy te gebruiken om retentiebeleid automatisch af te dwingen" -ForegroundColor Gray Write-Host "4. Voer dit script periodiek uit om compliance te monitoren" -ForegroundColor Gray } catch { Write-Error $_ exit 1 } } function Invoke-Monitoring { <# .SYNOPSIS Voert een monitoringcontrole uit en toont een samenvatting plus JSON-uitvoer. #> [CmdletBinding()] param() 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 ("Log Analytics Workspaces totaal : {0}" -f $result.TotalWorkspaces) -ForegroundColor White Write-Host ("Niet-conforme workspaces : {0}" -f $result.NonCompliantWorkspaces) -ForegroundColor (if ($result.NonCompliantWorkspaces -gt 0) { 'Yellow' } else { 'Green' }) Write-Host ("Abonnementen totaal : {0}" -f $result.TotalSubscriptions) -ForegroundColor White Write-Host ("Niet-conforme abonnementen : {0}" -f $result.NonCompliantSubscriptions) -ForegroundColor (if ($result.NonCompliantSubscriptions -gt 0) { 'Yellow' } else { 'Green' }) Write-Host ("Minimale gewenste retentie (dagen) : {0}" -f $result.MinimumRetentionDays) -ForegroundColor White if ($result.NonCompliantWorkspaces -gt 0 -or $result.NonCompliantSubscriptions -gt 0) { Write-Host "" -ForegroundColor White Write-Host "[WAARSCHUWING] Eén of meer resources voldoen niet aan het log retentiebeleid." -ForegroundColor Yellow } $output = @{ Summary = @{ TotalWorkspaces = $result.TotalWorkspaces NonCompliantWorkspaces = $result.NonCompliantWorkspaces TotalSubscriptions = $result.TotalSubscriptions NonCompliantSubscriptions = $result.NonCompliantSubscriptions MinimumRetentionDays = $result.MinimumRetentionDays } WorkspaceDetails = $result.WorkspaceDetails DiagnosticDetails = $result.DiagnosticDetails } $output | ConvertTo-Json -Depth 4 } catch { Write-Error $_ exit 1 } } function Invoke-Remediation { <# .SYNOPSIS Ondersteunt remediatie door niet-conforme resources zichtbaar te maken. .DESCRIPTION Deze functie past geen configuraties aan, maar geeft duidelijke instructies welke resources en retentie-instellingen moeten worden verbeterd om aan het retentiebeleid te voldoen. #> [CmdletBinding()] param() try { Connect-RequiredServices $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 retentie-instellingen bij te werken." -ForegroundColor Yellow $nonCompliantWorkspaces = $result.WorkspaceDetails | Where-Object { $_.NonCompliant -eq $true } if ($nonCompliantWorkspaces) { Write-Host "" -ForegroundColor White Write-Host "Log Analytics Workspaces met onvoldoende retentie-instellingen:" -ForegroundColor Yellow $nonCompliantWorkspaces | Select-Object WorkspaceName, ResourceGroupName, RetentionInDays, Notes | Format-Table -AutoSize Write-Host "" -ForegroundColor Cyan Write-Host "Remediatie-instructies voor Log Analytics Workspaces:" -ForegroundColor Cyan Write-Host "1. Navigeer naar Azure Portal > Log Analytics Workspace" -ForegroundColor Gray Write-Host "2. Selecteer de workspace > Usage en estimated costs > Data retention" -ForegroundColor Gray Write-Host "3. Stel de retentieperiode in op minimaal $($result.MinimumRetentionDays) dagen" -ForegroundColor Gray } $nonCompliantSubscriptions = $result.DiagnosticDetails | Where-Object { $_.NonCompliant -eq $true } if ($nonCompliantSubscriptions) { Write-Host "" -ForegroundColor White Write-Host "Abonnementen met ontbrekende of onvoldoende retentie-instellingen:" -ForegroundColor Yellow $nonCompliantSubscriptions | Select-Object SubscriptionName, RetentionEnabled, RetentionDays, Notes | Format-Table -AutoSize Write-Host "" -ForegroundColor Cyan Write-Host "Remediatie-instructies voor diagnostic settings:" -ForegroundColor Cyan Write-Host "1. Navigeer naar Azure Portal > Subscription > Activity log" -ForegroundColor Gray Write-Host "2. Selecteer Export Activity Log > Diagnostische instellingen" -ForegroundColor Gray Write-Host "3. Configureer of wijzig de diagnostic setting" -ForegroundColor Gray Write-Host "4. Schakel Retention policy in en stel in op minimaal $($result.MinimumRetentionDays) dagen" -ForegroundColor Gray } if (-not $nonCompliantWorkspaces -and -not $nonCompliantSubscriptions) { Write-Host "" -ForegroundColor Green Write-Host "Alle gecontroleerde resources voldoen aan het minimale retentiebeleid." -ForegroundColor Green } } catch { Write-Error $_ exit 1 } }

Risico zonder implementatie

Risico zonder implementatie
High: Zonder gestructureerd log retentiebeleid ontstaat inconsistentie in bewaartermijnen, kunnen organisaties niet voldoen aan compliance-vereisten van BIO, ISO 27001 en NIS2, en ontbreekt de basis voor forensische onderzoeken na beveiligingsincidenten. Dit leidt tot dataverlies, compliance-schendingen, onnodige kosten en verlies van vertrouwen bij burgers en toezichthouders.

Management Samenvatting

Ontwikkel een log retentiebeleid dat retentieperiodes koppelt aan dataclassificatie en compliance-frameworks, configureer retentie-instellingen op Log Analytics Workspaces en diagnostic settings, dwing beleid af via Azure Policy, en monitoor compliance periodiek via PowerShell-scripts. Gebruik archive tiers en lifecycle management voor kostenoptimalisatie terwijl lange retentieperiodes worden behouden.