Azure Monitoring: Alle Log-categorieën In Diagnostische Instellingen Inschakelen

Azure-resources bieden meerdere logcategorieën die elk verschillende aspecten van resourceoperaties vastleggen, waaronder beveiligingslogs voor authenticatie, autorisatie en toegang, auditlogs voor configuratiewijzigingen en gegevensoperaties, prestatielogs voor metrieken, fouten en waarschuwingen, en operationele logs voor levenscyclusgebeurtenissen en gezondheidsstatus. Wanneer alleen selectieve categorieën worden ingeschakeld, ontstaan logginghiaten waarbij kritieke gebeurtenissen niet worden vastgelegd. Een Key Vault met alleen auditlogs ingeschakeld maar zonder toegangslogs mist bijvoorbeeld informatie over wie welke geheimen heeft benaderd, wat een beveiligingshiat vormt. Een SQL Database met alleen prestatielogs maar zonder auditlogs mist alle queryactiviteit, wat een nalevingshiat creëert. Een Storage Account met alleen schrijflogs maar zonder leeslogs kan gegevensexfiltratie niet detecteren. Deze gedeeltelijke logging bemoeilijkt beveiligingsincidentonderzoek omdat onvolledige datasporen de reconstructie van aanvalstijdlijnen onmogelijk maken, maakt probleemoplossing inefficiënt omdat kritieke diagnostische informatie ontbreekt, en veroorzaakt nalevingsauditfouten omdat vereiste logcategorieën ontbreken. De beste praktijk is om alle beschikbare logcategorieën in te schakelen tenzij er specifieke prestatie- of kostentoelaatbare redenen zijn om selectieve categorieën uit te schakelen, waarbij elke uitgeschakelde categorie moet worden gedocumenteerd met zakelijke rechtvaardiging. Uitgebreide logging voldoet aan ISO 27001 controle A.12.4.1 voor uitgebreide loggingvereisten, BIO 12.04 voor uitgebreide loggingrichtlijnen, en NIST AU-2 voor auditbare gebeurtenissendekking.

Implementatie

Deze maatregel verifieert dat voor elke Azure-resource met geconfigureerde Diagnostische Instellingen alle beschikbare logcategorieën zijn ingeschakeld. De verificatie gebeurt via PowerShell door alle resources met diagnostische instellingen op te halen, voor elke resource de beschikbare logcategorieën te identificeren, en te verifiëren dat alle categorieën zijn ingeschakeld in plaats van een selectieve subset. Voor resources waar niet alle categorieën zijn ingeschakeld, moet remediatie plaatsvinden door ontbrekende categorieën toe te voegen aan de configuratie van de diagnostische instelling. Veelvoorkomende logcategorieën per resourcetype omvatten voor Key Vault de categorieën AuditEvent en AllMetrics, voor SQL Database de categorieën SQLInsights, AutomaticTuning, QueryStoreRuntimeStatistics, QueryStoreWaitStatistics, Errors, DatabaseWaitStatistics, Timeouts, Blocks, Deadlocks, Basic, InstanceAndAppAdvanced en WorkloadManagement, voor Storage Account de categorieën StorageRead, StorageWrite, StorageDelete en Transaction, en voor App Service de categorieën AppServiceHTTPLogs, AppServiceConsoleLogs, AppServiceAppLogs, AppServiceAuditLogs, AppServiceIPSecAuditLogs en AppServicePlatformLogs. De implementatie van uitgebreide categorisatie kost ongeveer één uur voor verificatie en remediatie en is essentieel voor complete loggingdekking conform CIS Azure Benchmark controle 5.1.4 Niveau 1 en BIO 12.04.

Vereisten

