Change Tracking Configuration Voor Azure Governance

Voor Nederlandse overheidsorganisaties en grote ondernemingen is het bijhouden van wijzigingen in cloud-omgevingen niet alleen een best practice maar vaak een wettelijke verplichting. Zonder een gestructureerde change tracking configuratie ontbreekt het aan volledige zichtbaarheid over wie welke wijzigingen heeft gemaakt, wanneer deze wijzigingen hebben plaatsgevonden, en wat de impact is van deze wijzigingen op beveiliging en compliance. Dit gebrek aan zichtbaarheid leidt tot situaties waarin beveiligingsincidenten niet kunnen worden onderzocht omdat er geen audit-trail beschikbaar is, waarbij compliance-audits falen omdat organisaties niet kunnen aantonen dat wijzigingen zijn gecontroleerd en goedgekeurd, en waarbij onbevoegde wijzigingen onopgemerkt blijven totdat ze leiden tot beveiligingsproblemen. Compliance-frameworks zoals de BIO-normen, ISO 27001 en NIS2 vereisen expliciet dat organisaties kunnen aantonen dat zij alle wijzigingen in hun IT-omgeving bijhouden en kunnen verifiëren wie welke wijzigingen heeft gemaakt. De BIO-normen benadrukken in Thema 09.01 het belang van logging en monitoring, waarbij organisaties moeten kunnen aantonen dat zij alle relevante gebeurtenissen loggen en deze logs bewaren voor audit-doeleinden. Zonder een gedocumenteerde change tracking configuratie kunnen organisaties niet bewijzen dat zij voldoen aan deze vereisten, wat kan leiden tot het falen van audits en mogelijke aansprakelijkheid bij beveiligingsincidenten. Beveiligingsrisico's nemen exponentieel toe wanneer organisaties geen volledige zichtbaarheid hebben over wijzigingen in hun cloud-omgeving. Zonder change tracking kunnen kwaadwillende actoren wijzigingen maken aan beveiligingsconfiguraties, toegangsrechten of netwerkinstellingen zonder dat deze worden gedetecteerd. Deze wijzigingen kunnen leiden tot beveiligingslekken die worden uitgebuit voor datadiefstal, service-onderbrekingen of andere kwaadaardige activiteiten. Bovendien kunnen insider threats onopgemerkt blijven wanneer er geen tracking is van wijzigingen die door geautoriseerde gebruikers worden gemaakt, waardoor misbruik van bevoegdheden niet wordt gedetecteerd. Een goed geconfigureerde change tracking oplossing biedt organisaties volledige zichtbaarheid en controle over hun cloud-omgeving. Door een gestructureerde configuratie te implementeren kunnen organisaties garanderen dat alle wijzigingen worden gelogd, dat deze logs worden bewaard voor de vereiste retentieperiode, en dat waarschuwingen worden gegenereerd wanneer verdachte of onbevoegde wijzigingen worden gedetecteerd. Dit maakt het mogelijk om proactief te reageren op beveiligingsbedreigingen en om tijdens audits te kunnen aantonen dat alle wijzigingen zijn gecontroleerd en goedgekeurd. Voor Nederlandse overheidsorganisaties is change tracking bijzonder belangrijk vanwege de publieke verantwoordelijkheid en de strenge eisen die gelden voor transparantie en verantwoording. Organisaties in de publieke sector moeten kunnen aantonen dat zij volledige controle hebben over hun cloud-omgeving en dat alle wijzigingen worden gecontroleerd en goedgekeurd volgens gedefinieerde processen. Een change tracking configuratie biedt de technische basis die nodig is om deze verantwoordelijkheid te vervullen en om tijdens audits en parlementaire vragen te kunnen aantonen dat wijzigingen daadwerkelijk worden getrackt en gecontroleerd.

Implementatie

