Directives relatives à l'authentification par e-mail

!! ATTENTION !! Ce document a été traduit automatiquement de l'italien

Lignes directrices

Configuration du service de messagerie pour l'authentification

L'Agence nationale italienne pour la cybersécurité a publié des lignes directrices relatives à la configuration du service de messagerie électronique en matière d'authentification, dans le but de renforcer la fiabilité de ce service pour toutes les organisations concernées et d'améliorer son niveau global de sécurité.

Contrôle de version

INDEX

1. Introduction

1.1. Prémisse

Le courrier électronique représente aujourd'hui l'un des services les plus essentiels dans le contexte numérique, car il figure parmi les principaux canaux utilisés par les organisations et les utilisateurs pour communiquer et échanger des informations¹.

Le fonctionnement du service de messagerie électronique, et en particulier la transmission des messages, repose sur le protocole SMTP qui, toutefois, ne dispose pas en soi de mécanismes suffisants pour l'authentification de l'expéditeur ni pour la protection de la confidentialité et de l'intégrité des messages. Ces failles l'exposent à des risques d'attaques telles que l'usurpation d'identité, le phishing, la falsification et l'interception de messages pendant leur transit.

Afin de pallier les faiblesses du protocole SMTP et, par conséquent, de réduire les risques liés aux attaques susmentionnées, des mécanismes d'authentification de l'expéditeur et de protection de l'intégrité des messages ont été mis au point au fil du temps, tels que le SPF (Sender Policy Framework), le DKIM (DomainKeys Identified Mail) et le DMARC (Domain-based Message Authentication, Reporting and Conformance).

Ces directives illustrent ces mécanismes dans le but de renforcer la fiabilité du service de messagerie électronique et d'améliorer son niveau global de sécurité, en particulier au regard des menaces décrites au chapitre 4.

Les mesures et protocoles nécessaires à la protection de la confidentialité des messages électroniques (tels que S/MIME et OpenPGP, qui concernent le chiffrement des messages) ne font pas l'objet des présentes lignes directrices.

1.2. Réglementations de référence

1.3. Documents de référence

» Retour en haut de la page

2. Cadre réglementaire

Afin de protéger les ressources numériques du pays, notamment les services de messagerie électronique et les infrastructures qui les hébergent, un ensemble complet de mesures de sécurité, fondées sur la législation en vigueur, a été mis en place et fait l'objet d'une mise à jour constante.

Le niveau de protection le plus élevé pour les services les plus critiques du pays, liés à la protection de la sécurité nationale, est assuré par le périmètre national de cybersécurité, institué par le décret-loi n° 105 du 21 septembre 2019, converti avec modifications par la loi n° 133 du 18 novembre 2019. Celui-ci prévoit des mesures de sécurité offrant des niveaux de protection particulièrement élevés, détaillées à l'annexe B du décret du Premier ministre du 14 avril 2021, n° 81, qui s’appliquent aux réseaux, aux systèmes d’information et aux services informatiques des entités publiques et privées dont dépend l’exercice d’une fonction essentielle de l’État ou la fourniture d’un service essentiel au maintien des activités civiles, sociales ou économiques fondamentales pour les intérêts de l’État, et dont la compromission pourrait porter atteinte à la sécurité nationale.

En outre, les services de messagerie électronique, à l'instar de tous les services numériques de l'administration publique, sont soumis aux dispositions du « règlement sur le cloud », adopté en vertu de l'article 33-septies du décret-loi n° 179 du 18 octobre 2012 et mis à jour par l'Agence nationale de cybersécurité (ACN) par le décret n° 21007 du 27 juin 2024. En vertu du règlement susmentionné, toutes les administrations publiques sont tenues de classer leurs données et services numériques en trois catégories : ordinaires, critiques ou stratégiques, selon le modèle élaboré par l’ACN. Cette activité vise à garantir que les données et services numériques de l’administration publique soient traités et fournis par le biais d’infrastructures numériques et de services cloud répondant aux exigences, y compris en matière de sécurité, adaptées aux risques associés au niveau de classification correspondant, comme le précise le règlement.

Le décret législatif n° 138 du 4 septembre 2024 (dit «décret NIS»), transposant la directive (UE) 2022/2555, a également défini – par le biais des annexes 1 et 2 de la décision ACN n° 379907/2025 – les mesures de sécurité de base que les entités essentielles et importantes doivent adopter aux fins des obligations prévues aux articles 23 et 24 du décret NIS, définissant un cadre de sécurité visant à renforcer la protection des réseaux et des systèmes d'information, y compris les services de messagerie électronique.

» Retour en haut de la page

3. Architecture du service de messagerie électronique

Comme indiqué dans l'introduction, le fonctionnement du service de messagerie repose sur le protocole SMTP, qui régit la transmission des messages électroniques de l'expéditeur au destinataire.

Le protocole SMTP a été défini pour la première fois en 1982² comme un protocole de stockage et de retransmission, dans lequel l'expéditeur génère un message via son client de messagerie, appelé dans le jargon Mail User Agent (MUA), qui l'envoie au serveur de messagerie de l'expéditeur. Celui-ci, via un composant appelé Mail Transfer Agent (MTA), transfère le message, éventuellement via un ou plusieurs MTA intermédiaires, pour le livrer au MTA du serveur de messagerie de destination. L'utilisateur destinataire accède au message via son client de messagerie (MUA)[1].

Le MTA est donc un composant du service de messagerie électronique qui gère la transmission des messages électroniques de l'expéditeur au destinataire. Des composants MTA sont présents sur les serveurs de messagerie de l'expéditeur et du destinataire, et il est également possible de configurer des MTA intermédiaires, par exemple pour gérer des listes de diffusion.

