Cloud Server para Wazuh: logs sem gargalo

Resposta direta

Um Cloud Server para Wazuh deve ser dimensionado pelo número de agentes, volume diário de eventos, tempo de retenção e nível de consulta esperado no dashboard. Para laboratório ou até 10 agentes leves, 2 vCPUs, 4 GB de RAM e 80 GB de SSD podem funcionar. Para uma pequena empresa com 25 a 50 agentes, o ponto mais seguro costuma ser 4 vCPUs, 8 a 16 GB de RAM e 200 a 500 GB de SSD ou NVMe. Em produção com retenção de 90 dias, auditoria e buscas frequentes, é melhor separar Wazuh Server, indexador e dashboard, ou usar ao menos 8 vCPUs, 32 GB de RAM e discos rápidos. O erro comum é calcular só CPU e esquecer que logs crescem todos os dias.

Resumo rápido

• Wazuh combina coleta de eventos, análise de segurança, alertas, regras, agentes e dashboard em uma pilha de SIEM self-hosted.
• O dimensionamento real depende de EPS, eventos por segundo, e não apenas do número de servidores monitorados.
• Para produção pequena, comece pensando em 4 vCPUs, 8 GB de RAM e pelo menos 200 GB de disco SSD.
• Retenção de logs costuma ser o fator que mais pesa no custo, principalmente quando há Windows Event Logs, Sysmon, firewalls e servidores web.
• NVMe ajuda em buscas, indexação e picos de ingestão, mas não corrige regras mal ajustadas nem retenção exagerada.
• Firewall, VPN, SSH com chave, TLS e backups testados são parte do projeto, não tarefas para depois.
• Se você já pesquisa observabilidade, compare também o caso de logs de aplicação em /vps-para-logs-centralizados-com-loki/, porque a lógica de retenção muda.

Pensar em Wazuh como apenas mais um serviço Linux é um atalho perigoso. Ele recebe eventos continuamente, indexa dados, aplica regras, gera alertas e mantém uma interface de consulta. Isso mistura características de banco de dados, ferramenta de segurança e plataforma de observabilidade. Um servidor que parece folgado no primeiro dia pode ficar lento após três semanas, quando os índices crescem e as consultas começam a disputar I/O com a ingestão.

A boa notícia é que dá para começar de forma controlada. Um laboratório pode rodar tudo em uma única instância. Uma operação pequena também pode usar nó único, desde que aceite limites claros de retenção, backup e disponibilidade. Já ambientes com compliance, investigação de incidentes e muitos endpoints precisam tratar Wazuh como infraestrutura crítica. Nesse cenário, o Cloud Server certo não é o mais barato nem o maior no papel, mas aquele que entrega previsibilidade de CPU, RAM, disco, rede, snapshot e recuperação.

Como o Wazuh funciona em um SIEM self-hosted

Wazuh é uma plataforma de segurança open source que combina agentes instalados em endpoints, um servidor central de análise, um indexador baseado em OpenSearch e um dashboard web. Em termos práticos, os agentes coletam eventos de Linux, Windows, macOS e alguns workloads específicos, enviam esses dados para o Wazuh Server, e o ambiente processa regras de detecção, integridade de arquivos, vulnerabilidades, auditoria de configuração e alertas. O dashboard permite investigar eventos, criar filtros e consultar dados históricos.

Componentes principais

Em uma instalação all-in-one, tudo roda no mesmo Cloud Server: Wazuh Manager, indexador, dashboard e serviços auxiliares. Essa abordagem é simples para prova de conceito, laboratório e empresas pequenas, mas concentra CPU, memória e disco em um único ponto. Um pico de logs do Windows, por exemplo, pode afetar a navegação no dashboard. Uma busca pesada por eventos dos últimos 30 dias pode disputar leitura de disco com a indexação em tempo real.

