Segurança do Sentrya Connector

O Sentrya Connector foi desenhado para passar pela revisão da equipe de segurança da sua empresa: nenhuma porta aberta, a credencial do Zabbix guardada só na sua rede, uma lista fechada do que ele pode fazer no Zabbix e registro local de cada chamada.

A conexão

Só de saída. O Connector abre uma conexão HTTPS (porta 443) para connector.flowbix.com e o Sentrya responde por ela. Nenhuma porta de entrada, nenhum redirecionamento, nenhuma VPN.
Autenticação dos dois lados. Cada conector gera, na própria máquina, uma chave Ed25519 que nunca sai dela. A cada conexão, o Sentrya prova a identidade dele assinando um desafio com uma chave cuja parte pública vem embutida no programa, e o Connector prova a dele assinando com a própria chave. Um servidor falso não consegue se passar pelo Sentrya. Se a sua rede usa um proxy com inspeção TLS e você apontou a CA dele em sentrya.ca_file, esse proxy enxerga o conteúdo da conexão, como em qualquer HTTPS que ele inspeciona; se a política permitir, libere connector.flowbix.com da inspeção.
Isolamento entre empresas. Cada conector pertence a uma empresa. O Sentrya só usa um conector para a empresa dona dele.
Revogação em segundos. Um conector revogado (pela desinstalação, pela Flowbix ou pela exclusão da empresa) é desconectado em segundos, no máximo em 1 minuto, e não consegue voltar. Se a empresa for suspensa, o conector é desconectado e só volta quando a empresa for reativada.

As credenciais do Zabbix

O token ou a senha do Zabbix ficam só na máquina do Connector, em /etc/sentrya-connector/secrets/ (permissão 0640, dono root, grupo do serviço). Eles nunca são enviados ao Sentrya.
O instalador testa a credencial antes de gravar; se algo falhar, nada é gravado.
Recomendamos um usuário dedicado, só de leitura, com um papel restrito à API: veja Preparar o usuário no Zabbix.
Os tokens de API das pessoas da sua equipe, criados quando cada uma vincula a conta ao próprio usuário do Zabbix, também ficam só na máquina do Connector. Veja Tokens de API das pessoas, abaixo.
Duas passagens pelo Sentrya, para você saber: no Vínculo com o Zabbix por usuário e senha, a senha que a pessoa digita no Sentrya passa por ele uma vez, até o Connector, para virar um token, e não é guardada. E, ao passar um servidor da conexão direta para o Connector, a credencial que o Sentrya guardava (cifrada) deixa de ser usada na hora e é apagada na primeira coleta bem-sucedida pelo Connector.

O que o Connector pode fazer no Zabbix

O Connector só executa estes 19 métodos da API do Zabbix e recusa todo o resto, mesmo que o Sentrya peça:

Tipo	Métodos
Leitura	`apiinfo.version`, `host.get`, `hostgroup.get`, `problem.get`, `trigger.get`, `event.get`, `item.get`, `user.get`, `usergroup.get`
Autenticação	`user.login` (quando a credencial é usuário e senha, e para trocar a senha de uma pessoa por um token), `user.logout` (só para encerrar essa sessão da pessoa), `user.checkAuthentication` (só para conferir o token guardado de uma pessoa)
ACK	`event.acknowledge` — só se você permitiu no assistente; com somente leitura, é recusado. Mesmo permitido, só passam as ações que o Sentrya usa: reconhecer, comentar, mudar a severidade e fechar, até 500 eventos por pedido. Suprimir, desfazer o reconhecimento e qualquer outro parâmetro são recusados sem tocar o Zabbix.
Tokens de API das pessoas	`token.create`, `token.generate`, `token.delete` e `token.get` — só com `allow_user_tokens` ligado (padrão). Criar, gerar e apagar valem só para tokens com o nome `Sentrya · …`; o `token.get` nunca devolve o token em si. Veja abaixo.
Histórico do item e minigráficos	`history.get` e `trend.get` — só com `allow_history` ligado (padrão). O Connector confere os parâmetros antes de chamar o Zabbix: de 1 a 10 itens no bruto e de 1 a 100 nas médias por hora (os minigráficos do Explorar pedem uma página de itens de uma vez), só itens numéricos (texto e log nunca), início da janela obrigatório, no máximo 20.000 amostras, janela de até 7 dias no bruto e até 400 dias nas médias por hora. Também limita a vazão na própria máquina: no máximo 2 leituras de histórico ao mesmo tempo e 60 por minuto em cada Zabbix. Fora disso, recusa sem tocar o Zabbix.

