Implementar Sophos XDR Data Collectors em AWS, Azure e GCP

Um Sophos XDR Data Collector recebe eventos syslog e encaminha-os cifrados para XDR. A implementação cloud começa em Security Operations > Integrations > Data Collectors > Actions > Add Collector > Cloud-Hosted. Depois gera-se um template para AWS, Azure ou GCP, associado à configuração específica do collector, e implementa-se na conta cloud própria.

Os três caminhos não usam imagens VM intercambiáveis. AWS utiliza AMI com CloudFormation e EC2 User Data; Azure, VHD com ARM e Custom Data; GCP, configuração Terraform para Infrastructure Manager. Este runbook descreve esses caminhos; a migração SVA e implementação local permanecem separadas.

Esclarecer rede, responsabilidade e custos antes de implementar

São necessários o tenant Sophos correto, conta ou projeto cloud autorizado e permissões para o template escolhido. Instância, discos, load balancer e outros recursos podem gerar custos cloud. Verificar template, rede, regras de segurança, responsáveis e âmbito de remoção antes de implementar. Restringir acesso às configurações geradas e credentials incluídas.

Registar, por origem, os eventos enviados, formato esperado e destino. Entradas syslog padrão são UDP/514 e TCP/601. Limitar regras às redes de origem necessárias em vez de abrir ao conjunto da Internet. O collector requer saída TCP/443 para o uplink XDR regional atribuído, DNS por UDP/TCP 53 e sincronização inicial por UDP 123. O runbook de migração explica os destinos regionais; compará-los com a safelist atual antes da alteração.

Sem NTP próprio, collectors não AWS usam os servidores pool documentados; AWS utiliza 169.254.169.123. Após ligação bem-sucedida, o canal backend sincroniza a hora; Admiral pode mostrar ntp.collector. Host Proxy é opcional. A ajuda geral exclui proxies autenticados fixos, embora algumas páginas de instalação mostrem sintaxe com utilizador/password. Esclarecer primeiro com a Sophos um caminho de proxy autenticado em produção; credentials no template não resolvem o conflito documental.

Criação comum no Sophos Fusion

Abrir Security Operations > Integrations > Data Collectors > Actions > Add Collector.
Escolher Cloud-Hosted e continuar com Next.
Preencher Name e Hostname únicos e, se necessário, descrição, Host Proxy e servidores NTP próprios. Verificar tenant, associação à rede e valores antes de Create Collector.
Escolher Create Collector e depois o Cloud Service Provider adequado. Os dados e ficheiros seguintes pertencem apenas a esse collector e não podem ser reutilizados em várias instâncias independentes.

AWS: CloudFormation, um collector e um NLB

São necessários AWS Account ID de 12 dígitos, região suportada no diálogo Sophos e VPC existente adequado com subnets. O template de exemplo cria Launch Template com AMI/User Data, Auto Scaling Group dimensionado estaticamente para uma instância, Network Load Balancer e regras syslog.

O NLB trabalha em Layer 4 e suporta TCP e UDP. O nome DNS estável continua utilizável como destino das origens após substituir uma instância. Um Application Load Balancer ou ELB clássico não substitui este desenho documentado. O collector AWS não suporta HA nesta configuração; manter Auto Scaling Group com tamanho 1. Duas instâncias simultâneas com User Data idêntica não são suportadas.

Implementar a configuração AWS

No diálogo Sophos, escolher Amazon Web Services (AWS), introduzir Account ID e selecionar região AWS suportada.
Se necessário, guardar e rever o YAML por Download. Launch Console abre Create stack do CloudFormation com o template gerado.
Associar CollectorName, VpcId e Subnets ao ambiente pretendido. Verificar VpcCidr e o SyslogIngress adicional face às redes efetivamente autorizadas. 0.0.0.0/0 é uma origem IPv4 sem restrições e não deve ser adotada como padrão.
Verificar InstanceType. O template Sophos usa c5.xlarge, 4 vCPUs e 8 GB RAM. Num template próprio, o disco de dados adicional deve manter pelo menos 200 GB e associação /dev/sdb.
Se usar EBS Encryption, pedir ao responsável AWS que confirme KmsCmkArn e a key policy necessária. Uma policy inadequada pode provocar lançamentos falhados repetidos.
Rever opções com Next. Só implementar com Create stack depois de aprovados os recursos e regras concretos.
Após sucesso, guardar CTPxCollectorDnsName em Outputs do stack. Este DNS do NLB é o destino das origens syslog, não um IP temporário EC2.