Het inschakelen van alle logcategorieën in Diagnostische Instellingen vereist een grondige voorbereiding op zowel technisch als organisatorisch vlak. Organisaties moeten beschikken over de juiste Azure-abonnementen met toegang tot Azure Monitor en de functionaliteit voor Diagnostische Instellingen. Dit betekent dat er minimaal een Azure-abonnement nodig is met actieve resources die diagnostische instellingen ondersteunen. Het is belangrijk om te begrijpen dat niet alle Azure-services diagnostische instellingen bieden, waardoor het essentieel is om te weten welke resourcetypen logging ondersteunen. Services zoals Key Vault, SQL Database, Storage Accounts en App Services bieden uitgebreide logging-mogelijkheden, terwijl andere services mogelijk beperkte of helemaal geen diagnostische instellingen hebben. Deze kennis is cruciaal voor het opstellen van een complete logging-strategie die alle relevante resources omvat. Voor het configureren en beheren van diagnostische instellingen zijn specifieke Azure RBAC-rollen vereist die de benodigde rechten verlenen. De belangrijkste benodigde rollen zijn Monitoring Contributor voor het aanmaken en wijzigen van diagnostische instellingen, Log Analytics Contributor voor het configureren van logbestemmingen naar Log Analytics workspaces, en Storage Account Contributor voor het configureren van opslagaccounts als logbestemming. Deze rollen kunnen worden toegewezen op verschillende niveaus, namelijk abonnementsniveau, resourcegroepniveau of resourceniveau, afhankelijk van de gewenste granulariteit van toegangsbeheer. Het is van groot belang om het principe van least privilege toe te passen, waarbij gebruikers alleen de minimale benodigde rechten krijgen om hun specifieke taken uit te voeren. Dit vermindert het risico op onbedoelde wijzigingen en verhoogt de algehele beveiligingspostuur van de organisatie. Voor het uitvoeren van verificatie en remediatie via PowerShell zijn de juiste PowerShell-modules vereist, waarbij de Az.Monitor module het meest belangrijk is omdat deze toegang biedt tot de cmdlets voor diagnostische instellingen. Daarnaast kunnen de Az.Resources en Az.Accounts modules nuttig zijn voor algemeen resourcebeheer en authenticatie. Organisaties moeten ervoor zorgen dat alle benodigde modules zijn geïnstalleerd en bijgewerkt naar de nieuwste versies om compatibiliteitsproblemen te voorkomen. Voor geautomatiseerde implementaties kunnen ook Azure Resource Manager templates of Terraform worden gebruikt om diagnostische instellingen te configureren als onderdeel van infrastructuur als code strategieën. Deze aanpak zorgt voor consistentie en reproduceerbaarheid van configuraties en maakt het mogelijk om wijzigingen te volgen via versiebeheer. Organisaties moeten ook beschikken over een Log Analytics workspace of opslagaccount waar de logs kunnen worden opgeslagen, afhankelijk van de gekozen logbestemming. Log Analytics workspaces bieden geavanceerde query- en analysemogelijkheden via KQL, terwijl opslagaccounts geschikt zijn voor langetermijnopslag en archivering. Event Hubs kunnen worden gebruikt voor real-time streaming van logs naar externe systemen zoals SIEM-oplossingen. Het is belangrijk dat deze opslaglocaties voldoen aan de retentievereisten van de organisatie en relevante compliance-standaarden zoals de BIO en AVG. Retentieperioden kunnen variëren van enkele maanden tot meerdere jaren, afhankelijk van de organisatorische en wettelijke vereisten. Organisaties moeten daarom een duidelijk retentiebeleid ontwikkelen dat rekening houdt met alle relevante vereisten en dit consistent toepassen. Daarnaast moeten organisaties duidelijkheid hebben over welke resources diagnostische instellingen vereisen en welke logcategorieën per resourcetype beschikbaar zijn. Dit vereist een complete inventarisatie van alle Azure-resources en een grondig begrip van de logging-mogelijkheden per servicetype. Verschillende resourcetypen hebben verschillende beschikbare logcategorieën, wat betekent dat een uniforme aanpak niet altijd mogelijk is. Een Key Vault heeft bijvoorbeeld AuditEvent en AllMetrics categorieën, terwijl een SQL Database veel meer categorieën heeft zoals SQLInsights, AutomaticTuning, QueryStoreRuntimeStatistics, QueryStoreWaitStatistics, Errors, DatabaseWaitStatistics, Timeouts, Blocks, Deadlocks, Basic, InstanceAndAppAdvanced en WorkloadManagement. Het is essentieel om deze verschillen te begrijpen en te documenteren om ervoor te zorgen dat alle relevante categorieën worden ingeschakeld voor elk resourcetype. Organisaties moeten ook rekening houden met de kostenimplicaties van uitgebreide logging, aangezien het opslaan van logs in Azure Monitor of opslagaccounts aanzienlijke kosten met zich mee kan brengen. Log Analytics werkt met een datainname-model waarbij kosten worden berekend op basis van de hoeveelheid data die wordt opgenomen. Opslagaccounts gebruiken een opslagprijsmodel gebaseerd op de hoeveelheid opgeslagen data. Voor grote omgevingen met veel resources kunnen deze kosten aanzienlijk zijn, waardoor het belangrijk is om budgettaire afwegingen te maken tussen de noodzaak van complete logging en de beschikbare middelen. Organisaties kunnen kosten optimaliseren door gebruik te maken van logretentie-instellingen, datareductietechnieken zoals compressie, of door kritieke logs op te slaan in Log Analytics voor analyse en minder kritieke logs te archiveren naar goedkopere opslagaccounts. Deze kostenoptimalisatie moet echter nooit ten koste gaan van de beveiligings- en compliance-vereisten. Tot slot is het essentieel dat organisaties een duidelijke logging-strategie hebben ontwikkeld waarin is vastgelegd welke logcategorieën verplicht zijn, welke optioneel, en onder welke omstandigheden bepaalde categorieën kunnen worden uitgeschakeld. Deze strategie moet zijn afgestemd op de beveiligingsvereisten, compliance-verplichtingen en operationele behoeften van de organisatie. De strategie moet ook procedures bevatten voor het beoordelen van nieuwe Azure-services en hun logging-mogelijkheden, zodat nieuwe resources automatisch correct worden geconfigureerd. Bovendien moet de strategie regelmatig worden herzien en bijgewerkt om rekening te houden met wijzigingen in compliance-vereisten, beveiligingsrisico's en organisatorische behoeften. Deze continue verbetering zorgt ervoor dat de logging-strategie relevant blijft en effectief blijft in het waarborgen van adequate zichtbaarheid en compliance.