O Wazuh Manager cuida da comunicação com agentes, aplicação de regras e geração de alertas. O indexador grava e organiza os eventos para consulta. O dashboard consome esses dados e exige memória adicional, especialmente quando há vários usuários pesquisando ao mesmo tempo. Em um cenário com 30 servidores Linux gerando autenticações SSH, logs de sudo, Nginx, Docker e auditd, a carga é bem diferente de 30 estações Windows com eventos detalhados de segurança e Sysmon.

Quando separar serviços

A separação começa a fazer sentido quando o ambiente passa de laboratório para operação contínua. Uma configuração comum é manter Wazuh Manager em um servidor, indexador em outro e dashboard em um terceiro, ou usar ao menos indexador separado. Isso melhora previsibilidade e facilita manutenção. Se o indexador consumir muito I/O, o manager continua recebendo agentes. Se o dashboard precisar reiniciar, a coleta não para.

Para empresas que já usam monitoramento tradicional, vale separar mentalmente SIEM de disponibilidade. Zabbix, por exemplo, responde melhor a perguntas como CPU alta, serviço fora do ar e latência. Wazuh responde a perguntas como tentativa de login suspeita, arquivo sensível alterado, pacote vulnerável instalado e mudança de configuração. Se o objetivo inclui disponibilidade e segurança, leia também o material sobre /vps-para-zabbix-no-brasil/, porque as duas ferramentas se complementam, mas exigem perfis de carga diferentes.

Dimensionamento de CPU, RAM e rede para Wazuh

Dimensionar Cloud Server para Wazuh começa por três perguntas simples: quantos agentes vão enviar eventos, quais logs serão coletados e por quanto tempo os dados precisam ficar pesquisáveis. O número de agentes sozinho engana. Dez controladores de domínio ou servidores Windows com Sysmon podem gerar mais eventos do que cinquenta servidores Linux simples. Do mesmo modo, um firewall enviando logs de tráfego em alto volume pode dominar a ingestão.

Ponto de partida por volume de agentes

Para laboratório, 2 vCPUs e 4 GB de RAM são suficientes para aprender a ferramenta, conectar 3 a 10 agentes e testar regras. Nesse perfil, use retenção curta, algo como 7 a 14 dias, e evite habilitar coleta excessiva. Para uma pequena empresa com 20 a 50 agentes leves, 4 vCPUs e 8 GB de RAM são o mínimo razoável, mas 16 GB deixam margem para indexação, dashboard e atualizações. Se houver Windows Event Logs detalhados, servidores web movimentados ou auditoria de arquivos em muitos diretórios, planeje 8 vCPUs e 16 a 32 GB de RAM.

Um exemplo prático: uma empresa com 25 notebooks, 5 servidores Linux, 2 servidores Windows e 1 firewall pode começar em 4 vCPUs, 16 GB de RAM e 300 GB de SSD, desde que retenha dados por 30 dias e filtre ruído. Se a política exigir 90 dias pesquisáveis, o disco sobe rapidamente. Se o time de segurança consulta o dashboard diariamente durante investigações, CPU e memória também precisam crescer.

Rede, latência e ingestão de eventos

A rede costuma ser esquecida no orçamento. Agentes Wazuh se comunicam com o manager em portas específicas, e a estabilidade dessa conexão afeta a entrega de eventos. Para endpoints no Brasil, um datacenter nacional pode reduzir latência e melhorar consistência, principalmente em filiais com links medianos. Isso não significa que uma região fora do país seja inviável. Significa que você precisa medir RTT, perda de pacotes e throughput antes de colocar a coleta inteira em produção.

Use limites e filtros desde o piloto. Habilitar todos os logs de uma vez parece produtivo, mas cria ruído e aumenta custo. Comece por autenticação, alterações críticas, integridade de arquivos sensíveis, eventos de privilégio e vulnerabilidades. Depois adicione Sysmon, logs de aplicação e firewall com critério. Em Cloud Server, essa estratégia evita superdimensionar por medo e reduz o risco de descobrir tarde que a instância está ocupada processando eventos sem valor investigativo.

