Migrar Log Collectors SVA para Sophos XDR Data Collectors

Na transição para a solução Sophos XDR ampliada, a Sophos provisiona, para os Log Collectors Sophos Security Virtual Appliance (SVA) elegíveis, uma nova configuração XDR Data Collector. Isto não instala nem ativa automaticamente a VM no próprio ambiente. É necessário implementar o substituto, mudar o caminho Syslog e comprovar a chegada de novos eventos. Se o endereço IP for o mesmo, o coletor antigo não pode estar em funcionamento quando o novo arrancar.

O XDR Data Collector é um recetor Syslog virtual no ambiente local ou em AWS, Azure ou GCP. Encaminha os logs recebidos para Sophos XDR. Uma integração API direta não necessita deste recetor Syslog. O runbook de integrações explica Data Ingest, Response Actions e estes tipos de ligação.

Se já utilizar Sophos Next-Gen SIEM, a Sophos recomenda substituir os coletores Syslog SVA anteriores por XDR Data Collectors para poder utilizar toda a retenção de dados suportada pelo produto SIEM. As integrações API existentes não têm de ser reconfiguradas para esta mudança de coletor Syslog. Isto não implica um período de retenção específico nem direitos de retenção SIEM para todos os tenants XDR; continuam a aplicar-se as condições de retenção do próprio produto SIEM.

Estado verificado em 11 de outubro de 2026: o guia de migração de 1 de outubro de 2026 complementa o rollout de setembro. O antigo caminho da documentação EAP identifica a proveniência da versão, não garante que todos os tenants já tenham a função. Verifique primeiro o estado do upgrade de cada tenant e o coletor efetivamente disponível em Security Operations > Integrations > Data Collectors. Este runbook descreve a mudança de Syslog e uma implementação local concreta em vSphere; explica o endereçamento cloud, mas a criação dos recursos de cada cloud não faz parte dos passos vSphere.

Identificar as cargas de trabalho existentes e as definições não migradas

Para cada coletor SVA antigo, registe a plataforma, o nome, o hostname, os valores de rede estáticos ou o lease DHCP, todas as origens emissoras e os respetivos destinos Syslog, portas e protocolos. Registe também o formato dos dados, a seleção de tipos de evento, as exclusões de domínios e protocolos, as definições passthrough e as credenciais necessárias. Documente a última receção de dados comprovada para cada origem; assim, após a mudança, poderá distinguir um fluxo sem atividade de uma falha.

São transferidos automaticamente o nome do coletor, o hostname ou a sua derivação, o endereço IP estático, a máscara de sub-rede, o gateway e o DNS ou a definição DHCP, bem como as associações de portas e protocolos Syslog. As portas de origem anteriores são mantidas e mapeadas para as portas Syslog padrão UDP/514 ou TCP/601. O tipo de plataforma determina o novo coletor cloud ou local.

Não são transferidos automaticamente:

• Integrações NDR: o NDR não utiliza um caminho de encaminhamento Syslog. Numa SVA mista, apenas a componente Syslog é migrada; uma SVA exclusivamente NDR não recebe um XDR Data Collector para este fim.
• Filtros de tipos de evento e listas de exclusão de domínios e protocolos.
• Definições de formato Syslog e passthrough específicas da SVA.
• Credenciais de integração.
• Investigation Consoles, Nessus Scanner e outros tipos de VM que não sejam Log Collectors SVA.
• Appliances físicas: não são migradas automaticamente para coletores virtuais.

Verifique expressamente quais os filtros e formatos ainda necessários na nova integração e que configuração o conector disponibiliza para os aplicar. Filtros em falta podem levar à ingestão de mais dados do que o previsto; um formato incorreto pode fazer com que os logs sejam processados apenas como eventos genéricos. Não copie credenciais de tickets ou capturas de ecrã antigas; disponibilize-as novamente através do sistema de gestão de secrets previsto.

