La violation a commencé par un seul compte e‑mail compromis. Un employé a cliqué sur un lien de phishing, saisi ses identifiants, et les attaquants ont eu accès. À partir de là, ils ont envoyé des factures aux clients avec des coordonnées de paiement mises à jour. Quand quelqu’un s’en est rendu compte, $200,000 avaient été redirigés vers des comptes contrôlés par les attaquants.
L’entreprise avait l’e‑mail. Elle n’avait pas la sécurité de l’e‑mail.
La sécurité de l’e‑mail n’est pas une seule configuration — ce sont des couches de protection qui travaillent ensemble. L’authentification empêche l’usurpation. Le chiffrement protège le contenu en transit. Les contrôles d’accès limitent qui peut envoyer et recevoir. La surveillance détecte les anomalies avant qu’elles ne deviennent des violations.
Cette liste de contrôle propose une approche systématique pour auditer votre posture de sécurité e‑mail.
Audit de l’authentification
L’enregistrement SPF est publié avec -all. Vérifiez que votre enregistrement SPF existe, est syntaxiquement valide, et se termine par -all (échec strict) plutôt que ~all (échec souple). Vérifiez que vous êtes en dessous de la limite de 10 recherches. Utilisez MXToolbox ou un outil similaire pour valider.
Tous les expéditeurs légitimes sont dans SPF. Auditez chaque service qui envoie des e‑mails en tant que votre domaine. Automatisation marketing, e‑mails transactionnels, CRM, support, applications internes — chacun doit être autorisé dans votre enregistrement SPF. Des expéditeurs manquants provoquent des échecs d’authentification ; des expéditeurs non autorisés indiquent une compromission potentielle.
Les clés DKIM sont publiées et valides. Vérifiez que les clés publiques DKIM sont dans le DNS pour tous les domaines d’envoi et sélecteurs. Vérifiez que les clés font au moins 1024 bits (2048 préférés). Confirmez que les clés n’ont pas expiré si vous utilisez une rotation de clés.
La signature DKIM est active. Envoyez des e‑mails de test et vérifiez que l’en-tête DKIM-Signature est présent et valide. Vérifiez que le domaine signataire est aligné avec votre domaine From pour DMARC.
La politique DMARC est appliquée. Vérifiez que votre enregistrement DMARC existe avec une politique p=quarantine ou p=reject. Si vous êtes encore sur p=none, établissez un plan pour passer à l’application. Vérifiez que les balises rua et ruf sont définies pour recevoir des rapports.
Les rapports DMARC sont traités. Confirmez que vous recevez et examinez les rapports agrégés DMARC. Utilisez un service d’analyse DMARC pour rendre les rapports lisibles. Recherchez des échecs d’authentification provenant d’expéditeurs légitimes et des tentatives d’envoi non autorisées.
BIMI est configuré (optionnel mais recommandé). Si vous avez atteint l’application de DMARC, envisagez d’implémenter BIMI pour afficher votre logo dans les clients de messagerie compatibles. Cela nécessite un Verified Mark Certificate pour une prise en charge complète.
Audit du chiffrement
TLS est requis pour l’envoi. Vérifiez que vos serveurs de messagerie exigent TLS pour les connexions sortantes. Assurez-vous d’utiliser TLS 1.2 ou supérieur — les versions plus anciennes présentent des vulnérabilités connues.
TLS est requis pour la réception. Configurez vos serveurs de messagerie pour exiger TLS pour les connexions entrantes, ou au minimum préférez TLS et journalisez lorsque les connexions retombent en non chiffré.
MTA-STS est publié. MTA-STS indique aux serveurs expéditeurs d’exiger TLS lors de la livraison vers votre domaine. Publiez une politique MTA-STS et vérifiez qu’elle est respectée. Cela empêche les attaques de rétrogradation où des attaquants forcent une livraison non chiffrée.
Les enregistrements DANE sont publiés (le cas échéant). Si vous contrôlez votre DNS et vos serveurs de messagerie, DANE fournit l’épinglage de certificats pour l’e‑mail. C’est plus complexe que MTA-STS mais offre des garanties plus fortes.
Le certificat est valide et correctement chaîné. Vérifiez la validité, l’expiration et la chaîne de certification de votre certificat TLS de serveur de messagerie. Utilisez SSL Labs ou CheckTLS pour vérifier.
Les suites de chiffrement sont sûres. Auditez les suites de chiffrement prises en charge par votre serveur de messagerie. Désactivez les chiffrements faibles (RC4, DES, chiffrements export) et les protocoles anciens (SSLv3, TLS 1.0, TLS 1.1).
Audit des contrôles d’accès
L’accès administrateur est restreint et journalisé. Limitez qui peut administrer les systèmes de messagerie. Exigez une authentification forte (MFA) pour l’accès administrateur. Journalisez toutes les actions administratives pour des pistes d’audit.
L’authentification des utilisateurs est forte. Exigez des mots de passe robustes ou, mieux, le MFA pour tous les comptes e‑mail. Désactivez les protocoles d’authentification hérités qui ne prennent pas en charge le MFA.
Les comptes de service sont inventoriés. Documentez tous les comptes de service qui envoient des e‑mails. Chacun doit avoir un propriétaire clairement défini, un objectif défini, et des limites d’accès appropriées. Supprimez les comptes de service inutilisés.
Les clés API sont sécurisées. Si vous utilisez des API e‑mail, auditez la gestion des clés API. Les clés doivent être régulièrement rotées, limitées au minimum de permissions nécessaires, et stockées de manière sécurisée (pas dans les dépôts de code).
Les limites d’envoi sont configurées. Définissez des limites de débit sur l’envoi d’e‑mails pour limiter les dégâts dus à des comptes compromis. Un volume d’envoi inhabituel doit déclencher des alertes.
Les règles de transfert sont auditées. Les attaquants créent souvent des règles de transfert pour exfiltrer des e‑mails. Auditez régulièrement les règles de transfert sur tous les comptes. Alertez en cas de création de nouvelles règles de transfert.
Audit de l’infrastructure
Les serveurs de messagerie sont à jour de correctifs. Vérifiez que le logiciel de vos serveurs de messagerie est à jour des correctifs de sécurité. Abonnez‑vous aux avis de sécurité pour votre logiciel de serveur de messagerie.
Les serveurs de messagerie sont durcis. Désactivez les services inutiles. Configurez les pare-feu pour n’autoriser que les ports requis. Suivez les guides de durcissement pour votre logiciel de serveur de messagerie spécifique.
Le relais ouvert est désactivé. Testez que votre serveur de messagerie ne relaie pas des e‑mails depuis des sources non autorisées. Les relais ouverts sont rapidement exploités pour le spam.
Le MX de secours est sécurisé. Si vous avez des serveurs MX de secours, assurez-vous qu’ils ont la même configuration de sécurité que les serveurs primaires. Les attaquants ciblent parfois une infrastructure de secours moins sécurisée.
Le DNS est sécurisé. Utilisez DNSSEC pour prévenir les attaques de spoofing DNS. Sécurisez votre compte chez votre fournisseur DNS avec une authentification forte.
Audit de la surveillance
Les échecs d’authentification sont surveillés. Suivez les échecs SPF, DKIM et DMARC. Analysez les schémas — des échecs provenant d’expéditeurs légitimes doivent être corrigés ; des échecs provenant de sources inconnues peuvent indiquer des tentatives d’usurpation.
Des modèles d’envoi inhabituels déclenchent des alertes. Surveillez les pics de volume d’envoi, les envois à des heures inhabituelles, ou vers des destinataires inhabituels. Ces schémas peuvent indiquer une compromission.
Les anomalies de connexion sont détectées. Surveillez les connexions depuis des emplacements inhabituels, les multiples échecs de connexion, et les connexions réussies après des échecs. Ces schémas suggèrent des attaques sur les identifiants.
Le statut sur les listes noires est surveillé. Vérifiez régulièrement les principales listes noires. Être listé indique un problème — compromission, mauvaise configuration ou problèmes de réputation.
Les taux de rebond sont suivis. Des augmentations soudaines des taux de rebond peuvent indiquer un empoisonnement de liste, un envoi compromis, ou des problèmes de délivrabilité.
Préparation à la réponse aux incidents
Un plan de réponse aux incidents existe. Documentez quoi faire lorsque des incidents de sécurité e‑mail surviennent. Qui est notifié ? Quels systèmes sont isolés ? Comment la communication est-elle gérée ?
Les indicateurs de compromission sont définis. Sachez quels signes indiquent une compromission de la messagerie : règles de transfert inhabituelles, éléments envoyés inattendus, authentification depuis des emplacements inconnus, signalements d’e‑mails usurpés.
Les procédures de rétablissement sont documentées. Sachez comment révoquer des identifiants compromis, supprimer des règles malveillantes, et restaurer les opérations normales. Testez ces procédures avant d’en avoir besoin.
Des modèles de communication sont prêts. Si vous devez notifier des clients ou des partenaires d’incidents liés à l’e‑mail, préparez des modèles. La communication de crise est difficile ; la préparation aide.
Réaliser l’audit
Parcourez cette liste de contrôle de manière systématique, en documentant vos constats au fur et à mesure. Pour chaque élément :
- —Conforme: Configuration correcte et vérifiée
- —Échec: Configuration manquante ou incorrecte — nécessite une remédiation
- —Partiel: Certains aspects sont corrects, d’autres doivent être améliorés
- —N/A: Sans objet pour votre environnement
Priorisez la remédiation en fonction du risque. Les problèmes d’authentification (SPF, DKIM, DMARC) sont fondamentaux — corrigez-les en premier. Les problèmes de contrôle d’accès susceptibles de permettre une compromission sont prioritaires. Les lacunes de surveillance sont importantes mais moins urgentes que des vulnérabilités actives.
Planifiez des audits réguliers — trimestriels au minimum, mensuels pour les environnements à haute sécurité. La sécurité de l’e‑mail n’est pas une configuration ponctuelle ; elle exige une attention continue.
Frequently asked questions
À quelle fréquence dois-je réaliser des audits de sécurité de l’e‑mail ?
Trimestriellement pour la plupart des organisations. Mensuellement pour les environnements à haute sécurité ou après des changements significatifs. En outre, auditez après tout incident de sécurité, changement d’infrastructure, ou lors de l’ajout de nouveaux services d’envoi d’e‑mails.
Quel est l’élément le plus critique de cette liste de contrôle ?
L’application de DMARC (p=reject) est sans doute le contrôle unique le plus impactant — elle empêche l’usurpation de domaine, qui est à la base de la plupart des attaques par e‑mail. Mais elle exige d’abord que SPF et DKIM soient correctement configurés.
Devrais-je faire appel à un tiers pour les audits de sécurité de l’e‑mail ?
Les audits externes apportent un regard neuf et révèlent les angles morts. Pour les exigences de conformité (SOC 2, HIPAA, etc.), des audits par des tiers peuvent être requis. Pour les vérifications de routine, des audits internes utilisant cette liste de contrôle suffisent.
De quels outils ai-je besoin pour cet audit ?
MXToolbox pour les vérifications d’authentification et DNS. L’interface d’administration de votre serveur de messagerie pour la revue de configuration. Un service d’analyse DMARC pour le traitement des rapports. Un scanner de vulnérabilités pour l’évaluation de l’infrastructure. La plupart des vérifications peuvent être effectuées avec des outils gratuits.