Een change tracking configuration voor Azure governance omvat een complete set van configuraties, processen en best practices voor het bijhouden, monitoren en analyseren van alle wijzigingen die plaatsvinden in de Azure-omgeving. De configuratie beschrijft hoe Azure Activity Logs worden geconfigureerd voor het vastleggen van alle resource-wijzigingen, hoe deze logs worden geaggregeerd en opgeslagen in een centrale locatie zoals Log Analytics, en hoe waarschuwingen worden geconfigureerd voor het detecteren van kritieke of verdachte wijzigingen. Het framework definieert ook welke typen wijzigingen moeten worden getrackt, hoe lang logs moeten worden bewaard, en wie toegang heeft tot deze logs voor audit- en onderzoeksdoeleinden. De configuratie omvat het instellen van Activity Log Collection voor alle relevante Azure-resources, waarbij wordt gegarandeerd dat alle wijzigingen aan resources, resource groups, abonnementen en Management Groups worden vastgelegd. Dit omvat het configureren van diagnostische instellingen die Activity Logs doorsturen naar Log Analytics workspaces, waar ze kunnen worden opgeslagen voor langetermijnretentie en geanalyseerd met behulp van KQL-queries. De configuratie beschrijft ook hoe logs worden georganiseerd en gecategoriseerd op basis van verschillende criteria, zoals het type wijziging, de resource die is gewijzigd, of de gebruiker die de wijziging heeft gemaakt. Het framework definieert waarschuwingsregels die automatisch waarschuwingen genereren wanneer specifieke typen wijzigingen worden gedetecteerd, zoals wijzigingen aan beveiligingsconfiguraties, toegangsrechten, netwerkinstellingen of compliance-policies. Deze waarschuwingen kunnen worden geconfigureerd om verschillende acties te triggeren, zoals het verzenden van e-mailmeldingen naar security officers, het maken van incident tickets in een ITSM-systeem, of het activeren van geautomatiseerde remediatie-scripts die wijzigingen automatisch terugdraaien wanneer ze niet zijn goedgekeurd. Het framework beschrijft ook hoe waarschuwingsregels worden ontwikkeld en getest om te garanderen dat zij effectief zijn zonder te veel valse positieven te genereren. Een cruciaal onderdeel van de configuratie is het definiëren van retentiebeleid voor change logs, waarbij wordt beschreven hoe lang verschillende typen logs moeten worden bewaard voor audit- en compliance-doeleinden. Voor Nederlandse overheidsorganisaties kunnen compliance-vereisten zoals de Archiefwet betekenen dat bepaalde logs minimaal zeven of twintig jaar moeten worden bewaard, wat speciale configuraties vereist voor langetermijnopslag. Het framework beschrijft hoe logs worden gearchiveerd naar goedkope opslagoplossingen zoals Azure Blob Storage of Azure Archive Storage wanneer de actieve retentieperiode is verstreken, terwijl ze nog steeds toegankelijk blijven voor audit-doeleinden. Het framework omvat ook processen voor het analyseren en onderzoeken van wijzigingen, waarbij wordt beschreven hoe security officers en auditors queries kunnen uitvoeren om specifieke wijzigingen te vinden, trends te identificeren in wijzigingspatronen, en incidenten te onderzoeken. Dit omvat het ontwikkelen van standaard KQL-queries voor veelvoorkomende onderzoeksscenario's, zoals het vinden van alle wijzigingen die door een specifieke gebruiker zijn gemaakt, het identificeren van wijzigingen aan kritieke resources, of het analyseren van wijzigingspatronen die kunnen wijzen op kwaadaardige activiteit. Het framework beschrijft ook hoe deze queries worden gedocumenteerd en gedeeld met security teams zodat zij effectief kunnen werken met change tracking data. Monitoring- en verificatieprocessen vormen een essentieel onderdeel van het framework, waarbij wordt beschreven hoe de effectiviteit van change tracking wordt gemonitord en geëvalueerd. Het framework definieert metrics en KPI's die worden gebruikt om te meten of change tracking correct werkt, zoals het percentage resources waarvan wijzigingen worden getrackt, de tijd die nodig is om wijzigingen te detecteren en te rapporteren, en de mate waarin waarschuwingen worden gegenereerd voor kritieke wijzigingen. Door deze metrics te monitoren kunnen organisaties identificeren waar de configuratie verbetering behoeft en kunnen zij aantonen tijdens audits dat change tracking daadwerkelijk effectief werkt.

