Monte seu próprio SOC Wazuh, ou implante um que já vem pronto

O que você precisa construir

O Wazuh padrão entrega um manager, um indexer e um agente. Tudo acima disso é o projeto: managers e indexers por cliente, um plano de controle para provisioná-los, isolamento de tenants no nível do banco, política de rede, o encanamento de registro de agentes, um fluxo de triagem e ferramentas de atualização. Cada peça é viável por si só; integrar todas, e mantê-las integradas conforme os clientes chegam, é para onde vão os meses de engenharia. Acrescente uma camada de triagem por IA e você também passa a cuidar de prompts, orquestração de ferramentas contra o Wazuh e suas fontes de enriquecimento, guardrails para o modelo não fechar o que não deveria, orçamentos de tokens e um fluxo de revisão em volta de tudo isso.

SocTalk entrega essas peças montadas: um plano de controle rodando pilhas Wazuh por cliente em namespaces Kubernetes isolados, com o pipeline de triagem e a fila de revisão incluídos. Um funil determinístico de deduplicação, coalescência e correlação resolve muitos alertas antes de qualquer chamada a modelo, toda escalação passa por revisão humana sem modo de aprovação automática, e o LLM é escolha sua por tenant, incluindo um Ollama totalmente local. Tudo é Apache 2.0, o chart tem como alvo Kubernetes 1.30+ padrão, e uma instalação de produção leva cerca de uma hora em um cluster preparado.

Isolamento de tenants

Multi-tenancy é a decisão de design a acertar cedo, e no caminho DIY cabe a você prová-la. Isso significa políticas de row-level security em toda tabela com escopo de tenant, identidade do tenant costurada em cada consulta e dashboard, política de rede e cotas de recursos por tenant, e uma suíte de testes demonstrando que consultas entre tenants de fato falham. Os scripts de provisionamento que você escreve para o cliente três ainda precisam funcionar para o cliente trinta.

SocTalk aplica FORCE ROW LEVEL SECURITY em toda tabela Postgres com escopo de tenant, com sete testes de isolamento que precisam passar no CI. Cada cliente recebe um manager e um indexer Wazuh dedicados no seu próprio namespace, com Cilium NetworkPolicy, ResourceQuota e segredos de registro de agentes com escopo de tenant. A pilha é testada até ~50 tenants em um cluster de 3 nós; planeje cerca de 6 a 8 GB de RAM e 1.5 vCPU por tenant persistente.

Onboarding e atualizações

Em uma pilha caseira, cada novo cliente é um runbook: subir a instância Wazuh dele, configurar DNS e segredos de registro, montar os dashboards e conectar tudo de volta à ferramenta central que você tiver escrito. As atualizações se multiplicam do mesmo jeito. Saltos de versão do Wazuh vezes o número de clientes, migrações de schema, rotação de certificados e ciclo de vida do Kubernetes somam tempo recorrente de engenharia que cresce a cada tenant.

SocTalk faz o onboarding a partir do plano de controle. O provisionamento executa nove fases ordenadas com retry idempotente, criando o namespace, as cotas, a pilha Wazuh e o endpoint de registro, e os agentes se registram por ingress roteado por hostname com segredos de escopo de tenant. A configuração de DNS e de load balancer por tenant ainda é manual na V1, e um perfil 'provided' conecta um Wazuh que você já opera. Os dois charts atualizam via helm upgrade com migrações de banco aplicadas automaticamente, embora atualizações de toda a frota hoje sejam um loop manual documentado sobre os namespaces dos tenants; uma API de atualização de frota está no roadmap, não entregue.

Quanto custa

Taxas de licença são zero nos dois caminhos. Wazuh é open source, e SocTalk é Apache 2.0 sem divisão entre community e enterprise e sem recursos bloqueados. A diferença é onde o gasto cai. Uma construção DIY custa meses de engenharia adiantados mais o tempo contínuo para mantê-la rodando, uma troca razoável se a plataforma é onde você quer sua equipe. Com SocTalk você paga pela sua própria infraestrutura e por tokens de LLM, na ordem de $9 por dia por tenant com 30 alertas por dia em uma configuração econômica, com alta variação, ou custo por token zero com um Ollama local.

Quando montar por conta própria faz sentido

SocTalk pressupõe um plano de dados Wazuh. O plano de dados do SocTalk é somente Wazuh hoje; outros SIEMs são adições viáveis à sua superfície de ferramentas, mas nenhum foi entregue. Uma operação centrada em Splunk ou Elastic é mais bem servida pelo seu próprio trabalho de integração.

Construa também se a plataforma SOC em si é o seu diferencial de produto. Lógica de correlação customizada, uma experiência de analista proprietária e fluxos que seus concorrentes não conseguem copiar, tudo isso pede que você seja dono de cada camada, e uma plataforma pronta ficaria principalmente no seu caminho.

Se estiver genuinamente em dúvida, o código-fonte está em github.com/soctalk/soctalk sob Apache 2.0. Leia as políticas de RLS, o modelo de rede e o pipeline de triagem antes de decidir. O pior caso é sair de lá com uma arquitetura de referência funcional para a sua própria construção.

O que você mantém em qualquer um dos caminhos

SocTalk roda no seu próprio Kubernetes, de uma máquina bare-metal a EKS, AKS ou GKE, air-gapped se você precisar, com a sua escolha de LLM por tenant, incluindo um totalmente local. Auto-hospedagem é uma constante nos dois caminhos. Você mantém sua infraestrutura e seus dados, e o relacionamento com o cliente nunca passa por um fornecedor.

É a pilha DIY com a montagem já feita, e a licença garante que o teto é o mesmo de construir você mesmo: tudo no repositório é Apache 2.0, não há edição enterprise retida, e se um dia você discordar do rumo do projeto, pode fazer um fork e continuar operando.