Azure Monitor: Alert Rules Configureren Voor Proactieve Monitoring

Wanneer Azure-resources uitsluitend worden gelogd zonder afspraken over alerting, verandert monitoring in een post-mortem oefening. Analyse van recente incidenten binnen Nederlandse overheidsorganisaties laat zien dat uitval van zaaksystemen en datalekken vaak pas uren later werden ontdekt omdat niemand actief werd gealarmeerd op afwijkende patronen. In een tenant waarin geen waarschuwingen bestaan voor plotselinge pieken in mislukte aanmeldingen, voor het uitschakelen van netwerkbeveiligingsgroepen of voor het falen van back-upjobs, blijft de respons afhankelijk van handmatige loginspectie of meldingen van gebruikers. De gemiddelde tijd tot detectie loopt dan op tot dagen of zelfs weken, met als gevolg verhoogde forensische kosten, reputatieschade en een aantoonbaar compliance-risico richting BIO 12.04 en AVG Artikel 32. Bovendien worden operationele teams overspoeld door ruwe data zonder prioritering, waardoor kritieke signalen verdrinken tussen routinegebeurtenissen. Door een uitgewerkt set aan alertregels te definiëren inclusief duidelijke severities, escalatiepaden en automatische notificaties, verandert dezelfde datastroom in een proactief waarschuwingssysteem dat Mean Time To Detect en Mean Time To Respond terugbrengt naar minuten.

Implementatie

Deze maatregel beschrijft hoe een Log Analytics-gedreven Azure Monitor-architectuur wordt ingericht met drempel- en querygebaseerde regels voor beveiliging, beschikbaarheid en prestaties. Voor elke bedrijfskritieke workload worden signalen geselecteerd (bijvoorbeeld Azure Activity Logs, Resource Health, Defender for Cloud en platformmetrische gegevens) en gekoppeld aan actiegerichte voorwaarden. De regels worden centraal beheerd via Azure Monitor -> Alerts, ondersteund door PowerShell- en Bicep-sjablonen voor consistente uitrol in meerdere abonnementen. Elke regel wordt gekoppeld aan één of meerdere Action Groups die e-mail, SMS, Teams-notificaties, ITSM-webhooks en geautomatiseerde runbooks combineren. Het resultaat is een reproduceerbare set waarschuwingen die aansluit bij nationale kaders, de escalatieprocedures van de organisatie en de capaciteitsplanning van het on-callteam.

Vereisten

Een solide set aan vereisten begint bij de beschikbaarheid van een Log Analytics-workspace die dienstdoet als centrale opslagplaats voor alle relevante signalen. Zonder geconsolideerde telemetrie is het onmogelijk om correlatie op tenantniveau uit te voeren of consistente alertregels te definiëren. Elke productie-abonnement dat onder de verantwoordelijkheid van de organisatie valt, moet daarom diagnostic settings hebben die Activity Logs, resource logs (zoals Azure SQL, Key Vault en App Service) en platformmetrische gegevens exporteren naar dezelfde workspace of naar een hiërarchie van workspaces met data sharing. Daarnaast is het nodig dat Azure Monitor Metrics ingeschakeld blijven voor alle PaaS-componenten, dat Application Insights-instanties worden gekoppeld aan de workspace en dat Defender for Cloud-plannen actueel zijn zodat beveiligingsaanbevelingen als signaal beschikbaar komen. Zonder deze basistelemetrie zijn drempelwaarden blind en wordt een deel van de waarschuwingen nooit getriggerd.

Naast de data-infrastructuur moeten de juiste rechten aanwezig zijn. De beheerders die alertregels ontwerpen hebben minimaal de rol Monitor Contributor nodig op abonnementsniveau, terwijl implementatiescripts vaak gebruikmaken van een serviceprincipal met Automation Contributor en Log Analytics Contributor. Voor de integratie met IT-serviceprocessen is toegang tot het ticketingsysteem (bijvoorbeeld TOPdesk of ServiceNow) noodzakelijk om webhooks of Logic Apps te kunnen registreren. Ook moeten er budgetten zijn voor eventuele notificatiekosten: hoewel Azure Monitor de eerste duizend metrische evaluaties kosteloos aanbiedt, brengen loggebaseerde query’s en SMS-berichten wel kosten met zich mee. Deze financiële randvoorwaarden moeten vooraf zichtbaar worden gemaakt in de cloudkostenbegroting, inclusief reserveringen voor aanvullende oplossingen zoals Azure Managed Grafana of Microsoft Sentinel indien daarop dashboards draaien.

