Sophos Server Protection: validar com segurança as plataformas Windows e Linux

Decisão em resumo: Um servidor só entra na próxima fase de instalação ou atualização se o seu sistema operativo específico e o respetivo agente cumprirem os requisitos atuais da Sophos, as funcionalidades necessárias estiverem disponíveis no tenant e um piloto representativo se mantiver em bom estado. Uma linha em notas de versão antigas apenas demonstra que houve componentes para uma plataforma — não que o sistema operativo continue a ter suporte sem restrições. Sem provas fiáveis, o servidor fica fora desta fase e a questão da plataforma deve ser esclarecida com o Suporte da Sophos.

Este guia ajuda a tomar a decisão de aprovação antes de uma nova instalação, mudança de sistema operativo ou atualização do agente. Os passos propriamente ditos para Windows Server e Sophos Protection for Linux (SPL) encontram-se nos respetivos guias de instalação.

Verificar separadamente a versão publicada e o suporte da plataforma

À data da verificação, 24 de setembro de 2026, as notas de versão da Sophos indicam 2026.2.2.1 (setembro de 2026) como versão mais recente do Server Core Agent para Windows, com secções de componentes distintas para Windows Server 2016 e posterior e para plataformas legadas mais antigas. As notas de versão atuais do Windows Server Core Agent são a referência para alterações de versões e componentes. Também avisam que a distribuição do software pode prolongar-se por várias semanas após a publicação das notas. Uma secção de componentes, antiga ou atual, não confirma o suporte de uma determinada edição ou compilação do Windows.

Segundo os requisitos de sistema da Sophos para Windows Server (KBA-000003024, em 7 de maio de 2026), Windows Server 2016, 2019, 2022 e 2025 são gerações de servidores com suporte completo. Windows Server 2008 R2, 2012 e 2012 R2 são plataformas legadas e exigem uma licença de Extended Support; algumas funcionalidades podem não estar disponíveis, ser suportadas ou receber atualizações. Sensor Mode não é suportado em plataformas legadas. Esta lista datada não aprova indiscriminadamente todas as edições, arquiteturas ou variantes de compilação. Antes da fase, registe a edição exata, a compilação completa do sistema operativo, a arquitetura, a versão do agente, o modo de proteção pretendido e, para hosts legados, o direito efetivo a Extended Support. Antes da aprovação, verifique para a combinação concreta os requisitos de sistema atuais da Sophos para Windows Server, as informações sobre as variantes Windows suportadas e o calendário de retirada de suporte. Se a página de suporte da Sophos não estiver acessível ou não der uma resposta inequívoca, suspenda a aprovação e consulte o Suporte da Sophos. O facto de um agente arrancar ou constar das notas de versão não comprova, por si só, o direito a suporte.

Verifique os recursos conforme a licença e o modo: Em 7 de maio de 2026, os mínimos para Sophos Endpoint – Server eram 8 GB de espaço livre em disco, 8 GB de RAM e 2 núcleos. Para Sophos EDR, XDR e MDR – Server, os mínimos eram 10 GB de espaço livre em disco, 8 GB de RAM e 2 núcleos; recomendavam-se 10 GB de espaço livre em disco, 16 GB de RAM e 4 núcleos. Estes requisitos aplicam-se tanto a Full Protection como a Sensor Mode — a tabela de recursos não anula a proibição do Sensor Mode em plataformas legadas. A Sophos recomenda vivamente uma SSD para a unidade de arranque. Os valores são orientações gerais, não uma garantia de desempenho suficiente para todas as cargas: em especial durante a deteção e limpeza de malware, a utilização de CPU, RAM e disco pode aumentar temporariamente. Verifique a margem disponível e o comportamento no seu piloto.

Para Linux, as notas de versão do SPL indicavam 2026.3 (setembro de 2026) como versão mais recente na mesma data de verificação. Também neste caso, a disponibilização no seu tenant pode ocorrer depois da publicação das notas. Em System requirements, os requisitos então indicados eram, no mínimo, 2,5 GB de espaço livre em disco, 2 GB de memória RAM livre, x86_64 ou ARM64, systemd em execução, Bash e glibc a partir da versão 2.17; em ARM64, glibc a partir da versão 2.18 e kernel a partir da versão 5.3. Estes valores constituem uma referência datada para a verificação, não uma aprovação permanente de todas as distribuições ou kernels Linux.

As orientações da Sophos sobre distribuições e kernels para SPL remetem para System requirements > Supported platforms nas notas de versão para a lista atual de plataformas; não constituem uma segunda matriz de suporte independente. A distribuição, as versões principal e secundária, a arquitetura, o kernel em execução e o suporte do fabricante têm de ser compatíveis entre si. Na data indicada, a lista testada incluía, entre outras, RHEL 8–10, Debian 11–13, Ubuntu 22.04/24.04 LTS e Ubuntu 26.04; existe ainda uma lista de plataformas legadas apresentada em separado, que não equivale a uma aprovação automática. A Sophos testa as versões secundárias ou os Service Packs ativos mais recentes; em x86_64, podem aplicar-se versões mínimas de kernel específicas de cada distribuição. Por isso, um kernel 5.3 não constitui uma aprovação geral para x86_64. Mesmo um kernel acima do mínimo pode causar problemas: as notas atuais apontam um erro conhecido de ftrace nas versões 5.10.133 a 5.10.142, que pode bloquear o kernel. Não aprove esta combinação só porque a instalação decorreu sem incidentes; esclareça primeiro a situação do kernel e as orientações da Sophos.

