Azure Monitor Alerts: Architectuur, Typen En Best Practices Voor Proactieve Monitoring

Zonder een volwassen alertingstrategie blijven organisaties afhankelijk van handmatige inspectie van logbestanden en dashboards, waardoor kritieke gebeurtenissen pas worden opgemerkt wanneer gebruikers klagen of wanneer audits afwijkingen aan het licht brengen. Onderzoek naar recente beveiligingsincidenten binnen Nederlandse overheidsorganisaties toont aan dat de gemiddelde detectietijd voor datalekken, ongeautoriseerde toegang en service-uitval oploopt tot dagen of weken wanneer er geen geautomatiseerde waarschuwingsmechanismen zijn ingericht. Dit leidt niet alleen tot verhoogde schade en reputatierisico's, maar ook tot aantoonbare non-compliance met kaders zoals BIO 12.04, ISO 27001 A.12.4.1 en AVG Artikel 32, die allemaal vereisen dat beveiligingsincidenten tijdig worden gedetecteerd en aangepakt. Bovendien worden operationele teams overspoeld door ruwe telemetrie zonder prioritering, waardoor echte bedreigingen verdrinken tussen routinegebeurtenissen en false positives de aandacht afleiden van kritieke signalen. Door een doordachte set alertregels te implementeren met duidelijke severities, escalatiepaden en geautomatiseerde notificaties, verandert dezelfde datastroom in een proactief waarschuwingssysteem dat teams in staat stelt om binnen minuten te reageren in plaats van uren of dagen.

Implementatie

Dit artikel beschrijft de architectuur, typen en best practices voor Azure Monitor Alerts binnen de context van de Nederlandse Baseline voor Veilige Cloud. We behandelen de verschillende alerttypen die beschikbaar zijn: metrische alerts op basis van platformmetrieken, loggebaseerde alerts die gebruikmaken van Kusto-query's in Log Analytics, Activity Log-alerts voor beheeractiviteiten en Application Insights-alerts voor applicatieprestaties. Daarnaast leggen we uit hoe Action Groups worden geconfigureerd voor multi-channel notificaties via e-mail, SMS, Teams, webhooks en geautomatiseerde runbooks. We bespreken de rol van Alert Processing Rules voor het beheren van alarmmoeheid, het toepassen van actiegroepen en het onderdrukken van redundante meldingen. Tot slot behandelen we hoe alerts worden geïntegreerd met Azure Policy voor consistente uitrol, hoe compliance wordt geborgd via periodieke controles en hoe de effectiviteit van alertregels wordt gemeten en geoptimaliseerd op basis van false positive-ratio's en responstijden.

Architectuur en Typen van Azure Monitor Alerts

