Migrare da Sophos Firewall Mail Protection a Sophos Email

Questa migrazione sposta ispezione e policy da Sophos Firewall Mail Protection a Sophos Email in Sophos Central. Non è una copia della configurazione: prima si mappano funzioni e destinatari, poi si prepara Sophos Email senza cambiare il routing di produzione e infine si commuta il flusso in modo controllato. Il percorso precedente deve restare ripristinabile fino alla fine della finestra di rollback concordata.

⚠️ Non cambiare contemporaneamente MX, smart host in uscita, DNAT e più policy senza test. Prima di qualsiasi modifica a firewall o routing, creare un backup aggiornato di Sophos Firewall, registrare i valori originali e verificare un accesso amministrativo indipendente.

1. Scegliere architettura e criteri di arresto

Microsoft 365 può usare Sophos Mailflow o Sophos Gateway. Mailflow usa connettori e regole Microsoft 365; Gateway usa routing SMTP e normalmente una modifica MX. Le altre piattaforme usano Gateway. Consultare Pianificare architettura e onboarding. Un dominio deve avere un solo percorso Sophos di produzione.

Definire finestra, responsabili per Sophos Central, Sophos Firewall, DNS e server mail, pilota e condizioni di arresto. Mancata consegna esterna, relay aperto, doppia elaborazione o loop richiedono rollback. La licenza Sophos Email deve essere attiva.

2. Conservare inventario, backup e percorso di ritorno

Per ogni dominio registrare:

MTA Mode o Legacy Mode/transparent proxy attuale;
domini, caselle, alias, liste e uso SSP;
MX in ingresso, smart host in uscita, sorgenti relay, NAT, porte SMTP e TLS;
policy SMTP, ordine, eccezioni, mittenti bloccati, riepiloghi quarantena e DKIM;
azioni spam/malware, file/Data Control, crittografia/SPX e banner;
ID regole NAT/firewall, oggetti, zone, log, destinazione server e ritorno.

Esportare o acquisire i valori, creare il backup e scrivere l’esatto ordine di ripristino. Ridurre il TTL solo secondo la procedura di change. Non eliminare le vecchie regole.

3. Mappare le policy e approvare le funzioni senza equivalente

Creare una riga per ogni policy sorgente, conservarne ordine e ambito e configurare la destinazione:

Spam MTA Mode: in Email Security > Policies > [Email Security policy] > Settings > Anti-Spam, mappare None → Deliver, Warn → Tag subject line, Quarantine → Quarantine, Drop → Delete; configurare SPF, DKIM e DMARC in Authentication.
Spam transparent proxy: mappare Accept → Deliver, Prefix subject for spam → Tag subject line, Quarantine → Quarantine, Drop → Delete. Reject e Change Recipient non hanno equivalente: ridisegnare il flusso o accettare esplicitamente il rischio, senza sostituire Deliver/Delete.
File/Data Control: ricreare allegati in Email Security > Policies > Data control: [policy] > Settings > Inbound > Add rule con Attachment file types (AFT), liste con Content control lists (CCLs) e dimensione/header/origine con Message Attribute (MA). Scegliere e testare inbound/outbound, azione ed eccezioni; le liste firewall non migrano automaticamente.
Encryption/SPX: mappare SMTP TLS a Email Security > Policies > Secure Message: Base Policy – Secure Message o Add Rule > Secure Message. Servono selezioni interne ed esterne. Push Encryption è la controparte PDF di SPX; Portal Encryption usa Sophos Secure Message. Password e impostazioni SPX non vengono copiate perché la password è definita dal destinatario. Validare TLS server–Sophos Email.
Exceptions: eccezione mittente/destinatario → policy ristretta con Anti-Spam = Deliver; globale → Email Security > Settings > Inbound Allow/Block > Add allow (email, dominio o IP), che bypassa lo spam globalmente. SPF/DKIM vanno in Authentication, Intelix in Anti-malware, Data/File come esclusioni di indirizzi o Message Attributes nella regola Data control. Riesaminare allow ampie.
Nessun equivalente diretto: RBL personalizzate e greylisting non sono configurabili; Sophos Email Advanced usa Sophos Delay Queue automatica, non greylisting cliente. Segreti/comportamento BATV firewall non hanno impostazioni da migrare al cloud. POP/IMAP scanning manca; Novell eDirectory/OpenLDAP non hanno migrazione identica, SNMP richiede notifiche/report Sophos Central assegnati e Hardware Monitoring resta separato.

Nessun go-live finché ogni riga non ha una destinazione testata o un’assenza di equivalente documentata con accettazione del rischio.

