Segurança do Zabbix

O que um atacante ganha comprometendo o monitoramento?

Segurança é ponta a ponta

Não coloque todos os componentes na mesma zona por conveniência

Banco deve aceitar conexão apenas de componentes necessários. Frontend não precisa estar exposto à Internet pública se o acesso administrativo puder ocorrer por VPN/ZTNA/rede corporativa.

Conta compartilhada destrói rastreabilidade

• uma identidade por operador;
• contas de serviço separadas de contas humanas;
• conta de API separada por integração relevante;
• desabilitar usuários que perderam necessidade de acesso;
• evitar uso cotidiano de Super admin;
• preservar conta de emergência controlada e auditada.

Zabbix suporta múltiplos modelos de autenticação

O Zabbix 7.4 suporta autenticação interna, HTTP/web server, LDAP, SAML e MFA. O método deve acompanhar o modelo de identidade da organização.

Administrador sem segundo fator é risco evitável

No Zabbix 7.4, MFA suporta TOTP e Duo Universal Prompt. Métodos podem ser associados aos grupos de usuários.

Role reduz o que um tipo de usuário pode fazer

Roles partem dos tipos User, Admin ou Super admin e permitem revogar permissões dentro do conjunto permitido pelo tipo. Elas não elevam um User além das capacidades de seu tipo.

Role responde “o que”; grupos ajudam a responder “onde”

NOC-L1
  role: leitura + acknowledge permitido
  hosts: produção/rede
  services: leitura

NOC-L2
  role: operações adicionais
  hosts: produção/rede

Engenharia-Zabbix
  role: configuração autorizada
  hosts: escopo técnico necessário

Evite dar acesso global quando a equipe precisa administrar apenas uma região, cliente ou plataforma.

Zabbix suporta TLS 1.2 e 1.3 conforme a biblioteca criptográfica

Comunicação criptografada pode ser configurada entre server, proxy, agent, web service, zabbix_sender e zabbix_get, além de conexões ao banco e entre frontend e server.

PSK é simples de implantar, mas precisa de lifecycle

Uma PSK possui identidade pública e valor secreto. A identidade não deve conter informação confidencial porque trafega sem criptografia. No Zabbix, o valor mínimo é 128 bits e é informado em hexadecimal.

# exemplo de parâmetros conceituais
TLSConnect=psk
TLSAccept=psk
TLSPSKIdentity=agent-pop-centro-01
TLSPSKFile=/etc/zabbix/agent.psk

Certificados escalam melhor quando existe PKI madura

Zabbix suporta certificados RSA em PEM assinados por CA pública ou interna. A verificação usa CA configurada e pode usar CRL. Também é possível restringir issuer e subject esperados.

TLSConnect=cert
TLSAccept=cert
TLSCAFile=/etc/zabbix/pki/ca.crt
TLSCertFile=/etc/zabbix/pki/agent.crt
TLSKeyFile=/etc/zabbix/pki/agent.key

A chave privada deve ser legível somente pelo usuário/processo necessário.

HTTPS é obrigatório em produção

O frontend é aplicação web e precisa dos controles tradicionais: TLS válido, headers de segurança compatíveis, patching do web server/PHP, sessão protegida, exposição mínima e autenticação forte.

• não publique painel administrativo diretamente na Internet sem necessidade;
• use reverse proxy/WAF conforme arquitetura;
• restrinja interfaces administrativas;
• mantenha PHP/web server suportados;
• não exponha páginas de diagnóstico ou arquivos de configuração.

Banco contém muito mais que gráficos

Além de history/trends, o banco armazena configuração e dados sensíveis. O usuário do Zabbix deve possuir somente os privilégios necessários e o banco não deve aceitar conexões de redes arbitrárias.

Agent roda dentro do ativo monitorado

O princípio de least privilege é crítico. A documentação oficial recomenda inclusive separar o usuário do Agent do usuário usado por Server/Proxy quando coexistem na mesma máquina, para impedir que o Agent acesse configurações sensíveis do Server/Proxy.

