Azure Monitoring: Resource Logging Inschakelen Voor Alle Resources

Resource Logging biedt datavlakzichtbaarheid die het Azure Activity Log, dat alleen besturingsvlaklogging biedt, niet heeft. Het Activity Log toont wie een resource heeft aangemaakt of verwijderd, maar Resource Logs tonen wat er binnen de resource gebeurt tijdens de werking. Voor Key Vaults wordt gelogd welke geheimen zijn benaderd door welke identiteiten, voor SQL Databases wordt elke query geauditeerd met gebruiker en tijdstempel, voor App Services worden HTTP-verzoeken gelogd inclusief bron-IP-adressen en responscodes, voor Storage Accounts worden blob-lees-, schrijf- en verwijderingsoperaties bijgehouden, en voor Virtual Machines worden opstartdiagnostiek en prestatiemetrieken verzameld. Zonder Resource Logging ontbreken deze operationele en beveiligingslogs, wat beveiligingsincidentonderzoek onmogelijk maakt, probleemoplossing van applicatieproblemen extreem moeilijk wordt, nalevingsaudits falen omdat er geen audittrails zijn van gegevenstoegang, en anomaliedetectie niet mogelijk is omdat basisgedrag niet wordt geregistreerd. Nalevingsframeworks vereisen resource-niveau logging: ISO 27001 controle A.12.4.1 eist uitgebreide gebeurtenislogging, BIO 12.04 vereist logging van resourceoperaties, NIS2 Artikel 21 verplicht logging voor kritieke systemen, en NIST AU-2 vereist dat controleerbare gebeurtenissen worden gelogd. Resource Logging lost dit op door per resourcetype relevante logcategorieën te verzamelen en naar een Log Analytics Workspace te sturen voor bevraging, waarschuwingen en langetermijnbewaring. Deze logging is essentieel voor Nederlandse overheidsorganisaties die moeten voldoen aan strikte beveiligings- en nalevingsvereisten volgens de Baseline Informatiebeveiliging Overheid en andere relevante frameworks.

Implementatie

Deze maatregel implementeert Resource Logging, ook wel diagnostische instellingen genoemd, voor alle Azure-resources. De configuratie omvat per resourcetype het inschakelen van diagnostische instellingen met relevante logcategorieën, bestemming naar een Log Analytics Workspace, en optioneel een Storage Account voor archivering. Kritieke resources zoals Key Vaults, SQL Databases, Storage Accounts, App Services en Network Security Groups moeten uitgebreide logging hebben ingeschakeld. Implementatie kan plaatsvinden via het ingebouwde Azure Policy initiatief 'Enable logging for Azure resources' of handmatig per resource. De implementatie kost vier uur en is verplicht voor CIS Azure Benchmark controle 5.1.3 Level 1 en BIO 12.04. Deze maatregel zorgt ervoor dat alle resources adequate logging hebben ingeschakeld, wat essentieel is voor beveiligingsmonitoring, probleemoplossing en naleving.

Vereisten

