Configurer le chiffrement des e-mails SPX sur Sophos Firewall

Avec Secure PDF Exchange, ou SPX, Sophos Firewall convertit un e-mail sortant et ses pièces jointes en fichier PDF protégé par mot de passe. Le destinataire n’a pas besoin de son propre client de chiffrement. Selon le modèle choisi, il reçoit un mot de passe à usage unique, utilise un mot de passe enregistré ou en définit un lui-même.

Quatre éléments doivent fonctionner ensemble : un modèle SPX, un déclencheur sans ambiguïté, un canal sécurisé pour le mot de passe et, si nécessaire, le SPX Reply Portal. Un flux positif et un flux négatif sont ensuite testés. La seule réception d’un PDF ne prouve ni que la bonne stratégie s’est déclenchée, ni que l’enregistrement du mot de passe et la réponse sécurisée fonctionnent.

SPX en huit étapes

1. Vérifier la licence Email Protection, le flux de messagerie MTA, la compatibilité du modèle, le certificat du portail et le chemin SMTP TLS distinct.
2. Décider si le chiffrement est déclenché par un domaine protégé, une correspondance Data Control ou l’expéditeur.
3. Créer un modèle personnalisé sous Email > Encryption > SPX templates > Add.
4. Choisir consciemment le type de mot de passe, le chiffrement PDF, la notification et le Reply Portal.
5. Sécuriser le FQDN, les réseaux autorisés et le port sous Email > Encryption > SPX portal settings.
6. Affecter le modèle dans la stratégie SMTP route and scan ou comme modèle par défaut choisi délibérément.
7. Tester le PDF, le canal du mot de passe, l’enregistrement et la réponse avec un destinataire externe.
8. Effectuer un test négatif sans déclencheur SPX et documenter Mail logs, les journaux MTA et le retour arrière.

⚠️ Un champ Allowed networks vide pour le SPX Portal ne signifie pas « aucun accès » : il revient à Any. Sophos recommande également un port dédié pour le Reply Portal. Le FQDN du portail, le certificat, les sources autorisées et le canal du mot de passe doivent donc être définis avant le test en production.

Quand SPX convient

SPX convient lorsque des destinataires externes doivent recevoir des contenus confidentiels sous forme de PDF protégé sans installer de client de chiffrement. Il est disponible en MTA mode comme en Legacy mode. Cette procédure utilise MTA mode, car le domaine, Data Control et le routage peuvent ainsi être reliés de façon compréhensible dans la stratégie SMTP. Configurer Mail Protection en Legacy mode explique l’alternative transparente.

SPX n’est ni un chiffrement de transport entre serveurs de messagerie ni un chiffrement de bout en bout entre deux clients de messagerie. Le pare-feu traite le texte en clair, génère le PDF et gère le mot de passe ou l’enregistrement. Le PDF peut ensuite subsister hors du pare-feu dans des boîtes aux lettres, des archives ou des téléchargements. Le périmètre des destinataires, la conservation et la transmission du mot de passe font donc partie de la conception de sécurité.

Le chiffrement du transport SMTP se règle séparément sous Email > General settings > SMTP TLS configuration. Require TLS negotiation impose TLS aux hôtes distants ou réseaux sélectionnés ; si SFOS ne peut pas établir la connexion TLS, il supprime l’e-mail destiné à cette cible. À l’inverse, Skip TLS negotiation force une connexion SMTP non chiffrée. Le TLS certificate sélectionné à cet endroit protège le chemin SMTP et n’est pas le certificat des portails SPX. Il faut donc planifier SPX et SMTP TLS séparément, puis les valider ensemble dans le flux externe.

Les prérequis sont les suivants :

• une licence Email Protection valide ;
• un flux de messagerie sortant déjà testé via Sophos Firewall ;
• un destinataire externe de test documenté ;
• un FQDN de confiance et un certificat correspondant pour les portails SPX utilisés ;
• un canal sécurisé distinct pour les mots de passe lorsqu’ils ne sont pas enregistrés par le destinataire ;
• une voie de récupération permettant de retirer les affectations de modèle et de stratégie.

Selon l’aide Sophos actuelle, SPX n’est pas disponible sur XGS 87/87w. Le MTA mode complet n’est en outre pas disponible sur XGS 88/88w. Configurer Mail Protection en MTA mode explique le flux de messagerie, la licence, le relais et les limites de modèle.

