Sécurité
La sécurité chez Mail.Land
Les contrôles que nous appliquons aujourd’hui, rédigés pour les revues de sécurité et les questionnaires fournisseurs. Nous ne mentionnons que ce qui est en place et nous indiquons ce qui n’est pas encore disponible.
État de la certification
Mail.Land ne détient aujourd’hui aucune certification de sécurité : ni certificat ISO 27001, ni rapport SOC 2, ni test d’intrusion tiers publié. Cette page décrit nos contrôles tels qu’ils sont. Lorsque cela changera, cette page changera aussi.
Contrôles en place
Chaque élément ci-dessous décrit un contrôle qui fonctionne aujourd’hui en production.
Hébergement et réseau
- Les systèmes de production fonctionnent chez Hetzner en Allemagne, à Nuremberg et Falkenstein. Nos bases de données et nos serveurs de messagerie se trouvent à Nuremberg.
- Une copie de sauvegarde secondaire chiffrée est conservée sur une infrastructure que nous exploitons à Varsovie, en Pologne.
- Le trafic web vers le site, le tableau de bord et l’API passe par Cloudflare, qui assure la protection contre les attaques DDoS.
- Les serveurs sont protégés par des pare-feu, et une détection automatisée (CrowdSec) bloque les tentatives de connexion abusives sur les serveurs de l’application et de la file de messages.
Chiffrement
- Les connexions au tableau de bord et à l’API utilisent HTTPS.
- Le relais SMTP n’accepte l’authentification qu’une fois la connexion chiffrée avec STARTTLS.
- La livraison vers les serveurs de messagerie des destinataires utilise TLS lorsque le serveur destinataire le prend en charge.
- Les clés API sont stockées uniquement sous forme de hachages et ne peuvent donc pas être relues. Les mots de passe sont stockés sous forme de hachages bcrypt.
- Les secrets de l’authentification à deux facteurs et les secrets de signature des webhooks sont stockés chiffrés.
- Les sauvegardes hors site sont chiffrées avant de quitter nos serveurs. Nous détenons les clés ; le fournisseur de stockage ne les détient pas.
Sécurité du compte
- L’authentification à deux facteurs avec une application d’authentification est disponible pour chaque utilisateur, avec des codes de récupération à usage unique.
- L’authentification unique (SSO) avec Google, Microsoft, Okta ou tout fournisseur OpenID Connect est incluse dans tous les plans. Vous pouvez imposer le SSO pour votre domaine de messagerie, ce qui désactive la connexion par mot de passe pour ce domaine.
- Rôles d’équipe : Owner, Admin, Member et Viewer.
- Un journal d’activité enregistre les actions effectuées dans votre compte.
- Les tentatives de connexion échouées répétées sont temporairement bloquées.
Pas encore disponible
- Un compte ne peut pas encore imposer l’authentification à deux facteurs à tous ses membres ; chaque utilisateur l’active pour lui-même.
- L’authentification unique SAML et les clés d’accès (passkeys) ne sont pas prises en charge.
Clés API
- Chaque clé peut être limitée à l’API ou au SMTP, à certains domaines d’envoi et à une liste d’adresses IP autorisées.
- Les clés peuvent avoir une date d’expiration et leurs propres limites de débit.
- Lorsque vous renouvelez une clé, l’ancienne clé continue de fonctionner pendant le délai de grâce que vous fixez, ce qui vous permet de déployer la nouvelle sans interruption de service.
- Une clé sandbox configurée en mode journalisation seule vous permet d’effectuer des tests sans livrer aucun e-mail.
Authentification des e-mails
- Vous ne pouvez envoyer qu’à partir d’un domaine que vous avez vérifié par DNS. La vérification contrôle vos enregistrements SPF, DKIM, DMARC et return-path.
- Mail.Land ajoute sa propre seconde signature DKIM à chaque message, afin que les fournisseurs de messagerie puissent identifier la plateforme qui l’a envoyé.
Webhooks signés
- Les requêtes des webhooks d’événements sont signées avec HMAC-SHA256, à l’aide d’un secret propre à chaque webhook.
- L’en-tête de signature contient un horodatage, ce qui permet à votre endpoint de rejeter les requêtes anciennes ou rejouées. Notre documentation recommande une fenêtre de cinq minutes.
Prévention des abus
- Chaque client accepte notre Politique d’utilisation acceptable.
- Avant qu’un compte soit autorisé à envoyer, nous vérifions l’organisation et ses bénéficiaires effectifs au regard des listes officielles de sanctions.
- Les liens des campagnes, ainsi que les liens suivis lorsqu’ils sont cliqués, sont vérifiés auprès de Google Web Risk pour détecter l’hameçonnage et les logiciels malveillants.
- Toute personne peut signaler un abus du service au moyen de notre formulaire de signalement d’abus.
Exploitation
- Les services de production sont supervisés au moyen de métriques, de journaux et d’alertes centralisés.
- Les restaurations de sauvegardes sont testées dans des environnements isolés.
- Nos dépendances .NET font l’objet d’une analyse des vulnérabilités connues dans notre chaîne de compilation, et toute découverte de gravité élevée ou critique bloque la compilation.
- L’accès aux systèmes de production et aux données personnelles est limité à un petit nombre de membres du personnel autorisés.
Notification des incidents et des violations de données
Si une violation de données à caractère personnel affecte vos données, nous vous la notifions dans les meilleurs délais après en avoir pris connaissance, comme l’exige l’article 33, paragraphe 2, du RGPD. La notification est adressée à votre contact sécurité désigné ou, à défaut de désignation, aux utilisateurs Owner et Admin de votre compte. La Section 6 du DPA précise le contenu de la notification et la manière dont nous vous aidons à remplir vos propres obligations.
Signaler une vulnérabilité
Si vous découvrez un problème de sécurité dans Mail.Land, écrivez-nous par e-mail. Merci d’indiquer les étapes permettant de le reproduire et les parties du service concernées. Nous nous efforçons d’accuser réception des signalements sous 72 heures et nous pratiquons la divulgation coordonnée. Nous ne proposons pas de programme de bug bounty rémunéré.
- Contact sécurité:
- [email protected]
Questionnaires de sécurité
Envoyez votre questionnaire à notre contact sécurité. Nous y répondons à partir des faits présentés sur cette page, dans le DPA et dans notre Politique de confidentialité. Pour les questions de protection des données, consultez notre page RGPD.
Questions fréquentes
Disposez-vous d’un rapport SOC 2 ou d’une certification ISO 27001 ?
Non. Mail.Land ne détient aujourd’hui aucune certification de sécurité. Cette page présente à la place les contrôles que nous appliquons.
Où mes données sont-elles hébergées ?
Nos systèmes de production fonctionnent chez Hetzner en Allemagne, avec une copie de sauvegarde chiffrée à Varsovie, en Pologne. Certains fournisseurs, tels que Cloudflare, Stripe et Google, peuvent traiter des données limitées en dehors de l’UE. Notre page RGPD les énumère un par un.
Pouvons-nous imposer l’authentification à deux facteurs à notre équipe ?
Pas encore. Chaque utilisateur peut activer l’authentification à deux facteurs et vous pouvez imposer le SSO pour votre domaine de messagerie, mais un compte ne peut pas encore imposer l’authentification à deux facteurs à tous ses membres.
Prenez-vous en charge SAML ?
Non. L’authentification unique fonctionne avec Google, Microsoft, Okta et tout fournisseur OpenID Connect.
Comment vérifier qu’un webhook provient bien de Mail.Land ?
Vérifiez l’en-tête X-MLND-Signature : un HMAC-SHA256 de l’horodatage et du corps de la requête, calculé avec le secret de votre webhook comme clé. Notre documentation propose des exemples dans huit langages.
Des questions sur la sécurité ?
Écrivez à notre contact sécurité ou lisez le DPA pour la liste complète des mesures.