Testes de intrusão

Teste de intrusão vs. análise de vulnerabilidades: de qual precisa?

Os dois são confundidos constantemente. Um guia em linguagem clara sobre o que cada um encontra, quanto custa e quando usar qual.

28 Jul 2026 · Testes de intrusão

Pelo menos uma vez por semana pedem-nos um teste de intrusão quando o que é preciso é uma análise de vulnerabilidades — e, ocasionalmente, o contrário. Os termos são usados como sinónimos em documentos de aquisição, o que é lamentável, porque produzem coisas muito diferentes e com uma ordem de grandeza de diferença no preço.

O que é uma análise de vulnerabilidades

Uma análise de vulnerabilidades é automática. Uma ferramenta liga-se aos seus sistemas, identifica o software e as versões em uso e compara o que vê com uma base de problemas conhecidos. Reporta atualizações em falta, bibliotecas desatualizadas, configuração TLS fraca, serviços expostos e credenciais por omissão.

É rápida, barata e repetível. Uma análise de um perímetro externo modesto termina em horas e pode correr semanalmente ou todas as noites. Essa repetibilidade é o seu verdadeiro valor: apanha o servidor que alguém criou na terça-feira e esqueceu, e avisa quando uma nova vulnerabilidade publicada afeta algo que utiliza.

A limitação é que só conhece aquilo que lhe ensinaram a procurar. Não consegue raciocinar sobre a lógica da sua aplicação, não encadeia dois problemas aparentemente inofensivos num problema grave, e produz falsos positivos que alguém tem de filtrar.

O que é um teste de intrusão

Um teste de intrusão é uma pessoa — normalmente uma equipa pequena — a trabalhar contra os seus sistemas com um objetivo definido, dentro de um âmbito acordado e durante um período combinado. Usa ferramentas automáticas como ponto de partida e depois faz a parte que as ferramentas não fazem: perceber para que serve a aplicação, determinar o que um atacante realmente quereria e tentar obtê-lo.

As constatações são diferentes. Em vez de «TLS 1.0 ativo no porto 443», recebe «um utilizador de nível membro consegue obter a exportação de qualquer outro cliente alterando um identificador, e este é o pedido que o faz». Em vez de uma lista de CVE, recebe uma cadeia: esta fuga de informação de baixa severidade revela nomes internos, que expõem uma interface de administração, que aceita uma credencial por omissão.

Custa mais e demora mais — tipicamente uma a três semanas, consoante o âmbito — e é uma fotografia de um momento, não um controlo contínuo.

Como escolher

A resposta honesta é que não são alternativas. A análise é um controlo de higiene que se corre em contínuo; o teste é uma avaliação periódica em profundidade. A maioria das organizações com alguma dimensão precisa dos dois, por esta ordem — não faz sentido pagar a um testador para encontrar as atualizações em falta que um scanner teria indicado por uma fração do custo.

Se tiver de começar por um, a pergunta decisiva é o que pretende saber:

  • Comece pela análise se não tem hoje um inventário fiável do que expõe à internet, ou se a aplicação de atualizações é irregular. Há higiene básica a estabelecer primeiro.
  • Vá diretamente ao teste de intrusão se o risco que o preocupa está em software feito à medida — a sua aplicação, a sua API, o seu modelo de permissões. Um scanner não lhe dirá quase nada sobre código que escreveu.
  • Vá diretamente ao teste de intrusão se um cliente empresarial, um parceiro ou um regulador pede prova de testes independentes. Um relatório de análise não satisfaz esse pedido, e enviá-lo costuma custar-lhe uma ida e volta.

E o que está pelo meio

Aparecem outros dois termos em propostas. Uma avaliação de vulnerabilidades é uma análise mais triagem humana: alguém retira os falsos positivos e ordena o resto por impacto real no negócio. É uma opção intermédia razoável quando tem um parque grande e precisa de prioridades mais do que de profundidade. Um exercício de red team vai no sentido oposto — âmbito mais largo, mais duração, e testa tanto a sua deteção e resposta como as suas defesas. É a compra errada para quem ainda não fez um teste de intrusão normal, porque lhe dirá que foi comprometido sem lhe dizer como corrigir as vinte coisas banais que o permitiram.

Perguntas a fazer a um fornecedor

  • Que percentagem desta intervenção é manual, e quem especificamente a executa?
  • Vão testar com vários perfis de utilizador, e o teste autenticado está incluído?
  • O que contém a entrega além da exportação da ferramenta — há relatório técnico e um resumo acionável por não especialistas?
  • O reteste das correções está incluído, e durante quanto tempo?
  • Como é acordado e autorizado o âmbito, e o que acontece se for descoberto algo fora dele?

Um fornecedor que responda à primeira pergunta com uma percentagem e à última com um processo está a fazer isto como deve ser. Um que não distinga o seu próprio serviço de uma análise está a vender-lhe a coisa mais barata ao preço mais caro.

Regra prática: a análise responde a «faltam-me atualizações?». O teste responde a «alguém consegue mesmo entrar, e a que chegaria?». Se precisa da segunda resposta, a primeira ferramenta não lha dá.

Próximo passo

Quer isto verificado nos seus sistemas?

Definimos o âmbito consigo, por escrito, antes de qualquer teste começar.