Définir le déclencheur et la priorité

SPX peut être déclenché de trois façons. Lorsque plusieurs méthodes sont configurées, Sophos Firewall applique cet ordre en MTA mode :

1. Domaine protégé : Le modèle SPX sélectionné sous Domains and routing target s’applique aux messages sortants du domaine protégé correspondant.
2. Data control list : Seulement si aucun modèle SPX n’est défini au niveau du domaine, une correspondance Data Control peut appliquer le modèle sélectionné pour la liste.
3. Déclencheur de l’expéditeur : Seulement lorsque ni le domaine ni Data Control ne fournissent de modèle, la méthode de l’expéditeur configurée sous Default SPX template s’applique.

Une affectation au niveau du domaine est large et ne convient que si tous les messages sortants correspondants doivent réellement être chiffrés. Data Control est adapté à des types de contenu définis, mais doit être testé avec de vrais exemples positifs et négatifs afin de détecter les faux positifs. Le déclencheur de l’expéditeur lui laisse la décision, mais exige une procédure de client de messagerie clairement documentée.

Avant la configuration, un seul déclencheur principal est défini pour chaque flux. Une deuxième méthode ne doit pas en supplanter une autre sans que cela soit remarqué.

Créer le modèle SPX

L’exemple utilise le modèle Finance-SPX-Recipient. Ce nom est une valeur de documentation à adapter au but et à l’organisation.

1. Ouvrir Email > Encryption > SPX templates.
2. Sélectionner Add.
3. Saisir un nom tel que Finance-SPX-Recipient. SFOS n’autorise pas les apostrophes, barres obliques, virgules, barres obliques inverses ni guillemets dans ce nom.
4. Définir le nom de l’organisation pour les notifications.
5. Choisir Encryption standard et PDF page size selon les exigences internes.
6. Sous Password type, sélectionner le modèle de mot de passe prévu.
7. Vérifier l’objet, le corps du message et les instructions destinées au destinataire, puis les adapter si nécessaire.
8. Si les réponses sécurisées sont requises, activer Enable SPX reply portal.
9. Activer Include original body into reply uniquement si le message original peut figurer dans la réponse.
10. Enregistrer le modèle.

Choisir consciemment le modèle de mot de passe

Sophos Firewall propose quatre modèles :

• Specified by sender : L’expéditeur définit le mot de passe. Le pare-feu le retire avant l’envoi et ne le conserve pas. Le mot de passe doit parvenir au destinataire par un canal sécurisé distinct.
• Generate one-time password for every email : Le pare-feu génère un nouveau mot de passe pour chaque message et l’envoie à l’expéditeur. Celui-ci le transmet séparément au destinataire. Le mot de passe n’est pas conservé.
• Generated and stored for recipient : Le pare-feu génère un mot de passe propre au destinataire, l’envoie à l’expéditeur et le réutilise jusqu’à son expiration.
• Specified by recipient : Un destinataire qui n’est pas encore enregistré reçoit un lien d’enregistrement, définit son mot de passe et l’utilise jusqu’à son expiration pour les futurs messages SPX de l’organisation.

Pour une relation régulière avec un partenaire, Specified by recipient est souvent la procédure la plus simple à comprendre. Un mot de passe à usage unique peut mieux convenir à un envoi ponctuel particulièrement sensible. Il faut éviter de mélanger sans planification plusieurs modèles de mots de passe enregistrés pour un même destinataire, car celui-ci devrait alors identifier le mot de passe correspondant à chaque message.

Avec Specified by sender, l’objet peut utiliser le modèle [secure:<password>]<subject text>. L’expéditeur doit ensuite transmettre le mot de passe séparément. Pour Microsoft Outlook, Sophos fournit un Outlook Add-in sous Authentication > Client downloads.

Installer l’Outlook Add-in de manière contrôlée

Pour une installation interactive, exécuter setup.exe depuis le paquet téléchargé sur le firewall actif. Sophos documente cette commande pour un déploiement sans assistance :

msiexec /qr /i SophosOutlookAddInSetupUTM.msi T=1 EC=3 C=1 I=1

