Sophos Email : configurer TLS et Secure Message en toute sécurité

Une Secure Message policy définit comment Sophos Email sécurise les messages et ce qui se passe si la méthode choisie est impossible. Pour la plupart des connexions TLS, Preferred TLS 1.3 constitue le point de départ le plus robuste : Sophos tente TLS 1.3, puis utilise TLS 1.2 si nécessaire. N’imposez Required TLS 1.3 ou Required TLS 1.2 qu’aux partenaires dont le système d’envoi ou de réception satisfait réellement cette exigence précise.

Procédure rapide : activez d’abord TLS 1.3 et les chiffrements requis sur votre serveur ou service de messagerie, puis testez le flux vers Sophos. Sous My Products > Email Security > Policies, créez une policy Secure Message, définissez le périmètre interne et, si nécessaire, externe, choisissez le sens et la méthode sous Settings, puis placez un petit groupe pilote sur Policy is enforced. Pour les messages sortants, décidez préalablement si un échec TLS peut autoriser une remise non chiffrée ou déclencher Fallback to push encrypt the entire message. Vérifiez ensuite dans Message History la version TLS et l’état de remise pour chaque partenaire et chaque sens.

Avertissement : TLS doit être actif sur votre serveur ou service de messagerie avant toute configuration d’une méthode Secure Message. Votre passerelle doit notamment prendre en charge TLS 1.3 avant d’imposer Required TLS 1.3. Sinon, la connexion à Sophos peut être interrompue et les messages entrants comme sortants peuvent ne plus circuler.

Consigner les prérequis et le retour arrière

Ce guide concerne Sophos Email dans Sophos Fusion (anciennement Sophos Central), et non Mail Protection exécuté sur une Sophos Firewall. En EMS mode, il est impossible de configurer les Secure Message Policies.

Avant le changement, consignez :

le nom, le périmètre, l’ordre, le sens et l’état d’application actuels de la policy, ainsi que toute heure de désactivation programmée ;
les utilisateurs, groupes ou domaines internes et les adresses ou domaines externes concernés ;
les versions TLS et chiffrements de votre serveur et des correspondants pilotes ;
si le correspondant présente un certificat valable pour son domaine destinataire ;
le choix de repli autorisé pour chaque partenaire ;
les expéditeurs et destinataires de test, Message-ID, fenêtre de changement et responsables des deux plateformes.

Sophos recommande TLS 1.3. La chaîne de chiffrements documentée est exactement TLSv1.2+FIPS:kRSA+FIPS:!eNULL:!aNULL. TLS 1.0 et TLS 1.1 ne sont plus pris en charge pour la remise entrante ou sortante depuis le 1er janvier 2024. Votre serveur ne doit donc pas être limité à ces anciennes versions.

Pour le retour arrière, conservez des captures ou un export de la policy précédente. Une nouvelle policy pilote ou son clone peut être remis sur Policy Bypassed, puis l’ordre précédent restauré. Ne supprimez aucune policy fonctionnelle avant la fin des tests.

Choisir consciemment la méthode et le comportement en cas d’échec

TLS : chiffrement du transport dans le client habituel

Secure using TLS protège la connexion SMTP pendant le transport ; expéditeur et destinataire continuent d’utiliser leur client habituel. Cela ne signifie pas que le message reste dans un conteneur chiffré après sa remise dans la boîte.

Les niveaux TLS ont des conséquences différentes :

Preferred TLS 1.3 tente TLS 1.3 et utilise TLS 1.2 si le correspondant ne prend pas en charge TLS 1.3. Sophos recommande ce choix plus souple, moins susceptible d’interrompre les échanges.
Required TLS 1.3 n’accepte que TLS 1.3. Si le correspondant ne le prend pas en charge, aucune autre version TLS n’est utilisée.
Required TLS 1.2 n’accepte que TLS 1.2. TLS 1.3 ne le remplace pas dans ce mode ; la version choisie est imposée.

Sans cette obligation, Sophos tente par défaut TLS lorsqu’une connexion TLS est possible. Ce comportement opportuniste favorise la compatibilité, mais ne garantit pas que chaque correspondant sera joint de façon chiffrée. Si une version précise ou un contrôle de certificat est contractuel, créez pour le partenaire un périmètre Required étroit et documentez un test d’échec.

Pour les connexions sortantes avec Required TLS 1.3 ou Required TLS 1.2, vous pouvez activer Verify certificate. Sophos vérifie alors que le certificat a été émis pour le domaine destinataire. En cas d’échec, le message n’est pas remis. Placez donc le véritable domaine destinataire dans le périmètre externe et vérifiez l’hôte et le certificat présentés par son parcours MX ; un domaine partenaire au nom proche ne convient pas.