Bien que le terme MTA désigne un composant spécifique des serveurs de messagerie³, étant donné que, dans le cadre du présent document, il est fait référence à ces derniers principalement dans leur fonction de MTA, et qu’il n’y a pas d’ambiguïté, par souci de simplicité d’exposé, le terme « serveur de messagerie » sera souvent utilisé à la place du terme plus spécifique « MTA ».

Dans ce guide, nous nous concentrons sur la configuration des protocoles SPF, DKIM et DMARC afin de permettre aux serveurs de messagerie de vérifier l'authenticité et l'intégrité des e-mails.

» Retour en haut de la page

4. Menaces

Le protocole SMTP présenté dans le chapitre précédent avait initialement été conçu pour fonctionner au sein d'un réseau universitaire de taille relativement modeste et ne tenait pas compte des aspects liés à la sécurité des messages transmis ni à l'authentification de l'expéditeur [1].

La généralisation croissante du courrier électronique et les faiblesses intrinsèques du protocole SMTP ont favorisé, au fil du temps, l'apparition d'attaques dont les principaux types sont brièvement présentés dans les paragraphes suivants.

4.1. Usurpation d'identité de l'expéditeur

L'usurpation d'identité est une technique de cyberattaque qui consiste à falsifier l'adresse de l'expéditeur d'un message afin de faire croire que celui-ci provient d'une source fiable (comme, par exemple, celle d'un collègue, d'une connaissance ou de sa propre banque), dans le but d'inciter le destinataire à effectuer des actions potentiellement dangereuses, telles que l'ouverture d'une pièce jointe ou le clic sur des liens contenus dans le message.

Ce type d'attaque est relativement simple à mettre en œuvre, car le protocole SMTP ne prévoit pas de mécanismes d'authentification de l'expéditeur ; il est donc possible, via le client de messagerie, de configurer n'importe quelle adresse d'expéditeur lors de la création du message.

Adresse e-mail de l'expéditeur : envelope-from et message-from

Le format des e-mails prévoit deux champs distincts pour indiquer l'adresse e-mail de l'expéditeur. Ces champs sont appelés « envelope-from » et « message-from »: le premier (également appelé « return-path » car il spécifie l'adresse e-mail à laquelle doivent être envoyés les messages d'erreur générés lorsqu'un e-mail n'atteint pas son destinataire) est l'adresse utilisée pour acheminer correctement le message, tandis que le second est l'adresse qui s'affiche dans l'en-tête du message reçu par le destinataire.

Si l'on fait une analogie avec l'envoi d'une lettre dans une enveloppe par la poste traditionnelle, le champ « envelope-from » correspond à l'adresse de l'expéditeur figurant sur l'enveloppe, tandis que le champ « message-from » correspond à l'en-tête de la lettre qui indique qui s'est adressé au destinataire.

Il est important de noter que ces deux adresses ne coïncident pas nécessairement. Cette distinction permet de gérer des situations telles que, par exemple, le transfert de messages provenant de services tiers, la diffusion via des listes de diffusion ou les réponses automatiques par e-mail.