Restrinja quem pode consultar o Agent e tenha extremo cuidado com UserParameters, plugins e execução remota.

Proxy é extensão da zona de monitoramento

Um proxy remoto costuma possuir acesso a centenas ou milhares de ativos. Comprometê-lo pode abrir caminho para descoberta e movimentação na rede monitorada.

• SO mínimo;
• acesso administrativo restrito;
• TLS com server;
• banco local protegido;
• sem serviços desnecessários;
• logs centralizados.

API transforma privilégio em escala

Um token capaz de alterar hosts, actions, scripts ou usuários pode produzir impacto em massa. Use token dedicado, role mínima, expiração/rotação e logging.

Abrir API e Automação →

Monitorar rede também exige proteger a coleta

SNMPv1/v2c usam community e não oferecem o mesmo modelo de segurança do SNMPv3. Quando o equipamento e a operação permitirem, prefira SNMPv3 com autenticação e privacidade adequadas. Em qualquer versão, restrinja origem por ACL e rede de gerenciamento.

Automação operacional é uma superfície de execução

Scripts globais, remote commands, webhooks e integrações precisam de revisão de privilégio. A documentação de segurança alerta que até usuários não privilegiados podem obter certas informações via API; portanto, não coloque credenciais sensíveis dentro de scripts globais.

Segredo precisa de origem, owner, rotação e destino

Alteração administrativa precisa deixar evidência

Use Audit log e, quando possível, envie logs para plataforma externa. Eventos importantes incluem criação/alteração de usuários, roles, tokens, scripts, actions, media types, proxies, templates e mudanças de configuração.

Backup do Zabbix também é material sensível

Banco, configurações, certificados, PSKs, chaves privadas, arquivos do frontend e scripts podem conter informação crítica. Proteja backup com controle de acesso e teste restauração.

Esta página explica o modelo; a próxima executa o endurecimento

Para evitar duplicação editorial, esta página fica responsável por arquitetura, identidade, confiança, criptografia e riscos. A página de Hardening entra na implementação: SO, serviços, firewall, web server, banco, arquivos, Agent, Proxy, Server, headers, permissões e checklist de produção.

Falha depois de ativar segurança: diagnostique por camada

1. Identifique qual fluxo falhou: browser, frontend, server, proxy, agent, DB ou API.
2. Valide DNS, rota e porta.
3. Valide relógio/NTP — crítico para certificados, SSO e TOTP.
4. Valide CA, cadeia, issuer/subject e validade do certificado.
5. Para PSK, valide identity e arquivo/valor correto.
6. Confirme TLSConnect/TLSAccept dos dois lados.
7. Revise role, user group e host group.
8. Revise logs sem expor segredo.
9. Teste com a menor permissão necessária; não “resolva” dando Super admin.
10. Registre causa e atualize o baseline.

Baseline mínimo antes de produção

• frontend em HTTPS?
• acesso administrativo restrito?
• MFA habilitado para contas críticas?
• contas individuais, sem compartilhamento?
• roles e grupos seguem least privilege?
• Server/Proxy/Agent usam usuários de SO adequados?
• TLS entre componentes onde necessário?
• PSKs/certificados possuem lifecycle?
• SNMP restrito por ACL e versão adequada?
• API tokens separados por integração?
• scripts/actions revisados?
• banco isolado e com usuário mínimo?
• backups protegidos e restauráveis?
• Audit log revisado/centralizado?
• hardening documentado e testado?

Escopo versionado

Conteúdo alinhado ao Zabbix 7.4. Recursos de criptografia, autenticação, MFA, roles e controles devem ser novamente validados ao migrar de versão. A implementação prática continua na página Segurança e Hardening.

Linha Zabbix 7.4

Autenticação atual inclui interna, HTTP, LDAP, SAML e MFA; LDAP/SAML suportam JIT. Separe autenticação de autorização e aplique privilégio mínimo por role e grupo.