Azure Activity Log Configuratie

De Azure Activity Log vormt de fundamentele basis voor change tracking in Azure, omdat het alle wijzigingen vastlegt die plaatsvinden op het niveau van abonnementen, resource groups en individuele resources. Een effectieve change tracking configuratie begint bij het correct configureren van Activity Logs voor alle relevante scopes binnen de organisatie. Dit omvat het garanderen dat Activity Logs zijn ingeschakeld voor alle abonnementen en Management Groups, dat diagnostische instellingen zijn geconfigureerd om logs door te sturen naar een centrale Log Analytics workspace, en dat alle relevante log-categorieën worden vastgelegd, inclusief Administrative, ServiceHealth, ResourceHealth, Alert, Security, Recommendation en Policy categorieën. Voor grote organisaties met meerdere abonnementen is het essentieel om een centrale Log Analytics workspace te configureren waar alle Activity Logs worden geaggregeerd. Deze centrale aggregatie maakt het mogelijk om wijzigingen over alle abonnementen heen te analyseren en te monitoren vanuit één locatie, wat cruciaal is voor organisatiebrede zichtbaarheid en compliance-rapportage. De configuratie moet beschrijven hoe diagnostische instellingen worden geconfigureerd op het niveau van Management Groups om ervoor te zorgen dat alle onderliggende abonnementen automatisch hun logs doorsturen naar de centrale workspace, zonder dat dit handmatig moet worden geconfigureerd voor elk individueel abonnement. Het configureren van de juiste log-categorieën is cruciaal om te garanderen dat alle relevante wijzigingen worden vastgelegd. Administrative logs bevatten alle wijzigingen die door gebruikers of service principals worden gemaakt, zoals het maken, wijzigen of verwijderen van resources, het wijzigen van toegangsrechten, of het configureren van beveiligingsinstellingen. ServiceHealth en ResourceHealth logs bevatten informatie over service-onderbrekingen en resource-status, wat belangrijk kan zijn voor het begrijpen van de context waarin wijzigingen plaatsvinden. Security logs bevatten informatie over beveiligingsgerelateerde gebeurtenissen, zoals mislukte authenticatiepogingen of verdachte activiteiten. Het framework moet beschrijven welke categorieën verplicht zijn voor compliance-doeleinden en hoe deze worden geconfigureerd. Retentiebeleid voor Activity Logs moet worden geconfigureerd op basis van compliance-vereisten en organisatorische behoeften. Standaard worden Activity Logs 90 dagen bewaard in Azure, maar voor compliance-doeleinden kunnen langere retentieperioden vereist zijn. Door Activity Logs door te sturen naar Log Analytics kunnen organisaties logs bewaren voor langere perioden, waarbij retentie kan worden geconfigureerd tot maximaal twee jaar in Log Analytics, of onbeperkt wanneer logs worden geëxporteerd naar externe opslagoplossingen. Het framework moet beschrijven hoe retentiebeleid wordt geconfigureerd en hoe logs worden gearchiveerd naar goedkope opslagoplossingen wanneer de actieve retentieperiode is verstreken. Een belangrijk aspect van Activity Log configuratie is het garanderen dat logs niet kunnen worden gewijzigd of verwijderd door onbevoegde gebruikers. Dit vereist het configureren van juiste toegangscontroles op Log Analytics workspaces, waarbij alleen geautoriseerde security officers en auditors toegang hebben tot change tracking logs. Het framework moet ook beschrijven hoe log-integriteit wordt gegarandeerd, bijvoorbeeld door het gebruik van immutable storage of door het configureren van audit logs die alle toegang tot change tracking logs vastleggen. Deze maatregelen zijn essentieel om te garanderen dat change tracking logs betrouwbaar zijn voor audit- en forensische doeleinden.