Azure Monitor Alerts zijn gebouwd op een gelaagde architectuur waarin signalen uit verschillende bronnen worden verzameld, geëvalueerd tegen vooraf gedefinieerde voorwaarden en omgezet in acties via Action Groups. De basislaag bestaat uit telemetriebronnen zoals Azure Resource Metrics, Log Analytics-workspaces, Activity Logs en Application Insights, die continu gegevens genereren over de status, prestaties en beveiliging van cloudresources. Deze gegevens worden opgeslagen in Azure Monitor Metrics Store voor platformmetrieken en in Log Analytics-tabellen voor gestructureerde loggegevens. De evaluatielaag bestaat uit alertregels die periodiek of in real-time controleren of signalen voldoen aan specifieke voorwaarden, zoals drempelwaarden voor CPU-gebruik, queryresultaten die afwijkingen detecteren of Activity Log-gebeurtenissen die wijzen op beveiligingsrisico's. Wanneer een voorwaarde wordt geactiveerd, genereert Azure Monitor een alert die wordt doorgestuurd naar de actielaag, bestaande uit Action Groups die notificaties versturen, webhooks activeren of geautomatiseerde runbooks starten. De eerste categorie alerts zijn metrische alerts, die werken op basis van platformmetrieken zoals CPU-percentage, geheugengebruik, netwerkdoorvoer en beschikbaarheid. Deze alerts zijn ideaal voor het monitoren van resourceprestaties en capaciteitsplanning, omdat ze zeer snel evalueren (elke minuut) en lage kosten met zich meebrengen. Metrische alerts ondersteunen zowel statische drempelwaarden (bijvoorbeeld 'CPU > 80%') als dynamische drempelwaarden die gebruikmaken van machine learning om afwijkingen te detecteren op basis van historische patronen. Voor beveiligingsscenario's zijn metrische alerts minder geschikt omdat ze geen context bieden over de oorzaak van een afwijking en geen correlatie kunnen uitvoeren tussen meerdere signalen. Loggebaseerde alerts vormen de tweede categorie en zijn gebaseerd op Kusto Query Language-query's die worden uitgevoerd tegen Log Analytics-tabellen. Deze alerts zijn krachtiger dan metrische alerts omdat ze complexe logica kunnen implementeren, meerdere databronnen kunnen correleren en contextrijke informatie kunnen extraheren uit gestructureerde loggegevens. Voorbeelden van loggebaseerde alerts zijn het detecteren van verdachte aanmeldingspatronen door het analyseren van Azure AD-sign-in logs, het identificeren van policy-overtredingen door het doorzoeken van Activity Logs of het monitoren van beveiligingsaanbevelingen uit Defender for Cloud. Loggebaseerde alerts worden periodiek geëvalueerd (standaard elke 5 minuten, configureerbaar tot 1 minuut) en kunnen worden geoptimaliseerd door efficiënte query's te schrijven die gebruikmaken van indexering en aggregaties om querykosten te minimaliseren. Activity Log-alerts vormen een speciale subcategorie die specifiek gericht zijn op het monitoren van beheeractiviteiten in Azure, zoals het maken, wijzigen of verwijderen van resources, het toewijzen van rollen, het wijzigen van netwerkconfiguraties of het uitschakelen van beveiligingsfuncties. Deze alerts zijn essentieel voor het detecteren van ongeautoriseerde wijzigingen, insider threats en misconfiguraties die kunnen leiden tot beveiligingslekken. Activity Log-alerts worden bijna real-time geëvalueerd (binnen enkele seconden) en kunnen worden geconfigureerd om te reageren op specifieke gebeurtenistypen, resourcegroepen of abonnementen. Voor Nederlandse overheidsorganisaties zijn Activity Log-alerts bijzonder waardevol omdat ze direct inzicht geven in wie welke wijzigingen heeft aangebracht, wat essentieel is voor accountability en forensisch onderzoek. Application Insights-alerts richten zich op applicatieprestaties en beschikbaarheid, door te monitoren op fouten, trage responsetijden, beschikbaarheidsproblemen en afhankelijkheidsfouten. Deze alerts maken gebruik van Application Insights-telemetrie die wordt verzameld vanuit webapplicaties, API's en serverless functies, en kunnen worden geconfigureerd om te reageren op trends, zoals een toename van foutpercentages over een bepaalde periode, of op specifieke gebeurtenissen, zoals het falen van een kritieke afhankelijkheid. Application Insights-alerts zijn waardevol voor het monitoren van bedrijfskritieke applicaties waar beschikbaarheid en prestaties direct impact hebben op dienstverlening aan burgers en ketenpartners.

Action Groups en Multi-Channel Notificaties

