Un'integrazione SIEM dovrebbe aiutare un analista a indagare su una condizione di autenticazione, non a creare un incidente per ogni riga del report aggregato non riuscita. Scegli una destinazione e un flusso di lavoro specifici. Questa guida usa l'inserimento di Monitoraggio di Azure e la gestione degli incidenti di Microsoft Sentinel come esempio di progettazione documentata, con mappature proposte e decisioni ipotetiche anziché un'integrazione EmailAuth dichiarata.
Separare l'osservazione dalla scoperta
UN rapporto aggregato registra le valutazioni di autenticazione. Una scoperta aggiunge un'interpretazione come quella di un mittente della fatturazione approvato che perde inaspettatamente allineamento. Conserva la popolazione delle prove, l'intervallo di tempo, il mittente conosciuto, la confidenza e l'impatto aziendale. RFC 9990 fornisce la semantica del reporting; non stabilisce che ogni errore sia dannoso o che debba essere aperto un incidente.
Utilizza una chiave di correlazione limitata contenente ambito, dominio, mittente e condizione del cliente. Evitare di inserire nell'evento il corpo del messaggio o gli indirizzi dei destinatari quando sono sufficienti metadati e un riferimento a prove con accesso controllato. Includere l'ora dell'evento e l'ora di acquisizione separatamente in modo che le prove ritardate non vengano confuse con un'interruzione corrente.
Mappatura su un limite di acquisizione effettivo
Documentazione dell'API di inserimento log di Monitoraggio di Azure descrive l'invio di dati tramite una regola di raccolta dati in una tabella di destinazione, con l'autenticazione e le autorizzazioni associate. Una distribuzione richiede lo schema della tabella, il flusso, l'endpoint, il DCR e l'identità autorizzata effettivi. Una serializzazione JSON riuscita da sola non dimostra che il servizio ha accettato o indicizzato l'evento.
Una mappatura proposta assegna il valore event_time a TimeGenerated e definisce le colonne personalizzate TenantScope_s, Domain_s, FindingType_s, EvidenceRef_s, CorrelationKey_s, Severity_s e SchemaVersion_s. Questi nomi personalizzati sono uno schema proposto, non campi Sentinel incorporati. TenantScope_s è un'etichetta di correlazione dell'applicazione; non impone l'isolamento o le autorizzazioni del tenant di Azure. Configura e testa l'accesso separatamente.
Correlare e gestire l'incidente
Decidi se le regole di analisi creano incidenti dai dati acquisiti o se un adattatore autorizzato gestisce direttamente gli incidenti. Evitare di eseguire entrambi i percorsi senza deduplicazione. IL Gli incidenti Sentinel creano o aggiornano l'API documenta un'operazione PUT rispetto a un ID incidente specifico per la versione 2025-09-01, con i campi obbligatori di titolo, gravità e stato. Blocca la versione effettiva nell'implementazione e gestisci la concorrenza anziché sovrascrivere ciecamente il lavoro di un analista.
Mantieni la relazione chiave di correlazione-ID incidente. Assegnare un ID incidente distinto per ciascuna chiave con ambito tenant attendibile; il riutilizzo di un ID fisso su più chiavi può sovrascrivere l'incidente di un altro cliente. Convalidare l'associazione del titolare prima della correlazione, poiché una stringa del titolare fornita da un evento non attendibile non è autorizzata. Osservazioni ripetute possono aggiornare l'incidente esistente con prove aggiuntive invece di aprire duplicati. Assegnare un analista e un'azione successiva. La chiusura dovrebbe registrare ciò che è stato indagato e il motivo per cui il risultato è giustificato, utilizzando lo stato supportato e i campi di classificazione della destinazione.
Mantieni separate la correlazione con i clienti e le decisioni degli analisti
Si supponga che due osservazioni della stessa mappatura della perdita di allineamento del mittente approvato siano relative a un incidente con ambito cliente, mentre una consegna ripetuta della prima osservazione non aggiunge alcuna prova duplicata. Il risultato altrimenti simile di un secondo cliente deve corrispondere alla propria destinazione autorizzata e all'identità distinta dell'incidente. Il riutilizzo di un ID incidente fisso su entrambe le chiavi rischia di sovrascrivere il record errato, anche se l'etichetta di correlazione contiene un nome tenant.
Separatamente, un analista può chiudere il primo incidente dopo aver confermato un test pianificato previsto. Un evento tardivo non deve sovrascrivere ciecamente quella decisione o riaprirla senza la regola del ciclo di vita approvata. Conservare le prove esistenti, valutare se la nuova osservazione modifica il risultato e risolvere le modifiche simultanee utilizzando il contratto di destinazione. Si tratta di decisioni ipotetiche, non di incidenti reali, risultati di classificazione o test del ciclo di vita eseguiti.
Questa guida non crea DCR, non ottiene token, non inserisce log e non chiama API Sentinel. Prima dell'accettazione della produzione, esegui un evento di test autorizzato attraverso la destinazione reale, verifica i campi indicizzati e l'accesso dei tenant, esercita la consegna duplicata e conferma la chiusura senza sovrascrivere le modifiche degli analisti non correlate. Conserva gli ID delle richieste e i risultati osservati. Se manca una fase, etichettare l'integrazione come una progettazione documentata con esecuzione in sospeso, non come un controllo distribuito.