Gebruik PowerShell-script change-tracking-configuration.ps1 (functie Set-ActivityLogConfiguration) – Configureert Azure Activity Log diagnostische instellingen voor change tracking.

Resource Change Tracking en Monitoring

Naast Activity Logs biedt Azure Resource Graph en Azure Resource Manager Change History aanvullende mogelijkheden voor het tracken van wijzigingen aan specifieke resources. Resource Change Tracking maakt het mogelijk om gedetailleerde informatie te verkrijgen over wat er precies is gewijzigd aan een resource, inclusief de oude en nieuwe waarden van gewijzigde eigenschappen. Deze gedetailleerde informatie is essentieel voor het begrijpen van de impact van wijzigingen en voor het onderzoeken van incidenten waarbij wijzigingen mogelijk hebben bijgedragen aan beveiligingsproblemen of service-onderbrekingen. Azure Resource Graph biedt een krachtige query-interface waarmee organisaties kunnen zoeken naar resources op basis van verschillende criteria, inclusief wijzigingsgeschiedenis. Door Resource Graph queries te gebruiken kunnen security officers snel identificeren welke resources zijn gewijzigd binnen een bepaalde tijdsperiode, welke eigenschappen zijn gewijzigd, en wie deze wijzigingen heeft gemaakt. Het framework moet beschrijven hoe standaard Resource Graph queries worden ontwikkeld voor veelvoorkomende change tracking scenario's, zoals het vinden van alle resources waarvan beveiligingsinstellingen zijn gewijzigd, of het identificeren van resources die zijn verwijderd zonder goedkeuring. Change History voor individuele resources biedt een gedetailleerd overzicht van alle wijzigingen die aan een specifieke resource zijn gemaakt, inclusief wanneer elke wijziging heeft plaatsgevonden, wie de wijziging heeft gemaakt, en wat de exacte wijziging was. Deze informatie is beschikbaar via de Azure Portal voor de afgelopen 14 dagen, maar kan worden uitgebreid door Change History te exporteren naar Log Analytics voor langetermijnretentie. Het framework moet beschrijven hoe Change History wordt geconfigureerd voor kritieke resources, zoals key vaults, storage accounts met gevoelige data, of netwerkconfiguraties, en hoe deze informatie wordt geaggregeerd in een centrale locatie voor analyse. Voor resources die worden beheerd via Infrastructure as Code (IaC) oplossingen zoals ARM templates, Bicep of Terraform, moet change tracking ook de wijzigingen in source code repositories vastleggen. Het framework moet beschrijven hoe wijzigingen aan IaC-templates worden getrackt via versiebeheersystemen zoals Git, hoe deze wijzigingen worden gekoppeld aan de daadwerkelijke resource-wijzigingen in Azure, en hoe wijzigingen worden gereviewed en goedgekeurd voordat ze worden geïmplementeerd. Dit maakt het mogelijk om een complete audit-trail te hebben van zowel de intentie (via source code) als de implementatie (via Activity Logs) van wijzigingen. Geautomatiseerde monitoring van resource-wijzigingen is essentieel voor het detecteren van onbevoegde of verdachte wijzigingen in real-time. Het framework moet beschrijven hoe Azure Monitor alert rules worden geconfigureerd om automatisch waarschuwingen te genereren wanneer specifieke typen wijzigingen worden gedetecteerd, zoals wijzigingen aan beveiligingsconfiguraties, toegangsrechten, of netwerkinstellingen. Deze waarschuwingen kunnen worden geconfigureerd om verschillende acties te triggeren, zoals het verzenden van e-mailmeldingen, het maken van incident tickets, of het activeren van geautomatiseerde remediatie-scripts. Het framework moet ook beschrijven hoe waarschuwingsregels worden getest en geoptimaliseerd om te voorkomen dat te veel valse positieven worden gegenereerd. Voor compliance-doeleinden moet change tracking ook kunnen aantonen dat wijzigingen zijn goedgekeurd volgens gedefinieerde processen. Dit vereist het koppelen van change tracking data aan goedkeuringsprocessen, bijvoorbeeld door het gebruik van Azure Policy voor het afdwingen van goedkeuringsvereisten, of door het integreren van change tracking met ITSM-systemen die goedkeuringsworkflows beheren. Het framework moet beschrijven hoe deze integraties worden geconfigureerd en hoe wordt gegarandeerd dat alleen goedgekeurde wijzigingen worden geïmplementeerd, terwijl onbevoegde wijzigingen automatisch worden gedetecteerd en gemeld.