Guarda de leitura

Nas leituras de objetos (host.get, item.get, trigger.get, hostgroup.get, problem.get, event.get, user.get, usergroup.get e token.get), o Connector confere cada parâmetro e cada campo pedido antes de chamar o Zabbix. Mesmo que o servidor do Sentrya fosse comprometido, estas consultas são recusadas sem tocar o Zabbix:

pedir todos os campos (output: extend) ou deixar de dizer quais campos quer;
pedir, filtrar, buscar ou ordenar por um campo de credencial ou de configuração sensível: usuário, senha, parâmetros (scripts e SQL), cabeçalhos, chaves e senhas de certificado, community e senhas do SNMP (os "detalhes" das interfaces), usuário e senha de IPMI, chaves PSK;
pedir macros, inventário, pré-processamento, regras de descoberta ou templates;
pedir dos usuários do Zabbix a senha, as mídias (e-mail, telefone) ou os tipos de mídia (tokens de webhook e SMTP), ou pedir os usuários de um grupo. Dos usuários passam só o login, o nome, o tipo, o papel e os grupos de cada um: o espelho de permissões precisa deles;
pedir o valor de um token de API: dos tokens passam só o id, o nome, a descrição, o dono, o estado e as datas;
pedir mais de 10.000 linhas de uma vez: o limit vai até 10.000 e, numa consulta sem limit, o Connector põe ele mesmo o teto e recusa a resposta que passaria disso. Só a consulta por uma lista de ids (de hosts, itens, triggers, eventos, grupos, usuários ou tokens) fica sem esse teto, porque a própria lista limita a resposta. As médias por hora (trend.get) sem limite de linhas também são recusadas;

A recusa aparece na auditoria local com o motivo. As consultas que o Sentrya faz hoje (coleta, ouvintes, ACK, histórico, Explorar, entrada da equipe, vínculo com o Zabbix e as permissões do Zabbix de cada pessoa vinculada) estão todas dentro da lista: veja O que o Sentrya lê do seu Zabbix. O Connector também não deixa sair valor de item de log: no item.get, o último valor e o anterior de itens de log, binários ou de tipo desconhecido vão vazios, e o histórico só lê itens numéricos. Valores de itens de texto passam, e o Sentrya só os pede quando o administrador liga Mostrar valores de texto no Explorar. O nome de um problema, os dados operacionais e a descrição de uma trigger são textos que o próprio Zabbix monta: se a trigger usa uma macro como {ITEM.VALUE} nesses textos, o valor vem dentro deles. Um conector de versão anterior pode recusar as leituras de Usar permissões do Zabbix: o cartão Permissões e vínculo mostra "O Sentrya Connector não deixou ler as permissões: atualize o conector." e quem está vinculado fica com o acesso inicial, ou com o que foi lido por último.

Ele só fala com os Zabbix configurados nele. Não serve de ponte para outras máquinas ou serviços da sua rede.

Tokens de API das pessoas

Quando alguém da sua equipe faz o Vínculo com o Zabbix, os reconhecimentos (ACK) dessa pessoa passam a sair no nome dela, com um token de API do usuário dela. Num servidor ligado pelo Connector, esse token mora no Connector, como a credencial do Zabbix: o Sentrya pede pela conexão, e o Connector cria, guarda, usa e apaga o token. O Sentrya nunca vê o token: ele guarda só quem é a pessoa no Zabbix, o identificador do token e quando ele vence.

