Une intégration SIEM devrait aider un analyste à enquêter sur une condition d'authentification, et non à créer un incident pour chaque ligne de rapport agrégé ayant échoué. Choisissez une destination et un flux de travail spécifiques. Ce guide utilise l’ingestion Azure Monitor et la gestion des incidents Microsoft Sentinel comme exemple de conception documenté, avec des mappages proposés et des décisions hypothétiques plutôt qu’une intégration EmailAuth revendiquée.
Séparer l’observation de la découverte
Un rapport global enregistre les évaluations d’authentification. Un résultat ajoute une interprétation telle qu'un expéditeur de facturation approuvé perd inopinément alignement. Conservez la population de preuves, la plage de temps, l’expéditeur connu, la confiance et l’impact commercial. RFC 9990 fournit la sémantique de reporting ; il n'établit pas que toute défaillance est malveillante ou qu'un incident doit être ouvert.
Utilisez une clé de corrélation limitée contenant la portée du client, le domaine, l'expéditeur et la condition. Évitez de placer le corps des messages ou les adresses des destinataires dans l'événement lorsque des métadonnées et une référence de preuve à accès contrôlé suffisent. Incluez séparément l’heure d’occurrence et l’heure d’ingestion afin que les preuves retardées ne soient pas confondues avec une panne actuelle.
Mapper avec une limite d'ingestion réelle
Documentation de l'API d'ingestion de journaux d'Azure Monitor décrit l'envoi de données via une règle de collecte de données dans une table cible, avec l'authentification et les autorisations associées. Un déploiement nécessite le schéma de table, le flux, le point de terminaison, le DCR et l'identité autorisée. Une sérialisation JSON réussie ne prouve pas à elle seule que le service a accepté ou indexé l'événement.
Un mappage proposé attribue la valeur event_time à TimeGenerated et définit les colonnes personnalisées TenantScope_s, Domain_s, FindingType_s, EvidenceRef_s, CorrelationKey_s, Severity_s et SchemaVersion_s. Ces noms personnalisés sont un schéma proposé et non des champs Sentinel intégrés. TenantScope_s est une étiquette de corrélation d'application ; il n’applique pas l’isolation ou les autorisations des locataires Azure. Configurez et testez l’accès séparément.
Corréler et gérer l'incident
Décidez si les règles d'analyse créent des incidents à partir des données ingérées ou si un adaptateur autorisé gère directement les incidents. Évitez d'exécuter les deux chemins sans déduplication. Le API de création ou de mise à jour des incidents Sentinel documente une opération PUT sur un ID d'incident spécifique pour la version 2025-09-01, avec les champs obligatoires de titre, de gravité et d'état. Épinglez la version actuelle dans l'implémentation et gérez la concurrence plutôt que d'écraser aveuglément le travail d'un analyste.
Conserver la relation clé de corrélation-ID d’incident. Attribuez un ID d'incident distinct pour chaque clé de confiance à l'échelle du locataire ; la réutilisation d'un identifiant fixe sur plusieurs clés peut écraser l'incident d'un autre client. Validez la liaison de locataire avant la corrélation, car une chaîne de locataire fournie par un événement non approuvé ne constitue pas une autorité. Des observations répétées peuvent mettre à jour l'incident existant avec des preuves supplémentaires au lieu d'ouvrir des doublons. Attribuez un analyste et une action suivante. La clôture doit enregistrer ce qui a fait l'objet d'une enquête et pourquoi le résultat est justifié, en utilisant les champs de statut et de classification pris en charge par la destination.
Séparez la corrélation des clients et les décisions des analystes
Supposons que deux observations de la carte de perte d'alignement du même expéditeur approuvé soient associées à un incident à l'échelle du client, tandis qu'une livraison répétée de la première observation n'ajoute aucune preuve en double. La découverte par ailleurs similaire d'un deuxième client doit correspondre à sa propre destination autorisée et à son identité d'incident distincte. La réutilisation d’un ID d’incident fixe sur les deux clés risque d’écraser le mauvais enregistrement, même si l’étiquette de corrélation contient un nom de locataire.
Par ailleurs, un analyste peut clôturer le premier incident après avoir confirmé un test planifié attendu. Un événement tardif ne doit pas écraser aveuglément cette décision ou la rouvrir sans la règle de cycle de vie approuvée. Conservez les preuves existantes, évaluez si la nouvelle observation modifie les résultats et résolvez les modifications simultanées à l'aide du contrat de destination. Il s’agit de décisions hypothétiques et non d’incidents réels, de résultats de classification ou de tests de cycle de vie exécutés.
Ce guide ne crée aucun DCR, n'obtient aucun jeton, n'ingère aucun journal et n'appelle aucune API Sentinel. Avant l'acceptation de la production, exécutez un événement de test autorisé via la destination réelle, vérifiez les champs indexés et l'accès des locataires, effectuez la livraison en double et confirmez la fermeture sans écraser les modifications d'analyste sans rapport. Conservez les ID de demande et les résultats observés. Si une étape manque, qualifiez l’intégration de conception documentée avec exécution en attente, et non de contrôle déployé.