Boas práticas de segurança no Zabbix: Criptografia, macros secretas e permissões

Zabbix concentra informações extremamente sensíveis: credenciais de acesso a bancos de dados, roteadores, hipervisores e aplicações; métricas que revelam o comportamento interno da sua infraestrutura; e a capacidade de executar comandos remotos em servidores de produção. Um Zabbix mal configurado não é apenas um risco de monitoramento: é uma porta de entrada para o restante do seu ambiente.

Nesta guia, vamos abordar como reforçar a segurança do Zabbix trabalhando com três pilares que se complementam: a criptografia das comunicações, as macros secretas para proteger credenciais e o gerenciamento avançado de permissões. Os exemplos são baseados no Zabbix 7.0 LTS, mas se aplicam igualmente ao 6.0 LTS e às versões padrão mais recentes.

Por que a segurança é crítica no Zabbix

O argumento central é simples: Zabbix toca tudo o que monitora. A configuração armazena as credenciais usadas para acessar outros sistemas, os dados coletados podem conter informações confidenciais e, em muitas implementações, o agente está habilitado para executar comandos nos hosts de produção.

As vulnerabilidades mais frequentes em ambientes mal configurados costumam se repetir:

• Tráfego em texto simples: por padrão, as conexões entre o servidor, os proxies e os agentes não são criptografadas. Qualquer sniffer na rede pode ler as métricas e, inclusive, dados sensíveis que trafeguem nelas;
• Credenciais visíveis: as macros de usuário tradicionais podem ser lidas por administradores com acesso ao host por meio da aba Inherited and host macros, expondo senhas de bancos de dados, APIs ou dispositivos;
• Permissões muito amplas: é comum encontrar usuários com função de administrador “porque era mais fácil”, ou acessos de leitura/escrita em grupos de hosts que não lhes correspondem;
• Chaves de agente sem restrição: se chaves perigosas como run não forem limitadas, um usuário com acesso suficiente poderá executar comandos arbitrários nos servidores monitorados;
• Versões sem suporte: executar uma versão que já atingiu seu End of Life significa ficar sem patches de segurança.

A boa notícia é que o Zabbix inclui, nativamente, todas as ferramentas necessárias para fechar essas brechas. Vamos analisá-las uma por uma.

Criptografia no Zabbix

O Zabbix permite comunicações criptografadas com TLS (Transport Layer Security) v1.2 e v1.3 entre todos os seus componentes: servidor, proxy, agente, web service e os utilitários zabbix_sender e zabbix_get. Também permite criptografar a conexão entre o frontend / servidor e o banco de dados.

Um detalhe importante de design: cada daemon do Zabbix usa uma única porta tanto para conexões criptografadas quanto não criptografadas. Ou seja, adicionar criptografia não obriga a abrir novas portas no firewall, o que facilita uma migração gradual.

A criptografia utiliza uma biblioteca criptográfica (OpenSSL, GnuTLS ou mbedTLS) e oferece dois métodos: chave pré-compartilhada (PSK) e certificados.

Configuração de conexões seguras (TLS/SSL)

Dois parâmetros controlam o comportamento da criptografia em cada componente:

• TLSConnect: define como são realizadas as conexões de saída (unencrypted, psk ou cert). É usado, por exemplo, no agente para os checks ativos e no proxy ativo em direção ao servidor;
• TLSAccept: define quais conexões de entrada são aceitas. Permite vários valores separados por vírgula, algo útil durante uma migração (por exemplo unencrypted,psk).

Criptografia com PSK (chave pré-compartilhada)

A opção mais rápida de implementar. Consiste em dois valores: uma identidade e uma chave.

Importante: A identidade PSK trafega sem criptografia pela rede. Nunca coloque informações sensíveis nela. Use-a apenas como um nome descritivo, por exemplo PSK-Agente-001.

A chave é uma string hexadecimal de entre 32 e 512 dígitos (de 128 a 2048 bits). Ela é gerada com OpenSSL e o arquivo deve ficar legível unicamente pelo usuário zabbix:

# Gerar a chave PSK (256 bits) e salvá-la em um arquivo

openssl rand -hex 32 > /etc/zabbix/zabbix_agentd.psk

# Restringir o acesso ao arquivo

chown zabbix:zabbix /etc/zabbix/zabbix_agentd.psk

chmod 600 /etc/zabbix/zabbix_agentd.psk

No arquivo de configuração do agente (zabbix_agentd.conf ou zabbix_agent2.conf):

TLSConnect=psk

TLSAccept=psk

TLSPSKFile=/etc/zabbix/zabbix_agentd.psk

TLSPSKIdentity=PSK-Agente-001

Após reiniciar o agente, configure o mesmo par identidade/chave no frontend, em Data collection → Hosts → [host] → Encryption. Você pode validar a conexão criptografada com zabbix_get:

zabbix_get -s 127.0.0.1 -k "system.cpu.load[all,avg1]" \

--tls-connect=psk \

--tls-psk-identity="PSK-Agente-001" \

--tls-psk-file=/etc/zabbix/zabbix_agentd.psk

Criptografia com certificados

Mais robusta e escalável para ambientes grandes, porque permite gerenciar a confiança de forma centralizada e revogar credenciais. Alguns pontos importantes:

• O Zabbix não aceita certificados autoassinados: você precisa de uma Autoridade Certificadora (CA). Recomenda-se usar CAs intermediárias para assinar os certificados de cliente e servidor;
• Você pode restringir o emissor (issuer) e o assunto (subject) do certificado remoto, de modo que não seja suficiente possuir qualquer certificado assinado pela CA.

Configuração de exemplo no agente:

TLSConnect=cert

TLSAccept=cert

TLSCAFile=/etc/zabbix/certs/ca.crt

TLSCertFile=/etc/zabbix/certs/agent.crt

TLSKeyFile=/etc/zabbix/certs/agent.key

# Opcional, mas altamente recomendado em ambientes corporativos:

TLSServerCertIssuer=CN=CA Interna Monitoreo

TLSServerCertSubject=CN=zabbix-server

PSK vs. certificados: qual escolher?

Para uma estratégia de migração com downtime mínimo, configure primeiro TLSAccept=unencrypted,cert (ou psk), valide se a conexão criptografada funciona e, somente então, reforce para TLSAccept=cert para rejeitar todo o tráfego não criptografado.

Criptografia de dados: frontend e banco de dados

Além do tráfego entre os componentes, é recomendável proteger outras duas superfícies:

• Frontend (interface web): disponibilize-o sempre por meio de HTTPS, configurando TLS no servidor web (Nginx ou Apache). As credenciais dos usuários e os tokens de sessão nunca devem trafegar em texto simples.
• Banco de dados: criptografe a conexão entre o servidor / frontend e o banco de dados. Isso é especialmente relevante porque as macros do tipo “Secret text” são armazenadas no banco de dados: se um invasor obtiver um backup, poderá lê-las.

Macros secretas

As macros de usuário no Zabbix ({$MACRO}) são ideais para parametrizar templates e evitar a repetição de credenciais. O problema é que, em sua forma tradicional, seu valor fica visível para qualquer administrador com acesso ao host: basta abrir a aba Inherited and host macros para visualizar senhas em texto simples. Até mesmo algumas macros globais, acessíveis por padrão somente para Super admins, acabam aparecendo nessa aba no nível do host.

Para resolver isso, desde o Zabbix 5.0 existem as macros secretas, que ocultam o valor de modo que ele nunca seja exibido para quem não deve visualizá-lo.

O que são e como as macros são usadas no Zabbix

O Zabbix oferece duas modalidades para proteger valores sensíveis em macros de usuário:

Para criar uma macro secreta, no formulário de macros clique no botão no final do campo Value e selecione Secret text ou Vault secret.

É importante ter em mente algumas limitações das macros secretas:

• Não funcionam em URLs nem em campos como o proxy HTTP de um cenário web: elas são resolvidas como ****** e a operação falha.
• Não podem ser usadas em expressões de trigger;
• Não são utilizadas nos formulários de teste (test) nem são clonadas junto com a macro do host ou do template;
• Depois que o valor de uma macro Secret text é salvo, ele não pode mais ser visualizado. Para alterá-lo, passe o cursor sobre o campo e use Set new value (o valor anterior é apagado);
• Atenção: embora o valor esteja oculto na interface, ele pode ser revelado indiretamente se for usado em um item que o imprima (por exemplo, um echo em um script externo), porque o servidor conhece o valor real. Por isso, as macros secretas devem ser combinadas com a restrição de chaves perigosas.

Exemplos práticos para proteger credenciais

Caso 1 — Secret text. Crie uma macro de host ou de template {$DB_PASSWORD}, selecione o tipo Secret text e insira a senha. A partir desse momento, você poderá usá-la normalmente nos seus itens (por exemplo, em um item de monitoramento de banco de dados) e ninguém poderá ler seu valor pelo frontend. Lembre-se de criptografar a conexão com o banco de dados, já que o valor continua armazenado nele.

Caso 2 — Vault secret com HashiCorp Vault. O valor real fica no Vault e o Zabbix armazena apenas uma referência. Primeiro, crie o segredo no Vault:

# Habilitar o mecanismo de segredos kv-v2 (se não estiver habilitado)

vault secrets enable -path=secret/ kv-v2

# Armazenar a credencial

vault kv put secret/zabbix/database username=zabbix password=<contraseña>

# Verificar

vault kv get secret/zabbix/database

Em seguida, configure o servidor (zabbix_server.conf) para se autenticar no Vault:

Vault=HashiCorp

VaultToken=hvs.XXXXXXXXXXXXXXXXXXXXXXXX

VaultURL=https://127.0.0.1:8200

VaultDBPath=secret/zabbix/database

Por fim, na macro de usuário, selecione o tipo Vault secret e, como valor, indique a referência no formato caminho:chave, por exemplo:

secret/zabbix:password

O servidor (e o proxy, se estiver configurado para isso) recupera o valor do Vault a cada atualização da configuração e o mantém no cache. Algumas boas práticas com o Vault:

• Use tokens somente leitura e, preferencialmente, periodic service tokens renováveis, para um serviço de longa duração como o Zabbix.
• Utilize tokens diferentes para cada proxy.
• Habilite a criptografia entre servidor e proxy; caso contrário, o Zabbix registrará um aviso ao resolver macros do Vault.
• Você pode monitorar com o próprio Zabbix a data de expiração do token para se antecipar ao seu vencimento.

Gerenciamento avançado de permissões

O princípio que rege todo o modelo de permissões do Zabbix é claro: as permissões são baseadas em grupos, não em usuários individuais. Mesmo que apenas um usuário precise de acesso a um único host, esse acesso é concedido adicionando-o a um grupo de usuários e concedendo a esse grupo permissões sobre o grupo de hosts que contém o host.

Tipos de usuário e funções

É necessário distinguir dois conceitos que trabalham juntos:

Tipos de usuário (definem o escopo geral):

• User: acesso limitado às seções do menu e sem acesso a nenhum recurso por padrão. Toda permissão sobre grupos de hosts ou templates deve ser atribuída explicitamente;
• Admin: acesso incompleto ao menu e sem acesso a grupos de hosts por padrão; as permissões são concedidas explicitamente;
• Super admin: acesso a todas as seções e leitura/escrita sobre todos os grupos de hosts e templates. Suas permissões não podem ser revogadas negando grupos específicos.

Funções de usuário (desde o Zabbix 5.2): quatro funções pré-configuradas (User, Admin, Super admin e Guest) que refinam a quais seções da interface, módulos e métodos da API cada usuário tem acesso. Você pode criar funções personalizadas e desmarcar permissões específicas para ajustá-las a cada função. A função Super admin padrão não pode ser modificada nem excluída, porque deve existir sempre pelo menos um Super admin com privilégios ilimitados.

