Saídas e Roteamento (visão geral)
O CentralOps é um pipeline de dados de segurança que coleta eventos de várias ferramentas, padroniza esses eventos e os entrega a um ou mais destinos (SIEMs, data lakes, brokers de mensagem). Em vez de mandar tudo para um único lugar fixo, você decide — por regra — qual evento vai para qual destino.
O caminho de um evento é sempre o mesmo: Coleta → Normalização → Roteamento → Destinos.
Quem faz o quê:
| Papel | O que pode fazer |
|---|---|
| Administrador | Criar e editar destinos e regras de roteamento. |
| Operador | Pausar e retomar destinos, acompanhar a saúde. |
| Demais perfis | Consultar a saúde e o histórico de entrega. |
Quando usar
- Reduzir custo de SIEM. Você paga caro por volume no SIEM, então quer mandar só os alertas críticos para lá e jogar os eventos verbosos (atividade de arquivo, fluxo de rede) num data lake mais barato, mantendo tudo retido para investigação posterior.
- Trocar de SIEM sem risco. Você está migrando do SIEM atual para um novo e quer começar enviando uma fração pequena dos eventos para o novo destino, validar, e ir aumentando aos poucos até cortar 100%.
- Atender vários clientes (MSSP). Cada cliente tem seu próprio destino e suas próprias credenciais, e um cliente nunca pode ver os dados ou os destinos de outro.
As quatro etapas do pipeline
1. Coleta
Os coletores buscam os eventos nas ferramentas de origem (por exemplo, Sophos Central e Wazuh). Você acompanha e configura os coletores no menu Coleta → Coletores e cadastra as origens em Coleta → Integrações.
2. Normalização
Eventos de qualquer origem são convertidos para um formato único e padronizado. Junto do evento vão metadados internos (plataforma, severidade, tipo de evento, origem) que o roteamento usa depois para decidir o caminho. Você gerencia as regras de conversão no menu Normaliza → Mapeamentos.
3. Roteamento
Para cada evento, o sistema decide:
- Quais destinos vão recebê-lo (pode ser mais de um — o mesmo evento é enviado simultaneamente a vários destinos).
- Qual redação de PII aplicar antes de enviar (pode ser diferente por destino).
- Se o evento deve ser descartado (para cortar ruído ou economizar).
As regras ficam no menu Roteia → Rotas (só admin).
4. Destinos
Cada destino é independente:
- Tem a própria configuração (endereço, credenciais, formato).
- Tem a própria fila de entrega, com novas tentativas automáticas e uma fila de reenvio para o que não passou na primeira vez.
- Reporta a própria saúde (status, vazão, latência, erros).
- Se um destino fica instável, isso não afeta os outros.
Os destinos ficam no menu Roteia → Destinos (só admin).
Tipos de destino disponíveis
O CentralOps entrega para os tipos de destino abaixo. Ao criar um destino, você escolhe o tipo e o formulário pede os campos certos para ele.
| Tipo de destino | Para que serve |
|---|---|
| Splunk (HEC) | Enviar para um índice do Splunk. |
| Elasticsearch | Enviar para um índice do Elastic. |
| Amazon S3 | Arquivar em um bucket S3 (ótimo para data lake / retenção longa). |
| Microsoft Sentinel | Enviar para o Sentinel via tabela de ingestão. |
| Apache Kafka | Publicar em um tópico Kafka. |
| OpenTelemetry (OTLP) | Enviar a um coletor de telemetria compatível. |
| Syslog | Enviar via Syslog (formatos RFC 3164 e RFC 5424). |
| Arquivo JSONL | Gravar em arquivo local, um evento por linha. |
| Webhook genérico | Integrar com SOAR, automação ou endpoints HTTP customizados. |
| Datadog (Logs) | Centralizar observabilidade de segurança no Datadog. |
| Google SecOps (Chronicle) | Enviar para o SIEM do Google. |
| Amazon Security Lake | Arquivar em formato OCSF padronizado na AWS. |
O destino Wazuh já vem pronto e entrega exatamente como na versão anterior do produto, sem mudança de comportamento. Ele aparece na lista de destinos como qualquer outro. Veja Destino Wazuh.
Para a lista completa com os detalhes de cada tipo, veja o Catálogo de Destinos.
Conceitos principais
Destino
Um destino é onde os eventos chegam. Ao cadastrá-lo, você informa:
| Item | O que é |
|---|---|
| Tipo | O tipo de destino (Splunk, Elastic, S3, etc.). |
| Configuração | Endereço, credenciais e formato. As credenciais ficam guardadas de forma cifrada e nunca aparecem em texto na tela. |
| Entrega | Como o destino agrupa e reenvia os eventos (veja abaixo). |
| Teste de conexão | Um botão que valida as credenciais e confirma que o destino está acessível antes de salvar. |
Opções de entrega
Cada destino tem ajustes de entrega no próprio formulário. Em linguagem de produto, eles controlam:
| Ajuste | O que faz |
|---|---|
| Tamanho do lote | Quantos eventos juntar antes de enviar de uma vez. |
| Tentativas automáticas | Quantas vezes reenviar quando há falha temporária. |
| Tempo limite | Quanto esperar pela resposta do destino antes de considerar falha. |
| Envios simultâneos | Quantos lotes podem estar em trânsito ao mesmo tempo (aumentar acelera, dentro do que o destino aguenta). |
| Proteção contra destino instável | Se o destino começa a falhar muito, o sistema pausa os envios por um tempo e tenta de novo depois, em vez de insistir e piorar. |
Cada destino tem a própria fila de reenvio. Se um destino rejeita um evento, ele vai para a fila de reenvio daquele destino — não é perdido e não atrapalha os outros destinos.
Regra de roteamento
Uma regra diz quais eventos vão para quais destinos. Você monta as regras no menu Roteia → Rotas (só admin). Cada regra tem:
| Campo | O que faz |
|---|---|
| Prioridade | Ordem em que as regras são avaliadas (a de número menor é avaliada primeiro). |
| Condição | O filtro que define a quais eventos a regra se aplica (por exemplo, eventos do Sophos com severidade alta). |
| Ação | Enviar o evento aos destinos escolhidos, ou descartá-lo. |
| Destinos | Quais destinos recebem o evento. |
| Regra final | Se marcada, o evento para nesta regra. Se não, o evento é copiado e continua sendo avaliado pelas próximas (é assim que se manda o mesmo evento a vários destinos). |
| Percentual gradual (canary) | Aplica a regra só a uma fração dos eventos (por exemplo, 10%). Serve para liberar uma mudança aos poucos. |
| Proteger detecção | Ligada por padrão. Enquanto estiver ligada, a regra nunca é amostrada, suprimida nem tem o evento bruto descartado — as três alavancas abaixo são simplesmente ignoradas nela. |
| Amostragem % | Entrega só essa fração dos eventos aos destinos da regra. 100 = entrega tudo (o padrão). |
| Supressão | Deixa passar só N eventos "iguais" por janela de tempo e economiza o excedente. Vem desligada. |
| Descartar o evento bruto | Remove o payload original do fornecedor da entrega desta regra, preservando o evento normalizado (OCSF). Vem desligado. |
Essas quatro últimas linhas formam o bloco de economia da regra e andam juntas: enquanto Proteger detecção estiver ligada — e ela nasce ligada em toda regra —, marcar amostragem, supressão ou descarte do bruto não faz nada. O detalhe de cada uma está no Guia de Roteamento.
Exemplo de conjunto de regras:
- Prioridade 10 — eventos com severidade alta vão para Wazuh e Sentinel ao mesmo tempo; não é regra final, então o evento continua.
- Prioridade 20 — eventos de atividade de arquivo são descartados (corte de ruído).
- Prioridade 30 — qualquer outro evento vai para o Wazuh (regra final de garantia, para nada se perder).
Para montar regras passo a passo, veja o Guia de Roteamento. Para liberar uma mudança aos poucos, veja Roteamento gradual (canary).
Redação de PII por regra
Cada regra pode esconder ou remover campos sensíveis (como nome de usuário ou IP de origem) antes de enviar ao destino. Como a redação é por regra, o mesmo evento pode chegar:
- Completo ao data lake (S3), para você ter o dado íntegro guardado.
- Mascarado ao SIEM, onde você não precisa do dado sensível em texto claro.
Isso permite guardar o dado íntegro num destino barato e mandar uma versão reduzida para o destino caro. Veja Redação de PII.
Fila de reenvio por destino
Quando um destino rejeita um evento, ele não é descartado: vai para a fila de reenvio daquele destino. O tratamento depende do motivo:
| Situação | O que acontece |
|---|---|
| Evento grande demais para o destino | É rejeitado e fica na fila de reenvio. Para caber, corte o payload bruto no mapeamento (bloco raw_reduction) ou ligue Descartar o evento bruto na regra que alimenta esse destino. As duas alavancas só valem para eventos novos: o que já está na fila guarda o payload como foi gravado, e reprocessar não o encolhe — ele será rejeitado de novo. A redação de PII não serve para isso: ela é de conformidade, é fail-closed e pode parar a entrega em vez de encolher o evento. Veja Redução de volume e custo. |
| Credencial inválida ou expirada | Não adianta repetir; o evento fica retido até você corrigir a credencial. |
| Falha temporária do destino (sobrecarga, indisponibilidade momentânea) | O sistema tenta de novo sozinho, esperando cada vez um pouco mais entre as tentativas. |
Eventos retidos na normalização ficam em Normaliza → Quarentena. Já o que um destino rejeitou fica na fila de reenvio daquele destino, em Roteia → Destinos — são duas filas diferentes, com causas diferentes.
Saúde de cada destino
Cada destino tem o próprio painel de saúde, com:
- Status: saudável, degradado ou inativo.
- Vazão: eventos por segundo e volume de dados.
- Taxa de sucesso e erro: percentual de eventos aceitos e rejeitados.
- Fila: tamanho da fila e se está acumulando.
- Último sucesso e último erro: quando cada um aconteceu.
Para ver o painel de um destino, vá a Roteia → Destinos, abra o destino e veja a aba de saúde. Para a visão geral de todo o pipeline, use Visão geral → Saúde do pipeline. Veja também Observabilidade.
Configuração rápida
1. Criar um destino
- Vá a Roteia → Destinos e inicie a criação de um novo destino.
- Escolha o tipo na lista — a interface pede apenas os campos necessários para aquele tipo.
- Preencha o endereço, as credenciais e o formato.
- Use o Teste de conexão para confirmar que está acessível.
- Salve.
2. Criar uma regra de roteamento
- Vá a Roteia → Rotas e inicie uma nova regra.
- Dê um nome claro (por exemplo, "Sophos crítico para Sentinel").
- Defina a prioridade.
- Defina a condição (por exemplo, eventos do Sophos com severidade alta).
- Escolha os destinos.
- Marque como regra final se ela for exclusiva.
- Salve.
3. Conferir a saúde
- Vá a Visão geral → Saúde do pipeline para ver o status de cada destino.
- Para detalhes de um destino específico (vazão, fila, erros recentes), abra-o em Roteia → Destinos.
O que acontece quando um evento é processado
Em linguagem de produto, sem detalhes técnicos:
- Coleta — o coletor busca o evento na ferramenta de origem.
- Normalização — o evento é convertido para o formato padrão e ganha os metadados internos que o roteamento usa.
- Roteamento — as regras são avaliadas por prioridade e definem para quais destinos o evento vai e qual redação aplicar a cada um.
- Entrega — para cada destino, o evento é agrupado em lote, formatado no formato daquele destino e enviado em segundo plano, com novas tentativas em caso de falha temporária.
- Resultado — eventos aceitos aparecem na vazão do destino; eventos rejeitados vão para a fila de reenvio e ficam visíveis em Normaliza → Quarentena.
Casos de uso detalhados
Tiering econômico
- Alertas críticos (severidade alta) vão para o SIEM (Sentinel), com retenção curta e dados mascarados.
- Eventos verbosos (atividade de arquivo, fluxo de rede) vão para o data lake (S3), com retenção longa e dados íntegros.
- Todo o resto vai para o Wazuh padrão, como garantia.
Resultado: você reduz o gasto com o SIEM caro e mantém tudo retido no armazenamento barato.
Migração gradual de SIEM
- Comece enviando uma fração pequena dos eventos ao novo SIEM (por exemplo, 10%), mantendo o restante no destino atual.
- Acompanhe a saúde do novo destino e aumente a fração aos poucos.
- Quando estiver confiante, corte 100% para o novo destino.
Tudo isso é feito ajustando o percentual gradual da regra — sem refazer a configuração. Veja Roteamento gradual (canary).
Isolamento por cliente (MSSP)
- Cada cliente tem seu próprio destino, com as próprias credenciais.
- Um cliente nunca vê os destinos ou as regras de outro.
Resolução de problemas
O evento não chega ao destino
- Em Roteia → Rotas, revise a condição da regra — ela realmente bate com o evento que você espera?
- Em Roteia → Destinos, abra o destino e use o Teste de conexão.
- Em Visão geral → Saúde do pipeline, verifique se o destino está com a fila acumulando.
- Em Normaliza → Quarentena, veja se o evento foi retido e por quê.
A fila do destino está crescendo
A fila cresce quando a entrega está mais lenta do que a chegada de eventos.
- Abra o destino em Roteia → Destinos e veja o tamanho da fila na aba de saúde.
- Aumente os envios simultâneos na configuração de entrega do destino, dentro do que o destino consegue aguentar.
- Verifique se o destino está respondendo: use o Teste de conexão no próprio destino para conferir se ele está acessível e respondendo rápido.
A fila de reenvio está crescendo
Muitos eventos estão sendo rejeitados.
- Em Roteia → Destinos, abra o destino e veja a fila de reenvio, agrupada por tipo de erro. (A Quarentena é outra coisa: ela guarda falhas de normalização, não rejeição de destino, e não tem filtro por destino.)
- Se os eventos forem grandes demais, corte o payload bruto no mapeamento (bloco
raw_reduction) ou ligue Descartar o evento bruto na regra daquele destino. Vale só para eventos novos — o que já está na fila não encolhe ao ser reprocessado. Não recorra à redação de PII para isso — ver Redução de volume e custo. - Se for falha de credencial, use o Teste de conexão do destino e atualize a credencial.
Próximos passos
- Catálogo de Destinos — todos os tipos e seus campos.
- Destino Wazuh — configurar o destino padrão.
- Splunk HEC — configurar o Splunk.
- Guia de Roteamento — montar regras de roteamento.
- Redação de PII — esconder dados sensíveis por regra.
- Observabilidade — acompanhar a saúde da entrega.
- Normalização — como os eventos são padronizados.