Migrer de Sophos Firewall Mail Protection vers Sophos Email

Cette migration transfère l’inspection et les stratégies de Sophos Firewall Mail Protection vers Sophos Email dans Sophos Fusion (anciennement Sophos Central). Il ne s’agit pas de copier une configuration : associez d’abord fonctions et destinataires, préparez Sophos Email sans modifier le routage de production, puis basculez le flux sous contrôle. L’ancien chemin doit rester récupérable jusqu’à la fin de la période de retour arrière convenue.

⚠️ Ne modifiez jamais simultanément MX, smart host sortant, DNAT et plusieurs stratégies sans test. Avant toute modification du pare-feu ou du routage, créez une sauvegarde récente de Sophos Firewall, relevez les valeurs initiales et vérifiez un accès d’administration indépendant.

1. Choisir l’architecture et les critères d’arrêt

Microsoft 365 peut utiliser Sophos Mailflow ou Sophos Gateway. Mailflow emploie les connecteurs et règles Microsoft 365 ; Gateway emploie le routage SMTP et généralement une modification MX. Les autres plateformes utilisent Gateway. Consultez Planifier l’architecture et l’onboarding Sophos Email. Un domaine ne doit avoir qu’un chemin Sophos de production.

Définissez fenêtre, responsables Sophos Fusion, Sophos Firewall, DNS et messagerie, pilote et critères d’arrêt. Courrier externe non distribuable, relais ouvert, double traitement ou boucle déclenchent le rollback. La licence Sophos Email doit être active.

2. Sauvegarder l’inventaire et le chemin de retour

Pour chaque domaine, consignez :

• le MTA Mode ou Legacy Mode/transparent proxy actuel ;
• domaines, boîtes, alias, listes et usage du SSP ;
• MX entrant, smart host sortant, sources de relais, NAT, ports SMTP et TLS ;
• stratégies SMTP, ordre, exceptions, expéditeurs bloqués, résumés de quarantaine et DKIM ;
• actions spam/malware, fichiers/Data Control, chiffrement/SPX et bannières ;
• ID des règles NAT/pare-feu, objets, zones, journaux, cible serveur et route retour.

Exportez ou capturez ces données, effectuez une sauvegarde Sophos Firewall et écrivez l’ordre exact de restauration. Réduisez le TTL uniquement selon la procédure de changement. Ne supprimez pas les anciennes règles.

3. Mapper les stratégies et valider les fonctions sans équivalent

Créez une ligne par stratégie source, conservez ordre et périmètre, puis configurez la cible :

• Spam MTA Mode : dans Email Security > Policies > [Email Security policy] > Settings > Anti-Spam, mappez None → Deliver, Warn → Tag subject line, Quarantine → Quarantine et Drop → Delete. Configurez SPF, DKIM et DMARC sous Authentication avec l’action validée.
• Spam transparent proxy : au même emplacement, mappez Accept → Deliver, Prefix subject for spam → Tag subject line, Quarantine → Quarantine et Drop → Delete. Reject et Change Recipient n’ont aucun équivalent Sophos Email : reconcevez le flux ou acceptez explicitement le risque, sans substituer Deliver ou Delete.
• File/Data Control : recréez les pièces jointes dans Email Security > Policies > Data control: [policy] > Settings > Inbound > Add rule avec Attachment file types (AFT), les listes avec Content control lists (CCLs) et les contrôles taille/en-tête/source avec Message Attribute (MA). Choisissez et testez sens entrant/sortant, action et exceptions ; aucune liste Firewall ne migre automatiquement.
• Encryption/SPX : mappez SMTP TLS vers Email Security > Policies > Secure Message: Base Policy – Secure Message ou Add Rule > Secure Message. Une règle ciblée exige les sélections interne et externe. Push Encryption correspond au chiffrement PDF SPX et Portal Encryption utilise Sophos Secure Message ; le destinataire définissant le mot de passe, paramètres et mots de passe SPX ne sont pas copiés. Validez TLS entre serveur et Sophos Email.
• Exceptions : une exception antispam expéditeur/destinataire devient une Email Security Policy ciblée avec Anti-Spam = Deliver ; une exception globale va dans Email Security > Settings > Inbound Allow/Block > Add allow (adresse, domaine ou IP) et contourne l’antispam globalement. Mappez SPF/DKIM sous Authentication, Intelix sous Anti-malware, et Data/File par exclusion d’adresses ou Message Attributes dans la règle Data control concernée. Réexaminez les autorisations larges.
• Sans équivalent direct : RBL personnalisées et greylisting ne sont pas configurables ; Sophos Email Advanced utilise Sophos Delay Queue activée automatiquement, pas le greylisting client. Les secrets et le comportement BATV Firewall n’ont aucun paramètre à migrer vers ce service cloud. POP/IMAP scanning est indisponible. Novell eDirectory/OpenLDAP n’ont pas de migration identique, SNMP exige des notifications/rapports Sophos Fusion attribués, et Hardware Monitoring reste distinct.

Pas de production avant une cible testée ou une absence d’équivalent documentée avec acceptation explicite du risque pour chaque ligne.

4. Préparer complètement Sophos Email