Action Groups vormen de verbinding tussen gedetecteerde alerts en de personen, systemen en processen die moeten reageren. Een Action Group is een herbruikbare verzameling van notificatiekanalen die kunnen worden gekoppeld aan meerdere alertregels, waardoor consistentie wordt geborgd en onderhoud wordt vereenvoudigd. Elke Action Group kan een combinatie bevatten van e-mailnotificaties naar individuele gebruikers of distributiegroepen, SMS-berichten naar telefoonnummers, voice calls voor kritieke scenario's, Azure mobile app push-notificaties, webhooks naar externe systemen zoals Microsoft Teams, Slack, PagerDuty of ITSM-tools zoals ServiceNow en TOPdesk, en Logic Apps of Azure Functions voor geautomatiseerde workflows. Voor Nederlandse overheidsorganisaties is het essentieel om Action Groups te structureren op basis van severity en scenario-type. Beveiligingsalerts met severity 0 (kritiek) worden bijvoorbeeld gekoppeld aan een SOC Action Group die direct notificeert naar het Security Operations Center via Teams, e-mail en een ServiceNow-webhook voor automatische ticketcreatie. Operationele alerts met severity 1 of 2 worden gekoppeld aan een Operations Action Group die notificeert naar het on-callteam en applicatiebeheerders. Informatieve alerts met severity 3 of 4 worden gekoppeld aan een Reporting Action Group die alleen e-mailnotificaties verstuurt naar belanghebbenden zonder directe actie te vereisen. Door deze scheiding ontstaat duidelijkheid over wie verantwoordelijk is voor welke type alerts en wordt voorkomen dat teams worden overspoeld door niet-kritieke meldingen. Webhook-integraties zijn bijzonder waardevol voor het automatiseren van incidentrespons. Een webhook naar Microsoft Teams kan bijvoorbeeld een rich card genereren met details over de alert, links naar relevante resources in de Azure Portal en knoppen voor snelle acties zoals het starten van een runbook of het openen van een ticket. Een webhook naar ServiceNow kan automatisch een incident ticket aanmaken met alle relevante context, de juiste prioriteit toewijzen op basis van de alert severity en het ticket koppelen aan de Configuration Management Database voor impactanalyse. Logic Apps kunnen worden gebruikt om complexe workflows te implementeren, zoals het verzamelen van aanvullende context uit andere systemen, het uitvoeren van vooraf gedefinieerde herstelacties of het escaleren naar management wanneer bepaalde drempelwaarden worden overschreden. Een belangrijk aspect van Action Groups is validatie en testen. E-mailadressen en telefoonnummers moeten worden gevalideerd voordat ze worden gebruikt, en Action Groups moeten periodiek worden getest door middel van synthetische alerts om te bevestigen dat notificaties daadwerkelijk worden ontvangen en correct worden weergegeven. Voor productieomgevingen is het aan te raden om een test Action Group te configureren die wordt gebruikt tijdens ontwikkeling en validatie, en een productie Action Group die alleen wordt gebruikt voor echte alerts. Daarnaast moeten Action Groups worden beveiligd met rolgebaseerde toegangscontrole, zodat alleen geautoriseerde personen wijzigingen kunnen aanbrengen, en moeten wijzigingen worden gelogd in Activity Logs voor auditdoeleinden.

Gebruik PowerShell-script azure-monitor-alerts.ps1 (functie Invoke-Implementation) – Inventariseren en configureren van Azure Monitor Alerts en Action Groups.

Alert Processing Rules en Alarmmoeheid Beheer

Alert Processing Rules zijn een krachtige functie van Azure Monitor die organisaties in staat stellen om alertgedrag dynamisch aan te passen zonder de onderliggende alertregels te wijzigen. Deze regels worden geëvalueerd nadat een alert is gegenereerd maar voordat notificaties worden verstuurd, waardoor ze kunnen worden gebruikt om alarmmoeheid te voorkomen, notificaties te onderdrukken tijdens geplande onderhoudsvensters, actiegroepen dynamisch toe te wijzen op basis van context of alerts te groeperen om redundante meldingen te voorkomen. Een veelvoorkomend probleem in cloudomgevingen is alarmmoeheid, waarbij teams worden overspoeld door een groot aantal alerts, waardoor kritieke signalen worden gemist en teams alerts gaan negeren. Alert Processing Rules kunnen dit probleem aanpakken door alerts te onderdrukken wanneer bepaalde voorwaarden zijn voldaan, zoals tijdens geplande onderhoudsvensters, wanneer een resource al in een bekende problematische staat verkeert, of wanneer een alert al is geëscaleerd naar een hoger niveau. Bijvoorbeeld, wanneer een applicatie tijdens een gepland onderhoudsvenster wordt bijgewerkt en meerdere alerts worden gegenereerd over beschikbaarheidsproblemen, kan een Alert Processing Rule deze alerts onderdrukken en alleen een samenvattende notificatie versturen naar het operations team in plaats van individuele alerts voor elke resource. Een andere use case voor Alert Processing Rules is het dynamisch toewijzen van Action Groups op basis van context. Bijvoorbeeld, wanneer een alert wordt gegenereerd voor een resource in een productieomgeving, kan een regel automatisch een productie Action Group toewijzen die notificeert naar het on-callteam en het SOC. Wanneer dezelfde alert wordt gegenereerd voor een testomgeving, kan een andere regel een test Action Group toewijzen die alleen notificeert naar ontwikkelaars. Dit maakt het mogelijk om één set alertregels te gebruiken voor meerdere omgevingen terwijl de notificatiestrategie wordt aangepast op basis van de omgeving. Alert Processing Rules kunnen ook worden gebruikt om alerts te groeperen, waardoor meerdere gerelateerde alerts worden gecombineerd in één notificatie. Dit is bijzonder waardevol voor scenario's waarbij een enkele gebeurtenis meerdere alerts triggert, zoals wanneer een netwerkstoring leidt tot alerts voor meerdere resources die afhankelijk zijn van dat netwerk. Door deze alerts te groeperen ontvangen teams één samenhangende notificatie in plaats van tientallen individuele alerts, wat de triage en respons aanzienlijk versnelt. Voor Nederlandse overheidsorganisaties is het belangrijk om Alert Processing Rules te documenteren en te koppelen aan change management processen. Elke regel moet een duidelijke business case hebben, moet worden getest in een sandbox-omgeving voordat deze wordt uitgerold naar productie, en moet worden gereviewd tijdens periodieke evaluaties om te bevestigen dat de regel nog steeds de beoogde doelen bereikt. Daarnaast moeten Alert Processing Rules worden gecontroleerd via Azure Policy om te voorkomen dat onbevoegde personen regels kunnen wijzigen of verwijderen die essentieel zijn voor de alertingstrategie.

