Pentest (teste de invasão): quando fazer e o que esperar

O pedido costuma chegar de fora. Um cliente grande manda um questionário de segurança com a pergunta "a aplicação passou por teste de invasão nos últimos doze meses?". Um parceiro de integração exige o relatório antes de liberar o acesso à API. Ou, pior, alguém encontrou um dado de cliente onde não deveria estar e a diretoria quer saber o tamanho do buraco.

A empresa contrata um pentest às pressas, recebe um PDF de muitas páginas cheio de termos em inglês, encaminha para a equipe de desenvolvimento e o documento fica parado numa pasta. Seis meses depois, o próximo teste encontra as mesmas falhas. O dinheiro foi gasto, o risco continua o mesmo.

Em resumo: faça um pentest antes de colocar no ar um sistema que guarda dados de clientes ou dinheiro, depois de mudanças grandes, quando um cliente ou parceiro exigir e após um incidente, e repita o teste em ciclos regulares enquanto o sistema continuar mudando. Abaixo está o que um teste de invasão realmente faz, quais tipos existem, quando faz sentido contratar e como preparar o escopo e tratar o relatório para que o resultado seja correção, e não papel.

Quando fazer um pentest: a resposta curta

Um teste de invasão vale a pena quando pelo menos uma destas situações é verdadeira:

• Um sistema novo vai para produção e vai expor dados de clientes, pagamentos ou acesso a operações críticas.
• Uma mudança grande aconteceu: nova API aberta a parceiros, novo módulo de pagamento, troca de autenticação, migração para a nuvem.
• Um cliente, parceiro ou contrato exige evidência de teste independente.
• Houve um incidente ou suspeita de acesso indevido e é preciso saber o que mais está exposto.
• Faz mais de um ano desde o último teste e o sistema mudou bastante nesse período.

E ele não é a primeira coisa a fazer quando o básico ainda não existe. Se a aplicação não tem controle de acesso por perfil, roda com bibliotecas desatualizadas e não tem registro de quem fez o quê, o pentest vai encontrar o óbvio. É mais barato arrumar o óbvio antes e usar o teste para achar o que a equipe não consegue ver sozinha.

O que um teste de invasão realmente faz

Um pentest é uma tentativa autorizada e controlada de invadir o sistema, feita por especialistas que pensam como um atacante. O objetivo não é listar todo problema teórico, mas responder a uma pergunta prática: o que alguém mal-intencionado conseguiria fazer com o que está exposto hoje?

Na prática, o testador:

1. Reconhece o alvo: quais endereços, telas, APIs e funcionalidades existem.
2. Procura pontos fracos: autenticação frágil, permissões mal verificadas, entradas que aceitam qualquer coisa, configurações expostas.
3. Tenta explorar: mostra que a falha é real, por exemplo acessando o pedido de outro cliente trocando um número na URL.
4. Documenta: descreve cada achado, como reproduzir, o impacto e a recomendação de correção.

A diferença para uma varredura automática de vulnerabilidades é importante. A ferramenta automática encontra versões desatualizadas e configurações conhecidas. Ela não entende que o vendedor da filial de Campinas não deveria ver a carteira de clientes da filial de Curitiba. Falhas de regra de negócio e de autorização, que estão entre as mais graves em sistemas de gestão, quase sempre só aparecem com alguém testando à mão.

Caixa preta, cinza e branca

O tipo de teste define quanta informação o testador recebe antes de começar. Cada um responde a uma pergunta diferente.

• Caixa preta parece mais realista, mas costuma render menos. Boa parte do tempo vai em descobrir o que poderia ter sido informado. Um atacante real pode ter meses; o testador tem dias.
• Caixa cinza é o ponto de partida para a maioria das empresas. Quase todo sistema de gestão tem login, e o risco maior está no que um usuário autenticado consegue fazer além do seu perfil.
• Caixa branca encontra mais com o mesmo esforço, porque o testador não precisa adivinhar como as coisas funcionam. Faz sentido quando o sistema é crítico ou quando a empresa quer aproveitar o teste para melhorar o código.

Quando contratar: lançamentos, clientes exigentes, incidentes

Antes de um lançamento

O melhor momento é quando o sistema está estável, num ambiente igual ao de produção, mas ainda há tempo para corrigir antes de abrir para o público. Testar uma semana antes do lançamento, sem folga na agenda, garante que as falhas graves vão para produção junto com o sistema.

Reserve na agenda tempo para o teste, a correção e o reteste.

Quando um cliente ou parceiro exige

Empresas maiores, bancos, operadoras de saúde e plataformas de pagamento costumam pedir evidência de teste independente antes de fechar contrato ou liberar integração. Antes de contratar, pergunte ao cliente o que exatamente ele espera: qual sistema, qual tipo de teste, se aceita um resumo executivo ou quer o relatório completo, e se exige reteste comprovando as correções. Isso evita pagar por um teste que não atende à exigência.

