Configurar integrações MDR e XDR no Sophos Fusion

Com as integrações, o Sophos Fusion (anteriormente Sophos Central) reúne telemetria de produtos Sophos e de terceiros no Sophos Data Lake ou disponibiliza Response Actions específicas. É essencial escolher o tipo de integração correto: Data Ingest fornece dados para consultas, Detections e investigações; Response Action executa uma ação no produto ligado. Nem todos os produtos suportam ambas as direções.

O ponto de entrada depende da versão do produto no tenant. Para a solução XDR/MDR ampliada, utiliza-se Security Operations > Integrations > Marketplace; as configurações Classic existentes encontram-se em Threat Analysis Center > Integrations. As instruções TAC mantidas abaixo descrevem esse percurso Classic e não uma sequência de cliques idêntica para a nova interface. A verificação do upgrade de cada tenant ajuda a identificar o percurso adequado. Os nomes Fusion visíveis, por si só, não comprovam que o upgrade do produto terminou.

No percurso de onboarding do Endpoint, este artigo encerra a fase de integração entre produtos, situada entre a configuração da proteção e a aceitação operacional.

O processo prático consiste em verificar a licença e o sistema de origem, escolher no Marketplace o bloco do produto e a configuração adequados, estabelecer a ligação com o mínimo de permissões possível, verificá-la em Configured e validá-la com um evento de teste esperado. Só depois disso a integração deve ser considerada operacional em produção.

Verificar separadamente ligação e fluxo real de dados

Na interface atual abrir Security Operations > Integrations > Configured Integrations. Em Data Ingest, o estado mostra configuração e ligação da integração API, syslog ou Sophos. Verde confirma comunicação, não eventos já normalizados corretamente. Pode surgir aviso após 20 minutos sem comunicação ou quando alguns recursos não reportam; erro após 60 minutos ou falha de autenticação. O texto ao passar o cursor indica a causa concreta.

Numa integração API abrir o nome e API Query Logs. O período predefinido é o último dia; podem selecionar-se até sete dias. Em Details, comparar parâmetros com o tenant de origem correto. Integrações hierárquicas podem ter um parent com vários endpoints child; um caminho parcial saudável não comprova todos os children.

Verificar depois Security Operations > Integrations > Configured Data Sources. Esta vista distinta mostra se os logs chegam e a que esquemas são associados. Healthy significa atividade na última hora, Warning entre uma e 24 horas e Unhealthy mais de 24 horas sem atividade. São critérios diferentes dos limiares de ligação acima. Avaliar uma fonte que envia raramente segundo a atividade esperada, não declará-la saudável com um evento de teste inventado.

Clicar na fonte mostra o histórico de mensagens por esquema nas últimas 24 horas. Para aceitação gerar um evento autorizado no sistema de origem e comparar hora, fonte, campos obrigatórios e esquema normalizado. Advanced Search nos detalhes abre uma pesquisa preparada pelo ID do sensor nas últimas 24 horas. O guia de pesquisa explica filtros adicionais. Se faltarem dados, verificar primeiro fonte → integração/collector → esquema; um evento de auditoria normal não tem necessariamente de gerar uma detection.

Export All as CSV ou Export Selected as CSV guarda o inventário das fontes através de Data Exports. O ícone do lixo remove apenas o registo da fonte, não a telemetria já recebida. A eliminação não pode ser anulada; uma fonte que continue a enviar reaparece e a remoção pode demorar cinco minutos. Eliminar não confirma a remoção de telemetria e não é um teste de reparação.

Visibilidade, permissões e allowlist API atual

Consoante o produto, Marketplace mostra cartões Ingest e Actions separados. EDR sem XDR não mostra cartões Ingest que não sejam de endpoints; response actions podem continuar visíveis. Admin e Super Admin podem gerir integrações. Help Desk e Read-only veem apenas configuração e estado. Nas Custom Roles atribuir Integration: read e apenas os direitos necessários create, update, delete e download. Verificar licença e função antes de ampliar permissões por falta de uma funcionalidade.

Distinguir a allowlist XDR atual do snapshot IP Classic conservado abaixo e do uplink do collector. Determinar a região geográfica XDR real em Profile icon > Support settings, sem a deduzir de um nome de produto. A lista do fabricante de 25 de setembro de 2026 indica estas redes para chamadas administrativas/API ao terceiro:

Autorizar só a rede da integração real, após aprovação da alteração. A lista não demonstra disponibilidade de todos os produtos em todas as regiões nem substitui a verificação dos destinos API atualmente necessários. O caminho mTLS de saída do collector utiliza outros destinos.

Direcionar precisamente as notificações Health

As regras abaixo para 24 horas de erro contínuo, reposição do contador e repetição de 30 em 30 dias aplicam-se também à ajuda Fusion atual de 20 de outubro de 2026. O e-mail não é um alarme imediato após os 20 ou 60 minutos referidos acima.

Abrir uma regra própria de destinatários em General Settings > Platform > Notification Settings > Configure email alerts > Custom rules > + Create new rule. Após função, administradores/listas de distribuição e âmbito de dispositivos, selecionar em Alert Types os filtros Medium alert, produto Sophos Central e categoria Central Integrations Alert. Definir nome/descrição e guardar. Planear antes o envio dos outros alertas: a primeira regra própria desativa o envio predefinido de todos os e-mails de alerta a todos os administradores. Preservar os restantes destinatários necessários com regras adicionais adequadas; não provocar falha de teste num connector de produção apenas para forçar um e-mail.

Passos seguintes por fonte

Para fontes próprias, HTTP Ingest, S3 e Azure explicam os transportes distintos. A operação do collector e o deployment cloud complementam o runbook de migração existente. Cloud Flow Logs, telemetria de rede e Windows Event Logs tratam formatos de origem e limites de licença por esquema. Nem toda a telemetria de um fabricante é automaticamente uma fonte exclusiva de SIEM.

