Amélioration du flux de messagerie avec MTA-STS

Article
08/10/2024

La prise en charge de la norme SMTP MTA Strict Transport Security (MTA-STS) est ajoutée à Exchange Online. La norme a été développée pour garantir que TLS est toujours utilisé pour les connexions entre les serveurs de messagerie. Il fournit également un moyen d’envoyer des serveurs pour vérifier que le serveur de réception dispose d’un certificat approuvé. Si TLS n’est pas proposé ou si le certificat n’est pas valide, l’expéditeur refuse de remettre des messages. Ces nouvelles vérifications améliorent la sécurité globale de SMTP et protègent contre les attaques de l’intercepteur.

MTA-STS peut être divisé en deux scénarios : la protection entrante et sortante. La protection entrante couvre la protection des domaines hébergés dans Exchange Online avec MTA-STS. La protection sortante couvre les validations MTA-STS effectuées par Exchange Online lors de l’envoi d’e-mails à des domaines protégés par MTA-STS.

Conseil

Si vous n’êtes pas un client E5, utilisez la version d’évaluation de 90 jours des solutions Microsoft Purview pour découvrir comment des fonctionnalités Supplémentaires purview peuvent aider vos organization à gérer les besoins en matière de sécurité et de conformité des données. Commencez maintenant sur le hub d’évaluation Microsoft Purview. En savoir plus sur les conditions d’inscription et d’essai.

Protection sortante

Tous les messages envoyés en sortie de Exchange Online aux destinataires protégés par MTA-STS sont validés avec ces vérifications de sécurité supplémentaires définies par la norme MTA-STS. Les administrateurs n’ont rien à faire pour l’appliquer. Notre implémentation sortante respecte les souhaits des propriétaires de domaine destinataire via leur stratégie MTA-STS. MTA-STS fait partie de l’infrastructure de sécurité de Exchange Online et est donc toujours activé (comme d’autres fonctionnalités SMTP de base).

MTA-STS sortant peut empêcher la remise d’e-mails en fonction des résultats de la validation MTA-STS sur le domaine de destination. Si le domaine n’est pas sécurisé et que la stratégie MTA-STS est définie sur Appliquer, une remise de remise peut être retournée à l’expéditeur avec l’un des codes d’erreur suivants :

Code d'erreur	Description	Cause possible	Informations supplémentaires
5.4.8	Échec de la validation MTA-STS des hôtes MX de « {domaine} »	L’hôte MX de destination n’était pas l’hôte attendu selon la stratégie STS du domaine.	Cette erreur indique généralement un problème avec la stratégie MTA-STS du domaine de destination ne contenant pas l’hôte MX. Pour plus d’informations sur MTA-STS, consultez https://datatracker.ietf.org/doc/html/rfc8461.
5.7.5	Échec de la validation MTA-STS du certificat distant. Raison : {validityStatus}	Le certificat du serveur de messagerie de destination doit être chaîné à une autorité de certification racine approuvée, et le nom commun ou autre nom de l’objet doit contenir une entrée pour le nom d’hôte dans la stratégie STS.	Cette erreur indique généralement un problème avec le certificat du serveur de messagerie de destination. Pour plus d’informations sur MTA-STS, consultez https://datatracker.ietf.org/doc/html/rfc8461.

Protection entrante

Les propriétaires de domaine peuvent prendre des mesures pour protéger les e-mails envoyés à leurs domaines avec MTA-STS, si leur enregistrement MX pointe vers Exchange Online. Si votre enregistrement MX pointe vers un service tiers intermédiaire, vous devez déterminer si les exigences MTA-STS sont remplies par ces derniers, puis suivre leurs instructions.

Une fois MTA-STS configuré pour votre domaine, tous les messages envoyés par les expéditeurs qui prennent en charge MTA-STS effectuent les validations définies par la norme pour garantir une connexion sécurisée. Si vous recevez un e-mail d’un expéditeur qui ne prend pas en charge MTA-STS, l’e-mail sera toujours remis sans la protection supplémentaire. De même, il n’y a aucune interruption des messages si vous n’utilisez pas encore MTA-STS, mais que l’expéditeur le prend en charge. Le seul scénario où les messages ne sont’ pas remis est lorsque les deux côtés utilisent MTA-STS et que la validation MTA-STS échoue.

Guide pratique pour adopter MTA-STS

MTA-STS permet à un domaine de déclarer la prise en charge de TLS et de communiquer l’enregistrement MX et le certificat de destination à attendre. Il indique également ce qu’un serveur d’envoi doit faire en cas de problème. Cette communication s’effectue via une combinaison d’un enregistrement TXT DNS et d’un fichier de stratégie publié en tant que page web HTTPS. La stratégie protégée par HTTPS introduit une autre protection de sécurité que les attaquants doivent surmonter.

