Nyc clouds

Reprendre le contrôle sur le relais des emails envoyés par vos applications

Share with your network!

Récemment, Proofpoint a examiné les données DMARC de 325 clients de Proofpoint Email Fraud Defense pour identifier leur origine. Nous avons constaté que les emails envoyés depuis les domaines de ces clients provenaient des sources suivantes :

  • Applications/systèmes (42 %)
  • Marketing (57 %)
  • Utilisateurs finaux (1 %)

Étant donné que les applications envoient 42 % des emails, les équipes responsables de la messagerie et de la sécurité font face à des enjeux de taille. Depuis toujours, les relais SMTP sur site aident à contrôler les messages générés par les applications qui sont envoyés par les domaines de leur entreprise. Ce contrôle permet de protéger plus facilement l’identité de marque de l’entreprise qui s’exprime au travers des emails. Sans cela, la réputation de l’entreprise et la sécurité de ses données sensibles risquent d’être mises à mal. De plus, sans cette protection, les destinataires sont davantage vulnérables aux fraudes de tous types.

Toutefois, avec la modernisation des applications, il devient difficile de maintenir ce contrôle. Si vous êtes responsable de la messagerie ou de la sécurité, vous êtes sans doute préoccupé par l’évolution des applications et ses implications sur le maintien sous contrôle de l’identité email de votre entreprise. Et vous n’êtes pas le seul dans ce cas.

Dans cet article, nous nous intéressons à l’évolution du contrôle des relais de messagerie et vous proposons quelques conseils pour regagner ce contrôle et ainsi protéger votre entreprise.

Contrôles de protection traditionnels

Par le passé, pour gérer les messages générés par les applications, les équipes mettaient en place et maintenaient les contrôles suivants :

  • Règles de rejet DMARC. Ces contrôles empêchent l’usurpation des domaines par des cybercriminels.
  • Filtrage des emails sortants. Des filtres empêchent l’envoi de spam, de malwares ou de données sensibles, que ce soit volontairement ou par accident.
  • Restrictions d’accès. Ces restrictions permettent aux équipes de contrôler les applications et systèmes autorisés à utiliser les relais SMTP.

Processus illustrant les règles de rejet DMARC, le filtrage des emails sortants et les restrictions d’accès

Relais traditionnel à l’aide d’une solution sur site

La modernisation des applications a introduit trois types de risques pour l’identité email d’une entreprise :

1. Migration vers le cloud

Les applications sur site migrent désormais vers le cloud. Or, dans le cloud, il n’existe pas de relais SMTP sécurisés.

En théorie, les relais SMTP sur site existants pourraient continuer à implémenter facilement les règles de rejet DMARC et le filtrage des emails sortants. Cependant, leur permettre de relayer des emails à partir d’environnements cloud externes est risqué, car l’opération implique de les transformer en « relais ouverts’ » (s’ils ne le sont pas déjà).

Migration d’applications vers le cloud, où il n’existe pas de relais SMTP modernes et sécurisés

Exposer les relais sur site à des environnements externes est risqué

2. Fournisseurs de services de messagerie

Les fournisseurs de services de messagerie envoient certes des emails en conformité à DMARC, mais ils demandent à leurs clients d’accorder des autorisations à des infrastructures partagées de grande envergure via les enregistrements SPF. Et malheureusement, les enregistrements SPF sont visibles par les cybercriminels. De plus, ils sont souvent mal sécurisés et dépourvus de filtrage des emails sortants.

Email conforme à DMARC pour lequel les clients doivent accorder une autorisation, un processus non sécurisé et dépourvu de filtrage des emails sortants

Les fournisseurs de services de messagerie donnent la priorité à la remise en boîte de réception, pas à la sécurité

3. SaaS

Ces applications sont externalisées à des fournisseurs tiers. Comme la plupart de ces derniers se concentrent sur le développement de leurs principaux produits et la différenciation de leur offre, à l’instar des fournisseurs de services de messagerie, la sécurité email n’est pas leur principale préoccupation.

  • Bien souvent, les fournisseurs SaaS ne sont pas en mesure d’envoyer des emails conformes aux exigences DMARC. Cela signifie que l’implémentation et la maintenance des règles de rejet DMARC constituent de vrais défis.
  • Comme dans le cas des fournisseurs de services de messagerie, ce scénario nécessite d’octroyer des autorisations à des infrastructures souvent non sécurisées au moyen d’enregistrements SPF.

Les applications SaaS sont externalisées à des tiers, qui ne peuvent pas envoyer des emails conformes à DMARC.

Les fournisseurs SaaS se concentrent sur le développement de leurs principaux produits, pas sur la messagerie

Proofpoint SER offre le contrôle requis

Avec autant de défis à relever, il est compliqué de redonner le contrôle des emails envoyés par les applications aux équipes chargées de la messagerie et de la sécurité. C’est pourtant précisément ce que fait Proofpoint Secure Email Relay (SER). Voici quelques-unes des stratégies de Proofpoint SER pour résoudre les problèmes que nous venons de relever :

