Implementar Sophos Server Protection em instâncias AWS EC2 e VMs Azure

Uma instância EC2 ou VM Azure é protegida no sistema operativo convidado com Sophos Server Protection. Para Windows Server, utiliza-se o Windows Server Installer; para servidores Linux compatíveis, o Sophos Protection for Linux (SPL). A localização da VM não altera a escolha do agente de servidor. Sophos Firewall como appliance virtual na AWS ou no Azure protege e encaminha o tráfego de rede, mas não substitui o agente no sistema convidado. Sophos Cloud Optix é um produto separado de avaliação da postura de segurança e inventário na cloud, não um pré-requisito para instalar a proteção do servidor: segundo o aviso de ciclo de vida da Sophos, o suporte e o acesso terminam em 30 de setembro de 2026. Por isso, não deve servir de base a um novo processo, nem a um processo duradouro, de inventário e limpeza na cloud. A disponibilidade e a cobertura contratual de Server Protection e das suas funcionalidades no tenant em causa têm de ser verificadas separadamente.

Percurso rápido: Selecionar uma VM representativa, validar o sistema operativo e o modo de proteção, testar a ligação ao Sophos Fusion a partir da rede cloud efetivamente utilizada, instalar o instalador de servidor associado ao tenant e, depois, verificar My Products > Server > Servers e os detalhes do servidor. Só avançar para a fase seguinte quando o registo, o grupo, as políticas, o estado de funcionamento do agente e a aplicação estiverem a funcionar. Para instâncias de curta duração, é também necessário planear uma reconciliação própria com o inventário da cloud.

Antes do piloto: definir a proteção e a ligação à rede

1. VM e contrato: Registar a conta AWS ou subscrição Azure, a região, a função da VM, a versão do sistema operativo ou distribuição Linux, a arquitetura e o ciclo de vida. Confirmar a compatibilidade atual desse sistema operativo convidado e dos componentes necessários. Confirmar a licença do tenant específico e o SKU de servidor contratado, incluindo os termos contratuais aplicáveis a estas VMs; a presença de um botão de transferência não comprova o direito de utilização.
2. Modo de proteção: Escolher a proteção antimalware completa da Sophos ou o XDR Sensor. O XDR Sensor isolado não oferece proteção antimalware e requer uma solução de proteção de terceiros ativa. Antes de mudar, identificar possíveis conflitos com o software de segurança existente e definir um plano de reversão para a VM afetada.
3. Ligação de saída: Verificar, a partir da sub-rede prevista, se DNS, HTTPS, os destinos Sophos exigidos pelo tenant e, se aplicável, o proxy ou Message Relay estão acessíveis durante a instalação e o funcionamento. Security Groups, Network Security Groups, rotas da cloud, NAT, firewalls e inspeção TLS podem afetar o percurso. A lista de permissões atual e o diagnóstico do proxy estão em Requisitos de rede e proxy. Não presumir que uma lista fixa de endereços IP da cloud substitui os destinos Sophos.
4. Piloto e critérios de aceitação: Selecionar um pequeno grupo de VMs com função de servidor, versão do sistema operativo, segmento de rede e, se aplicável, percurso pelo proxy representativos. Registar os nomes, o grupo de servidores esperado, as políticas pretendidas, a janela de reinício, o teste da carga de trabalho e os critérios de paragem. Se houver várias sub-redes ou imagens, planear pelo menos um teste adequado para cada percurso diferente.

Exemplo: uma VM de aplicações Windows e uma VM de processamento Linux em sub-redes privadas diferentes constituem dois casos de piloto, não um único teste de rede. O sucesso do instalador na primeira VM não prova que a segunda consiga alcançar o destino de atualização através do seu percurso NAT ou proxy.

Executar o instalador no sistema convidado e preparar corretamente as imagens

Em My Environment > Installers > Server Protection, selecionar o Windows Server Installer ou o Linux Server Installer correspondente ao modo de proteção aprovado, no tenant Sophos Fusion correto. Numa VM Windows individual, transferir SophosSetup.exe de forma segura, executá-lo com privilégios de administrador local, seguir as verificações prévias apresentadas e concluir a instalação, incluindo o reinício solicitado. Numa VM Linux, transferir SophosSetup.sh de forma segura, torná-lo executável e executar primeiro sudo ./SophosSetup.sh --test e, se o teste for bem-sucedido, sudo ./SophosSetup.sh. Depois, verificar o registo no tenant e o estado de funcionamento local do agente; o simples facto de o instalador terminar não é suficiente. O modo de proteção, as opções avançadas da CLI, os registos e a resolução de problemas estão em Instalar e implementar Windows Server Protection e Instalar e implementar SPL. Guardar o instalador associado ao tenant e o respetivo endereço de transferência apenas num repositório de pacotes protegido, nunca numa imagem de VM ou num repositório públicos.

Não clonar sem alterações a VM principal já registada. No caso do SPL numa imagem padrão Linux, depois da instalação a VM principal tem de ser removida do registo com registerCentral --deregister, conforme o procedimento para imagens padrão Linux, desligada imediatamente e guardada como imagem enquanto estiver desligada. Se a VM principal voltar a arrancar, poderá registar-se novamente; nesse caso, remover novamente o registo antes de guardar a imagem. Iniciar dois clones e verificar as suas identidades separadas.