4. Preparare completamente Sophos Email

Aggiungere o sincronizzare domini e tutti i destinatari, quindi confrontare alias e gruppi con l’inventario. Preparare SSP, quarantena amministrativa e ruoli. Creare policy di destinazione con scope ristretto e ordine previsto, inizialmente pilota o non applicato. Seguire Configurare Sophos Email Gateway oppure, per Microsoft 365, Configurare Sophos Email Mailflow.

Usare host, IP e DNS regionali solo da Configure External Dependencies del proprio tenant. Non riutilizzare esempi o ticket.

5. Preparare l’interoperabilità temporanea del firewall

Serve solo quando Sophos Email deve consegnare, dopo l’ispezione cloud, attraverso Sophos Firewall a un server locale o di terze parti. Ometterla per Microsoft 365 o Google Workspace senza quel passaggio.

Creare DNAT disattivata: Original source = Sophos Delivery IPs regionali da Configure External Dependencies; Original destination = interfaccia/indirizzo WAN; Original service = porta di consegna chiamata da Sophos Email; Translated destination (DNAT) = host/IP interno reale; Translated service (PAT) = porta SMTP realmente in ascolto (spesso SMTP/25). Usare PAT solo se i servizi differiscono e impostare l’interfaccia inbound. Mai server interno in Original destination o oggetto WAN in Translated destination.

Creare firewall rule disattivata sopra i match generici: Source zones = WAN, Source networks and devices = Sophos Delivery IPs, Destination zones = zona post-NAT del server, Destination networks = destinazione WAN pre-NAT di Original destination DNAT, Services = servizio/porta originale accettato sulla WAN, non SMTP/PAT tradotto. Abilitare logging. I campi rappresentano volutamente fasi pre/post-NAT diverse. Verificare ritorno e limitare relay al percorso Sophos.

Il nuovo hop non deve attraversare di nuovo il vecchio MTA/proxy. La destinazione Sophos Email non deve risolvere al MX pubblico Sophos né tornare a Sophos Email tramite smart host. Definire una sola uscita: server/provider → Sophos Email → Internet.

6. Eseguire il cutover a fasi

Ricontrollare backup, destinatari, policy, raggiungibilità, ordine regole e autorizzazione rollback. Per una destinazione locale, attivare prima DNAT/firewall e confermare il Rule Hit previsto. Per Mailflow, attivare connettori e regole Microsoft dopo aver risolto i conflitti. Per Gateway, cambiare solo ora il MX pubblico con i valori del tenant.

Testare prima l’ingresso. Poi cambiare smart host/connettore e aggiornare SPF, DKIM e DMARC per il percorso finale secondo il tenant, verificando tutti e tre in DNS e header ricevuti. Bloccare altri cambi durante l’accettazione.

7. Validare flusso e protezione

Registrare Message-ID e timestamp univoci per: ingresso a casella personale; alias o lista; risposta e nuovo messaggio verso un account esterno controllato; test innocui autorizzati di spam, malware/file e Data Control; verifiche TLS, quarantena, report e SSP.

Provare ogni messaggio in Message History e in Microsoft Message Trace, trace del provider o log server. Su Sophos Firewall verificare ID DNAT/firewall, porta e destinazione. Successo significa consegna finale, una sola ispezione Sophos e azione attesa, non soltanto TCP aperto.

Diagnosticare nell’ordine: MX/DNS, stato dominio/casella, connettore o smart host, DNAT e zona, ordine e ID regola, porta/TLS, relay, scope policy, quindi filtri. L’assenza da Message History indica spesso routing, non la necessità di un’eccezione ampia.

8. Eseguire rollback o dismissione sicura

In caso di arresto ripristinare prima smart host/connettore uscente e ripubblicare il vecchio MX, trattando DNS come asincrono. Per almeno il vecchio TTL MX più la propagazione autoritativa mantenere entrambi gli ingressi funzionanti: vecchia destinazione per cache con vecchio MX; Sophos Email, dominio/routing e DNAT/firewall/relay temporaneo per cache con nuovo MX. Nessun percorso rinvia nell’altro. Testare entrambi e misurare con DNS, Message History e log.

Disattivare il nuovo ingresso solo dopo scadenza cache e assenza di consegne nei log; non spegnere le regole firewall alla ripubblicazione del vecchio MX. Disattivare le vecchie policy SMTP solo dopo la finestra rollback, poi rimuovere NAT, regole, oggetti e relay dopo nuova accettazione. Conservare backup, mappa, DNS, Message-ID e verbale. Non rimuovere percorsi richiesti da MX in cache, POP/IMAP o funzioni non sostituite.