Verificar estado no Sophos Fusion. Como AWS atribui endereços dinamicamente, uma coluna Address vazia não é automaticamente erro. Investigar ciclos de arranque no Auto Scaling Group pelos eventos AWS; perante Client.InternalError: Client error on launch com EBS Encryption ativo, verificar particularmente a KMS key policy. Não iniciar instâncias adicionais com a mesma configuração em paralelo.

Azure: template ARM novo e permissões limitadas

São necessários uma subscrição Azure e Virtual Network adequado com subnet. O template Sophos requer Owner ou Contributor + User Access Administrator. Ajustar estas permissões ao âmbito necessário e à implementação autorizada, sem as atribuir permanentemente a todos os operadores.

O template copia a VHD para um Storage Account com contentor privado, cria Managed Image e uma VM collector com Network Security Group. O Storage Account destina-se a esta tarefa. A SAS URL da VHD só é válida durante três horas desde a geração do template ARM. Não repetir simplesmente um template antigo inalterado.

Templates descarregados a partir de 3 de agosto de 2026 usam um Azure Deployment Script temporário fora do Virtual Network para transferir a VHD. Não requerem bootstrap VM, bootstrap NSG nem exceção adicional de saída bootstrap no VNet. Templates anteriores utilizavam outro desenho com VM temporária e contentor de limpeza; não transportar preventivamente essas exceções para uma nova instalação. Gerar um template novo para nova implementação.

Implementar a configuração Azure

Escolher Microsoft Azure no diálogo Sophos. Usar Download ARM Template se necessário; Deploy in Azure abre Custom deployment preparado.
Escolher Subscription e Resource group correto. Um grupo dedicado facilita identificação e remoção posterior, mas não justifica incluir recursos de rede partilhados.
Selecionar a região compatível com o VNet pretendido. Definir Vm Name e Vm Size; a Sophos recomenda Standard_D4s_v3 no guia atual.
Identificar exatamente grupo do VNet, Azure Virtual Network e Azure Virtual Network Subnet. Introduzir um Static Private IP livre e adequado ou deixar vazio para atribuição automática.
Manter os valores gerados de Utc Now e Random Seed. Servem para nomes de deployment únicos e password temporária durante implementação, respetivamente.
Rever regras NSG geradas: documentam-se entrada UDP/514 e TCP/601 do VNet e a saída necessária XDR, DNS e NTP. Considerar no template outros requisitos próprios de rede e segurança.
Rever condições Marketplace e só iniciar com Purchase após aprovação dos recursos. Comparar o resultado Azure com estado no Sophos Fusion.

Num template personalizado, manter o disco adicional com pelo menos 200 GB em /dev/sdc. Azure também não suporta HA neste desenho; um eventual VM Scale Set personalizado só pode executar uma instância com essa Custom Data. Uma VM collector funcional não ativa por si uma integração de auditoria Microsoft 365; configurar e validar essa origem separadamente.

GCP: Infrastructure Manager e Service Account próprio

GCP requer projeto autorizado, Infrastructure Manager API ativada, Cloud Shell ou gcloud CLI já disponível e user-managed Service Account. A conta gerida pela Google <numeric ID>@cloudservices.gserviceaccount.com não é adequada segundo a Sophos.

O administrador de implementação cria a conta, por exemplo infra-manager-sa, com roles/compute.instanceAdmin.v1, roles/compute.securityAdmin e roles/config.agent no projeto de destino. Permitem criar instâncias/discos, gerir regras firewall e trabalhar com Infrastructure Manager. A aprovação destas permissões de escrita é uma preparação separada; uma revisão de leitura do collector não necessita delas.

Gerar e aplicar a configuração GCP

Escolher Google Cloud Platform (GCP) no diálogo Sophos e introduzir GCP Project ID.
Em Service Agent ID, associar a user-managed Service Account prevista. Apesar do nome do campo, não usar o Google-managed Service Agent.
Verificar GCP Region, GCP Zone, Network Name, Subnet Name e Network CIDR. O CIDR deve corresponder às regras pretendidas; não introduzir uma abertura geral à Internet.
Guardar o arquivo Terraform gerado com Download. Abrir Cloud Shell na consola do projeto correto, carregar o ZIP específico e extrair para diretório próprio. O nome selecionado deve corresponder ao collector acabado de gerar.