O Windows Server exige um processo de criação de imagens diferente: Antes de criar a imagem, verificar se Tamper Protection está desativado para a configuração da imagem e se Server Lockdown ou Update Cache estão ativos; não criar uma imagem padrão a partir de servidores com estes últimos componentes ativos. Também não são elegíveis VMs principais encriptadas com BitLocker ou com componentes Sophos Encryption. Executar SophosSetup.exe --goldimage como administrador, com o Windows Server Installer associado ao tenant, de acordo com o procedimento para imagens padrão Windows (também aplicável a servidores); verificar a instalação e o estado de funcionamento, reativar Tamper Protection e desligar a VM principal antes de capturar a imagem. No primeiro arranque, cada clone tem de receber atempadamente, antes de ser detetado pela Sophos, um nome de computador definitivo e diferente do da VM principal: a Sophos identifica os clones pela alteração do nome, não pelo ID da instância na cloud. Se a atribuição do nome demorar, verificar o modo de timeout descrito no guia; o Notification Mode é aí descrito para o VMware Horizon Instant Clone e não deve ser aplicado indiscriminadamente a EC2/Azure. Não considerar uma instalação Windows comum pronta para clonagem. Também neste caso, validar separadamente dois clones no Fusion.

Verificar a fase de implementação na cloud e parar em caso de erro

Depois da instalação ou do arranque de um clone piloto, abrir individualmente os servidores esperados em My Products > Server > Servers. Se houver dois clones em execução ao mesmo tempo, têm de aparecer dois objetos de servidor distintos. Na validação, registar uma correspondência externa entre conta AWS/subscrição Azure, região, ID da instância EC2/ID do recurso da VM Azure, ID do servidor no Fusion, responsável e data de criação; a lista de servidores não apresenta automaticamente os IDs da cloud. Nos detalhes, verificar Summary, Status e Policies, bem como a última atividade, o estado de funcionamento, os componentes instalados e as políticas de servidor efetivamente aplicadas. A primeira Default Policy atribuída automaticamente não é necessariamente a política de produção prevista. Em seguida, comparar o serviço, o acesso à aplicação, o backup e um teste representativo da carga de trabalho antes e depois de um reinício necessário.

Se uma VM não aparecer no Fusion, verificar primeiro o tenant e os filtros e, depois, DNS, proxy, ligação de saída à rede e registos de instalação conforme o runbook de Windows ou Linux aplicável. Se não for possível distinguir os clones, parar a implementação da imagem e rever o passo de identidade do procedimento para imagens padrão. Perante componentes incorretos, problemas no estado de funcionamento ou perturbações da carga de trabalho, não avançar para outra fase; investigar a fase afetada isoladamente, em vez de voltar a aplicar às cegas instaladores e políticas.

Tratar separadamente instâncias terminadas e dispositivos inativos

VMs de curta duração podem já ter sido terminadas enquanto o respetivo registo continua visível no Sophos Fusion. Uma data antiga em Last Active não prova que a instância na cloud foi terminada nem define um prazo universal de limpeza automática. Reconciliar regularmente a correspondência externa entre conta/subscrição, região, ID da instância ou do recurso na cloud e ID do servidor no Fusion com o inventário AWS/Azure e o inventário de dispositivos do Fusion; registar o responsável, as datas do ciclo de vida e a prova do evento Terminate da instância EC2 ou Delete da VM Azure. A reutilização de um nome de host ou uma VM Azure parada não prova que o objeto de servidor correspondente tenha sido desativado.

A reconciliação manual e a eliminação direcionada com Delete continuam a ser a base do processo: só depois de confirmar a terminação na cloud e a correspondência inequívoca entre IDs se devem preservar os alertas e dados de investigação necessários, verificar eventuais duplicados e documentar a desativação ou a proteção substituta. O Delete no Fusion não substitui a desinstalação numa VM ainda em funcionamento nem o processo de ciclo de vida na cloud.

Em separado, a Sophos documenta em Removal of inactive devices uma regra configurável para dispositivos Server inativos: direcionada a grupos ou global com exceções de grupos (as exceções não se aplicam às regras direcionadas). Esta regra reage à inatividade, não a um evento confirmado de EC2 Terminate ou Azure Delete, e não desinstala o agente. Antes de a ativar no tenant, testar num conjunto de dispositivos as opções de grupos, prazo, exceções, retenção de dados e consequências para VMs de produção paradas ou temporariamente inacessíveis; não presumir um prazo geral nem efeitos nas licenças. A antiga integração Cloud Optix oferecia, para ambientes AWS/Azure existentes associados ao mesmo tenant e com agentes de servidor, uma limpeza separada na terminação, desativada por predefinição, ativável apenas por um Super Admin e sem efeito retroativo sobre instâncias terminadas anteriormente. Como o suporte e o acesso terminam em 30 de setembro de 2026, esta informação serve apenas de contexto histórico e não é uma recomendação para novas configurações ou automatização duradoura. Não se pressupõe nenhum comportamento não confirmado para hooks de eliminação de autoscaling, automatização por API ou contagem de licenças.