Segurança e hardening

O monitoramento é um ativo privilegiado

Uma plataforma Zabbix pode conhecer IPs, nomes, versões, interfaces, credenciais SNMP, tokens, contas de banco, topologia e estados operacionais. Dependendo das Actions e scripts, também pode executar operações remotas. Comprometer o monitoramento pode fornecer visibilidade e alcance sobre grande parte da infraestrutura.

Mapeie cada fronteira de confiança

Considere navegador→frontend, frontend→Server, Server→banco, Server↔Proxy, Server/Proxy↔Agent, API, SNMP, IPMI, SSH, webhooks e integrações. Cada caminho possui autenticação, criptografia, origem permitida e privilégio próprios. Hardening eficiente começa pelo diagrama de fluxos, não por uma lista genérica de portas.

Server e banco não deveriam estar expostos como serviços comuns

Posicione componentes centrais em redes administrativas controladas. Libere somente os fluxos necessários entre Server, Proxy, banco, frontend e destinos monitorados. Um Proxy em rede remota pode reduzir a necessidade de abrir milhares de origens diretamente para o Server.

Criptografia deve proteger enlaces relevantes

O Zabbix suporta TLS entre componentes, com autenticação baseada em certificados ou PSK conforme o componente e o fluxo. Em 7.4, também é possível proteger por TLS a comunicação entre frontend e Server. A escolha deve considerar escala, PKI, rotação e identidade necessária.

PSK é simples, mas continua sendo segredo

Uma PSK combina uma identidade pública e um valor secreto. A identidade não deve conter informação confidencial, pois não é secreta. O arquivo contendo o valor deve possuir permissões restritas ao usuário do processo Zabbix.

Reutilizar a mesma PSK em toda a frota aumenta blast radius

Mesmo quando operacionalmente conveniente, compartilhar um único segredo entre centenas de hosts amplia o impacto de vazamento. Prefira segmentar segredos por ativo ou domínio de confiança e mantenha processo de rotação.

X.509 adiciona identidade e governança por CA

Zabbix pode usar certificados RSA em PEM assinados por CA pública ou interna. A verificação usa CA configurada e pode incluir CRL. Certificados são especialmente úteis quando a organização já possui PKI e precisa controlar emissão, revogação e identidade de componentes.

Confiar na CA pode não ser granular o bastante

Além da validação da cadeia, parâmetros de issuer e subject permitem restringir o certificado aceito. Isso reduz a possibilidade de outro certificado válido da mesma CA ser aceito indevidamente para uma conexão específica.

Chave privada deve ser tratada como credencial

Arquivos de chave TLS devem ser legíveis somente pelo usuário necessário. Backup, distribuição e automação precisam preservar essa restrição. Um certificado público pode ser distribuído; a chave privada correspondente não.

Revogação precisa fazer parte da PKI

Certificado comprometido não deixa de ser válido apenas porque foi substituído. Quando a arquitetura utiliza CRL, mantenha a lista atualizada e valide o processo de revogação. PKI sem procedimento de revogação é governança incompleta.

O navegador deve falar HTTPS com o frontend

O frontend carrega credenciais, tokens, dashboards e dados operacionais. Publique-o via HTTPS, use certificado válido, protocolos modernos e configuração segura do web server. Redirecione HTTP para HTTPS quando aplicável e evite exposição administrativa desnecessária à Internet.

Zabbix 7.4 permite criptografar essa comunicação

No Zabbix 7.4, a comunicação entre frontend e Server pode usar TLS, controlada por parâmetros específicos do Server e configuração do frontend. Isso fecha um enlace que historicamente poderia permanecer em texto claro dentro da rede.

Restrinja quem pode iniciar a comunicação de frontend

Quando o desenho utiliza a proteção frontend→Server do 7.4, restrições de origem podem reduzir a superfície de acesso ao listener correspondente. A regra deve refletir endereços reais do frontend e alta disponibilidade, evitando ranges amplos por conveniência.