Após o upgrade: voltar a colocar as Response Actions em funcionamento

Estado verificado em 11 de outubro de 2026: a solução ampliada utiliza um modelo diferente de execução e permissões para Actions. As ligações TAC existentes e as respetivas credenciais não são simplesmente transferidas. Antes de alterar algo, documente os tenants Microsoft afetados, as ligações, as ações ativadas e os responsáveis. A ingestão bem-sucedida de dados por um conector de auditoria ou Graph separado não é um teste de resposta.

Voltar a ligar o Microsoft 365 ou a autorizar as credenciais

Estes passos exigem Admin ou Super Admin no Sophos Fusion e um Microsoft 365 administrator do lado da Microsoft. Em cada diálogo de consentimento, verifique as permissões efetivamente solicitadas e o tenant Microsoft correto; não reutilize sem análise o conjunto de permissões de uma antiga aplicação TAC.

Se a ligação TAC anterior ainda não estiver configurada na nova interface, crie-a assim:

1. Abra Security Operations > Integrations > Marketplace e o mosaico Actions Microsoft Graph API.
2. Selecione Add new connection. Em Add a Connection, selecione novamente Add new connection, preencha Name e, se necessário, Description e Tags, e continue com Done.
3. Inicie a autorização guiada da Microsoft com Proceed. Um nome como M365-Response-Produktiv é apenas uma identificação de livre escolha; o que importa é o tenant de origem correto e as permissões aprovadas.
4. Em Pick an account, selecione a conta administrativa prevista. O primeiro pedido Permissions requested autoriza a aplicação principal da Sophos. Após regressar à Sophos, segue-se um segundo passo Microsoft para a ligação de resposta propriamente dita. Depois de verificar as permissões, conclua ambos os diálogos com Accept. Se cancelar um deles, a ligação não é criada.
5. Ao regressar, verifique as ações disponíveis e guarde apenas o âmbito aprovado com Save. A nova ligação tem de aparecer em Configured Integrations.
6. No Microsoft Entra, em Manage > All applications, utilize Refresh para confirmar que a nova aplicação de resposta aparece ativada.

Se já existir uma ligação em Microsoft Graph API > Configured Integrations, abra o menu de três pontos junto do nome da ligação e Edit Connection. Selecione Re-Authorize Credentials e percorra a autorização Microsoft. O botão só aparece quando é necessária uma nova autorização e desaparece depois de esta terminar. Repita para cada ligação afetada; reparar uma só ligação não basta para todos os tenants ou configurações.

As instruções atualizadas de 7 de outubro de 2026 distinguem expressamente a continuidade da proteção de eventuais falhas das ações de resposta Microsoft até à nova autorização. Indicam 1 de outubro de 2027 como limite de validade das credenciais anteriores. Se precisar de Actions, não espere por esse limite: é necessário comprovar o funcionamento agora.

A aceitação inclui a aplicação Entra correta, as ligações esperadas, as ações ativadas e um teste aprovado com uma conta dedicada. Utilize apenas uma alteração reversível documentada para a ação atual. O par Classic Block user sign-in / Allow user sign-in descrito abaixo não prova que todas as novas Actions tenham os mesmos nomes ou o mesmo caminho de reversão. As sessões revogadas não podem ser restauradas. Nos detalhes da Action, View Executions > History apresenta o histórico; verifique também o estado real na Microsoft. Um consentimento ou um registo de execução bem-sucedido não substitui esta confirmação.

Adicionar Sophos Firewall (Actions) apenas se a ligação estiver em falta

Após o upgrade do produto, abra primeiro um Case e verifique se as ações Sophos Firewall estão disponíveis. Se estiverem, não é necessária uma nova ligação. Se faltarem:

1. Abra Security Operations > Integrations > Marketplace.
2. Procure e abra Sophos Firewall (Actions).
3. Selecione Add new connection e guarde com Save.

Esta ligação não exige credenciais. Depois, os Cases disponibilizam ações de resposta da firewall, como bloquear endereços IP, domínios ou URLs maliciosos. Os analistas MDR podem executá-las dentro da definição de resposta aprovada; os utilizadores XDR podem iniciá-las diretamente no Case. Verifique a disponibilidade sem bloquear destinos de produção. Um teste do efeito é uma alteração separada e aprovada, com um caminho de reversão específico do produto previamente definido.

Desativar Actions específicas em vez de eliminar ligações indiscriminadamente

As Actions da solução ampliada têm um controlo de desativação documentado: em Security Operations > Integrations > Marketplace, Configured > Actions, abra a Action em causa e desative-a em Enable/disable integration. Este não é um controlo universal para todos os conectores Data Ingest. A desativação não reverte alterações já executadas no sistema de origem.

Delete Integration remove as ligações e condições associadas e repõe a configuração da Action no estado inicial. Remover a única ligação também elimina as condições que lhe estão associadas. Por isso, guarde ou documente previamente as ligações e condições. Para reverter ações de teste, continua a aplicar-se o procedimento Microsoft ou da firewall correspondente, não a eliminação do conector.

Automatizações XDR: distinguir Classic REST e GraphQL

A informação sobre APIs é um complemento de 9 de outubro de 2026, não uma garantia retroativa relativa ao lançamento de setembro. As novas integrações XDR e os workflows XDR de escrita no Fusion devem utilizar as novas GraphQL APIs. Isto é diferente de uma ligação API do Marketplace: as suas chamadas REST podem continuar a dirigir-se ao fornecedor terceiro.