Voor het implementeren van Resource Logging op alle Azure-resources zijn specifieke technische en organisatorische vereisten noodzakelijk om ervoor te zorgen dat de logging effectief kan worden ingezet en voldoet aan de gestelde beveiligings- en nalevingsstandaarden. Organisaties moeten een grondige evaluatie uitvoeren van hun huidige Azure-infrastructuur om te bepalen welke resources logging vereisen en welke logcategorieën relevant zijn voor elk resourcetype. Deze evaluatie vormt de basis voor een succesvolle implementatie en moet worden uitgevoerd door ervaren IT-professionals die volledig begrijpen welke logging essentieel is voor beveiligingsmonitoring, probleemoplossing en naleving. De primaire technische vereiste is de aanwezigheid van een Log Analytics Workspace waar alle Resource Logs kunnen worden verzameld en opgeslagen. Een Log Analytics Workspace is een centrale locatie voor het verzamelen, analyseren en bewaren van loggegevens uit verschillende Azure-resources. Deze workspace maakt het mogelijk om loggegevens te bevragen met KQL, waarschuwingen te configureren op basis van loggegevens, en loggegevens langdurig te bewaren voor nalevingsdoeleinden. Organisaties moeten ervoor zorgen dat de Log Analytics Workspace is geconfigureerd met de juiste retentie-instellingen, wat doorgaans minimaal zeven jaar is voor overheidsorganisaties volgens Nederlandse wetgeving. De workspace moet ook zijn geconfigureerd met de juiste toegangsbeperkingen om te voorkomen dat onbevoegde personen toegang hebben tot gevoelige loggegevens. Naast een Log Analytics Workspace kunnen organisaties ook optioneel een Storage Account configureren voor archivering van loggegevens. Dit Storage Account kan worden gebruikt voor langetermijnbewaring van loggegevens die niet regelmatig worden geraadpleegd, maar die wel moeten worden bewaard voor nalevingsdoeleinden. Het gebruik van een Storage Account voor archivering kan kostenbesparend zijn omdat Log Analytics Workspace opslagkosten kan oplopen bij grote hoeveelheden loggegevens. Organisaties moeten echter zorgvuldig evalueren of archivering nodig is, omdat het kan leiden tot complexiteit in het beheer van loggegevens en het kan moeilijker maken om loggegevens te bevragen en te analyseren. Een kritische technische vereiste is de beschikbaarheid van Azure Resource Manager API-toegang voor het configureren van diagnostische instellingen op alle resources. Dit vereist dat organisaties beschikken over de juiste Azure-abonnementen en resourcegroepen waar de resources zich bevinden. Het is belangrijk om te begrijpen dat diagnostische instellingen worden geconfigureerd op het niveau van individuele resources, wat betekent dat organisaties een duidelijk overzicht moeten hebben van alle resources die logging vereisen. Voor grote omgevingen met honderden of duizenden resources kan het configureren van diagnostische instellingen op alle resources een aanzienlijke inspanning vereisen, maar dit is essentieel voor een effectieve implementatie. Organisaties kunnen geautomatiseerde scripts gebruiken om diagnostische instellingen te configureren op meerdere resources tegelijk, wat de implementatie versnelt en het risico van menselijke fouten vermindert. Voor het configureren van diagnostische instellingen is toegang vereist met voldoende privileges. Het configureren van diagnostische instellingen vereist typisch de rol van Eigenaar of Inzender op het abonnement of de resourcegroep. Organisaties moeten ervoor zorgen dat alleen bevoegde personen deze rollen hebben en dat toegang wordt beheerd volgens het principe van minimale rechten. Dit betekent dat alleen personen die daadwerkelijk verantwoordelijk zijn voor het beheer van logging toegang moeten hebben tot deze privileges, en dat alle toegang wordt gelogd en gemonitord voor beveiligingsdoeleinden. Het gebruik van Azure Privileged Identity Management kan helpen bij het beheren van deze privileges door just-in-time toegang te bieden en alle toegang te loggen voor audit-doeleinden. Naast technische vereisten zijn er ook organisatorische vereisten die moeten worden vervuld. Organisaties moeten beschikken over gekwalificeerd IT-personeel met kennis van Azure Monitor en diagnostische instellingen. Het implementeren en onderhouden van Resource Logging vereist begrip van verschillende resourcetypen, relevante logcategorieën per resourcetype, en de impact van logging op kosten en prestaties. Dit personeel moet niet alleen technische kennis hebben, maar ook begrijpen welke logging essentieel is voor beveiligingsmonitoring en naleving. Daarnaast moeten organisaties procedures ontwikkelen voor het beheren van Resource Logging, inclusief het identificeren van resources die logging vereisen, het configureren van diagnostische instellingen, en het monitoren van logging om te verifiëren dat alle resources adequate logging hebben ingeschakeld. Een belangrijke organisatorische vereiste is ook de beschikbaarheid van een wijzigingsbeheerproces voor het configureren en wijzigen van diagnostische instellingen. Wijzigingen aan logging-configuraties kunnen impact hebben op de hoeveelheid loggegevens die wordt verzameld en de kosten die worden gegenereerd, en moeten daarom zorgvuldig worden gepland en uitgevoerd. Het wijzigingsbeheerproces moet duidelijk definiëren wie verantwoordelijk is voor het beheren van Resource Logging, welke goedkeuringsprocessen gelden voor wijzigingen, en hoe wijzigingen worden gedocumenteerd en gecommuniceerd. Goed wijzigingsbeheer voorkomt onbedoelde wijzigingen aan logging-configuraties en zorgt ervoor dat alle wijzigingen traceerbaar zijn voor audit-doeleinden. Tot slot is een belangrijke vereiste de beschikbaarheid van documentatie en inventarisatie van alle resources en hun loggingstatus. Organisaties moeten in staat zijn om regelmatig te rapporteren over welke resources logging hebben ingeschakeld, welke resources logging missen, en welke logcategorieën zijn geconfigureerd voor elk resourcetype. Deze documentatie is essentieel voor nalevingsdoeleinden en maakt het mogelijk om de effectiviteit van de implementatie te meten en te verbeteren over tijd. Effectieve documentatie helpt ook bij het onboarden van nieuwe teamleden en het overdragen van kennis wanneer teamleden de organisatie verlaten. De documentatie moet regelmatig worden bijgewerkt wanneer nieuwe resources worden toegevoegd of wanneer bestaande resources worden gewijzigd, en moet beschikbaar zijn voor auditors en nalevingsfunctionarissen. Goede documentatie maakt het mogelijk om snel te identificeren welke resources logging vereisen en waarom, wat essentieel is voor het onderhouden van een effectieve beveiligingspositie.

Implementatie

