Azure Monitoring: Diagnostische Instellingen Op Alle Resources Configureren

Het Azure Activiteitenlogboek vormt een fundamenteel onderdeel van de monitoringinfrastructuur binnen Azure-omgevingen, maar heeft een cruciale beperking die organisaties volledig moeten begrijpen voordat zij een accuraat beeld krijgen van hun beveiligings- en operationele status. Dit logboek registreert uitsluitend control plane-operaties, wat betekent dat het alleen vastlegt wie welke beheeracties heeft uitgevoerd op het niveau van resourcebeheer. Wanneer een beheerder bijvoorbeeld een virtuele machine aanmaakt, verwijdert of opnieuw configureert, wordt deze actie vastgelegd in het Activiteitenlogboek. Echter, wat er daarna gebeurt binnen die virtuele machine tijdens de normale werking blijft volledig onzichtbaar voor organisaties die alleen afhankelijk zijn van het Activiteitenlogboek. Deze fundamentele beperking creëert een kritieke blinde vlek in de beveiligings- en operationele monitoring van Azure-omgevingen die organisaties kwetsbaar maakt voor aanvallen en operationele problemen. Zonder diagnostische instellingen ontbreekt cruciaal operationeel en beveiligingsinzicht dat essentieel is voor het effectief beheren en beveiligen van cloudinfrastructuur. Opstartfouten van virtuele machines blijven volledig onzichtbaar, waardoor beheerders niet kunnen achterhalen waarom een systeem niet correct opstart of waarom bepaalde services niet beschikbaar zijn. Deze onzichtbaarheid maakt probleemoplossing extreem moeilijk en kan leiden tot langdurige uitval zonder dat organisaties de onderliggende oorzaak kunnen identificeren. Schijf-I/O-problemen en prestatieknelpunten die de beschikbaarheid en prestaties van applicaties kunnen beïnvloeden worden niet gedetecteerd, wat kan resulteren in slechte gebruikerservaringen en mogelijke verlies van productiviteit. Network Security Group flow logs die verkeersanalyse mogelijk maken en essentieel zijn voor het detecteren van verdacht netwerkverkeer of potentiële aanvallen worden niet verzameld, waardoor beveiligingsteams geen inzicht hebben in wat er daadwerkelijk over het netwerk wordt verzonden. Deze blinde vlek maakt het onmogelijk om netwerkaanvallen te detecteren, te onderzoeken of te voorkomen. Key Vault-toegangslogboeken die tonen wie welke geheimen, sleutels of certificaten heeft benaderd ontbreken volledig zonder diagnostische instellingen, wat betekent dat organisaties niet kunnen controleren wie toegang heeft gehad tot gevoelige credentials of kunnen onderzoeken of er ongeautoriseerde toegang heeft plaatsgevonden. Deze situatie creëert een ernstig beveiligingsrisico omdat organisaties niet kunnen detecteren wanneer iemand onbevoegd toegang heeft gekregen tot kritieke geheimen die kunnen worden gebruikt om verdere aanvallen uit te voeren. SQL Database auditlogboeken van queryactiviteit en gegevens toegang zijn niet beschikbaar, waardoor organisaties niet kunnen achterhalen welke queries zijn uitgevoerd, welke gegevens zijn benaderd of of er mogelijk ongeautoriseerde database-activiteit heeft plaatsgevonden. Dit gebrek aan zichtbaarheid maakt het onmogelijk om datalekken te detecteren of te voorkomen en om te voldoen aan gegevensbeschermingsvereisten. App Service-toepassingslogboeken en HTTP-verzoeklogboeken die cruciaal zijn voor het begrijpen van applicatiegedrag en het detecteren van aanvallen worden niet vastgelegd zonder diagnostische instellingen, waardoor ontwikkelaars en beveiligingsteams geen inzicht hebben in hoe applicaties worden gebruikt of misbruikt. Deze onzichtbaarheid maakt het onmogelijk om applicatie-aanvallen zoals SQL-injectie, cross-site scripting of andere web-aanvallen te detecteren en te onderzoeken. Resourcespecifieke beveiligingsgebeurtenissen zoals authenticatiefouten of autorisatieweigeringen die kunnen wijzen op brute force-aanvallen of pogingen tot ongeautoriseerde toegang blijven volledig ongelogd, waardoor beveiligingsteams deze bedreigingen niet kunnen detecteren of onderzoeken. Dit gebrek aan data plane-logging maakt onderzoek naar beveiligingsincidenten vrijwel onmogelijk, omdat beveiligingsanalisten geen gegevens hebben om te analyseren wanneer er een vermoeden bestaat van een beveiligingsinbreuk. Probleemoplossing van operationele problemen wordt extreem moeilijk omdat beheerders geen inzicht hebben in wat er daadwerkelijk gebeurt binnen resources, waardoor het identificeren van de oorzaak van problemen een tijdrovend en vaak onsuccesvol proces wordt. Deze situatie kan leiden tot langdurige uitval en aanzienlijke impact op de bedrijfsvoering. Nalevingsaudits worden onuitvoerbaar omdat auditors niet kunnen verifiëren of organisaties daadwerkelijk voldoen aan de vereisten voor uitgebreide logging en monitoring die door verschillende compliancestandaarden worden geëist. Nalevingskaders vereisen uitgebreide logging die verder gaat dan alleen control plane-operaties. De BIO-norm vereist in controle 12.04 logging van resourceoperaties, wat betekent dat alle relevante activiteiten binnen resources moeten worden vastgelegd. ISO 27001-controle A.12.4.1 vereist gebeurtenislogging voor beveiligingsrelevante gebeurtenissen, wat betekent dat organisaties moeten kunnen aantonen dat zij alle beveiligingsgebeurtenissen monitoren en vastleggen. De NIS2-richtlijn verplicht in Artikel 21 logging voor incidentdetectie, wat betekent dat organisaties logging moeten hebben die hen in staat stelt beveiligingsincidenten tijdig te detecteren. Het NIST Cybersecurity Framework verplicht in controle AU-2 auditgebeurtenislogging, wat betekent dat organisaties moeten vaststellen welke gebeurtenissen moeten worden geaudit en deze moeten vastleggen in auditlogboeken. Diagnostische instellingen bieden dit essentiële inzicht door resourcespecifieke logboeken en metriek te verzamelen en te verzenden naar centrale opslag waar ze kunnen worden geanalyseerd, gemonitord en gebruikt voor beveiligingsonderzoek en nalevingsverificatie. De logboekcategorieën variëren per resourcetype maar omvatten typisch beveiligingslogboeken die authenticatiepogingen, autorisatiebeslissingen en toegang tot resources vastleggen, auditlogboeken die gegevensoperaties en configuratiewijzigingen documenteren, en operationele logboeken die fouten, prestaties en statusinformatie bevatten die essentieel zijn voor het effectief beheren van cloudinfrastructuur.