Gebruik PowerShell-script change-tracking-configuration.ps1 (functie Get-ResourceChangeHistory) – Haalt de wijzigingsgeschiedenis op voor specifieke Azure-resources.

Waarschuwingsconfiguratie voor Kritieke Wijzigingen

Effectieve waarschuwingsconfiguratie vormt een kritiek onderdeel van change tracking, omdat het garandeert dat security officers en compliance managers onmiddellijk worden geïnformeerd wanneer kritieke of verdachte wijzigingen worden gedetecteerd. Het framework moet een gestructureerde aanpak definiëren voor het ontwikkelen, configureren en beheren van waarschuwingsregels die automatisch waarschuwingen genereren op basis van change tracking data. Deze waarschuwingsregels moeten worden georganiseerd op basis van de ernst van wijzigingen, waarbij kritieke wijzigingen onmiddellijke aandacht vereisen en minder kritieke wijzigingen kunnen worden geaggregeerd in periodieke rapportages. Kritieke wijzigingen die onmiddellijke waarschuwingen moeten triggeren, omvatten typisch wijzigingen aan beveiligingsconfiguraties zoals firewall-regels, netwerk security groups, of toegangsrechten voor kritieke resources. Wijzigingen aan key vaults, storage accounts met gevoelige data, of identiteitsconfiguraties zoals Conditional Access policies moeten ook worden beschouwd als kritiek en moeten onmiddellijke waarschuwingen genereren. Het framework moet beschrijven hoe waarschuwingsregels worden ontwikkeld voor deze kritieke scenario's, welke informatie moet worden opgenomen in waarschuwingen, en wie moet worden geïnformeerd wanneer waarschuwingen worden gegenereerd. Waarschuwingsregels moeten worden geconfigureerd met behulp van KQL-queries die Activity Logs analyseren om specifieke patronen te detecteren die wijzen op kritieke of verdachte wijzigingen. Deze queries moeten worden ontwikkeld in samenwerking met security officers die begrijpen welke typen wijzigingen verdacht zijn en welke context nodig is om te bepalen of een wijziging legitiem is of niet. Het framework moet beschrijven hoe KQL-queries worden ontwikkeld, getest en geoptimaliseerd om te garanderen dat zij effectief zijn zonder te veel valse positieven te genereren. Queries moeten ook worden gedocumenteerd zodat andere teamleden kunnen begrijpen wat zij detecteren en hoe zij kunnen worden aangepast wanneer nieuwe bedreigingen worden geïdentificeerd. Waarschuwingsacties moeten worden geconfigureerd om verschillende typen respons te triggeren op basis van de ernst en het type wijziging. Voor kritieke wijzigingen moeten waarschuwingen onmiddellijk worden verzonden naar security officers via e-mail, SMS of andere real-time communicatiekanalen. Voor minder kritieke maar nog steeds belangrijke wijzigingen kunnen waarschuwingen worden geaggregeerd in periodieke rapportages die dagelijks of wekelijks worden verzonden. Het framework moet ook beschrijven hoe waarschuwingen worden geïntegreerd met incident response systemen, zodat waarschuwingen automatisch incident tickets genereren die kunnen worden toegewezen aan de juiste teams voor onderzoek en remediatie. Geautomatiseerde remediatie kan worden geconfigureerd voor bepaalde typen onbevoegde wijzigingen, waarbij wijzigingen automatisch worden teruggedraaid wanneer zij worden gedetecteerd en niet zijn goedgekeurd volgens gedefinieerde processen. Dit vereist het ontwikkelen van remediatie-scripts die wijzigingen kunnen identificeren, verifiëren of zij zijn goedgekeurd, en automatisch terugdraaien wanneer dit niet het geval is. Het framework moet beschrijven hoe deze geautomatiseerde remediatie wordt geconfigureerd, welke typen wijzigingen geschikt zijn voor automatische remediatie, en hoe wordt gegarandeerd dat legitieme wijzigingen niet per ongeluk worden teruggedraaid. Geautomatiseerde remediatie moet altijd worden gecombineerd met waarschuwingen zodat security officers worden geïnformeerd over alle acties die worden ondernomen. Waarschuwingsregels moeten regelmatig worden geëvalueerd en bijgewerkt om te garanderen dat zij effectief blijven naarmate nieuwe bedreigingen worden geïdentificeerd en organisatorische behoeften veranderen. Het framework moet beschrijven hoe waarschuwingsregels worden gereviewed, hoe false positive rates worden gemonitord, en hoe regels worden aangepast wanneer zij niet effectief blijken te zijn. Regelmatige evaluatie moet ook identificeren waar nieuwe waarschuwingsregels nodig zijn op basis van nieuwe bedreigingen of wijzigingen in de cloud-omgeving. Door waarschuwingsregels continu te verbeteren kunnen organisaties ervoor zorgen dat change tracking daadwerkelijk bijdraagt aan beveiliging en compliance in plaats van alleen maar data te verzamelen.

