En SIEM-integrasjon skal hjelpe en analytiker med å undersøke en autentiseringstilstand, ikke opprette en hendelse for hver mislykket aggregatrapportrad. Velg en bestemt destinasjon og arbeidsflyt. Denne veiledningen bruker Azure Monitor-inntak og Microsoft Sentinel-hendelseshåndtering som et dokumentert designeksempel, med foreslåtte kartlegginger og hypotetiske beslutninger i stedet for en påstått EmailAuth integrasjon.
Skille observasjon fra funn
An samlet rapport registrerer autentiseringsevalueringer. Et funn legger til tolkning som at en godkjent faktureringsavsender taper uventet justering. Behold bevispopulasjonen, tidsintervallet, kjent avsender, tillit og forretningseffekt. RFC 9990 gir rapporteringssemantikken; det fastslår ikke at enhver feil er ondsinnet eller at en hendelse må åpnes.
Bruk en avgrenset korrelasjonsnøkkel som inneholder kundeomfang, domene, avsender og tilstand. Unngå å legge meldingstekster eller mottakeradresser inn i hendelsen når metadata og en tilgangskontrollert bevisreferanse er tilstrekkelig. Inkluder forekomsttid og inntakstid separat, slik at forsinkede bevis ikke forveksles med et nåværende strømbrudd.
Kart til en faktisk inntaksgrense
Azure Monitors Logs Ingestion API-dokumentasjon beskriver sending av data gjennom en datainnsamlingsregel inn i en måltabell, med tilhørende autentisering og tillatelser. En distribusjon trenger det faktiske tabellskjemaet, strømmen, endepunktet, DCR og autorisert identitet. En vellykket JSON-serialisering alene beviser ikke at tjenesten godtok eller indekserte hendelsen.
En foreslått tilordning tildeler hendelsestidsverdien til TimeGenerated og definerer egendefinerte kolonner TenantScope_s, Domain_s, FindingType_s, EvidenceRef_s, CorrelationKey_s, Severity_s og SchemaVersion_s. Disse egendefinerte navnene er et foreslått skjema, ikke innebygde Sentinel-felt. TenantScope_s er en applikasjonskorrelasjonsetikett; den håndhever ikke Azure-leietakerisolering eller tillatelser. Konfigurer og test tilgang separat.
Korreler og administrer hendelsen
Bestem om analyseregler oppretter hendelser fra inntatt data eller en autorisert adapter administrerer hendelser direkte. Unngå å kjøre begge banene uten deduplisering. De Sentinel Incidents Opprett eller oppdater API dokumenterer en PUT-operasjon mot en spesifikk hendelses-ID for versjon 2025-09-01, med obligatoriske tittel-, alvorlighets- og statusfelt. Fest den faktiske versjonen i implementeringen og håndter samtidighet i stedet for å blindt overskrive en analytikers arbeid.
Vedvarende forholdet korrelasjon-nøkkel-til-hendelse-ID. Tildel en distinkt hendelses-ID for hver klarerte nøkkel med leietaker; gjenbruk av én fast ID på tvers av nøkler kan overskrive en annen kundes hendelse. Valider leietakerbinding før korrelasjon, siden en leietakerstreng levert av en uklarert hendelse ikke er autoritet. Gjentatte observasjoner kan oppdatere den eksisterende hendelsen med ytterligere bevis i stedet for å åpne duplikater. Tildel en analytiker og en neste handling. Lukking bør registrere hva som ble undersøkt og hvorfor utfallet er berettiget, ved å bruke destinasjonens støttede status- og klassifiseringsfelt.
Hold kundekorrelasjon og analytikerbeslutninger atskilt
Anta at to observasjoner av samme godkjente avsenderes justeringstap kartlegger én kundeomfattet hendelse, mens en gjentatt levering av den første observasjonen ikke tilfører duplikatbevis. En annen kundes ellers lignende funn må kartlegges til sin egen autoriserte destinasjon og distinkte hendelsesidentitet. Gjenbruk av én fast hendelses-ID på tvers av begge nøklene risikerer å overskrive feil post, selv om korrelasjonsetiketten inneholder et leietakernavn.
Separat kan en analytiker avslutte den første hendelsen etter å ha bekreftet en forventet planlagt test. En sen hendelse må ikke blindt overskrive den beslutningen eller gjenåpne den uten den godkjente livssyklusregelen. Ta vare på eksisterende bevis, vurder om den nye observasjonen endrer funnet og løs samtidige redigeringer ved å bruke destinasjonskontrakten. Dette er hypotetiske beslutninger, ikke faktiske hendelser, klassifiseringsresultater eller utførte livssyklustester.
Denne veiledningen oppretter ingen DCR, henter ingen token, inntar ingen logger og kaller ingen Sentinel API. Før produksjonsgodkjennelse, kjør en autorisert testhendelse gjennom den virkelige destinasjonen, verifiser indekserte felt og leietakertilgang, utøv duplikatlevering og bekrefte stenging uten å overskrive urelaterte analytikerendringer. Behold forespørsels-IDer og observerte resultater. Hvis et stadium mangler, merk integrasjonen et dokumentert design med ventende utførelse, ikke en distribuert kontroll.