As anteriores Cases REST API e Detections REST API passam a chamar-se Classic XDR APIs e têm a descontinuação anunciada. A Detections REST API já é read-only. A Cases REST API continua disponível para integrações existentes; também deverá passar a read-only posteriormente. Depois, ambas deverão disponibilizar dados históricos até serem removidas. Esta informação não indica uma data concreta de desativação. Não elimine, por isso, integrações existentes indiscriminadamente nem altere os seus hosts devido ao nome Fusion.

Para cada automatização, registe a API, as operações de leitura e escrita, o período dos dados, o tenant, as permissões e o tratamento de erros. Nos clientes existentes, verifique separadamente se esperam dados atuais ou históricos e se algum workflow de escrita ainda tenta aceder a Classic Detections. A mudança para GraphQL exige implementar a correspondência de campos, paginação, autenticação, permissões e tratamento de erros com base no novo esquema concreto e comparar os resultados num teste isolado. Este artigo não fornece endpoints, nomes de mutations nem payloads inventados. O inventário está concluído quando cada cliente tem um responsável e uma decisão fundamentada de continuidade ou migração; isso ainda não equivale a um teste bem-sucedido de migração da API.

Qual a GraphQL API adequada ao cliente?

A publicação de 18 de setembro de 2026 incluía cinco API GraphQL com funções diferentes:

• Detections v2: pesquisar e editar Detections de endpoints, sensores de rede e outras fontes.
• Cases v2: gerir Cases, bem como Evidence, comentários, ficheiros e links.
• Threat Timeline v2: pesquisar relações entre processos para até 100 processos numa única chamada.
• Events v1: obter detalhes de eventos a partir de Event IDs conhecidos.
• Live Endpoint Search v1 (LES): executar consultas do tipo osquery em endpoints ligados e obter resultados e Telemetry.

Live Discover REST não está abrangido pelo anúncio de descontinuação das Classic Cases/Detections APIs. As integrações Live Discover REST existentes podem continuar a funcionar; a sua mudança para LES é opcional. A via Live e a XDR Query API de dados históricos têm funções distintas. A distinção entre as APIs de Live Discover explica também a seleção de destinos LES baseada em sessões. Do mesmo modo, a Endpoint API em /endpoint/v1 e a sua Device Migration não passam para GraphQL devido a esta descontinuação XDR.

Desde 12 de outubro de 2026 também está publicada a Search GraphQL API v1 para pesquisas QL históricas. Disponibiliza createSearch, getOrCreateSearch, search e searchResults; Consultar o Data Lake do Sophos Fusion com a Search GraphQL API descreve contrato de pedido, estado de execução, páginas de resultados e verificação da migração SQL. Data Lake Search mantém-se como via interativa; a XDR Query API continua disponível. A nova API não obriga a uma transição imediata nem é um processo LES de endpoints em tempo real. Para Assets e Entity Graph, continuam pendentes verificações separadas das referências e do tenant: a sua menção no guia Cases não autoriza uma implementação completa.

Verificar o contrato concreto de migração

A mudança não consiste em substituir o URL mantendo o cliente inalterado. Para Cases, Detections e, opcionalmente, LES, compara-se o respetivo workflow, não se aplica uma receita comum de REST para GraphQL:

• GraphQL devolve apenas os campos selecionados. O cliente verifica tanto o estado HTTP como o array errors e os campos de estado específicos da operação; HTTP 200 pode conter um erro de Query. Os campos aninhados necessários e as indicações de tempo com seconds/nanos são selecionados e processados deliberadamente.
• Em Detections, detectionSearch substitui o procedimento REST de início da Query, consulta do estado e obtenção dos resultados. As pesquisas com poucos resultados utilizam offset/limit; as pesquisas com muitos resultados utilizam o search_id devolvido com detectionPoll. Compare todas as partes e a contagem total. Os filtros são verificados individualmente como predicados QL; uma pesquisa de host espera um ID, não apenas o nome do dispositivo. Não está garantida uma alternativa idêntica para um type REST ou uma reputação Intelix.
• A Detection Severity de REST e GraphQL avalia conjuntos de dados separados segundo modelos separados. REST utiliza uma escala de números inteiros até 10; metadata.severity de GraphQL utiliza uma escala de 0 a 1. Não converta por divisão. Reavalie tecnicamente os limiares com base nos respetivos dados. Case.severity, com 2/4/6/8/10, é ainda outra escala.
• Em Cases, o cliente API utiliza o UUID id, não o shortId legível no formato CSE#####. Os antigos IDs de Cases REST não são traduzidos e os Cases antigos não ficam disponíveis através da nova API. As provas necessárias de casos antigos são guardadas antes da transição através do método anterior de obtenção confirmado; isto não implica um botão de exportação universal nem a transferência do histórico.
• Os tipos de Case, estados e Verdicts são resolvidos como dados de referência dinâmicos do tenant, dependentes da licença, e atualizados regularmente. assigneeId espera uma Subject ID ou uma @mention suportada, não um endereço de e-mail. Um assigneeSubject que não possa ser resolvido pode ser null; a apresentação precisa de uma alternativa deliberadamente definida para esse caso.
• caseEvidence devolve IDs de associação, não payloads de Evidence prontos a utilizar. As Detections são obtidas adicionalmente através de detectionRetrieveById com o argumento escrito exatamente como iDs, e os Events através dos seus Resource Names inalterados. As dependências de Assets e Entity Graph continuam em aberto até à verificação da referência adequada e do tenant. Os IDs de Detection, Event, Asset e Entity Graph não são intercambiáveis; um ponto de entrada de Entity Graph para um Case utiliza o UUID desse Case como INVESTIGATION, não o shortId.
• A paginação de Cases utiliza Offset ou Cursor, não ambos no mesmo pedido. Para uma lista que muda ao longo do tempo, prefira Cursor e devolva-o sem alterações. keyFindings é um documento tipado e é fornecido na obtenção individual, não na lista de Cases. Os filtros anteriores overviewContains e escalated não têm uma alternativa direta; decida expressamente sobre as funções necessárias antes da transição.
• Não existe deleteCase como substituto de DELETE REST. O encerramento, eventualmente com o Verdict exigido pelo tipo de Case, e o posterior arquivamento opcional são passos separados. Nos Cases MDR geridos pelo prestador, os campos em que a escrita é efetivamente permitida são mais restritos e têm de ser verificados previamente.