Gebruik PowerShell-script change-tracking-configuration.ps1 (functie Set-ChangeTrackingAlerts) – Configureert waarschuwingsregels voor kritieke wijzigingen in Azure-resources.

Log Retentie en Archivering

Log retentie en archivering vormen een essentieel onderdeel van change tracking configuratie, omdat compliance-vereisten vaak specificeren dat change logs voor langere perioden moeten worden bewaard dan wat standaard wordt aangeboden door Azure-services. Voor Nederlandse overheidsorganisaties kunnen compliance-vereisten zoals de Archiefwet betekenen dat bepaalde logs minimaal zeven of twintig jaar moeten worden bewaard, wat speciale configuraties vereist voor langetermijnopslag. Het framework moet een gestructureerde aanpak definiëren voor het beheren van log retentie, waarbij wordt beschreven hoe lang verschillende typen logs moeten worden bewaard, hoe logs worden gearchiveerd naar goedkope opslagoplossingen, en hoe logs toegankelijk blijven voor audit-doeleinden zelfs wanneer zij zijn gearchiveerd. Retentiebeleid moet worden ontwikkeld op basis van compliance-vereisten, organisatorische behoeften en kostenoverwegingen. Verschillende typen logs kunnen verschillende retentieperioden vereisen, waarbij kritieke beveiligingslogs mogelijk langer moeten worden bewaard dan operationele logs. Het framework moet beschrijven hoe retentiebeleid wordt gedocumenteerd, wie verantwoordelijk is voor het vaststellen van retentieperioden, en hoe retentiebeleid wordt geïmplementeerd in Azure-configuraties. Retentiebeleid moet ook regelmatig worden herzien om te garanderen dat het nog steeds voldoet aan compliance-vereisten en organisatorische behoeften. Voor logs die langer moeten worden bewaard dan de standaard retentieperiode in Log Analytics (twee jaar), moeten archiveringsprocessen worden geconfigureerd die logs exporteren naar goedkope opslagoplossingen zoals Azure Blob Storage of Azure Archive Storage. Het framework moet beschrijven hoe deze archiveringsprocessen worden geconfigureerd, hoe vaak archivering plaatsvindt, en hoe wordt gegarandeerd dat logs niet verloren gaan tijdens het archiveringsproces. Archiveringsprocessen moeten geautomatiseerd zijn om te voorkomen dat handmatige fouten leiden tot verlies van logs, en moeten worden getest om te garanderen dat zij betrouwbaar werken. Gearchiveerde logs moeten toegankelijk blijven voor audit-doeleinden, zelfs wanneer zij zijn opgeslagen in goedkope opslagoplossingen. Dit vereist het ontwikkelen van processen en tools waarmee auditors en security officers gearchiveerde logs kunnen opvragen en analyseren wanneer dit nodig is. Het framework moet beschrijven hoe deze toegankelijkheid wordt gegarandeerd, hoe lang het duurt om gearchiveerde logs op te halen, en wie toegang heeft tot gearchiveerde logs. Voor logs die zijn opgeslagen in Azure Archive Storage moet rekening worden gehouden met de tijd die nodig is om logs te rehydrateren voordat zij kunnen worden geopend. Log-integriteit is cruciaal voor audit-doeleinden, omdat auditors moeten kunnen verifiëren dat logs niet zijn gewijzigd of gemanipuleerd. Het framework moet beschrijven hoe log-integriteit wordt gegarandeerd, bijvoorbeeld door het gebruik van immutable storage, cryptografische hashing, of andere technieken die voorkomen dat logs kunnen worden gewijzigd zonder detectie. Log-integriteit moet worden geverifieerd tijdens audits, waarbij auditors moeten kunnen aantonen dat logs authentiek zijn en niet zijn gemanipuleerd. Het framework moet ook beschrijven hoe log-integriteit wordt gemonitord en hoe wordt gereageerd wanneer integriteitsproblemen worden gedetecteerd. Kostenbeheer is een belangrijk aspect van log retentie en archivering, omdat het bewaren van grote hoeveelheden logs voor langere perioden aanzienlijke kosten kan genereren. Het framework moet beschrijven hoe kosten worden gemonitord en beheerd, hoe archiveringsbeslissingen worden genomen op basis van kostenoverwegingen, en hoe wordt gegarandeerd dat compliance-vereisten worden nageleefd zonder onnodige kosten te genereren. Dit kan betekenen dat sommige logs worden bewaard in goedkope opslagoplossingen met langere retrieval-tijden, terwijl andere logs worden bewaard in snellere maar duurdere opslagoplossingen. Het framework moet beschrijven hoe deze beslissingen worden genomen en hoe kosten worden geoptimaliseerd zonder in te boeten op compliance-vereisten.