Gebruik PowerShell-script resource-logging-enabled.ps1 (functie Invoke-Implementation) – Implementeren.

De implementatie van Resource Logging op alle Azure-resources vereist een gestructureerde aanpak waarbij organisaties systematisch alle resources identificeren en diagnostische instellingen configureren om logging in te schakelen voor relevante logcategorieën. Het implementatieproces begint met een grondige inventarisatie van alle Azure-resources om te bepalen welke resources logging vereisen en welke logcategorieën relevant zijn voor elk resourcetype, gevolgd door de daadwerkelijke configuratie van diagnostische instellingen voor elke resource. Deze systematische aanpak zorgt ervoor dat geen enkele resource wordt overgeslagen en dat alle diagnostische instellingen correct worden geconfigureerd volgens de organisatorische standaarden en beste praktijken. De eerste stap in het implementatieproces is het identificeren van alle resources binnen de Azure-omgeving die logging vereisen. Dit omvat het uitvoeren van een volledige inventarisatie van alle resources in alle abonnementen en resourcegroepen. Organisaties moeten resources evalueren op basis van hun kritiekheid en de behoefte aan logging, waarbij factoren zoals beveiligingsimpact, nalevingsvereisten, en operationele behoeften worden overwogen. Deze evaluatie moet worden uitgevoerd door ervaren IT-professionals die volledig begrijpen welke logging essentieel is voor beveiligingsmonitoring en naleving. Kritieke resources zoals Key Vaults, SQL Databases, Storage Accounts, App Services en Network Security Groups moeten uitgebreide logging hebben ingeschakeld, omdat deze resources vaak gevoelige gegevens bevatten of kritieke beveiligingsfuncties bieden. Voor elke geïdentificeerde resource moet een diagnostische instelling worden geconfigureerd met de relevante logcategorieën voor dat resourcetype. Dit kan worden gedaan via de Azure Portal door te navigeren naar de resource, vervolgens naar de sectie Diagnostische instellingen, en de optie Diagnostische instelling toevoegen te selecteren. Bij het toevoegen van een diagnostische instelling moeten de relevante logcategorieën worden geselecteerd voor het resourcetype, en moet een bestemming worden geselecteerd, typisch een Log Analytics Workspace. Voor Key Vaults zijn relevante logcategorieën bijvoorbeeld AuditEvent en AllMetrics, voor SQL Databases zijn relevante logcategorieën SQLSecurityAuditEvents en DatabaseWaitStatistics, voor App Services zijn relevante logcategorieën AppServiceHTTPLogs en AppServiceConsoleLogs, en voor Storage Accounts zijn relevante logcategorieën StorageRead, StorageWrite en StorageDelete. Het is belangrijk om alleen relevante logcategorieën te selecteren om onnodige kosten te voorkomen, maar ook om ervoor te zorgen dat alle essentiële logging is ingeschakeld voor beveiligingsmonitoring en naleving. Naast het configureren van diagnostische instellingen via de Azure Portal kunnen diagnostische instellingen ook worden geconfigureerd via PowerShell met de cmdlet Set-AzDiagnosticSetting of via Azure CLI met de opdracht az monitor diagnostic-settings create. Deze aanpak is bijzonder nuttig voor grote omgevingen met veel resources, omdat het mogelijk maakt om diagnostische instellingen programmatisch te configureren op meerdere resources tegelijk. PowerShell-scripts kunnen worden ontwikkeld die automatisch alle resources in een resourcegroep of abonnement scannen en diagnostische instellingen configureren op resources die nog geen diagnostische instellingen hebben, wat de implementatie versnelt en het risico van menselijke fouten vermindert. Voor nog geavanceerdere scenario's kunnen diagnostische instellingen ook worden geconfigureerd via Azure Resource Manager-sjablonen of Infrastructure as Code-oplossingen zoals Terraform of Bicep. Deze aanpak maakt het mogelijk om diagnostische instellingen te definiëren als onderdeel van de resource-definitie, wat ervoor zorgt dat diagnostische instellingen automatisch worden geconfigureerd wanneer resources worden geïmplementeerd. Dit is bijzonder waardevol voor nieuwe resources, omdat het voorkomt dat resources worden geïmplementeerd zonder de juiste logging. Voor organisaties die een meer geautomatiseerde aanpak willen, kan Azure Policy worden gebruikt om ervoor te zorgen dat alle resources diagnostische instellingen hebben geconfigureerd. Azure Policy biedt ingebouwde initiatieven zoals 'Enable logging for Azure resources' die automatisch diagnostische instellingen configureren op alle resources die voldoen aan bepaalde criteria. Deze aanpak is bijzonder effectief voor grote omgevingen omdat het ervoor zorgt dat nieuwe resources automatisch logging hebben ingeschakeld zonder handmatige interventie. Azure Policy kan ook worden gebruikt om te controleren of bestaande resources diagnostische instellingen hebben geconfigureerd en om automatisch diagnostische instellingen te configureren op resources die deze missen. Het gebruik van Azure Policy voor Resource Logging zorgt ervoor dat logging consistent wordt toegepast op alle resources en dat nieuwe resources automatisch worden beschermd vanaf het moment van implementatie. Na het configureren van diagnostische instellingen moet worden geverifieerd dat logging correct is geconfigureerd en functioneert zoals verwacht. Dit omvat het controleren van de diagnostische instelling-configuratie voor elke resource, het valideren dat loggegevens daadwerkelijk worden verzameld in de Log Analytics Workspace, en het testen van query's om te bevestigen dat loggegevens beschikbaar zijn voor bevraging en analyse. Het is belangrijk om te verifiëren dat relevante logcategorieën zijn ingeschakeld en dat loggegevens correct worden verzameld, omdat het ontbreken van essentiële logging kan leiden tot beveiligingsblindheid en nalevingsproblemen. Deze verificatie moet worden uitgevoerd voor een representatieve steekproef van resources om te bevestigen dat de implementatie succesvol is geweest. Als er problemen worden geïdentificeerd tijdens de verificatie, moeten deze onmiddellijk worden opgelost voordat de implementatie als voltooid wordt beschouwd. Het implementatieproces moet worden afgerond met documentatie van alle geconfigureerde diagnostische instellingen. Deze documentatie moet informatie bevatten over welke resources diagnostische instellingen hebben, welke logcategorieën zijn ingeschakeld voor elk resourcetype, waar loggegevens worden verzameld, en wie verantwoordelijk is voor het beheer van de logging. Deze documentatie is essentieel voor nalevingsdoeleinden en maakt het mogelijk om de implementatie te onderhouden en te verbeteren over tijd. Goede documentatie helpt ook bij het onboarden van nieuwe teamleden en het overdragen van kennis wanneer teamleden de organisatie verlaten. De documentatie moet regelmatig worden bijgewerkt wanneer nieuwe resources worden toegevoegd of wanneer bestaande resources worden gewijzigd, en moet beschikbaar zijn voor auditors en nalevingsfunctionarissen. De implementatie van Resource Logging kost doorgaans vier uur voor identificatie en configuratie, en is verplicht voor alle productiekritieke resources volgens CIS Azure Benchmark controle 5.1.3 Level 1 en BIO 12.04. Deze relatief kleine investering in tijd biedt aanzienlijke bescherming tegen beveiligingsblindheid en helpt organisaties te voldoen aan beveiligings- en nalevingsvereisten.