Disco, retenção de logs e custo operacional

O disco é o ponto que mais transforma um projeto Wazuh de barato em caro. CPU e RAM podem ficar estáveis por meses, mas logs crescem todos os dias. Se você coleta 5 GB por dia e retém 30 dias, já tem 150 GB brutos antes de considerar overhead de índice, réplicas, compressão, snapshots e margem operacional. Em ambientes reais, é prudente reservar 30% a 50% de folga para crescimento, manutenção e picos de incidentes.

Estimando consumo diário

A melhor estimativa vem de um piloto de 7 dias. Instale agentes em uma amostra representativa, por exemplo 5 estações Windows, 3 servidores Linux, 1 servidor web e 1 firewall. Meça o volume diário indexado e multiplique pelo ambiente completo. Se 10 ativos geram 2 GB por dia e a empresa tem 50 ativos semelhantes, a projeção simples aponta 10 GB por dia. Com 30 dias de retenção, isso sugere 300 GB úteis, mais overhead. Para 90 dias, passa de 900 GB com facilidade.

Retenção também deve ser dividida por valor. Nem todo evento precisa ficar quente e pesquisável no dashboard. Alertas críticos, autenticação, mudanças de privilégio e integridade de arquivos têm valor maior para investigação. Logs muito verbosos podem ir para armazenamento frio, exportação compactada ou retenção menor. Essa decisão precisa envolver segurança, jurídico e compliance quando houver exigência regulatória.

SSD, NVMe e snapshots

SSD é o mínimo aceitável para Wazuh em produção. NVMe pode melhorar indexação e busca, especialmente quando há muitos eventos por segundo ou consultas longas. Ainda assim, disco rápido não resolve retenção mal planejada. Um ambiente com 1 TB de dados e consultas amplas nos últimos 90 dias continuará exigindo memória, CPU e boas políticas de índice.

Snapshots ajudam em recuperação, mas não substituem backup lógico e teste de restauração. Antes de contratar, confirme se o provedor oferece snapshot manual, backup automatizado, custo por GB, janela de retenção e impacto no desempenho. Em provedores como DigitalOcean, Vultr, Linode, AWS Lightsail e opções brasileiras como LetsCloud, recursos de storage, região e backup variam por plano e localidade, então esses dados precisam ser revisados no site oficial antes da publicação de qualquer comparação de preço. Para Wazuh, procure também a capacidade de anexar volumes adicionais, porque migrar índices para outro disco é mais simples do que trocar toda a instância às pressas.

Implantação segura: firewall, agentes e acesso administrativo

Um SIEM exposto de forma descuidada vira um risco. O Wazuh centraliza eventos sensíveis, nomes de máquinas, usuários, IPs internos, tentativas de login, vulnerabilidades e trilhas de auditoria. Por isso, a implantação precisa começar por superfície mínima. O dashboard não deve ficar aberto para a internet sem controle forte. O ideal é restringir acesso por VPN, allowlist de IPs corporativos, autenticação forte e TLS válido. SSH deve usar chaves, bloqueio de senha e usuário administrativo separado.

Portas e exposição mínima

Em uma instalação típica, agentes precisam alcançar o Wazuh Manager nas portas usadas pela comunicação do agente, como 1514 para eventos e 1515 para registro, conforme a configuração adotada. O dashboard usa HTTPS, geralmente atrás de proxy reverso ou acesso restrito. O indexador não deve ser exposto publicamente. Em uma topologia mais segura, somente agentes e administradores autorizados chegam aos serviços necessários. Todo o resto é bloqueado no firewall do sistema e no firewall de borda do provedor.

Um exemplo simples para Linux é permitir SSH apenas do IP do escritório ou da VPN, liberar as portas dos agentes para redes conhecidas e bloquear acesso público ao indexador. Antes de aplicar regras, teste em console de emergência do provedor para evitar lockout. Se você ainda está desenhando essa camada, o guia de /vps-com-firewall-e-hardening-de-seguranca/ ajuda a organizar SSH, firewall, atualizações e redução de superfície em servidores expostos.

