Ferramentas gratuitas de chamados como o GLPI sustentam operações de TI inteiras no Brasil, e funcionam bem. O risco não está na ferramenta: está em operar sem contrato, sem prazo de correção e sem ninguém responsável quando o sistema para num sábado ou quando aparece uma falha de segurança.
O GLPI é usado por milhares de equipes de TI no Brasil porque resolve o problema principal com custo zero de licenciamento: centraliza os chamados, organiza as filas e registra o histórico. Para uma equipe que está começando ou que tem restrições de orçamento, é uma escolha racional. O problema não é a ferramenta — é a camada de sustentação que fica descoberta quando ninguém tem contrato.
Esta entrada não propõe que você troque de ferramenta. Propõe cinco perguntas para saber qual é a sua exposição real. Se você conseguir responder todas com clareza, o ambiente está bem sustentado. Se alguma revelar um ponto cego, o momento de agir é antes da parada, não durante.
Atualização — 21 de outubro de 2026. Foram divulgadas duas falhas críticas no núcleo do PHP (CVE-2026-109618 e CVE-2026-109619, gravidade 9.2 de 10) que permitem executar código no servidor a partir de uma única requisição, sem nenhuma credencial. A falha é do PHP, não do GLPI: atinge qualquer aplicação web executada sobre ele. As correções saíram no mesmo dia — PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Quem roda PHP 8.1 ou anterior não recebe correção oficial, porque essas versões estão fora de suporte. Alterar configuração não protege; só atualizar resolve.
Se hoje você não sabe dizer quem aplica esse patch, em quanto tempo e quem responde caso algo quebre depois, as cinco perguntas que este artigo propõe deixaram de ser um exercício.
O que o GLPI resolve bem
O GLPI é um sistema de gestão de chamados e ativos de TI de código aberto, mantido por uma comunidade ativa e com uma base instalada significativa no Brasil. A versão gratuita inclui gestão de incidentes e solicitações, controle de ativos, base de conhecimento, portal do usuário e integrações via plugin. Para organizações que precisam de um sistema de tickets funcional sem custo de licença, o GLPI entrega o que promete.
Gestão de chamados: categorização, priorização, atribuição e acompanhamento de incidentes e solicitações em uma interface web. A fila de chamados substitui a caixa de e-mail compartilhada e dá visibilidade sobre o que está aberto, com quem e desde quando.
Inventário de ativos: o GLPI pode descobrir automaticamente os ativos da rede via agente (FusionInventory) e manter o inventário de hardware e software atualizado. Isso é relevante para auditorias de licenças e para entender o parque antes de tomar decisões de renovação.
Base de conhecimento: artigos de solução para problemas recorrentes que reduzem o tempo de resolução e permitem que o analista de nível 1 resolva mais sem escalar.
O GLPI resolve bem o problema de organização dos chamados. O que ele não inclui, por definição, é um contrato de suporte que obrigue alguém a responder quando o sistema falha.
As cinco perguntas que revelam a exposição
A diferença entre operar o GLPI de forma segura e operar com risco oculto não está na versão instalada nem no número de chamados ativos. Está na capacidade de responder cinco perguntas concretas. A tabela a seguir apresenta cada pergunta, o sinal que indica exposição e a consequência operativa se esse sinal for ignorado.
| A pergunta | Sinal de alerta | Consequência operativa |
|---|---|---|
| Quem aplica as correções de segurança do GLPI quando uma vulnerabilidade é publicada? | Não há uma pessoa designada com prazo definido. | A falha fica aberta no ambiente de produção por tempo indeterminado. O CERT.br documenta regularmente exploits em sistemas desatualizados. |
| Qual é o SLA de resposta quando o GLPI para em produção num sábado às 22h? | Não há contrato — a resposta depende de quem estiver disponível. | Indisponibilidade sem prazo de correção. Os chamados continuam chegando por e-mail, WhatsApp ou telefone; o histórico se perde. |
| Quem valida se a versão atual é compatível com o PHP e o banco de dados após uma atualização do servidor? | Ninguém fez esse mapeamento formalmente. | A atualização do servidor pode derrubar o GLPI silenciosamente. O ambiente fica instável até alguém diagnosticar a causa. |
| Há um processo documentado de backup e restauração testado nos últimos 90 dias? | Os backups existem, mas a restauração nunca foi testada em produção. | No dia da parada, a restauração demora mais do que o esperado. Dados de chamados recentes podem ser perdidos. |
| O que acontece com o GLPI se o único técnico que o conhece sair da empresa? | O conhecimento está na cabeça de uma pessoa, não documentado. | Qualquer problema vira bloqueador. A equipe não sabe onde está o ambiente, qual versão roda nem como acessar o banco. |
Se duas ou mais respostas revelam um ponto cego, o ambiente tem uma dependência de resiliência que não aparece no orçamento de TI — mas que vai aparecer na nota fiscal de uma parada ou de um incidente de segurança.
Quem responde: a diferença entre comunidade e contrato
O modelo open source funciona sobre uma premissa honesta: a comunidade mantém o software, mas ninguém tem obrigação contratual de resolver o seu problema. Isso é diferente de dizer que o suporte não existe — a comunidade do GLPI é ativa, os fóruns têm respostas e os plugins são atualizados. A diferença é o prazo e a responsabilidade.
Suporte de comunidade: você posta o problema, aguarda uma resposta, implementa a solução sugerida e testa. O tempo entre o problema e a resolução depende da disponibilidade de quem responde e da complexidade do ambiente. Para problemas comuns e bem documentados, isso funciona. Para problemas específicos do seu ambiente, o tempo pode ser imprevisível.
Suporte com contrato: há um SLA — tempo máximo de resposta para cada categoria de severidade — e um responsável que tem obrigação contratual de cumpri-lo. Para uma parada em produção, a diferença entre “aguardando resposta no fórum” e “chamado aberto com SLA de 4 horas” é a diferença entre explicar para o negócio por que o sistema está fora e explicar por quanto tempo mais vai ficar.
O CERT.br documenta regularmente que vulnerabilidades em sistemas web desatualizados são vetores frequentes de comprometimento. O GLPI publica correções de segurança, mas a responsabilidade de aplicá-las no prazo é de quem opera o ambiente — sem contrato, esse prazo é definido pela disponibilidade interna, não por um acordo externo.
Para a maioria das equipes que opera o GLPI sem suporte, o risco não é que a ferramenta vai falhar amanhã. É que quando falhar, o custo de recuperação vai ser maior do que o custo de um contrato preventivo.
Como avaliar sem trocar nada ainda
A avaliação da exposição não exige uma decisão de migração imediata. Começa com um inventário de três itens que não aparecem no dashboard do GLPI mas que determinam a resiliência do ambiente.
1. Mapa de responsabilidade: quem é o responsável nomeado pela manutenção do GLPI? Se a resposta é “o time de TI em geral”, não há um responsável — há uma responsabilidade difusa que ninguém assume quando o problema aparece fora do horário.
2. Registro de versão e atualização: qual versão do GLPI está em produção? Quando foi a última atualização? O PHP e o banco de dados estão nas versões compatíveis com a versão atual? Esse mapeamento leva menos de uma hora e responde se o ambiente está dentro do ciclo de suporte da comunidade ou já está em versão sem manutenção ativa.
3. Teste de restauração: o backup existe, mas foi testado? Uma restauração validada em ambiente de homologação nos últimos 90 dias é a única evidência de que o plano de recuperação vai funcionar quando for necessário. Sem esse teste, o backup é uma suposição, não uma garantia.
Com esses três itens mapeados, você tem uma visão clara do que está coberto e do que está exposto. Essa visão é o ponto de partida para uma conversa fundamentada sobre se o ambiente atual é adequado para o nível de criticidade da operação — e se uma plataforma com contrato faz sentido para o próximo ciclo.
O próximo passo com a Aufiero Informática
A Aufiero Informática é distribuidora oficial do OTRS para a América Latina — uma plataforma de ITSM com suporte contratual, SLA definido e atualizações gerenciadas. O OTRS cobre o mesmo conjunto de funcionalidades do GLPI com a camada de suporte que o modelo open source não inclui por definição.
Se o mapeamento dos três itens acima revelou pontos de exposição, ou se a operação já teve uma parada que deixou clara a necessidade de um contrato, a Aufiero pode ajudar a estruturar a avaliação — incluindo uma estimativa do custo total de manutenção do ambiente atual versus o custo de uma plataforma com suporte.
Perguntas frequentes sobre GLPI e suporte
O GLPI é seguro?
O projeto publica correções de segurança, mas quem instala é responsável por aplicá-las. Sem uma pessoa designada com prazo definido, a correção não chega ao ambiente de produção no prazo necessário.
O GLPI foi afetado pela vulnerabilidade do PHP de outubro de 2026?
A falha não é do GLPI. As duas vulnerabilidades críticas divulgadas em 21 de outubro de 2026 (CVE-2026-109618 e CVE-2026-109619, gravidade 9.2) estão no núcleo do PHP e atingem qualquer aplicação web executada sobre ele — o GLPI entre milhares de outras. A correção é atualizar o PHP do servidor. O ponto operacional não é a falha em si: é quem na sua organização aplica a correção e em quanto tempo.
O que fazer se a minha ferramenta de chamados roda sobre PHP?
Descubra primeiro em qual versão do PHP o servidor está. Nas linhas 8.5, 8.4, 8.3 e 8.2, atualize para 8.5.12, 8.4.27, 8.3.36 ou 8.2.35. No PHP 8.1 ou anterior não existe correção oficial: a versão está fora de suporte e o caminho é migrar para uma versão suportada. Enquanto isso não acontece, a recomendação é tirar da internet pública qualquer aplicação PHP exposta que não possa ser corrigida de imediato. Regras de WAF servem como paliativo, não como substituto da atualização.
Preciso trocar de ferramenta?
Não necessariamente. O primeiro passo é saber quem responde hoje pelo prazo de correção e pela atualização. Se há um responsável designado com processo documentado, o ambiente pode estar bem sustentado mesmo sem contrato externo.
Dá para migrar sem perder o histórico?
Sim, começando pela validação dos fluxos e dos dados antes da migração. Um projeto de migração bem conduzido mapeia os dados existentes, valida a equivalência dos fluxos na nova plataforma e realiza a migração com janela de homologação antes do corte.
Qual o custo de continuar como está?
O custo aparece no dia da parada: horas de indisponibilidade sem prazo de correção e sem fornecedor responsável. Para operações que processam mais de 200 chamados por mês, uma parada de quatro horas tem um custo de equipe e de produtividade que frequentemente supera o custo anual de um contrato de suporte.
Ferramenta open source é sempre mais barata?
No licenciamento, sim. No custo total, depende de quanto tempo da equipe é gasto sustentando o ambiente — atualizações, diagnóstico de problemas, restauração de backups e manutenção de compatibilidade. Esse tempo tem um custo que raramente aparece na linha de software do orçamento de TI.