Gebruik PowerShell-script change-tracking-configuration.ps1 (functie Export-LogsToArchive) – Exporteert change tracking logs naar archiefopslag voor langetermijnretentie.

Monitoring en Verificatie van Change Tracking

Effectieve monitoring en verificatie van change tracking is essentieel om te garanderen dat de configuratie daadwerkelijk werkt en dat alle relevante wijzigingen worden getrackt zoals bedoeld. Het monitoringproces moet verschillende aspecten omvatten, waaronder het verifiëren dat Activity Logs correct worden verzameld voor alle relevante scopes, het controleren dat waarschuwingsregels effectief zijn zonder te veel valse positieven te genereren, het meten van de tijd die nodig is om wijzigingen te detecteren en te rapporteren, en het identificeren van gaten in change tracking coverage die moeten worden aangepakt. Het verifiëren dat Activity Logs correct worden verzameld vereist regelmatige controles van diagnostische instellingen voor alle abonnementen en Management Groups. Het monitoringproces moet controleren of diagnostische instellingen zijn geconfigureerd voor alle relevante scopes, of deze instellingen correct zijn geconfigureerd om logs door te sturen naar de centrale Log Analytics workspace, en of logs daadwerkelijk worden ontvangen in de workspace. Het proces moet ook controleren of alle relevante log-categorieën zijn ingeschakeld en of retentiebeleid correct is geconfigureerd. Door regelmatig deze configuraties te verifiëren kunnen organisaties ervoor zorgen dat change tracking volledig werkt en dat er geen gaten zijn in de coverage. Het monitoren van waarschuwingsregels is belangrijk om te garanderen dat zij effectief zijn en niet te veel valse positieven genereren die security officers overbelasten. Het monitoringproces moet bijhouden hoeveel waarschuwingen worden gegenereerd, hoeveel van deze waarschuwingen daadwerkelijk legitieme problemen identificeren, en hoeveel valse positieven worden gegenereerd. Door deze metrics te monitoren kunnen organisaties identificeren waar waarschuwingsregels moeten worden aangepast om effectiever te zijn, of waar nieuwe regels nodig zijn om nieuwe bedreigingen te detecteren. Het proces moet ook controleren of waarschuwingen daadwerkelijk worden geleverd aan de juiste personen en of zij tijdig worden behandeld. Het meten van de tijd die nodig is om wijzigingen te detecteren en te rapporteren is cruciaal voor het evalueren van de effectiviteit van change tracking. Het monitoringproces moet bijhouden hoe lang het duurt voordat wijzigingen worden vastgelegd in Activity Logs, hoe lang het duurt voordat waarschuwingen worden gegenereerd wanneer kritieke wijzigingen worden gedetecteerd, en hoe lang het duurt voordat security officers worden geïnformeerd. Door deze metrics te monitoren kunnen organisaties identificeren waar processen kunnen worden verbeterd om sneller te reageren op wijzigingen, en kunnen zij aantonen tijdens audits dat change tracking daadwerkelijk real-time of near-real-time werkt. Het identificeren van gaten in change tracking coverage is belangrijk voor continue verbetering. Het monitoringproces moet regelmatig evalueren of alle relevante resources en scopes worden getrackt, of er nieuwe resource-typen zijn toegevoegd die moeten worden getrackt, en of er wijzigingen zijn in de cloud-omgeving die nieuwe tracking-vereisten introduceren. Het proces moet ook controleren of change tracking correct werkt voor resources die worden beheerd via verschillende methoden, zoals de Azure Portal, Azure CLI, PowerShell, of Infrastructure as Code tools. Door regelmatig coverage te evalueren kunnen organisaties ervoor zorgen dat change tracking volledig is en dat er geen blinde vlekken zijn. Voor audit-doeleinden moet het monitoringproces ook documentatie genereren die aantoont dat change tracking daadwerkelijk werkt en effectief is. Deze documentatie moet omvatten overzichten van change tracking configuraties, bewijs dat logs worden verzameld en bewaard, en metrics die aantonen dat waarschuwingen effectief zijn. Deze documentatie is essentieel voor externe auditors die moeten verifiëren dat organisaties voldoen aan compliance-vereisten voor change tracking, zoals die worden gesteld door de BIO-normen, ISO 27001 en andere relevante frameworks. Door regelmatig monitoring-rapporten te genereren kunnen organisaties aantonen dat change tracking niet alleen is geconfigureerd, maar ook daadwerkelijk werkt en wordt beheerd.