L’enregistrement TXT MTA-STS d’un domaine indique la prise en charge de MTA-STS à un expéditeur, après quoi la stratégie MTA-STS basée sur HTTPS du domaine est récupérée par l’expéditeur. L’enregistrement TXT doit contenir v=STSv1 ; jusqu’à ce que STSv2 soit pris en charge et l’ID de la stratégie. L’ID DOIT être unique pour le propriétaire du domaine et la stratégie, car une modification de l’ID signale aux expéditeurs qu’ils doivent récupérer à nouveau la stratégie. L’ID n’a pas besoin d’être globalement unique, ne vous inquiétez pas des ID de stratégie des autres propriétaires de domaine. Après toute mise à jour de stratégie MTA-STS, vous devez mettre à jour l’ID, sinon les expéditeurs continueront à utiliser des stratégies mises en cache pour votre domaine jusqu’à l’expiration du max_age de la stratégie mise en cache.

Un modèle reproductible pour définir un ID unique consiste à utiliser l’heure UTC comme suit :
id=<yyyymmddhh0000>Z;

L’enregistrement TXT suivant est un exemple qui déclare la prise en charge de MTA-STS, l’ID a été défini à 8 h 00, heure UTC du 1er janvier 2022 :

_mta-sts.contoso.com. 3600 IN TXT v=STSv1; id=20220101080000Z;

La stratégie MTA-STS d’un domaine doit se trouver à une URL prédéfinie hébergée par l’infrastructure web du domaine. La syntaxe de l’URL est https://mta-sts.<domain name>/.well-known/mta-sts.txt. Par exemple, la stratégie de Microsoft.com se trouve à l’adresse suivante : https://mta-sts.microsoft.com/.well-known/mta-sts.txt.

version: STSv1
mode: enforce
mx: *.mail.protection.outlook.com
max_age: 604800

Tout client dont les enregistrements MX pointent directement vers Exchange Online peut spécifier dans sa propre stratégie les mêmes valeurs que celles affichées dans https://mta-sts.microsoft.com/.well-known/mta-sts.txt. Les informations requises uniques dans la stratégie sont l’enregistrement MX qui pointe vers Exchange Online (*.mail.protection.outlook.com) et le même certificat est partagé par tous les clients Exchange Online. Exchange Online n’autorise qu’un seul organization à recevoir des e-mails pour un domaine donné afin que l’utilisation d’un caractère générique n’affaiblisse pas la sécurité. Toutefois, ce n’est peut-être pas le cas pour d’autres services de messagerie. Il est possible de publier votre stratégie en mode test pour vous assurer qu’elle est valide avant de la modifier en mode d’application . Il existe des outils de validation tiers qui peuvent vérifier votre configuration.

Ces stratégies ne sont pas quelque chose que Exchange Online pouvez héberger pour le compte des clients ; par conséquent, les clients doivent configurer la stratégie STS de leur domaine à l’aide des services qu’ils préfèrent. Les services Azure peuvent être facilement utilisés pour l’hébergement de stratégie. Vous trouverez une procédure pas à pas de configuration plus loin dans cet article. La stratégie doit être protégée par HTTPS avec un certificat pour le sous-domaine mta-sts.<domain name>.

Une fois l’enregistrement TXT DNS créé et le fichier de stratégie disponible à l’URL HTTPS requise, le domaine est protégé par MTA-STS. Des détails sur MTA-STS sont disponibles dans RFC 8461.

Configuration de MTA-STS entrant avec les services Azure

Remarque

Ces flux de configuration ont été développés pour aider Microsoft Exchange Online clients à héberger leur stratégie MTA-STS à l’aide de ressources Azure. Ce flux de configuration suppose que vous êtes un client Exchange Online qui connaît le fonctionnement de MTA-STS et ses exigences. Pour plus d’informations sur le protocole au-delà de cette rubrique, consultez RFC8461.

Deux ressources Azure peuvent être utilisées pour héberger la stratégie MTA-STS : Azure Static Web App et Azure Functions. Bien que cet article explique comment déployer la stratégie à l’aide des deux ressources, la méthode recommandée est Azure Static Web App , car elle est conçue pour héberger des pages statiques telles que la stratégie STS, et Azure simplifie la configuration en fournissant un certificat TLS pour la page web MTA-STS prête à l’emploi, sans nécessiter plus de configuration. Si vous ne pouvez pas utiliser Azure Static Web App, vous pouvez également héberger votre stratégie en tant que code serverless à l’aide de Azure Functions. Cette approche n’est pas la méthode recommandée, car Azure Functions est une fonctionnalité conçue pour d’autres scénarios et n’émet pas de certificat TLS automatiquement, contrairement à Azure Static Web Apps. Par conséquent, l’utilisation de Azure Functions pour MTA-STS nécessite que vous émettez votre propre « mta-sts . » votre domaine] » et liez-le à la fonction.