Implementatie

Deze maatregel implementeert diagnostische instellingen op alle Azure-resources door systematisch elk resourcetype te configureren voor uitgebreide logging naar Log Analytics-werkruimte voor real-time analyse en monitoring, en optioneel naar opslagaccount voor kosteneffectieve langetermijnarchivering die essentieel is voor nalevingsdoeleinden. De implementatie dekt alle kritieke resourcetypen die diagnostische mogelijkheden ondersteunen, waarbij elk resourcetype specifieke logboekcategorieën heeft die moeten worden ingeschakeld om volledige zichtbaarheid te garanderen. Voor virtuele machines omvat dit opstartdiagnostiek die informatie bevat over het opstartproces en eventuele fouten die optreden tijdens het opstarten, prestatiemeters die inzicht geven in het resourcegebruik en de prestaties van de virtuele machine, en systeemlogboeken die informatie bevatten over het besturingssysteem en de applicaties die op de virtuele machine draaien. Opslagaccounts genereren blob-, bestand-, tabel- en wachtrijtoegangslogboeken die cruciaal zijn voor het monitoren van wie toegang heeft gehad tot opgeslagen gegevens en voor het detecteren van ongeautoriseerde toegangspogingen. Key Vaults produceren toegangslogboeken voor geheimen, sleutels en certificaten die essentieel zijn voor het monitoren van wie toegang heeft gehad tot gevoelige credentials en voor het detecteren van potentiële beveiligingsincidenten. SQL-databases genereren auditlogboeken van queryactiviteit en gegevens toegang die organisaties in staat stellen om te achterhalen welke queries zijn uitgevoerd, welke gegevens zijn benaderd en of er mogelijk ongeautoriseerde database-activiteit heeft plaatsgevonden. Network Security Groups produceren flow logs voor verkeersanalyse die essentieel zijn voor het detecteren van verdacht netwerkverkeer of potentiële aanvallen. App Services genereren toepassingslogboeken en HTTP-verzoeklogboeken die cruciaal zijn voor het begrijpen van applicatiegedrag en het detecteren van aanvallen. Azure Firewalls produceren netwerkverkeerslogboeken die inzicht geven in alle verkeer dat door de firewall wordt gefilterd. Alle andere Azure-resources die diagnostische mogelijkheden ondersteunen moeten ook worden geconfigureerd met de juiste logboekcategorieën. De implementatie wordt het beste uitgevoerd via Azure Policy door de ingebouwde initiatief 'Schakel logging in voor Azure-resources' toe te wijzen die automatische implementatie van diagnostische instellingen voor nieuwe resources afdwingt. Deze aanpak schaalt veel beter dan handmatige configuratie en zorgt ervoor dat nieuwe resources automatisch worden voorzien van de juiste loggingconfiguratie zodra ze worden aangemaakt, waardoor de kans op menselijke fouten wordt geminimaliseerd en de consistentie van de configuratie wordt gegarandeerd. Voor bestaande resources die al zijn aangemaakt voordat het beleid is toegewezen, moet een hersteltaak worden uitgevoerd om de diagnostische instellingen alsnog toe te voegen. Handmatige configuratie per resource gebeurt via Azure Portal onder resource, Diagnostische instellingen, Diagnostische instelling toevoegen waarbij alle relevante logboekcategorieën worden geselecteerd die beschikbaar zijn voor dat specifieke resourcetype. De bestemming moet worden ingesteld op Log Analytics-werkruimte voor real-time query's en waarschuwingen, waardoor organisaties direct kunnen reageren op beveiligingsgebeurtenissen en operationele problemen zodra ze worden gedetecteerd. Optioneel kan er ook een opslagaccount worden toegevoegd voor kosteneffectieve langetermijnarchivering met een bewaartermijn van zeven jaar voor nalevingsdoeleinden. De implementatie vereist typisch 10 tot 15 uur voor initiële implementatie over alle resources in een gemiddelde omgeving, afhankelijk van het aantal resources en de gekozen implementatiemethode. De kosten variëren afhankelijk van het logboekvolume, waarbij typisch twee tot tien euro per resource per maand wordt gerekend voor het verzamelen en opslaan van logboeken. Voor grote omgevingen met honderden of duizenden resources kunnen de totale kosten oplopen tot enkele duizenden euro's per maand, wat een aanzienlijke impact kan hebben op het IT-budget van organisaties. Deze investering is echter absoluut noodzakelijk voor beveiligingsbewaking en naleving, en biedt essentiële zichtbaarheid die organisaties in staat stelt om beveiligingsincidenten te detecteren, te onderzoeken en te voorkomen. Deze maatregel voldoet aan CIS Azure Benchmark uitgebreide loggingvereisten, BIO 12.04.01, ISO 27001 A.12.4.1, NIST AU-2 en NIS2 Artikel 21.