Depois de um incidente

Se houve vazamento ou acesso indevido, o primeiro passo é conter o problema e entender o que aconteceu, não contratar um pentest. Depois da contenção, o teste ajuda a responder se existem outras portas abertas parecidas com a que foi usada. Nesse momento, caixa branca costuma ser a melhor escolha, porque o tempo importa mais do que simular um atacante sem informação.

Incidentes com dados pessoais também têm obrigações próprias de comunicação previstas na LGPD. Essa parte deve ser conduzida com o jurídico e o encarregado de dados da empresa; o que o sistema precisa suportar para isso está em LGPD no desenvolvimento de sistemas.

Escopo: o que testar e o que deixar fora

Escopo mal definido faz o teste passar por tudo superficialmente ou deixar de fora justamente a parte que mais importa.

Checklist para montar o escopo

• Liste os sistemas e endereços que entram no teste: site, painel administrativo, API, app.
• Marque o que é mais sensível: telas e rotas da API que mexem com dados pessoais, financeiro, pagamentos, emissão de documentos fiscais, cadastro de usuários e permissões.
• Defina os perfis de usuário que o testador vai receber: cliente, vendedor, gerente de filial, administrador. Cada perfil a mais permite testar se um consegue fazer o que é do outro.
• Inclua as APIs, não só as telas. Muitos sistemas protegem bem a interface e deixam a API aceitar qualquer requisição. Os erros mais frequentes nessa camada estão em segurança de APIs: erros comuns.
• Escolha o ambiente: homologação idêntica à produção é o mais seguro. Testar em produção é possível, mas exige combinar horários, limites e o que não pode ser feito.
• Liste o que fica fora: sistemas de terceiros que a empresa não controla (ERP em nuvem do fornecedor, gateway de pagamento), ataques de negação de serviço, engenharia social, se não forem o objetivo.
• Combine as regras do jogo: datas, horários, contatos de emergência, o que fazer se o testador encontrar algo crítico no meio do teste.

Autorização por escrito

Sem autorização formal, um pentest não se distingue de uma invasão, inclusive perante a lei. O contrato precisa deixar claro quem autoriza, quais sistemas, em que período e com quais limites. Se parte da infraestrutura é de um provedor de nuvem ou de um fornecedor de software, confira se as regras desse terceiro permitem o teste e se é preciso avisá-lo.

Lendo o relatório: severidades e prioridades

Um bom relatório tem duas partes: um resumo executivo, para a diretoria, e os achados técnicos, para a equipe que vai corrigir. Se o relatório só tem a segunda parte, peça a primeira.

Cada achado costuma vir com uma severidade. As escalas variam, mas em geral seguem esta lógica:

Severidade não é prioridade

A severidade do relatório é técnica. A prioridade é decisão do negócio, e considera o contexto que o testador não conhece:

• O que está exposto: uma falha média no portal de clientes, aberto a todos, pode ser mais urgente que uma alta num painel interno acessível só pela rede da empresa.
• Quais dados estão envolvidos: dados pessoais sensíveis, dados financeiros e credenciais pesam mais.
• Esforço de correção: algumas falhas se resolvem com uma configuração; outras exigem mudar a forma como o sistema verifica permissões em dezenas de telas.

Muitos achados graves em sistemas de gestão são de autorização: o sistema confere se o usuário está logado, mas não se ele pode ver aquele registro específico. Se o relatório aponta vários achados desse tipo, o problema é de desenho, e corrigir tela por tela não resolve. A forma de estruturar isso está em controle de acesso e trilha de auditoria.

Corrigir e retestar

O relatório só tem valor quando vira lista de trabalho:

1. Reunião de leitura com quem fez o teste, a equipe técnica e alguém do negócio.
2. Transformar cada achado em tarefa na mesma fila de trabalho das funcionalidades, com responsável e prazo proporcional à prioridade.
3. Tratar a causa, não o sintoma. Se a falha é "o pedido 123 aparece para outro cliente", a correção não é bloquear o pedido 123, é garantir que toda consulta filtre pelo dono do registro.
4. Procurar o mesmo padrão em outras partes do sistema. O testador encontrou a falha em uma tela; é provável que ela se repita em outras que ele não teve tempo de testar.
5. Criar um teste automatizado para cada falha corrigida, para que ela não volte numa versão futura.
6. Pedir o reteste. O testador verifica se as correções funcionam e emite uma confirmação. É isso que clientes e parceiros costumam querer ver.
7. Registrar riscos aceitos. Se a empresa decide não corrigir algo agora, a decisão fica escrita, com motivo e responsável.