Ne pas confondre Push Encryption ou Portal Encryption avec TLS

Push Encryption n’est disponible qu’en sortie. Sophos convertit le contenu en document protégé par mot de passe ; les pièces jointes Microsoft Office, ZIP et PDF utilisent leur chiffrement natif, tandis que d’autres formats peuvent être fournis en PDF. Lors du premier envoi, le destinataire crée un mot de passe Sophos Secure Message depuis la notification, dont le lien expire après 30 jours. Le mot de passe ne vaut que pour les messages de la même région que le message d’origine. Pour l’ouverture par le destinataire, l’utilisation du mot de passe et les réponses sécurisées, consultez Exploiter le chiffrement Portal et Push de Sophos Email.

Portal Encryption est également réservé à la sortie et nécessite une licence Sophos Email avec Portal Encryption Add-on. Le destinataire lit et répond dans Sophos Secure Message et crée un compte au premier message. Personnalisation, administration des destinataires, expiration et rappel relèvent d’une exploitation distincte du portail ; cet article ne fait que sélectionner la méthode dans la policy.

Secure using S/MIME suppose des autorités, certificats utilisateur et destinataire et clés privées déjà configurés. S/MIME peut signer sans forcément chiffrer. Provisionnement, confiance, extraction et réinitialisation des certificats relèvent donc d’une procédure S/MIME séparée et ne sont pas remplacés par Verify certificate de TLS.

Pour le TLS sortant vers un correspondant sans TLS, Sophos propose Allow unencrypted delivery ou Fallback to push encrypt the entire message ; Sophos recommande le repli Push. Si le repli Push est configuré et que la négociation TLS échoue, Sophos envoie le message avec Push Encryption au lieu de le placer en file pour de nouvelles tentatives TLS. N’autorisez la remise non chiffrée que si la classification des données le permet explicitement. Le repli Push ne convient que si les destinataires peuvent ouvrir les documents protégés et si l’inscription initiale est acceptable. Sans repli autorisé ni négociation TLS fonctionnelle, aucun retour silencieux au texte clair ne doit être attendu.

Créer et limiter la Secure Message policy

Ouvrez My Products > Email Security > Policies, puis cliquez sur Add Policy.
Sélectionnez Secure Message, puis Continue. Donnez un nom explicite, par exemple SM-Outbound-Partner-TLS13.
Sous Internal, ajoutez utilisateurs, groupes ou domaines. Une correspondance dans l’une des listes suffit. Survolez un utilisateur pour vérifier son adresse.
Pour une règle partenaire, ouvrez External et ajoutez l’adresse ou le domaine exact, manuellement ou depuis un fichier. Vérifiez inclusion ou exclusion ; la valeur par défaut est Include all. La policy s’applique lorsqu’une entrée interne communique avec une entrée externe.
Ouvrez Settings, choisissez Inbound ou Outbound, puis activez Secure inbound messages ou Secure outbound messages.
Sous Select the method to secure messages, choisissez la méthode approuvée. Pour TLS, définissez ensuite Preferred TLS 1.3, Required TLS 1.3 ou Required TLS 1.2.
Si nécessaire pour un partenaire Required TLS sortant, activez Verify certificate. Définissez explicitement le comportement de repli ou en cas d’échec ; ne le déduisez pas du nom.
Pour Push ou Portal Encryption, choisissez la langue des notifications et messages d’inscription destinés au destinataire.
Sous Choose how to secure, décidez de protéger tous les messages ou de laisser l’utilisateur déclencher la protection par un tag d’objet. Le tag fixe secure: déclenche toujours le chiffrement, même avec des déclencheurs personnalisés. secureTest: ou secureFull: doivent apparaître intégralement et exactement au début de l’objet ; une sous-chaîne ne suffit pas.
Placez la policy pilote sur Policy is enforced, enregistrez et vérifiez sa priorité. Une date et une heure de désactivation automatique peuvent aussi être définies.

Pour plusieurs périmètres similaires, utilisez Clone. Un clone démarre sur Policy Bypassed, le clone de la Base Policy ne contient aucun utilisateur, groupe ou domaine, et il est par défaut prioritaire sur l’original. Vérifiez périmètre, paramètres et ordre avant Policy is enforced.

