O Que Significa Hermético

O termo hermético e o que significa na prática técnica

O que significa hermético

Hermético é um adjetivo que descreve algo completamente fechado, selado, sem comunicação com o exterior. Na linguagem do dia a dia significa isso mesmo, mas no contexto técnico a coisa se complica um pouco. Um sistema hermético é aquele que não expõe detalhes de implementação, não permite inspeção interna e não oferece integrações ou APIs acessíveis. Você aperta um botão e algo acontece, mas não sabe como e não consegue interferir no processo. Isso parece inofensivo até você precisar resolver um problema que não está nos documentos. Aí entra a dor real. Trabalhei num projeto de integração de ERP onde o fornecedor vendia o módulo como "solução completa e segura". O termo hermético estava presente em todos os materiais de marketing. Na prática, significava que não havia endpoint de API, não havia log exportável e não havia documentação do esquema de dados. Só dava para preencher formulários web e esperar que os dados chegassem do outro lado. Passei duas semanas tentando descobrir por que uma transação de R$ 3.450,12 estava sendo rejeitada sem motivo. O suporte apenas respondia "erro interno, verifique os dados". A solução foi usar um proxy HTTP capturando o tráfego entre o navegador e o servidor deles. Aí descobri que o campo "motivo_rejeicao" existia na resposta JSON, mas a interface web simplesmente não exibia esse campo. Era um caso de hermético seletivo: o que convenha ao fornecedor fica visível, o que convenha esconder fica enterrado.

O que distingue um sistema verdadeiramente hermético de um sistema apenas bem estruturado é a imposição de limite de acesso. Um sistema bem documentado com boa API é transparente por decisão do fabricante. Um sistema hermético é opaco por design, mesmo que tecnicamente seja possível romper essa opacidade com técnicas inadequadas. Não recomendo fazer isso em produção, só citei o exemplo porque mostra a realidade do campo.

Os sinais de que você está lidando com um ambiente hermético

Na maioria das vezes você percebe antes mesmo de testar. A ausência de API pública é o primeiro sintoma. Depois vem a falta de logs acessíveis pelo usuário final, erros genéricos que não informam causa raiz, endpoints ocultos que só aparecem se você fizer engenharia reversa de requisições, e documentação que descreve o comportamento esperado mas nunca os casos de falha. Alguns fornecedores até colocam intencionalmente variáveis com nomes obscuros nas URLs para dificultar a leitura do código. Existe um detalhe que pouca gente nota. Sistema hermético e sistema monolítico não são a mesma coisa. Um monolito pode ser totalmente transparente se o fabricante permitir acesso ao banco de dados e aos logs. Um sistema hermético pode ser arquitetado como microsserviços, com cada peça funcionando perfeitamente isolada. O problema não é a arquitetura. É a política de informação. E isso é intencional na maioria das vezes. Vendedores usam hermeticismo como argumento de venda: "nosso sistema é fechado justamente para garantir segurança". Tradução: é mais fácil para você confiar e menos fácil para você verificar. Nada disso é necessariamente malicioso. Apenas é comercialmente conveniente.

Como proceder quando o sistema é hermético

Não existe método universal. Depende do nível de acesso que o fornecedor permite. Se houver API, comece por ela. Se não houver, a próxima camada é o banco de dados. Em alguns casos o sistema grava diretamente em tabelas relacionais e você consegue ler e até escrever via SQL, desde que o fornecedor não tenha aplicado controle rigoroso de permissões. Conversei com um colega que trabalhava numa operadora de saúde onde o sistema de faturamento era completamente hermético via interface, mas o banco era MySQL padrão com tabelas nomeadas de forma legível. Ele escreveu um script Python que lia os logs de aplicação e mapeava as tabelas. Levou três dias. O fornecedor nunca soube. Quando nem SQL está disponível, sobra a captura de rede. Ferramentas como Wireshark, mitmproxy ou até o DevTools do navegador resolveram metade dos casos que encontrei. O problema real começa quando o tráfego é criptografado e há certificate pinning. Aí você precisa decidir se vai remover o pinning, usar um certificado intermediário ou simplesmente aceitar que o sistema é hermético de verdade e trabalhar dentro das restrições impostas. Remover certificate pinning funciona, mas é instável. Atualizações do app ou do SDK do fornecedor reintroduzem o pinning sem aviso e seu workaround quebra no meio de um processo crítico. Já vi isso acontecer durante uma operação de fechamento mensal em uma empresa de logística. O erro ocorreu numa sexta à tarde. Ninguém queria investigar. O trabalho foi feito de manhã seguinte.

Limitações e quando o hermeticismo é problema real

Sistemas herméticos falham de formas específicas. Eles não dão erro claro. Eles simplesmente não fazem nada e silenceam o problema. Auditoria torna-se impossível. Conformidade regulatória, como LGPD e normas setoriais, exige rastreabilidade. Sistema hermético não fornece rastreabilidade sem esforço adicional de engenharia. Se você precisa provar para um fiscalizador que uma operação aconteceu exatamente como aconteceu, depends do fornecedor cooperar. Se o fornecedor não coopera, você não tem como provar nada além do que está nos logs que ele permite acessar. A alternativa mais honesta é escolher fornecedores que não sejam herméticos por padrão. API aberta, documentação de erros, endpoints de status e acesso a logs são requisitos mínimos, não diferenciais premium. Quando isso não é possível, o caminho é manter uma camada de abstração própria que registre tudo antes e depois de cada chamada ao sistema fechado. É um trabalho extra, mas é o único jeito de ter controle real sobre um ecossistema hermético. Ninguém recomenda isso porque ninguém gosta de construir workarounds. Eu recomendo porque já vi muita coisa dar errado do outro lado desse tipo de configuração.