Guardado cifrado, só nesta máquina. Os tokens ficam em /var/lib/sentrya-connector/user-tokens.enc, cifrados (AES-256-GCM), com a chave em user-tokens.key, os dois com permissão 0600. Cada token fica preso a este conector e ao endereço do Zabbix em que foi criado: registrar o conector de novo descarta os tokens, e trocar o endereço do Zabbix faz o conector deixar de usá-los. Perder os dois arquivos só obriga as pessoas a vincular de novo.
Guarda que não abre = tokens desligados. Se a chave ou o arquivo dos tokens estiver com permissão mais aberta que 0600, se o arquivo estiver sem a chave ou se a chave não for a dele, o Connector não abre a guarda e avisa o Sentrya que os tokens de pessoa estão desligados em todos os Zabbix, seja qual for o allow_user_tokens. O Sentrya mostra os mesmos avisos dos tokens desligados, e os reconhecimentos saem com a credencial do Connector, com o nome da pessoa no fim da mensagem. O sudo sentrya-connector doctor avisa, e o log do serviço diz o motivo. Depois de corrigir, reinicie o serviço (sudo systemctl restart sentrya-connector): recarregar não reabre a guarda.
Usado só pela própria pessoa. O token de uma pessoa só entra no reconhecimento dela e na conferência do vínculo dela. Qualquer outro uso é recusado.
Só tokens do Sentrya. O Connector só cria tokens com o nome Sentrya · <nome da pessoa>, para o usuário da pessoa do pedido. Antes de gerar, confere que o token é do Sentrya e dessa pessoa; antes de apagar, confere que todos os tokens do pedido têm esse nome: um token que não é do Sentrya nunca é apagado.
Nem na auditoria. O token não aparece na auditoria local, no estado, nos logs nem no pacote de suporte. sentrya-connector status e o doctor mostram só quantos tokens estão guardados e quando vencem, nunca de quem nem o valor.
Token colado não é oferecido. Nos servidores ligados pelo Connector, o Sentrya não oferece a opção de colar um token de API, porque ele passaria pelo Sentrya. A pessoa vincula com usuário e senha, trocados na hora por um token gerado aqui, ou pelo vínculo pelo Microsoft 365.
Renovado e apagado por aqui. O Sentrya renova cada token 30 dias antes de vencer e apaga do Zabbix os tokens que criou quando a pessoa desvincula, toca em Não sou eu, é desativada ou excluída, e quando o servidor é removido. Os pedidos passam pelo Connector, com a credencial dele, e a cópia guardada aqui some junto. Se o usuário do Connector não é Super admin, o Connector ainda apaga a cópia na hora, e o token deixa de servir, mas o token continua no Zabbix e aparece em Tokens a apagar no Zabbix, com o motivo "o usuário da coleta não é Super admin". Na renovação e quando a pessoa vincula de novo, o token anterior fica de reserva no Connector por até 15 minutos, até o Sentrya confirmar a troca: se a troca falhar, o token que funcionava continua valendo. O que não puder ser apagado aparece para o administrador em Tokens a apagar no Zabbix.

Se o Connector deixa de ter o token de uma pessoa (foi registrado de novo, ou o endereço do Zabbix mudou na configuração dele), o vínculo dela passa a Com problema no Sentrya com "o Sentrya Connector não tem mais o seu token de API (o conector foi registrado de novo ou o endereço do Zabbix mudou nele); vincule de novo", e os reconhecimentos dela saem com a credencial do Connector, com o nome dela no fim da mensagem (ou ficam bloqueados, se a empresa exige vínculo para reconhecer ou usa as permissões do Zabbix nesse servidor), até ela vincular de novo.

Desligar os tokens de pessoa

A chave local allow_user_tokens de cada Zabbix vem ligada, como o ACK. Para desligar, acrescente allow_user_tokens: false ao servidor em /etc/sentrya-connector/connector.yaml (no Docker, ZABBIX_ALLOW_USER_TOKENS=false; ao adicionar pelo terminal, zabbix add --no-user-tokens) e recarregue o serviço (sudo systemctl reload sentrya-connector). Desligada, o Connector recusa, sem tocar o Zabbix, os métodos de token, a conferência do vínculo e todo uso do token de uma pessoa. A coleta, as leituras e o ACK com a credencial do Connector continuam.

Os reconhecimentos de todos saem com a credencial do Connector, com o nome da pessoa no fim da mensagem ("— Fulano Silva, via Sentrya"). Os vínculos não são desfeitos: se a chave for religada, os reconhecimentos voltam a sair no nome de cada pessoa.
O vínculo automático pelo Microsoft 365 fica indisponível nesse servidor, e o cartão Permissões e vínculo do administrador avisa (num Zabbix anterior à 5.4, vale antes o aviso de que o Zabbix não tem tokens de API): "Os tokens de pessoa estão desligados no Sentrya Connector deste servidor (allow_user_tokens). Ligue na máquina do conector para o vínculo automático e para os reconhecimentos saírem no nome de cada pessoa; até lá, saem com o usuário da coleta."
Os tokens já guardados ficam no disco sem uso. O Sentrya não consegue apagá-los no Zabbix enquanto a chave estiver desligada: os que ele precisar apagar aparecem em Tokens a apagar no Zabbix. Para apagar todos, use a lista de tokens de API do Zabbix, pelo nome Sentrya · .