Les tenants migrés peuvent afficher des policies dont le nom commence par Migrated. Elles contiennent les anciens paramètres TLS et de chiffrement de Global Settings, ainsi que les utilisateurs et domaines protégés lors de la migration. Elles peuvent être modifiées, renommées, fusionnées ou supprimées, mais seulement après comparaison du périmètre, de la méthode, du repli et de la priorité avec l’état cible actuel.

Interaction avec Data Control

Une action de chiffrement sortant d’une policy Data Control remplace la méthode choisie dans la Secure Message policy. Si un message utilise Push ou Portal au lieu de TLS, contrôlez la Secure Message policy et les règles Data Control correspondantes. Contrôlez séparément le périmètre et l’ordre, car chaque famille a une fonction différente.

Valider avec des destinataires représentatifs

Pour la recette, envoyez des messages contrôlés et non confidentiels à au moins un destinataire dans le périmètre et un témoin hors périmètre. Le plan de test TLS partenaire comprend :

un correspondant prenant en charge la version choisie et présentant, avec Verify certificate, un certificat correspondant ;
un correspondant prenant en charge TLS 1.2 mais pas TLS 1.3 afin de tester Preferred TLS 1.3 ;
un test négatif autorisé où l’exigence TLS ou de certificat n’est pas satisfaite ;
avec repli Push, un destinataire qui teste notification, création du mot de passe et ouverture ;
avec tags d’objet, un message avec déclencheur exact, un incomplet et un sans déclencheur.

Dans Message History, ouvrez Filter à gauche, choisissez la catégorie Secure message et filtrez selon la version TLS. Ouvrez ensuite l’objet. Dans Message Details, le survol des trois points sous Status indique si la connexion a été sécurisée par TLS et la version authentifiée. Si Sophos n’a pas pu vérifier la signature de l’autorité émettrice, SMTP Text signale que la remise TLS n’était pas fiable.

Une recette réussie consigne nom et priorité de la policy, périmètres interne et externe, Message-ID, horodatage, destinataire, méthode, version TLS observée, résultat du certificat, repli et état final chez le destinataire. Une entrée Message History ne prouve pas à elle seule que le destinataire a pu lire le message.

Examiner les échecs TLS, la file et les certificats

Si Sophos Email ne peut pas établir une connexion TLS requise et qu’aucun repli configuré ne prend en charge le message, l’e-mail n’est pas envoyé. Sophos le place jusqu’à sept jours dans la file de nouvelle remise, puis le supprime. Chaque tentative liée à TLS crée une entrée au format Processing: Check TLS ; après l’échec final, le journal indique que le message a été supprimé en raison de la TLS policy. Ce mécanisme ne convient pas pour tester en production pendant sept jours un paramètre Required erroné.

Contrôlez dans cet ordre :

La Secure Message policy attendue est-elle sur Policy is enforced, avec les bons périmètres et la bonne priorité ?
Une action Data Control remplace-t-elle la méthode ou le tag fixe secure: déclenche-t-il le chiffrement ?
Votre serveur et le correspondant prennent-ils en charge la version choisie ? TLS 1.0 et 1.1 ne sont pas des replis.
TLS et les chiffrements requis sont-ils actifs, notamment TLSv1.2+FIPS:kRSA+FIPS:!eNULL:!aNULL ?
Avec Verify certificate, le certificat correspond-il au vrai domaine destinataire et Sophos peut-il vérifier l’autorité émettrice ?
Message History, Processing: Check TLS et SMTP Text indiquent-ils un problème de version, de confiance ou de négociation ?

Si la cause reste inconnue, rassemblez nom, périmètre et priorité de la policy, Message-ID, horodatage, sens, domaine destinataire, versions attendue et observée, ainsi que les textes History et SMTP pertinents pour Sophos Email Support. N’ajoutez ni clés privées, ni mots de passe, ni contenu confidentiel au ticket.

Revenir en arrière en sécurité

Si le flux devient inattendu, remettez d’abord la nouvelle policy sur Policy Bypassed ou utilisez l’heure de désactivation préparée, puis restaurez la priorité précédente. Retestez les deux sens et confirmez l’ancien chemin dans Message History et chez le destinataire. N’assouplissez pas simultanément version TLS, contrôle du certificat et périmètre : la cause deviendrait indéterminable.

Un repli temporaire vers Preferred TLS 1.3, Push Encryption ou une remise non chiffrée n’est permis que si le responsable des données et celui du changement l’approuvent explicitement. Si le texte clair est interdit, mieux vaut retenir le message pendant que le partenaire corrige version TLS, chiffrements ou chaîne de certificats. N’élargissez le périmètre et ne nettoyez une ancienne policy Migrated qu’après réussite des tests pilote et négatif.