Monitoring

Gebruik PowerShell-script diagnostic-setting-categories.ps1 (functie Invoke-Monitoring) – Controleren.

Het monitoren van de status van logcategorieën in Diagnostische Instellingen is een kritieke activiteit voor het waarborgen van volledige loggingdekking. Organisaties moeten periodiek controleren of alle beschikbare logcategorieën daadwerkelijk zijn ingeschakeld voor hun Azure-resources. Dit vereist een systematische aanpak waarbij alle resources met diagnostische instellingen worden geïnventariseerd en gecontroleerd. Zonder regelmatige monitoring kunnen configuratiedrift en onbedoelde wijzigingen leiden tot logginghiaten die pas worden ontdekt wanneer er een beveiligingsincident of compliance-audit plaatsvindt. Proactieve monitoring voorkomt dergelijke problemen door afwijkingen vroegtijdig te detecteren en te remediëren. De monitoring kan worden uitgevoerd via PowerShell-scripts die automatisch alle resources scannen en de status van elke logcategorie rapporteren. Het script controleert voor elke resource welke logcategorieën beschikbaar zijn voor dat specifieke resourcetype en vergelijkt dit met de categorieën die daadwerkelijk zijn ingeschakeld. Dit kan worden gedaan door gebruik te maken van de Get-AzDiagnosticSetting cmdlet die informatie retourneert over de geconfigureerde diagnostische instellingen voor een resource. Het script moet itereren door alle abonnementen, resourcegroepen en resources om een complete inventarisatie te maken. Voor grootschalige omgevingen met duizenden resources kan dit proces tijdrovend zijn, dus het is belangrijk om geoptimaliseerde scripts te gebruiken die parallel kunnen werken of gefaseerd kunnen worden uitgevoerd. Wanneer er discrepanties worden gevonden tussen beschikbare en ingeschakelde categorieën, moet dit worden gemeld als een afwijking die remediatie vereist. Het monitoringrapport moet duidelijk aangeven welke resources welke categorieën missen, zodat remediatie gericht kan worden uitgevoerd. Het rapport kan worden gegenereerd in verschillende formaten zoals CSV, JSON of HTML, afhankelijk van de behoeften van de organisatie. Geautomatiseerde monitoring kan ook worden geïntegreerd met ticketing-systemen of werkstroomplatforms om automatisch remediatietaken aan te maken wanneer afwijkingen worden gedetecteerd. De monitoring moet regelmatig worden uitgevoerd, bij voorkeur maandelijks of na wijzigingen in de infrastructuur, om ervoor te zorgen dat nieuwe resources direct volledig worden gelogd en dat bestaande configuraties niet onbedoeld worden gewijzigd. Voor kritieke omgevingen met hoge beveiligingsvereisten kan het nodig zijn om wekelijks of zelfs dagelijks te monitoren. Automatische monitoring via Azure Automation of Azure Functions kan worden geconfigureerd om op een vastgesteld schema te draaien en meldingen te verzenden wanneer afwijkingen worden gedetecteerd. Deze geautomatiseerde monitoring moet worden ondersteund door handmatige controles tijdens belangrijke momenten zoals na grote infrastructure-wijzigingen, beveiligingsincidenten of compliance-audits. Daarnaast moeten organisaties proactief monitoren op resources die helemaal geen diagnostische instellingen hebben geconfigureerd, aangezien deze volledig ontbrekende logging vormen. Deze resources zijn vaak een groter risico dan resources met gedeeltelijke logging, omdat er helemaal geen zichtbaarheid is in de activiteiten die plaatsvinden. Het monitoringproces moet daarom niet alleen controleren op ingeschakelde categorieën, maar ook op de aanwezigheid van diagnostische instellingen zelf. Voor resources zonder diagnostische instellingen moet prioriteit worden gegeven aan het implementeren van complete logging-configuraties. Het monitoren van logcategorieën moet ook rekening houden met verschillende resourcetypen en hun specifieke logging-mogelijkheden. Een Key Vault heeft bijvoorbeeld andere beschikbare logcategorieën dan een SQL Database of Storage Account. De monitoring moet daarom resourcetype-specifieke controles uitvoeren om te verifiëren dat alle relevante categorieën voor elk type zijn ingeschakeld. Dit vereist een database of configuratiebestand met informatie over welke categorieën beschikbaar zijn per resourcetype, zodat het monitoringproces weet wat het moet controleren. Deze informatie kan worden opgehaald via Azure API's of worden onderhouden als onderdeel van de logging-strategie van de organisatie. Naast technische verificatie is het belangrijk om ook de zakelijke rechtvaardiging te documenteren voor eventuele categorieën die bewust zijn uitgeschakeld. Dit helpt bij compliance-audits en maakt duidelijk waarom bepaalde logging-beslissingen zijn genomen. De documentatie moet informatie bevatten over welke categorieën zijn uitgeschakeld, de redenen voor uitschakeling (bijvoorbeeld kosten, prestatie-implicaties, of ontbrekende zakelijke waarde), en de goedgekeurde eigenaar of beslisser. Deze documentatie moet regelmatig worden herzien om te verifiëren dat de redenen voor uitschakeling nog steeds geldig zijn, aangezien beveiligingsvereisten en risico's in de loop van de tijd kunnen veranderen. Monitoring moet ook worden geïntegreerd in het algemene beveiligingsbewustzijn en incident response proces, aangezien incomplete logging directe invloed heeft op de mogelijkheid om beveiligingsincidenten te onderzoeken en op te lossen. Wanneer een beveiligingsincident wordt gedetecteerd, moeten security teams direct kunnen zien welke logging beschikbaar is voor de betrokken resources. Als bepaalde logcategorieën ontbreken, kan dit het onderzoek aanzienlijk bemoeilijken of zelfs onmogelijk maken. Daarom moet monitoring van logging-configuraties worden behandeld als een kritieke beveiligingsactiviteit en moeten afwijkingen worden behandeld met dezelfde urgentie als andere beveiligingsproblemen.