Vereisten

Voordat diagnostische instellingen kunnen worden geconfigureerd op Azure-resources, moeten organisaties verschillende voorbereidende stappen ondernemen om ervoor te zorgen dat de implementatie succesvol verloopt en alle benodigde componenten beschikbaar zijn. Deze voorbereiding is essentieel omdat een onvolledige of incorrecte implementatie kan leiden tot gaten in de loggingconfiguratie die beveiligingsrisico's en nalevingsproblemen veroorzaken. Een grondige voorbereiding voorkomt dat organisaties later moeten terugkeren om ontbrekende configuraties toe te voegen of incorrecte instellingen te corrigeren, wat tijdrovend en kostbaar kan zijn. De belangrijkste vereiste voor het implementeren van diagnostische instellingen is een actief Azure-abonnement met voldoende rechten om resources te configureren en beheerdersrollen toe te wijzen. Zonder de juiste machtigingen is het niet mogelijk om diagnostische instellingen te maken of te wijzigen, wat kan leiden tot onvolledige loggingconfiguratie en beveiligingsrisico's die organisaties kwetsbaar maken voor aanvallen en niet-naleving van compliancestandaarden. Organisaties moeten ervoor zorgen dat de gebruikers of service principals die betrokken zijn bij de implementatie beschikken over de benodigde Azure RBAC-rollen zoals Inzender of Eigenaar op het niveau waar de diagnostische instellingen moeten worden geconfigureerd. Deze rollen zijn essentieel omdat diagnostische instellingen resourceconfiguraties zijn die specifieke machtigingen vereisen om te kunnen worden aangemaakt of gewijzigd. Daarnaast moet er een Log Analytics-werkruimte worden aangemaakt waar alle logboeken naartoe worden gestuurd voor centrale analyse en monitoring. Deze werkruimte fungeert als het centrale punt waar alle diagnostische gegevens worden verzameld, waardoor organisaties een uniforme manier hebben om logboeken te bekijken, te analyseren en te doorzoeken. De Log Analytics-werkruimte moet worden geconfigureerd met de juiste retentie-instellingen die voldoen aan de nalevingsvereisten van de organisatie, waarbij vaak een bewaartermijn van minimaal zeven jaar wordt aangehouden voor audit- en nalevingsdoeleinden. Deze lange bewaartermijn is essentieel omdat veel compliancestandaarden vereisen dat logboeken worden bewaard voor een bepaalde periode om te kunnen worden gebruikt tijdens audits en nalevingscontroles. Voor grotere omgevingen met honderden of duizenden resources is het sterk aan te bevelen om Azure Policy te gebruiken voor automatische implementatie van diagnostische instellingen. Deze aanpak schaalt veel beter dan handmatige configuratie en zorgt ervoor dat nieuwe resources automatisch worden voorzien van de juiste loggingconfiguratie zodra ze worden aangemaakt, waardoor de kans op menselijke fouten wordt geminimaliseerd en de consistentie van de configuratie wordt gegarandeerd. Bij het opzetten van Azure Policy moet de ingebouwde initiatief 'Schakel logging in voor Azure-resources' worden toegewezen aan het juiste beheersbereik, zoals een management group voor organisatiebrede implementatie, een abonnement voor gefaseerde implementatie, of een resourcegroep voor specifieke omgevingen. Dit zorgt ervoor dat alle nieuwe resources binnen dat bereik automatisch worden geconfigureerd met diagnostische instellingen, waardoor de kans op vergeten resources of inconsistente configuraties aanzienlijk wordt verminderd. Organisaties moeten ook nadenken over de configuratie van de beleidsparameters, zoals het specificeren van de Log Analytics-werkruimte waar de logboeken naartoe moeten worden gestuurd, en het bepalen welke logboekcategorieën moeten worden ingeschakeld voor elk resourcetype. Deze parameters zijn cruciaal omdat incorrecte configuratie kan leiden tot logboeken die naar de verkeerde bestemming worden gestuurd of logboekcategorieën die niet worden ingeschakeld, wat resulteert in onvolledige loggingconfiguratie. Naast deze technische vereisten moeten organisaties ook nadenken over de kosten die gepaard gaan met het verzamelen en opslaan van logboeken. Afhankelijk van het aantal resources en het volume aan gegenereerde logboeken kunnen de kosten variëren van enkele honderden tot duizenden euro's per maand, wat een aanzienlijke impact kan hebben op het IT-budget van organisaties. Het is daarom belangrijk om een kostenraming te maken voordat de implementatie wordt gestart en om te beslissen welke logboekcategorieën werkelijk nodig zijn voor elk resourcetype. Sommige logboekcategorieën genereren aanzienlijk meer gegevens dan andere, en organisaties moeten een balans vinden tussen de gewenste zichtbaarheid en de daarmee gepaard gaande kosten. Organisaties kunnen bijvoorbeeld besluiten om voor niet-kritieke resources alleen essentiële logboekcategorieën in te schakelen, terwijl voor kritieke resources alle beschikbare logboekcategorieën worden ingeschakeld om maximale zichtbaarheid te garanderen. Ten slotte moeten organisaties ervoor zorgen dat het personeel dat betrokken is bij de implementatie voldoende kennis heeft van Azure Monitor, Log Analytics en diagnostische instellingen om fouten te voorkomen en de juiste configuratie te garanderen. Dit kan worden bereikt door training te verzorgen voor de betrokken teamleden, door documentatie te raadplegen, of door externe expertise in te schakelen wanneer de interne kennis onvoldoende is. Een goed voorbereide implementatie met voldoende kennis en de juiste technische componenten is essentieel voor het succesvol configureren van diagnostische instellingen op alle Azure-resources en voorkomt dat organisaties later moeten terugkeren om problemen op te lossen die hadden kunnen worden voorkomen met een grondige voorbereiding.