Een tweede cluster van vereisten richt zich op communicatie en escalatie. Action Groups hebben validatie nodig van de security officer, de on-callcoördinator en de functioneel beheerders van bedrijfskritieke processen. Voor e-mailadressen moet een distributiegroep bestaan met geautoriseerde leden, MFA is verplicht voor accounts die pushmeldingen in de Azure mobile app ontvangen en telefoonnummers voor SMS moeten routinematig worden getest. Wanneer webhooks naar Teams, PagerDuty of SIEM-oplossingen worden gebruikt, is het noodzakelijk dat de betreffende endpoint authenticatie ondersteunt (bijvoorbeeld Azure AD-appregistraties of afgesproken API-keys) en dat throttling-limieten zijn afgestemd op het verwachte volume. Zonder deze validaties riskeren organisaties dat meldingen wel worden verstuurd maar nooit worden gelezen of automatisch worden geblokkeerd.

Ook vanuit datagovernance bestaan duidelijke voorwaarden. Elke alertregel verwerkt metadata over gebruikers, resources en eventueel persoonsgegevens zoals IP-adressen, waardoor de organisatie moet kunnen aantonen dat gegevens minimaal BIO-classificatie BBN2 aankunnen en dat bewaartermijnen zijn vastgelegd. De Log Analytics-workspace moet daarom een retentionpolicy hebben die zowel operationele analyse als auditdoeleinden ondersteunt, doorgaans tussen de 180 en 730 dagen afhankelijk van het proces. Daarnaast is het noodzakelijk dat er taggingstandaarden bestaan voor abonnementen, resourcegroepen en individuele resources zodat alerts kunnen filteren op kritieke workloads. Deze metadata worden eveneens gebruikt om runbooks gericht te laten reageren, bijvoorbeeld door alleen productieomgevingen automatisch te isoleren. Zonder eenduidige tagging verliezen incidentresponders kostbare tijd met triage.

Tot slot wordt verwacht dat de organisatie testcapaciteit en kennisborging heeft ingericht. Er moet een sandbox-abonnement beschikbaar zijn waarin waarschuwingen kunnen worden geoefend zonder impact op productie, inclusief representatieve workloads die voldoende metrische variatie genereren. Teams moeten beschikken over een playbook waarin staat welke drempelwaarden als acceptabel worden gezien, hoe false positives worden gemeten en hoe wijzigingen door het Change Advisory Board worden goedgekeurd. Opleidingsmateriaal voor operators, SOC-analisten en applicatiebeheerders is essentieel zodat zij alertpayloads kunnen interpreteren, het juiste bewijsmateriaal verzamelen en escalatiecriteria begrijpen. Zonder deze organisatorische voorwaarden verandert een technische configuratie nooit in een effectief proces.

Implementatie

De implementatie start met een gedetailleerde inventarisatie van alle workloads die als missie- of taak-kritiek zijn aangemerkt binnen de Nederlandse Baseline voor Veilige Cloud. Voor iedere applicatie wordt bepaald welke risico’s prioriteit hebben (confidentialiteit, integriteit, beschikbaarheid) en welk type signaal daarbij past. Vervolgens worden de relevante metrische signalen verzameld uit Azure Resource Graph en Log Analytics om te bepalen welke bestaande metriekwaarden, dimensies en logtabellen beschikbaar zijn. Hieruit worden use-cases samengesteld, zoals het detecteren van verwijderde netwerkbeveiligingsgroepen, pieken in Key Vault-toegangen of het uitvallen van App Service-SLA’s. Deze voorbereiding resulteert in een mappingdocument waarin per scenario een Kusto-query, een drempelwaarde, een severiteit en een escalatiegroep staan beschreven. Pas wanneer dit document is goedgekeurd door de service-owner, de CISO en de operationsmanager begint de technische configuratie.

Wanneer de ontwerpprincipes vastliggen wordt in het Azure Portal genavigeerd naar Monitor -> Alerts -> Alert rules. Voor metrische alerts wordt gekozen voor het betreffende abonnement en resource, waarna statische of dynamische thresholds worden ingesteld op basis van historische data. Loggebaseerde alerts worden opgebouwd in de Log Analytics-workspace door een Kusto-query te schrijven en deze als scheduled query rule op te slaan, inclusief frequentie, lookback-periode en suppressie-interval om alarmmoeheid te voorkomen. Elke regel krijgt een severity van 0 (kritiek) tot 4 (informatief) en een duidelijke beschrijving waarin doel, eigenaar en hersteladvies zijn opgenomen. Door consistent dezelfde naamgevingsconventie te gebruiken (bijvoorbeeld `---`) kunnen operators alerts in dashboards en ticketingtools eenvoudiger filteren.