Quelle que soit l’approche que vous avez adoptée, nous vous encourageons à vérifier si votre stratégie a été correctement configurée et si le temps de réponse est acceptable ( le délai d’expiration selon les conseils RFC est de 60 secondes).

Ces flux de configuration sont destinés à fournir uniquement des informations techniques sur les fonctionnalités Azure qui peuvent être utilisées pour héberger la stratégie MTA-STS et ne fournissent aucune information sur la facturation ou les coûts des fonctionnalités Azure. Si vous souhaitez connaître les coûts des fonctionnalités Azure, utilisez la calculatrice de prix Azure.

Option 1 (RECOMMANDÉE) : Application web statique Azure

Créez un organization Azure DevOps ou utilisez un organization qui existe déjà. Dans cet exemple, un organization appelé « ContosoCorporation » sera utilisé pour héberger la stratégie MTA-STS.
Dans Repos > Files, clonez votre dépôt dans l’IDE de votre choix. Dans cet exemple, le référentiel est cloné dans Visual Studio.
Une fois le référentiel cloné, créez le chemin home\.well-known\du dossier . Ensuite, créez les fichiers suivants :
- Fichier 1 : home.well-known\mta-sts.txt
  
  Remarque
  
  Cette configuration permet uniquement Exchange Online de recevoir des messages au nom de votre domaine. Si vous utilisez plusieurs fournisseurs de messagerie, vous devez également référencer des hôtes MX pour les domaines de ces autres fournisseurs. Les caractères génériques ou « * » ne doivent pas être utilisés comme préfixe MX dans tous les scénarios MTA-STS ; Les paramètres ci-dessous sont spécifiques à Exchange Online uniquement et ne doivent PAS être utilisés comme instructions générales pour la configuration de MTA-STS.
  1. Entrez le texte suivant dans le mta-sts.txt fichier :
```
version: STSv1
mode: testing
mx: *.mail.protection.outlook.com
max_age: 604800
```
    Remarque
    
    Il est recommandé de définir initialement le mode de stratégie comme test. Ensuite, à la fin de la configuration et après avoir vérifié que la stratégie fonctionne comme prévu, mettez à jour le mta-sts.txt fichier de sorte que le mode soit appliqué.
    
    Le fichier doit uniquement contenir le contenu, comme illustré dans la capture d’écran suivante :
- Fichier 2 : home\index.html
  1. Créez un index.html fichier et entrez-y le code suivant :
```
<!DOCTYPE html>
<html lang="en">

<head>
<meta charset="UTF-8">
<title>MTA-STS</title>
</head>

<body>
<h1>MTA-STS Static Website index</h1>
</body>

</html>
```
    Le fichier doit uniquement contenir le contenu, comme illustré dans la capture d’écran suivante :
    
    Une fois le chemin d’accès au dossier et les fichiers créés, n’oubliez pas de valider les modifications et de les envoyer (push) dans votre branche main.
Créez une application web statique Azure avec la configuration suivante :
- Nom : MTA-STS-StaticWebApp
- Type de plan : Standard
- Détails du déploiement : Azure DevOps
- Organisation : ContosoCorporation
- Projet : MTA-STS_Project
- Dépôt : MTA-STS_Project
- Branche : master
- Préréglages de build : Angular
- Emplacement de l’application : /home
Une fois la création de l’application web statique terminée et la ressource approvisionnée, accédez à Vue d’ensemble > Gérer le jeton de déploiement, puis copiez le jeton tel qu’il sera utilisé à l’étape suivante.
Accédez à Pipelines > Créer un pipeline > Azure Repos Git > MTA-STS_Project, puis effectuez les tâches subordonnées suivantes :
1. Accédez à Variables > Nouvelle variable et tapez ce qui suit :
  1. Nom : jeton
  2. Valeur : (collez le jeton que vous avez copié précédemment, à l’étape 5)