Implementatie

Gebruik PowerShell-script diagnostic-settings-all-resources.ps1 (functie Invoke-Implementation) – Implementeren.

De implementatie van diagnostische instellingen op alle Azure-resources kan op verschillende manieren worden uitgevoerd, waarbij organisaties moeten kiezen tussen geautomatiseerde en handmatige aanpakken afhankelijk van hun specifieke behoeften, omgevingsgrootte en beschikbare resources. De keuze tussen deze aanpakken heeft aanzienlijke gevolgen voor de implementatiesnelheid, consistentie en onderhoudbaarheid van de loggingconfiguratie. Voor organisaties met meer dan enkele tientallen resources is de Azure Policy-aanpak sterk aan te bevelen, omdat deze schaalbaar is en zorgt voor consistente configuratie over alle resources heen, waardoor de kans op menselijke fouten wordt geminimaliseerd en de configuratie consistent blijft naarmate de omgeving groeit. Bij het gebruik van Azure Policy moet de ingebouwde initiatief 'Schakel logging in voor Azure-resources' worden toegewezen aan het juiste beheersbereik, zoals een management group voor organisatiebrede implementatie of een specifiek abonnement voor gefaseerde implementatie. Deze initiatief bevat meerdere beleidsregels die automatisch diagnostische instellingen toevoegen aan verschillende resourcetypen zodra ze worden aangemaakt, waardoor nieuwe resources direct worden voorzien van de juiste loggingconfiguratie zonder handmatige interventie. Het voordeel van deze aanpak is dat nieuwe resources automatisch worden geconfigureerd zonder handmatige interventie, wat de kans op vergeten resources of inconsistente configuraties aanzienlijk vermindert en ervoor zorgt dat de loggingconfiguratie consistent blijft naarmate de omgeving evolueert. De toewijzing van het beleid gebeurt via de Azure Portal door te navigeren naar Beleid, het initiatief te zoeken en het toe te wijzen aan het gewenste bereik met de juiste parameters, zoals de Log Analytics-werkruimte waar de logboeken naartoe moeten worden gestuurd. Organisaties moeten zorgvuldig nadenken over de configuratie van deze parameters, omdat incorrecte configuratie kan leiden tot logboeken die naar de verkeerde bestemming worden gestuurd of logboekcategorieën die niet worden ingeschakeld, wat resulteert in onvolledige loggingconfiguratie. Voor bestaande resources die al zijn aangemaakt voordat het beleid is toegewezen, moet een hersteltaak worden uitgevoerd om de diagnostische instellingen alsnog toe te voegen. Dit kan via de Azure Portal door naar de beleidstoewijzing te gaan en de optie 'Hersteltaak maken' te selecteren, waarna Azure automatisch de diagnostische instellingen toevoegt aan alle bestaande resources die voldoen aan de beleidsregels. Het is belangrijk om te begrijpen dat hersteltaken enige tijd kunnen duren, afhankelijk van het aantal resources dat moet worden geconfigureerd, en dat organisaties moeten controleren of de hersteltaak succesvol is voltooid voordat zij ervan uitgaan dat alle resources correct zijn geconfigureerd. Handmatige configuratie per resource gebeurt via de Azure Portal door naar de specifieke resource te navigeren, onder Monitoring de optie 'Diagnostische instellingen' te selecteren en vervolgens 'Diagnostische instelling toevoegen' te kiezen. In het configuratiescherm moeten alle relevante logboekcategorieën worden geselecteerd die beschikbaar zijn voor dat specifieke resourcetype, waarbij organisaties moeten begrijpen welke logboekcategorieën beschikbaar zijn voor elk resourcetype en welke categorieën essentieel zijn voor hun specifieke beveiligings- en operationele behoeften. Voor virtuele machines kunnen dit bijvoorbeeld opstartdiagnostiek zijn die informatie bevat over het opstartproces en eventuele fouten die optreden tijdens het opstarten, prestatiemeters die inzicht geven in het resourcegebruik en de prestaties van de virtuele machine, en systeemlogboeken die informatie bevatten over het besturingssysteem en de applicaties die op de virtuele machine draaien. Voor Key Vaults zijn dit toegangslogboeken voor geheimen, sleutels en certificaten die cruciaal zijn voor het monitoren van wie toegang heeft gehad tot gevoelige credentials en voor het detecteren van potentiële beveiligingsincidenten. De bestemming moet worden ingesteld op de Log Analytics-werkruimte voor real-time query's en waarschuwingen, waardoor organisaties direct kunnen reageren op beveiligingsgebeurtenissen en operationele problemen zodra ze worden gedetecteerd. Optioneel kan er ook een opslagaccount worden toegevoegd voor kosteneffectieve langetermijnarchivering, wat vooral belangrijk is voor nalevingsdoeleinden waarbij organisaties moeten kunnen aantonen dat zij logboeken hebben bewaard voor de vereiste bewaartermijn. Voor nalevingsdoeleinden wordt vaak een bewaartermijn van zeven jaar aangehouden, wat kan worden geconfigureerd in de levenscyclusbeheerinstellingen van het opslagaccount, waarbij organisaties moeten zorgen dat de opslagaccountconfiguratie correct is ingesteld om te voorkomen dat logboeken per ongeluk worden verwijderd voordat de bewaartermijn is verstreken. Na het configureren van de diagnostische instellingen begint Azure onmiddellijk met het verzamelen en verzenden van logboeken naar de opgegeven bestemmingen, hoewel het enige minuten tot enkele uren kan duren voordat de eerste logboeken zichtbaar zijn in de Log Analytics-werkruimte, afhankelijk van het resourcetype en de hoeveelheid gegenereerde gegevens. Organisaties moeten regelmatig controleren of de diagnostische instellingen correct functioneren door query's uit te voeren op de Log Analytics-werkruimte om te verifiëren dat logboeken worden ontvangen van alle geconfigureerde resources, waarbij het belangrijk is om te begrijpen dat het ontbreken van logboeken kan wijzen op een probleem met de configuratie of met het verzenden van logboeken. De implementatie vereist typisch 10 tot 15 uur voor initiële implementatie over alle resources in een gemiddelde omgeving, afhankelijk van het aantal resources en de gekozen implementatiemethode, waarbij de Azure Policy-aanpak aanzienlijk sneller is dan handmatige configuratie omdat het proces grotendeels geautomatiseerd is. Voor grote omgevingen met duizenden resources kan dit aanzienlijk langer duren, maar de Azure Policy-aanpak kan dit proces aanzienlijk versnellen en automatiseren, waardoor organisaties tijd besparen en de consistentie van de configuratie kunnen garanderen.

