Sécuriser votre compte d'envoi d'e-mails : accès de l'équipe, identifiants et réponse en cas de compromission

Une bonne sécurité du compte d'envoi d'e-mails fait la différence entre une mauvaise après-midi et un mauvais trimestre. Si quelqu'un prend le contrôle du compte que vous utilisez pour envoyer vos e-mails, il hérite de votre domaine authentifié, de votre réputation d'expéditeur et de la confiance de vos clients. En quelques heures, il peut envoyer du phishing ou du spam qui passe tous les contrôles techniques, et vous pouvez passer des semaines à vous remettre des mises sur liste de blocage et du filtrage qui en résultent. Nous voulons vous aider à rendre ce scénario improbable, et surmontable s'il survient. Ce guide explique qui doit avoir accès et à quel niveau, comment protéger les connexions, comment gérer les identifiants par application, comment gérer le départ des collaborateurs, à quoi ressemble une compromission dans vos données et que faire pendant la première heure.

Tout ce qui suit relève des bonnes pratiques générales, valables pour n'importe quelle plateforme d'envoi. Lorsqu'un contrôle dépend de votre offre ou de votre configuration, nous le précisons, et la bonne démarche consiste à vérifier quels contrôles votre compte MigoSMTP propose avant de planifier quoi que ce soit. Nous ne présumons ni de noms de rôles précis ni de fonctions de connexion particulières.

Pourquoi les comptes d'envoi sont ciblés

Les attaquants apprécient les comptes d'envoi pour les mêmes raisons que vous. L'infrastructure est fiable, le domaine est authentifié et les messages arrivent en boîte de réception. Un identifiant volé ou une clé qui fuite transforme tout cela en outil à leur service. Leurs objectifs typiques incluent des campagnes de phishing qui empruntent votre marque, du spam en masse, la fraude à la facture et l'abus de réinitialisations de mot de passe visant des tiers.

Les dégâts se limitent rarement à l'attaquant. Les fournisseurs de messagerie jugent votre domaine et vos adresses IP sur ce qu'ils observent : une rafale de messages abusifs dégrade donc la délivrabilité de vos e-mails légitimes pendant des jours, voire des semaines. Les destinataires qui reçoivent des messages frauduleux en votre nom perdent une confiance difficile à reconstruire. Si le compte expose aussi des listes de destinataires, des journaux de livraison ou le contenu des messages, un problème de protection des données peut s'ajouter au problème de délivrabilité.

Accès de l'équipe et moindre privilège

Le moindre privilège signifie que chaque personne et chaque programme reçoit le minimum d'accès nécessaire à sa mission, et rien de plus. C'est l'idée la plus efficace en matière de sécurité des comptes, car elle limite ce qu'un identifiant volé peut faire. Commencez par noter qui a accès aujourd'hui et pourquoi. La plupart des équipes sont surprises : d'anciens prestataires, une agence d'il y a deux ans, un fondateur qui a créé le compte avant de le transmettre.

Séparez les rôles

Même une petite équipe gagne à raisonner en groupes de rôles. Que votre compte dispose de rôles intégrés, de permissions personnalisées ou d'un seul identifiant propriétaire, c'est à vérifier dans votre compte MigoSMTP. Le tableau présente la répartition que nous suggérons comme cible et la logique qui la sous-tend. Adaptez-la aux contrôles dont vous disposez réellement.

Deux règles pratiques aident. Premièrement, limitez le nombre de propriétaires au minimum compatible avec l'absence de l'un d'eux en congé, soit généralement deux. Deuxièmement, ne laissez personne utiliser un identifiant propriétaire pour le travail ordinaire. Si une personne du marketing doit envoyer une campagne, elle doit le faire avec son rôle de marketing.

L'accès individuel vaut mieux que les identifiants partagés