Ajoutez ou synchronisez domaines et tous les destinataires, puis rapprochez alias et groupes de l’inventaire. Préparez SSP, quarantaine administrateur et rôles. Créez les stratégies cibles avec des périmètres étroits et le bon ordre, d’abord en pilote ou non appliquées. Suivez Configurer Sophos Email Gateway ou, pour Microsoft 365, Configurer Sophos Email Mailflow.

Copiez les hôtes, IP et valeurs DNS propres à la région uniquement depuis Configure External Dependencies de votre tenant. N’utilisez pas d’exemples ou d’anciens tickets.

5. Préparer l’interopérabilité temporaire du pare-feu

Cette étape n’est requise que si Sophos Email doit livrer, après inspection cloud, via Sophos Firewall à un serveur local ou tiers. Ignorez-la pour Microsoft 365 ou Google Workspace sans passage nécessaire par le pare-feu.

Créez la DNAT désactivée ainsi : Original source = Sophos Delivery IPs régionales de Configure External Dependencies ; Original destination = interface/adresse WAN réceptrice ; Original service = port de livraison appelé par Sophos Email ; Translated destination (DNAT) = hôte/IP réel du serveur interne ; Translated service (PAT) = port SMTP réellement écouté (souvent SMTP/25). PAT ne sert que si les services diffèrent ; définissez l’interface entrante. Ne mettez jamais le serveur interne dans Original destination ni l’objet WAN dans Translated destination.

Créez la règle firewall désactivée au-dessus des règles larges : Source zones = zones WAN, Source networks and devices = Sophos Delivery IPs, Destination zones = zone post-NAT du serveur, Destination networks = destination WAN pré-NAT utilisée comme Original destination DNAT, Services = service/port de livraison original accepté sur WAN, non le SMTP/PAT traduit. Activez les journaux. Ces champs décrivent volontairement des étapes pré/post-NAT distinctes. Vérifiez le retour et limitez le relais serveur au chemin Sophos prévu.

Le nouveau saut ne doit pas repasser par l’ancien MTA/proxy. La cible de livraison Sophos Email ne doit ni résoudre vers le MX Sophos public ni revenir à Sophos Email via un smart host. Définissez une seule sortie : serveur/fournisseur → Sophos Email → Internet.

6. Basculer par étapes

Revérifiez sauvegarde, destinataires, stratégies, accessibilité, ordre des règles et autorisation du rollback. Pour une cible locale, activez d’abord DNAT et règle pare-feu, puis confirmez le Rule Hit attendu. Pour Mailflow, activez connecteurs et règles Microsoft après résolution des conflits. Pour Gateway, modifiez seulement maintenant le MX public avec les valeurs du tenant.

Testez d’abord l’entrée. Quand externe → Sophos Email → cible fonctionne sans ambiguïté, changez le smart host ou connecteur sortant. Mettez à jour SPF, DKIM et DMARC pour le chemin final selon le tenant et vérifiez les trois dans DNS et les en-têtes reçus. Gelez les autres changements pendant la recette.

7. Valider le flux et la protection

Relevez Message-ID et horodatages uniques par domaine :

1. message externe vers une boîte personnelle ;
2. message vers un alias ou une liste ;
3. réponse et nouveau message vers un compte externe contrôlé ;
4. tests inoffensifs autorisés des actions spam, malware/fichier et Data Control ;
5. contrôles TLS, quarantaine, rapports et SSP.

Prouvez chaque message dans Message History et Microsoft Message Trace, la trace fournisseur ou les journaux serveur. Sur Sophos Firewall, vérifiez ID DNAT/pare-feu, port et cible. La réussite signifie distribution finale, une seule inspection Sophos et l’action prévue, pas seulement une connexion TCP.

Diagnostiquez dans cet ordre : MX/DNS, état domaine/boîte, connecteur ou smart host, DNAT et zone cible, ordre et ID de règle, port/TLS, autorisation de relais, périmètre de stratégie, puis filtres. Une absence de Message History signale généralement le routage, pas le besoin d’une exception large.

8. Revenir en arrière ou retirer proprement

En cas d’arrêt, restaurez d’abord l’ancien smart host/connecteur sortant et republiez l’ancien MX, mais DNS reste asynchrone. Pendant au moins l’ancien TTL MX plus la propagation autoritative, gardez les deux chemins entrants fonctionnels : l’ancienne cible accepte les caches avec ancien MX ; Sophos Email, son domaine/routage et le chemin temporaire DNAT/firewall/relais acceptent les caches avec nouveau MX. Aucun ne renvoie vers l’autre. Testez les deux et mesurez via DNS, Message History et journaux serveur.

Ne désactivez la nouvelle entrée qu’après expiration du cache et absence de livraison dans les journaux ; ne coupez pas les règles firewall temporaires à la republication de l’ancien MX. Désactivez les anciennes stratégies SMTP seulement après la fenêtre de rollback, puis retirez NAT, règles, objets et relais inutiles après recette. Conservez sauvegarde, mapping, DNS, Message-ID et procès-verbal. Aucun chemin n’est retiré tant que MX en cache, POP/IMAP ou une fonction non remplacée en dépendent.