Para criar o token de outra pessoa, o usuário do Connector precisa ser Super admin. Sem Super admin, só funciona o vínculo com a senha da própria pessoa, quando o papel dela no Zabbix deixa criar token; o vínculo pelo Microsoft 365, a renovação e o apagar do token no Zabbix, não (o Connector ainda apaga a cópia que guarda). O sudo sentrya-connector doctor confere e avisa, em "tokens de pessoa". Veja Dar Super admin ao usuário da coleta.

Conectores de versões anteriores não guardam tokens de pessoa. Nesses servidores, os reconhecimentos continuam saindo com a credencial do Connector, com o nome da pessoa no fim da mensagem, e o Sentrya avisa que o conector precisa ser atualizado. Veja Atualizações.

O que sai da sua rede

Dado	Quando
Respostas das chamadas acima (problemas, triggers, nomes de hosts e grupos, eventos)	Quando o Sentrya coleta ou monta um ouvinte — os mesmos dados que um Zabbix conectado diretamente entregaria.
Hosts, interfaces, itens com o último valor e triggers, com os campos listados em O que o Sentrya lê do seu Zabbix	Só quando alguém abre o Explorar no app. Nada disso é gravado: fica no máximo alguns minutos na memória do serviço.
Valores de um item numérico da trigger (horário e valor, ou as médias por hora)	Só quando alguém abre o histórico daquele incidente no Sentrya. O Sentrya não guarda esses valores: eles ficam no máximo 30 minutos na memória do serviço de histórico.
Um resumo de cada Zabbix: apelido, endereço, versão, se está alcançável, número de hosts, se o ACK, o histórico e os tokens de pessoa estão ligados e o tipo de credencial (token ou usuário e senha)	Ao conectar e quando a configuração muda. É o que aparece para a equipe Flowbix e na sua lista de servidores.
Dados da máquina: nome, sistema, arquitetura, versão do Connector e a política de atualização	Ao registrar e ao conectar.

Nunca saem: a credencial do Zabbix, os tokens de API das pessoas, a chave privada do conector e o conteúdo da auditoria local.

Auditoria local

Cada chamada que passa pelo Connector fica registrada na máquina (método, horário, tempo, tamanho e resultado), sem parâmetros nem respostas. No histórico do item, a linha também diz quantos itens e qual janela foram pedidos, nunca os valores. Veja com sudo sentrya-connector logs --audit. Detalhes em Status, logs e diagnóstico.

O serviço na máquina

Roda com um usuário próprio (sentrya-connector), sem shell e sem privilégios de root.
O systemd restringe o processo: sem capabilities, sistema de arquivos somente leitura (exceto o diretório de estado), sem acesso às pastas pessoais, rede restrita a IPv4/IPv6 e aos sockets locais do sistema, memória limitada a 256 MB.
Só o atualizador roda como root, e só para instalar pacotes assinados pelo gerenciador de pacotes da máquina.

Pacotes e atualizações assinados

O repositório de pacotes (apt/dnf) é assinado com GPG; a chave pública é instalada pelo instalador, e o apt/dnf confere essa assinatura na instalação.
Cada versão tem um manifesto assinado com Ed25519, com o tamanho e o hash SHA-256 de cada arquivo. Para atualizar, o atualizador confere a assinatura do manifesto, baixa o pacote, confere o tamanho e o hash dele contra o manifesto antes de instalar e só então instala esse arquivo. Depois, compara o programa instalado com o hash do manifesto. Se não bater, ou se a versão nova não ficar saudável, ele volta sozinho para a anterior.
O atualizador não instala versão abaixo do piso de segurança: o maior entre o piso de volta assinado no manifesto da versão instalada e o piso que vem no próprio programa. E o Sentrya tem um piso de segurança da frota, que nenhuma ação no painel baixa: ele nunca indica versão abaixo desse piso, e um Connector abaixo dele não conecta.