Un identifiant partagé est pratique le premier jour et coûteux ensuite, en permanence. Vous ne pouvez pas savoir qui a modifié un paramètre, toute personne ayant connu le mot de passe reste un risque, et son renouvellement interrompt toute l'équipe. Donnez à chaque personne un utilisateur nominatif. Lorsque votre compte le permet, rattachez la connexion au système d'identité de votre entreprise afin que la désactivation d'une personne en un seul endroit supprime son accès partout. Si votre compte ne propose pas d'utilisateurs nominatifs dans votre offre, considérez-le comme un risque à consigner et compensez-le par une gestion plus stricte des identifiants et une surveillance renforcée.

Protégez les connexions par l'authentification à deux facteurs

Un second facteur signifie qu'un mot de passe volé ne suffit pas pour se connecter. Les recommandations du NIST sur l'identité numérique font de l'authentification multifacteur un contrôle essentiel, et les recommandations d'authentification de l'OWASP la préconisent pour les comptes à risque réel. Un compte d'envoi en fait certainement partie. Si votre compte MigoSMTP propose l'authentification à deux facteurs, activez-la pour chaque utilisateur, en commençant par les propriétaires et les personnes qui peuvent gérer les identifiants.

• Privilégiez les méthodes résistantes au phishing. Les clés de sécurité matérielles et les passkeys résistent mieux aux fausses pages de connexion que les codes reçus par SMS. Les applications d'authentification constituent une bonne solution intermédiaire. Les codes par SMS valent mieux que rien, mais restent le choix le plus faible.
• Utilisez un gestionnaire de mots de passe. Chaque utilisateur doit disposer d'un mot de passe long et unique pour le compte. La réutilisation d'un site à l'autre est la cause de la plupart des prises de contrôle de comptes.
• Sécurisez le parcours de récupération. Un attaquant qui ne peut pas déjouer votre connexion peut viser la réinitialisation du mot de passe. Protégez la messagerie qui reçoit les messages de réinitialisation avec une connexion tout aussi robuste, et gardez les codes de récupération en lieu sûr, hors ligne.
• Ne comptez pas sur une fonction qui peut ne pas exister. Nous n'affirmons ici l'existence d'aucune fonction de connexion en particulier. Vérifiez quels contrôles votre compte MigoSMTP propose et, si l'un d'eux manque, compensez en protégeant plus strictement l'identité et la messagerie derrière chaque connexion.

Identifiants SMTP et clés API : un par application

Les personnes se connectent à un tableau de bord, tandis que les programmes s'authentifient avec des identifiants SMTP ou des clés API. Ce sont deux secrets qui permettent à un logiciel d'envoyer des e-mails en votre nom, et tous deux finissent souvent dans des dépôts, des messages de discussion, des tickets et d'anciennes sauvegardes de serveurs. Notre guide sur la sécurité des clés API, leurs permissions, leur stockage et leur renouvellement détaille les mécanismes. Voici les principes à retenir pour la sécurité du compte.

• Un identifiant par application et par environnement. La production, la préproduction et chaque service distinct ont les leurs. Si l'un fuite, vous en révoquez un seul et les autres continuent de fonctionner. Vos journaux vous indiquent aussi quel système fait quoi.
• La permission la plus restreinte possible. Un service qui se contente d'envoyer n'a pas besoin de gérer des utilisateurs ni de lire des données. Lorsqu'une clé peut être limitée, limitez-la.
• Gardez les secrets hors du code. Utilisez des variables d'environnement ou un gestionnaire de secrets. Ajoutez une analyse à vos dépôts et à vos pipelines de build afin qu'un commit accidentel soit détecté avant de se propager.
• Ne collez pas de secrets dans une discussion ou un e-mail. Partagez-les via le gestionnaire de secrets, afin que les accès soient journalisés et puissent être retirés.
• Renouvelez selon un calendrier et après toute exposition. Créez le nouvel identifiant, déployez-le, vérifiez que l'envoi fonctionne, puis révoquez l'ancien. Ne révoquez jamais d'abord sur un système en production sans plan.
• Nommez-les et datez-les. Un identifiant nommé d'après son propriétaire, son système et sa date de création se contrôle facilement. Un identifiant nommé test2 est une panne qui n'attend que de se produire.