Se o NDR estiver na mesma SVA, a mudança de Syslog não pode desligar inadvertidamente o sensor. A variante com o mesmo IP exige desligar a SVA antiga e, assim, também interrompe a sua carga de trabalho NDR. Planeie essa operação separadamente ou escolha outro IP para o novo coletor Syslog, permitindo que a SVA continue a funcionar para NDR. O runbook de operação NDR trata desta carga de trabalho; provisionar um substituto Syslog não é migrar NDR.

Escolher a variante de endereçamento antes do download

O endereço de destino determina se as duas VMs podem funcionar simultaneamente e se é necessário alterar as origens.

Com o mesmo IP estático, planeie uma breve fase de mudança: desligue a SVA antiga e só depois arranque a nova VM. As origens mantêm o destino. Isto não garante uma transição sem perdas; a preservação dos eventos durante a interrupção também depende do buffering e do transporte do sistema de origem.

Para uma mudança gradual, defina o novo IP estático antes do download da ISO. Exemplo: o coletor antigo utiliza 192.0.2.10 e o novo 192.0.2.20. Não utilize estes endereços de documentação em produção. Escolha antes um endereço livre na rede correta do próprio ambiente e verifique a sub-rede, o gateway, o DNS e a acessibilidade a partir das redes de origem. Um novo IP facilita a reversão e permite mudar uma origem de cada vez, mas exige ajustar as regras de destino e de firewall.

Com DHCP e reutilização do IP antigo, antes da mudança documente os endereços MAC das VMs antiga e nova, a reserva IP anterior e o estado atual dos leases. Depois, altere ou crie a reserva do IP antigo para o endereço MAC da nova VM, seguindo o procedimento documentado de reservas e leases da plataforma DHCP utilizada. Em seguida, desligue a SVA antiga e só depois arranque o novo coletor. Verifique o lease efetivo e o IP atribuído antes de validar os dados. Uma reserva não impede que uma VM antiga ainda em funcionamento utilize o mesmo endereço.

Nos coletores cloud, o endereço muda sempre. Em AWS com CloudFormation, em Outputs do stack encontra-se o valor CTPxCollectorDnsName. É o nome DNS do Network Load Balancer e deve ser preferido a um IP fixo nas origens Syslog. Em Azure, verifique no portal Azure o endereço da interface de rede da VM; em GCP, o endereço interno em Compute Engine > VM instances. Os endereços DHCP podem ser identificados na tabela de leases pelo novo endereço MAC ou através de Data Collectors. Não confunda este destino das origens com os endereços regionais de uplink da Sophos.

Preparar o caminho de rede e os recursos do coletor

O upload do coletor para Sophos XDR utiliza mTLS com TLS 1.3 e TCP/443 de saída. Isto não significa que não sejam necessárias portas de entrada: as próprias origens Syslog têm de alcançar o coletor na porta e no protocolo configurados. Os destinos padrão são UDP/514 e TCP/601; compare também as associações de portas migradas com a configuração anterior. Não permita indiscriminadamente acesso da Internet ao recetor Syslog.

Permitir o uplink regional, o DNS e a sincronização da hora

Os destinos de uplink abaixo são um instantâneo verificado em 11 de outubro de 2026. A associação US1/US2/US3/EU1/EU2 vem da configuração do coletor XDR, não de uma equivalência presumida com uma região AWS Central. Utilize apenas a região efetivamente atribuída. O conjunto de IPs Sophos existente para chamadas API recebidas pelo fornecedor terceiro constitui outra lista permitida.

Se a própria firewall exigir permissões baseadas em IP, este instantâneo inclui os seguintes endereços de destino. Não combine regiões:

• US1: 18.217.45.178/32, 3.16.4.173/32, 18.224.219.97/32, 13.59.146.90/32, 3.16.16.254/32, 18.223.74.238/32.
• US2: 52.14.113.127/32, 3.141.73.137/32, 3.136.78.106/32.
• US3: 44.229.101.49, 35.166.77.47, 34.214.135.78.
• EU1: 18.158.143.139/32, 35.159.14.37/32, 52.59.37.234/32.
• EU2: 54.217.251.111/32, 54.194.78.20/32, 52.50.215.147/32.