Implementatie

Gebruik PowerShell-script diagnostic-setting-categories.ps1 (functie Invoke-Implementation) – Implementeren.

De implementatie van complete logcategorieën in Diagnostische Instellingen vereist een gestructureerde aanpak waarbij alle Azure-resources systematisch worden geconfigureerd. Het implementatieproces begint met een inventarisatie van alle resources die diagnostische instellingen ondersteunen en het identificeren van welke logcategorieën per resourcetype beschikbaar zijn. Deze inventarisatie vormt de basis voor een complete implementatie en moet worden uitgevoerd voordat begonnen wordt met het configureren van diagnostische instellingen. Het is belangrijk om een complete lijst te hebben van alle Azure-resources in alle abonnementen, zodat geen enkele resource wordt overgeslagen. Deze inventarisatie kan worden uitgevoerd via PowerShell, Azure Resource Graph queries, of via de Azure Portal. Voor elk resourcetype moeten alle beschikbare logcategorieën worden ingeschakeld, tenzij er specifieke zakelijke redenen zijn om bepaalde categorieën uit te schakelen. Het identificeren van beschikbare categorieën per resourcetype kan worden gedaan via de Azure API's of door te verwijzen naar Microsoft-documentatie. Het is belangrijk om te begrijpen dat verschillende versies of SKU's van dezelfde resourcetype mogelijk verschillende logcategorieën kunnen hebben, dus de implementatie moet rekening houden met deze verschillen. Wanneer een resourcetype wordt bijgewerkt en nieuwe logcategorieën beschikbaar komen, moeten deze ook worden ingeschakeld als onderdeel van het onderhoudsproces. Het implementeren van complete logcategorieën gebeurt via PowerShell door alle resources met diagnostische instellingen op te halen en voor elke resource te verifiëren dat alle beschikbare categorieën zijn ingeschakeld. Dit kan worden gedaan met behulp van de Set-AzDiagnosticSetting cmdlet die diagnostische instellingen kan aanmaken of bijwerken. Het script moet eerst de bestaande configuratie ophalen met Get-AzDiagnosticSetting, vervolgens de beschikbare categorieën identificeren, en dan de ontbrekende categorieën toevoegen aan de configuratie. Het is belangrijk om bij te houden welke resources zijn aangepast en welke wijzigingen zijn gemaakt, voor documentatie- en rollback-doeleinden. Wanneer er resources zijn waar niet alle categorieën zijn ingeschakeld, moeten de ontbrekende categorieën worden toegevoegd aan de diagnostische instelling configuratie. Dit vereist toegang tot de Azure Portal of het gebruik van Azure Resource Manager templates en PowerShell-cmdlets. Voor grote implementaties met veel resources is geautomatiseerde implementatie via scripts of templates sterk aanbevolen om consistentie en efficiency te waarborgen. Handmatige implementatie via de Azure Portal is alleen praktisch voor kleine omgevingen of voor het configureren van individuele resources die speciale aandacht vereisen. Tijdens de implementatie is het belangrijk om rekening te houden met de verschillende logbestemmingen, zoals Log Analytics workspaces, opslagaccounts of Event Hubs. Elke bestemming heeft zijn eigen voor- en nadelen. Log Analytics workspaces bieden geavanceerde query- en analysemogelijkheden maar hebben hogere kosten voor datainname. Opslagaccounts zijn kostenefficiënter voor lange-termijn opslag maar bieden minder analysemogelijkheden. Event Hubs zijn geschikt voor real-time streaming naar externe systemen. Organisaties kunnen ook meerdere bestemmingen configureren voor dezelfde logcategorieën om verschillende use cases te ondersteunen. Organisaties moeten ervoor zorgen dat deze bestemmingen voldoen aan hun retentievereisten en compliance-verplichtingen, zoals het opslaan van logs binnen de EU voor AVG-compliance of het waarborgen van langdurige retentie voor audit-doeleinden. De implementatie moet ook rekening houden met de kostenimplicaties van uitgebreide logging, aangezien het opslaan van meer logs hogere kosten met zich meebrengt. Voor een gemiddelde Azure-omgeving met honderden resources kunnen de maandelijkse logging-kosten variëren van enkele honderden tot duizenden euro's, afhankelijk van de hoeveelheid gegenereerde logdata en de gekozen opslagopties. Organisaties moeten daarom budgettaire afwegingen maken tussen de noodzaak van complete logging en de beschikbare middelen. Kostenoptimalisatie kan worden bereikt door gebruik te maken van kostenmodellen zoals Log Analytics commitment tiers, het archiveren van oude logs naar goedkopere opslagaccounts, of het implementeren van logsampling voor zeer verbale logcategorieën waar volledige logging niet strikt noodzakelijk is. Na de initiële implementatie moeten organisaties een proces opzetten voor continue verificatie en handhaving, zodat nieuwe resources automatisch met alle logcategorieën worden geconfigureerd en bestaande configuraties niet onbedoeld worden gewijzigd. Dit vereist integratie met CI/CD-pipelines en infrastructure as code (IaC) oplossingen om ervoor te zorgen dat alle nieuwe resources automatisch correct worden geconfigureerd. Azure Policy kan worden gebruikt om automatisch diagnostische instellingen af te dwingen voor nieuwe resources, wat helpt om configuratiedrift te voorkomen. Bovendien moeten wijzigingen aan bestaande diagnostische instellingen worden beheerd via change management processen om te voorkomen dat configuraties onbedoeld worden gewijzigd. De implementatie moet ook worden gedocumenteerd met duidelijk overzicht van welke categorieën per resourcetype zijn ingeschakeld en eventuele uitzonderingen met hun zakelijke rechtvaardiging. Deze documentatie dient als referentie voor toekomstige implementaties, compliance-audits en troubleshooting. De documentatie moet regelmatig worden bijgewerkt wanneer nieuwe resourcetypen worden toegevoegd aan de omgeving of wanneer bestaande configuraties worden gewijzigd. Geautomatiseerde documentatie-generatie vanuit de actuele Azure-configuratie kan helpen om de documentatie actueel te houden zonder handmatige inspanning.

