La sécurité des clés API repose sur quatre habitudes : donner à chaque clé le plus petit ensemble de permissions dont elle a besoin, la conserver dans un véritable stockage de secrets, la renouveler sans interruption et avoir un plan prêt pour le jour où l'une fuite. Une clé d'envoi compromise permet à n'importe qui d'envoyer des e-mails en votre nom : elle met donc en danger la réputation de votre expéditeur autant que vos données.
Vérifiez les noms des permissions dans votre compte. Les noms de permissions de ce guide sont des exemples du principe. Utilisez les options que votre compte MigoSMTP propose réellement, et choisissez la plus restrictive qui convient.
Pourquoi les clés fuitent
| Mode de fuite | Exemple | Prévention |
|---|---|---|
| Validée dans un dépôt | Un fichier de configuration contenant une clé est poussé vers un dépôt public ou partagé | Utiliser des variables d'environnement, des fichiers d'exclusion et l'analyse des secrets |
| Livrée au client | Une clé dans du JavaScript ou une application mobile | Appeler plutôt votre propre serveur |
| Partagée dans une discussion ou un ticket | Une clé collée dans un échange avec le support | Partager via un gestionnaire de secrets et renouveler en cas d'exposition |
| Laissée sur un compte d'une personne partie | Un ancien prestataire détient encore la clé | Renouveler lorsque des personnes partent |
| Journalisée par accident | Un journal de débogage affiche les en-têtes de requête | Masquer les secrets dans les journaux |
| Serveur compromis | Un logiciel malveillant lit les variables d'environnement | Mettre à jour les serveurs et limiter ce que chacun peut atteindre |
Étape 1 : une clé par application et par environnement
Créez des clés distinctes pour la production, la préproduction et chaque application qui envoie des e-mails. Nommez-les de façon à les reconnaître dans un journal d'audit.
| Nom de la clé | Utilisée par | Permission |
|---|---|---|
| shop-production | La boutique en ligne, e-mails de commande | Envoi uniquement |
| shop-staging | Environnement de test | Envoi uniquement, vers des adresses de test |
| crm-production | Le CRM, envoi de campagnes | Envoi et gestion de ses propres contacts |
| webhooks-reader | Une tâche de reporting | Lecture des événements uniquement |
| ops-admin | Une personne nommée, tâches rares | Accès complet avec authentification à deux facteurs |
Étape 2 : appliquer le moindre privilège
Demandez-vous pour chaque clé : quel est le strict minimum dont elle a besoin ? Envoyer des e-mails n'exige pas de lire votre liste de contacts, de modifier le DNS ni de gérer la facturation, et une tâche de reporting ne devrait pas pouvoir envoyer du tout.
- Préférez une clé en envoi seul pour tout système qui ne fait que délivrer des messages.
- Réservez la gestion du compte, de la facturation et des utilisateurs aux personnes disposant de l'authentification à deux facteurs, pas aux clés.
- Réexaminez les permissions chaque trimestre et retirez ce qui n'est plus nécessaire.
- Si votre compte propose des restrictions par adresse IP, par domaine ou par limite de débit, utilisez-les. Consultez les paramètres de sécurité du compte pour voir ce qui est disponible.
Étape 3 : stocker les clés en sécurité
Chargez la clé à l'exécution depuis l'environnement ou un gestionnaire de secrets. Un schéma minimal figure ci-dessous.
# .env (never commit this file)
MIGOSMTP_API_KEY=replace-with-your-key
# .gitignore
.env
*.pem<?php
$key = getenv('MIGOSMTP_API_KEY');
if (!$key) {
throw new RuntimeException('API key is not configured');
}Ajoutez l'analyse des secrets. Activez l'analyse des secrets dans votre hébergeur de code et exécutez un scanner dans votre pipeline de build. Elle détecte les clés avant qu'elles n'atteignent une branche partagée et vous alerte si l'une passe entre les mailles.
Étape 4 : renouveler sans interruption
- Créez la nouvelle clé. Donnez-lui les mêmes permissions et un nom comportant la date ou la version.
- Stockez-la. Ajoutez-la à votre gestionnaire de secrets ou à la configuration d'environnement.
- Déployez. Publiez la modification et redémarrez les services qui lisent la clé.
- Vérifiez. Consultez les journaux de livraison pour confirmer que le trafic utilise la nouvelle clé.
- Révoquez l'ancienne clé. Ne le faites qu'une fois le trafic basculé. Attendez un court instant et recherchez d'éventuelles erreurs.
- Consignez-le. Notez la date, le motif et l'auteur de l'opération.
Étape 5 : surveiller les abus
| Signal | Ce que cela peut signifier | Action |
|---|---|---|
| Volume très supérieur à la normale | Une clé compromise ou une boucle dans votre code | Suspendre la clé et enquêter |
| Destinataires nouveaux ou inconnus | Spam ou phishing envoyé avec votre clé | Révoquer la clé et examiner les messages |
| Envois à des heures inhabituelles | Abus automatisé | Vérifier l'IP source et restreindre l'accès |
| Hausse des rebonds ou des plaintes | Mauvais destinataires ou abus | Vérifier la suppression et les sources, voir la liste de contrôle anti-spam |
| Requêtes depuis de nouvelles adresses IP | Une clé utilisée en dehors de vos serveurs | Ajouter une liste d'autorisation et renouveler |
Si une clé fuite : la première heure
| Minutes | À faire |
|---|---|
| 0 à 10 | Révoquez la clé. Si vous ne pouvez pas encore déployer de remplacement, acceptez une courte interruption plutôt que la poursuite de l'abus |
| 10 à 30 | Créez et déployez une nouvelle clé. Confirmez que l'envoi est redevenu normal |
| 30 à 60 | Examinez le journal de livraison à la recherche de messages que vous n'avez pas envoyés. Vérifiez les taux de plaintes et de rebonds ainsi que les listes de blocage |
| Ensuite | Déterminez comment elle a fuité, supprimez la source, renouvelez les secrets associés et consignez ce que vous avez appris |
Si des e-mails ont été envoyés en votre nom, suivez le guide de retrait des listes de blocage et contactez le support afin que l'examen du compte dispose du contexte.
Vous pensez qu'une clé a été exposée ? Révoquez-la d'abord, puis contactez-nous en indiquant le nom de la clé et l'heure, afin que nous vous aidions à examiner les envois récents.
Pour aller plus loin et sources
Questions fréquentes
Pourquoi une clé API d'e-mail est-elle aussi sensible ?
Quiconque détient une clé d'envoi peut envoyer des e-mails en votre nom. Les attaquants utilisent des clés compromises pour envoyer du phishing et du spam en quelques minutes, ce qui peut faire inscrire votre domaine et vos IP sur liste de blocage et suspendre votre compte. Le coût se mesure en réputation, et elle met des semaines à se rétablir.
Que signifie le moindre privilège pour les clés API ?
Cela signifie que chaque clé ne peut faire que ce que sa fonction exige, et rien de plus. Une clé utilisée par un formulaire web pour envoyer des e-mails ne doit pas pouvoir lire les contacts, modifier les domaines ni gérer la facturation. En cas de fuite, les dégâts se limitent à ce que cette clé était autorisée à faire.
Dois-je utiliser une seule clé pour tout ?
Non. Utilisez une clé distincte pour chaque application et chaque environnement. Si l'une fuit, vous ne révoquez que celle-ci, et vos journaux indiquent de quel système provenait un message. Les clés partagées rendent la réponse aux incidents lente et risquée.
Où dois-je stocker les clés API ?
Utilisez des variables d'environnement ou un gestionnaire de secrets, et chargez-les à l'exécution. Ne placez pas de clés dans le code source, dans le front-end d'un site web ou d'une application mobile, dans des dépôts publics, des tickets ou une messagerie instantanée. Ajoutez à votre fichier d'exclusion les fichiers de configuration qui contiennent des secrets.
À quelle fréquence dois-je renouveler les clés ?
Une règle courante est tous les 90 jours pour les clés de production, et immédiatement lorsqu'une personne ayant accès quitte l'entreprise, qu'un ordinateur portable est perdu ou qu'une fuite est soupçonnée. Plus important que l'intervalle : disposer d'un processus de rotation que vous avez déjà éprouvé.
Comment renouveler une clé sans interruption ?
Créez une nouvelle clé, ajoutez-la à votre stockage de secrets, déployez la modification, vérifiez que le trafic utilise la nouvelle clé et seulement ensuite révoquez l'ancienne. Ne révoquez jamais en premier, car cela provoque une panne le temps du déploiement.
Que faire si une clé fuite ?
Révoquez immédiatement la clé, créez-en une de remplacement, déployez-la, examinez les envois récents à la recherche de messages que vous n'avez pas envoyés, puis vérifiez les inscriptions sur liste de blocage et les pics de plaintes. Ensuite, déterminez comment elle a fuité et fermez cette voie.
Comment savoir qu'une clé est utilisée à mauvais escient ?
Recherchez un volume soudain, des destinataires nouveaux ou inhabituels, des envois à des heures inhabituelles, une hausse des rebonds ou des plaintes, et des requêtes provenant d'adresses IP inconnues. Des alertes sur le volume et le taux de rebond vous donnent un signal précoce.
Les identifiants SMTP sont-ils différents des clés API ?
Ils servent au même but, qui est de prouver que vous avez le droit d'envoyer, et demandent les mêmes précautions. Traitez le nom d'utilisateur et le mot de passe SMTP comme une clé API : un jeu par application, stocké comme un secret et renouvelé selon un calendrier. Consultez le guide des paramètres SMTP pour les détails de connexion.
Puis-je mettre une clé API dans une application mobile ou dans du JavaScript sur une page web ?
Non. Tout ce qui est livré sur un appareil ou dans un navigateur peut être extrait. Envoyez les e-mails depuis votre propre serveur, et faites appeler votre serveur par l'application ou la page, lequel appelle ensuite l'API d'e-mail avec la clé.