Migrar do Sophos Firewall Mail Protection para o Sophos Email

Esta migração transfere inspeção e políticas do Sophos Firewall Mail Protection para o Sophos Email no Sophos Fusion (anteriormente Sophos Central). Não é uma cópia de configuração: primeiro mapeiam-se funções e destinatários, depois prepara-se o Sophos Email sem alterar o routing produtivo e só então se comuta o fluxo de forma controlada. O caminho antigo deve poder ser restaurado até terminar a janela de rollback acordada.

⚠️ Nunca altere simultaneamente MX, smart host de saída, DNAT e várias políticas sem testar. Antes de qualquer alteração de firewall ou routing, faça um backup atual do Sophos Firewall, registe os valores originais e confirme acesso administrativo independente.

1. Escolher arquitetura e critérios de paragem

O Microsoft 365 pode usar Sophos Mailflow ou Sophos Gateway. Mailflow usa conectores e regras do Microsoft 365; Gateway usa routing SMTP e normalmente altera o MX. Outras plataformas usam Gateway. Consulte Planear arquitetura e onboarding. Um domínio deve ter apenas um caminho produtivo de inspeção Sophos.

Defina janela, responsáveis por Sophos Fusion, Sophos Firewall, DNS e servidor de correio, piloto e critérios de paragem. Correio externo não entregue, relay aberto, processamento duplicado ou loop exigem rollback. A licença Sophos Email deve estar ativa.

2. Preservar inventário, backup e caminho de retorno

Para cada domínio, registe:

MTA Mode ou Legacy Mode/transparent proxy atual;
domínios, caixas, aliases, listas e utilização do SSP;
MX de entrada, smart host de saída, fontes de relay, NAT, portas SMTP e TLS;
políticas SMTP, ordem, exceções, remetentes bloqueados, resumos de quarentena e DKIM;
ações spam/malware, ficheiros/Data Control, encriptação/SPX e banners;
IDs de regras NAT/firewall, objetos, zonas, logs, destino e rota de retorno.

Exporte ou capture os valores, crie o backup e escreva a ordem exata de restauro. Reduza TTL apenas pelo procedimento de change. Não apague regras antigas.

3. Mapear políticas e aprovar funções sem equivalente

Crie uma linha por política de origem, preserve ordem e âmbito e configure o destino:

Spam MTA Mode: em Email Security > Policies > [Email Security policy] > Settings > Anti-Spam, mapeie None → Deliver, Warn → Tag subject line, Quarantine → Quarantine, Drop → Delete; configure SPF, DKIM e DMARC em Authentication.
Spam transparent proxy: mapeie Accept → Deliver, Prefix subject for spam → Tag subject line, Quarantine → Quarantine, Drop → Delete. Reject e Change Recipient não têm equivalente; redesenhe o fluxo ou aceite explicitamente o risco, sem substituir silenciosamente Deliver/Delete.
File/Data Control: recrie anexos em Email Security > Policies > Data control: [policy] > Settings > Inbound > Add rule com Attachment file types (AFT), listas com Content control lists (CCLs) e tamanho/header/origem com Message Attribute (MA). Escolha e teste inbound/outbound, ação e exceções; listas do firewall não migram automaticamente.
Encryption/SPX: mapeie SMTP TLS para Email Security > Policies > Secure Message: Base Policy – Secure Message ou Add Rule > Secure Message. São necessárias seleções interna e externa. Push Encryption corresponde à encriptação PDF SPX; Portal Encryption usa Sophos Secure Message. O destinatário define a palavra-passe, logo definições/palavras-passe SPX não são copiadas. Valide TLS.
Exceptions: remetente/destinatário → política restrita com Anti-Spam = Deliver; global → Email Security > Settings > Inbound Allow/Block > Add allow (email, domínio ou IP), que ignora spam globalmente. SPF/DKIM em Authentication, Intelix em Anti-malware, Data/File como exclusões de endereços ou Message Attributes na regra Data control. Reveja allows amplos.
Sem equivalente: RBL personalizadas e greylisting não são configuráveis; Sophos Email Advanced usa Sophos Delay Queue automática, não greylisting do cliente. Segredos/comportamento BATV não têm definição para migrar para cloud. POP/IMAP scanning falta; Novell eDirectory/OpenLDAP não migram de modo idêntico, SNMP requer notificações/relatórios Sophos Fusion atribuídos e Hardware Monitoring fica separado.