Il est en effet possible d'indiquer n'importe quel expéditeur, tant au niveau « message-from » (adresse e-mail de l'expéditeur telle qu'elle apparaît pour le destinataire dans l'en-tête du message reçu) qu'au niveau « envelope-from » (adresse e-mail de l'expéditeur utilisée pour la transmission du message).

Pour faire face à ces menaces, il est donc essentiel de mettre en place des mécanismes permettant d'authentifier de manière fiable l'expéditeur et de vérifier que la personne qui a envoyé le message est bien habilitée à le faire.

4.2. Hameçonnage

Le phishing est une technique de cyberattaque visant à obtenir frauduleusement des informations (telles que, par exemple, des identifiants de connexion, des numéros de carte de crédit ou d'autres données sensibles), généralement en envoyant des messages trompeurs qui semblent provenir d'expéditeurs fiables³.

L'usurpation d'identité, abordée dans le paragraphe précédent, fait partie des principales techniques utilisées par un pirate pour falsifier l'identité de l'expéditeur et faire croire que le message provient d'un utilisateur ou d'un domaine légitime.

Il est également possible d'utiliser une adresse ou un domaine d'expéditeur similaire à celui que le destinataire est susceptible de reconnaître, en modifiant, par exemple, ce qu'on appelle le « nom d'affichage »⁴ afin de renforcer l'authenticité apparente du message.

Pour envoyer des messages de hameçonnage, il est également possible d'utiliser des comptes légitimes qui ont déjà été piratés par le cybercriminel.

Un message de phishing contient généralement un contenu conçu pour susciter un sentiment d'urgence, d'inquiétude ou d'intérêt financier chez le destinataire, créant ainsi des situations qui l'incitent à réagir de manière impulsive et à effectuer des actions spécifiques, telles que l'ouverture de pièces jointes malveillantes ou le clic sur des liens redirigeant vers des sites web apparemment légitimes, mais qui, en réalité, ont été créés par le pirate dans le but de voler des informations et/ou d'installer des logiciels malveillants.

En général, les attaques par hameçonnage consistent à envoyer le même message électronique à un grand nombre de victimes, sans adapter le texte au profil spécifique de chacune d'entre elles.

Une variante du phishing est ce qu'on appelle le « spear phishing », dans lequel le pirate connaît le profil de la victime et la cible spécifiquement.

Contrairement à un e-mail de phishing classique, un message de spear phishing utilise des informations contextuelles plus précises pour convaincre l'utilisateur qu'il est en contact avec un expéditeur fiable [2].

4.3. Falsification de messages

Le contenu d'un e-mail, comme toute autre communication transitant par le réseau Internet qui n'utilise pas de techniques de chiffrement de bout en bout (E2EE), peut être intercepté et modifié pendant son acheminement entre l'expéditeur et le destinataire (un type de menace communément appelé « attaque de l'homme du milieu »).

Par conséquent, outre la perte de confidentialité, le message reçu pourrait ne pas correspondre à celui rédigé à l'origine par l'expéditeur.

Un pirate pourrait, par exemple, manipuler le contenu du message pour le faire passer pour provenant d'un expéditeur de confiance, modifier le texte ou les liens et/ou pièces jointes présents dans le message, ou encore y insérer du code malveillant.

Le destinataire, convaincu de l'authenticité apparente du message, peut ainsi être amené à effectuer des actions potentiellement dangereuses, telles que communiquer ses identifiants de connexion, autoriser des paiements ou ouvrir des fichiers malveillants.

Pour faire face à ces menaces, il est donc essentiel de mettre en place des mécanismes garantissant l'intégrité et l'authenticité du message, afin de s'assurer que le contenu reçu n'a pas été modifié et que l'expéditeur est bien celui qu'il prétend être.

» Retour en haut de la page

5. Mesures de lutte

Le chapitre 2 a rappelé les dispositions réglementaires qui prévoient des mesures de sécurité visant également à protéger les services de messagerie électronique. Le présent document a pour objectif principal de fournir un guide pour la mise en œuvre des mesures de sécurité prévues par ces réglementations et présentées à l'annexe A, qui s'appliquent également à la configuration des services de messagerie électronique, afin d'atténuer les risques liés aux menaces évoquées au chapitre 4. Il convient toutefois de noter que les indications contenues dans ces lignes directrices sont également recommandées aux entités qui ne sont pas soumises aux réglementations susmentionnées.

Les mesures de sécurité en question ne font pas explicitement référence à la configuration du service de messagerie électronique, mais – selon la réglementation considérée – à la configuration des systèmes informatiques et des systèmes de contrôle industriel (PSNC et règlement sur le cloud) ou des systèmes d'information et de réseau (NIS2). Les services de messagerie électronique, qui font l'objet des présentes lignes directrices, relèvent de ces deux types de systèmes.

Les protocoles SPF, DKIM et DMARC, présentés ci-dessous, constituent notamment des mécanismes de sécurité conçus pour renforcer la sécurité globale du service de messagerie électronique, et plus particulièrement l'authentification de l'expéditeur et le contrôle de l'intégrité des messages.

5.1. SPF

SPF (Sender Policy Framework) est un protocole d'authentification, défini par la norme RFC 7208, qui permet au propriétaire d'un domaine de spécifier quelles adresses IP sont autorisées à envoyer des e-mails en son nom et de définir les règles que le destinataire doit appliquer si l'adresse IP associée au domaine⁵ de l'adresse e-mail de l'expéditeur ne figure pas parmi celles explicitement autorisées.

Les adresses IP autorisées sont répertoriées dans un enregistrement DNS de type TXT associé au domaine de l'expéditeur, appelé enregistrement SPF, et présenté dans la section suivante de ce paragraphe.

De cette manière, le serveur de messagerie du destinataire⁶ , lorsqu’il reçoit un message provenant d’un domaine donné, peut interroger l’enregistrement SPF correspondant et authentifier son origine en vérifiant que l’adresse IP d’où provient le message figure parmi celles autorisées à envoyer des messages au nom de ce domaine.

Il est important de noter que le domaine vérifié au niveau du SPF est celui associé au champ « envelope-from » ; par conséquent, l'adoption du protocole SPF à elle seule ne suffit pas à contrer l'usurpation d'identité, car ce type d'attaque pourrait être mené au niveau du champ « message-from »⁷.

Si une organisation externalise, en tout ou en partie, son service de messagerie électronique à un tiers, tel qu'un fournisseur de services cloud, elle doit s'assurer que les messages envoyés par ces fournisseurs satisfont aux vérifications SPF. À cette fin, l'organisation doit inclure dans son enregistrement SPF les adresses IP à partir desquelles les fournisseurs envoient des e-mails au nom du domaine de l'organisation.

Dans le cas du transfert automatique d'e-mails, les messages étant généralement redirigés par un serveur intermédiaire, l'adresse IP effectuant la livraison finale ne correspond plus à celle initialement autorisée par le domaine de l'expéditeur. Dans ces cas, afin d'éviter l'échec de la vérification SPF, il est nécessaire d'autoriser également tous les serveurs de transfert intermédiaires, ou de recourir à des mécanismes tels que le SRS (Sender Rewriting Scheme) ou l'ARC (Authenticated Received Chain), qui peuvent s'avérer plus efficaces, en particulier en présence de nombreux serveurs de transfert intermédiaires.

Il convient de souligner que, pour que le SPF soit réellement efficace, il doit être correctement configuré non seulement par l'expéditeur, mais aussi par le destinataire. En particulier :

• l'expéditeur doit publier l'enregistrement SPF sur le serveur DNS correspondant, en indiquant les adresses autorisées à envoyer des e-mails en son nom ;
• le destinataire doit configurer son propre serveur de messagerie de manière à ce qu'il effectue une vérification SPF sur les messages reçus et applique de manière cohérente les politiques qui en découlent.

5.1.1. Enregistrement SPF

Un enregistrement SPF est un enregistrement DNS de type TXT dont le nom correspond au domaine de l'expéditeur et dont le contenu est constitué⁸ par la partie indiquant la version⁹ et d’une série de directives qui indiquent le comportement du serveur de messagerie du destinataire lorsqu’il y a une correspondance entre l’adresse IP du domaine de l’expéditeur et une directive.

Les directives sont constituées d'un mécanisme précédé d'un qualificatif. Les principaux mécanismes utilisés dans les enregistrements SPF sont les suivants [2]:

• ip4, répertorie les adresses IPv4 autorisées ;
• ip6, répertorie les adresses IPv6 autorisées ;
• a) autorise les adresses IP figurant dans l'enregistrement A du domaine ;
• mx, autorise les adresses IP associées aux enregistrements MX du domaine ;
• inclut, autorise les adresses IP présentes dans l'enregistrement SPF d'un autre domaine ;
• en somme, désigne toutes les adresses IP qui n'ont pas été explicitement autorisées par le biais des autres mécanismes.

En particulier, le tout Ce mécanisme permet de définir des règles pour les messages provenant d'adresses IP qui n'ont pas été déclarées par les mécanismes précédents.

De plus, SPF propose les qualificatifs suivants à associer aux mécanismes :

• + (autoriser) indique que les adresses IP correspondant au mécanisme associé sont autorisées. Il s'agit du qualificateur par défaut si aucun autre n'est spécifié ;
• - (échec) indique que les adresses IP correspondant au mécanisme associé ne sont pas autorisées ;
• ~ (softfail) indique que les adresses IP correspondant au mécanisme associé ne sont probablement pas autorisées. Il s'agit d'une déclaration plus incertaine que la précédente. Dans ces cas, le message doit être accepté mais marqué pour une analyse plus approfondie ; cette indication est utilisée, par exemple, lors du débogage ou lorsqu'il est prévisible que la vérification SPF risque d'échouer ;
• ? (neutre) indique qu'aucune indication n'est fournie pour les adresses IP correspondant au mécanisme associé. Par défaut, le message est accepté.

Il convient de souligner qu'en pratique, l'enregistrement SPF est configuré pour spécifier les adresses IP autorisées, en recourant ensuite à la directive -tout pour préciser que toutes les autres adresses ne sont pas autorisées (à ce sujet, veuillez vous reporter aux exemples ci-dessous). Il s'agit de la configuration recommandée, car elle permet d'indiquer explicitement les adresses IP autorisées et d'exclure toutes les autres.

Dans tous les cas, il est recommandé de ne jamais utiliser la directive +tout (ou l'équivalent tout) car cela reviendrait à autoriser toutes les adresses IP.

Exemples d'enregistrements SPF

Autoriser une adresse IP spécifique

v=spf1 ip4:203.0.113.0 -all

L'enregistrement SPF ci-dessus utilise la version 1 du protocole SPF et autorise l'accès via le ip4 mécanisme de l'adresse IP 203.0.113.0 (en effet, comme aucun qualificatif n'est spécifié pour le ip4 mécanisme, la valeur par défaut + est utilisé implicitement). Le -tout directive élaborée par le tout mécanisme et le - Le qualificatif « (fail) » indique que toutes les autres adresses ne sont pas autorisées.

Autoriser un espace d'adresses IP spécifique

v=spf1 ip4:203.0.113.0/24 -all

L'enregistrement SPF ci-dessus est similaire au précédent, mais autorise toutes les adresses IP du 203.0.113.0/24 espace d'adressage.

Autoriser plusieurs adresses IP

v=spf1 ip4:203.0.113.22 ip4:203.0.113.44 -all

L'enregistrement SPF ci-dessus autorise exclusivement les adresses IPv4 203.0.113.22 et 203.0.113.44.

Autoriser les adresses des enregistrements MX et un domaine spécifique

v=spf1 mx include:spf.emailprovider.it -all

L'enregistrement SPF ci-dessus autorise exclusivement les adresses IP des enregistrements MX du même domaine que celui de l'enregistrement SPF, ainsi que celles autorisées pour ce domaine. spf.emailprovider.it (par exemple, le nom de domaine d'un fournisseur de messagerie électronique).

5.1.2. Processus d'authentification

S'il est correctement configuré pour effectuer la vérification SPF, le serveur de messagerie du destinataire, dès qu'il reçoit un nouveau message électronique, récupère l'enregistrement SPF du domaine de l'expéditeur en interrogeant le serveur DNS qui héberge les enregistrements de ce domaine, tel qu'il ressort de l'adresse indiquée dans le champ « envelope-from ». Par exemple, si l'adresse indiquée dans le champ « envelope-from » est alice@example.com, le serveur de messagerie du destinataire récupère l'enregistrement SPF du domaine exemple.com.

Le serveur de messagerie du destinataire procède alors à la vérification SPF, en analysant l'enregistrement SPF afin de déterminer si l'adresse IP à partir de laquelle il a reçu le message est autorisée à envoyer des e-mails pour le exemple.com domaine. Si le message électronique passe la vérification SPF, il est remis au destinataire.

Par exemple, si l'enregistrement SPF du exemple.com le domaine était v=spf1 ip4:203.0.113.22 -all la vérification ne serait validée que si l'adresse IP du serveur expéditeur était 203.0.113.22, alors qu'il échouerait pour toute autre adresse.

» Retour en haut de la page

5.2. DKIM

DKIM (DomainKeys Identified Mail) est un protocole d'authentification, défini par la norme RFC 6376, qui permet au propriétaire d'un domaine de garantir l'authenticité des messages électroniques envoyés en y apposant une signature numérique (signature DKIM) générée par le serveur de messagerie à l'aide d'algorithmes de cryptographie à clé publique, puis insérée dans les en-têtes du message à transmettre.

Afin de permettre au destinataire de vérifier que le message n'a pas été modifié pendant la transmission, la clé publique associée à la signature DKIM est enregistrée dans un enregistrement TXT du DNS public du domaine de l'expéditeur, appelé « enregistrement DKIM », que le serveur de messagerie du destinataire interroge à la réception du message.

La signature DKIM et l'enregistrement correspondant sont présentés dans les sections suivantes de ce paragraphe.

Tout comme pour le SPF, le DKIM doit également être correctement configuré par l'expéditeur et le destinataire, notamment :

• l'expéditeur doit configurer son serveur de messagerie pour générer des signatures DKIM et publier l'enregistrement DKIM sur le serveur DNS correspondant ;
• le destinataire doit configurer son serveur de messagerie de manière à ce qu'il effectue une vérification DKIM sur les messages reçus.

5.2.1. Signature DKIM

La signature DKIM est générée à partir d'éléments spécifiques du corps et des en-têtes du message et se compose d'une série de paires clé-valeur qui spécifient divers éléments, parmi lesquels :

• v: version du protocole¹⁰;
• a: algorithme de chiffrement utilisé¹¹;
• d: signature du domaine attestant de l'authenticité du message¹²;
• s: sélecteur indiquant quelle clé publique DKIM rechercher dans l'enregistrement DNS¹³;
• h: liste des en-têtes d'e-mail inclus dans la signature¹⁴;
• bh: hachage du corps du message encodé au format Base64¹⁵;
• b: signature numérique effective générée à l'aide de la clé privée et encodée au format Base64¹⁶;
• x: date de validité de la signature ;
• c: type de canonicalisation.

La canonisation est le processus qui consiste à normaliser les éléments d'un message avant sa signature numérique afin de réduire l'impact des petites modifications pouvant survenir pendant le transit, telles que les espaces répétés ou les sauts de ligne. Il existe deux types de canonisation : la canonisation simple, qui exige une correspondance exacte entre le message d'origine et le message reçu, et la canonisation assouplie, qui applique des normalisations telles que la suppression des espaces, la conversion des majuscules en minuscules dans les en-têtes et la réduction des lignes vides consécutives dans le corps du message.

5.2.2. Enregistrement DKIM

L'enregistrement DKIM est stocké dans un enregistrement DNS de type TXT dont le nom suit la structure suivante selector._domainkey.domain, où _domainkey est une balise utilisée pour indiquer que l'enregistrement DNS est bien un enregistrement DKIM. Le contenu de l'enregistrement DKIM se compose d'une série de paires clé-valeur spécifiant divers éléments, parmi lesquels :

• v: version du protocole ;
• k: type de clé, qui est par défaut RSA ;
• p: clé publique encodée au format Base64.

Exemple d'enregistrement DKIM

Nom : s1._domainkey.example.com
Valeur : v=DKIM1 ; k=rsa ; p=Y2hpYXZ1cHViYmxpY2FkaWVzZW1waW8h...

L'exemple d'enregistrement DKIM est associé au sélecteur s1 de la exemple.com domaine, utilise la version 1 et contient la clé publique RSA encodée au format base64 (Y2hpYXZ1cHViYmxpY2FkaWVzZW1waW8h...).

5.2.3. Processus d'authentification

Si le protocole DKIM est correctement configuré à la fois sur le serveur de messagerie de l'expéditeur et sur celui du destinataire, le fonctionnement du processus d'authentification et de vérification DKIM prévoit que le serveur de messagerie de l'expéditeur génère la signature DKIM du message, comme décrit au paragraphe 5.2.1, laquelle est ajoutée au message lui-même. En particulier, la signature DKIM contient dans le d indiquer le domaine de signature¹⁷ et dans le b insérer la signature numérique du message générée à l'aide de la clé privée du domaine signataire.

À la réception d'un message, le serveur de messagerie destinataire récupère l'enregistrement DKIM du domaine signataire (d champ de la signature DKIM) provenant du serveur DNS contenant les enregistrements de ce domaine. Il utilise ensuite la clé publique contenue dans l'enregistrement DKIM pour vérifier la signature numérique (b (champ) contenu dans la signature DKIM. Si la vérification aboutit, le message est remis au destinataire.

5.2.4. Aspects cryptographiques

En matière de cryptographie, le protocole DKIM a toujours utilisé l'algorithme RSA, notamment dans sa variante rsa-sha256, considérée comme la norme depuis 2007. La nouvelle alternative, introduite par la RFC 8463, est Ed25519-SHA256, une forme moderne de signature numérique basée sur les courbes elliptiques qui garantit une plus grande efficacité et des clés bien plus compactes.

Sur le plan technique, le RSA, avec une longueur de clé de 2048 bits, reste la norme universelle, mais les clés sont longues et les signatures relativement volumineuses, tandis qu’Ed25519 propose des clés neuf fois plus courtes et des signatures quatre fois plus petites, avec des performances de signature jusqu’à trente fois supérieures à celles du RSA 2048. Malgré ces avantages, la prise en charge dans la pratique est limitée : en 2026, Ed25519 n'est vérifié que par quelques fournisseurs, tandis que certains opérateurs majeurs ne prennent en charge de manière fiable ni la signature ni la vérification, ce qui le rend inadapté en tant que solution unique en production.

C'est pourquoi, bien qu'il soit techniquement supérieur, au moment de la rédaction du présent document, l'utilisation d'Ed25519 n'est pas recommandée, sauf en combinaison avec RSA, via une double signature, à des fins expérimentales et dans une optique de compatibilité future. Tant que les principaux fournisseurs n'auront pas pleinement mis en œuvre sa vérification, RSA reste indispensable pour garantir une fiabilité maximale dans la transmission des messages.

En ce qui concerne la sécurité à long terme, il est important de garder à l'esprit que ni RSA ni Ed25519 ne sont résistants aux attaques des futurs ordinateurs quantiques [3], et que la transition vers des algorithmes post-quantiques nécessitera de nouvelles normes DKIM qui n'existent pas encore à l'heure actuelle ; il est donc essentiel de suivre de près les avancées en matière de cryptographie de nouvelle génération ainsi que les futures recommandations de l'ACN dans ce domaine.

En ce qui concerne la gestion des clés cryptographiques, la clé privée DKIM doit être protégée par des mesures de sécurité rigoureuses : elle doit être conservée sur des systèmes isolés, accessibles uniquement aux services autorisés, et faire l'objet de permissions restrictives, d'une rotation périodique et d'une surveillance constante afin d'empêcher tout accès non autorisé ou toute compromission.

» Retour en haut de la page

5.3. DMARC

DMARC (Domain-based Message Authentication, Reporting and Conformance) est un protocole d'authentification, défini par la RFC 7489, qui intègre¹⁸ les mécanismes SPF et DKIM, permettant au propriétaire d'un domaine de définir, à l'intention des destinataires des messages transmis depuis ce domaine, les politiques de gestion des messages qui échouent aux vérifications SPF et DKIM.

En particulier, DMARC introduit un mécanisme d'authentification – appelé « alignement » – qui vérifie la correspondance entre les domaines authentifiés par SPF et DKIM et le domaine associé à l' message-de champ du message reçu. Notez que la vérification de l'alignement entre le message-de et le domaine SPF/DKIM échoue dans tous les cas si la vérification SPF/DKIM correspondante échoue (voir figure 4).

L'alignement peut être vérifié dans strict mode dans lequel une correspondance exacte est requise entre les domaines authentifiés par SPF/DKIM et celui associé au message-de champ, ou détendu, où il suffit que les domaines principaux correspondent, même si les sous-domaines peuvent être différents.

Par exemple, dans détendu mode pour les domaines sub1.exemple.com et sub2.exemple.com une correspondance serait trouvée à des fins de vérification DMARC (puisque le domaine principal, exemple.com, c'est la même chose). Dans strict En mode normal, cependant, la vérification de l'alignement DMARC échouerait en raison de l'absence de correspondance exacte entre les domaines.

Grâce à la vérification de l'alignement, même si un pirate parvenait à passer les contrôles SPF et/ou DKIM en utilisant un message-de différent de expéditeur même si le message est authentifié par SPF et/ou provient du domaine de signature authentifié, DMARC détecterait tout de même cette divergence, garantissant ainsi une vérification cohérente et fiable de l'identité de l'expéditeur [2].

Les politiques de gestion des messages ayant échoué¹⁹ sont spécifiées dans un enregistrement TXT du serveur DNS relatif du domaine de l'expéditeur, appelé enregistrement DMARC, et illustrées dans la section suivante de ce paragraphe.

DMARC permet également de demander aux destinataires d'envoyer des rapports aux propriétaires du domaine expéditeur concernant les messages prétendant provenir de ce domaine. De cette manière, le propriétaire du domaine peut vérifier si son domaine est utilisé de manière non autorisée et dans quelle mesure, en analysant, par exemple, combien de messages sur l'ensemble de ceux prétendant provenir de ce domaine peuvent effectivement lui être attribués.

Tout comme pour SPF et DKIM, DMARC doit également être correctement configuré par l'expéditeur et le destinataire, et notamment :

• l'expéditeur doit publier l'enregistrement DMARC dans son DNS en précisant les règles à appliquer pour gérer les messages qui échouent à la vérification DMARC ;
• le destinataire doit configurer son serveur de messagerie pour qu'il effectue une vérification DMARC sur les messages reçus.

5.3.1. Enregistrement DMARC

Le nom de l'enregistrement DMARC a la structure suivante _dmarc.domaine, où _dmarc est une balise utilisée pour indiquer que l'enregistrement DNS est un enregistrement DMARC et domaine est le domaine auquel se rapporte la politique.

L'enregistrement DMARC se compose d'une série de paires clé-valeur définissant divers éléments, parmi lesquels :

• v: version du protocole DMARC²⁰;
• p: politique à appliquer aux messages qui échouent à la vérification DMARC ; peut prendre l'une des valeurs suivantes aucun, quarantaine, refuser;
• aspf: mode d'alignement à appliquer au contrôle SPF (peut être détendu, valeur par défaut, ou strict);
• adkim: mode d'alignement à appliquer au contrôle DKIM (peut être détendu, valeur par défaut, ou strict);
• rua: adresses e-mail auxquelles envoyer des rapports agrégés contenant des informations statistiques et récapitulatives sur les messages reçus provenant du domaine de l'expéditeur ;
• ruf: adresses e-mail auxquelles envoyer des rapports détaillés sur les messages individuels reçus du domaine de l'expéditeur qui n'ont pas passé la vérification DMARC.

Exemple d'enregistrement DMARC

Nom :
_dmarc.example.com
Valeur :
v=DMARC1 ; p=reject ; rua=mailto:dmarc-reports@example.com ; ruf=mailto:dmarc-fail@example.com ; adkim=s ; aspf=s

L'exemple d'enregistrement DMARC est associé au exemple.com domaine, utilise la version 1 et spécifie le refuser politique applicable aux messages ne passant pas la vérification DMARC, demandant strict mode (s) afin de vérifier la cohérence entre les domaines SPF et DKIM et d'envoyer des rapports agrégés à l'adresse e-mail dmarc-reports@example.com et les rapports d'erreur à l'adresse dmarc-fail@example.com.

5.3.2. Politiques DMARC

Comme indiqué dans le paragraphe précédent, l'enregistrement DMARC précise la politique que le serveur de messagerie destinataire doit appliquer aux messages qui ne passent pas la vérification DMARC. Les politiques possibles sont les suivantes :

• aucune: le domaine de l'expéditeur ne fournit aucune indication concernant la distribution des messages qui échouent à la vérification DMARC ;
• quarantaine: le domaine de l'expéditeur indique que les messages ne passant pas la vérification DMARC doivent être considérés comme suspects (par exemple, faire l'objet d'un examen plus approfondi, être traités comme du spam ou être signalés comme suspects) ;
• rejet: le domaine de l'expéditeur indique que les messages ne passant pas la vérification DMARC doivent être rejetés.

5.3.3. Processus de vérification et d'application des politiques

Si le protocole DMARC est correctement configuré à la fois sur le serveur de messagerie de l'expéditeur et sur celui du destinataire, lors de la réception du message, le serveur de messagerie du destinataire récupère les enregistrements SPF et DKIM afin d'effectuer les vérifications correspondantes, ainsi que celle relative au DMARC (décrite en détail au début du paragraphe 5.2.4). Si le message ne passe pas la vérification DMARC, la politique indiquée dans l'enregistrement DMARC (aucun, quarantaine ou refuser) est appliquée.

Il convient de noter que chaque serveur de messagerie peut appliquer des règles et des politiques locales pour déterminer s’il convient ou non de distribuer un message, en tenant également compte des résultats des vérifications SPF, DKIM et DMARC. Par conséquent, il existe généralement un processus décisionnel supplémentaire (« Filtre standard » sur la figure 5) en aval des vérifications susmentionnées, qui peut également inclure d’autres contrôles (tels que, par exemple, des filtres anti-spam et anti-malware).

De plus, le serveur de messagerie destinataire peut transmettre :

• aux adresses indiquées dans le rue champ de l'enregistrement DMARC, des rapports agrégés contenant des informations statistiques et récapitulatives sur les messages reçus du domaine de l'expéditeur ;
• aux adresses indiquées dans le ruf champ de l'enregistrement DMARC, des rapports détaillés sur les messages individuels reçus du domaine de l'expéditeur qui n'ont pas passé la vérification DMARC.

» Retour en haut de la page

6. Conclusions

Comme indiqué dans le chapitre précédent, pour lutter efficacement contre les menaces liées à l'usurpation d'identité du domaine de l'expéditeur, il est nécessaire que les trois protocoles examinés soient mis en œuvre conjointement et, en particulier, que [3]:

• le domaine de l'expéditeur publie correctement les enregistrements SPF, DKIM et DMARC dans le DNS ;
• le serveur de messagerie de l'expéditeur est configuré pour signer les messages avec DKIM ;
• le serveur de messagerie du destinataire est configuré pour effectuer des vérifications SPF et DKIM et appliquer les politiques DMARC.

En ce qui concerne la mise en œuvre du protocole, les recommandations suivantes ont également été formulées [2]:

• configurer le SPF en précisant quelles adresses IP sont autorisées à envoyer des e-mails au nom du domaine ; pour les domaines qui ne sont pas utilisés pour la transmission d'e-mails, par exemple ceux destinés exclusivement à des sites web, il convient tout de même de créer un enregistrement SPF afin d'indiquer explicitement qu'il n'existe aucun expéditeur d'e-mails valide pour ce domaine ;
• utiliser des protocoles et des algorithmes de chiffrement de pointe considérés comme sûrs pour les clés DKIM ; à la date de rédaction du présent document, le chiffrement RSA 2048 bits est recommandé ;
• protéger de manière adéquate la clé privée DKIM stockée sur le serveur de messagerie, en mettant en place des autorisations d'accès restrictives, et s'assurer que seul le logiciel du serveur de messagerie dispose de droits de lecture sur cette clé ;
• configurer chaque serveur de messagerie avec une paire de clés et un sélecteur uniques, afin de limiter les conséquences d'une éventuelle compromission de la clé privée ;
• protéger la clé privée à la fois contre toute divulgation accidentelle et contre toute tentative d'accès ou de modification par un pirate ;
• prévoir que les logiciels liés à toute liste de diffusion vérifient les signatures DKIM des messages entrants et apposent de nouvelles signatures DKIM sur les messages sortants ;
• utiliser des paires de clés DKIM uniques pour chaque tiers envoyant des e-mails au nom de l'organisation ;
• renouveler régulièrement les paires de clés DKIM (au moins tous les six mois) afin de limiter l'impact d'une éventuelle compromission ;
• révoquer immédiatement les clés en cas de suspicion de compromission ;
• surveiller les rapports DMARC afin de détecter toute erreur de configuration ou tentative d'abus.

Pour plus d'informations, veuillez consulter les ressources répertoriées dans la section « Documents de référence ».

On constate que, pour assurer correctement la sécurité des e-mails, outre les protocoles d'authentification examinés ici, il existe d'autres protocoles – qui ne font pas l'objet des présentes lignes directrices – tels que, par exemple, le protocole TLS (Transport Layer Security), qui garantit le chiffrement du canal de transmission, ainsi que les protocoles SMIME et OpenPGP, qui concernent le chiffrement de bout en bout et l'authentification des messages.

Il convient également de noter que, bien qu'il ne s'agisse pas d'un protocole de sécurité de la messagerie électronique au sens strict, il est recommandé, dans le cadre de la sécurité des services de messagerie, de mettre en œuvre le protocole DNSSEC (Domain Name System Security Extensions), une extension du protocole DNS qui ajoute des signatures cryptographiques aux enregistrements DNS afin de garantir l'intégrité et l'authenticité des requêtes DNS. Grâce au DNSSEC, par exemple, les informations relatives aux enregistrements SPF, DKIM et DMARC sont protégées pendant leur transmission, ce qui réduit le risque d'altération et renforce ainsi la sécurité du service de messagerie.

» Retour en haut de la page

Annexe A : Mesures de sécurité

Périmètre national de cybersécurité (PSNC)

PR.IP-1 : Des pratiques de référence (appelées « lignes directrices ») sont définies et gérées pour la configuration des systèmes informatiques et des systèmes de contrôle industriel, en intégrant des principes de sécurité (par exemple, le principe de fonctionnalité minimale).

1. Il existe un document détaillé et mis à jour qui précise, notamment en ce qui concerne la catégorie ID.AM, au moins :
   • a) les politiques de sécurité adoptées pour l'élaboration des configurations des systèmes informatiques et des systèmes de contrôle industriel, ainsi que le déploiement exclusif des configurations adoptées ;
   • b) la liste des configurations des systèmes informatiques et des systèmes de contrôle industriel utilisés, ainsi que la référence aux pratiques de référence correspondantes ;
   • c) les processus, les méthodologies et les technologies utilisés qui contribuent au respect des politiques de sécurité.