Um piloto tem de responder à mesma pergunta funcional no tenant correto, com IDs rastreáveis, paginação completa e erros analisados. As funções GraphQL adicionais, como comentários, ficheiros, links, regras, Templates e Split/Merge, são extensões próprias, não requisitos para todas as transições. A falta de correspondência entre campos ou um histórico por esclarecer continuam a exigir uma decisão em aberto para o cliente; não são ignorados com base numa equivalência presumida.

Âmbito: XDR, MDR e licenças

Uma integração não substitui uma licença XDR nem MDR. O XDR disponibiliza funções de análise que permitem à própria equipa de segurança investigar dados no Threat Analysis Center e no Data Lake. O MDR acrescenta o serviço gerido da Sophos. As integrações selecionáveis no tenant dependem do contrato Sophos, do produto, do tipo de integração e, quando aplicável, da licença do produto de terceiros.

Para uma conservação mais longa ou fontes de dados próprias, Sophos Next-Gen SIEM explica como verificar o add-on opcional e inventariar os períodos de conservação por fonte.

A afirmação de que determinadas integrações são gratuitas não significa que todo o Marketplace o seja. Para MSP Flex existem Integration License Packs separados para categorias como Endpoint, Network, Email ou Firewall. A regra MSP Flex anterior indicava que, com uma licença XDR, Sophos NDR, Sophos Cloud Optix, Microsoft Graph Security e a Microsoft 365 audit appliance não exigiam um Integration License Pack adicional. Esta regra aplica-se expressamente apenas a clientes MSP Flex. Hoje, Cloud Optix é apenas uma entrada histórica nessa lista: o seu End of Life em 30 de setembro de 2026 impede planear novas utilizações em produção deste serviço. Confirme, por isso, o que está disponível no próprio tenant e no contrato, em vez de assumir um âmbito gratuito geral.

O sistema do outro lado também pode exigir licenças. As páginas da Sophos contradizem-se no caso do Microsoft 365: a página de visão geral afirma que os logs de auditoria de Management Activity estão disponíveis para todos os clientes Microsoft 365; contudo, a página de configuração específica exige Purview Audit (Standard ou Premium), uma das licenças de utilizador aí indicadas e auditoria ativa. Para a configuração, aplicam-se estes requisitos específicos. As Detections fornecidas pelo Graph Security V2 dependem ainda do âmbito das licenças Microsoft e das funções Defender XDR disponíveis. Para Microsoft 365 Response Actions no percurso Classic/TAC, a Sophos não indica um requisito de licença Microsoft; contudo, são necessários um administrador Microsoft 365 e as permissões Graph expressamente identificadas abaixo como Classic. Para Actions na solução ampliada, aplicam-se antes os requisitos descritos acima e as permissões efetivamente solicitadas na autorização em dois passos; a lista Classic não define o novo consentimento.

Cloud Optix após o End of Life: tratar telemetria e CSPM separadamente

O Sophos Cloud Optix atingiu o End of Life em 30 de setembro de 2026. Desde então, o serviço não recolhe novos dados, não gera findings e não encaminha telemetria para MDR ou XDR. No estado verificado em 11 de outubro de 2026, a recomendação anterior de exportar antes do EOL e mudar em paralelo já não é um passo futuro executável.

Verifique agora quais os ambientes AWS, Azure, GCP ou OCI anteriormente ligados apenas através de Cloud Optix e quais já têm uma ligação direta à solução XDR/MDR ampliada. Estas integrações cloud diretas têm de ser configuradas para cada plataforma; o upgrade do produto não o faz automaticamente. Sem uma nova ligação verificada, não se pode afirmar uma cobertura de telemetria sem lacunas para o período após 30 de setembro. Se o tenant ainda não tiver recebido o upgrade ou faltar um mosaico de produto, esclareça o estado com a equipa de conta Sophos ou de parceiros.

Uma integração API cloud direta não é o mesmo que um Syslog Data Collector a funcionar em AWS, Azure ou GCP. No Marketplace, selecione a integração para o fluxo de dados cloud necessário, verifique as permissões concretas na origem e comprove depois os dados e as Detections esperadas. A comprovação tem de identificar a conta cloud, a origem dos dados e o intervalo de tempo; uma ligação verde, por si só, não basta.

O Cloud Security Posture Management (CSPM) não é transferido: a avaliação da configuração cloud, os relatórios de benchmarks de conformidade e os findings de configuration drift não são funções prometidas pelas novas integrações de telemetria. Documente esta necessidade separadamente e esclareça a substituição e os direitos contratuais restantes com a equipa de conta. Os relatórios Cloud Optix, o histórico de findings, as provas de conformidade e os dados de inventário também não são migrados para o novo sistema. Proteja as exportações já existentes e verifique se estão completas; não está aqui confirmada uma possibilidade de exportação posterior ou de recuperação.

Tipos de integração e credenciais necessárias

REST API

Uma integração API obtém dados do serviço cloud do fabricante ou envia para esse serviço uma Response Action. Consoante o produto, o assistente de configuração solicita, por exemplo, Tenant ID ou Organization ID, API URL, Client ID, Client secret, token ou certificado. As integrações API não necessitam de uma appliance Sophos.