La liste publique de compatibilité est particulièrement ancienne : L’aide SFOS 22 actuelle ne mentionne que Windows XP à Windows 8, Outlook 2007 SP3, 2010 ou 2013, .NET Framework 4 Client Profile et Visual Studio 2010 Tools for Office Runtime 4.0. Elle ne démontre donc pas la prise en charge des applications Microsoft 365 actuelles ni des versions modernes de Windows. Avant un déploiement étendu, tester sur un appareil pilote le paquet réellement téléchargé, les versions et l’architecture de Windows et Outlook, un déclencheur SPX positif et un autre négatif, ainsi que la désinstallation. Ne pas modifier au hasard les paramètres MSI non expliqués.

L’aide Sophos actuelle utilise deux orthographes différentes de l’en-tête pour les autres clients de messagerie : X-Sophos-SPXEncrypt: yes sur la page du modèle et X-Sophos-SPX-Encrypt: yes sur la page générale Encryption. Cette divergence n’est pas traitée comme une recette à copier-coller. Avant un déploiement en production, il faut vérifier l’orthographe qui fonctionne sur le build SFOS utilisé. Lorsque c’est possible, une stratégie, Data Control ou le Sophos Outlook Add-in constitue un déclencheur plus facile à tracer.

Concevoir la notification sans créer une nouvelle fuite de données

Les variables de notification disponibles comprennent notamment :

• %ENVELOPE_TO%
• %PASSWORD%
• %ORGANIZATION_NAME%
• %SENDER%
• %REG_LINK%

Une mise en forme HTML simple et des liens sont autorisés. Le texte doit expliquer qui a envoyé le message, comment obtenir le mot de passe de façon sécurisée et pendant combien de temps l’enregistrement ou la réponse restent possibles. Les identifiants ou le contenu confidentiel du message ne doivent pas être recopiés dans une notification non protégée.

Sécuriser les portails SPX

L’enregistrement des mots de passe et l’accès au portail sont définis sous Email > Encryption > SPX portal settings :

1. Sous Hostname, saisir le FQDN réellement utilisé par les destinataires externes pour atteindre le portail.
2. Sous Allowed networks, définir uniquement les réseaux sources requis. Any ne convient que si des destinataires externes quelconques doivent accéder au portail et si le risque est accepté consciemment.
3. Documenter le port. Le Password Registration Portal utilise par défaut le port TCP 8094.
4. Utiliser un port dédié pour le SPX Reply Portal.
5. Définir les périodes de validité des mots de passe non utilisés, des réponses sécurisées et des liens d’enregistrement.
6. Saisir les destinataires des notifications d’erreur SPX.

Si Allowed networks reste vide, SFOS utilise Any, car le SPX Reply Portal est activé par défaut dans la zone WAN. Si le Reply Portal n’est pas nécessaire, Sophos indique d’utiliser une adresse privée de confiance inutilisée, par exemple 169.254.0.1, comme seul réseau autorisé afin de le désactiver. Cette valeur de documentation ne doit correspondre à aucune adresse utilisée en production.

Le CAPTCHA est toujours actif sur le SPX Portal et ne peut pas être désactivé. Gérer le CAPTCHA de Sophos Firewall de manière réfléchie explique les limites des réglages CAPTCHA des autres portails.

WebAdmin, User Portal, VPN Portal, Captive Portal et les deux portails SPX utilisent la même sélection centrale de certificat. Une modification peut donc affecter plusieurs services à la fois. Le certificat, les SAN, la voie de récupération et l’URL réelle du portail doivent être planifiés avec Gérer les certificats sur Sophos Firewall. Un certificat Let’s Encrypt sur Sophos Firewall peut convenir à un nom public.

La sélection se trouve sous Administration > Admin and user settings > Admin console and end-user interaction > Certificate. L’identité du certificat dans le SAN ou le CN doit correspondre au FQDN du portail saisi sous Hostname, et la chaîne de CA complète doit être présente sur le firewall. Un remplacement de certificat n’est donc pas une modification limitée à SPX : WebAdmin et les autres portails doivent aussi être vérifiés après l’opération.

Relier le modèle à la stratégie SMTP

En MTA mode, le modèle SPX est sélectionné dans la stratégie SMTP route and scan correspondante sous Email > Policies and exceptions.

Utiliser un domaine comme déclencheur

Sous Domains and routing target, le modèle est affecté au domaine protégé. Il s’applique ensuite aux messages sortants correspondants. Une affectation large au niveau du domaine est d’abord testée avec un expéditeur pilote et un destinataire externe de test.

Utiliser Data Control comme déclencheur

