Définir ce que la ligne de base est censée prouver
Une référence d'authentification est une description approuvée de la configuration prévue et des preuves la soutenant à un moment donné. Il ne s’agit pas simplement d’une capture d’écran d’un éditeur DNS , d’une liste d’enregistrements souhaités ou d’une affirmation selon laquelle tous les futurs courriers seront authentifiés. Une base de référence utile connecte les domaines, les services d'envoi, la propriété des enregistrements, les chemins d'authentification attendus et les critères de vérification. La gestion des versions rend les changements explicables ; L'examen détermine si la configuration prévue convient toujours à l'entreprise.
Cet article propose un workflow de référence et de contrôle des modifications. Aucun référentiel n'a été créé, aucune configuration exportée, aucun enregistrement DNS modifié ou message testé. Les références de protocole établissent ce que signifie la configuration, tandis que le processus de gestion des versions est une recommandation opérationnelle éditoriale plutôt qu'une affirmation selon laquelle une norme impose un outil particulier. La référence doit rester distincte de la preuve du comportement de production actuel jusqu'à ce que les observations réelles soient collectées.
Capturer les identités et les responsabilités avant les enregistrements
Pour chaque flux de travail d'envoi, enregistrez l'objet commercial, le propriétaire du domaine, l'opérateur de service, le domaine visible depuis, l'identité de l'enveloppe attendue et DKIM signature du ou des domaines. Identifiez qui peut approuver un changement et qui peut l’exécuter. Un administrateur DNS peut contrôler la publication tandis qu'un fournisseur contrôle la signature, et le propriétaire de l'entreprise peut déterminer si un flux d'envoi doit exister. Ces responsabilités ne doivent pas être concentrées dans un seul champ ambigu de « propriétaire ».
RFC 9989 définit DMARCLes relations d'alignement de domaine de . Une ligne de base doit donc identifier le chemin aligné prévu plutôt que d'enregistrer uniquement ce chemin. SPF ou DKIM est activé. RFC 6376 définit la signature DKIM et sélecteur modèle. Enregistrez les sélecteurs et les dépendances de recherche publique qui comptent, mais ne placez jamais les clés de signature privées, les secrets d'API ou les informations d'identification de récupération dans une base de référence de configuration générale.
Conserver l’ensemble complet d’enregistrements pertinents
Enregistrez les noms exacts des propriétaires DNS , les types, les valeurs complètes et les durées de vie comme observé, avec la zone et le fournisseur faisant autorité. Gardez la notation du fournisseur-éditeur séparée de la représentation DNS publiée. Pour les données TXT , distinguez plusieurs chaînes de caractères dans un enregistrement de plusieurs enregistrements dans un ensemble. Une capture d'écran montrant une ligne sélectionnée peut omettre d'autres valeurs et ne peut pas nécessairement prendre en charge une opération de remplacement sûre. Conservez suffisamment de structure pour expliquer le changement complet prévu.
Documentation sur les enregistrements Azure DNS décrit les jeux d'enregistrements, les chaînes TXT et les métadonnées spécifiques au fournisseur. Il s’agit d’une preuve utile du modèle Azure, et non d’un schéma universel pour chaque fournisseur. Si le fournisseur réel diffère, vérifiez sa représentation actuelle et mettez à jour son comportement avant d'appliquer la feuille de calcul. Une référence peut utiliser une représentation neutre tout en conservant l'exportation du fournisseur d'origine comme preuve avec son temps de collecte et ses limites.
Séparer l’état prévu de l’état observé
Utilisez des sections distinctes pour la configuration cible approuvée et les observations collectées depuis la production. Une valeur SPF souhaitée ne constitue pas une preuve qu'un serveur faisant autorité l'a publiée. Une réponse DNS ne prouve pas qu'un fournisseur a signé un message avec le sélecteur attendu. Le résultat d’un message reçu ne prouve pas que chaque workflow d’envoi utilise le même chemin. Chaque observation doit indiquer sa portée, son heure, sa méthode de collecte et l'identité qu'elle couvre.
Lors de l'utilisation Authentication-Results comme preuve de vérification, suivez les préoccupations liées aux limites de confiance dans RFC 8601. Conservez les résultats du destinataire de confiance concerné plutôt que d’accepter des assertions arbitraires transmises par l’expéditeur. Conservez les preuves de messages expurgées et les originaux entièrement sensibles sous des contrôles d’accès appropriés. La référence doit faire référence aux emplacements de preuves approuvés, et non accumuler des corps de messages confidentiels ou des informations d'identification simplement pour des raisons de commodité.
Faites de chaque révision une décision explicable
Attribuez un identifiant de version interne et enregistrez la version précédemment approuvée, le motif du changement, la différence prévue, les flux de travail concernés, l'évaluation des risques et l'approbation commerciale. Un diff lisible doit montrer les ajouts, les suppressions et les remplacements dans un contexte complet. Il doit identifier si un fournisseur est introduit, un sélecteur alterné, un expéditeur obsolète supprimé ou une politique modifiée. Ne laissez pas une modification de formatage masquer une modification significative de l'autorisation ou alignement.
Choisissez un mécanisme de révision adapté aux outils de l'organisation, mais ne présumez pas qu'un engagement de contrôle de version équivaut à une approbation. Enregistrez séparément le propriétaire de la décision et la portée de l’approbation. Définissez ce qui se passe si la configuration actuelle observée diffère de la configuration de base attendue avant l'exécution. La réponse sûre consiste à rechercher et à concilier la différence, et non à écraser un état plus récent simplement parce qu'un fichier de modification préparé existe.
Tenir compte des modifications simultanées et des limites d'annulation
Azure DNS documente les Etags associés aux zones et aux jeux d'enregistrements, et explique comment ils peuvent détecter les modifications simultanées lorsqu'ils sont fournis lors des mises à jour. Il s'agit d'un mécanisme de concurrence spécifique au fournisseur, et non d'une propriété DNS générale. Un TTL contrôle le comportement de la mise en cache, et non qui peut modifier un enregistrement ou si un changement en écrase un autre. Confirmez le comportement de concurrence réel de l'interface et conservez la preuve de version utilisée pour la modification autorisée.
Les critères de restauration doivent identifier à la fois le déclencheur technique et le décideur autorisé. Le matériel de restauration nécessite la configuration complète précédente, l’état du fournisseur pertinent et les dépendances connues. La restauration d'un enregistrement DNS ne peut pas restaurer une ressource fournisseur supprimée, annuler le courrier envoyé ou remplacer instantanément les réponses mises en cache. Planifiez la récupération comme un flux de travail coordonné plutôt que de promettre que la copie d'une ancienne valeur annulera toutes les conséquences. Aucun retour en arrière n'a été tenté lors de la préparation de ce projet.
Une feuille de travail d'examen de base
Créez une feuille de calcul avec la version de base, la portée du domaine et du flux de travail, l'objectif commercial, le propriétaire de la configuration, le propriétaire de l'exécution, l'inventaire exact des enregistrements et le chemin d'authentification attendu. Ajoutez des références de preuves avec des dates, des lacunes connues, des versions du document source et des déclencheurs de révision. Pour une révision proposée, incluez la différence prévue, l'approbation commerciale, les conditions préalables, les contrôles de concurrence, les critères de vérification, les critères d'annulation et la disposition finale. Marquez explicitement les résultats non observés plutôt que de les laisser sous-entendre par une revue de conception terminée.
Les déclencheurs d'examen peuvent inclure un nouvel expéditeur, le retrait d'un fournisseur, une migration de domaine, une rotation de clé, un changement de propriétaire d'entreprise ou un incident d'authentification important. Une révision du calendrier peut également être utile, mais sa fréquence doit refléter le risque organisationnel et le volume des changements plutôt qu'un intervalle universel inventé. Vérifiez si la référence couvre toujours tous les workflows légitimes et si les dépendances retirées demeurent. Ne considérez pas un fichier inchangé comme une preuve que l’environnement de production n’a pas dérivé.
Diagnostic fictif : un ajout de fournisseur non documenté
Une organisation fictive dispose d'une base de référence approuvée couvrant son service de facturation et le courrier de ses employés. Une équipe marketing introduit ensuite un autre expéditeur via un fournisseur distinct. La ligne de base reste inchangée, tandis qu'un nettoyage DNS préparé supprimerait une dépendance utilisée par le nouveau service. Dans l'exercice proposé, l'examinateur compare les enregistrements actuels de propriété et de flux de travail avec la référence avant d'approuver le nettoyage et découvre les lacunes dans la documentation.
L'équipe rapprocherait le nouveau flux de travail, obtiendrait l'approbation de l'entreprise, mettrait à jour la différence prévue et collecterait des preuves de vérification après une modification autorisée. Il ne restaurerait pas aveuglément l’ancienne base de référence simplement parce qu’elle avait été approuvée auparavant. Ce scénario est fictif : aucun fournisseur n'a été découvert, aucune différence de configuration n'a été appliquée et aucun test de livraison n'a eu lieu. Il illustre pourquoi l’historique des versions doit être associé à la propriété actuelle et aux observations opérationnelles.
Libérer la ligne de base avec ses limites visibles
Une conclusion utile de l'examen indique quels flux de travail sont couverts, quelles observations les soutiennent et ce qui reste non vérifié. Il ne promet ni une livraison universelle ni une sécurité permanente. Les contrôles d'authentification peuvent être corrects tandis que le contenu, la réputation, la compromission du compte ou la politique du destinataire affectent les résultats du courrier. La ligne de base doit rendre ces limites visibles afin que les futurs opérateurs ne confondent pas un enregistrement de configuration avec une évaluation complète de la sécurité.
Le catalogue nécessite un enregistrement de modification avec des critères de référence, de différence prévue, d'approbation commerciale, de vérification et de restauration. Ce dossier opérationnel original reste ouvert. Ce projet fournit une structure proposée, et non une preuve de changement exécuté. L'examen par un spécialiste humain, l'applicabilité des sources, les itinéraires de production, l'accessibilité visuelle et la libération du propriétaire restent également ouverts. Une version publiable nécessite un exemple autorisé avec de véritables observations et approbations, correctement rédigé et conservé sans révéler de secrets.