Gebruik PowerShell-script azure-monitor-alerts-configured.ps1 (functie Invoke-Implementation) – Implementeren.

Voor grootschalige uitrol wordt gebruikgemaakt van het PowerShell-script azure-monitor-alerts-configured.ps1, dat in dit project dient als referentie-implementatie. Het script accepteert parameters voor abonnement, workspace en Action Group-id’s en kan vanuit Azure Cloud Shell of een geautomatiseerd deploymentaccount worden gestart. Binnen de functie Invoke-Implementation worden metrische en logregels aangemaakt via de cmdlets New-AzScheduledQueryRule en New-AzMetricAlertRuleV2, waardoor configuraties reproduceerbaar zijn en versiebeheer toepasbaar wordt. De organisatiespecifieke logica, zoals het automatisch koppelen van tags of het vullen van custom properties voor ITSM, wordt in variabelen vastgelegd zodat hergebruik over meerdere tenants mogelijk is.

Action Groups worden parallel opgebouwd met combinaties van e-mail, SMS, voice calls, Azure Functions en Logic Apps. Voor beveiligingsscenario’s wordt minimaal één groep ingericht die rechtstreeks naar het SOC leidt en daarbij een Microsoft Teams-webhook en ServiceNow-webhook bevat om automatische tickets te openen. Operationele scenario’s zoals capaciteitsproblemen worden gekoppeld aan een DevOps-groep die naast notificaties ook een runbook kan starten om bijvoorbeeld schaalsets uit te breiden of probleeminformatie in een Configuration Management Database bij te werken. Door deze multi-channel aanpak wordt voorkomen dat meldingen alleen in een mailbox blijven hangen en ontstaat een aantoonbare keten van detectie tot remediatie.

Elke alertregel wordt vervolgens getest door een gecontroleerde gebeurtenis te simuleren: denk aan het tijdelijk verhogen van CPU-belasting, het uitvoeren van een mislukte back-up of het doelbewust uitschakelen van een beleid in een sandbox. De ontvangen meldingen worden gevalideerd op inhoud, tonaliteit en snelheid, waarna bevindingen worden teruggekoppeld aan het ontwerpdocument. Na acceptatie worden de regels via een Infrastructure-as-Code-pijplijn (bijvoorbeeld GitHub Actions of Azure DevOps) uitgerold naar productie. Een change record in het CAB bevat de referentie naar commit, testresultaten en impactanalyse. Hiermee is de implementatie aantoonbaar gecontroleerd en herhaalbaar, wat essentieel is voor audits en lessons learned.

Compliance en Auditing

Deze maatregel sluit rechtstreeks aan op BIO 12.04, dat vereist dat beveiligingsrelevante gebeurtenissen worden vastgelegd, beoordeeld en van passende opvolging worden voorzien. Door Azure Monitor-waarschuwingen als formeel proces te definiëren, kan de organisatie aantonen dat logging niet slechts passief plaatsvindt maar actief wordt geanalyseerd. De alertdocumentatie 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. Bovendien ondersteunt de maatregel BIO 11.04 (continuïteitsbeheer) doordat beschikbaarheidsrisico’s meetbaar worden gemaakt via expliciete drempelwaarden. Wanneer auditors vragen naar de koppeling met business impact analyses, kunnen de beschreven alertscenario’s direct worden gekoppeld aan kritieke processen en maximale uitvaltijden.

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 en querygebaseerde regels 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 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 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 en de toegewezen eigenaar worden weergegeven. Exporten van 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 zoals de Autoriteit Nucleaire Veiligheid en Stralingsbescherming of de Inspectie Justitie en Veiligheid 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. Hierdoor ontstaat continue aantoonbaarheid.

Monitoring

Monitoring begint niet nadat alerts zijn gebouwd, maar loopt parallel met de operationele cyclus. Voor elke regel worden meetpunten ingericht die aantonen hoe vaak zij worden geëvalueerd, welke suppressie actief is en of notificaties succesvol zijn afgeleverd. Azure Monitor levert daarvoor de Alert Processing Rule-telemetrie, terwijl Log Analytics dashboards inzicht geven in queryduur, time-outs en throttling. Door deze technische data wekelijks te bespreken in het operationsoverleg ontstaat zicht op trends, bijvoorbeeld een toename in waarschuwingen na patches of een afname omdat workloads zijn geoptimaliseerd. Deze trendanalyses vormen de basis voor het aanpassen van drempelwaarden zonder in te leveren op dekking.

