💼 Management Samenvatting
In grote Azure-omgevingen met meerdere abonnementen, resourcegroepen en workloads ontstaan vaak tientallen of zelfs honderden Log Analytics workspaces zonder centrale governance. Deze gefragmenteerde aanpak leidt tot inconsistente retentie-instellingen, onbeheersbare kosten, compliance-risico's en het onvermogen om correlaties te leggen tussen gebeurtenissen in verschillende workloads. Een gestructureerde multi-workspace strategie met duidelijke governance-principes vormt de basis voor effectieve monitoring, compliance en kostenbeheersing.
✓ Multi-abonnement omgevingen
✓ Enterprise organisaties
Zonder een doordachte multi-workspace governance-strategie zien we in de praktijk dat organisaties ad-hoc workspaces aanmaken voor elk nieuw project of abonnement, waardoor na verloop van tijd tientallen of honderden workspaces ontstaan zonder centrale regie. Deze fragmentatie leidt tot aanzienlijke problemen: retentie-instellingen verschillen per workspace waardoor compliance-vereisten niet consistent worden nageleefd, kosten lopen onbeheersbaar op doordat data dubbel wordt verzameld en opgeslagen, diagnostische instellingen worden niet consistent geconfigureerd waardoor belangrijke logdata ontbreekt, en het is onmogelijk om correlaties te leggen tussen gebeurtenissen in verschillende workloads omdat data verspreid staat over tientallen workspaces. Bovendien ontbreekt vaak een centraal overzicht van welke workspaces actief zijn, wie eigenaar is van elke workspace, welke retentie-instellingen zijn geconfigureerd en hoe workspaces zijn gekoppeld aan compliance-frameworks zoals de BIO, ISO 27001 en NIS2. Deze situatie maakt het onmogelijk om richting bestuurders en auditors aan te tonen dat logging en monitoring op orde zijn, en leidt tot compliance-risico's, onnodige kosten en verminderde zichtbaarheid op beveiligingsincidenten.
Connection:
Connect-AzAccountRequired Modules: Az.Accounts, Az.OperationalInsights, Az.Monitor, Az.Resources, Az.PolicyInsights
Implementatie
Dit artikel beschrijft een gestructureerde aanpak voor het beheren van meerdere Log Analytics workspaces binnen de Nederlandse Baseline voor Veilige Cloud. We behandelen architectuurkeuzes zoals de inrichting van een hiërarchische workspace-structuur met centrale security workspaces en gedecentraliseerde operationele workspaces, consolidatiestrategieën voor het samenvoegen van overbodige workspaces, governance-principes voor naamgeving, tagging en eigenaarschap, implementatie van Azure Policy voor automatische enforcement van workspace-configuraties, afstemming van retentie-instellingen op compliance-frameworks zoals de Archiefwet, BIO en ISO 27001, en inrichting van role-based access control voor scheiding van ontwikkel- en beheertaken. Daarnaast gaan we in op het beheren van workspaces via Infrastructure as Code, configuratie van data-export naar SIEM-systemen en externe opslag voor langetermijnbewaring, implementatie van kostenbeheersing door middel van data-cap en ingestiebeperkingen, en het opzetten van periodieke reviewcycli voor workspace-governance. Het artikel sluit af met praktische richtlijnen voor consolidatie van bestaande workspaces en toont hoe het bijbehorende PowerShell-script log-analytics-workspaces.ps1 kan worden gebruikt om alle workspaces te inventariseren, compliance te monitoren en governance te verbeteren.
Multi-Workspace Architectuur en Ontwerpprincipes
Een effectieve multi-workspace strategie begint bij het maken van bewuste keuzes over wanneer een nieuwe workspace nodig is en wanneer bestaande workspaces kunnen worden hergebruikt. In tegenstelling tot de verleiding om voor elk project of abonnement een aparte workspace aan te maken, adviseren we een hiërarchische workspace-architectuur waarbij workspaces worden gegroepeerd op basis van organisatorische grenzen, compliance-vereisten en geografische locatie. Voor Nederlandse overheidsorganisaties betekent dit vaak: één centrale security workspace voor alle beveiligings- en auditlogs die langdurig worden bewaard voor compliance-doeleinden, één workspace per omgeving (productie, acceptatie, ontwikkeling) voor operationele monitoring, en eventueel één workspace per organisatorische eenheid of business unit voor specifieke workloads. Deze structuur maakt het mogelijk om retentie-instellingen per workspace af te stemmen op compliance-vereisten: security workspaces kunnen bijvoorbeeld zeven jaar worden bewaard voor auditdoeleinden, terwijl ontwikkelomgevingen na negentig dagen kunnen worden verwijderd om kosten te besparen. Een veelgemaakte fout is om voor elke resource of applicatie een aparte workspace aan te maken. Dit leidt tot gefragmenteerde monitoring, hogere kosten door duplicate data-inname en het onvermogen om correlaties te leggen tussen gebeurtenissen in verschillende workloads. Daarom is het verstandig om workspaces te groeperen op basis van organisatorische grenzen, compliance-vereisten en geografische locatie. Voor een middelgrote overheidsorganisatie kan dit bijvoorbeeld betekenen: één centrale workspace voor alle productie-Azure-resources, één workspace voor hybride servers en on-premises workloads, en één workspace voor security-specifieke logs die worden geëxporteerd naar een SIEM-systeem. Binnen elke workspace configureert u vervolgens tabellen met passende retentie-instellingen: auditlogs en security events kunnen lang worden bewaard, terwijl performance metrics en verbose application logs kortere retentieperioden krijgen. Naast workspace-architectuur is het cruciaal om diagnostische instellingen consistent te configureren voor alle kritieke Azure-resources. Diagnostische instellingen bepalen welke platformlogs en metrische data worden verzameld en waar deze naartoe worden gestuurd. Voor resources zoals Virtual Machines, Storage Accounts, Key Vaults en Azure AD moet u expliciet configureren dat auditlogs, security events en operationele logs worden doorgestuurd naar de juiste Log Analytics workspace. Zonder deze configuratie blijven belangrijke gebeurtenissen zoals mislukte authenticatiepogingen, wijzigingen in beveiligingsinstellingen en prestatieproblemen onzichtbaar, waardoor incidenten te laat worden gedetecteerd en compliance-vereisten niet worden nageleefd. Het PowerShell-script log-analytics-workspaces.ps1 sluit hierbij aan door te controleren of diagnostische instellingen aanwezig zijn op alle resources die als kritiek zijn gemarkeerd, en door te rapporteren welke resources nog niet correct zijn geïnstrumenteerd.
Workspace Governance: Naamgeving, Tagging en Eigenaarschap
Effectieve governance van meerdere Log Analytics workspaces vereist duidelijke standaarden voor naamgeving, tagging en eigenaarschap. Zonder deze standaarden ontstaan na verloop van tijd workspaces met inconsistente namen, ontbrekende tags en onduidelijk eigenaarschap, waardoor het onmogelijk wordt om te bepalen welke workspaces actief zijn, wie verantwoordelijk is voor elke workspace en hoe workspaces zijn gekoppeld aan compliance-frameworks. Voor Nederlandse overheidsorganisaties adviseren we een naamgevingsconventie die informatie bevat over de omgeving (bijvoorbeeld prod, acc, dev), het doel (security, operations, compliance) en eventueel de organisatorische eenheid. Een voorbeeld van een goede naamgeving is: law-prod-security-we, waarbij law staat voor Log Analytics Workspace, prod voor productie, security voor het doel en we voor de organisatorische eenheid. Naast naamgeving is tagging essentieel voor governance en kostenbeheersing. Elke workspace moet minimaal de volgende tags bevatten: Environment (prod, acc, dev), Owner (e-mailadres of teamnaam van de eigenaar), InformationClassification (bijvoorbeeld Public, Internal, Confidential, Secret), ComplianceFramework (bijvoorbeeld BIO, ISO27001, NIS2), en RetentionPeriod (bijvoorbeeld 90d, 1y, 7y). Deze tags maken het mogelijk om workspaces te filteren en te groeperen voor rapportage, kostenallocatie en compliance-audits. Het PowerShell-script log-analytics-workspaces.ps1 controleert of alle vereiste tags aanwezig zijn en rapporteert welke workspaces ontbrekende of inconsistente tags hebben. Eigenaarschap is cruciaal voor governance omdat elke workspace een duidelijke eigenaar moet hebben die verantwoordelijk is voor het beheer van de bijbehorende configuraties, het monitoren van kosten en het waarborgen van compliance. In de context van Nederlandse overheidsorganisaties is het verstandig om dit eigenaarschap te koppelen aan bestaande rollen binnen de informatiebeveiligings- en continuïteitsorganisatie, zoals lijnmanagers, applicatie-eigenaren en de CISO. Leg vast dat grote wijzigingen in workspace-configuraties altijd via het changeproces lopen en dat bij ingrijpende wijzigingen – bijvoorbeeld het wijzigen van retentie-instellingen voor auditlogs – expliciet akkoord van compliance of security nodig is.
Gebruik PowerShell-script log-analytics-workspaces.ps1 (functie Invoke-Monitoring) – Voert een tenant-brede inventarisatie uit van alle Log Analytics workspaces, controleert compliance met governance-standaarden en rapporteert inconsistente configuraties..
Consolidatiestrategieën en Workspace Rationalisatie
In bestaande Azure-omgevingen zien we vaak dat organisaties tientallen of zelfs honderden workspaces hebben zonder duidelijke structuur of governance. Deze fragmentatie leidt tot aanzienlijke problemen: inconsistente retentie-instellingen, onbeheersbare kosten, compliance-risico's en het onvermogen om correlaties te leggen tussen gebeurtenissen in verschillende workloads. Consolidatie van workspaces is daarom essentieel voor het verbeteren van governance, kostenbeheersing en compliance. Het consolidatieproces begint bij een grondige inventarisatie van alle bestaande workspaces, waarbij wordt geanalyseerd welke workspaces actief zijn, welke data wordt verzameld, welke retentie-instellingen zijn geconfigureerd en hoe workspaces zijn gekoppeld aan resources en diagnostische instellingen. Het PowerShell-script log-analytics-workspaces.ps1 kan hierbij helpen door een complete inventarisatie te genereren van alle workspaces in alle abonnementen, inclusief configuratiegegevens, retentie-instellingen, tags en koppelingen aan resources. Op basis van deze inventarisatie kunt u een consolidatieplan opstellen dat identificeert welke workspaces kunnen worden samengevoegd, welke workspaces overbodig zijn geworden en welke workspaces moeten worden behouden. Bij het samenvoegen van workspaces is het belangrijk om te realiseren dat data uit verschillende workspaces niet automatisch kan worden samengevoegd: u moet diagnostische instellingen en agents herconfigureren om data naar de nieuwe workspace te sturen, en bestaande data in de oude workspace blijft beschikbaar totdat de retentieperiode is verstreken. Een praktische aanpak voor consolidatie is om te beginnen met het identificeren van workspaces die weinig of geen data genereren, workspaces zonder duidelijke eigenaar, en workspaces met inconsistente of ontbrekende tags. Deze workspaces zijn vaak kandidaten voor consolidatie of verwijdering. Vervolgens kunt u workspaces groeperen op basis van omgeving, organisatorische eenheid of compliance-vereisten, en een plan opstellen voor het samenvoegen van gerelateerde workspaces. Het is belangrijk om dit proces zorgvuldig te plannen en te testen, omdat wijzigingen in workspace-configuraties impact kunnen hebben op bestaande queries, dashboards en alertregels die afhankelijk zijn van specifieke workspaces.
Azure Policy Enforcement voor Workspace Governance
Azure Policy biedt krachtige mogelijkheden voor het automatisch enforceen van governance-standaarden voor Log Analytics workspaces. In plaats van handmatig te controleren of workspaces voldoen aan naamgevingsconventies, tagging-vereisten en retentie-instellingen, kunnen organisaties Azure Policy gebruiken om automatisch te controleren of nieuwe workspaces voldoen aan deze standaarden en om bestaande workspaces te herstellen naar compliant configuraties. Voor Nederlandse overheidsorganisaties adviseren we het implementeren van policies die vereisen dat alle workspaces minimaal de volgende tags bevatten: Environment, Owner, InformationClassification, ComplianceFramework en RetentionPeriod. Daarnaast kunnen policies worden geconfigureerd om te vereisen dat productieworkspaces een minimale retentieperiode van 365 dagen hebben, en dat security workspaces een retentieperiode van zeven jaar hebben conform de Archiefwet. Het PowerShell-script log-analytics-workspaces.ps1 kan worden gebruikt om te controleren of Azure Policies correct zijn geconfigureerd en of workspaces voldoen aan policy-vereisten. Het script rapporteert welke workspaces non-compliant zijn en kan, indien gewenst, voorstellen doen voor het herstellen van non-compliant configuraties. Daarnaast kan het script worden gebruikt om periodiek te controleren of nieuwe workspaces voldoen aan governance-standaarden en om waarschuwingen te genereren wanneer non-compliant workspaces worden gedetecteerd.
Gebruik PowerShell-script log-analytics-workspaces.ps1 (functie Invoke-Remediation) – Ondersteunt verbetering van workspace-governance door non-compliant workspaces te identificeren en – indien gewenst – standaard-configuraties en tags toe te passen..
Kostenbeheersing in Multi-Workspace Omgevingen
Azure Monitor kan aanzienlijke kosten genereren wanneer logdata onbeperkt wordt verzameld zonder strategie voor kostenbeheersing, vooral in omgevingen met meerdere workspaces. Voor Nederlandse overheidsorganisaties is het daarom essentieel om expliciete retentie-instellingen te configureren die balanceren tussen compliance-vereisten en kostenoptimalisatie, en om data-inname te monitoren en te beheren over alle workspaces heen. De Archiefwet vereist bijvoorbeeld dat bepaalde categorieën administratieve gegevens langdurig worden bewaard, terwijl de AVG stelt dat persoonsgegevens niet langer mogen worden bewaard dan noodzakelijk. Azure Monitor biedt flexibele mogelijkheden om deze tegenstrijdige eisen op te lossen door per tabel of per workspace verschillende retentieperioden te configureren. Voor auditlogs en security events die relevant zijn voor compliance-audits adviseren we een retentieperiode van minimaal 365 dagen, en voor kritieke beveiligingsgebeurtenissen zelfs zeven jaar conform de Archiefwet. Voor performance metrics en verbose application logs kan een kortere retentieperiode van 30 tot 90 dagen volstaan, omdat deze data primair wordt gebruikt voor operationele troubleshooting en niet voor langetermijn-auditdoeleinden. Daarnaast biedt Azure Monitor de mogelijkheid om data te exporteren naar externe opslag zoals Azure Blob Storage of een SIEM-systeem voor langetermijnbewaring, waardoor u kosten kunt besparen door korte retentie in Log Analytics te combineren met langetermijnopslag elders. Kostenbeheersing gaat verder dan alleen retentie-instellingen. Azure Monitor biedt verschillende mechanismen om data-inname te beperken, zoals data-cap instellingen die automatisch data-inname stoppen wanneer een maandelijks limiet wordt bereikt, en ingestiebeperkingen die voorkomen dat overmatige logging leidt tot onverwachte kosten. Voor productieomgevingen is het verstandig om data-cap in te stellen op basis van historische verbruikspatronen, maar wel met een buffer voor onverwachte pieken tijdens incidenten. Het PowerShell-script log-analytics-workspaces.ps1 kan hier input voor leveren door te rapporteren welke workspaces het meeste data verbruiken, welke tabellen de grootste volumes genereren en of data-cap instellingen actief zijn.
Compliance, Audit en Bewijsvoering in Multi-Workspace Omgevingen
Multi-workspace configuraties spelen een belangrijke rol in het aantonen van compliance met uiteenlopende kaders zoals de BIO, ISO 27001 en NIS2. Toezichthouders en auditors vragen steeds vaker niet alleen óf logging is ingericht, maar ook hoe de organisatie waarborgt dat relevante gebeurtenissen tijdig worden gesignaleerd, opgeslagen en geanalyseerd over alle workspaces heen. Tijdens audits worden bijvoorbeeld vragen gesteld als: hoe weet u dat alle kritieke resources correct zijn geïnstrumenteerd? Hoe borgt u dat auditlogs lang genoeg worden bewaard voor compliance-vereisten? En hoe voorkomt u dat wijzigingen in architectuur leiden tot verlies van monitoring-capaciteiten? Een goed gedocumenteerde multi-workspace architectuur, gecombineerd met aantoonbare reviewcycli en scriptgestuurde controles, vormt het antwoord op deze vragen. Voor de BIO sluiten multi-workspace configuraties vooral aan bij de normen rond logging, monitoring en incidentrespons. Door in het informatiebeveiligingsbeleid expliciet op te nemen dat kritieke processen ondersteund worden door Log Analytics workspaces met gedefinieerde retentie-instellingen en diagnostische instellingen, en door de concrete invulling te documenteren per workload, kan de organisatie richting ENSIA-auditors onderbouwen dat monitoring structureel is ingericht. Het PowerShell-script log-analytics-workspaces.ps1 levert daarbij concreet auditbewijs in de vorm van exports die tonen welke workspaces actief zijn, welke retentie-instellingen zijn geconfigureerd, welke resources diagnostische instellingen hebben en hoe deze zijn gekoppeld aan incidentresponse-processen. Deze exports kunnen worden bewaard in een auditdossier, samen met besluiten uit de periodieke reviewmeetings en runbooks die beschrijven hoe het SOC of beheerteam gebruik maakt van monitoring-data voor incidentdetectie. Voor ISO 27001 en NIS2 is vooral van belang dat er een aantoonbare PDCA-cyclus (Plan-Do-Check-Act) bestaat rondom monitoring en observability. Het plan-niveau wordt ingevuld via architectuur- en beleidsdocumenten, de do-fase via implementatie van Log Analytics workspaces en diagnostische instellingen, de check-fase via periodieke analyses en scriptgestuurde controles, en de act-fase via verbetermaatregelen op basis van bevindingen en incidenten. Door deze samenhang expliciet te maken in documentatie en tijdens audits te illustreren met concrete voorbeelden – bijvoorbeeld een incident waarbij monitoring een dreiging vroegtijdig signaleerde, of een oefening waarin het gebruik van Log Analytics voor forensisch onderzoek is getest – ontstaat een overtuigend beeld van volwassen monitoring. Het gebruik van log-analytics-workspaces.ps1 als standaardinstrument in deze check-fase toont bovendien aan dat de organisatie niet afhankelijk is van handmatige controles, maar geautomatiseerde waarborgen inzet om de kwaliteit van workspace-configuraties op niveau te houden.
Gebruik PowerShell-script log-analytics-workspaces.ps1 (functie Invoke-Revert) – Biedt waar nodig een gecontroleerd mechanisme om test- of tijdelijke workspace-configuraties terug te draaien naar een eerder vastgelegde, goedgekeurde staat..
Compliance & Frameworks
- CIS M365: Control 6.7 (L1) - Configureer en onderhoud centrale logging en monitoring voor kritieke systemen en diensten.
- BIO: 12.04, 12.06, 16.01 - Logging, monitoring en incidentrespons voor kritieke processen en onderliggende IT-diensten.
- ISO 27001:2022: A.8.16, A.12.4.1, A.5.25 - Bewaking van beveiligingsevenementen, reactie op incidenten en continue verbetering van detectiecapaciteiten.
- NIS2: Artikel - Technische en organisatorische maatregelen voor monitoring, detectie en tijdige respons op beveiligingsincidenten bij essentiële en belangrijke entiteiten.
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).
Risico zonder implementatie
Management Samenvatting
Richt een hiërarchische multi-workspace architectuur in met duidelijke governance-principes voor naamgeving, tagging en eigenaarschap. Implementeer Azure Policy voor automatische enforcement van workspace-configuraties, consolideer bestaande workspaces waar mogelijk, en gebruik log-analytics-workspaces.ps1 om alle workspaces periodiek te inventariseren en compliance te monitoren. Zo borgt u dat relevante gebeurtenissen tijdig worden gedetecteerd, opgeslagen en geanalyseerd, en dat monitoring aantoonbaar wordt gemaakt richting bestuur en toezichthouders.
- Implementatietijd: 60 uur
- FTE required: 0.3 FTE