Criptografe o caminho até o banco quando ele atravessa rede não confiável

Zabbix suporta TLS para conexões ao banco em cenários suportados. Modos com verificação de CA e hostname oferecem garantia superior à criptografia sem autenticação completa. Além de TLS, use usuário dedicado e privilégios mínimos compatíveis com a operação.

Socket local reduz exposição de rede quando arquitetura permite

Quando frontend, Server e banco estão no mesmo host ou contexto apropriado, sockets locais podem evitar listener de banco exposto. Isso não substitui permissões do sistema operacional, isolamento e proteção dos arquivos de dados.

Senha em arquivo não deve ser a primeira opção

O Zabbix integra armazenamento de credenciais com HashiCorp Vault e CyberArk em áreas suportadas. Secret macros e credenciais de banco podem ser retiradas de arquivos convencionais conforme arquitetura e versão. Isso centraliza rotação e reduz cópias persistentes de segredo.

Macro secreta reduz exposição visual, não elimina governança

Secret user macros ocultam o valor na interface após armazenamento. Vault secret macros apontam para segredos externos. Ainda assim, quem pode alterar itens, scripts ou integrações precisa ser controlado, pois o valor pode ser consumido por funções autorizadas da plataforma.

Vault não é apenas “guardar senha em outro lugar”

Defina autenticação do Zabbix no cofre, escopo de leitura, disponibilidade, TLS, rotação e comportamento durante indisponibilidade do Vault. Em 7.4, Server e Proxy podem resolver secret vault macros independentemente, permitindo desenhos distribuídos mais adequados.

Permissão deve seguir função, não conveniência

Zabbix permite diferenciar acesso administrativo, ações no frontend, hosts por host group e métodos de API. Estruture grupos e roles para NOC, redes, servidores, aplicações, auditoria e administração, evitando distribuir Super Admin para resolver limitações de desenho.

Conta máxima deve ser rara

Super Admin possui poder amplo e deve ser reservado à administração da plataforma. Operadores cotidianos precisam somente das permissões necessárias. Quanto mais contas privilegiadas existem, maior a chance de erro, abuso ou comprometimento de credencial com impacto global.

Credencial padrão deve desaparecer imediatamente

Instalações novas possuem usuário administrativo predefinido. Troque a senha padrão no primeiro acesso e aplique política forte. Contas bootstrap são conhecidas publicamente e não devem permanecer com credenciais de fábrica.

Acesso anônimo precisa ser decisão explícita

O usuário guest existe no Zabbix e é desabilitado por padrão. Só habilite acesso anônimo quando houver necessidade clara e objetos especificamente autorizados. Dashboard público não justifica exposição acidental de inventário ou problemas internos.

Integre identidade quando isso melhora governança

Em organizações maduras, autenticação centralizada reduz contas locais órfãs e facilita desligamento. Mesmo com diretório ou SSO, mantenha estratégia controlada de acesso de emergência e teste-a periodicamente.

Proteja principalmente identidades privilegiadas

Quando o mecanismo de autenticação adotado permite MFA, priorize administradores e acessos remotos. MFA reduz risco de reutilização ou vazamento de senha, mas não substitui RBAC, proteção de sessão e controle de origem.

Token de API é credencial

A API pode autenticar usando API token ou token obtido por login. Prefira tokens dedicados a automações, vinculados a usuários/roles de menor privilégio. Não reutilize credencial humana de Super Admin em scripts de integração.

Todo token precisa de dono, escopo e expiração

Documente finalidade, responsável, origem, permissões e validade. Remova tokens sem uso. Rotacione quando houver suspeita de vazamento ou mudança de equipe. Segredo sem inventário inevitavelmente vira segredo eterno.

Não publique API administrativa sem necessidade