Gebruik PowerShell-script azure-monitor-alerts-configured.ps1 (functie Invoke-Monitoring) – Controleren.

Het bijbehorende PowerShell-script bevat de functie Invoke-Monitoring, waarmee periodiek wordt gecontroleerd of de verwachte alertregels en Action Groups nog aanwezig zijn en of de configuratie overeenkomt met het basismodel. Het script kan worden geïntegreerd in Azure Automation of GitHub Actions en levert een JSON-rapport op dat direct in de compliance-rapportage kan worden opgenomen. Door deze controle dagelijks of wekelijks te draaien wordt onmiddellijk zichtbaar of iemand een regel per ongeluk heeft uitgeschakeld of verwijderd.

Naast configuratievalidatie is functionele monitoring noodzakelijk. Hiervoor worden synthetische tests opgezet die eens per kwartaal een gecontroleerde afwijking veroorzaken om te bevestigen dat notificaties daadwerkelijk doorkomen. De resultaten worden gedeeld met het SOC en het on-callteam, inclusief meetgegevens over levertijd per kanaal (Teams, e-mail, SMS). Bij afwijkingen worden Alert Processing Rules of Action Group-retries aangepast. Deze aanpak voorkomt dat stille misconfiguraties pas tijdens een echt incident aan het licht komen.

De operationele teams combineren deze inzichten met dashboards in Azure Workbooks of Grafana waarin key performance indicators worden gevolgd, zoals het percentage alerts dat binnen de SLA is opgepakt, de verhouding tussen true en false positives en de gemiddelde resolutietijd per severity. Door koppelingen te leggen met ServiceNow of TOPdesk ontstaat een volledig beeld van detectie tot ticketafhandeling. De rapportages worden maandelijks gedeeld met de CISO en de eigenaar van het cloudplatform, zodat strategische besluiten kunnen worden genomen over uitbreiding of afschaling van alertsets.

Tot slot omvat monitoring ook de menselijke factor. On-call-evaluaties en blameless post-incidentreviews leveren inzichten op over de begrijpelijkheid van meldingen, de volledigheid van context en de volgorde van escalatie. Deze feedback wordt vertaald naar verbeteringen in tekstvelden, runbooklinks en trainingsmateriaal. Door deze continue verbeterlus blijft het alertframework aansluiten op veranderende dreigingsbeelden en organisatorische verwachtingen.

Naast dashboards en scripts wordt ook gebruikgemaakt van near-real-time notificaties binnen Microsoft Defender for Cloud en Azure Service Health, die via integraties met Azure Monitor Alerts aanvullende context leveren. Door deze bronnen te correleren in één Log Analytics-workspace kunnen teams patronen herkennen, zoals combinaties van policy-uitschakelingen en afwijkend netwerkverkeer, en bepalen of aanvullende regels of machinelearningdetecties noodzakelijk zijn. De verzamelde inzichten worden gedeeld in het maandelijkse Cloud Risk Board, waar besluiten worden genomen over het toevoegen van nieuwe signalen of het afschalen van verouderde regels. Op die manier blijft monitoring een levend proces in plaats van een eenmalige configuratie.

De kwaliteit van monitoring wordt tenslotte jaarlijks beoordeeld via een maturity-assessment waarin de alertdekking wordt gespiegeld aan het actuele dreigingsbeeld van de NCTV en Microsoft Threat Intelligence-rapporten. Tijdens deze beoordelingen worden scenario's toegevoegd of verwijderd, wordt gecontroleerd of de ingestelde severities nog aansluiten bij de risicobereidheid en wordt vastgesteld of aanvullende tooling zoals Microsoft Sentinel of Defender for Cloud Apps moet worden gekoppeld. De uitkomsten worden vastgelegd in het cloudroadmapdocument en vormen input voor budget- en capaciteitsplanning.

Remediatie

Wanneer een alert afgaat, start een gestroomlijnd remediatieproces waarin rollen en responstijden vooraf zijn gedefinieerd. Elke melding bevat context zoals resource-id, correlatie-id en aanbevolen eerste handelingen, zodat analisten onmiddellijk kunnen bepalen of sprake is van een echte dreiging of een operationeel incident. De eerste stap is triage: controleren of het scenario reeds bekend is, of er onderhoud gepland stond en welke gebruikers of systemen zijn getroffen. SOC-analisten loggen deze bevindingen direct in het ITSM-systeem zodat auditsporen intact blijven.

