Implementar o Sophos NDR na AWS

O Sophos NDR é executado na AWS como um appliance de integração baseado em EC2. Recebe uma cópia do tráfego da VPC selecionado através do VPC Traffic Mirroring, analisa-a passivamente e envia dados NDR para o Sophos Data Lake. O appliance não fica inline nem substitui Security Groups ou uma firewall.

O fluxo de trabalho resumido e fiável é o seguinte: clarificar a licença e as responsabilidades, registar as redes AWS, criar o appliance no Sophos Fusion, transferir o template do CloudFormation gerado, subscrever a oferta do Marketplace, criar a stack, adicionar exatamente uma Mirror Session controlada, restringir o acesso de gestão e validar cada camada individualmente.

⚠️ Este runbook não inclui deliberadamente um procedimento completo de desativação. A sequência segura e as consequências da eliminação da stack, do appliance e dos recursos EC2, EBS, ENI, Security Group, Elastic IP, Mirror e Marketplace não estão totalmente verificadas. Por conseguinte, uma implementação falhada não deve ser «limpa» com uma sequência de eliminação improvisada.

Arquitetura e decisões antes de começar

O CloudFormation cria dois caminhos de rede logicamente separados:

A Management Interface encontra-se numa Public Subnet e utiliza um Elastic IP Address atribuído. É através dela que são efetuados o SSH e o acesso ao Sophos Appliance Manager.
A SPAN interface recebe o tráfego espelhado. O NDR SPAN Target criado pelo template é utilizado como Mirror Target.
Uma Traffic mirror session liga uma ENI de origem selecionada a este Target. O NDR Traffic Mirror Filter, também criado, determina quais os pacotes que são espelhados.
O appliance processa as cópias e envia os dados NDR para a Sophos. Os fluxos originais permanecem no respetivo caminho de dados AWS normal.

Assim, a decisão de conceção mais importante não é «que VPC inteira devemos monitorizar?», mas sim que ENI constitui uma Mirror Source adequada. Comece com uma única ENI documentada de um sistema de teste. Isto mantém o volume de dados, os custos e o âmbito de falha reduzidos. Só devem ser adicionadas outras origens após a validação técnica.

Antes da implementação, o plano de construção deve incluir, no mínimo:

conta AWS, Region, VPC, Availability Zone e tags de Owner;
ID da VPC e ID das sub-redes de gestão e SPAN;
pelo menos um Elastic IP atribuído na conta AWS para a Management Interface; trata-se de um pré-requisito da conta, mas, na lista de parâmetros documentada, não é um input do template que possa ser selecionado antecipadamente;
tipos de EC2 atualmente suportados pela Sophos: c5n.2xlarge, c6i.4xlarge ou c7i.16xlarge, com virtualização Nitro; o tipo efetivamente utilizado deve ser verificado no template atual do tenant e, após a implementação, na instância;
nome do SSH Key Pair existente e local seguro de armazenamento da Private Key;
Security Group para SSH e redes de origem administrativas fixas;
primeira ENI que será a Mirror Source e a equipa responsável pelo workload correspondente;
tráfego de teste normal esperado para esta ENI;
centro de custos, alerta de orçamento e aprovação para os custos da infraestrutura AWS, bem como as condições do Marketplace apresentadas para esta conta.

VPC, Subnets e Elastic IP

Podem ser utilizadas uma VPC e Subnets existentes. No entanto, a seleção não deve basear-se apenas no nome:

A sub-rede de gestão deve ser planeada como uma Public Subnet. Antes de a selecionar, verifique a respetiva Route Table e o caminho previsto para a Internet.
A sub-rede SPAN é especificada para a NDR SPAN interface. Registe a Subnet e a Availability Zone juntamente com a Mirror Source, em vez de tentar deduzir estes valores mais tarde a partir dos nomes dos recursos.
O Elastic IP deve ser associado à Management Interface, e não ao lado SPAN. Certifique-se antecipadamente de que existe pelo menos um Elastic IP atribuído na conta. Não afirme que a stack utiliza um endereço existente específico: após CREATE_COMPLETE, determine e registe o endereço efetivamente criado ou utilizado e a respetiva associação à ENI.
O template seleciona automaticamente a AMI e a Region com base na Region da AWS para a qual o template é carregado. Não force outra AMI através de uma alteração manual do template.