2. Une fois la variable enregistrée, revenez à Passer en revue votre yaML de pipeline et collez le code yml suivant, enregistrez-le et exécutez-le :
```
trigger:
- main

pool:
vmImage: ubuntu-latest

steps:
- checkout: self
submodules: true
- task: AzureStaticWebApp@0
inputs:
 app_location: '/home'
 azure_static_web_apps_api_token: $(token)
```
  Dans Azure DevOps, pendant le déploiement, si vous rencontrez l’erreur Aucun parallélisme hébergé n’a été acheté ou accordé, demandez via ce formulaire ou implémentez une configuration via paramètres de l’organisation Travaux >> parallèles microsoft hébergés > Modifier > les travaux parallèles payants de sorte que les « travaux parallèles payants » soient autorisés.
Une fois le travail terminé, vous pouvez valider le déploiement via le Portail Azure en accédant à Azure Static Web App > Environment > Browser. Vous devez voir le index.html contenu du fichier.
Ajoutez votre domaine personnel dans Azure Static Web App > Domaines personnalisés > Ajouter. Vous devez créer un enregistrement CNAME via votre fournisseur DNS (par exemple, GoDaddy) pour vérifier si la zone vous appartient. Une fois la validation terminée, Azure émet un certificat et le lie automatiquement à votre application web statique.
Vérifiez si votre stratégie MTA-STS est publiée via : https://mta-sts.[votre domaine]/.well-known/mta-sts.txt.
Créez l’enregistrement DNS TXT MTA-STS via votre fournisseur DNS. Le format est :
```
Hostname: _mta-sts.<domain name>
TTL: 3600 (recommended)
Type: TXT
Text: v=STSv1; id=<ID unique for your domain’s STS policy>Z;
```
Remarque

Vous trouverez un exemple d’enregistrement TXT MTA-STS dans Guide pratique pour adopter MTA-STS.
Une fois l’enregistrement TXT disponible dans DNS, validez votre configuration MTA-STS. Une fois la configuration validée, mettez à jour le mta-sts.txt fichier afin que le mode de stratégie soit appliqué, puis mettez à jour votre ID de stratégie dans l’enregistrement TXT.

Option 2 : Fonction Azure

Créez une application de fonction Azure avec la configuration suivante :
- Nom de l’application de fonction : [Au choix]
- Publier : Code
- Pile d’exécution : .NET
- Version : 6
- Système d’exploitation : Windows
- Type de plan : [Au choix]
Ajoutez votre domaine personnalisé à l’application de fonction. Vous devez créer un enregistrement CNAME pour vérifier si le domaine vous appartient.
Liez votre « mta-sts . [votre domaine] » à l’application de fonction.
Dans Fichier d’application, ajoutez l’extension suivante à la host.json de votre application de fonction pour éliminer routePrefix. Cet ajout est nécessaire pour supprimer /api de l’URL de la fonction.
```
"extensions": {
  "http": {
    "routePrefix": ""
  }
}
```
Dans votre application de fonction, accédez à Créer des fonctions > et configurez les paramètres suivants :

Remarque

Bien que cet exemple décrive le développement de la fonction via le portail, vous êtes libre d’utiliser VS Code ou tout autre outil de votre choix.
- Environnement de développement : [Comme vous le faites, cet exemple utilise « Développer dans le portail »]
- Sélectionner un modèle : déclencheur HTTP
- Nouvelle fonction : [Au choix]
- Niveau d’autorisation : Anonyme
Une fois la fonction créée, ouvrez Code + Test et développez en C# une réponse HTTP asynchrone simple qui sera votre stratégie MTA-STS. L’exemple suivant indique que Exchange Online est censé recevoir des e-mails :

Remarque

Il est recommandé de définir initialement le mode de stratégie comme test. Ensuite, à la fin de la configuration et après avoir vérifié que la stratégie fonctionne comme prévu, mettez à jour le mta-sts.txt fichier de sorte que le mode soit appliqué.
Dans Http d’intégration > (req) , modifiez le déclencheur avec les valeurs suivantes :
- Modèle de route : .well-known/mta-sts.txt
- Méthodes HTTP sélectionnées : GET
Vérifiez que votre stratégie MTA-STS est publiée via : https://mta-sts.[votre domaine]/.well-known/mta-sts.txt.
Créez l’enregistrement DNS TXT MTA-STS via votre fournisseur DNS au format suivant :
```
Hostname: _mta-sts.<domain name>
TTL: 3600 (recommended)
Type: TXT
Text: v=STSv1; id=<ID unique for your domain’s STS policy>Z;
```
Remarque

Vous trouverez un exemple d’enregistrement TXT MTA-STS dans Guide pratique pour adopter MTA-STS.
Une fois l’enregistrement TXT disponible dans DNS, validez votre configuration MTA-STS. Une fois la configuration validée, mettez à jour le mta-sts.txt fichier afin que le mode de stratégie soit appliqué, puis mettez à jour votre ID de stratégie dans l’enregistrement TXT.