Naleving en Audit

De implementatie van Resource Logging op alle Azure-resources is direct gerelateerd aan naleving met verschillende beveiligings- en gegevensbeschermingsstandaarden, waaronder de Baseline Informatiebeveiliging Overheid (BIO), ISO 27001, CIS Azure Benchmark, en andere relevante frameworks. Deze maatregel ondersteunt organisaties bij het voldoen aan wettelijke verplichtingen voor logging en monitoring, wat essentieel is voor Nederlandse overheidsorganisaties die verantwoordelijk zijn voor het beschermen van gevoelige gegevens en kritieke infrastructuren. Naleving met deze standaarden is niet alleen een best practice, maar vaak een wettelijke verplichting die organisaties moeten naleven om te voorkomen dat zij worden geconfronteerd met boetes, reputatieschade, en andere juridische gevolgen. De CIS Azure Benchmark controle 5.1.3 Level 1 vereist specifiek dat Resource Logging is ingeschakeld voor alle Azure-resources. Deze controle is onderdeel van de CIS Azure Benchmark, een uitgebreide set beveiligingsaanbevelingen voor Azure-omgevingen die wordt ontwikkeld door het Center for Internet Security. Naleving van CIS Azure Benchmark controles is essentieel voor organisaties die hun Azure-omgeving willen beveiligen volgens industrie-standaarden. Resource Logging voldoet aan deze controle door ervoor te zorgen dat alle resources adequate logging hebben ingeschakeld, wat essentieel is voor beveiligingsmonitoring en incidentonderzoek. Tijdens audits moet kunnen worden aangetoond dat Resource Logging is geconfigureerd voor alle relevante resources en dat logging effectief is in het verzamelen van essentiële loggegevens. Auditors zullen controleren of organisaties een volledige inventarisatie hebben van alle resources, of diagnostische instellingen correct zijn geconfigureerd, en of loggegevens daadwerkelijk worden verzameld en beschikbaar zijn voor analyse. Het ontbreken van adequate Resource Logging kan leiden tot negatieve auditbevindingen en de noodzaak tot snelle remediatie. De Baseline Informatiebeveiliging Overheid (BIO) controle 12.04 vereist specifiek logging van resource-operaties. Resource Logging biedt deze logging door ervoor te zorgen dat alle resources adequate logging hebben ingeschakeld voor hun operaties, wat essentieel is voor beveiligingsmonitoring en naleving. Voor Nederlandse overheidsorganisaties is naleving met BIO-normen niet alleen een best practice, maar een wettelijke verplichting die voortvloeit uit de Wet informatieveiligheid overheid. Organisaties moeten kunnen aantonen dat zij passende maatregelen hebben genomen om logging in te schakelen voor alle relevante resources, en Resource Logging vormt een concrete manier om aan deze verplichting te voldoen. Tijdens audits moet kunnen worden aangetoond dat Resource Logging is geconfigureerd voor alle relevante resources en dat logging effectief is in het verzamelen van essentiële loggegevens. Auditors zullen controleren of organisaties een volledige inventarisatie hebben van alle resources, of diagnostische instellingen correct zijn geconfigureerd, en of procedures bestaan voor het beheren van logging. Het ontbreken van adequate Resource Logging kan leiden tot negatieve auditbevindingen en de noodzaak tot snelle remediatie. De ISO 27001 standaard controle A.12.4.1 vereist uitgebreide gebeurtenislogging. Resource Logging voldoet aan deze vereiste door ervoor te zorgen dat alle resources adequate logging hebben ingeschakeld voor hun operaties, wat essentieel is voor beveiligingsmonitoring en incidentonderzoek. De logging biedt een extra beveiligingslaag die voorkomt dat beveiligingsincidenten onopgemerkt blijven en maakt het mogelijk om beveiligingsincidenten te onderzoeken en te analyseren. Organisaties die ISO 27001 certificering nastreven of behouden moeten kunnen demonstreren dat zij effectieve maatregelen hebben geïmplementeerd om logging in te schakelen voor alle relevante resources, en Resource Logging biedt een bewezen oplossing voor deze vereiste. Tijdens ISO 27001 audits moeten organisaties bewijs kunnen leveren van de configuratie van Resource Logging, de identificatie van resources die logging vereisen, en het gebruik van logging voor beveiligingsmonitoring. Certificeringsinstanties zullen controleren of de implementatie volledig is, of logging effectief is, en of procedures bestaan voor het beheren en monitoren van logging. Het niet voldoen aan ISO 27001 vereisten kan leiden tot het verlies van certificering, wat aanzienlijke impact kan hebben op de reputatie en het vermogen van organisaties om zaken te doen. Het auditingproces voor deze maatregel moet regelmatig worden uitgevoerd om te verifiëren dat Resource Logging correct is geconfigureerd en effectief is in het verzamelen van essentiële loggegevens. Audits moeten worden uitgevoerd door onafhankelijke partijen of interne auditafdelingen, en moeten een volledige inventarisatie bevatten van alle resources en hun logging-configuraties. De auditresultaten moeten worden gedocumenteerd en beschikbaar zijn voor externe auditors en toezichthouders. Effectieve audits helpen organisaties niet alleen om naleving te demonstreren, maar ook om gebieden te identificeren waar verbeteringen mogelijk zijn. Tijdens audits moeten organisaties kunnen aantonen dat Resource Logging is geconfigureerd voor alle relevante resources, dat logging effectief is in het verzamelen van essentiële loggegevens, en dat procedures bestaan voor het beheren van logging. Audits moeten minimaal jaarlijks worden uitgevoerd, maar voor organisaties met hoge beveiligingseisen wordt aanbevolen om vaker te auditen, bijvoorbeeld halfjaarlijks of zelfs kwartaal. Regelmatige audits maken het mogelijk om problemen vroegtijdig te identificeren en te remediëren voordat ze worden ontdekt tijdens externe audits of certificeringscontroles. Voor audit-doeleinden moeten organisaties bewijs kunnen leveren van hun nalevingsstatus. Dit omvat inventarissen van alle resources met hun logging-configuraties, rapporten van logging-beheeractiviteiten, en documentatie van procedures voor het configureren en beheren van logging. Deze documentatie moet worden bewaard voor de vereiste bewaartermijn, welke doorgaans minimaal zeven jaar is voor overheidsorganisaties. Goede documentatie maakt het mogelijk om de nalevingshistorie te traceren en te demonstreren dat de organisatie proactief werkt aan het handhaven van standaarden, zelfs wanneer er incidenteel afwijkingen optreden. Organisaties moeten ook procedures hebben voor het omgaan met uitzonderingen op logging-vereisten, waarbij duidelijk wordt aangegeven onder welke omstandigheden logging tijdelijk kan worden uitgeschakeld en welke goedkeuringsprocessen hiervoor gelden. Deze uitzonderingen moeten strikt worden gecontroleerd en gelogd, en moeten worden goedgekeurd door bevoegde personen die volledig begrijpen wat de gevolgen zijn van het uitschakelen van logging. Alle uitzonderingen moeten worden gedocumenteerd met een duidelijke business justification en moeten regelmatig worden geëvalueerd om te bepalen of ze nog steeds nodig zijn. Naast formele audits moeten organisaties ook regelmatig zelfevaluaties uitvoeren om te verifiëren dat Resource Logging correct is geconfigureerd en effectief is. Deze zelfevaluaties moeten worden uitgevoerd door interne teams en moeten dezelfde criteria gebruiken als formele audits. Regelmatige zelfevaluaties maken het mogelijk om problemen vroegtijdig te identificeren en te remediëren voordat ze worden ontdekt tijdens formele audits. Ze helpen ook bij het onderhouden van een continue focus op naleving en het verbeteren van de effectiviteit van Resource Logging over tijd. Zelfevaluaties moeten worden uitgevoerd door teams die onafhankelijk zijn van de teams die verantwoordelijk zijn voor het dagelijkse beheer van resources, om te waarborgen dat evaluaties objectief zijn en dat problemen niet worden over het hoofd gezien. De resultaten van zelfevaluaties moeten worden gedocumenteerd en gedeeld met management en nalevingsfunctionarissen, en moeten worden gebruikt om verbeteringen te identificeren en te implementeren. Effectieve naleving met Resource Logging vereist een combinatie van technische implementatie, organisatorische processen, en regelmatige verificatie om te waarborgen dat alle resources adequate logging hebben ingeschakeld en dat organisaties voldoen aan alle relevante beveiligings- en nalevingsstandaarden.