Algumas integrações recebem as credenciais diretamente no assistente. Outras pedem uma credencial de integração reutilizável. A opção de selecionar uma credencial existente ou criar outra no assistente indica se o conector suporta esta função. O Integration Credential Manager está disponível apenas para uma parte limitada das integrações API; nem todos os secrets podem ser reutilizados centralmente.

Log collector

A descrição da appliance abaixo aplica-se ao percurso Classic SVA. Na solução XDR ampliada, os XDR Data Collectors recolhem dados Syslog e têm requisitos próprios de recursos e rede. Os antigos mínimos SVA não devem ser aplicados à nova VM. A migração provisiona configurações, mas não inicia um substituto pronto a funcionar. Mudança do Syslog SVA e operação do XDR Data Collector explica as variantes de endereçamento, as definições excluídas e a mudança segura. O NDR não é migrado automaticamente neste processo.

Numa integração Log Collector, o sistema de origem exporta eventos por Syslog para uma Sophos appliance. O Log Collector processa os dados e carrega-os para o Sophos Data Lake. A appliance funciona em ESXi, Hyper-V, AWS ou Nutanix, ou em hardware Dell, NUC ou OnLogic adequado. Para ESXi ou Hyper-V, atribua pelo menos 4 CPUs, 16 GB de RAM e 160 GB de armazenamento; são suportados ESXi 6.7 Update 3 com hardware VM versão 11 ou posterior e Hyper-V no Windows Server 2016 ou posterior. A Sophos gere as atualizações do sistema operativo e de segurança; não instale outro agente Sophos ou antimalware. Aumente os recursos para muito volume ou várias integrações e valide DNS, proxy e as exclusões de portas e domínios antes da aprovação. Configure o produto de terceiros para enviar para esta appliance, não para um servidor Syslog qualquer.

Várias integrações podem utilizar a mesma appliance. Ainda assim, o protocolo, a porta, o formato e a origem têm de ser configurados para cada produto de acordo com o respetivo guia de integração. Uma appliance verde, por si só, não comprova que está a chegar o tipo de evento correto.

Produtos Sophos

Produtos como Sophos Firewall e Sophos NDR têm processos de configuração específicos. O Sophos NDR e as integrações Log Collector precisam de uma Integration appliance, mas não necessariamente de uma VM clássica. Uma integração exclusivamente REST API não precisa de appliance. Use o Marketplace do tenant afetado para verificar a disponibilidade: cada mosaico mostra os métodos oferecidos e abre o assistente adequado.

Delimitar com segurança a carga de trabalho NDR numa appliance partilhada

A topologia de appliance partilhada abaixo aplica-se a Classic SVA/TAC, não ao novo XDR Data Collector. Este substitui a componente Syslog; o NDR continua a ser uma carga de trabalho da appliance operada separadamente e não é transferido para o novo Collector.

Cada appliance só pode alojar uma integração Sophos NDR. A mesma appliance pode também alojar várias integrações de terceiros baseadas em appliance como Log Collectors. Por isso, antes de cada alteração, expanda a entrada da appliance em Configured > Integration Appliances e verifique todas as integrações atribuídas. Nem o valor Integrations nem um estado verde da appliance substituem esta verificação.

Um reinício específico do NDR interrompe o sensor NDR, enquanto os Log Collectors continuam a funcionar. Em contrapartida, Restart ou Shutdown da VM completa interrompe o NDR e todos os Log Collectors dessa appliance. Planeie estas ações numa janela de manutenção, documente previamente o estado de todas as cargas de trabalho e verifique-as individualmente depois. O procedimento está descrito em Operar com segurança a appliance e o sensor Sophos NDR.

Delete no menu da appliance não remove apenas uma integração individual. Não elimine a appliance enquanto lhe estiver atribuído o NDR ou um Log Collector. Além disso, a opção do menu não indica que a VM implementada será removida nem que os dados já ingeridos no Data Lake serão eliminados. Antes da desativação, esclareça as atribuições, a retenção de dados, a remoção dos recursos da plataforma, o caminho de recuperação e a verificação final. Até lá, mantenha a appliance.

Antes da configuração

1. Inicie sessão no Sophos Fusion como Admin ou Super Admin. A Sophos indica estas funções como requisito para a configuração geral.
2. No produto de terceiros, confirme que licença, função administrativa, função API ou saída Syslog é necessária.
3. Decida se precisa de Data Ingest, Response Action ou de ambos. Uma integração Response não fornece automaticamente a telemetria em que se baseia uma investigação.
4. Para acesso API, crie sempre que possível uma aplicação ou conta de serviço dedicada. Conceda apenas as permissões exigidas pelo guia do produto e documente o responsável, a data de expiração e o processo de rotação do secret.
5. Se o produto de terceiros exigir uma lista permitida de IPs de origem para chamadas API administrativas, identifique primeiro a região Central em My Environment > Installers: passe o cursor sobre um link de download em Endpoint Protection ou Server Protection e leia a região no URL apresentado, por exemplo eu-central-1. Depois permita apenas os endereços dessa região na tabela abaixo. São origens das chamadas API da Sophos, não destinos de saída da appliance de integração.
6. Para uma Integration appliance, verifique o respetivo percurso de rede de saída, o DNS e, quando aplicável, o proxy de acordo com os requisitos da appliance.
7. Planeie um evento de teste reproduzível e inofensivo. Um evento de início de sessão ou evento de auditoria é mais adequado do que uma tentativa real de malware.

Endereços IP de origem para a lista permitida da API

Esta tabela apresenta o conjunto de IPs Classic verificado em 14 de setembro de 2026. Distingue-se da lista permitida XDR atual acima e não é, por si só, prova suficiente para alterar uma lista permitida de produção.

