A DKIM la clé privée est l'autorité nécessaire pour créer des signatures qui peuvent être vérifiées par rapport à l'enregistrement public correspondant. La protection de l’enregistrement DNS à elle seule ne protège pas cette autorité. Inventoriez les systèmes de signature, les comptes qui peuvent les utiliser et chaque copie opérationnelle du secret avant de décider que la clé est contrôlée.
Identifier la garde plutôt que de l'assumer
Commencez par le fournisseur actuel ou le logiciel de signature. Un service géré peut générer et conserver des clés ; un signataire autonome peut lire un fichier, un magasin secret ou une interface matérielle prise en charge. Ces modèles ont des contrôles d'accès et de récupération différents. Ne promettez pas de protection matérielle, de non-exportabilité ou de rotation gérée par le client à moins que le produit choisi ne le documente et ne le mette en œuvre.
RFC 6376 §8.3 explique la conséquence d'une compromission de clé privée : un intrus peut créer un courrier signé par le domaine qui publie la clé publique correspondante. Il décrit également la valeur d'un serveur de courrier sortant contrôlé qui authentifie les émetteurs et applique des contrôles d'envoi. Les étapes spécifiques de stockage et de révision ci-dessous sont des recommandations opérationnelles et non des exigences universelles du protocole DKIM .
Créez une carte de garde qui expose les copies cachées
Pour chacun sélecteur, enregistrez le domaine de signature, le propriétaire du service, le dépositaire de clé, les nœuds de signature actifs, le chemin de déploiement et le mécanisme de récupération pris en charge. Suivez la référence ou l'identifiant du secret, et non le secret lui-même. Examinez les référentiels de configuration, les étapes de création de conteneurs, les fichiers de déploiement temporaires, les sauvegardes et les ensembles de diagnostics pour détecter les copies involontaires via le processus de gestion des secrets approuvé par l'organisation.
Un exemple synthétique est un cluster de facturation avec deux nœuds de signature et une tâche de déploiement. La clé DNS est publique et attendue. La clé privée est destinée à atteindre uniquement les deux nœuds, mais un ancien pipeline de build l'intègre également dans une image accessible aux projets non liés. Sécuriser les autorisations actuelles des fichiers de nœuds ne supprimerait pas cette ancienne exposition. Examinez le chemin de distribution et traitez un secret potentiellement exposé selon le processus incident.
Ne collez jamais une clé privée dans un champ DNS public, un ticket, un chat ou un vérificateur DKIM public. Lorsque le soutien nécessite des preuves, fournir au public des informations sur le sélecteur et des résultats de diagnostic convenablement contrôlés. Les messages bruts peuvent également contenir du contenu sensible ; minimiser ce qui est partagé et utiliser les canaux approuvés.
Réduisez le nombre de personnes pouvant signer et celles pouvant récupérer des secrets
Utilisez les contrôles de moindre privilège pris en charge par la plateforme pour l'accès à l'administration et à l'exécution. Un compte capable de demander des signatures peut être puissant même s'il ne peut pas exporter la clé. Vérifiez qui peut modifier les identités d'envoi autorisées, envoyer du courrier, effectuer une rotation des clés, déployer la configuration des signataires et récupérer des sauvegardes.
Services séparés avec différents propriétaires ou niveaux de confiance où l'architecture prend en charge des clés et des sélecteurs indépendants. Copier une clé dans chaque application rend un incident plus difficile à évaluer et son retrait plus perturbateur. La haute disponibilité peut légitimement nécessiter une identité de signature partagée, mais cela doit être une conception explicite avec une distribution contrôlée plutôt qu'une conséquence accidentelle d'un fichier de configuration copié.
Tester la récupération sans distribuer le secret
Demandez si une panne est récupérée en restaurant une clé protégée, en générant un remplacement ou en utilisant le chemin de récupération géré par le fournisseur. Testez la procédure prise en charge dans un environnement contrôlé. Enregistrez le temps de récupération, les dépendances DNS et si le courrier en file d'attente utilise toujours l'ancien sélecteur. Ne créez pas de copies de sauvegarde supplémentaires non protégées simplement pour faciliter une analyse.
Consultez les journaux et accédez aux événements disponibles à partir de la plateforme de signature et du système de gestion des secrets. La question utile est de savoir si une modification ou une utilisation non autorisée pourrait être détectée et étudiée, et non si un tableau de bord particulier existe. Documentez les lacunes de journalisation au lieu d’inventer une piste d’audit.
Terminez avec un enregistrement de cycle de vie exploitable
Conservez la carte de garde à côté des procédures de rotation et de compromis. Supprimez les accès obsolètes lorsque le personnel ou les fournisseurs partent, et revérifiez la distribution après des modifications de l'infrastructure. Lors d'une exposition suspectée, coordonnez le confinement de l'accès, un remplacement propre et la vérification des conséquences du retrait de l'ancienne clé. Un fichier actuel protégé n’est qu’une partie d’un cycle de vie de signature contrôlé.
Utilisez une feuille de calcul de décision de garde
Pour chaque identité signataire, enregistrez ces champs non secrets :
- Utilisation : quels comptes de service peuvent soumettre ou demander des signatures, et quelles identités ils peuvent utiliser.
- Récupération : quels rôles peuvent exporter ou restaurer la clé privée et où résident les copies approuvées.
- Modification : qui peut modifier la configuration des signataires, les identités autorisées ou les artefacts de déploiement.
- Récupération : indique si le chemin pris en charge restaure une clé protégée ou génère un remplacement, avec des dépendances DNS et de courrier en file d'attente.
- Preuve : journaux d'accès/signature disponibles, éventuelles lacunes de couverture et propriétaire responsable de l'examen.
Si un ancien artefact de build contient une clé exposée, sécuriser uniquement le nœud actif est insuffisant : définissez l'ancienne exposition et décidez d'un remplacement propre selon les procédures d'incident. Cette feuille de travail constitue un guide de sécurité éditorial et non une affirmation selon laquelle une plateforme particulière fournit ces contrôles.
Lecture connexe
Révoquer une clé DKIM et distinguer la révocation d'un enregistrement DNS manquant · Longueur de la clé DKIM et algorithmes : vérifiez la prise en charge actuelle du récepteur.