Monitoring

Gebruik PowerShell-script resource-logging-enabled.ps1 (functie Invoke-Monitoring) – Controleren.

Effectieve monitoring van Resource Logging op alle Azure-resources is essentieel om te waarborgen dat logging correct is geconfigureerd en effectief is in het verzamelen van essentiële loggegevens. Het monitoren van Resource Logging vereist een gestructureerde aanpak waarbij regelmatig wordt gecontroleerd of diagnostische instellingen correct zijn geconfigureerd op alle resources, of loggegevens daadwerkelijk worden verzameld, en of er nieuwe resources zijn geïdentificeerd die logging vereisen. Zonder adequate monitoring kunnen organisaties niet garanderen dat hun resources adequate logging hebben ingeschakeld, wat kan leiden tot beveiligingsblindheid en nalevingsproblemen. De monitoringactiviteiten moeten systematisch worden uitgevoerd door middel van geautomatiseerde controles die verifiëren dat diagnostische instellingen zijn geconfigureerd voor alle relevante resources en dat loggegevens daadwerkelijk worden verzameld. Deze controles moeten minimaal maandelijks worden uitgevoerd, maar voor organisaties met hoge beveiligingseisen wordt aanbevolen om wekelijkse of zelfs dagelijkse controles uit te voeren. Het gebruik van geautomatiseerde monitoringoplossingen voorkomt menselijke fouten en zorgt ervoor dat problemen direct worden gedetecteerd, zelfs wanneer nieuwe resources worden toegevoegd of bestaande resources worden gewijzigd. Geautomatiseerde monitoring maakt het ook mogelijk om trends te identificeren en proactief te reageren op veranderende omstandigheden. Het monitoringproces begint met het verifiëren dat diagnostische instellingen zijn geconfigureerd voor alle resources in productieomgevingen. Dit omvat het controleren van alle resources in alle Azure-abonnementen en resourcegroepen om te bepalen welke resources diagnostische instellingen hebben en welke niet. Resources zonder diagnostische instellingen moeten worden geïdentificeerd en gemarkeerd voor configuratie, omdat het missen van zelfs één kritieke resource kan leiden tot beveiligingsblindheid. Het is belangrijk dat het monitoringproces ook resources identificeert waarvan de diagnostische instelling-configuratie mogelijk is gewijzigd of verwijderd, omdat dit kan wijzen op onbedoelde wijzigingen of beveiligingsproblemen. Naast het verifiëren van de configuratie moet het monitoringproces ook controleren of Resource Logging daadwerkelijk functioneert zoals verwacht. Dit omvat het verifiëren dat loggegevens daadwerkelijk worden verzameld in de Log Analytics Workspace, dat relevante logcategorieën zijn ingeschakeld, en dat loggegevens beschikbaar zijn voor bevraging en analyse. Problemen met logging-functionaliteit kunnen wijzen op configuratiefouten, privilege-problemen, of serviceproblemen met Azure Monitor. Het is belangrijk dat deze problemen snel worden gedetecteerd en opgelost, omdat het ontbreken van effectieve logging kan leiden tot beveiligingsblindheid en nalevingsproblemen. Het monitoringproces moet ook controleren of er nieuwe resources zijn toegevoegd die logging vereisen. Dit omvat het scannen van alle nieuwe resources die zijn geïmplementeerd sinds de laatste monitoringcyclus en het evalueren of deze resources diagnostische instellingen vereisen. Nieuwe Key Vaults, SQL Databases, Storage Accounts, App Services, Network Security Groups, en andere kritieke resources moeten allemaal worden geëvalueerd om te bepalen of ze diagnostische instellingen vereisen. Het is belangrijk dat dit proces automatisch wordt uitgevoerd om te voorkomen dat nieuwe resources worden geïmplementeerd zonder de juiste logging. Rapportage vormt een cruciaal onderdeel van het monitoringproces. Organisaties moeten regelmatig rapporten genereren die een overzicht geven van de Resource Logging status, het aantal resources met diagnostische instellingen, het aantal resources zonder diagnostische instellingen, en de geplande acties om ontbrekende configuraties te remediëren. Deze rapporten moeten informatie bevatten over het type resources dat diagnostische instellingen heeft, de locatie van deze resources, de verantwoordelijke teams, en de reden waarom resources logging vereisen. De rapporten moeten worden gedeeld met beveiligingsteams, nalevingsfunctionarissen, en management om transparantie te waarborgen. Effectieve rapportage maakt het mogelijk om trends te identificeren, prioriteiten te stellen voor remediatie-activiteiten, en te demonstreren aan auditors dat de organisatie proactief werkt aan het handhaven van naleving. Daarnaast moet het monitoringproces waarschuwingen bevatten voor kritieke problemen zoals kritieke resources zonder diagnostische instellingen, problemen met logging-functionaliteit, of onbevoegde pogingen om diagnostische instellingen te verwijderen. Wanneer een kritieke resource wordt geïdentificeerd zonder diagnostische instellingen, moet direct een waarschuwing worden gegenereerd naar de verantwoordelijke teams. Dit maakt het mogelijk om proactief te reageren op ontbrekende configuraties voordat deze impact hebben op beveiligingsmonitoring. Waarschuwingen moeten worden geconfigureerd met de juiste prioriteit en moeten worden gerouteerd naar de teams die verantwoordelijk zijn voor het beheer van de betreffende resources, zodat snelle actie kan worden ondernomen. Effectieve waarschuwingen maken het mogelijk om problemen snel op te lossen en te voorkomen dat kritieke resources onbeschermd blijven. Het is belangrijk dat de monitoringoplossing ook historische trends kan volgen, zodat organisaties kunnen zien of de Resource Logging status verbetert of verslechtert over tijd. Dit maakt het mogelijk om de effectiviteit van implementatie- en remediatie-activiteiten te meten en te bepalen of aanvullende maatregelen nodig zijn om de gewenste nalevingsstatus te bereiken en te behouden. Historische data kan ook worden gebruikt om te identificeren welke teams of processen het meest bijdragen aan nalevingsproblemen, zodat gerichte verbeteringen kunnen worden geïmplementeerd. Door trends te analyseren kunnen organisaties ook voorspellen wanneer nieuwe resources mogelijk logging nodig hebben, waardoor preventieve maatregelen kunnen worden genomen. Effectieve monitoring van Resource Logging is essentieel voor het waarborgen van continue logging van alle resources en het voldoen aan beveiligings- en nalevingsvereisten.