Boas práticas de hardening

Hardening não é uma etapa única. Comece com atualização do sistema, NTP correto, firewall ativo, fail2ban quando fizer sentido, SSH com chave, logs locais preservados e conta root protegida. No Wazuh, use certificados, senhas fortes, rotação de credenciais e revisão periódica de usuários do dashboard. Também vale separar contas de leitura, investigação e administração, para evitar que todo analista opere com privilégio máximo.

Nos agentes, padronize instalação por script ou ferramenta de automação. Ansible, scripts shell assinados internamente ou GPO em Windows reduzem erro manual. Documente qual grupo cada agente usa, quais regras estão habilitadas e quais diretórios entram no FIM, file integrity monitoring. Um erro comum é monitorar diretórios enormes, como uploads temporários ou caches de aplicação, gerando milhares de eventos inúteis. Segurança boa também filtra ruído.

Operação em produção: alertas, backup e troubleshooting

Depois que o Wazuh entra em produção, o trabalho muda de instalação para operação. O primeiro indicador a observar é se os agentes estão conectados e enviando eventos. Depois vêm fila de processamento, uso de CPU, memória livre, swap, latência de disco, crescimento dos índices e tempo de resposta do dashboard. Se a instância começa a usar swap com frequência, as buscas ficam lentas e a indexação pode atrasar. Se o disco passa de 80% de uso, o risco operacional sobe rápido.

O que monitorar no dia a dia

Defina um painel operacional fora do próprio Wazuh, ou pelo menos alertas externos, para saber quando o SIEM está saudável. Monitore CPU média em 5 minutos, memória disponível, IOPS, espaço em disco, status dos serviços, quantidade de agentes desconectados e volume diário indexado. Um bom gatilho inicial é alertar com 75% de disco, agir com 80% e tratar 90% como incidente. Para memória, investigue se o uso de swap passa de algumas centenas de MB de forma recorrente.

Backups precisam ser testados. Faça snapshot antes de upgrades e mantenha cópia de configurações, certificados, regras customizadas e dados necessários para reconstrução. Em ambientes menores, uma rotina semanal de snapshot mais backup diário de configuração pode ser suficiente. Em empresas com auditoria, defina RPO e RTO. Por exemplo, RPO de 24 horas e RTO de 4 horas indicam que a empresa aceita perder no máximo um dia de dados e precisa restaurar o SIEM em até quatro horas.

Falhas comuns e como investigar

Quando o dashboard fica lento, não aumente recursos antes de olhar causa. Verifique consultas muito amplas, retenção excessiva, índices grandes, heap do indexador, I/O do disco e regras que geram alertas demais. Quando agentes aparecem desconectados, valide DNS, firewall, horário do sistema, certificados e rota de rede. Diferença de horário quebra correlação e dificulta investigação, então NTP é requisito básico.

Outro problema frequente é ingestão explosiva após habilitar logs detalhados no Windows ou Sysmon sem filtros. Um único endpoint mal configurado pode gerar centenas de milhares de eventos por dia. Nesses casos, reduza a verbosidade, ajuste grupos de agentes e revise regras. SIEM bom não é aquele que guarda tudo sem critério. É aquele que preserva os eventos certos, pelo tempo certo, com busca rápida o suficiente para responder incidentes.

Tabela comparativa de perfis de Cloud Server

A tabela abaixo ajuda a transformar requisitos em uma primeira estimativa. Ela não substitui piloto, porque cada ambiente gera logs de forma diferente. Use como ponto de partida para conversa entre segurança, infraestrutura e gestão. Depois rode 7 a 14 dias de teste com uma amostra real, registre volume diário, ajuste filtros e só então feche o tamanho final do Cloud Server.

