O health check tradicional funciona pela camada de protocolo: 'porta aberta', 'retorna HTTP 200', talvez 'o conteúdo da página contém esta palavra'. Essas respostas dizem que o servidor está servindo, mas não dizem COM QUAL conteúdo ele está servindo.
Os problemas modernos vivem exatamente nessa lacuna. Se um atacante passou pelo WAAP e deixou um webshell no servidor, o health probe continua dizendo 'servidor saudável'. Se um release saiu defeituoso, o servidor responde com o binary antigo, mas para o probe de protocolo continua sendo 200 OK. Se um operador alterou manualmente o arquivo de config, o desvio do baseline opera em silêncio.
Na escala de cluster a situação é ainda pior. Dos 10 servidores, 9 têm a nova versão e 1 não; o health probe vê todos como saudáveis, e a requisição do usuário cai por azar no servidor desatualizado. Ou, ao contrário, em 1 servidor o atacante depositou um novo arquivo; o resto do cluster está limpo, mas o tráfego não é retirado desse único servidor porque ninguém está olhando.
A ETM Integridade de Servidor e Inteligência de Release preenche essa lacuna: o estado de arquivo, diretório, binary e config no servidor é monitorado continuamente; as mudanças fluem como evento ao ADC e ao SOC; a decisão de routing vai além da casca externa.
O agente no servidor faz auditoria contínua no nível de arquivo; detecta mudanças e vincula-se ao vivo à decisão de routing do ADC e ao sistema de eventos do SOC.
Para arquivos críticos selecionados (conteúdo do webroot, application binary, arquivos de config, certificados TLS) é calculado um hash periódico. Para árvores de diretórios é gerado um hash agregado estilo Merkle. A mudança é detectada instantaneamente pela comparação de hash.
A adição de um novo arquivo fora do baseline esperado, a alteração de um arquivo existente ou a exclusão de um arquivo esperado geram um evento instantâneo. Um novo arquivo .aspx/.php/.jsp depositado no webroot é marcado como suspeita de webshell.
É feita comparação de hash entre os servidores que prestam o mesmo serviço de aplicação. Um único servidor que fica fora da distribuição esperada (drift ou comprometido) é separado do cluster; o tráfego é redirecionado aos servidores consistentes.
Quando uma mudança é detectada, a política de tráfego do ADC pode reagir automaticamente: período de warm-up, routing gradual, isolamento temporário. Quando um novo release é detectado, o tráfego transita suavemente; quando uma alteração não autorizada é detectada, o tráfego é cortado.
A integridade de arquivos e a inteligência de release não são apenas segurança, mas parte do mecanismo de decisão operacional.
Para os arquivos de conteúdo mantidos nas raízes vhost do servidor web (HTML, ASP, ASPX, PHP, JSP, JS, CSS, imagem) são calculados hash periódico e integridade da árvore de diretórios. O operador define por política quais diretórios serão monitorados e quais extensões serão consideradas sensíveis. Uma mudança inesperada reflete-se como evento instantâneo.
Quando o atacante tenta passar pelo WAAP e implantar um webshell no servidor, o ETM captura instantaneamente a nova extensão executável depositada no webroot (ex.: .aspx, .php, .jsp). O servidor pode ser colocado automaticamente em quarentena, o tráfego pode ser cortado, o SOC recebe alarme. É a camada de defesa final DEPOIS do WAAP.
A mudança de hash do application binary ou artifact é interpretada como evento de release. O ADC aguarda esse evento: até os indicadores de saúde ficarem estáveis, pouco tráfego é direcionado ao servidor; quando o warm-up se completa, o tráfego total é aberto. Os passos manuais de 'tirar do load balancer, fazer o release, recolocar' são automatizados.
Quando arquivos de configuração como Apache config, Nginx config, IIS application config, systemd units, definições de cron desviam do baseline, é gerado alarme. O operador pode intervir antes de uma alteração não autorizada; alterações regulares são tratadas com atualização do baseline.
O hash dos binaries de sistema críticos, arquivos de biblioteca e ferramentas auxiliares é comparado com o baseline. A alteração de binary resultante de rootkit, supply-chain compromise ou intervenção manual é detectada instantaneamente; o servidor é colocado em isolamento e permanece disponível para forense.
Quando o dono, as permissões ou as entradas de ACL de arquivos e diretórios críticos mudam, é gerado um evento. Escalonamento de privilégio não autorizado, alteração de propriedade de arquivo ou abertura de permissão de escrita em configuração sensível tornam-se visíveis instantaneamente.
É feita comparação de hash de baseline entre os servidores que prestam o mesmo serviço de aplicação. Se 9 de 10 servidores coincidem e 1 é diferente, o diferente é suspeito de drift ou comprometimento. Pode-se aplicar quarentena automática ou isolamento com aprovação do operador.
Quando o operador abre uma janela de manutenção, as mudanças dentro dessa janela não geram alarme; o baseline é atualizado conforme a política. Um evento de release esperado não é interpretado como 'mudança real'; uma mudança surpresa dispara alarme.
Se, após a nova versão, a telemetria do ETM (tempo de GC, error rate, frequência de restart) mostrar degradação, o ETM a correlaciona com o evento de release. O routing do ADC pode priorizar os servidores que têm a versão anterior; a equipe de rollback é informada automaticamente.
Cada mudança de arquivo/configuração/binary é gravada no registro de auditoria; é exportada ao SIEM. Em qual servidor, quando, qual arquivo mudou de qual hash para qual hash — a cadeia de evidências completa está pronta para a auditoria. Suporte ao vivo para GDPR Art 32 e requisitos de auditoria setorial.
O monitoramento de integridade não é apenas um recurso técnico, mas a camada de gestão viva dos processos corporativos de release e segurança.
Quais diretórios serão monitorados, quais extensões de arquivo serão consideradas sensíveis, quais arquivos serão ignorados (log, cache, arquivos temporários) são definidos por política. Podem ser definidos perfis distintos para servidor web, servidor de aplicação e servidor de banco de dados.
Arquivos críticos (system binary, TLS cert) podem ter hash na ordem de segundos; de prioridade média (arquivos de config) em minutos; de baixa prioridade (conteúdo estático) em intervalos horários. A carga de IO de disco é mantida sob controle.
Os eventos de integridade são vinculados ao vivo à política de routing do ADC. Regras de política como 'novo arquivo detectado + há contexto de ataque do WAAP → isolamento', 'hash drift detectado → baixa prioridade', 'release detectado → warm-up' são definidas pelo operador.
O pipeline CI/CD pode notificar um evento de release à API do ETM; o ETM interpreta esse evento como mudança esperada e, em vez de alarme, dispara a coordenação de routing. Quando o release termina, o ETM assina o novo baseline.
Eventos de alta prioridade como suspeita de webshell, binary tampering e cluster drift são transmitidos ao SOC diretamente com alarme. O evento é enriquecido: qual servidor, qual arquivo, resultado da comparação de hash, momento da última modificação, recomendação de ação.
Cada evento de integridade é registrado no log de auditoria. Quando o auditor pergunta 'nos últimos 30 dias, qual arquivo mudou em qual servidor?', a resposta é dada ao vivo. A cadeia de evidências para PCI DSS, GDPR Art 32 e requisitos de auditoria setorial é automatizada.
Mesmo que o WAAP não tenha detectado o ataque, um novo arquivo executável depositado no diretório vhost do IIS no servidor é capturado instantaneamente pelo ETM. O servidor é retirado automaticamente do cluster, o tráfego é cortado, o SOC recebe alarme instantâneo; o dispositivo permanece disponível para forense.
Quando a equipe de DevOps publica uma nova versão, o ETM detecta a mudança de hash do application binary; o ADC faz routing gradual ao servidor. Quando as métricas de saúde (CPU, tempo de GC, error rate) permanecem estáveis, o tráfego total é aberto. Os processos manuais de 'tirar do load balancer, deploy, recolocar' desaparecem.
Dos 10 servidores do cluster de produção, 9 coincidem com o hash de baseline; 1 apresenta um hash diferente. É versão desatualizada, intervenção manual ou comprometimento? O ETM coloca esse servidor automaticamente em quarentena; o operador investiga o motivo. A requisição do usuário não cai por azar na versão errada.
Após a nova versão, a telemetria do ETM mostra que o tempo de GC se alongou, o error rate aumentou e a frequência de restart subiu. O ETM correlaciona isso com o evento de release; o routing do ADC prioriza os servidores que têm o hash da versão anterior. A equipe de rollback é informada automaticamente; a decisão de release é apoiada por dados.
Quando o hash de um system binary crítico em um servidor desvia do baseline — suspeita de rootkit, supply-chain compromise ou alteração não autorizada — o servidor é separado do cluster, o acesso à internet é cortado e apenas o canal de gestão do ETM permanece aberto. O SOC faz inspeção remota para forense.
Vamos ver a ETM Integridade de Servidor ao vivo no seu próprio backend — vamos planejar uma sessão de implantação que cobre a definição de baseline, o vínculo com o ADC e o fluxo SIEM sobre um grupo piloto de servidores.