Remediatie

Gebruik PowerShell-script resource-logging-enabled.ps1 (functie Invoke-Remediation) – Herstellen.

Wanneer resources worden geïdentificeerd die geen Resource Logging hebben of wanneer Resource Logging niet correct functioneert, moeten deze onmiddellijk worden geremediateerd door diagnostische instellingen te configureren of te herstellen. Het remediatieproces moet systematisch worden uitgevoerd om te waarborgen dat alle niet-nalevende resources worden aangepakt zonder onnodige impact op functionaliteit of beveiliging. Effectieve remediatie is essentieel omdat resources zonder logging kwetsbaar zijn voor beveiligingsblindheid, wat kan leiden tot onopgemerkte beveiligingsincidenten en nalevingsproblemen. Het remediatieproces begint met het identificeren van alle resources die remediatie vereisen. Dit wordt gedaan door middel van de monitoring- en auditprocessen die regelmatig worden uitgevoerd. Voor elke geïdentificeerde resource moet worden bepaald waarom diagnostische instellingen ontbreken of niet functioneren, wat kan variëren van eenvoudige configuratiefouten tot complexere problemen met Azure Monitor of privilege-instellingen. Een grondige evaluatie voorkomt onnodige configuratiewijzigingen en zorgt ervoor dat de juiste remediatie-acties worden ondernomen. Het is belangrijk om hierbij ook te evalueren of de resource daadwerkelijk logging vereist, of dat deze mogelijk verkeerd is geclassificeerd, omdat logging vooral belangrijk is voor werkelijk kritieke resources. Voor het uitvoeren van de remediatie moet voor elke resource een configuratieplan worden ontwikkeld dat rekening houdt met de specifieke omstandigheden van de resource en de impact op bedrijfsoperaties. Het configureren van diagnostische instellingen voor een resource is doorgaans een niet-disruptieve operatie die geen impact heeft op de functionaliteit van de resource, maar het is belangrijk om te verifiëren dat de configuratie correct is en dat logging functioneert zoals verwacht. Het configuratieplan moet ook rekening houden met de beschikbaarheid van benodigde privileges en Azure-services, omdat het ontbreken van deze vereisten de remediatie kan belemmeren. Het wordt sterk aanbevolen om remediatie-acties eerst uit te voeren in een testomgeving of tijdens onderhoudsvensters om de impact te minimaliseren, hoewel dit doorgaans niet nodig is voor diagnostische instelling configuratie. Tijdens het configuratieproces moeten organisaties de resource en de logging-functionaliteit continu monitoren om te verifiëren dat de configuratie succesvol is en dat logging correct functioneert. Als er problemen optreden tijdens of na de configuratie, moeten terugdraai-procedures beschikbaar zijn om de configuratie terug te brengen naar de oorspronkelijke staat. Goede monitoring en terugdraai-procedures minimaliseren het risico van langdurige problemen en zorgen ervoor dat problemen snel kunnen worden opgelost. Voor resources die niet direct kunnen worden geconfigureerd vanwege technische beperkingen of bedrijfsvereisten, moeten tijdelijke mitigatiemaatregelen worden geïmplementeerd. Dit kan bijvoorbeeld betekenen dat extra monitoring wordt toegevoegd via alternatieve methoden, dat de resource wordt geëvalueerd voor migratie naar een alternatieve configuratie, of dat aanvullende beveiligingsmaatregelen worden geïmplementeerd om het risico te verminderen. Deze mitigatiemaatregelen moeten echter worden gezien als tijdelijke oplossingen, en er moet een duidelijk plan zijn voor definitieve remediatie. Tijdelijke mitigatie mag nooit worden gebruikt als excuus om definitieve remediatie uit te stellen, omdat dit de organisatie blootstelt aan continue risico's van beveiligingsblindheid. Na het voltooien van de remediatie moet worden geverifieerd dat Resource Logging nu correct is geconfigureerd en functioneert. Dit omvat het controleren van de diagnostische instelling-configuratie, het valideren dat loggegevens daadwerkelijk worden verzameld in de Log Analytics Workspace, en het bevestigen dat loggegevens beschikbaar zijn voor bevraging en analyse. Deze verificatie moet worden gedocumenteerd als bewijs van de uitgevoerde remediatie. Verificatie is essentieel omdat het bevestigt dat de remediatie succesvol is geweest en dat de resource nu voldoet aan alle vereisten. Zonder adequate verificatie kunnen organisaties niet zeker zijn dat de remediatie daadwerkelijk het gewenste resultaat heeft opgeleverd. Het is belangrijk dat alle remediatie-acties worden geregistreerd in het wijzigingsbeheersysteem en worden gecommuniceerd naar de relevante stakeholders. Dit omvat het documenteren van de oorspronkelijke status van de resource, de uitgevoerde remediatie-acties, de nieuwe configuratie, de reden voor de remediatie, en de resultaten van de verificatie. Deze documentatie is essentieel voor nalevingsdoeleinden en maakt het mogelijk om de remediatie-activiteiten te traceren en te auditen. Goede documentatie helpt ook bij het leren van ervaringen en het verbeteren van toekomstige remediatie-processen. Het is ook belangrijk om te documenteren welke lessen zijn geleerd van de remediatie, zodat vergelijkbare problemen in de toekomst kunnen worden voorkomen. Tot slot moet het remediatieproces worden afgerond met een evaluatie van de effectiviteit van de genomen maatregelen. Dit omvat het beoordelen van de impact op beveiligingsmonitoring, naleving, kosten en operationele processen. Als de remediatie negatieve gevolgen heeft gehad, moeten deze worden geanalyseerd en moeten lessen worden getrokken voor toekomstige remediatie-activiteiten. Daarnaast moet worden gecontroleerd of er preventieve maatregelen zijn geïmplementeerd om te voorkomen dat nieuwe resources worden geïmplementeerd zonder diagnostische instellingen. Evaluatie is belangrijk omdat het helpt bij het verbeteren van het remediatieproces en ervoor zorgt dat toekomstige remediaties effectiever en efficiënter kunnen worden uitgevoerd. Door continu te leren van remediatie-activiteiten kunnen organisaties hun beveiligingsmonitoring en nalevingspositie voortdurend verbeteren.

Compliance & Frameworks

• CIS M365: Control 5.1.3 (L1) - Resource logging
• BIO: 12.04 - 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

Alternatieve verificatie voor Resource Logging. Zie diagnostic-settings-all-resources.json voor volledige implementatie (diagnostische instellingen voor ALLE resources). Verplicht CIS 5.1.3.

• Implementatietijd: 4 uur
• FTE required: 0.1 FTE