Réglementation du cloud – Infrastructures et services numériques pour l'administration publique

PR.IP-01 : Des pratiques de référence (appelées « lignes directrices ») sont définies et gérées pour la configuration des systèmes informatiques et des systèmes de contrôle industriel, en intégrant des principes de sécurité (par exemple, le principe de fonctionnalité minimale).

1. Les politiques et procédures relatives à la sécurité des applications sont définies afin d'apporter un soutien adéquat à la planification, à la mise en œuvre et à la maintenance des dispositifs de sécurité des applications ; elles doivent être réexaminées et mises à jour au moins une fois par an.
2. Il existe un document détaillé et mis à jour qui précise, notamment en ce qui concerne la catégorie ID.AM, au moins :
   • a) les politiques de sécurité adoptées pour l'élaboration des configurations des systèmes informatiques et des systèmes de contrôle industriel, ainsi que le déploiement exclusif des configurations adoptées ;
   • b) la liste des configurations des systèmes informatiques et des systèmes de contrôle industriel utilisés, ainsi que la référence aux pratiques de référence correspondantes ;
   • c) les processus, les méthodologies et les technologies utilisés qui contribuent au respect des politiques de sécurité.
3. Les exigences de base en matière de sécurité pour diverses applications sont définies et documentées.
4. Des indicateurs techniques, utiles pour évaluer le niveau de conformité aux exigences de sécurité et aux obligations réglementaires définies, sont définis et mis en œuvre.
5. Il existe un processus de correction des vulnérabilités et de restauration des applications visant à garantir leur sécurité, qui automatise les mesures correctives lorsque cela est possible.
6. Il existe une procédure permettant de vérifier la compatibilité des appareils avec les systèmes d'exploitation et les applications.
7. Il existe un système de gestion des modifications concernant le système d'exploitation, les correctifs et/ou les applications.