Compliance

Het implementeren van diagnostische instellingen op alle Azure-resources vormt een fundamentele vereiste voor naleving van verschillende beveiligings- en compliancestandaarden die van toepassing zijn op Nederlandse overheidsorganisaties. Deze standaarden vereisen uitgebreide logging en monitoring om te kunnen aantonen dat organisaties voldoen aan de vereisten voor informatiebeveiliging, gegevensbescherming en cybersecurity. Zonder diagnostische instellingen is het vrijwel onmogelijk om aan deze vereisten te voldoen, wat kan leiden tot ernstige nalevingsproblemen en mogelijke sancties tijdens audits. De BIO-norm, voluit Baseline Informatiebeveiliging Overheid, vormt de basis voor informatiebeveiliging binnen de Nederlandse overheid en vereist in controle 12.04.01 dat organisaties logging en monitoring implementeren van alle relevante systemen en services. Specifiek voor Azure-resources betekent dit dat alle data plane-operaties moeten worden gelogd via diagnostische instellingen, omdat het Activiteitenlogboek alleen control plane-operaties vastlegt en niet voldoet aan de vereisten voor uitgebreide logging die door de BIO-norm worden geëist. Het Activiteitenlogboek registreert uitsluitend beheeracties zoals het aanmaken, wijzigen of verwijderen van resources, maar biedt geen inzicht in wat er daadwerkelijk gebeurt binnen resources tijdens normale werking. Deze fundamentele beperking maakt het onmogelijk om te voldoen aan de BIO-vereisten zonder diagnostische instellingen, omdat organisaties dan niet kunnen aantonen dat zij alle relevante activiteiten monitoren en vastleggen. Zonder diagnostische instellingen voldoen organisaties niet aan deze BIO-vereiste, wat kan leiden tot bevindingen tijdens audits en mogelijke sancties, waarbij auditors kunnen concluderen dat organisaties niet voldoen aan de basisvereisten voor informatiebeveiliging. De ISO 27001-norm is een internationaal erkende standaard voor informatiebeveiligingsmanagement en vereist in controle A.12.4.1 dat organisaties gebeurtenisregistratie implementeren voor alle beveiligingsrelevante gebeurtenissen. Dit omvat authenticatiepogingen die kunnen wijzen op brute force-aanvallen of pogingen tot ongeautoriseerde toegang, autorisatiebeslissingen die tonen wie toegang heeft gekregen tot welke resources, toegang tot gevoelige gegevens die cruciaal is voor het detecteren van datalekken, en configuratiewijzigingen die kunnen wijzen op ongeautoriseerde wijzigingen aan de beveiligingsconfiguratie. Al deze gebeurtenissen worden vastgelegd door diagnostische instellingen op Azure-resources, waardoor organisaties kunnen aantonen dat zij voldoen aan de ISO 27001-vereisten voor gebeurtenisregistratie. Organisaties die gecertificeerd willen worden of blijven voor ISO 27001 moeten kunnen aantonen dat zij uitgebreide logging hebben geïmplementeerd op alle relevante systemen, waaronder Azure-resources, en zonder diagnostische instellingen is het niet mogelijk om deze certificering te behalen of te behouden. Tijdens ISO 27001-audits zullen auditors specifiek controleren of organisaties gebeurtenisregistratie hebben geïmplementeerd voor alle beveiligingsrelevante gebeurtenissen, en het ontbreken van diagnostische instellingen zal automatisch leiden tot een bevinding die moet worden opgelost voordat certificering kan worden verkregen of behouden. De CIS Azure Benchmark is een internationaal erkende standaard voor Azure-beveiliging die wordt ontwikkeld door het Center for Internet Security en vereist expliciet dat diagnostische instellingen worden ingeschakeld op alle ondersteunde Azure-resources. Deze benchmark wordt vaak gebruikt door auditors en beveiligingsprofessionals om de beveiligingsstatus van Azure-omgevingen te beoordelen, en het ontbreken van diagnostische instellingen leidt automatisch tot een bevinding die moet worden opgelost voordat organisaties kunnen voldoen aan de benchmarkvereisten. De CIS Azure Benchmark bevat specifieke controles die vereisen dat diagnostische instellingen worden geconfigureerd voor verschillende resourcetypen, en organisaties die deze benchmark willen volgen moeten kunnen aantonen dat alle vereiste diagnostische instellingen correct zijn geconfigureerd. De NIST Cybersecurity Framework is een vrijwillige richtlijn die wordt gebruikt door organisaties wereldwijd om hun cybersecurity-postuur te verbeteren en vereist in controle AU-2, wat staat voor Audit Events, dat organisaties de gebeurtenissen vaststellen die moeten worden geaudit en dat deze gebeurtenissen worden vastgelegd in auditlogboeken. Voor Azure-resources betekent dit dat alle beveiligingsrelevante gebeurtenissen moeten worden vastgelegd via diagnostische instellingen, waarbij de logboeken moeten worden opgeslagen op een veilige locatie met voldoende bewaartermijn voor nalevingsdoeleinden, zodat organisaties kunnen aantonen dat zij voldoen aan de NIST-vereisten voor auditlogging. Het NIST Framework vereist dat organisaties een duidelijk proces hebben voor het identificeren van welke gebeurtenissen moeten worden geaudit, en diagnostische instellingen bieden de technische implementatie om deze gebeurtenissen daadwerkelijk vast te leggen. De NIS2-richtlijn, voluit Directive on measures for a high common level of cybersecurity across the Union, is een Europese richtlijn die vereist dat essentiële en belangrijke entiteiten maatregelen nemen om hun cybersecurity-postuur te verbeteren, en vereist in Artikel 21 dat deze entiteiten logging implementeren voor de detectie van beveiligingsincidenten. Nederlandse overheidsorganisaties die vallen onder de NIS2-richtlijn moeten kunnen aantonen dat zij uitgebreide logging hebben geïmplementeerd op alle kritieke systemen, waaronder Azure-resources, en zonder diagnostische instellingen is het vrijwel onmogelijk om beveiligingsincidenten tijdig te detecteren en te onderzoeken, wat kan leiden tot niet-naleving van de NIS2-vereisten en mogelijke boetes of andere sancties. De NIS2-richtlijn verplicht organisaties om logging te hebben die hen in staat stelt beveiligingsincidenten te detecteren, te onderzoeken en te rapporteren, en diagnostische instellingen vormen de technische basis om aan deze verplichting te voldoen. Naast deze specifieke standaarden vereisen veel andere compliancestandaarden en regelgevingen, zoals de AVG, voluit Algemene Verordening Gegevensbescherming, uitgebreide logging voor audit- en nalevingsdoeleinden, waarbij organisaties moeten kunnen aantonen dat zij logboeken hebben bewaard die relevant zijn voor gegevensbescherming en privacy. De AVG vereist dat organisaties kunnen aantonen dat zij passende technische en organisatorische maatregelen hebben genomen om persoonsgegevens te beschermen, en uitgebreide logging vormt een essentieel onderdeel van deze maatregelen. Het is daarom van cruciaal belang dat organisaties diagnostische instellingen implementeren op alle Azure-resources om te voldoen aan deze vereisten en om bewijsmateriaal te kunnen leveren tijdens audits en nalevingscontroles, waarbij het belangrijk is om te begrijpen dat het ontbreken van deze logboeken kan leiden tot bevindingen tijdens audits en mogelijke sancties. De bewaartermijn van logboeken moet minimaal zeven jaar zijn voor nalevingsdoeleinden, wat kan worden geconfigureerd via levenscyclusbeheerinstellingen in Azure Storage voor langetermijnarchivering van diagnostische gegevens, waarbij organisaties moeten zorgen dat de opslagaccountconfiguratie correct is ingesteld om te voorkomen dat logboeken per ongeluk worden verwijderd voordat de bewaartermijn is verstreken. Deze lange bewaartermijn is essentieel omdat veel compliancestandaarden vereisen dat logboeken worden bewaard voor een bepaalde periode om te kunnen worden gebruikt tijdens audits en nalevingscontroles, en het verwijderen van logboeken voordat de bewaartermijn is verstreken kan leiden tot nalevingsproblemen en mogelijke sancties.