Perfil de uso	Agentes típicos	Recursos iniciais	Disco e retenção	Arquitetura sugerida	Observações operacionais
Laboratório técnico	3 a 10	2 vCPUs, 4 GB RAM	80 a 120 GB SSD, 7 a 14 dias	All-in-one	Bom para aprender regras, agentes e dashboard, sem promessa de alta disponibilidade
Pequena empresa	20 a 50	4 vCPUs, 8 a 16 GB RAM	200 a 500 GB SSD, 30 dias	All-in-one reforçado ou indexador separado	Exige filtro de eventos, backup testado e alerta de disco
Produção regulada	50 a 150	8 vCPUs, 32 GB RAM ou mais	1 TB ou mais, 60 a 90 dias	Manager, indexador e dashboard separados	Planejar snapshots, armazenamento frio, restauração e controle de acesso
Ambiente com muitos Windows	30 a 100	8 vCPUs, 16 a 32 GB RAM	500 GB a 2 TB SSD ou NVMe	Separar indexador quando possível	Sysmon e Event Logs podem elevar EPS rapidamente

Em provedores internacionais, como DigitalOcean, Vultr, Linode, AWS Lightsail, Google Cloud e Azure, a vantagem costuma estar na variedade de regiões, APIs e ecossistema. Em provedores com presença no Brasil ou foco local, a discussão passa por latência, cobrança, suporte e disponibilidade de datacenter. LetsCloud pode entrar na avaliação quando região brasileira, pagamento local ou operação próxima do público nacional fizerem diferença, mas recursos como NVMe, snapshots, backup e localidades precisam ser confirmados por plano antes de qualquer decisão editorial ou comercial.

Na prática, o perfil pequeno é onde mais acontecem erros. A empresa contrata um servidor enxuto, conecta todos os endpoints, ativa logs detalhados e descobre em duas semanas que a retenção real não cabe. O caminho mais seguro é começar com margem, medir ingestão e otimizar. Se o uso estabilizar abaixo do previsto, você pode reduzir retenção quente ou mover dados antigos. Se crescer, já terá métricas para justificar expansão.

Recomendações por perfil

Dev solo ou laboratório técnico

Para estudo, demonstração interna ou validação de regras, rode Wazuh em Cloud Server único com 2 vCPUs, 4 GB de RAM e 80 a 120 GB de SSD. Use poucos agentes, retenção curta e snapshots antes de mudanças grandes. Esse perfil serve para aprender registro de agentes, dashboard, FIM, detecção de vulnerabilidades e regras customizadas. Não trate esse laboratório como ambiente de auditoria. Se o servidor cair ou o disco lotar, o impacto deve ser aceitável. A melhor prática aqui é documentar tudo: versão instalada, portas liberadas, grupos de agentes, comandos usados e limites encontrados.

Time de TI em empresa pequena

Para uma empresa com 20 a 50 ativos, pense em 4 vCPUs, 8 a 16 GB de RAM e 200 a 500 GB de SSD. Comece com autenticação, eventos críticos, integridade de arquivos sensíveis e vulnerabilidades. Depois inclua logs mais verbosos apenas quando houver caso de uso claro. Mantenha backup de configuração, snapshot antes de upgrade e alerta de disco em 75%. Se o time também opera aplicações, bancos e servidores web, integre Wazuh ao processo de resposta a incidentes. O objetivo não é gerar centenas de alertas por dia, mas destacar eventos que alguém realmente consegue investigar.

Produção com retenção longa e auditoria

Ambientes com retenção de 60 a 90 dias, auditoria formal ou investigação frequente pedem arquitetura mais cuidadosa. Use pelo menos 8 vCPUs, 32 GB de RAM e 1 TB de disco rápido como referência inicial, mas valide com piloto. Sempre que possível, separe manager, indexador e dashboard. Defina política de retenção por tipo de evento, armazenamento frio para dados antigos e restauração testada. Controle acesso por VPN ou rede privada, use TLS, MFA quando disponível e contas separadas por função. Nesse perfil, a decisão de infraestrutura deve ser aprovada junto com segurança, compliance e continuidade de negócio.