Une Data Control List n’est pas une règle de contenu rédigée librement. Elle est constituée de Sophos Content Control Lists, ou CCL, pour des modèles de données définis. Lors de sa création, filtrer les CCL par Type et Region. Le pilote ne contient que les modèles réellement nécessaires, afin qu’une sélection trop large ne déclenche pas inutilement l’envoi SPX.

1. Créer une liste clairement nommée sous Email > Data control list ou vérifier la liste existante.
2. Activer Data protection dans la stratégie SMTP route and scan et sélectionner précisément cette liste sous Data control list.
3. Définir Data control list action sur Accept with SPX, puis sélectionner le SPX template prévu. Accept distribue sans SPX ; Drop supprime le message sans avertir l’expéditeur.
4. Effectuer un test de contenu positif et un test négatif similaire.

Si un modèle SPX est déjà défini sous Domains and routing target, il est prioritaire sur le modèle Data Control. Une correspondance de la Data Control List prouve uniquement que le contenu a correspondu au critère configuré. Le flux de messagerie réel doit confirmer que le bon message a été chiffré.

Utiliser un déclencheur de l’expéditeur

Sous Email > Encryption > SPX configuration, sélectionner un Default SPX template. Il s’applique au chiffrement SPX déclenché par l’expéditeur uniquement si la stratégie SMTP ne fournit pas déjà un modèle au niveau du domaine ou de Data Control. None désactive cette voie par défaut.

Valider le flux de messagerie chiffré

Noter l’heure du test, l’expéditeur, le destinataire, l’objet et le déclencheur attendu. Tester ensuite au minimum les cas suivants :

1. Test positif : Un message sortant déclenche exactement le modèle SPX prévu.
2. Test du mot de passe : Le destinataire reçoit le mot de passe ou le lien d’enregistrement par le canal prévu et peut ouvrir le PDF.
3. Test du contenu : L’objet, le corps et les pièces jointes figurent dans le PDF comme prévu et sont lisibles.
4. Test de réponse : Si cette fonction est activée, le lien de réponse mène au FQDN attendu et une réponse de test parvient à l’expéditeur initial.
5. Test négatif : Un message similaire sans déclencheur n’est pas envoyé sous forme de PDF SPX.
6. Test d’expiration : L’enregistrement, le mot de passe conservé et la période de réponse se comportent de façon prévisible après la durée définie.
7. Test du certificat : Le navigateur et le destinataire externe reçoivent une chaîne de certificats complète et de confiance pour le FQDN du portail utilisé.

Commencer la corrélation sous Email > Mail logs. Dans Reason, SPX encryption identifie les messages chiffrés par SPX et SPX failure les messages SPX non distribués ; dans Result, filtrer ensuite par exemple sur Delivered, Dropped ou Quarantined. Faire correspondre l’expéditeur, le destinataire, l’objet et la plage horaire à la note de test. Pour les erreurs détaillées, poursuivre dans Log Viewer et les fichiers MTA smtpd_main.log, smtpd_error.log et smtpd_panic.log. Services et journaux de Sophos Firewall explique l’accès et les autres fichiers journaux.

SPX failure n’est pas un autre nom pour la quarantaine SMTP. Un message n’apparaît sous Email > SMTP quarantine que lorsqu’une action Spam, Malware, Unscannable, DKIM ou une autre action de stratégie l’a réellement mis en quarantaine. Pendant le test, ne pas le libérer avant d’avoir consigné le motif et la stratégie déclenchée, sous peine de confondre une erreur d’analyse ou de stratégie avec une erreur SPX.

En HA, les journaux résident sur le nœud qui a traité le trafic. Après un basculement contrôlé, tester séparément un nouvel e-mail SPX, l’enregistrement du mot de passe et la réponse. Ne pas supposer qu’une session de portail existante ou un enregistrement en cours se poursuit sans interruption. Les principes HA sont décrits dans Clusters HA Sophos Firewall.

Isoler les erreurs de manière systématique

Le message n’est pas chiffré

Vérifier la direction, le domaine protégé, la stratégie SMTP route and scan réellement appliquée et la priorité des déclencheurs. Pour Data Control, vérifier aussi Data protection, la Data control list sélectionnée, Data control list action: Accept with SPX et le SPX template associé. Pour un déclencheur d’expéditeur, un modèle par défaut doit être défini et ne doit pas être supplanté par un modèle de domaine ou Data Control. Les deux orthographes documentées de l’en-tête ne justifient pas de les déployer toutes les deux sans test en production.