Compliance en Auditing

Het inschakelen van alle logcategorieën in Diagnostische Instellingen is een kritieke vereiste voor compliance met verschillende beveiligingsstandaarden en regelgeving. De CIS Azure Benchmark controle 5.1.4 Niveau 1 vereist expliciet dat alle beschikbare logcategorieën zijn ingeschakeld voor Azure-resources met diagnostische instellingen. Deze controle valt onder de logging en monitoring-sectie van de CIS Benchmark en is essentieel voor het waarborgen van complete auditability en traceerbaarheid van activiteiten in Azure-omgevingen. De CIS Azure Benchmark is een erkende beveiligingsstandaard die door veel organisaties wordt gebruikt als basis voor hun cloud-beveiligingsprogramma's. Naleving van deze benchmark wordt vaak vereist door verzekeraars, klanten en regelgevende instanties als bewijs van adequate beveiligingsmaatregelen. Daarnaast voldoet uitgebreide logging aan de BIO norm 12.04 die uitgebreide logging richtlijnen voorschrijft voor Nederlandse overheidsorganisaties. De BIO (Baseline Informatiebeveiliging Overheid) is de belangrijkste beveiligingsstandaard voor Nederlandse overheidsorganisaties en bevat specifieke vereisten voor logging en monitoring. Norm 12.04 vereist dat organisaties alle relevante gebeurtenissen loggen om adequate beveiliging en compliance te waarborgen. Dit omvat niet alleen technische gebeurtenissen maar ook administratieve en beveiligingsgerelateerde activiteiten. Nederlandse overheidsorganisaties die Azure gebruiken moeten daarom specifiek aandacht besteden aan de implementatie van complete logging om te voldoen aan deze BIO-vereisten. Uitgebreide logging is ook essentieel voor ISO 27001 controle A.12.4.1 die uitgebreide logging vereisten stelt voor het vastleggen van beveiligingsgebeurtenissen en operationele activiteiten. ISO 27001 is een internationaal erkende informatiebeveiligingsstandaard die door veel organisaties wereldwijd wordt gebruikt. Controle A.12.4.1 vereist dat organisaties uitgebreide logging implementeren om beveiligingsincidenten te kunnen detecteren, onderzoeken en voorkomen. De logging moet alle relevante gebeurtenissen vastleggen, inclusief toegangspogingen, configuratiewijzigingen, foutmeldingen en beveiligingsgebeurtenissen. Voor organisaties die ISO 27001 certificering nastreven of behouden, is het inschakelen van alle logcategorieën daarom een absolute vereiste. NIST AU-2 controle vereist dat organisaties auditbare gebeurtenissen identificeren en alle relevante gebeurtenissen vastleggen. Het NIST Cybersecurity Framework en NIST SP 800-53 bevatten uitgebreide richtlijnen voor audit logging die worden gebruikt door veel organisaties, vooral in de Verenigde Staten maar ook internationaal. NIST AU-2 vereist dat organisaties een auditbeleid ontwikkelen dat specificeert welke gebeurtenissen moeten worden gelogd en dat dit beleid consistent wordt toegepast across alle systemen. Het inschakelen van alle beschikbare logcategorieën helpt organisaties te voldoen aan deze NIST-vereisten door ervoor te zorgen dat alle potentiële auditbare gebeurtenissen worden vastgelegd. Voor Nederlandse organisaties is het ook belangrijk om te voldoen aan de AVG vereisten voor het vastleggen van toegang tot persoonsgegevens, wat vereist dat alle toegangslogs en auditlogs correct zijn geconfigureerd. De Algemene Verordening Gegevensbescherming (AVG) verplicht organisaties om te kunnen aantonen wie toegang heeft gehad tot persoonsgegevens, wanneer deze toegang plaatsvond, en voor welk doel. Dit vereist uitgebreide logging van alle activiteiten die betrekking hebben op persoonsgegevens, inclusief toegang, wijziging, verwijdering en export. Voor Azure-resources die persoonsgegevens verwerken, zoals databases, storage accounts en applicaties, is het daarom essentieel dat alle relevante logcategorieën zijn ingeschakeld om te kunnen voldoen aan deze AVG-vereisten. Tijdens compliance-audits moeten organisaties kunnen aantonen dat alle beschikbare logcategorieën zijn ingeschakeld en dat eventuele uitzonderingen zijn gedocumenteerd met zakelijke rechtvaardiging. Auditoren zullen doorgaans vragen om bewijs van de logging-configuratie, inclusief screenshots of exports van diagnostische instellingen, en willen zien dat er een proces is voor het reguliere controleren en onderhouden van deze configuraties. Het is daarom belangrijk dat organisaties niet alleen de configuratie correct hebben ingesteld, maar ook kunnen aantonen dat dit een onderdeel is van een breder governance-proces. Dit vereist regelmatige verificatie en documentatie van de logging-configuratie, inclusief verslaglegging van wanneer controles zijn uitgevoerd, welke afwijkingen zijn gevonden, en hoe deze zijn opgelost. Organisaties moeten ook kunnen aantonen dat de logs voldoen aan de vereiste retentieperioden en dat toegang tot logs is beveiligd volgens relevante beveiligingsstandaarden. Verschillende compliance-standaarden en regelgeving vereisen verschillende retentieperioden voor logs. De BIO vereist bijvoorbeeld vaak retentie van minimaal 7 jaar voor bepaalde soorten logs, terwijl de AVG vereist dat logs worden bewaard zolang ze nodig zijn voor het oorspronkelijke doel maar niet langer dan strikt noodzakelijk. Organisaties moeten daarom een duidelijk retentiebeleid hebben dat rekening houdt met alle relevante vereisten en dit beleid consistent toepassen op alle logopslaglocaties. Bovendien moeten logs worden beschermd tegen ongeautoriseerde toegang, wijziging of verwijdering, wat vereist dat toegang tot logbestemmingen wordt beheerd via RBAC en dat logopslaglocaties voldoen aan beveiligingsstandaarden zoals encryptie in transit en at rest. Incomplete logging kan leiden tot compliance-schendingen en kan organisaties blootstellen aan juridische risico's en boetes, vooral in het geval van beveiligingsincidenten waarbij incomplete logging het onmogelijk maakt om adequaat te onderzoeken wat er is gebeurd. Wanneer een beveiligingsincident plaatsvindt, moeten organisaties vaak kunnen aantonen dat zij adequate beveiligingsmaatregelen hebben genomen, inclusief logging. Als logs ontbreken of incompleet zijn, kan dit worden geïnterpreteerd als nalatigheid en kunnen organisaties verantwoordelijk worden gehouden voor schade die had kunnen worden voorkomen met adequate logging. In het geval van datalekken kan onvoldoende logging zelfs leiden tot hogere AVG-boetes, aangezien toezichthouders kunnen concluderen dat de organisatie niet voldoende maatregelen had genomen om persoonsgegevens te beschermen.