Inclua o reteste na contratação desde o início. Sem ele, a empresa tem um documento dizendo que estava vulnerável e nenhum dizendo que deixou de estar.

Segurança contínua além do pentest anual

Um pentest é uma fotografia do sistema nas datas do teste. Na semana seguinte, sai uma versão nova e a fotografia já está desatualizada.

Por isso o teste anual funciona melhor como auditoria de um processo que já existe, e não como o processo inteiro. O que deveria acontecer entre um teste e outro:

• Atualização de dependências com rotina definida, e alerta quando uma biblioteca usada recebe correção de segurança.
• Análise automática no processo de publicação: ferramentas que verificam código e dependências a cada versão, antes de ir para produção.
• Revisão de código com atenção a permissões e validação de entradas, principalmente em telas e APIs novas.
• Requisitos de segurança desde o desenho: quem pode ver, quem pode alterar, o que fica registrado. Corrigir no desenho é muito mais simples que corrigir depois de um pentest.
• Registro e monitoramento: registros de acesso e alertas para comportamento estranho, como um usuário consultando centenas de cadastros em minutos.
• Teste focado a cada mudança grande, sem esperar o ciclo anual.

Quando esse processo existe, o pentest encontra menos coisas, e as que encontra são as realmente difíceis.

Erros comuns ao contratar um pentest

• Não dar usuários de teste. O testador passa o tempo tentando entrar, e a parte mais arriscada, o que acontece depois do login, fica sem teste.
• Não planejar tempo de correção. O teste termina, a agenda já está tomada por funcionalidades e as falhas ficam para depois.
• Comprar varredura automática com nome de pentest. Se a proposta não fala em testes manuais, perfis de usuário nem exploração dos achados, provavelmente é só uma ferramenta rodando sozinha. Pergunte como o teste é feito e peça um relatório de exemplo, com os dados de outro cliente ocultados.
• Testar uma versão diferente da que vai para produção. Se o ambiente de teste não reflete a configuração real, o relatório descreve outro sistema.
• Confundir pentest com certificação. Um teste sem achados graves mostra que, naquelas datas e naquele escopo, o testador não conseguiu explorar nada sério. Não garante que o sistema é invulnerável.

Perguntas frequentes

Quanto tempo dura um pentest?

Depende do escopo: número de sistemas, APIs e perfis de usuário a testar. O teste de invasão em si costuma levar de alguns dias a algumas semanas, mas a agenda precisa incluir também a correção dos achados e o reteste. Por isso, antes de um lançamento, o pentest deve acontecer com folga, não na última semana.

Qual a diferença entre pentest e varredura de vulnerabilidades?

A varredura de vulnerabilidades é automática e encontra versões desatualizadas e configurações conhecidas. O pentest é feito por especialistas que tentam explorar as falhas à mão, inclusive de regra de negócio e de autorização, como um usuário vendo dados de outro cliente. Proposta que não fala em testes manuais nem em perfis de usuário provavelmente é só varredura.

O pentest pode derrubar o sistema em produção?

Pode haver impacto, e por isso o teste de invasão costuma ser feito num ambiente de homologação idêntico à produção. Quando é preciso testar em produção, a empresa combina com o testador horários, limites, o que não pode ser feito e contatos de emergência, e ataques de negação de serviço ficam fora do escopo, salvo quando são o objetivo.

O pentest é obrigatório pela LGPD?

A LGPD não cita o pentest pelo nome, mas exige que quem trata dados pessoais adote medidas de segurança técnicas e administrativas para protegê-los. O teste de invasão é uma das formas de demonstrar esse cuidado, e contratos com clientes ou parceiros podem exigi-lo. A necessidade no caso da sua empresa deve ser avaliada com o jurídico.

Como a Pervian Tech trabalha segurança de aplicações

Na Pervian Tech, segurança entra como requisito desde o desenho, dentro do trabalho de arquitetura de software: definimos perfis e regras de acesso, validação de entradas, registro de ações e rotina de atualização antes de escrever a primeira tela. Quando a empresa já tem um sistema em produção, começamos por um diagnóstico das áreas mais expostas e ajudamos a montar o escopo do teste de invasão.

Depois do teste, atuamos onde o PDF costuma parar: leitura do relatório em linguagem de negócio, priorização, correção da causa de cada achado, testes automatizados para que a falha não volte e acompanhamento até o reteste. Tudo é sob medida, porque o risco de cada sistema está em lugares diferentes.

O investimento é definido sob consulta, depois de um diagnóstico inicial gratuito. Se um cliente pediu um pentest ou você recebeu um relatório e não sabe por onde começar, fale com a gente. Mais conteúdo sobre o tema em Segurança e LGPD.