Antes de alterar a produção, compare a região e os destinos com a configuração atual do tenant e com a safelist de coletores mantida pelo responsável operacional. Trate as diferenças numa alteração verificada, não numa permissão preventivamente mais abrangente. A grafia do endpoint técnico secureworks.com permanece inalterada.

O coletor também necessita de UDP e TCP/53 para os servidores DNS indicados no provisionamento. A sincronização da hora exige UDP/123 para os servidores NTP escolhidos. Sem uma definição NTP própria, os coletores fora de AWS utilizam 0.pool.ntp.org a 3.pool.ntp.org; em AWS, o destino padrão é 169.254.169.123. Com NTP local, o tráfego entre o coletor e o servidor de hora tem de ser permitido em ambas as direções. No coletor local, estes valores NTP servem para o bootstrap; após a ligação, o canal do backend XDR assume a sincronização da hora. Segundo o guia da plataforma, os controladores de domínio Windows não são um destino NTP para este host que não pertence ao domínio.

Pode indicar-se um forward web proxy em Host Proxy. A visão geral dos coletores exclui proxies autenticados configurados de forma fixa, enquanto o guia local também apresenta uma sintaxe URL com utilizador e palavra-passe. Estas indicações não coincidem. Por isso, não planeie um caminho de proxy autenticado em produção sem uma aprovação esclarecida pela Sophos; não contorne o conflito incorporando credenciais na ISO. Se existir inspeção TLS, o uplink mTLS concreto tem de funcionar sem intervenção MITM. Limite uma eventual exceção às ligações necessárias do coletor.

Não dimensionar a VM local pelos valores SVA antigos

A nova VM local necessita de 4 vCPUs com pelo menos 2 GHz, 8 GB de RAM, um disco de sistema de 20 GB e um disco de dados de 200 GB. O guia da plataforma indica como ambientes recomendados vSphere ESXi 6.7 ou posterior, Hyper-V 8.0 em Windows Server 2016 ou posterior e Nutanix 6.8.x ou posterior. A VM tem de ter acesso às funções de CPU x86-64-v2; uma máscara de compatibilidade de CPU inadequada pode impedir o arranque.

A indicação até 200'000 EPS é um limite superior para coletores cloud e locais corretamente configurados, não uma garantia de desempenho com estes recursos mínimos. Dimensione segundo o número, o tamanho e os picos de carga dos eventos e verifique o fluxo de dados real. Não instale ferramentas de terceiros nem aplicações adicionais no coletor. As atualizações são automáticas, normalmente a cada 24 horas, quando a ligação está saudável.

Implementar o coletor local pré-provisionado em vSphere

Para uma migração existente, utilize a configuração correspondente em Security Operations > Integrations > Data Collectors. Compare o nome, os valores de rede e as associações Syslog com a SVA antiga. Descarregue a ISO com a configuração do coletor e a OVA da VM. Os dois ficheiros têm de corresponder; uma ISO de outro coletor provisionaria o estado errado. Guarde os ficheiros de configuração com acesso restrito.

Se faltar a configuração, verifique primeiro as exclusões e os erros de rede na secção seguinte. Para um substituto novo criado manualmente de forma deliberada, a interface oferece Actions > Add Collector > On-Premises > Next. Preencha o nome e o hostname, se necessário a descrição, Host Proxy e NTP, bem como DHCP ou os valores estáticos completos, e crie com Create Collector. Isto não justifica criar um coletor duplicado sem controlo ao lado de uma migração já existente.

Em vSphere, a implementação faz-se assim:

1. Na vSphere Web Console, abra Virtual Machines > Create / Register VM e selecione Deploy a virtual machine from an OVF or OVA file.
2. Atribua um nome inequívoco à VM, por exemplo sophos-xdr-collector, e selecione a OVA descarregada. O nome é de livre escolha; deve distinguir a VM da SVA antiga no hipervisor.
3. Selecione um datastore com pelo menos 220 GB livres para os dois discos. Verifique a associação de rede e a configuração dos discos, reveja o resumo e conclua com Finish. Mantenha a VM desligada por enquanto.
4. Em Storage > Datastore Browser, carregue a ISO de configuração correspondente.
5. Abra Edit Settings da VM. Altere o CD-ROM de Client Device para Datastore ISO File, selecione a ISO carregada e guarde. Antes do primeiro arranque, confirme que a ISO está efetivamente montada e que a VM alcança a rede de origem correta.
6. Se o IP for o mesmo, desligue agora a SVA antiga. Só depois arranque a nova VM. Com um novo IP, a SVA antiga pode continuar a funcionar; as origens serão mudadas individualmente em seguida.
7. Em Security Operations > Integrations > Data Collectors, espere até o novo coletor indicar Ready. Só então pode desmontar a ISO. Ready ainda não confirma que todas as origens estão a ser recebidas corretamente.

Para Hyper-V, a Sophos disponibiliza um pacote VHD em vez de OVA; para Nutanix, ficheiros QCOW2. O segundo disco de dados e a ISO montada no primeiro arranque continuam a ser necessários. A sequência de cliques vSphere não deve ser aplicada a estas plataformas. Os coletores cloud também têm de ser implementados com os recursos da respetiva plataforma, não como OVA em vSphere.

Mudar as origens e validar o fluxo de dados

Se o endereço de destino mudar, atualize todos os dispositivos e aplicações afetados para o novo IP ou nome DNS do coletor. Altere apenas o destino, não a porta, o protocolo ou o formato dos logs sem análise: estas associações deverão ser transferidas da SVA. Se uma origem enviava por UDP/514, mantém UDP/514 neste caso de migração. Mudar o transporte para TCP é uma alteração separada, que exige verificar o sistema de origem.

Com IPs diferentes, comece por mudar uma origem de âmbito limitado. Gere nela um evento inofensivo recolhido pelo conector e registe a origem, o tipo de evento e a hora com fuso horário. Procure-o no XDR através do percurso de dados ou consultas disponibilizado para essa integração. A comprovação tem de mostrar o tenant correto, a origem, o timestamp e o formato de evento adequado. Considere os atrasos esperados do conector; um evento de teste não tem necessariamente de gerar um Case ou uma Detection.

Só depois desta verificação mude as restantes origens. Compare, para cada uma, os últimos eventos antes da mudança e os primeiros depois. Não se espera a mesma duração ou taxa de eventos para todas as origens; o que importa é a atividade real e a ausência de períodos sem explicação. Evite enviar o mesmo fluxo simultaneamente para ambos os coletores sem planeamento, pois pode criar duplicados.

A SVA anterior pode continuar a funcionar durante o planeamento. Os dados históricos SVA já ingeridos continuam consultáveis no XDR; o substituto não tem de os reenviar. Isto não constitui uma nova garantia de retenção ilimitada. O spool de 200 GB do novo coletor armazena temporariamente logs quando o uplink está lento ou temporariamente interrompido. Não substitui a verificação da origem nem garante a cobertura de interrupções de duração ilimitada.

A validação operacional só está concluída quando todas as origens esperadas fornecem dados atuais corretamente associados, os filtros e exclusões foram verificados deliberadamente, o DNS, a sincronização da hora e o uplink funcionam e, quando aplicável, o NDR continua a operar separadamente. Documente o momento da mudança e o período de observação. Até lá, preserve a SVA antiga e a sua configuração para uma possível reversão; só depois decida sobre as cargas de trabalho restantes e a retirada segura de serviço.

Identificar falhas e reverter sem conflito de IP