Separar as exceções antes do piloto: Se a imagem Linux for immutable, não aprove o SPL neste caso: segundo a Sophos, o SPL não foi concebido para distribuições immutable, para as quais existe o produto distinto Sophos Linux Sensor (SLS). O SLS não é o XDR Sensor do SPL; este guia não descreve a instalação do SLS. Distribuições derivadas que não constem da lista, kernels personalizados ou mínimos e sistemas reforçados também não passam automaticamente a ser plataformas testadas: a Sophos prevê nesses casos uma avaliação segundo o princípio do esforço comercialmente razoável e pode exigir que o problema seja reproduzido numa plataforma suportada ou que se faça uma atualização.

Para um servidor Linux legado já existente, verifique ainda o direito efetivo a suporte alargado e tanto o pacote de software instalado como o atribuído através do Update Management. Em 24 de setembro de 2026, a Sophos indicava para versões legadas o pacote LTS suportado 2026.1.0.35 e recomendava a sua atribuição através do Update Management; em caso de problemas com um pacote mais recente, pode ser necessário voltar ao pacote suportado para investigar. Antes de qualquer alteração, confirme as orientações da Sophos então em vigor e a disponibilidade concreta do pacote: o título das notas do SPL 2026.3 não torna esta versão um destino automático para um servidor legado, e 2026.1.0.35 não é uma garantia permanente nem uma instrução geral para reverter versões.

Documentar a aprovação de uma fase concreta

Um registo breve da verificação evita confundir uma instalação funcional com uma prova de suporte. Registe separadamente cada família de servidores — por exemplo, servidores de aplicações Windows e servidores de bases de dados Linux:

Situação atual e pretendida: Função do servidor, edição do sistema operativo ou distribuição e versão secundária, compilação completa ou uname -r, arquitetura, agente instalado com os respetivos componentes e versão de destino pretendida. Em Windows, verifique o tipo de licença (Endpoint – Server ou EDR/XDR/MDR – Server), Full Protection ou Sensor Mode, espaço livre em disco, RAM, núcleos e unidade de arranque. Em Linux, verifique também o tipo de imagem (immutable ou modificável), RAM e espaço livres no volume efetivo da instalação, systemd em execução, Bash e glibc. Para Linux legado, registe separadamente os pacotes de software instalado e atribuído.
Comprovativos: Anote a data e o estado dos requisitos de sistema Windows e das notas de versão do Windows ou SPL, os requisitos atuais de sistema operativo/kernel, o ciclo de vida e o suporte alargado, incluindo o direito efetivo para servidores legados, bem como a licença e as funcionalidades necessárias no tenant. Para Windows, sem confirmação inequívoca da edição, compilação, arquitetura e modo de proteção, assinale expressamente por esclarecer em vez de «compatível». A menção de uma nova funcionalidade nas notas de versão — por exemplo, Linux como Update Cache ou Message Relay a partir do SPL 2026.3 — não substitui a confirmação da sua disponibilidade efetiva no tenant nem dos requisitos específicos dessa funcionalidade.
Decisão: «aprovado para piloto», «atualizar primeiro o sistema operativo/kernel» ou «parar e esclarecer com o suporte». Identifique o responsável pela verificação, a janela de alteração, os equipamentos piloto e os critérios de paragem. A primeira opção exige uma confirmação positiva de suporte da plataforma; uma compilação derivada não testada não equivale a uma combinação testada. Linux immutable fica fora da fase de implementação do SPL; para Linux legado, só prossiga depois de confirmar o direito a suporte, a atribuição do pacote adequado e uma prova atual de suporte.

No servidor Linux piloto, execute estes comandos apenas de leitura tão perto quanto possível da janela de alteração e registe os resultados:

cat /etc/os-release
uname -r; uname -m
free -m
df -h -- /opt
ps -p 1 -o comm=; test -d /run/systemd/system && printf 'systemd läuft\n'
command -v bash; getconf GNU_LIBC_VERSION