Implementatie en Automatisering van Alertregels

De implementatie van Azure Monitor Alerts begint met een gedetailleerde inventarisatie van alle workloads, resources en processen die als kritiek zijn aangemerkt binnen de organisatie. Voor elke workload wordt bepaald welke risico's prioriteit hebben (confidentialiteit, integriteit, beschikbaarheid), welke signalen beschikbaar zijn in Azure Monitor en Log Analytics, en welke drempelwaarden of query's nodig zijn om afwijkingen te detecteren. Deze voorbereiding resulteert in een alertingdesign-document waarin per scenario wordt beschreven welke alertregel wordt gebruikt, welke voorwaarden worden geëvalueerd, welke severity wordt toegekend, welke Action Group wordt gekoppeld en wie verantwoordelijk is voor opvolging. Voor grootschalige implementaties is het essentieel om alertregels te beheren via Infrastructure as Code in plaats van handmatige configuratie in de Azure Portal. Dit maakt het mogelijk om alertregels te versiebeheren, te testen in sandbox-omgevingen, gecontroleerd uit te rollen via CI/CD-pijplijnen en consistent te implementeren over meerdere abonnementen en tenants. Azure Resource Manager-templates, Bicep of Terraform kunnen worden gebruikt om alertregels, Action Groups en Alert Processing Rules te definiëren als code, waardoor wijzigingen traceerbaar zijn en rollback mogelijk is wanneer problemen optreden. Het PowerShell-script azure-monitor-alerts.ps1 dat bij deze baseline hoort, dient als referentie-implementatie voor het inventariseren en configureren van alertregels. Het script kan worden gebruikt om per abonnement te controleren welke alertregels actief zijn, welke Action Groups zijn geconfigureerd en of de configuratie overeenkomt met de organisatorische standaarden. De functie Invoke-Implementation kan worden uitgebreid om automatisch alertregels aan te maken op basis van templates, Action Groups te koppelen en Alert Processing Rules te configureren, waardoor de implementatie reproduceerbaar en schaalbaar wordt. Naast technische implementatie is organisatorische voorbereiding essentieel. Teams moeten worden getraind in het interpreteren van alerts, het uitvoeren van triage, het volgen van runbooks en het documenteren van incidenten. Playbooks moeten worden ontwikkeld die beschrijven welke acties moeten worden ondernomen wanneer specifieke alerts worden geactiveerd, inclusief escalatiecriteria, contactpersonen en herstelprocedures. Deze playbooks moeten regelmatig worden bijgewerkt op basis van lessons learned uit echte incidenten en moeten worden geoefend tijdens tabletop-oefeningen om te bevestigen dat teams effectief kunnen reageren onder druk. Validatie en testen vormen een kritiek onderdeel van de implementatie. Elke alertregel moet worden getest door een gecontroleerde gebeurtenis te simuleren die de alert zou moeten triggeren, waarna wordt geverifieerd dat de notificatie correct wordt ontvangen, dat de context compleet is en dat de responstijd acceptabel is. Voor loggebaseerde alerts moeten query's worden geoptimaliseerd om te voorkomen dat ze te lang duren of te veel kosten genereren, en moeten ze worden getest met representatieve data om te bevestigen dat ze de beoogde scenario's correct detecteren. Na acceptatie worden alertregels uitgerold naar productie via een gecontroleerd changeproces, waarbij change records worden aangemaakt, impactanalyses worden uitgevoerd en rollback-plannen worden voorbereid.

Gebruik PowerShell-script azure-monitor-alerts.ps1 (functie Invoke-Monitoring) – Periodiek controleren van alertregels, Action Groups en compliance-status.

Monitoring, Optimalisatie en Continue Verbetering