Não existe um novo coletor: uma appliance física, uma SVA exclusivamente NDR ou uma VM que não seja SVA não é migrada automaticamente. Numa SVA Syslog em utilização, verifique se a porta e o protocolo estão configurados e se os valores estáticos de rede estão completos. A ausência de gateway ou DNS pode impedir a migração. Corrija a configuração de rede inválida no Fusion e esclareça com o suporte uma nova migração, ou crie um coletor manual expressamente planeado. Não introduza endereços fictícios apenas para que um formulário seja aceite.

A nova VM não arranca: verifique a associação da ISO, o segundo disco, a RAM, as vCPUs e as funções x86-64-v2 visíveis para a VM. Não instale software de reparação ou monitorização no coletor.

O coletor permanece offline: verifique primeiro o IP efetivamente atribuído ou o lease, o gateway, o DNS e a sincronização da hora no bootstrap. Depois, consulte os logs da firewall ou do proxy para o uplink regional TCP/443. Uma porta de saída aberta, por si só, não comprova um canal mTLS bem-sucedido. No cenário com o mesmo IP, confirme também que a SVA antiga está realmente desligada.

O coletor está Ready, mas falta uma origem: verifique o destino da origem, a rota e a porta Syslog de entrada. Compare a associação de portas e o formato com a integração antiga. Um log forwarder a montante tem de preservar o formato esperado da integração; caso contrário, os dados podem chegar como eventos genéricos e não no esquema esperado. Comprove primeiro o caminho dos dados e só depois procure uma Detection.

Para reverter, trate separadamente os endereços estáticos e as reservas DHCP:

• Mesmo IP estático: desligue a nova VM e só depois arranque a SVA antiga com a configuração estática preservada. As origens mantêm o destino anterior. Verifique se a SVA antiga utiliza efetivamente esse IP e recebe e encaminha novos eventos Syslog. Nunca ligue as duas VMs com este endereço.
• Reserva DHCP para o mesmo IP: desligue primeiro a nova VM. Depois, associe novamente a reserva do IP antigo ao endereço MAC antigo da SVA documentado e trate o estado dos leases segundo o procedimento documentado da própria plataforma DHCP. Não se pressupõe aqui um comando universal de eliminação de leases. Só então arranque a SVA antiga, verifique o lease e o IP efetivos e comprove a receção e o encaminhamento com um novo evento Syslog. As origens mantêm o destino anterior; por isso, arrancar a SVA, por si só, ainda não comprova uma reversão funcional. Nunca ligue as duas VMs com este endereço.
• Outro IP ou destino DNS: reponha os destinos das origens documentados e, quando aplicável, as regras de rede associadas para o coletor antigo. Com um novo evento, verifique se a SVA antiga volta a receber e encaminhar. Retire o novo coletor de serviço apenas após verificar todas as associações.

A reversão só está validada quando se comprova que a SVA antiga detém o endereço de destino previsto e que novos eventos Syslog voltam a ser recebidos e encaminhados.

A reversão só funciona enquanto a SVA antiga estiver disponível e a sua configuração preservada. Não reverte o upgrade do produto realizado pelo fornecedor nem garante recuperar eventos não entregues. A Sophos anuncia um fim de suporte posterior para Log Collectors SVA, mas a informação de migração aqui verificada não indica uma data concreta. Após a migração, as novas instâncias Log Collector devem ser criadas como XDR Data Collectors; a SVA antiga é, por isso, um caminho de reversão limitado para o ambiente existente, não uma estratégia de novas instalações a longo prazo.

Se a causa continuar por esclarecer, recolha a identidade do coletor e do tenant, a plataforma, os valores de rede sem dados sensíveis, a origem afetada, os intervalos de tempo exatos, o estado e a mensagem de erro. Para escalar, consulte Abrir um ticket de suporte Sophos. Secrets, a ISO de configuração e logs sem remoção de dados sensíveis não devem ser incluídos em tickets ou capturas de ecrã de acesso público.