Monitoring

Gebruik PowerShell-script diagnostic-settings-all-resources.ps1 (functie Invoke-Monitoring) – Controleren.

Het monitoren van diagnostische instellingen op Azure-resources is essentieel om ervoor te zorgen dat alle resources correct zijn geconfigureerd en dat logboeken daadwerkelijk worden verzameld en verzonden naar de opgegeven bestemmingen. Zonder regelmatige monitoring kunnen organisaties niet zeker zijn van de volledigheid van hun loggingconfiguratie, wat kan leiden tot beveiligingsrisico's en nalevingsproblemen die kunnen resulteren in beveiligingsincidenten die niet worden gedetecteerd of in bevindingen tijdens audits die kunnen leiden tot sancties. Het monitoren van diagnostische instellingen omvat verschillende aspecten die allemaal belangrijk zijn voor het waarborgen van een effectieve loggingconfiguratie. Het controleren of alle resources diagnostische instellingen hebben geconfigureerd is de eerste stap in het monitoren van diagnostische instellingen, omdat organisaties moeten weten welke resources wel en welke niet zijn geconfigureerd voordat zij kunnen bepalen of er actie moet worden ondernomen. Het verifiëren dat logboeken daadwerkelijk worden ontvangen in de Log Analytics-werkruimte is cruciaal omdat het hebben van diagnostische instellingen niet voldoende is als de logboeken niet daadwerkelijk worden verzameld en verzonden, wat kan wijzen op een probleem met de configuratie of met het verzenden van logboeken. Het monitoren van de status van diagnostische instellingen om fouten of problemen te detecteren is belangrijk omdat diagnostische instellingen kunnen worden verwijderd, gewijzigd of kunnen falen zonder dat organisaties dit direct opmerken, wat kan leiden tot gaten in de loggingconfiguratie. Het bewaken van de kosten die gepaard gaan met het verzamelen en opslaan van logboeken is ook belangrijk omdat deze kosten kunnen oplopen voor grote omgevingen met veel resources, en organisaties moeten een balans vinden tussen de gewenste zichtbaarheid en de daarmee gepaard gaande kosten. Voor het controleren van de configuratie van diagnostische instellingen kunnen organisaties gebruikmaken van Azure Policy compliance-rapportages, die aangeven welke resources voldoen aan de beleidsregels en welke niet. Deze rapportages kunnen worden bekeken in de Azure Portal door naar Beleid te navigeren, de betreffende beleidstoewijzing te selecteren en de compliance-rapportage te bekijken, waarbij organisaties kunnen zien welke resources compliant zijn en welke niet, en waarom bepaalde resources niet compliant zijn. Resources die niet voldoen aan het beleid worden gemarkeerd als niet-compliant, en er kan een hersteltaak worden uitgevoerd om deze resources alsnog te configureren, waarbij het belangrijk is om te begrijpen dat niet-compliant resources een beveiligingsrisico vormen omdat zij niet de vereiste loggingconfiguratie hebben. Naast Azure Policy-compliance-rapportages kunnen organisaties ook gebruikmaken van PowerShell-scripts of Azure Resource Graph-query's om alle resources te doorzoeken die geen diagnostische instellingen hebben geconfigureerd. Deze aanpak is met name handig voor bestaande omgevingen waar Azure Policy nog niet is geïmplementeerd of voor resources die om technische redenen niet door het beleid worden gedekt, waarbij organisaties regelmatig deze scripts of query's moeten uitvoeren om te verifiëren dat alle resources correct zijn geconfigureerd. Voor het verifiëren dat logboeken daadwerkelijk worden ontvangen in de Log Analytics-werkruimte kunnen organisaties gebruikmaken van KQL-query's (Kusto Query Language) om te controleren of er recente logboeken zijn ontvangen van specifieke resources. Een eenvoudige query kan bijvoorbeeld controleren of er in de afgelopen 24 uur logboeken zijn ontvangen van een specifieke resource, en als dat niet het geval is, kan dit wijzen op een probleem met de diagnostische instelling of met het verzenden van logboeken, waarbij organisaties moeten onderzoeken waarom er geen logboeken worden ontvangen en actie moeten ondernemen om het probleem op te lossen. Voor het monitoren van de status van diagnostische instellingen kunnen organisaties gebruikmaken van Azure Monitor-waarschuwingen die worden geactiveerd wanneer een diagnostische instelling wordt verwijderd, gewijzigd of wanneer er geen logboeken meer worden ontvangen van een resource. Deze waarschuwingen kunnen worden geconfigureerd via Azure Monitor en kunnen automatisch acties ondernemen, zoals het versturen van e-mails naar beheerders of het uitvoeren van automatische herstelacties, waardoor organisaties direct kunnen reageren op problemen met diagnostische instellingen voordat deze leiden tot beveiligingsrisico's of nalevingsproblemen. Het bewaken van de kosten die gepaard gaan met het verzamelen en opslaan van logboeken is ook belangrijk, omdat deze kosten kunnen oplopen voor grote omgevingen met veel resources, en organisaties moeten regelmatig de kosten controleren via Azure Cost Management en eventueel aanpassingen maken aan de loggingconfiguratie om de kosten te beheersen. Organisaties kunnen bijvoorbeeld bepaalde logboekcategorieën uitschakelen die niet essentieel zijn voor hun specifieke beveiligings- en operationele behoeften, of de bewaartermijn van logboeken verkorten voor niet-kritieke resources, waarbij het belangrijk is om een balans te vinden tussen kostenbeheersing en de gewenste zichtbaarheid. Naast deze technische monitoringaspecten moeten organisaties ook procedures implementeren voor het regelmatig controleren en onderhouden van diagnostische instellingen, bijvoorbeeld door maandelijks een review uit te voeren van alle resources om te verifiëren dat ze nog steeds correct zijn geconfigureerd en dat er geen wijzigingen zijn aangebracht die de loggingconfiguratie hebben beïnvloed. Deze reviews moeten worden gedocumenteerd en moeten worden uitgevoerd door bevoegde personen die voldoende kennis hebben van Azure Monitor en diagnostische instellingen om problemen te kunnen identificeren en op te lossen.