A API acompanha o frontend e deve receber as mesmas proteções de HTTPS, autenticação, reverse proxy, WAF quando apropriado e restrição de origem. Uma URL difícil de adivinhar não é controle de segurança.

Automação aumenta poder e risco

Remote commands, scripts e Actions podem transformar Zabbix em plano de execução. Use contas técnicas de menor privilégio, comandos permitidos explicitamente, revisão e auditoria. Não conceda shell irrestrito apenas para simplificar uma automação.

Passive checks exigem controle de origem

Quando agentes recebem conexões, limite servidores/proxies autorizados e proteja o transporte conforme o risco. Active checks podem reduzir conexões de entrada no host, mas também exigem identidade e configuração corretas.

Plugins ampliam capacidade e superfície

Plugins podem consultar bancos, APIs e serviços locais. Habilite apenas o necessário, proteja credenciais e revise custom query paths. Consultas customizadas são código operacional e devem ser versionadas, revisadas e limitadas.

Evite SNMPv2c quando segurança exigir autenticação forte

Community strings são segredos fracos e frequentemente reutilizados. Quando suportado pelos equipamentos e pela operação, SNMPv3 oferece autenticação e privacidade. Separe credenciais de leitura de qualquer capacidade de escrita e limite origem no equipamento.

Saída também é superfície de segurança

Webhooks carregam tokens e dados de incidentes para sistemas externos. Restrinja destinos, proteja segredos, minimize payload e valide quem pode editar media types. Uma integração comprometida pode exfiltrar dados sem tocar diretamente no Server.

Parâmetro vindo de evento não deve virar shell sem validação

Macros inseridas em comandos podem conter valores inesperados. Evite construir shell commands concatenando dados não confiáveis. Prefira argumentos restritos, scripts intermediários com validação e allowlists.

Hardening do Zabbix inclui Apache/Nginx/PHP

Desabilite módulos desnecessários, limite métodos e paths, mantenha PHP e servidor web atualizados, proteja arquivos de configuração e evite directory listing. O frontend pode estar atualizado enquanto a camada web permanece vulnerável.

Proteções do navegador complementam HTTPS

O Zabbix possui opções relacionadas a X-Frame-Options e iframe sandboxing. Cabeçalhos adicionais podem ser definidos no reverse proxy conforme compatibilidade. Aplique CSP e outras políticas somente após testar widgets, integrações e autenticação.

Protocolos permitidos precisam ser intencionais

O frontend possui validação de URI schemes. Reduza esquemas permitidos ao necessário para o ambiente. Quanto menor o conjunto de comportamentos aceitos, menor a superfície para links perigosos ou integrações inesperadas.

Daemon deve rodar sem root sempre que possível

Componentes Zabbix possuem opção para reduzir privilégios para usuário dedicado. Proteja diretórios de configuração, logs, sockets e chaves. SELinux/AppArmor, systemd hardening e firewall local podem adicionar camadas quando compatíveis e testados.

Versão suportada não significa “instalar e esquecer”

Acompanhe releases, correções e advisories do Zabbix e das dependências: banco, PHP, web server, OpenSSL/GnuTLS, sistema operacional e plugins. Defina janela de atualização e ambiente de homologação. Segurança da plataforma é uma cadeia de software.

Mudança administrativa precisa deixar evidência

Use o audit log para investigar alterações e ações relevantes. Centralize logs quando necessário e defina retenção compatível com investigação. Auditoria perde valor quando o mesmo administrador que executa mudanças pode apagar todas as evidências fora de qualquer controle.

Log seguro não deve vazar segredo

Evite debug permanente em produção. Durante troubleshooting, revise se payloads, tokens, URLs ou respostas sensíveis podem aparecer. Retorne o nível de log ao normal e proteja arquivos contra leitura por usuários não autorizados.

Backup do Zabbix contém informação sensível