unzip collector-*.zip -d collector-infrastructure

O exemplo do fabricante usa um wildcard. O diretório de trabalho deve conter exatamente o arquivo pretendido; se vários ficheiros corresponderem, usar o nome exato. Rever os ficheiros Terraform quanto a recursos, redes, regras firewall e identidade antes de aplicar. A configuração cria instância Compute com interface de rede e disco de dados de pelo menos 200 GB em /dev/sdb.

A Sophos documenta o comando seguinte:

gcloud infra-manager deployments apply \
  projects/PROJECT_ID/locations/LOCATION/deployments/taegis-collector \
  --service-account projects/PROJECT_ID/serviceAccounts/infra-manager-sa@PROJECT_ID.iam.gserviceaccount.com \
  --local-source="./collector-infrastructure" \
  --tf-version-constraint="1.5.7"

Substituir PROJECT_ID em todos os pontos pelo projeto autorizado e LOCATION por uma localização suportada de Infrastructure Manager. O nome da Service Account deve corresponder à conta efetivamente criada. taegis-collector identifica o recurso de deployment e não pode sobrescrever inadvertidamente outro existente. apply cria ou altera recursos cloud reais; só executar após revisão e aprovação.

A Sophos indica gcloud infra-manager previews create como opção prévia de preview. Também as previews devem correr no projeto correto com conta autorizada e não substituem a revisão das alterações. Após Apply bem-sucedido, verificar estado e origens. Segundo o guia, Provisioning deve terminar em até dez minutos; caso contrário, investigar erros de implementação e ligação, sem criar repetidamente o mesmo deployment de forma descontrolada.

Shared VPC: separar projeto de rede e de serviço

Por predefinição, o template espera rede e instância no mesmo projeto. Em Shared VPC, o Host Project possui VPC, subnets e regras firewall; o Service Project contém instância collector e disco. Ambos devem existir antecipadamente.

O administrador da organização ativa Shared VPC no projeto host e associa o projeto de serviço. É necessário roles/compute.xpnAdmin a nível da organização, não uma função normal de projeto. Depois atribui à infra-manager-sa do projeto de serviço, no projeto host, roles/compute.securityAdmin para regras firewall e roles/compute.networkUser para utilização da rede.

No assistente Sophos, preencher Network Project ID com o ID do projeto host; manter as restantes referências no projeto de serviço. PROJECT_ID no destino Apply e no endereço da Service Account continua a ser o ID do projeto de serviço. Reler separadamente esta associação antes de aprovar: substituir todos os placeholders pelo projeto host quebraria a separação prevista.

Validar origens e preservar configuração persistente

Depois de implementar, o collector deve estar acessível no Sophos Fusion. Fazer então uma origem piloto limitada enviar no formato syslog adequado ao destino cloud correto. Comparar origem, hora, tipo de evento e campos esperados na pesquisa XDR. Um collector saudável ou stack cloud bem-sucedido não prova ingestão e normalização completas.

O runbook operacional explica vistas de origem, backlog e Admiral. Só migrar outras origens após aceitar o piloto; preservar caminhos anteriores até à aceitação acordada. Um collector não substitui nem entitlement SIEM e inventário de retenção, nem uma integração API específica.

Se a configuração mudar depois no Sophos Fusion, guardar novos ficheiros e atualizar também a implementação cloud existente: stack CloudFormation AWS com template atual, deployment Azure com ARM atual, deployment GCP com nova configuração Terraform. Caso contrário, uma futura substituição da instância pode reutilizar valores bootstrap antigos. Uma alteração online bem-sucedida não comprova essa persistência.

Para reverter, devolver primeiro as origens ao caminho anterior preservado e confirmar eventos recentes nesse destino. Depois remover apenas recursos claramente atribuídos ao collector pelo processo de alteração cloud aplicável. VPCs/VNets, subnets, chaves ou Service Accounts partilhadas não são eliminados como «limpeza do collector» geral. Uma reversão de infraestrutura não recupera automaticamente eventos históricos perdidos ou mal normalizados.