Gebruik PowerShell-script change-tracking-configuration.ps1 (functie Test-ChangeTrackingConfiguration) – Verifieert en test de change tracking configuratie voor volledigheid en effectiviteit.

Compliance & Frameworks

• BIO: 09.01.01, 09.01.02, 09.02.01 - Logging en monitoring van wijzigingen en gebeurtenissen in de IT-omgeving
• ISO 27001:2022: A.12.4.1, A.12.4.2, A.12.4.3 - Event logging en monitoring van wijzigingen in informatiesystemen
• NIS2: Artikel - Incident handling en logging van beveiligingsgebeurtenissen

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

Een change tracking configuration voor Azure governance omvat een complete set van configuraties, processen en best practices voor het bijhouden, monitoren en analyseren van alle wijzigingen die plaatsvinden in de Azure-omgeving. De configuratie beschrijft hoe Azure Activity Logs worden geconfigureerd, hoe waarschuwingen worden geconfigureerd voor kritieke wijzigingen, hoe logs worden bewaard en gearchiveerd voor compliance-doeleinden, en hoe change tracking wordt gemonitord en geverifieerd. Implementatie vereist ongeveer 120 uur voor configuratie, documentatie en training. De configuratie is essentieel voor organisaties die moeten voldoen aan compliance-vereisten zoals BIO, ISO 27001 en NIS2.

• Implementatietijd: 120 uur
• FTE required: 0.5 FTE