Een volwassen alertingstrategie vereist continue monitoring en optimalisatie om te bevestigen dat alerts effectief zijn, dat false positives worden geminimaliseerd en dat responstijden binnen acceptabele grenzen blijven. Azure Monitor biedt ingebouwde telemetrie over alertevaluaties, notificatieleveringen en actie-uitvoeringen, die kan worden gebruikt om dashboards te bouwen die inzicht geven in de gezondheid en effectiviteit van het alertingsysteem. Key performance indicators die moeten worden gemonitord omvatten het aantal gegenereerde alerts per dag/week/maand, de verhouding tussen true positives en false positives, de gemiddelde responstijd van teams op alerts, het percentage alerts dat binnen de SLA wordt opgepakt, en de kosten die worden gegenereerd door loggebaseerde query's en notificaties. Door deze KPI's te volgen in Azure Workbooks of Grafana-dashboards kunnen teams trends identificeren, zoals een toename in false positives na een wijziging in drempelwaarden, een afname in responstijden na het implementeren van automatisering, of een stijging in kosten na het toevoegen van nieuwe loggebaseerde alerts. False positives vormen een groot probleem in veel alertingimplementaties, omdat ze teams afleiden van echte bedreigingen en leiden tot alertmoeheid. Om false positives te minimaliseren moeten alertregels regelmatig worden gereviewd en aangepast op basis van historische data. Loggebaseerde alerts kunnen worden verbeterd door query's te verfijnen om edge cases uit te sluiten, door aggregaties toe te voegen om ruis te filteren, of door aanvullende voorwaarden toe te voegen die context vereisen voordat een alert wordt geactiveerd. Metrische alerts kunnen worden verbeterd door dynamische drempelwaarden te gebruiken in plaats van statische waarden, waardoor seizoensgebonden variaties en trends worden meegenomen in de evaluatie. Het PowerShell-script bevat de functie Invoke-Monitoring die periodiek kan worden uitgevoerd om de status van alertregels te controleren, Action Groups te valideren en compliance te rapporteren. Het script genereert een JSON-rapport dat kan worden geïntegreerd in compliance-dashboards en kan worden gebruikt om trends te analyseren over tijd. Door dit script dagelijks of wekelijks uit te voeren via Azure Automation of GitHub Actions wordt onmiddellijk zichtbaar wanneer alertregels worden uitgeschakeld, wanneer Action Groups worden gewijzigd of wanneer nieuwe regels worden toegevoegd die mogelijk niet voldoen aan de organisatorische standaarden. Continue verbetering wordt gerealiseerd door periodieke evaluaties, bijvoorbeeld tijdens het kwartaaloverleg van het Cloud Competence Center of tijdens de jaarlijkse informatiebeveiligingscyclus. Tijdens deze evaluaties wordt geanalyseerd of de huidige alertregels nog aansluiten bij het actuele dreigingsbeeld, of nieuwe scenario's moeten worden toegevoegd op basis van lessons learned uit incidenten, of bestaande regels moeten worden verwijderd omdat ze niet langer relevant zijn, en of drempelwaarden moeten worden aangepast op basis van veranderende workload-patronen. De uitkomsten worden vastgelegd in het alertingdesign-document en worden vertaald naar concrete acties zoals het aanpassen van query's, het toevoegen van nieuwe Action Groups of het implementeren van aanvullende Alert Processing Rules.

Compliance, Audit en Verantwoording