Antes de uma alteração, verifique a geração da integração, a região do tenant e o conjunto completo de IPs necessários face às informações atuais da Sophos. Se houver divergências, não utilize valores antigos nem combine regiões. Solicite a verificação da associação da região e da alteração segundo o seu próprio processo de aprovação, permita apenas o âmbito necessário e depois valide a integração afetada com uma sincronização da API ou um evento de teste inofensivos. Registe na alteração o estado inicial, a aprovação, os resultados e o procedimento de recuperação.

A Sophos identifica atualmente tanto a linha de São Paulo como a do Dubai como sa-east-1. Distinga-as pela localização do tenant e pelo conjunto de IPs; nunca combine regiões. Registe a lista aprovada na alteração.

Adicionar a integração no Marketplace

1. Abra Threat Analysis Center > Integrations > Marketplace.
2. Pesquise o fabricante ou o produto. Quando existirem entradas semelhantes, utilize a página do produto e verifique a categoria, o nome do produto, o tipo de integração e a finalidade. Cisco Meraki e Fortinet FortiAnalyzer, por exemplo, são disponibilizados como variantes API e Log Collector.
3. Abra a integração pretendida.
4. Selecione o tipo necessário, por exemplo Data Ingest, e clique em Add Configuration.
5. Siga os passos de Integration setup. Nas integrações API, introduza os dados do sistema de origem ou conceda um OAuth Consent. Nas integrações Log Collector, crie ou selecione uma appliance e direcione depois para ela a exportação Syslog do sistema de origem.
6. Se a Sophos solicitar Internal Domains e IP Ranges na primeira integração, introduza apenas os seus intervalos internos. Estes dados identificam endereços próprios, agrupam Alerts relacionados e evitam pesquisas em terceiros; não devem ser confundidos com a lista permitida dos endereços de origem da Sophos.
7. Guarde a configuração e conclua totalmente qualquer diálogo de Consent externo. Registe o nome da integração, o tenant de origem, a pessoa responsável e a data da próxima rotação de credenciais.
8. Abra Threat Analysis Center > Integrations > Configured. A nova configuração tem de aparecer nessa área. É aí que pode ser monitorizada ou editada posteriormente; em Connection Method, também pode confirmar se o diagnóstico deve seguir o percurso API ou Log Collector.

FortiAnalyzer: os Alerts da API não correspondem a todos os eventos Syslog recebidos

No Fortinet FortiAnalyzer, o conector API suporta Appliance e VM Subscription, não FortiAnalyzer Cloud. Lê exclusivamente Alerts gerados pelo FortiAnalyzer a partir de /eventmgmt/adom/<ADOM>/alerts; <ADOM> identifica o domínio administrativo adequado do sistema de origem. Um evento Syslog apenas recebido pelo FortiAnalyzer não se transforma automaticamente num Alert deste tipo. Se for necessário ingerir eventos Syslog, avalia-se antes a integração FortiAnalyzer Log Collector ou a integração Fortinet Fortigate para a fonte concreta. A decisão é tomada antes da configuração do conector, não apenas quando se deteta uma suposta lacuna de dados.

O conector API remove dados que não respeitam o formato e descarta depois determinados tipos de Alert: mensagens de túneis VPN (vpntunnel), pedidos Web bloqueados para destinos não classificados, mensagens de varrimento de IPs/portas, ligações excluídas da inspeção SSL devido a uma lista permitida ou endereço, mensagens Link Monitor sobre interfaces desativadas ou ativadas, avisos de Memory Log cheio, bem como Disk Quota Alert/Warning e ligações SSL inseguras bloqueadas. A ausência de um Alert destes não constitui, por isso, automaticamente um erro de autenticação ou transporte. A classificação do tipo utiliza uma correspondência de padrões quando message não está vazio; caso contrário, utiliza os campos FTNTFGTattack, ad.subtype e cat; se não houver correspondência, o campo message é limpo. O título de um Alert recebido não constitui automaticamente um mapeamento MITRE completo.

Para a aceitação, escolha um evento inofensivo e aprovado que comprovadamente gere um Alert do FortiAnalyzer, por exemplo uma alteração de configuração prevista para esse efeito no seu Event Handler. Comprove primeiro o Alert, o ADOM e o momento no FortiAnalyzer e confirme que o formato e o tipo de Alert não são descartados. Depois, comprove o mesmo Alert no tenant correto através do método de pesquisa Sophos confirmado para este conector. Um início de sessão de teste arbitrário ou uma linha Syslog enviada sem um Alert do FortiAnalyzer não é um teste válido de ingestão pela API. Se faltar o Alert esperado, verifique primeiro a geração de Alerts, o ADOM, o formato e os filtros de tipo, e depois as credenciais e a ligação; uma Sophos Detection ou um Case não estão garantidos mesmo quando a ingestão é bem-sucedida.

Verificar e testar o funcionamento

Uma configuração guardada ainda não comprova o funcionamento. Verifique, por esta ordem, a ligação, o fluxo de dados e o conteúdo funcional:

1. Estado da ligação: Abra a entrada em Configured ou, no caso de uma appliance, o respetivo estado. Nos Log Collectors, vermelho significa que a integração não está a funcionar, amarelo que funciona com erros e verde que os eventos estão a ser recebidos e processados sem problemas visíveis.
2. Evento de teste definido: Gere no sistema de origem um evento inofensivo que seja certamente recolhido pela API ou categoria Syslog em causa, por exemplo uma alteração administrativa ou um início de sessão de teste. Registe a hora, o utilizador e a origem.
3. Comprovação no Data Lake: Depois do atraso específico do produto, pesquise em Threat Analysis Center > Live Discover. Utilize a categoria ou consulta do Live Discover documentada no guia específico do produto; se a Sophos não documentar uma para o conector, este processo geral não deve prometer uma comprovação universal por consulta. O runbook de Live Discover explica a consulta, os limites do Data Lake e a verificação de resultados. Confirme o timestamp, o Tenant, o utilizador e o tipo de evento. Um único registo comprova a ligação; vários registos atuais durante um período adequado comprovam o fluxo contínuo de dados.
4. Limite das Detections: Nem todos os eventos ingeridos originam uma Detection ou um Case. O Data Ingest torna os dados analisáveis; as Detections só surgem quando é acionada uma lógica de deteção adequada. Por isso, teste primeiro a ingestão no Data Lake e não espere necessariamente um Alert.
5. Response Action: Utilize uma conta de teste aprovada e documente o estado inicial. Para Microsoft 365, Block user sign-in, seguido de Allow user sign-in, é adequado como teste reversível; Revoke all current sessions não é reversível. Tenha também em conta que o Entra Connect Sync pode voltar a ativar posteriormente uma conta híbrida bloqueada, que a definição MDR Response limita as ações dos analistas Sophos e que os nomes de algumas Inbox Rules são sensíveis a maiúsculas e minúsculas nas Response Actions.

Os Health Alerts não constituem um teste imediato. O período de 24 horas começa com a primeira mensagem de erro e só produz um Alert de Severity média se o erro persistir sem interrupção. Um estado verde ou o reconhecimento do Alert reinicia a contagem decrescente. Se o problema continuar, o Alert volta depois a aparecer uma vez a cada 30 dias.

Microsoft 365: três integrações distintas

«Ligar o Microsoft 365» não corresponde a um único botão. A tabela abaixo descreve tarefas separadas no Marketplace Classic/TAC, incluindo o limite das Response Actions nesse percurso. Para a solução ampliada, aplica-se o processo Microsoft Graph API Actions acima, com ligações próprias e novo consentimento; a limitação Classic a um único ambiente não se aplica a esse novo processo.

Para Response Actions no percurso Classic/TAC, a Sophos indica as permissões Microsoft Graph User.ManageIdentities.All, User.EnableDisableAccount.All, User.RevokeSessions.All, MailboxSettings.Readwrite e User.Read. No MDR, a opção MDR Response selecionada continua a limitar se os analistas podem atuar sem aprovação. Num ambiente Entra ID híbrido, o Microsoft Entra Connect Sync pode voltar a ativar posteriormente um início de sessão bloqueado no Central.

Exemplo: ligar Management Activity em segurança

1. Certifique-se de que a auditoria está ativa no Microsoft 365. Um administrador Microsoft 365 tem de autorizar a ligação.
2. Abra Threat Analysis Center > Integrations > Marketplace e selecione Microsoft - Office 365 Management Activity API.
3. Em Data Ingest (Security Alerts), clique em Add Configuration.
4. Verifique o aviso de auditoria, clique em Save and continue e, depois, em Connect to Microsoft 365, clique em Proceed.
5. Inicie sessão com a conta de administrador Microsoft prevista, verifique as permissões solicitadas e confirme com Accept. Termine a confirmação com Close.
6. Verifique a entrada no Sophos Fusion. Em Live Discover > Query, tem de aparecer a categoria Microsoft 365 audit data. Gere depois um evento de auditoria identificável e procure-o com uma consulta disponibilizada.

A Microsoft não garante um prazo fixo para que cada evento apareça no log de auditoria. Por conseguinte, o atraso de uma linha não significa automaticamente que exista um erro de integração. Após ativar a auditoria pela primeira vez, os dados podem demorar até 12 horas a ficar visíveis.

Para o Graph Security V2, a primeira sincronização ocorre cerca de cinco minutos depois de os dados estarem disponíveis no Microsoft Defender Security Center. Se for necessário provisionar primeiro o serviço Alerts and Incidents, só esse passo da Microsoft pode demorar cerca de uma hora.

Desativar ou reverter uma integração

Não existe um botão Disable uniforme para todos os tipos de integração. As ações disponíveis variam consoante o produto e o Connection Method. Por isso, não presuma que existe uma opção universal:

1. Abra Threat Analysis Center > Integrations > Configured, selecione a configuração e documente o estado, o nome, o tenant de origem, a appliance e a credencial.
2. Numa integração API, comece por interromper de forma controlada a ingestão de dados ou utilize uma ação Disable ou Delete, se a página do produto a disponibilizar. Em seguida, revogue o OAuth Consent no sistema de origem ou desative a aplicação dedicada ou o token. Nas Response Actions, este passo impede novas ações a partir do Central.
3. Numa integração Log Collector, remova a configuração de destino Syslog no sistema de origem. Não elimine uma appliance Sophos partilhada enquanto outras integrações a utilizarem.
4. Remova a configuração no Central apenas quando estiverem cumpridos os requisitos de retenção, auditoria e alteração. A remoção de uma configuração não garante a eliminação dos dados já ingeridos no Data Lake; por isso, esclareça previamente a retenção e a eliminação com base nos requisitos de Data Lake e conformidade aplicáveis ao tenant.
5. Confirme que deixaram de chegar novos eventos e que já não são possíveis Response Actions inesperadas. Remova depois os secrets, certificados, contas de serviço e entradas da lista permitida que já não sejam necessários.

Para uma breve interrupção de manutenção numa integração Log Collector, pare a exportação Syslog sem eliminar uma appliance partilhada. Nas integrações API e Response, só deve bloquear uma credencial como pausa de manutenção se a reativação da mesma configuração tiver sido verificada previamente; caso contrário, utilize exclusivamente o processo Disable, Delete ou Reconnect disponível para o conector. Uma credencial bloqueada ou expirada não é uma reversão universal e provoca erros de sincronização.

Delimitar sistematicamente erros comuns

A integração API não sincroniza