Security Groups e SSH Key Pair

Utilize um AWS Key Pair existente cuja Private Key já esteja armazenada em segurança. O CloudFormation necessita do nome do Key Pair; a Private Key não é guardada no Sophos Fusion nem no template. Sem a Private Key, o acesso SSH documentado pela Sophos para o appliance AWS não estará disponível mais tarde.

Prepare um Security Group que permita SSH apenas a partir da rede de acesso administrativo, por exemplo, a partir de um IP fixo de saída da empresa como /32 ou através de um Jump Host controlado. Não abra SSH nem TCP 8443 a 0.0.0.0/0.

O template também cria o InternalMgmtSG. Após a implementação, permita aí TCP 8443 apenas para as origens administrativas efetivas. Se o mesmo appliance alojar adicionalmente um Log Collector, permita Syslog exclusivamente com o protocolo e a porta exigidos pelo conector correspondente e a partir das redes de origem internas. O próprio VPC Traffic Mirroring não necessita de uma permissão geral de Syslog a partir da Internet.

Verificar antecipadamente a ligação de saída

Uma Public Subnet e um Elastic IP não comprovam, por si só, a existência de um caminho de saída funcional. Antes de selecionar Submit, a equipa de rede responsável tem de confirmar que a Management Interface consegue comunicar para o exterior através da rota prevista e de um Internet Gateway ou do desenho de saída central aprovado. Para isso, verifique a resolução de DNS, a Route Table, a Network ACL, a saída do Security Group e as regras do proxy e da firewall a montante.

Os destinos e as portas necessários não são copiados para este runbook. Em vez disso, no momento da alteração, compare as exclusões atuais de portas e domínios para appliances Sophos com o conjunto de regras de saída. Estas permissões são relevantes para o arranque, as atualizações, o registo e o carregamento de dados; a prova de ligação a um único destino não substitui a comparação completa.

Pré-requisitos, funções, licença e custos

Para a configuração, são necessários:

uma conta AWS com VPC, Subnets e Availability Zones existentes;
uma conta Sophos Fusion;
regra geral, o Sophos Network Detection and Response integration license pack;
pelo menos uma instância EC2 de origem adequada ou a respetiva ENI;
pelo menos um Elastic IP Address atribuído na conta AWS;
um AWS SSH Key Pair guardado;
uma aprovação de alteração atual para o espelhamento de rede e para os dados processados nesse âmbito.

Sempre que possível, distribua o trabalho sem inventar nomes de IAM Policy não confirmados:

Um administrador do Sophos Fusion cria a configuração NDR e transfere o template.
Uma pessoa autorizada para aquisições aceita as condições do Sophos Integration Appliance no AWS Marketplace.
Um administrador AWS com as permissões necessárias para a stack e para os recursos de rede referenciados cria os recursos CloudFormation, EC2, VPC Traffic Mirroring, Security Group e Elastic IP.
A equipa de rede ou de workload responsável confirma a Mirror Source, o efeito do filtro, a janela de teste e o tráfego esperado.

A Sophos não especifica uma função mínima separada do Fusion, específica do NDR, para este procedimento. Por isso, se Add Configuration, Download image ou Open Appliance Manager não estiver visível, não faça suposições: um Super Admin deve verificar as permissões efetivas do tenant e a licença.

A única exceção considerada aqui é estritamente limitada: para clientes MSP Flex com uma licença XDR, a Sophos documenta que o Sophos NDR pode ser integrado sem um Integration License Pack adicional. Isto não implica que todas as subscrições XDR ou MDR incluam NDR, nem que a exceção se aplique a licenças a termo. Por conseguinte, confirme a autorização específica do tenant/SKU no Fusion e, em caso de dúvida, junto da Sophos ou do parceiro responsável pela aquisição, com base nas regras atuais de licenciamento de integrações Sophos.

