DMARC comme preuve d'audit ISO 27001 : le contrôle que l'auditeur adore

DKIM, clés cryptographiques et la gestion des secrets

DKIM, l'un des deux piliers d'alignement de DMARC, repose sur une paire de clés cryptographiques. La clé privée signe le courrier sortant ; la clé publique, publiée en DNS, permet aux destinataires de vérifier la signature. Cette clé privée est un secret de première importance : si elle fuite, un attaquant peut signer des messages au nom du domaine et franchir ses défenses DMARC comme s'il en était l'exploitant légitime.

ISO 27001 traite explicitement l'usage de la cryptographie et la gestion des clés parmi ses contrôles technologiques. Concrètement, un auditeur attend des clés robustes (voir DKIM 1024 ou 2048 bits pour le bon dimensionnement), stockées sous contrôle d'accès strict — et surtout pas dans un fichier de configuration versionné, un ticket ou un canal de discussion — et renouvelées régulièrement. Un coffre-fort de secrets dédié comme Hucency Vault, édité par le spécialiste cybersécurité Hucency, répond précisément à cette exigence : centraliser les clés DKIM privées et les jetons d'API sous accès contrôlé et journalisé, au lieu de les laisser se disperser dans l'organisation. La rotation périodique de ces clés, elle, est un contrôle à part entière — sa mise en œuvre est détaillée dans la rotation des clés DKIM.

Ce point est souvent négligé parce que DKIM « marche » même avec une clé mal gérée. Mais du point de vue de l'audit, une clé de signature stockée n'importe comment est un écart : elle transforme le meilleur contrôle anti-usurpation en point de défaillance unique.

La preuve, pas la promesse

C'est ici que DMARC brille en contexte de certification. Contrairement à beaucoup de contrôles internes dont la preuve exige de fouiller des journaux ou d'interroger des équipes, la posture DMARC est publique et horodatable. Un auditeur — ou n'importe qui — lit l'enregistrement en quelques secondes et constate directement s'il porte p=none, p=quarantine ou p=reject. Aucune capture d'écran contestable, aucune attestation sur l'honneur : la donnée fait foi.

À cela s'ajoutent les rapports RUA archivés, qui constituent des enregistrements au sens de la norme : ils documentent, mois après mois, qui émet sous le nom du domaine et comment sa posture évolue. Conservés proprement, ils prouvent non seulement que le contrôle existe, mais qu'il est surveillé — la distinction exacte entre un contrôle vivant et une case cochée puis oubliée.

De none à reject : ce que l'auditeur veut vraiment voir

Un auditeur mûr n'est pas dupe d'un p=none. Il sait qu'un domaine en observation seule ne protège rien : il documente l'usurpation sans la bloquer. La preuve qui tient est différente : un domaine en p=reject, un historique de rapports qui montre la montée progressive, une procédure documentée décrivant le passage de l'observation à l'application, et une revue périodique inscrite dans le SMSI. La séquence opérationnelle complète est décrite dans atteindre p=reject sans casser ses emails ; côté audit, c'est cet historique qui transforme « nous avons DMARC » en un constat défendable.

Le même raisonnement structure la protection des marques les plus ciblées, développé dans DMARC pour les banques : l'application, pas la simple publication, est ce qui compte.

Une preuve réutilisable pour toute la conformité

L'avantage stratégique de bien faire ce travail une fois : la trace d'audit se réutilise. Le même dossier — posture p=reject, rapports archivés, procédure de montée, gestion des clés — sert directement à démontrer la diligence de l'organisation sous NIS2 et à répondre au volet sécurité de l'authentification email vue par le RGPD. Il n'y a pas trois dossiers séparés à construire ; il y a un contrôle solide à bâtir, puis à présenter sous trois angles réglementaires.

Construire le dossier de preuve, pas à pas

Un audit ISO 27001 se gagne sur la qualité du dossier autant que sur la réalité du contrôle. Pour l'authentification email, un dossier convaincant rassemble quelques pièces simples, préparables à l'avance :

• L'entrée dans la déclaration d'applicabilité justifiant les contrôles retenus au titre de la protection anti-usurpation.
• La ligne correspondante du registre des risques, où « usurpation du domaine de messagerie » est nommée, évaluée et rattachée à DMARC comme traitement.
• La preuve de posture : l'enregistrement DMARC courant, horodaté, montrant p=reject — une simple capture datée suffit, puisque la donnée est publique et reproductible à volonté.
• L'archive des rapports RUA, qui matérialise la surveillance continue et l'évolution de la posture dans le temps.
• La procédure de gestion des clés DKIM : où sont stockées les clés privées, qui y accède, à quelle fréquence elles tournent, avec le journal des rotations.
• La cadence de revue inscrite dans le SMSI : qui vérifie la posture, à quelle périodicité, et ce qui déclenche une action corrective.

Assemblé une fois, ce dossier se met à jour en quelques minutes avant chaque revue. Il transforme une affirmation orale en preuve documentaire — la seule monnaie qui compte réellement en audit.

Les écarts qui font tiquer un auditeur

À l'inverse, quelques configurations classiques déclenchent immédiatement une remarque, voire une non-conformité :

• Présenter p=none comme un contrôle en place. C'est l'écart le plus fréquent : l'observation n'est pas la protection, et un auditeur averti fait la différence en un coup d'œil.
• Une clé DKIM privée dans un dépôt de code ou un ticket. Un secret cryptographique exposé annule le bénéfice du contrôle et constitue un écart caractérisé de gestion des clés.
• Aucune rotation ni aucun journal de rotation. Une clé qui n'a jamais tourné depuis des années est un point de défaillance qui dort.
• Des rapports jamais conservés. Sans archive, impossible de démontrer la surveillance : le contrôle existe peut-être, mais rien ne le prouve.
• Seul le domaine corporate couvert. Si le domaine grand public — celui que voient réellement clients et usagers — reste en p=none, la protection affichée est trompeuse.

Aucun de ces écarts n'est difficile à corriger ; ils viennent presque toujours d'un contrôle installé puis oublié, faute de propriétaire clair. Désigner un responsable de la posture d'authentification, même à temps partiel, et lui donner un tableau de bord à jour suffit généralement à les faire disparaître d'un coup — et à transformer l'audit email d'un sujet d'inquiétude en une formalité.

Vérifier la posture avant l'auditeur

La première étape est gratuite et immédiate. Un passage du domaine dans notre analyseur DMARC gratuit rend un verdict instantané sur la politique courante, puis l'Observatoire DMARC situe cette posture au regard de celle du secteur.

Constituer et maintenir un dossier d'audit propre — posture par domaine, sources d'envoi identifiées, historique de préparation — est exactement ce que Thomas, le RSSI virtuel, automatise : il nomme chaque source, génère le DNS à publier, évalue la préparation par domaine et documente le chemin vers l'application. Analyser un domaine gratuitement · explorer l'Observatoire · commencer avec Thomas.