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 et le certificat.
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.

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é.

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.
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.

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.

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

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.
3. Affecter le modèle SPX prévu à la Data Control List.
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é.

Pour la première corrélation, utiliser Email > Mail logs, Log Viewer et les fichiers MTA smtpd_main.log, smtpd_error.log et smtpd_panic.log. Corréler un message d’erreur avec le même e-mail de test et le même horaire. Services et journaux de Sophos Firewall explique l’accès et les autres fichiers journaux.

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 correspondance de liste et l’affectation du modèle. 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.

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 ou de la Data Control List.
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é.
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, le port et Allowed Networks sont strictement limités.
• 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.
• Mail logs et les journaux MTA peuvent être corrélés avec le message de test.
• 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