O CloudFormation cria recursos AWS que implicam custos. O appliance virtual está incluído no entitlement aplicável do Sophos NDR; daí não se deduz aqui um preço de tabela público nem qualquer afirmação sobre a oferta concreta do Marketplace da conta. Antes de selecionar Submit, verifique as condições do Marketplace apresentadas nesse momento. Estime separadamente as categorias AWS de EC2, armazenamento, endereço IPv4 público/Elastic IP, transferência de dados e VPC Traffic Mirroring. Este runbook não indica deliberadamente montantes fixos: a Region, a duração, o volume de dados e o modelo de preços da AWS alteram o cálculo. As tags e um alerta de orçamento devem constar da alteração antes do espelhamento em produção.

1. Criar o appliance e o template do CloudFormation no Sophos Fusion

No Sophos Fusion, abra Threat Analysis Center > Integrations > Marketplace.
Abra Sophos Network Detection and Response (NDR).
Em Data Ingest (Security Alerts), clique em Add Configuration.
Em Step 1, introduza um nome exclusivo e uma descrição, por exemplo, ndr-aws-prod-eu1 e NDR Sensor für AWS Produktions-VPC eu1.
Em Step 2, em Virtual platform, selecione AWS.
Clique em Save. A Sophos gera o ficheiro do CloudFormation aws_ndr_cf_latest.json.
Abra Threat Analysis Center > Integrations > Configured e, em seguida, o separador Integration Appliances.
Localize o appliance que acabou de criar. Na coluna da direita, abra o menu de três pontos, selecione Download image e guarde aws_ndr_cf_latest.json na pasta protegida da alteração.

O JSON provém do próprio tenant do Fusion e do appliance que acabou de ser criado. Não utilize um ficheiro antigo de outro tenant ou de outra alteração. Não modifique manualmente o template para forçar tipos de instância, AMIs ou variantes de rede não suportados.

2. Subscrever a oferta do Marketplace

No AWS Marketplace, procure Sophos Integration Appliance.
Na página Product Overview, clique em Continue to Subscribe.
Em Subscribe to this software, verifique as condições e aceite-as apenas com a aprovação de aquisição prevista. Em seguida, clique em Continue to Configuration.
Em Configure this software, verifique a versão e a Region. Estas devem corresponder ao plano de construção. Clique em Continue to Launch.
Em Launch this software, abra primeiro Usage instructions e documente as instruções de acesso apresentadas.
Clique em Launch. A AWS abre Create stack.

A subscrição do Marketplace é um pré-requisito para que a AWS aceite o software referenciado no template. Por isso, se uma AMI não estiver disponível ou ocorrer um erro de entitlement, comece a resolução de problemas pela subscrição, pela Region e pela versão, e não por alterações ao JSON.

3. Criar a stack do CloudFormation

Antes de preencher os dados, abra os parâmetros do template gerado recentemente a partir deste tenant. Caso este disponibilize um parâmetro documentado para o tipo de instância EC2, selecione aí exclusivamente um tipo atualmente suportado pela Sophos e registe o nome e o valor do parâmetro. Se não disponibilizar tal parâmetro, o template seleciona o tipo; não edite o JSON manualmente. Em ambos os casos, o tipo de EC2 efetivamente iniciado é verificado após a criação.

Em Create stack, mantenha a opção Template is ready selecionada.
Em Specify template, selecione a opção Upload a template file.
Clique em Choose file, selecione o ficheiro aws_ndr_cf_latest.json que acabou de ser gerado e, em seguida, clique em Next.
Em Specify stack details, atribua um Stack name exclusivo, por exemplo, sophos-ndr-prod-eu1.
Em Network Configuration, introduza:
- a VPC existente planeada;
- a Public Subnet para a NDR Management Interface;
- a Subnet para a NDR SPAN interface;
- o Security Group preparado para o acesso SSH administrativo.
Em EC2 Instance Configuration, selecione o SSH Key Pair existente. Volte a confirmar que a Private Key está acessível e protegida.
Clique em Next. Em Configure stack options, verifique as tags e as restantes opções da AWS. Não aceite os Defaults sem os analisar; compare-os com a alteração.
Verifique o resumo e clique em Submit.
Aguarde por CREATE_COMPLETE. A Sophos indica que isto demora normalmente entre cinco e seis minutos; os eventos do CloudFormation são a referência, e não esta estimativa de tempo.

