Tipos de pentest: interno, externo e os níveis de acesso
Não existe um pentest melhor em abstrato. O formato certo depende do que você quer descobrir e do cenário que precisa simular.
Quem vai contratar um teste de invasão logo percebe que a palavra pentest cobre trabalhos bem diferentes. Um teste da rede interna simulando um funcionário mal-intencionado e um teste da aplicação web exposta na internet têm objetivos, técnicas e custos distintos. Escolher o tipo errado gera um relatório que não responde à pergunta que motivou a contratação.
Este guia organiza os tipos de pentest em três eixos: a posição do atacante simulado (interno ou externo), o nível de acesso e informação concedido (caixa preta, cinza ou branca) e o alvo (aplicação, API, rede, nuvem). Entender esses eixos ajuda a definir um escopo alinhado ao objetivo e a comparar propostas que, à primeira vista, parecem iguais, mas cobrem coisas diferentes.
Pentest interno e externo
O primeiro eixo é de onde parte o teste. O pentest externo simula um atacante na internet, sem acesso prévio, tentando comprometer o que está exposto: aplicações, serviços e a borda da rede. Ele responde à pergunta de quanto risco a superfície pública representa. O pentest interno parte de dentro da rede, simulando alguém que já obteve algum acesso, seja um funcionário mal-intencionado, seja um atacante que passou da borda.
Os dois olham riscos diferentes e por isso se complementam. Muitas empresas investem apenas no teste externo e esquecem que boa parte do dano de um incidente acontece depois do acesso inicial, na movimentação lateral e no escalonamento de privilégio dentro da rede. O pentest interno é o que avalia a resistência a esse segundo momento do ataque.
Caixa preta, cinza e branca
O segundo eixo é quanto o testador sabe e recebe antes de começar. Esse nível de acesso muda o realismo, a cobertura e o custo do teste. Não há um nível universalmente melhor: cada um serve a um objetivo.
- Caixa preta: o testador parte sem informação privilegiada, simulando um atacante externo real. Gasta mais tempo em reconhecimento e reflete bem o cenário de quem não conhece o ambiente.
- Caixa cinza: o testador recebe credenciais e algum contexto, como um usuário comum faria. Equilibra realismo e profundidade e costuma ser o formato com melhor custo-benefício.
- Caixa branca: o testador tem acesso amplo a documentação, configuração e às vezes ao código. Maximiza a cobertura por hora investida e é indicado quando o objetivo é encontrar o máximo de falhas.
Quando escolher cada nível
A escolha depende do que se quer aprender. Para medir a resistência a um atacante que chega sem nada, a caixa preta faz sentido. Para aprofundar a análise de uma aplicação crítica com o orçamento disponível, a caixa cinza ou branca cobre mais em menos tempo, porque o testador não gasta horas descobrindo o que a empresa já poderia informar.
Há um limite prático importante na caixa preta: parte do tempo é consumida em reconhecimento, e o relógio corre igual para todos. Um alvo grande testado em caixa preta com prazo curto tende a ficar com áreas inteiras sem cobertura, porque o testador não teve tempo de chegar a elas. Se o objetivo é confiança na profundidade da análise, informar o contexto costuma render mais do que preservar o realismo de um atacante que não conhece nada.
Tipos por alvo
O terceiro eixo é o que está sendo testado. Cada alvo exige competências e abordagens próprias, e isso influencia diretamente o esforço e o perfil do profissional. Misturar alvos muito diferentes em um único escopo mal definido costuma diluir a profundidade em todos eles.
- Aplicação web: foco em autenticação, autorização, injeções e lógica de negócio
- API: superfície REST ou GraphQL, validação de entrada e controle de acesso
- Rede interna: serviços expostos, segmentação e movimentação lateral
- Ambiente de nuvem: identidade, exposição pública e escalonamento de privilégio
- Aplicação mobile: o app, a comunicação com o servidor e o armazenamento local
- Engenharia social: simulação controlada de phishing e do fator humano
Metodologia, escopo e autorização
Antes de qualquer teste começar, o que separa um trabalho profissional de um risco jurídico é a formalização. Um pentest é uma atividade autorizada por escrito, com escopo delimitado e regras de engajamento acordadas. Sem a autorização explícita de quem tem poder para concedê-la, o mesmo conjunto de técnicas deixa de ser um teste contratado e passa a ser acesso não autorizado. Por isso o documento de autorização, muitas vezes chamado de regras de engajamento, é a base de tudo.
O que definir no escopo
- Alvos exatos: domínios, faixas de IP, aplicações e contas que entram no teste
- O que fica de fora: sistemas de terceiros e ambientes que não podem ser tocados
- Janela de execução e horários acordados para as ações de maior impacto
- Tipos de ação permitidos, como exploração ativa, e os que ficam expressamente vedados
- Contatos de emergência dos dois lados para pausar o teste se algo sair do previsto
- Tratamento de dados sensíveis eventualmente encontrados e regras de confidencialidade
A autorização precisa vir de quem tem autoridade sobre os ativos testados. Testar um sistema hospedado na nuvem de um terceiro, ou uma aplicação SaaS, costuma exigir também a permissão do provedor, porque o contrato dele pode restringir testes de segurança. Ignorar isso expõe a empresa e o testador a consequências que nada têm a ver com o resultado técnico.
Ambiente de teste ou produção
Decidir se o teste roda em produção ou em um ambiente espelhado faz parte do escopo. Testar em produção reflete melhor a realidade, mas carrega risco de indisponibilidade e de efeitos colaterais sobre dados reais. Um ambiente de homologação reduz esse risco, desde que seja fiel ao de produção, o que nem sempre acontece. A escolha depende da tolerância a impacto e da fidelidade do ambiente alternativo, e precisa estar clara antes de começar.
Padrões e metodologias reconhecidas
Um teste conduzido por método, e não por improviso, tende a ser mais completo e mais fácil de comparar entre fornecedores. Metodologias reconhecidas dão uma estrutura de fases e uma lista do que precisa ser coberto, o que reduz a chance de o testador esquecer uma classe inteira de falha. Elas não substituem a competência de quem testa, mas elevam o piso e tornam a cobertura auditável.
- OWASP Testing Guide e OWASP ASVS para aplicações web, com classes de vulnerabilidade e níveis de verificação
- OWASP API Security Project para a superfície específica de APIs
- PTES, que descreve as fases de um teste de intrusão de ponta a ponta
- NIST SP 800-115 como referência técnica de planejamento e execução
- MITRE ATT&CK para descrever técnicas de forma padronizada em testes mais adversariais
Ao comparar propostas, pergunte qual metodologia orienta o trabalho e como a cobertura é evidenciada. Uma proposta que apenas promete encontrar vulnerabilidades, sem descrever o método e as fases, dá pouca garantia de que o alvo será coberto por inteiro. O relatório final também ganha valor quando mapeia cada achado a uma referência conhecida, porque isso ajuda a equipe interna a entender a natureza da falha e a comparar resultados entre ciclos.
Red team e o teste focado
Vale distinguir o pentest de um exercício de red team, porque os dois são confundidos. O pentest tem escopo definido e busca encontrar e evidenciar o máximo de vulnerabilidades relevantes em um alvo, dentro de um prazo. O red team tem um objetivo específico, como acessar um dado crítico, e testa também a capacidade de detecção e resposta da empresa, muitas vezes sem que o time de defesa saiba do exercício.
Red team faz sentido para organizações mais maduras, que já corrigiram o básico e querem testar a operação de segurança como um todo. Para a maioria das empresas, começar por um pentest bem escopado entrega mais valor, porque revela as falhas que um atacante exploraria primeiro. Escalar para red team antes de fechar o básico costuma ser gasto no lugar errado.
Checklist prático
- Definir o objetivo do teste antes de escolher o tipo
- Decidir entre pentest externo, interno ou os dois
- Escolher o nível de acesso: caixa preta, cinza ou branca
- Delimitar o alvo com clareza (web, API, rede, nuvem)
- Evitar misturar alvos diferentes em um escopo raso
- Formalizar escopo e autorização por escrito
- Registrar as regras de engajamento com janelas, contatos e ações vedadas
- Obter autorização de quem tem poder sobre os ativos, e do provedor quando aplicável
- Definir se o teste roda em produção ou em ambiente espelhado
- Perguntar qual metodologia reconhecida orienta o trabalho
- Distinguir pentest de red team conforme a maturidade
- Exigir relatório com evidência, severidade e reteste
Boas práticas
- Escolha o tipo pelo cenário que precisa simular
- Formalize a autorização antes de qualquer ação, sem exceção
- Combine teste externo e interno para cobrir os dois momentos do ataque
- Prefira caixa cinza quando busca equilíbrio entre realismo e profundidade
- Delimite um alvo por vez para não diluir a análise
- Escolha uma metodologia reconhecida para tornar a cobertura auditável
- Reserve red team para depois de fechar o básico
- Trate o pentest como recorrente, já que o ambiente muda
Erros comuns
Iniciar o teste sem autorização formal e escopo por escrito
A atividade deixa de ser um teste contratado e vira risco jurídico para as duas partes.
Testar ativos de terceiros sem permissão do provedor
Violação do contrato do provedor, independentemente do resultado técnico.
Testar só a superfície externa e esquecer a rede interna
A resistência à movimentação lateral fica sem avaliação.
Pedir caixa preta esperando cobertura máxima
Tempo gasto em reconhecimento reduz a profundidade da análise.
Misturar muitos alvos em um escopo mal definido
Profundidade diluída e falhas relevantes deixadas de fora.
Contratar red team sem ter fechado o básico
Gasto elevado antes de corrigir o que um atacante exploraria primeiro.
Quando procurar apoio especializado
O serviço de Pentest da GUARDIASEC ajuda a definir o tipo de teste adequado ao seu objetivo, do escopo externo ao interno e do nível de acesso ao alvo, com teste manual orientado por metodologia reconhecida e entrega de evidência, priorização e reteste.
Perguntas frequentes
Qual a diferença entre pentest interno e externo?
O pentest externo simula um atacante na internet, sem acesso prévio, e avalia o risco da superfície exposta, como aplicações e serviços públicos. O pentest interno parte de dentro da rede, simulando alguém que já obteve algum acesso, e avalia a resistência à movimentação lateral e ao escalonamento de privilégio. Os dois olham riscos diferentes e se complementam, porque boa parte do dano de um incidente acontece depois do acesso inicial.
Caixa preta, cinza ou branca: qual escolher?
Depende do objetivo. A caixa preta simula um atacante sem informação e reflete o cenário externo real, mas gasta mais tempo em reconhecimento. A caixa cinza fornece credenciais e algum contexto, equilibrando realismo e profundidade, e costuma ter o melhor custo-benefício. A caixa branca dá acesso amplo e maximiza a cobertura por hora, sendo indicada quando se quer encontrar o máximo de falhas em um alvo crítico.
Pentest e red team são a mesma coisa?
Não. O pentest tem escopo definido e busca encontrar e evidenciar o máximo de vulnerabilidades relevantes em um alvo, dentro de um prazo. O red team tem um objetivo específico e testa também a capacidade de detecção e resposta da empresa, muitas vezes sem o conhecimento do time de defesa. O red team faz mais sentido para organizações maduras, enquanto a maioria das empresas ganha mais começando por um pentest bem escopado.
Preciso de autorização por escrito para um pentest?
Sim. O pentest usa técnicas que, sem consentimento, configuram acesso não autorizado. A autorização por escrito, com escopo e regras de engajamento, é o que torna o trabalho legítimo e protege as duas partes. Ela deve vir de quem tem autoridade sobre os ativos testados, e quando o alvo está hospedado em nuvem ou serviço de terceiro, costuma ser necessária também a permissão do provedor, porque o contrato dele pode restringir testes de segurança.
O que são regras de engajamento em um pentest?
São o documento que delimita como o teste será conduzido: quais alvos entram e quais ficam de fora, a janela de execução, os tipos de ação permitidos e vedados, os contatos de emergência dos dois lados e o tratamento de dados sensíveis encontrados. Elas evitam mal-entendidos, definem quando e como pausar o teste se algo sair do previsto e servem de referência caso surja alguma dúvida sobre o que foi ou não autorizado.
Qual metodologia de pentest devo exigir?
Depende do alvo. Para aplicações web, o OWASP Testing Guide e o OWASP ASVS são referências comuns; para APIs, o OWASP API Security Project; para o teste como um todo, o PTES e o NIST SP 800-115 descrevem fases e boas práticas. O ponto não é a sigla, e sim exigir que exista um método explícito e que a cobertura seja evidenciada no relatório. Uma proposta que descreve o método dá mais garantia de que o alvo será coberto por inteiro do que uma que apenas promete achar falhas.
Guias relacionados
Próximo passo
Vamos avaliar os riscos do seu ambiente?
Conte seu cenário e definimos juntos o escopo certo. O objetivo é reduzir caminhos prováveis de ataque e elevar a maturidade de segurança, sem promessas absolutas.