Azure Monitor Alerts staan rechtstreeks in verbinding met meerdere wettelijke en normatieve kaders die van toepassing zijn op Nederlandse organisaties. Voor de publieke sector is de Baseline Informatiebeveiliging Overheid (BIO) leidend, met name norm 12.04 die vereist dat beveiligingsrelevante gebeurtenissen worden vastgelegd, beoordeeld en van passende opvolging worden voorzien. Door Azure Monitor Alerts als formeel proces te definiëren, kan de organisatie aantonen dat logging niet slechts passief plaatsvindt maar actief wordt geanalyseerd en dat teams proactief worden gewaarschuwd wanneer afwijkingen worden gedetecteerd. De alertdocumentatie, inclusief design-documenten, playbooks en incidentrapporten, fungeert als controle-evidence tijdens ENSIA-audits omdat zichtbaar is welke processen worden bewaakt, wie verantwoordelijk is voor opvolging en binnen welke tijdvensters moet worden gehandeld. ISO 27001-controle A.12.4.1 vereist dat gebeurtenissen in systemen worden bewaakt en dat alarmering wordt ingericht wanneer afwijkingen optreden. De beschreven configuratie van metrische, loggebaseerde en Activity Log-alerts levert exact deze waarborg: incidenten worden niet alleen geregistreerd maar ook automatisch geëscaleerd naar aangewezen rollen. In het kader van AVG Artikel 32 kan de organisatie aantonen dat passende technische maatregelen zijn getroffen om beveiligingsincidenten snel te detecteren, wat essentieel is voor de meldplicht datalekken. Door alertpayloads te loggen in ITSM-systemen en door incidentrespons te documenteren ontstaat bovendien een compleet dossier waarmee binnen 72 uur richting de Autoriteit Persoonsgegevens kan worden aangetoond welke signalen zijn ontvangen, wie heeft gereageerd en welke maatregelen zijn genomen. De NIS2-richtlijn en de Wet beveiliging netwerk- en informatiesystemen verlangen aantoonbare monitoring voor vitale en belangrijke entiteiten. Door alle kritieke workloads te koppelen aan gestandaardiseerde alertregels en door escalaties automatisch te loggen in ITSM-systemen, kan een organisatie laten zien dat zij passende en proportionele maatregelen hanteert voor het detecteren en reageren op beveiligingsincidenten. Voor sectorale kaders zoals DigiD-beveiligingsrichtlijnen, DNB Good Practice Informatiebeveiliging of de Rijkscloudstrategie geldt eveneens dat incidentdetectie en opvolging controleerbaar moeten zijn. Het gebruik van Action Groups met MFA-beschermde accounts, rolgebaseerde autorisaties en audit trails binnen Azure Monitor voldoet aan deze eisen en toont volwassenheid in security operations. Auditors zullen bewijs willen zien dat alertregels daadwerkelijk bestaan, actief zijn en worden gebruikt. Daarom hoort bij deze maatregel een set rapportages waarin per regel de status, het aantal triggers, de verhouding tussen true en false positives, en de toegewezen eigenaar worden weergegeven. Exporten van Get-AzMetricAlertRuleV2, Get-AzScheduledQueryRule en Get-AzActionGroup fungeren als basisevidence, aangevuld met incidenttickets, post-mortemrapporten en lessons-learned-sessies. Door deze artefacten te koppelen aan het risicoregister en aan change-records ontstaat een sluitende keten van detectie -> respons -> verbetering. Hierdoor wordt duidelijk dat compliance geen papieren exercitie is maar ondersteund wordt door werkende technologie en aantoonbare processen. Voor organisaties die onder toezicht staan van de Algemene Rekenkamer of sectorale toezichthouders is het bovendien noodzakelijk om periodiek assurance-verklaringen aan te leveren. Een volwassen Azure Monitor-alertframework maakt het mogelijk om betrouwbare cijfers te leveren over aantallen gedetecteerde incidenten, responstijden en structurele verbetermaatregelen. Deze informatie wordt gekoppeld aan de planning-en-controlcyclus en vormt input voor het jaarverslag over informatieveiligheid. Door expliciet te verwijzen naar de alertregels in architectuurdocumenten en verwerkingsregisters kan de organisatie aantonen dat beveiligingsmaatregelen privacy by design zijn ingebed in de cloudarchitectuur, wat het vertrouwen van auditors en stakeholders vergroot.

Gebruik PowerShell-script azure-monitor-alerts.ps1 (functie Invoke-Remediation) – Ondersteunen van remediatie door niet-conforme configuraties te identificeren en hersteladvies te geven.

Compliance & Frameworks

• CIS M365: Control 5.16 (L1) - Azure Monitor alerts configureren voor proactieve detectie
• BIO: 12.04 - Bewaking en alarmering van beveiligingsrelevante gebeurtenissen
• ISO 27001:2022: A.12.4.1 - Gebeurtenissen logging en audittrails met proactieve alarmering
• NIS2: Artikel - Continu monitoren en onderzoeken van beveiligingsincidenten met geautomatiseerde detectie

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

Ontwerp een complete set Azure Monitor-alertregels op basis van metrische signalen, loggebaseerde query's en Activity Log-gebeurtenissen, koppel ze aan Action Groups met multi-channel notificaties, implementeer Alert Processing Rules om alarmmoeheid te voorkomen, en borg continue optimalisatie via monitoring, dashboards en periodieke evaluaties. Gebruik het PowerShell-script azure-monitor-alerts.ps1 om alertregels te inventariseren, te configureren en te monitoren.

• Implementatietijd: 24 uur
• FTE required: 0.12 FTE