Antes da Mirror Session, na stack ou nos recursos AWS associados devem ser localizáveis, no mínimo, o appliance Sophos esperado, o respetivo tipo de EC2 efetivo, as ENI de gestão e SPAN, o NDR SPAN Target, o NDR Traffic Mirror Filter, o InternalMgmtSG, bem como o Elastic IP efetivamente utilizado e a respetiva associação. Se faltar algum elemento ou a stack não terminar com CREATE_COMPLETE, não crie uma Mirror Session.

4. Criar uma Traffic Mirror Session

Nem todas as ENI ou topologias EC2 são automaticamente adequadas como Mirror Source. Antes da criação, consulte na documentação atual da AWS os tipos de instância de origem suportados, bem como os pré-requisitos e as limitações do Mirror Target, e verifique a topologia concreta de Source/Target, Region e Availability Zone. Além disso, verifique em Service Quotas e nas quotas da AWS para Traffic Mirroring se existe quota suficiente para a Source, as Sessions, os Targets e os filtros. Esta verificação da AWS constitui um ponto de aprovação independente; a lista da Sophos de tipos de appliance suportados não confirma a capacidade de Mirroring de qualquer ENI de workload.

Abra VPC > Traffic mirror sessions > Create traffic mirror session e preencha deliberadamente os campos:

Name Tag: um nome descritivo, por exemplo, ndr-prod-app01;
Description: a finalidade e a referência da alteração, por exemplo, Mirror app01 ENI to Sophos NDR - CHG-1234;
Mirror Source: a ENI do sistema de teste aprovado, e não apenas uma instância EC2 com um nome semelhante;
Mirror Target: o NDR SPAN Target criado pela stack;
Session number: um número adequado para esta Source. A AWS utiliza-o para definir a ordem quando a mesma Source tem várias Sessions. Inventarie as Sessions existentes antes de o selecionar;
VNI: 1;
Filter: o NDR Traffic Mirror Filter criado pela stack.

Só deve clicar em Create depois de uma verificação por duas pessoas da Source, do Target, do Session number, do VNI e do filtro. VNI = 1 e a seleção do filtro gerado são requisitos do produto. Por outro lado, a Source, o nome, a descrição e o Session number têm de corresponder ao ambiente AWS em causa.

No primeiro teste, não crie outras origens «por precaução». Uma Mirror Session adicional aumenta o volume de dados, os custos e o âmbito da investigação, pelo que necessita de uma aprovação técnica própria.

5. Configurar o acesso de gestão e as credenciais

Na AWS Console, procure o nome do appliance, selecione o separador EC2 e abra a instância Sophos Appliance.
Em Instance Summary, abra o separador Security e, em seguida, InternalMgmtSG.
Em Inbound rules, adicione TCP 8443 apenas para os CIDR administrativos aprovados. Documente o ID da regra, a origem e a referência da alteração.
No Sophos Fusion, abra Threat Analysis Center > Integrations > Configured > Integration Appliances.
No appliance, abra o menu de três pontos e selecione Open Appliance Manager.
Na caixa de diálogo de confirmação, clique em reset it para definir a palavra-passe.
Inicie sessão com o nome de utilizador fixo zadmin e a palavra-passe definida.

Trate a palavra-passe zadmin como um segredo privilegiado. Guarde-a no cofre de palavras-passe aprovado, e não no template do CloudFormation, num ticket ou numa captura de ecrã. Todos os administradores utilizam a mesma palavra-passe do Appliance Manager. Se for perdida, deve ser novamente definida através de Open Appliance Manager > reset it.

Validação da implementação e do registo inicial

Um estado de EC2 em execução não comprova, por si só, o caminho de espelhamento nem o registo. Verifique pela seguinte ordem:

CloudFormation: a stack apresenta CREATE_COMPLETE; os recursos esperados estão presentes e não existem eventos ignorados ou falhados.
Associação de rede: a VPC, a Management Subnet, a SPAN Subnet, o Elastic IP, ambas as ENI e o SSH Key Pair correspondem ao plano de construção.
Exposição: o SSH e o TCP 8443 só estão acessíveis a partir das redes administrativas aprovadas. Não existe nenhuma nova regra de gestão com 0.0.0.0/0.
Configuração de Mirror: a Session referencia exatamente a ENI de Source aprovada, o NDR SPAN Target, VNI 1 e o NDR Traffic Mirror Filter. O Session number e quaisquer Sessions paralelas existentes estão documentados.
Ligação à Sophos: o appliance está visível em Integration Appliances; o respetivo estado NDR no Sophos Fusion está verde, Open Appliance Manager abre o destino esperado e o início de sessão como zadmin funciona.
Caminho de dados preliminar: durante a janela de teste aprovada, gere tráfego normal e inofensivo na ENI que constitui a Mirror Source. No separador NDR do Appliance Manager, verifique a percentagem de carregamento, a percentagem de captura da porta SPAN configurada e o gráfico Total flows. Registe a hora da medição e os valores. Não é necessária uma Detection para este teste de infraestrutura.
Controlo negativo: uma origem administrativa não aprovada não deve conseguir aceder a TCP 8443. Este controlo comprova a restrição da gestão, e não a deteção NDR.

Registe o ID da stack, o nome do appliance, o ID e o tipo da instância, as ENI de gestão e SPAN, a associação efetiva do EIP, o ID da Mirror Session, a ENI de Source, o Target, o filtro, o VNI, os ID das regras do Security Group, as métricas NDR e a janela de validação. Os segredos não devem ser incluídos neste registo. Esta validação confirma apenas a implementação e o registo inicial. Em seguida, verifique integralmente o caminho de dados espelhado com Configurar e validar o Traffic Mirroring para o Sophos NDR e efetue depois um teste seguro de deteção de extremo a extremo. Nem o início de sessão nem o tráfego de teste normal comprovam, isoladamente, o funcionamento da cadeia de deteção.

Resolução de problemas por sintoma

A stack não termina com `CREATE_COMPLETE`

Abra primeiro o separador Events da stack e comece pelo primeiro evento falhado, em vez de trabalhar retrospetivamente a partir da última mensagem de erro subsequente.

Em caso de erros de entitlement do Marketplace ou da AMI: verifique a subscrição, as condições aceites, a versão e a Region.
Em caso de erros de permissão: peça ao administrador AWS que verifique a ação e o recurso indicados no evento concreto. Não atribua uma Policy de administrador geral como solução rápida.
Em caso de parâmetros de rede: compare os ID da VPC e das Subnets, o Elastic IP atribuído ou a quota de EIP disponível, o Security Group e o SSH Key Pair com o plano de construção.
Em caso de erros de capacidade ou de quota: verifique o tipo de instância suportado selecionado e a mensagem de erro concreta da AWS. Não mude para um tipo que não seja disponibilizado pelo template.

Enquanto a stack estiver incompleta, não crie uma Mirror Session nem Inbound Rules adicionais.

O appliance está em execução, mas não recebe tráfego espelhado

Verifique a cadeia pela seguinte ordem:

A Mirror Source é realmente a ENI através da qual passa o tráfego de teste?
O Mirror Target é o NDR SPAN Target desta stack, e não um Target de outro ambiente com um nome semelhante?
O VNI está definido como 1?
O NDR Traffic Mirror Filter está selecionado?
O Session number entra em conflito com a ordem de avaliação pretendida de outras Sessions da mesma Source?
Foi realmente gerado tráfego através desta ENI durante a janela documentada?

Altere apenas uma destas variáveis de cada vez e, em seguida, repita o mesmo teste. Uma seleção mais abrangente do filtro ou da Source não substitui a análise da causa.

Não é possível criar a Mirror Session