Si vous hésitez encore sur la façon dont une application donnée doit se connecter, notre comparaison entre l'envoi par SMTP et par API présente les compromis, et chaque connexion doit utiliser TLS, comme l'explique la RFC 8314. Un identifiant transmis sur une liaison non chiffrée est un identifiant offert.

Départ des collaborateurs, prestataires et agences

La plupart des problèmes d'accès ne sont pas des attaques. Ce sont d'anciens employés, des contrats expirés et des intégrations oubliées qui fonctionnent encore. Une procédure de départ écrite transforme ce qui est une décision délicate en liste de contrôle, et elle vaut pour les salariés, les freelances et les agences.

1. Supprimez ou désactivez l'utilisateur nominatif le jour du départ. Si la connexion est rattachée à votre fournisseur d'identité, désactivez-le d'abord à cet endroit.
2. Listez tous les identifiants que la personne pouvait lire ou créer, y compris les clés d'application dans le gestionnaire de secrets, les dépôts et les anciens tickets.
3. Renouvelez ces identifiants, en commençant par la production. Les secrets partagés rendent le départ d'un collaborateur pénible, ce qui plaide encore pour des identifiants par application.
4. Examinez les trente derniers jours d'activité de la personne : utilisateurs créés, identifiants émis, paramètres modifiés, exports lancés.
5. Vérifiez les webhooks, les règles de transfert et les intégrations API qu'elle a mis en place, et supprimez ceux que vous ne pouvez pas justifier.
6. Transférez la propriété des campagnes, modèles et automatisations à un collègue nommément désigné, afin que le travail ne s'arrête pas quand le compte disparaît.
7. Consignez la date, les étapes effectuées et qui les a confirmées.

Procédez de la même façon à la fin d'une mission avec une agence ou un fournisseur. Les intervenants externes détiennent souvent les accès les plus privilégiés et sont les moins attachés à vos politiques de sécurité.

Repérer tôt un compte compromis

Les attaquants s'annoncent rarement. Ils envoient vite, avant que quiconque s'en aperçoive : votre meilleure défense consiste donc à savoir ce qui est normal et à surveiller les écarts. Voici comment les interpréter sous l'angle de la sécurité.

Créez des alertes auxquelles les gens réagissent vraiment

• Définissez des seuils relatifs à votre schéma habituel, par exemple un multiple du volume horaire courant, plutôt qu'un chiffre deviné une fois pour toutes.
• Envoyez les alertes à au moins deux personnes et à un canal partagé, afin qu'un congé ou un message manqué ne masque pas un incident.
• Vérifiez les alertes et les journaux que fournit votre compte MigoSMTP, et comblez les lacunes par des contrôles de votre côté, comme le décompte des messages soumis par vos applications.
• Consultez chaque semaine un court récapitulatif du volume, des rebonds, des plaintes et des nouveaux identifiants. Un calme inhabituel mérite aussi un coup d'œil, car une intégration en panne est un problème à part entière.

Exemple concret : repérer et contenir une clé qui a fuité

Voici un exemple inventé, avec des chiffres illustratifs, pour montrer comment les signaux et la réponse s'articulent. Une petite boutique en ligne soumet normalement environ 400 messages par jour, tous depuis un seul service de confirmation de commande, avec un taux de rebond d'environ 1 pour cent et presque aucune plainte.

Dans cet exemple, les dégâts se sont limités à environ 3 000 messages indésirables en une vingtaine de minutes, au lieu de centaines de milliers sur un week-end. Ce résultat tient à trois décisions antérieures : des identifiants distincts par environnement, une alerte fondée sur le volume normal et une personne d'astreinte qui savait pouvoir révoquer une clé sans demander la permission.

Réponse aux incidents : la première heure et la suite

Décidez du plan avant d'en avoir besoin. Pendant un incident, les gens sont sous tension, et la moitié des retards vient du fait de ne pas savoir qui a le droit de faire quoi. Le NIST publie un guide de gestion des incidents très utilisé (SP 800-61) dont les phases sont la préparation, la détection et l'analyse, la contention, l'éradication et la reprise, puis les enseignements tirés. Les étapes ci-dessous suivent la même structure, adaptée à un compte d'envoi.