Gebruik PowerShell-script azure-monitor-alerts-configured.ps1 (functie Invoke-Remediation) – Herstellen.

Het PowerShell-script bevat de functie Invoke-Remediation die bewaakt of de volledige definitieset actief is en, waar nodig, ontbrekende regels opnieuw creëert of Action Groups herkoppelt. Deze functie kan eveneens corrigerende acties uitvoeren, zoals het heractiveren van een uitgeschakelde policy of het forceren van een nieuwe baseline-implementatie. Door dezelfde codebasis te gebruiken voor implementatie en herstel is gewaarborgd dat configuraties consistent blijven over meerdere abonnementen en dat herstelacties aantoonbaar zijn.

Wanneer een alert wijst op een daadwerkelijke verstoring, volgen runbooks die exact beschrijven welke stappen in welke volgorde worden uitgevoerd. Voor beveiligingsincidenten betekent dit bijvoorbeeld dat verdachte accounts worden geblokkeerd, dat netwerksegmenten tijdelijk via Azure Firewall worden dichtgezet en dat relevante logboeken veilig worden gesteld voor forensisch onderzoek. Voor beschikbaarheidsincidenten kan het runbook instructies bevatten voor schaalacties, het terugzetten van back-ups of het inschakelen van failover naar een secundaire regio. Elk runbook bevat duidelijke beslismomenten en contactpersonen, zodat samenwerking tussen SOC, cloud engineers en applicatiebeheerders soepel verloopt.

Na het uitvoeren van directe herstelacties wordt een post-incidentreview gestart. Hierin wordt geëvalueerd welke alerts zijn getriggerd, hoe snel er is gereageerd, welke maatregelen effectief waren en welke structurele verbeteringen nodig zijn. Eventuele aanpassingen aan drempelwaarden, escalatiepaden of documentatie worden via het changeproces vastgelegd. Lessons learned worden toegevoegd aan het kennisportaal, zodat toekomstige responders profiteren van eerdere ervaringen. Dankzij deze continue verbetercyclus blijft het remediatieproces afgestemd op de actuele dreigingen en op de volwassenheid van de organisatie.

Documentatie van elke remediatieactie is verplicht voor compliance. Daarom wordt na afronding van een incident het ticket verrijkt met referenties naar de gebruikte scripts, betrokken resources en verzamelde forensische artefacten. Deze gegevens worden gekoppeld aan het risicoregister en aan KPI’s zoals MTTR en het aantal escalaties naar management. Door consequent te rapporteren ontstaat inzicht in structurele verbeterpunten, bijvoorbeeld het aanpassen van architectuur of het toevoegen van nieuwe alertscenario’s. De rapportages worden besproken in het Cloud Competence Center en vormen input voor toekomstige investeringen.

Voor incidenten met potentiële externe impact wordt het remediatiepad uitgebreid met communicatie- en juridische stappen. Zodra een alert is bevestigd als datalek of serviceonderbreking met maatschappelijke impact, wordt het crisisteam geactiveerd zodat persvoorlichting, privacy officers en contractmanagers beschikken over dezelfde feiten als de technische teams. Azure Monitor-gegevens, inclusief de oorspronkelijke payload en correlatie-id's, worden opgeslagen in een beveiligd dossier dat als bewijsmateriaal kan dienen richting leveranciers of toezichthouders. Hiermee kunnen beslissingen over melding aan de Autoriteit Persoonsgegevens, het informeren van ketenpartners of het activeren van continuïteitscontracten worden gebaseerd op actuele, verifieerbare data.

Het remediatieproces omvat bovendien structurele training. Elk kwartaal worden tabletop-oefeningen georganiseerd waarbij recente alerts worden nagebootst en multidisciplinaire teams oefenen met besluitvorming onder tijdsdruk. Hierbij wordt gekeken naar communicatie, technische uitvoering en documentatiekwaliteit. De resultaten leveren concrete verbeteracties op voor runbooks, scripts en escalatiepaden en zorgen ervoor dat nieuwe medewerkers snel vertrouwd raken met het proces.

Compliance & Frameworks

• BIO: 12.04 - Alerting
• ISO 27001:2022: A.12.4.1 - Gebeurtenissen logging en audittrails

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, automatiseer en test een volledige set Azure Monitor-regels op basis van Log Analytics en metrische signalen, koppel ze aan Action Groups met e-mail, SMS, Teams en ITSM-webhooks, en borg onderhoud via scripts en dashboards zodat detectie en respons voorspelbaar worden.

• Implementatietijd: 6 uur
• FTE required: 0.1 FTE