Réglementation du cloud – Services cloud pour l'administration publique

PR.IP-01 : Des pratiques de référence (appelées « lignes directrices ») sont définies et gérées pour la configuration des systèmes informatiques et des systèmes de contrôle industriel, en intégrant des principes de sécurité (par exemple, le principe de fonctionnalité minimale).

1. Les politiques et procédures sont définies en matière de sécurité des applications afin d'apporter un soutien adéquat à la planification, à la mise en œuvre et à la maintenance des dispositifs de sécurité des applications, qui doivent être réexaminés et mis à jour au moins une fois par an [IaaS, SaaS].
2. Il existe un document détaillé et mis à jour qui précise, notamment en ce qui concerne la catégorie ID.AM, au moins :
   • a) les politiques de sécurité adoptées pour l'élaboration des configurations des systèmes informatiques et des systèmes de contrôle industriel, ainsi que le déploiement exclusif des configurations adoptées ;
   • b) la liste des configurations des systèmes informatiques et des systèmes de contrôle industriel utilisés, ainsi que la référence aux pratiques de référence correspondantes ;
   • c) les processus, méthodologies et technologies utilisés qui contribuent au respect des politiques de sécurité [SaaS].
3. Les exigences de base en matière de sécurité pour diverses applications sont définies et documentées.
4. Des indicateurs techniques, utiles pour surveiller le niveau de conformité aux exigences de sécurité et aux obligations réglementaires définies, sont définis et mis en œuvre. 5. Un processus est en place pour la correction des vulnérabilités des applications et la restauration de la sécurité de celles-ci, automatisant les mesures correctives lorsque cela est possible.
5. Il existe un processus permettant de vérifier la compatibilité des appareils avec les systèmes d'exploitation et les applications [PaaS, SaaS].
6. Il existe un système de gestion des changements concernant le système d'exploitation, les correctifs et/ou les applications [PaaS, SaaS].

NIS 2

PR.PS-01 : Des pratiques de gestion de la configuration sont mises en place et appliquées.

1. Au moins pour les informations et les systèmes réseau concernés, leurs configurations de base sécurisées (renforcées) sont définies et documentées dans une liste mise à jour.
2. Conformément aux politiques visées dans la mesure GV.PO-01, des procédures sont adoptées et documentées en ce qui concerne le point 1.

» Retour en haut de la page

Bibliographie

[1] NIST, « Note technique 1945 ».
[2] NIST, « Publication spéciale du NIST 800-177, révision 1 »
[3] Agence nationale de cybersécurité, « Cryptographie post-quantique et quantique – Préparation à la menace quantique ».
[4] Agence nationale de cybersécurité, « Cadre d'authentification des e-mails ».

» Retour en haut de la page