Leia primeiro a mensagem de erro concreta da API/consola da AWS e não altere simultaneamente a Source, o Target e o filtro.
Volte a comparar a ENI de Source e o respetivo tipo de instância EC2 com os pré-requisitos e as limitações atuais da AWS para Traffic Mirroring.
Compare a topologia de Source/Target e a seleção de Region/Availability Zone com a documentação atual da AWS.
Verifique as quotas de Traffic Mirroring afetadas em Service Quotas. Solicite um aumento ou altere o desenho através do processo de alteração normal da AWS, em vez de eliminar Sessions existentes sem as verificar.

O registo ou o carregamento NDR falha

Verifique primeiro o caminho definido em Verificar antecipadamente a ligação de saída. Em particular, a configuração de DNS, Route Table, Internet Gateway ou desenho de saída aprovado, Network ACL, saída do Security Group, proxy e firewall a montante tem de ser coerente. Volte a comparar as regras com as exclusões atuais de portas e domínios da Sophos. Segundo a Sophos, um erro no carregamento através de um URL S3 pré-assinado indica frequentemente tráfego de saída para a Internet bloqueado no proxy ou na firewall. Não amplie genericamente a saída; documente o destino concreto bloqueado e peça autorização apenas para a exceção atualmente exigida pela Sophos.

O Appliance Manager não está acessível através de TCP 8443

Verifique se o InternalMgmtSG permite o atual endereço público da origem administrativa.
Verifique a associação do Elastic IP à Management Interface e a Public Subnet selecionada.
Certifique-se de que Open Appliance Manager abre o appliance esperado.
Se uma regra tiver sido temporariamente ampliada para 0.0.0.0/0, volte a restringi-la imediatamente; uma permissão ampla não é um passo de diagnóstico.

Só deve investigar um problema de palavra-passe depois de o caminho de rede estar funcional.

O início de sessão de `zadmin` falha ou o Appliance Manager está bloqueado

Se a palavra-passe for desconhecida, utilize Open Appliance Manager > reset it no Sophos Fusion. Se o appliance apresentar explicitamente uma mensagem de bloqueio, a Sophos documenta a seguinte intervenção através de SSH para a AWS:

redis-cli --no-auth-warning -h redis-master.default.svc.cluster.local -p 6379 -a $(jq -r .RedisPassword /etc/dragonfly/sensorapi_config.json) SET userlockout '{"attempt":0,"locked":false}'

O comando é executado exclusivamente na sessão SSH da instância EC2 do Sophos NDR afetada, utilizando a Private Key selecionada durante a implementação. Este runbook não indica deliberadamente um nome de utilizador do sistema operativo nem a sintaxe SSH completa, porque a página da Sophos que foi verificada não os documenta. Consulte a identidade de ligação atual nas Usage instructions da oferta subscrita no Marketplace ou esclareça-a junto do Sophos Support; não a tente adivinhar. Antes de estabelecer a ligação, compare o endereço de destino, o ID da instância e a impressão digital do anfitrião com o inventário AWS. O comando altera o estado de bloqueio, mas não define uma nova palavra-passe. Utilize-o apenas quando o bloqueio for explicitamente visível, e não como correção geral do início de sessão. Em seguida, teste o início de sessão com a palavra-passe existente; se não funcionar, volte depois a defini-la no Sophos Fusion. O comando e o resultado devem ser incluídos no registo da alteração, sem a palavra-passe ou a Private Key.

Reversão limitada em vez de uma desativação não confirmada

Antes de qualquer alteração manual do Security Group, exporte o estado inicial ou documente-o com os ID das regras. Se a nova regra TCP 8443 ou Syslog causar um problema, apenas essa regra adicionada manualmente pode ser removida e o estado inicial documentado pode ser verificado. Esta é uma reversão restrita para a própria alteração de Inbound, e não uma desativação do appliance NDR.

Não é deliberadamente indicada aqui uma sequência completa de eliminação para a stack, a subscrição do Marketplace, o objeto do appliance, EC2/EBS, ENI, Elastic IP, Traffic Mirror Session, Target, filtro e Security Groups. Do mesmo modo, não se afirma que a eliminação da stack do CloudFormation resolve todos os recursos, custos, objetos Sophos ou consequências para os dados associados. Até estas dependências serem verificadas com documentação atual do fabricante e através de um teste, os recursos só devem ser removidos através de uma alteração de desativação verificada separadamente.