Un inventaire d'expéditeurs hérité est un outil de décision, pas une liste d'adresses IP. Avant de standardiser les domaines acquis, connectez le courrier observé au service spécifique au client qui l'a produit, à son propriétaire commercial et à ses identités approuvées. Un fournisseur familier peut héberger du trafic à la fois légitime et indésirable. La reconnaissance de l’infrastructure à elle seule ne constitue pas une approbation.
Commencez avec plusieurs sources de preuves
Rassemblez les exportations de configuration autorisées, les registres d'applications, les enregistrements de compte fournisseur, les observations DNS et les preuves de courrier disponibles. Conservez l’origine de chaque observation et la date à laquelle elle a été collectée. Rapports agrégés peut révéler les adresses IP sources et les modèles d'authentification, mais ne peut pas établir de manière indépendante l'intention commerciale de l'organisation ni la population complète des expéditeurs. RFC 9990.
Pour chaque service, objectif de l'enregistrement, propriétaire responsable, compte fournisseur ou locataire, criticité, visible depuis le domaine, domaine d'enveloppe, DKIM identité de signature, dernier test représentatif et preuve d’approbation. Gardez les champs inconnus explicites. Enregistrez séparément les objectifs d'envoi et de réception pour les domaines qui peuvent être dormants ou défensifs.
Attribuer des identités avant d'ajouter une autorité
Comparez les identifiants observés avec la configuration réelle du fournisseur et le flux de travail métier. DMARC utilise alignement entre le domaine auteur et un identifiant authentifié avec succès ; un résultat de réussite générique sans les identifiants peut masquer le problème que vous devez résoudre. RFC 9989.
N'ajoutez pas de source inconnue à SPF simplement parce que le courrier semble provenir de là. SPF autorise les hôtes pour l'identité évaluée et son évaluation inclut les limites de recherche DNS . RFC 7208 , section 4.6.4. Une nouvelle inclusion peut étendre l'autorité, dépasser les limites opérationnelles ou ne pas réussir à corriger l'alignement. Établissez d’abord le service prévu et l’itinéraire authentifié approprié.
Séparez l’approbation et les tests
Un service approuvé peut toujours échouer à un test de migration ; un message authentifié peut toujours provenir d'un service non approuvé. Stockez les deux états. Les preuves d'approbation doivent identifier la décision responsable, tandis que les preuves de test doivent décrire la transaction réelle, les identités, le résultat et le moment. N'utilisez pas la réussite d'un test comme substitut à la propriété d'une entreprise.
Supposons qu'un service de facturation hérité ait un propriétaire d'entreprise nommé et un objectif approuvé, mais que l'identité de signature du compte cible n'ait pas été vérifiée. Un deuxième service a un message de transmission aligné mais aucun propriétaire d'entreprise identifié. Le premier doit acheminer les preuves avant la migration ; le second doit être attribué et approuvé avant d'être traité comme un service autorisé. Aucun des deux écarts n'est résolu par le résultat rassurant de l'autre service.
Il s’agit de décisions d’inventaire hypothétiques, et non d’enregistrements générés ou de tests exécutés. Conservez des champs séparés pour la propriété, les identités prévues, l’approbation et la couverture actuelle des tests. Lorsque le propriétaire de l'application fournit les preuves de compte manquantes, mettre à jour uniquement l'état qu'il établit ; ne changez pas automatiquement un résultat de migration non testé en réussi.
Transformez l’attribution en plan de migration
Regroupez les services par propriétaire vérifié, dépendance et état de préparation. Définissez les identités cibles et les tests prévus avant de modifier les enregistrements. Préservez les itinéraires inconnus pour enquête, avec un propriétaire nommé et une date limite, plutôt que de les approuver ou de les supprimer en silence. Conservez l'ancienne configuration et un plan de récupération approuvé pour chaque transition consécutive.
Après la normalisation, rapprochez les observations réelles de l'inventaire approuvé et étudiez de nouvelles identités. Conservez les services retraités et leurs décisions dans l’historique. Un inventaire utile reste un enregistrement opérationnel grâce aux changements de fournisseurs et aux réponses aux incidents, plutôt qu'une feuille de calcul abandonnée à la fin du projet de fusion.
Ce flux de travail d’inventaire et d’examen est un modèle opérationnel recommandé. NIST SP 800-53 Rev. 5 CM-8 et CM-3 fournissent une base générale pour des inventaires responsables et des changements contrôlés ; ils ne prescrivent pas ces champs spécifiques au courrier électronique et ne confèrent pas d'approbation. Catalogue de contrôle NIST.