Relais moderne

Le principe fondamental consistant à contrôler les emails envoyés par les applications via un relais n’a pas nécessairement changé. Ce qui a changé, en revanche, c’est la façon dont le relais est déployé et géré.

Du point de vue de l’architecture, la meilleure façon de prendre en compte la modernisation et la prolifération des applications est d’employer un modèle de relais en étoile. Dans cette configuration :

  • Tous les emails, indépendamment de leur environnement source, transitent par l’élément central du réseau. C’est à cet emplacement que les emails sont filtrés, que les règles sont appliquées et que les charges utiles sont chiffrées, entre autres fonctions.
  • Les branches de l’étoile sont des canaux supplémentaires qui permettent de déplacer les emails depuis divers environnements jusqu’à l’élément central du modèle en étoile. Par exemple, une branche légère interne au réseau peut rassembler des emails provenant de centaines, voire de milliers d’applications. Elle peut ensuite normaliser le flux de ces emails depuis le réseau d’un client vers l’élément central du relais. De même, une branche Amazon Simple Email Service (SES) peut utiliser SES Mail Manager pour router de façon conditionnelle les emails vers l’élément central du relais.

Sécurité

Généralement, lorsqu’un élément est modernisé, on peut s’attendre à ce que sa sécurité soit renforcée. Cependant, il vaut la peine d’exposer quelques considérations particulières qui s’appliquent à un relais de messagerie :

  • Les processus de développement et de déploiement de la solution doivent répondre aux bonnes pratiques et aux normes de sécurité les plus récentes. Par exemple, plutôt que de reposer sur un serveur de messagerie monolithique, Proofpoint SER possède une architecture cloud utilisant des microservices. Cette architecture en microservices se traduit par des systèmes sur mesure et plus légers, qui offrent une surface d’attaque réduite. Les microservices emploient également un système CI/CD moderne. Il est ainsi possible d’appliquer des correctifs de sécurité et d’apporter des modifications à l’environnement de production plus rapidement, sans pratiquement aucune interruption de service.
  • Les emails pris en charge par la solution doivent être chiffrés de bout en bout. Au niveau de la connexion entrante, les applications doivent se soumettre à une authentification stricte (TLS 1.2 au minimum, un chiffrement plus fort de préférence).
  • La solution doit proposer des fonctionnalités de sécurité telles que le blocage du spam et des malwares. Elle doit aussi protéger les informations sensibles et disposer de capacités de prévention des fuites de données (DLP). Tous les emails qui quittent le système à destination d’Internet doivent être dotés de signature DKIM avec des clés 2 048 bits en rotation tous les six mois. Nous vous recommandons par ailleurs de vous tenir informé de l’avancement de DKIM2.

Services

Le facteur humain est incontournable. C’est particulièrement vrai pour la mise hors service des relais sur site. Ces systèmes gèrent souvent plusieurs types d’emails de manière active, notamment :

  • Les emails envoyés par des centaines (voire des milliers) d’applications. Selon la stratégie de migration, il se peut que les propriétaires de ces applications doivent être consultés et soutenus au cours de la transition.
  • Les emails critiques tels que les réinitialisations de mot de passe et les codes MFA. Certaines applications doivent se voir accorder la priorité en termes de traitement et de calendrier de migration.

Architecture en étoile de Proofpoint SER

Architecture en étoile de Proofpoint SER

Protégez votre messagerie plus efficacement avec Proofpoint

Avec Proofpoint SER, votre entreprise peut mieux gérer l’ensemble des applications et des partenaires SaaS tiers qui envoient des emails en votre nom. En outre, en cas de compromission de l’une de ces sources, Proofpoint SER vous permet de la mettre immédiatement hors d’état de nuire. Ce point est particulièrement important pour les applications tierces qui étaient auparavant hors de votre contrôle, mais qui pouvaient porter gravement atteinte à la réputation de votre marque.

Que vous souhaitiez démanteler vos relais sur site, accroître votre sécurité avec la norme DKIM ou simplement renforcer votre contrôle sur tous les emails envoyés par des applications, Proofpoint SER est peut-être la solution que vous attendiez.

Vous souhaitez en savoir plus ?

Vous pouvez regarder une courte présentation vidéo ou consulter la page produit Proofpoint Secure Email Relay. Nous vous invitons également à contacter votre représentant commercial Proofpoint, qui vous aidera à déterminer si Proofpoint SER est l’outil qu’il vous faut.

Si vous êtes un client Amazon SES et souhaitez savoir comment il est possible de sécuriser le trafic email de vos applications avec Proofpoint SER, sachez que nous venons d’organiser un webinaire avec Amazon sur ce thème.

De même, n’hésitez pas à assister à notre prochain webinaire « Cloud Initiatives for Securely Sending Application-Generated Email ». Inscrivez-vous à l’événement ici.