Mail logs affiche SPX failure

Sous Email > Mail logs, isoler la ligne concernée par l’heure, l’expéditeur, le destinataire et l’objet, puis confirmer Reason: SPX failure. Corréler l’erreur affichée avec smtpd_main.log, smtpd_error.log et, pour une erreur de processus grave, smtpd_panic.log au même instant. Ne modifier qu’ensuite le modèle de mot de passe, le template, la distribution ou le chemin du portail. Si Result vaut plutôt Quarantined, examiner sous Email > SMTP quarantine l’analyse ou l’action de stratégie déclenchée.

Le lien d’enregistrement ou le portail est inaccessible

Vérifier le FQDN, la résolution DNS publique, le port, le certificat, Allowed networks et la validité du lien. Une valeur Allowed Networks vide est traitée comme Any et ne constitue donc pas un état désactivé sûr. Si le client atteint un autre hôte ou portail, l’URL, le NAT ou l’affectation du certificat ne correspond pas au chemin prévu.

Le PDF ne s’ouvre pas

Commencer par faire correspondre le type de mot de passe au message concerné. Un mot de passe à usage unique ne s’applique qu’à cet e-mail. Pour les mots de passe conservés ou enregistrés, l’expiration ou plusieurs modèles de mot de passe peuvent être en cause. Après un SPX Password Reset, l’expéditeur doit de nouveau transmettre le nouveau mot de passe au destinataire de façon sécurisée.

La réponse sécurisée n’arrive pas

Vérifier Enable SPX reply portal dans le modèle, la période de réponse, le FQDN du portail, le port, le certificat et les sources autorisées. Examiner ensuite Mail logs et les journaux MTA pour la réponse concernée. L’ouverture réussie du PDF ne prouve pas que le canal de retour fonctionne.

La validation DKIM échoue après SPX

SPX modifie le corps et les pièces jointes. Si un message est signé avant cette modification, la signature peut devenir invalide chez le destinataire. Définir si le serveur de messagerie interne, Sophos Firewall ou une passerelle ultérieure signe après toutes les modifications prévues. La chaîne de traitement et un test externe doivent être validés ensemble.

Revenir en arrière en toute sécurité

1. Retirer d’abord l’affectation SPX concernée de Domains and routing target. Pour un déclencheur Data Control, rétablir Data control list action dans la stratégie SMTP de Accept with SPX à l’action précédente consignée.
2. Si elle est utilisée, définir Default SPX template sur None.
3. Effectuer un test négatif sortant et confirmer qu’aucun nouveau PDF SPX n’est généré.
4. Ne retirer les Reply et Registration Portal que si aucune autre stratégie SPX active n’en dépend.
5. Rétablir les accès temporaires publics de port, DNS ou portail à l’état antérieur documenté. Ne restaurer les exigences SMTP TLS modifiées séparément qu’en fonction de leur propre état antérieur consigné.
6. Supprimer le modèle seulement lorsqu’aucune stratégie ni procédure opérationnelle active ne le référence.
7. Conserver Mail logs et les journaux MTA du dernier test chiffré et du premier test non chiffré.

Créer une sauvegarde Sophos Firewall récente avant toute modification des chemins de messagerie et de portail en production. SPX peut continuer à fonctionner dans un environnement air gap, mais les dépendances externes DNS, certificats et portail doivent rester accessibles séparément. Les limites du produit sont décrites dans Fonctions SFOS sans accès Internet.

Liste de contrôle opérationnelle

• La licence, le modèle, le flux de messagerie MTA et le destinataire externe sont vérifiés.
• Le déclencheur et sa priorité sont documentés.
• Le type de mot de passe et son canal de transmission sécurisé correspondent au cas d’usage.
• Le FQDN du portail, le certificat central des portails, le port et Allowed Networks sont strictement limités ; SMTP TLS est documenté séparément.
• L’affectation par domaine, Data Control ou par défaut est sans ambiguïté.
• Les tests positif, négatif, du mot de passe, du PDF et de réponse ont réussi.
• Les filtres SPX encryption et SPX failure de Mail logs ainsi que les journaux MTA peuvent être corrélés avec le message de test ; les actions de quarantaine en sont distinguées.
• Le basculement HA et les journaux locaux aux nœuds font partie de la procédure opérationnelle.
• Le responsable, les délais d’expiration, la date de révision et le retour arrière sont documentés.

FAQ