En SIEM-integration skal hjælpe en analytiker med at undersøge en godkendelsesbetingelse, ikke skabe en hændelse for hver mislykket række i samlet rapport. Vælg en bestemt destination og arbejdsgang. Denne vejledning bruger Azure Monitor-optagelse og Microsoft Sentinel-hændelsesstyring som et dokumenteret designeksempel med foreslåede kortlægninger og hypotetiske beslutninger i stedet for en påstået EmailAuth integration.
Adskil observation fra fund
An samlet rapport registrerer autentificeringsevalueringer. Et fund tilføjer fortolkning, såsom at en godkendt faktureringsafsender uventet taber justering. Bevar bevispopulationen, tidsinterval, kendt afsender, tillid og forretningspåvirkning. RFC 9990 leverer rapporteringssemantikken; det fastslår ikke, at enhver fejl er ondsindet, eller at en hændelse skal åbnes.
Brug en afgrænset korrelationsnøgle, der indeholder kundeomfang, domæne, afsender og betingelse. Undgå at indsætte meddelelsestekster eller modtageradresser i begivenheden, når metadata og en adgangskontrolleret bevisreference er tilstrækkelig. Inkluder forekomsttid og indtagelsestid separat, så forsinkede beviser ikke forveksles med en aktuel afbrydelse.
Kort til en faktisk indtagelsesgrænse
Azure Monitors Logs Ingestion API-dokumentation beskriver afsendelse af data gennem en dataindsamlingsregel til en måltabel med tilhørende godkendelse og tilladelser. En implementering kræver det faktiske tabelskema, stream, slutpunkt, DCR og godkendt identitet. En vellykket JSON-serialisering alene beviser ikke, at tjenesten har accepteret eller indekseret hændelsen.
En foreslået kortlægning tildeler hændelsestidsværdien til TimeGenerated og definerer brugerdefinerede kolonner TenantScope_s, Domain_s, FindingType_s, EvidenceRef_s, CorrelationKey_s, Severity_s og SchemaVersion_s. Disse brugerdefinerede navne er et foreslået skema, ikke indbyggede Sentinel-felter. TenantScope_s er en applikationskorrelationslabel; det håndhæver ikke Azure-lejerisolering eller -tilladelser. Konfigurer og test adgang separat.
Korreler og administrer hændelsen
Beslut, om analyseregler skaber hændelser fra indlæste data, eller en autoriseret adapter administrerer hændelser direkte. Undgå at køre begge stier uden deduplikering. De Sentinel Incidents Opret eller opdater API dokumenterer en PUT-operation mod et specifikt hændelses-id for version 2025-09-01 med påkrævede titel-, alvorligheds- og statusfelter. Fastgør den faktiske version i implementeringen og håndter samtidighed i stedet for blindt at overskrive en analytikers arbejde.
Bevar sammenhængen-nøgle-til-hændelse-ID-forholdet. Tildel et særskilt hændelses-id for hver betroet lejer-omfattet nøgle; genbrug af ét fast ID på tværs af nøgler kan overskrive en anden kundes hændelse. Valider lejerbinding før korrelation, da en lejerstreng leveret af en upålidelig hændelse ikke er autoritet. Gentagne observationer kan opdatere den eksisterende hændelse med yderligere beviser i stedet for at åbne dubletter. Tildel en analytiker og en næste handling. Lukning skal registrere, hvad der blev undersøgt, og hvorfor resultatet er berettiget, ved hjælp af destinationens understøttede status- og klassifikationsfelter.
Hold kundekorrelation og analytikerbeslutninger adskilt
Antag, at to observationer af den samme godkendte afsenderes tab af tilpasning til én kunde-omfattet hændelse, mens en gentagen levering af den første observation ikke tilføjer duplikatbevis. En anden kundes ellers lignende fund skal knyttes til sin egen autoriserede destination og særskilte hændelsesidentitet. Genbrug af ét fast hændelses-id på tværs af begge nøgler risikerer at overskrive den forkerte post, selvom korrelationsetiketten indeholder et lejernavn.
Separat kan en analytiker lukke den første hændelse efter at have bekræftet en forventet planlagt test. En sen hændelse må ikke blindt overskrive denne beslutning eller genåbne den uden den godkendte livscyklusregel. Behold de eksisterende beviser, vurder, om den nye observation ændrer resultatet, og løs samtidige redigeringer ved hjælp af destinationskontrakten. Disse er hypotetiske beslutninger, ikke faktiske hændelser, klassificeringsresultater eller udførte livscyklustests.
Denne guide opretter ingen DCR, opnår ingen token, indtager ingen logfiler og kalder ingen Sentinel API. Før produktionsaccept skal du køre en autoriseret testhændelse gennem den rigtige destination, verificere indekserede felter og lejeradgang, udføre duplikatlevering og bekræfte lukning uden at overskrive urelaterede analytikerændringer. Behold anmodnings-id'er og observerede resultater. Hvis der mangler et trin, skal du mærke integrationen som et dokumenteret design med afventende udførelse, ikke en implementeret kontrol.