Não avance até cada linha ter destino testado ou ausência de equivalente documentada com aceitação do risco.

4. Preparar totalmente o Sophos Email

Adicione ou sincronize domínios e todos os destinatários; compare aliases e grupos com o inventário. Prepare SSP, quarentena administrativa e funções. Crie políticas alvo com âmbito restrito e ordem prevista, inicialmente em piloto ou sem enforcement. Use Configurar Sophos Email Gateway ou, para Microsoft 365, Configurar Sophos Email Mailflow.

Obtenha hosts, IP e DNS regionais apenas em Configure External Dependencies do seu tenant. Não reutilize exemplos ou tickets.

5. Preparar interoperabilidade temporária do firewall

Esta fase só é necessária se o Sophos Email tiver de entregar, após inspeção cloud, através do Sophos Firewall a um servidor local ou de terceiros. Ignore-a para Microsoft 365 ou Google Workspace sem esse salto.

Crie DNAT desativada: Original source = Sophos Delivery IPs regionais de Configure External Dependencies; Original destination = interface/endereço WAN recetor; Original service = porta de entrega usada por Sophos Email; Translated destination (DNAT) = servidor interno real; Translated service (PAT) = porta SMTP realmente escutada (normalmente SMTP/25). PAT só se os serviços diferirem; defina interface inbound. Nunca servidor interno em Original destination nem WAN em Translated destination.

Crie firewall rule desativada acima das gerais: Source zones = WAN, Source networks and devices = Sophos Delivery IPs, Destination zones = zona pós-NAT do servidor, Destination networks = destino WAN pré-NAT de Original destination DNAT, Services = serviço/porta de entrega original na WAN, não SMTP/PAT traduzido. Ative logging. Os campos representam propositadamente fases pré/pós-NAT distintas. Verifique retorno e restrinja relay.

O novo salto não pode voltar a atravessar o MTA/proxy antigo. O destino do Sophos Email não pode resolver para o MX público Sophos nem regressar por smart host. Defina uma saída única: servidor/fornecedor → Sophos Email → Internet.

6. Executar cutover por fases

Volte a verificar backup, destinatários, políticas, alcance, ordem de regras e aprovação do rollback. Para destino local, ative primeiro DNAT/firewall e confirme o Rule Hit esperado. Para Mailflow, ative conectores e regras Microsoft depois de resolver conflitos. Para Gateway, altere só agora o MX público para os valores do tenant.

Teste primeiro a entrada, depois altere smart host/conector. Atualize SPF, DKIM e DMARC para o caminho final e verifique os três em DNS e headers recebidos. Congele outras alterações.

7. Validar fluxo e proteção

Registe Message-ID e hora únicos para: entrada numa caixa pessoal; alias ou lista; resposta e nova mensagem para conta externa controlada; testes inofensivos autorizados de spam, malware/ficheiro e Data Control; TLS, quarentena, relatórios e SSP.

Comprove cada mensagem em Message History e em Microsoft Message Trace, trace do fornecedor ou logs do servidor. No Sophos Firewall verifique IDs DNAT/firewall, porta e destino. Sucesso significa entrega final, exatamente uma inspeção Sophos e ação esperada, não apenas TCP aberto.

Diagnostique por ordem: MX/DNS, estado de domínio/caixa, conector ou smart host, DNAT e zona, ordem e ID da regra, porta/TLS, relay, âmbito da política e só depois filtros. Ausência no Message History costuma indicar routing, não necessidade de exceção ampla.

8. Fazer rollback ou retirar em segurança

Ao abortar, restaure primeiro smart host/conector antigo e publique o MX anterior, tratando DNS como assíncrono. Por pelo menos o TTL MX antigo mais a propagação autoritativa, mantenha ambas as entradas funcionais: destino antigo para caches com MX antigo; Sophos Email, domínio/routing e DNAT/firewall/relay temporário para caches com MX novo. Nenhum caminho reenvia ao outro. Teste e meça via DNS, Message History e logs.

Desative a nova entrada só após a janela de cache e ausência de entregas nos logs, não ao republicar o MX antigo. Desative políticas SMTP antigas após a janela de rollback; depois remova NAT/regras/objetos/relay. Preserve evidências. Não retire caminhos exigidos por MX em cache, POP/IMAP ou função não substituída.