Como as permissões sobre os dados são calculadas

As permissões sobre os dados são atribuídas aos grupos de usuários nas abas Host permissions e Template permissions, com quatro níveis: Read-write, Read, Deny e None (este último “reseta” e remove o grupo da lista).

O nível efetivo depende da combinação entre o tipo de usuário e a permissão sobre o grupo de hosts:

Duas regras de precedência que vale a pena memorizar quando um usuário pertence a vários grupos:

1. Read-write tem prioridade sobre Read. Se um grupo concede leitura e outro concede leitura/escrita sobre o mesmo grupo de hosts, prevalece a leitura/escrita;
2. Deny é o mais restritivo. Se um host pertence a algum grupo negado para o usuário, o acesso é bloqueado mesmo que outro grupo conceda leitura/escrita.

O Zabbix também oferece suporte a grupos de hosts aninhados por meio da barra diagonal no nome (por exemplo, Europa/España/Madrid), o que facilita modelar hierarquias e aplicar (ou negar) permissões por ramo. E, por meio do filtro por tags (Problem tag filter), você pode separar o acesso a um grupo de hosts da capacidade de visualizar seus problemas: por exemplo, permitir que uma equipe veja apenas os problemas identificados com service: database.

Boas práticas para ambientes corporativos

• Privilégio mínimo: atribua a cada grupo apenas o acesso de que necessita. Evite a função Super admin, exceto para um pequeno grupo de administradores;
• Funções por atividade, não por pessoa: crie funções personalizadas (por exemplo, “Operador NOC”, “Engenheiro de rede”, “Somente leitura auditoria”) e atribua usuários a elas;
• Modele grupos de hosts de acordo com sua organização (por equipe, localização, criticidade) e aproveite o aninhamento para gerenciá-los em bloco;
• Use Deny com critéri: lembre-se de que ele prevalece sobre qualquer outra permissão; é ideal para excluir um subgrupo sensível dentro de um ramo ao qual, de modo geral, é concedido acesso;
• Restrinja a conta guest: ela fica desabilitada por padrão; mantenha-a assim, a menos que você tenha uma necessidade explícita;
• Limite as chaves do agente: com AllowKey e DenyKey na configuração do agente, você pode bloquear chaves perigosas (como run) e reduzir o risco de execução indesejada de comandos.

A segurança no Zabbix é uma estratégia de defesa em camadas

A segurança no Zabbix não depende de uma única função, mas da combinação de diferentes camadas de proteção que trabalham em conjunto. Para proteger o ambiente, é fundamental criptografar as comunicações entre o servidor, os proxies e os agentes por meio de TLS, além de disponibilizar o frontend via HTTPS e proteger as conexões com o banco de dados. As credenciais sensíveis devem ser armazenadas de forma segura, utilizando macros secretas ou Vault em vez de senhas em texto simples.

Também é importante proteger os arquivos que contêm chaves PSK e certificados por meio de permissões adequadas, aplicar o princípio do menor privilégio por meio de funções e permissões sobre grupos de hosts e restringir ou desabilitar a conta Guest. Nos agentes, as chaves potencialmente perigosas devem ser limitadas por meio de AllowKey e DenyKey, enquanto o parâmetro Server deve ser restrito aos IPs dos servidores ou proxies autorizados. Por fim, manter o Zabbix em uma versão com suporte e revisar periodicamente o audit log são práticas essenciais para manter um ambiente seguro e preparado para infraestruturas críticas.

Quer levar a segurança do seu ambiente Zabbix para o próximo nível?

Cada infraestrutura tem seus próprios desafios de segurança. Se você quiser avaliar a configuração do seu ambiente, aplicar as melhores práticas ou descobrir como o Zabbix pode ajudar você a construir uma infraestrutura de monitoramento mais segura, fale com nossa equipe de especialistas.

Entre em contato com a equipe do Zabbix e descubra como podemos ajudar.

Lucas Frade

Prev Post