1. Contenir. Révoquez l'identifiant suspect, désactivez l'utilisateur suspect ou suspendez l'application concernée. Faites-le en premier, avant d'être certain de la cause. Privilégiez l'action la plus ciblée qui arrête l'abus.
2. Préserver les preuves. Exportez les journaux, des échantillons de messages et la liste des utilisateurs et des identifiants avant qu'ils ne changent. Notez les heures dans un seul fuseau horaire.
3. Évaluer l'étendue. Établissez ce qui a été envoyé, à qui, depuis quel identifiant et pendant combien de temps. Vérifiez si des données de destinataires, des modèles ou des paramètres ont été lus ou modifiés.
4. Éradiquer. Renouvelez tous les identifiants que l'attaquant a pu voir. Réinitialisez les mots de passe et les sessions des utilisateurs concernés, activez ou revérifiez les seconds facteurs, et supprimez tout ce que vous n'avez pas créé, comme des utilisateurs, des webhooks et des règles de transfert.
5. Reprendre. Rétablissez progressivement l'envoi légitime, en commençant par les messages les plus critiques. Surveillez de près les taux de rebond et de plaintes. Si des e-mails ont été bloqués, suivez les étapes de la levée d'une mise sur liste de blocage.
6. Communiquer. Informez d'abord les parties prenantes internes. Vérifiez les obligations légales ou contractuelles de notification auprès de votre contact conformité. Si des destinataires ont reçu des messages frauduleux, dites-le clairement et indiquez-leur ce qu'ils doivent ignorer.
7. Apprendre. Dans la semaine, organisez un court retour d'expérience sans recherche de coupable. Corrigez la cause racine, mettez à jour ce plan et ajoutez la détection qui l'aurait repérée plus tôt.

Une liste de contrôle de sécurité pour votre compte d'envoi

• Chaque personne a un utilisateur nominatif, et il ne reste aucun identifiant partagé.
• Le groupe propriétaire compte au plus deux membres, et personne ne l'utilise pour le travail quotidien.
• Les rôles suivent la séparation entre développeur, marketing, finance et auditeur, dans la mesure où votre compte le permet.
• L'authentification à deux facteurs est activée pour chaque utilisateur là où elle est disponible, et les parcours de récupération sont protégés.
• Chaque application et chaque environnement a son propre identifiant, nommé et daté, avec la permission la plus restreinte possible.
• Les secrets se trouvent dans un gestionnaire de secrets ou des variables d'environnement, et les dépôts sont analysés pour détecter les fuites.
• Des alertes existent pour le volume, les rebonds, les plaintes, les nouveaux identifiants et les lieux de connexion inhabituels, et elles atteignent au moins deux personnes.
• Une procédure de départ existe et est appliquée pour les salariés, les prestataires et les agences.
• Le plan de réponse aux incidents est rédigé, désigne un responsable pour chaque étape et inclut un moyen de nous joindre en urgence.
• Les revues d'accès et le renouvellement des identifiants suivent un calendrier, au moins chaque trimestre.
• Votre domaine d'envoi est authentifié et surveillé ; voir comment authentifier un domaine d'envoi.

Sources et lectures complémentaires

Ces références publiques ont éclairé les pratiques ci-dessus. Ce sont des recommandations générales, et non des affirmations sur une fonction de MigoSMTP.

• NIST SP 800-61 Rev. 2, Computer Security Incident Handling Guide
• NIST SP 800-63B, Digital Identity Guidelines: Authentication and Lifecycle Management
• OWASP Authentication Cheat Sheet
• OWASP Secrets Management Cheat Sheet
• RFC 8314, Cleartext Considered Obsolete: Use of TLS for Email Submission and Access
• RFC 7489, Domain-based Message Authentication, Reporting, and Conformance (DMARC)