Em free -m, compare a coluna available (não total) com os 2 GB de memória livre exigidos. df -h -- /opt só é adequado para uma instalação padrão se /opt estiver no volume de destino efetivo; se houver uma montagem separada ou for usado --install-dir, verifique antes com df -h -- <Pfad> um caminho já existente no volume efetivo da instalação e comprove 2,5 GB livres. Se ainda não for possível identificar esse volume, não aprove os recursos. ps e o diretório /run/systemd/system permitem verificar o sistema de inicialização em execução; Bash tem de estar disponível e a versão de glibc apresentada tem de corresponder aos requisitos da arquitetura. Confirme ainda se a imagem é immutable pelo tipo de imagem/sistema operativo no inventário de implementação; os-release, por si só, não comprova que o servidor seja modificável. Para Windows, guarde os dados completos do sistema operativo e do agente a partir do inventário gerido e das propriedades do sistema, bem como os recursos para a licença e o modo de proteção previstos. Repita a verificação sempre que mudarem o sistema operativo, o kernel, o agente, a licença ou os requisitos da Sophos; não se baseie apenas na data deste artigo.

Piloto, estado de funcionamento e fase seguinte

Escolha primeiro um servidor representativo de cada combinação de plataformas relevante: mesma versão secundária do sistema operativo, arquitetura e kernel, percurso de rede/proxy semelhante e função e carga comparáveis. Antes do piloto, confirme a cópia de segurança e o processo de restauro, assegure acesso à consola ou fora de banda e reserve uma janela de manutenção que contemple um possível reinício. Uma base de dados com picos específicos de E/S exige um teste de carga adequado; arrancar uma máquina virtual de teste sem carga não basta.

Depois da instalação ou atualização, em My Products > Server > Servers no tenant correto, confirme que o servidor piloto aparece uma única vez, comunica de forma atualizada, apresenta os componentes de proteção esperados, pertence ao grupo de servidores previsto e não tem alertas persistentes de estado de funcionamento. Compare os componentes e versões instalados no equipamento e na Fusion; verifique a política de servidor efetiva no servidor, e não apenas a atribuição ao grupo. Em Linux, verifique também sudo systemctl status sophos-spl. Apenas se o plugin antivírus estiver instalado, leia sudo cat /opt/sophos-spl/plugins/av/VERSION.ini no caminho padrão (adapte-o se --install-dir tiver sido alterado) e compare a versão com o componente Server Protection, não com o componente base do SPL, no Central. Num SPL XDR Sensor sem plugin antivírus, verifique antes os componentes efetivamente instalados e as respetivas versões e estado no Central; a ausência do ficheiro do antivírus não é um erro nesse caso. Um serviço em bom estado, por si só, não confirma a proteção atual contra malware nem a aplicação efetiva de uma política. Apenas com proteção antivírus instalada e depois de confirmar que Real-time scanning - Local files and network shares e Enable scan for Server Protection for Linux Agent estão ativos na Server Threat Protection Policy efetiva, realize um teste planeado e seguro de deteção no acesso, conforme o guia de instalação Linux; um XDR Sensor sem antivírus não é adequado para esse teste.

Em seguida, compare a aplicação de negócio, o comportamento após reinício, as ligações de rede e a carga normal com a situação anterior. Para uma nova funcionalidade do agente, confirme primeiro se está efetivamente disponível para o piloto no tenant. A fase seguinte, de âmbito limitado, só começa quando a prova de suporte da plataforma, o estado do agente e da política, o estado de funcionamento e o teste da aplicação tiverem sido aprovados em conjunto. As notas de versão podem ser publicadas antes da disponibilização; se a versão efetivamente oferecida for diferente, investigue em vez de forçar uma transferência.

Preparar a paragem e a reversão

Antes da alteração, registe as versões funcionais do sistema operativo/kernel e do agente; em Linux legado, registe também os pacotes de software instalado e atribuído, a cópia de segurança, a janela de manutenção, o modo de proteção e o responsável. Não presuma que pode regressar a um agente antigo apenas porque a versão figura em notas de versão históricas. Para reverter o sistema operativo ou o kernel, é preciso verificar separadamente a capacidade de arranque, a consistência dos dados e o suporte da versão de destino. Embora a Sophos possa pedir, em casos de suporte de Linux legado, o regresso ao pacote suportado, os pacotes de software ou as políticas de atualização da Sophos não são um mecanismo universal de downgrade; esclareça antecipadamente com a Sophos a via de reversão para o servidor concreto.

Se o registo falhar, o estado de funcionamento continuar mau, a proteção não corresponder ao previsto, ocorrerem reinícios inesperados ou a aplicação do servidor for afetada, interrompa imediatamente a distribuição e as tentativas automáticas, identifique os servidores afetados e delimite o grupo da distribuição; não inicie outra fase. Verifique primeiro o tenant, a ligação, a política efetiva, a versão do agente oferecida e eventuais diferenças no sistema operativo/kernel face ao registo. Limite qualquer correção de política ao piloto e volte a validá-la depois; não desative a proteção em todo o tenant. Se for necessário reverter, use o procedimento de restauro do sistema previamente definido e testado e o processo do Suporte da Sophos adequado à versão concreta do agente. Não remova componentes ou controladores por tentativa. Se a questão da plataforma ou uma via de reversão suportada continuar por esclarecer, guarde os registos e os dados da plataforma e contacte o Suporte da Sophos; até lá, mantenha a implementação suspensa.