En SIEM-integration bör hjälpa en analytiker att undersöka ett autentiseringsvillkor, inte skapa en incident för varje misslyckad rad i sammanlagd rapport. Välj en specifik destination och arbetsflöde. Den här guiden använder Azure Monitor-intag och Microsoft Sentinel-incidenthantering som ett dokumenterat designexempel, med föreslagna mappningar och hypotetiska beslut snarare än en påstådd EmailAuth integration.
Separera observation från fynd
En samlad rapport registrerar autentiseringsutvärderingar. Ett fynd lägger till tolkning som att en godkänd faktureringsavsändare oväntat förlorar inriktning. Behåll bevispopulationen, tidsintervall, känd avsändare, förtroende och affärseffekt. RFC 9990 tillhandahåller rapporteringssemantiken; det fastställer inte att varje fel är skadligt eller att en incident måste öppnas.
Använd en avgränsad korrelationsnyckel som innehåller kundomfattning, domän, avsändare och villkor. Undvik att lägga in meddelandetexter eller mottagaradresser i händelsen när metadata och en åtkomstkontrollerad bevisreferens räcker. Inkludera händelsetid och intagstid separat så att försenade bevis inte förväxlas med ett aktuellt avbrott.
Karta till en faktisk intagsgräns
Azure Monitors Logs Ingestion API-dokumentation beskriver att skicka data via en datainsamlingsregel till en måltabell, med tillhörande autentisering och behörigheter. En distribution behöver det faktiska tabellschemat, strömmen, slutpunkten, DCR och auktoriserad identitet. En framgångsrik JSON-serialisering i sig bevisar inte att tjänsten accepterade eller indexerade händelsen.
En föreslagen mappning tilldelar värdet event_time till TimeGenerated och definierar anpassade kolumner TenantScope_s, Domain_s, FindingType_s, EvidenceRef_s, CorrelationKey_s, Severity_s och SchemaVersion_s. Dessa anpassade namn är ett föreslaget schema, inte inbyggda Sentinel-fält. TenantScope_s är en applikationskorrelationsetikett; den upprätthåller inte isolering eller behörigheter för Azure-tenant. Konfigurera och testa åtkomst separat.
Korrelera och hantera incidenten
Bestäm om analysregler skapar incidenter från intagen data eller om en auktoriserad adapter hanterar incidenter direkt. Undvik att köra båda vägarna utan deduplicering. De Sentinel Incidents Skapa eller uppdatera API dokumenterar en PUT-operation mot ett specifikt incident-ID för version 2025-09-01, med obligatoriska rubrik-, allvarlighets- och statusfält. Fäst den faktiska versionen i implementeringen och hantera samtidighet snarare än att blint skriva över en analytikers arbete.
Behåll korrelation-nyckel-till-incident-ID-relationen. Tilldela ett distinkt incident-ID för varje betrodd hyresgäst-omfattande nyckel; återanvändning av ett fast ID över nycklar kan skriva över en annan kunds incident. Validera klientbindning före korrelation, eftersom en klientsträng som tillhandahålls av en otillförlitlig händelse inte är auktoritet. Upprepade observationer kan uppdatera den befintliga incidenten med ytterligare bevis istället för att öppna dubbletter. Tilldela en analytiker och en nästa åtgärd. Stängning bör registrera vad som undersöktes och varför resultatet är motiverat, med hjälp av destinationens stödda status- och klassificeringsfält.
Håll kundkorrelation och analytikerbeslut åtskilda
Antag att två observationer av samma godkända avsändares anpassningsförlust kartlägger en incident med kundomfattning, medan en upprepad leverans av den första observationen inte tillför några dubbla bevis. En andra kunds annars liknande fynd måste mappas till sin egen auktoriserade destination och distinkta incidentidentitet. Återanvändning av ett fast incident-ID över båda nycklarna riskerar att skriva över fel post, även om korrelationsetiketten innehåller ett hyresgästnamn.
Separat kan en analytiker avsluta den första incidenten efter att ha bekräftat ett förväntat planerat test. En sen händelse får inte blint skriva över beslutet eller öppna det igen utan den godkända livscykelregeln. Behåll befintliga bevis, utvärdera om den nya observationen ändrar upptäckten och lös samtidiga redigeringar med hjälp av destinationskontraktet. Dessa är hypotetiska beslut, inte faktiska incidenter, klassificeringsresultat eller utförda livscykeltester.
Den här guiden skapar ingen DCR, erhåller ingen token, matar inga loggar och anropar inget Sentinel API. Innan produktionsacceptans, kör en auktoriserad testhändelse genom den verkliga destinationen, verifiera indexerade fält och hyresgäståtkomst, utöva dubblettleverans och bekräfta stängning utan att skriva över orelaterade analytikerändringar. Behåll begäran-ID och observerade resultat. Om något steg saknas, märk integrationen som en dokumenterad design med väntande exekvering, inte en distribuerad kontroll.