Remediatie

Gebruik PowerShell-script diagnostic-setting-categories.ps1 (functie Invoke-Remediation) – Herstellen.

Wanneer monitoring afwijkingen detecteert waarbij niet alle logcategorieën zijn ingeschakeld voor bepaalde resources, moet onmiddellijk remediatie plaatsvinden. De snelheid van remediatie is cruciaal, omdat elke dag dat logging onvolledig is, een dag is waarin potentiële beveiligingsincidenten niet kunnen worden gedetecteerd of onderzocht. Voor kritieke resources met hoge beveiligingsrisico's of die persoonsgegevens verwerken, moet remediatie binnen 24 uur plaatsvinden. Voor minder kritieke resources kan een langere termijn acceptabel zijn, maar moet wel binnen een redelijke termijn worden afgerond, bijvoorbeeld binnen een week. Het remediatieproces begint met het identificeren van welke specifieke logcategorieën ontbreken voor welke resources en het bepalen van de oorzaak van deze afwijking. Deze analyse is belangrijk om niet alleen het symptoom te verhelpen maar ook de onderliggende oorzaak aan te pakken, zodat het probleem niet opnieuw optreedt. Mogelijke oorzaken zijn onvolledige initiële configuratie wanneer resources voor het eerst werden aangemaakt, onbedoelde wijzigingen in diagnostische instellingen door handmatige aanpassingen of scripts, of automatische updates van Azure-services die configuraties hebben gewijzigd. Door de oorzaak te begrijpen kunnen organisaties procesverbeteringen implementeren om toekomstige afwijkingen te voorkomen. Remediatie vereist dat de ontbrekende logcategorieën worden toegevoegd aan de diagnostische instelling configuratie van de betreffende resources. Dit kan worden uitgevoerd via PowerShell door de bestaande diagnostische instellingen op te halen met Get-AzDiagnosticSetting en de ontbrekende categorieën toe te voegen aan de configuratie met Set-AzDiagnosticSetting. Het is belangrijk om de bestaande configuratie te behouden en alleen de ontbrekende categorieën toe te voegen, om te voorkomen dat andere instellingen zoals logbestemmingen of retentieperioden per ongeluk worden gewijzigd. Voor bulk-remediatie met veel resources kunnen scripts worden ontwikkeld die automatisch alle afwijkingen herstellen, maar dit moet zorgvuldig worden getest voordat het wordt uitgevoerd op productie-omgevingen. Het is belangrijk om tijdens remediatie te verifiëren dat de logbestemmingen (Log Analytics workspace, opslagaccount, of Event Hub) correct zijn geconfigureerd en dat ze voldoen aan de retentievereisten van de organisatie. Als een resource geen diagnostische instelling heeft, moet niet alleen de logcategorieën worden geconfigureerd, maar ook de logbestemmingen. De keuze van logbestemming moet zijn gebaseerd op de logging-strategie van de organisatie en moet voldoen aan alle compliance-vereisten. Bij het toevoegen van nieuwe categorieën aan een bestaande diagnostische instelling is het belangrijk om te verifiëren dat de bestaande bestemmingen nog steeds geschikt zijn voor de nieuwe categorieën en dat er voldoende capaciteit is om de extra logdata op te slaan. Na remediatie moeten organisaties verifiëren dat alle logcategorieën nu correct zijn ingeschakeld en dat logs daadwerkelijk worden gegenereerd en opgeslagen. Dit vereist testen van de logging-functionaliteit om te bevestigen dat alle categorieën correct werken en data produceren. Eenvoudigweg verifiëren dat de categorieën zijn ingeschakeld in de configuratie is niet voldoende; het is essentieel om te bevestigen dat de logs daadwerkelijk worden gegenereerd en opgeslagen. Dit kan worden gedaan door activiteiten te triggeren die de betreffende logcategorieën zouden moeten produceren en vervolgens te verifiëren dat deze logs verschijnen in de logbestemmingen. Voor sommige logcategorieën kan het enige tijd duren voordat logs worden gegenereerd, dus het testen moet rekening houden met deze vertragingen. Remediatie moet ook worden gedocumenteerd met details over welke resources zijn aangepast, welke categorieën zijn toegevoegd, en wanneer de remediatie heeft plaatsgevonden. Deze documentatie is belangrijk voor audit-doeleinden en om trends te identificeren in logging-configuratieproblemen. Door patronen te identificeren in welke resources of resourcetypen vaak afwijkingen vertonen, kunnen organisaties gerichte verbeteringen implementeren om deze problemen te voorkomen. De documentatie moet ook informatie bevatten over de oorzaak van de afwijking en welke maatregelen zijn genomen om herhaling te voorkomen. Dit helpt bij het opbouwen van organisatorische kennis en het verbeteren van processen over de tijd. Organisaties moeten ook een proces opzetten om herhaling van problemen te voorkomen, bijvoorbeeld door automatische checks in te bouwen in CI/CD-pipelines of door regelmatige verificatie uit te voeren. Preventieve maatregelen zijn effectiever dan reactieve remediatie, omdat ze problemen voorkomen voordat ze optreden. Azure Policy kan worden gebruikt om automatisch te controleren dat nieuwe resources diagnostische instellingen hebben met alle logcategorieën ingeschakeld, en om automatische remediatie toe te passen wanneer afwijkingen worden gedetecteerd. Daarnaast moeten wijzigingen aan diagnostische instellingen worden beheerd via change management processen waarbij wijzigingen worden gereviewed voordat ze worden toegepast, om te voorkomen dat configuraties onbedoeld worden gewijzigd. In gevallen waar remediatie complex is of veel resources betreft, kan het nodig zijn om een gefaseerde aanpak te volgen waarbij eerst de meest kritieke resources worden aangepakt en daarna systematisch alle andere resources worden gerepareerd. Kritieke resources zijn doorgaans die welke gevoelige gegevens verwerken, direct toegankelijk zijn vanaf het internet, of essentieel zijn voor de bedrijfsvoering. Door prioriteit te geven aan deze resources, wordt de grootste impact op beveiliging en compliance zo snel mogelijk gerealiseerd. Voor minder kritieke resources kan een meer geplande aanpak worden gevolgd waarbij resources systematisch worden geïnventariseerd en gerepareerd over een langere periode. Deze gefaseerde aanpak helpt ook om de impact op operationele activiteiten te minimaliseren, aangezien remediatie mogelijk kortstondige onderbrekingen kan veroorzaken of extra belasting kan toevoegen aan resources tijdens de configuratiewijzigingen.

Compliance & Frameworks

• CIS M365: Control 5.1.4 (L1) - Alle logcategorieën
• BIO: 12.04 - Uitgebreide logging

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

Diagnostische Instelling Categorieën: Schakel ALLE beschikbare logcategorieën per resource in (Administratief, Beveiliging, ServiceHealth, Waarschuwing, etc.). Volledige logging. Activatie: Diagnostische instellingen → Selecteer alle categorieën. Kosten: verhoogde data-opname (€5-20/resource/maand). Verplicht CIS 5.1.4. Implementatie: 1-2 uur verificatie. Uitgebreide logging.

• Implementatietijd: 1 uur
• FTE required: 0.02 FTE