Abra Configured, verifique Connection Method e leia o erro concreto. Corrija primeiro no produto de terceiros Invalid credentials, insufficient permission e expired credentials: confirme IDs, secrets, validade dos tokens, certificados e permissões API. Network not reachable e invalid domain também exigem verificações de DNS, proxy, firewall e estado do serviço. Com request throttling, o fornecedor limitou a API; guardar repetidamente de imediato pode piorar o problema. Na Microsoft, HTTP 401 indica autenticação inválida; 429 e 509 indicam limitação.

O Log Collector permanece vermelho ou amarelo

Vermelho significa indisponível; amarelo, em funcionamento com erros. Verifique os recursos da VM, a rede e o DNS, a acessibilidade de saída e o percurso Syslog entre o sistema de origem e a appliance. A mensagem no events received since last container restart indica que não foram recebidos eventos Syslog desde o arranque do contentor; no received events in last 10 mins pode significar uma interrupção do Export ou apenas uma origem que envia raramente. Em caso de erros de upload, a appliance armazena os dados em buffer no disco. Se o upload permanecer bloqueado e o armazenamento ficar cheio, os dados mais antigos poderão ser descartados.

O Microsoft 365 não fornece dados

Para Management Activity, a auditoria do Microsoft 365 tem de estar ativa e, em Office 365 Management APIs, a propriedade Enabled for users to sign-in? = Yes tem de estar ativada. Considere o tempo de arranque de até 12 horas após a ativação da auditoria. Para Graph Security V2, verifique o acesso a Defender XDR, o Consent, o provisionamento do serviço Alerts e o âmbito das licenças Microsoft disponíveis. A antiga Graph Security API já não é uma alternativa.

Não existe Health Alert apesar da falha

Confirme primeiro se se trata de uma integração Data Ingest e se o erro persiste sem interrupção há 24 horas desde a primeira mensagem. Um estado verde entretanto obtido ou o reconhecimento do Alert reinicia a contagem decrescente. Por predefinição, todos os administradores do Central recebem o e-mail; as suas Notification Rules podem alterar esta distribuição.

Regras de segurança e operação

• Utilize aplicações e secrets dedicados, em vez de acessos de administrador pessoais.
• Conceda apenas as permissões API exigidas pela integração concreta. Pela sua natureza, as integrações Response necessitam de permissões de escrita e requerem uma aprovação mais rigorosa do que a mera ingestão de dados.
• Não guarde secrets em tickets, capturas de ecrã ou artigos da KB. Registe o responsável e a data de expiração no sistema de gestão de palavras-passe ou secrets.
• Planeie a rotação de credenciais antes da expiração. A Sophos comunica credenciais expiradas como erros de sincronização.
• Autorize endereços IP da Sophos apenas se o fornecedor exigir uma lista de origens permitidas e utilize a lista da região real do Central.
• Ative Health Notifications para uma equipa responsável. Ao criar uma Custom Notification Rule, tenha em conta que é desativado o envio padrão de todos os Alerts por e-mail a todos os administradores e que as regras necessárias têm de ser recriadas separadamente.
• Documente, para cada integração, a origem dos dados, a finalidade, a classificação dos dados, a retenção, as permissões, o teste, o responsável e o processo de reversão.

Critérios de aceitação

A integração só está concluída quando aparece em Configured com o método esperado, um evento de teste definido é comprovável no destino previsto, o timestamp e o tenant de origem estão corretos e um responsável assume a rotação de credenciais e os Health Alerts. Para Response Actions, a aceitação inclui também um teste aprovado e documentado; apenas as ações reversíveis são repostas no estado inicial, e ações irreversíveis como a revogação de Sessions não podem servir de teste de Rollback. Documente no registo operacional os atrasos inevitáveis, como os da auditoria do Microsoft 365.

Perguntas frequentes

Todas as integrações enviam dados para o Sophos Data Lake?

Não. Data Ingest envia dados para o Data Lake. Response Action permite executar uma ação no produto de terceiros. Alguns produtos oferecem apenas um tipo; outros têm configurações separadas para ambas as direções.

As integrações de terceiros são gratuitas com o XDR?

Não de forma geral. Para MSP Flex, a Sophos identifica certas integrações na categoria Sophos XDR que podem ser utilizadas com XDR sem um Integration License Pack adicional. Outras categorias exigem os Packs adequados no Flex. Podem ainda ser necessárias licenças do fornecedor terceiro.

Porque vejo dados, mas nenhuma Detection?

A ingestão e a deteção são fases distintas. Um Data Ingest Connector pode escrever corretamente eventos no Data Lake sem que cada evento origine uma Sophos Detection ou um Case. Verifique primeiro o fluxo de dados em bruto com a consulta prevista no Live Discover.

Posso utilizar a mesma appliance para várias integrações Syslog?

Sim, no percurso Classic SVA, a Sophos permite várias integrações de terceiros e uma integração Sophos NDR na mesma appliance. Ainda assim, cada origem tem de ser configurada com os dados corretos de ligação e formato. O novo XDR Data Collector, por sua vez, substitui o Syslog e não transfere nem aloja essa carga de trabalho NDR. Para a mudança, aplica-se o processo de migração de Collectors ligado acima; o NDR é operado separadamente segundo o respetivo runbook.

Porque não é suficiente a integração Microsoft 365 Response?

Esta disponibiliza ações, mas não ingere automaticamente logs de auditoria ou Defender Alerts. Adicione também Microsoft 365 Management Activity e Microsoft Graph Security API V2, para disponibilizar Detections e contexto de investigação.

A remoção de uma integração elimina dados históricos do Data Lake?

A remoção não garante a eliminação imediata dos dados já ingeridos. Considere, portanto, a remoção como uma interrupção do fluxo futuro e esclareça separadamente as obrigações de retenção ou eliminação antes de prometer um prazo vinculativo.