Banco e arquivos de configuração podem conter inventário, hashes, macros, tokens e detalhes de infraestrutura. Criptografe backups quando necessário, limite acesso, teste restauração e aplique retenção. Backup abandonado em storage aberto pode ser mais fácil de roubar que o ambiente ativo.

Monitoramento e administração não precisam compartilhar a mesma conta

Contas de coleta devem ser read-only sempre que possível. Credencial usada para SSH de backup, API de automação ou configuração não deve ser reutilizada para simples monitoramento. Separar funções reduz blast radius.

Permita fluxos, não “a rede inteira”

Construa regras com origem, destino, porta e direção explícitos. Proxies e active agents podem simplificar ACLs em redes distribuídas. Documente exceções temporárias e remova-as depois do troubleshooting.

Exposição direta exige justificativa excepcional

Server, Proxy, Agent e banco não devem ser publicados indiscriminadamente. Quando acesso externo é necessário, prefira VPN, rede privada, bastion ou controles equivalentes. O frontend público precisa de hardening equivalente a qualquer aplicação administrativa crítica.

Rede interna não é prova de identidade

Mesmo dentro da LAN, autentique componentes, limite origens e criptografe enlaces sensíveis. Segmentação e identidade reduzem movimento lateral quando uma estação, filial ou servidor intermediário é comprometido.

Segurança que derruba monitoramento também é falha

Rotação de certificado, Vault, firewall e autenticação precisam ser testados com rollback. Um controle aplicado sem observar dependências pode cegar o NOC. Hardening deve reduzir risco mantendo disponibilidade operacional mensurável.

Proteja cada enlace separadamente

USUÁRIO
  │ HTTPS
  ▼
FRONTEND
  │ TLS (7.4)
  ▼
ZABBIX SERVER ─── TLS ─── DATABASE
  │
  ├── TLS/PSK/X.509 ── PROXY ── AGENTS / SNMP / HTTP
  │
  ├── API / WEBHOOKS ── SISTEMAS EXTERNOS
  │
  └── VAULT ── SEGREDOS

Pergunta para cada seta:
1. Quem inicia?
2. Quem pode responder?
3. Há autenticação?
4. Há criptografia?
5. Qual credencial?
6. Qual privilégio?
7. Como rotaciona?
8. Como audita?

Escolha pela governança do ambiente

Um modelo simples de menor privilégio

Automação não precisa ser Super Admin

INTEGRAÇÃO: inventário-cmdb

Usuário técnico:
svc_zabbix_cmdb

Role:
somente métodos de API necessários

Token:
dedicado à integração

Controles:
- HTTPS
- validade definida
- origem restrita quando possível
- segredo fora do código-fonte
- rotação documentada
- owner conhecido
- revogação ao desativar integração

NÃO:
Admin + senha dentro de script.py

Reduza cópias permanentes

PREFERÊNCIA ARQUITETURAL

1. Vault secret
   ↓
2. Secret macro
   ↓
3. Arquivo protegido no host
   ↓
4. Macro comum / configuração visível
   ↓
5. Credencial hardcoded em script/template  ← evitar

Objetivo:
segredo com owner + escopo + rotação + auditoria.

Controle por componente

Atalhos que criam risco estrutural

Endurecer um ambiente sem perder observabilidade

Baseline mínimo de segurança

Base factual

Conteúdo estruturado a partir da documentação oficial Zabbix 7.4 sobre criptografia TLS, PSK, certificados X.509, frontend, banco, usuários, permissões, API tokens, secret macros, HashiCorp Vault, CyberArk e recursos de segurança introduzidos no 7.4. O modelo de ameaça, arquitetura de confiança, matrizes, laboratórios e recomendações de hardening são síntese editorial própria.

Linha Zabbix 7.4

MFA suporta TOTP e Duo Universal Prompt. Zabbix 7.4 também suporta TLS entre frontend e Server; combine HTTPS, RBAC, MFA, TLS/PSK/certificados e gestão segura de segredos.