Remediatie

Gebruik PowerShell-script diagnostic-settings-all-resources.ps1 (functie Invoke-Remediation) – Herstellen.

Wanneer diagnostische instellingen ontbreken op Azure-resources of wanneer bestaande diagnostische instellingen niet correct zijn geconfigureerd, moeten organisaties deze problemen zo snel mogelijk oplossen om beveiligingsrisico's en nalevingsproblemen te voorkomen. Het ontbreken van diagnostische instellingen creëert kritieke gaten in de loggingconfiguratie die organisaties kwetsbaar maken voor beveiligingsincidenten die niet worden gedetecteerd en voor bevindingen tijdens audits die kunnen leiden tot sancties. Het herstelproces begint met het identificeren van alle resources die geen diagnostische instellingen hebben of waarvan de diagnostische instellingen niet correct zijn geconfigureerd, waarbij organisaties systematisch moeten doorzoeken welke resources aandacht vereisen voordat zij kunnen beginnen met het oplossen van de problemen. Dit kan worden gedaan via Azure Policy-compliance-rapportages die aangeven welke resources niet voldoen aan de beleidsregels, Azure Resource Graph-query's die alle resources doorzoeken en controleren op de aanwezigheid en configuratie van diagnostische instellingen, of PowerShell-scripts die geautomatiseerd alle resources controleren en rapporteren welke resources herstel vereisen. Zodra de resources zijn geïdentificeerd die herstel vereisen, kunnen organisaties verschillende methoden gebruiken om de diagnostische instellingen toe te voegen of te corrigeren, waarbij de keuze van de methode afhangt van het aantal resources dat herstel vereist, de beschikbare automatiseringstools, en de specifieke behoeften van de organisatie. Voor organisaties die Azure Policy gebruiken voor automatische implementatie van diagnostische instellingen, is de eenvoudigste manier om herstel uit te voeren door een hersteltaak te maken via de Azure Portal. Deze hersteltaak wordt automatisch uitgevoerd door Azure en voegt diagnostische instellingen toe aan alle bestaande resources die voldoen aan de beleidsregels maar nog geen diagnostische instellingen hebben geconfigureerd, waarbij het proces volledig geautomatiseerd is en organisaties niet handmatig elke resource hoeven te configureren. Het voordeel van deze aanpak is dat het proces volledig automatisch is en dat organisaties niet handmatig elke resource hoeven te configureren, wat tijd bespaart en de kans op fouten vermindert, terwijl het ook zorgt voor consistente configuratie over alle resources heen. Voor resources die niet door Azure Policy worden gedekt of voor organisaties die nog geen Azure Policy hebben geïmplementeerd, kan handmatige remediatie worden uitgevoerd via de Azure Portal, PowerShell-scripts of Azure CLI, waarbij organisaties moeten kiezen welke methode het beste past bij hun specifieke situatie. Bij handmatige remediatie via de Azure Portal moeten beheerders naar elke resource navigeren, de diagnostische instellingen configureren en alle relevante logboekcategorieën selecteren en de bestemming instellen op de Log Analytics-werkruimte, waarbij het belangrijk is om te begrijpen welke logboekcategorieën beschikbaar zijn voor elk resourcetype en welke categorieën essentieel zijn voor de beveiligings- en operationele behoeften van de organisatie. Dit proces kan tijdrovend zijn voor omgevingen met veel resources, maar het geeft beheerders volledige controle over de configuratie en het maakt het mogelijk om specifieke instellingen te gebruiken voor verschillende resources, waarbij organisaties kunnen beslissen welke logboekcategorieën moeten worden ingeschakeld voor elk resourcetype op basis van hun specifieke behoeften. Voor grootschalige hersteloperaties kunnen organisaties ook gebruikmaken van PowerShell-scripts of Azure CLI-opdrachten om diagnostische instellingen toe te voegen aan meerdere resources tegelijk, waarbij deze scripts kunnen worden aangepast aan de specifieke behoeften van de organisatie en automatisch de juiste logboekcategorieën kunnen selecteren op basis van het resourcetype. Deze scripts kunnen worden uitgevoerd op regelmatige basis om te verifiëren dat alle resources correct zijn geconfigureerd en om automatisch diagnostische instellingen toe te voegen aan resources die deze nog niet hebben, waardoor organisaties kunnen zorgen voor consistente configuratie zonder handmatige interventie. Bij het uitvoeren van hersteloperaties is het belangrijk om te verifiëren dat de diagnostische instellingen correct zijn geconfigureerd en dat logboeken daadwerkelijk worden ontvangen in de Log Analytics-werkruimte, omdat het hebben van diagnostische instellingen niet voldoende is als de logboeken niet daadwerkelijk worden verzameld en verzonden. Dit kan worden gedaan door na het toevoegen van de diagnostische instellingen te wachten enige tijd en vervolgens een KQL-query uit te voeren om te controleren of er recente logboeken zijn ontvangen van de betreffende resources, waarbij organisaties moeten begrijpen dat het enige tijd kan duren voordat de eerste logboeken zichtbaar zijn in de Log Analytics-werkruimte. Als er na enige tijd nog steeds geen logboeken worden ontvangen, kan dit wijzen op een probleem met de configuratie of met het verzenden van logboeken, en moeten aanvullende troubleshootingsstappen worden ondernomen om te identificeren waarom de logboeken niet worden ontvangen en om het probleem op te lossen. Na het uitvoeren van hersteloperaties moeten organisaties ook procedures implementeren om te voorkomen dat dezelfde problemen in de toekomst optreden, waarbij preventieve maatregelen essentieel zijn om te zorgen dat de loggingconfiguratie consistent blijft en dat alle resources blijven voldoen aan beveiligings- en nalevingsvereisten. Dit kan worden gedaan door Azure Policy te implementeren voor automatische implementatie van diagnostische instellingen op nieuwe resources, waardoor nieuwe resources automatisch worden geconfigureerd zodra ze worden aangemaakt en de kans op vergeten resources wordt geminimaliseerd. Organisaties kunnen ook regelmatige compliance-controles uitvoeren om vroegtijdig resources te detecteren die geen diagnostische instellingen hebben, waarbij deze controles kunnen worden geautomatiseerd met scripts of query's die regelmatig worden uitgevoerd om te verifiëren dat alle resources correct zijn geconfigureerd. Daarnaast kunnen organisaties waarschuwingen configureren die worden geactiveerd wanneer een diagnostische instelling wordt verwijderd of gewijzigd, waardoor organisaties direct kunnen reageren op wijzigingen die de loggingconfiguratie kunnen beïnvloeden. Door deze preventieve maatregelen te implementeren, kunnen organisaties ervoor zorgen dat hun loggingconfiguratie consistent blijft en dat alle resources blijven voldoen aan beveiligings- en nalevingsvereisten, waardoor het risico op beveiligingsincidenten en nalevingsproblemen wordt geminimaliseerd.

Compliance & Frameworks

• CIS M365: Control Azure - Diagnostische instellingen (L1) -
• BIO: 12.04.01 - Logging en monitoring
• ISO 27001:2022: A.12.4.1 - gebeurtenisregistratie
• NIS2: Artikel - beveiligingsincident 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 instellingen op alle resources: Schakel diagnostische instellingen in op alle Azure-resources inclusief virtuele machines, SQL-databases, opslagaccounts, Key Vaults, netwerkbeveiligingsgroepen en andere kritieke services. Stuur alle logboeken naar Log Analytics voor centrale analyse en monitoring. Logging op gegevensvlak is essentieel voor beveiligingszichtbaarheid. Gebruik Azure Policy voor geautomatiseerde implementatie op schaal. Geschatte kosten: 200 tot 1000 euro per maand afhankelijk van omvang. Verplicht volgens CIS Azure Benchmark, BIO 12.04.01 en ISO 27001 A.12.4.1. Implementatietijd: 10 tot 15 uur voor een gemiddelde omgeving. Basisvoorwaarde voor effectieve beveiligingszichtbaarheid.

• Implementatietijd: 15 uur
• FTE required: 0.1 FTE