Um teste de intrusão é útil quando responde a uma pergunta de segurança delimitada e termina com correções verificadas. Contratar «um pentest ao sistema» sem definir contas, aplicações, ambientes e regras pode produzir um relatório extenso que deixa precisamente o percurso mais arriscado por analisar. O primeiro resultado a preparar é, por isso, uma autorização operacional compreensível por quem testa e por quem mantém o serviço.
Este guia permite escrever um âmbito, estabelecer regras de execução e aceitar os resultados de um teste autorizado. O exemplo é fictício e centra-se num portal de clientes. Os mesmos campos podem ser adaptados a uma rede interna ou aplicação móvel, sem presumir que todas as técnicas são adequadas a todos os ambientes.
Escolher o tipo de avaliação que responde à pergunta
Uma análise de vulnerabilidades procura problemas conhecidos e configurações suscetíveis de verificação sistemática. Um teste de intrusão acrescenta avaliação humana e validação controlada de percursos de ataque dentro de um âmbito autorizado. Uma revisão de código pode esclarecer uma falha que depende da lógica interna. Um exercício de equipa vermelha avalia objetivos e capacidades de deteção mais amplos, exigindo preparação própria.
Estes trabalhos podem complementar-se. Um relatório de um scanner não se transforma num teste manual porque recebeu um título diferente. Em contrapartida, uma análise automatizada bem delimitada pode ser suficiente para uma pergunta estreita, como verificar uma configuração conhecida em todos os servidores inventariados. Peça ao prestador que associe o método à pergunta, em vez de selecionar apenas o nome comercial do serviço.
O NIST SP 800-115, publicado em 2008, oferece uma referência metodológica para planear avaliações e tratar resultados. A sua antiguidade exige usar documentação técnica atual para produtos e vulnerabilidades concretas. Para aplicações web, o OWASP Web Security Testing Guide organiza cenários de avaliação; indique a versão utilizada para que o relatório continue interpretável.
Relacionar o teste com obrigações e riscos reais
O artigo 32.º do RGPD inclui a avaliação regular da eficácia das medidas de segurança. Não determina, para todas as organizações, um pentest anual, um fornecedor específico ou um número fixo de dias de trabalho. Requisitos setoriais, contratuais ou relativos a sistemas particulares devem ser analisados no respetivo âmbito.
Defina a prioridade a partir do dano possível. Um portal que permite consultar documentos de outros clientes merece atenção diferente de uma página pública sem autenticação. Uma integração nova pode alterar mais o risco do que uma alteração visual. O anexo de medidas técnicas e organizativas ajuda a identificar as garantias que o teste deve pôr à prova e os controlos que exigem outro método de avaliação.
Escrever um âmbito que não deixe dúvidas
Identifique aplicações, endereços, ambientes, versões e proprietários. Domínios e endereços IP podem apontar para infraestrutura partilhada, serviços externos ou sistemas que a entidade contratante não tem autoridade para autorizar. Confirme estas relações antes do início, incluindo as condições do fornecedor de alojamento e as autorizações necessárias de terceiros.
Liste as funções e os percursos incluídos: autenticação, recuperação de conta, consulta, alteração, exportação e interfaces de integração. Para um serviço com vários clientes, indique se a separação entre organizações faz parte da avaliação. Uma análise apenas sem autenticação não cobre as permissões de um utilizador normal ou de um administrador.
Use a cartografia de sistemas e dependências para identificar fronteiras. Uma ligação para pagamentos pode abrir um serviço externo que fica excluído, enquanto a integração que prepara o pedido continua incluída. Escreva ambas as decisões. Uma exclusão deve tornar visível a limitação do resultado, sem desaparecer na apresentação final à direção.
Exemplo preenchido de âmbito e regras
Uma empresa fictícia vai publicar um portal para clientes profissionais consultarem pedidos e descarregarem documentos. A pergunta principal é se uma conta de um cliente consegue aceder aos documentos de outro. O teste inclui também recuperação de acesso e permissões do operador de apoio.
| Campo | Decisão de exemplo |
|---|---|
| Objeto | Versão candidata do portal CLIENTES e respetiva API de documentos |
| Ambiente | Pré-produção, com configuração comparada com a produção e dados sintéticos |
| Contas | Dois clientes fictícios distintos e um operador de apoio com permissões limitadas |
| Percursos | Início de sessão, recuperação de conta, consulta, descarga e exportação autorizada |
| Exclusões | Serviço de pagamentos externo e contas reais de trabalhadores |
| Técnicas condicionadas | Qualquer operação que possa degradar a disponibilidade exige autorização adicional |
| Interrupção | Erros anormais, contacto com dados reais ou descoberta de um alvo fora do âmbito |
| Comunicação urgente | Contacto técnico e substituto identificados; confirmação de receção pelo canal acordado |
| Evidência | Apenas dados sintéticos e elementos mínimos que demonstrem o problema |
| Encerramento | Relatório, reunião de interpretação, correções prioritárias e nova verificação |
As condições são escolhas do projeto. A pré-produção reduz riscos, mas pode esconder uma configuração específica da produção. O relatório deve identificar diferenças relevantes, como serviço de identidade, regras de rede ou distribuição de ficheiros. A equipa decide depois que verificações adicionais, estritamente autorizadas, são necessárias no ambiente real.
Preparar a execução e a capacidade de parar
Antes do início, confirme contas de teste, versões, acessos e disponibilidade das pessoas de contacto. Uma janela reservada perde utilidade se a equipa passa metade do período à espera de uma palavra-passe. Faça uma breve validação de acesso e congele o âmbito aprovado; alterações posteriores ficam registadas com o respetivo impacto.
Defina limites técnicos de carga e operações que podem modificar dados. O prestador deve saber que ações exigem aprovação suplementar, sem interpretar silêncio como consentimento. Um teste de engenharia social, acesso físico ou simulação de indisponibilidade não fica autorizado por uma referência genérica a «técnicas habituais».
Combine um mecanismo de interrupção utilizável por ambas as partes. No exemplo, o contacto com um registo real suspende o percurso afetado, desencadeia aviso e permite decidir como preservar a evidência mínima. Se surgir um incidente real durante o teste, a equipa distingue os eventos do exercício e aplica o processo de resposta pertinente. Não classifique automaticamente toda a atividade suspeita como parte do trabalho contratado.
A organização dos registos de segurança permite reconstruir o que aconteceu. Determine antecipadamente os elementos necessários para correlacionar ações autorizadas com alertas, sem desativar indiscriminadamente a deteção. Se alguns responsáveis desconhecem o exercício para avaliar a resposta, a coordenação reservada e os limites devem continuar claros para quem tem poder de o interromper.
Proteger os dados e o próprio relatório
Prefira dados sintéticos que representem os formatos e relações importantes. Copiar uma base real para testes pode acrescentar exposição sem melhorar a validade do cenário. Quando o uso de dados pessoais for necessário, delimite as operações, os acessos, a conservação e o enquadramento contratual apropriado. A qualificação do prestador depende das funções efetivas, não apenas da designação «auditor».
As provas devem demonstrar a falha com o mínimo de conteúdo. Uma captura de ecrã com centenas de clientes raramente é necessária para provar acesso indevido a um documento. Defina canal cifrado de entrega, destinatários, local de armazenamento e eliminação das cópias de trabalho. O relatório contém informação sensível sobre a defesa da organização e precisa de proteção própria.
Inclua no encerramento a revogação das contas criadas e a remoção de artefactos de teste. A equipa técnica confirma que não ficaram permissões temporárias, integrações abertas ou ficheiros de demonstração. Relacione esta verificação com a configuração segura dos sistemas para evitar que o exercício deixe um desvio permanente à configuração aprovada.
Exigir um relatório que permita decidir e corrigir
Cada ocorrência deve indicar o objeto afetado, as condições em que surgiu, o impacto demonstrado, a evidência mínima e uma recomendação acionável. Diferencie uma hipótese, uma vulnerabilidade validada e uma limitação que impediu a avaliação. Uma pontuação técnica pode ajudar a ordenar, mas o impacto no serviço e nos titulares precisa de interpretação contextual.
No exemplo do portal, uma falha permite ao cliente fictício A descarregar um documento do cliente B. O relatório identifica a operação afetada e o controlo de autorização ausente, sem expor dados reais. A correção deve verificar a autorização no servidor para o objeto pedido; ocultar o botão na interface não resolve o problema. A nova verificação inclui acesso permitido e acesso que deve ser recusado.
Peça também uma lista dos percursos efetivamente analisados e dos que ficaram por analisar. «Sem vulnerabilidades críticas encontradas» é uma conclusão limitada pelo tempo, pelo âmbito e pelos métodos utilizados. Não equivale a uma garantia de ausência de vulnerabilidades nem a uma certificação global de conformidade.
Aceitar resultados e acompanhar a correção
Aceitar a entrega significa confirmar que o trabalho contratado foi realizado e documentado. Não significa aceitar todos os riscos encontrados. Separe estas decisões: a equipa pode aceitar o relatório e impedir a publicação até uma falha ser corrigida. Registe quem decide, com que informação e que condições precisam de ser satisfeitas.
A política de segurança da informação deve definir a responsabilidade por prioridades e exceções. Atribua cada ocorrência a uma pessoa, estabeleça uma data interna coerente com o risco e identifique medidas temporárias. Depois, confirme a correção por nova verificação adequada; uma tarefa marcada como concluída pelo programador não demonstra sozinha o resultado.
Para comparar propostas, peça o mesmo âmbito, perfis, métodos, entregáveis e condições de nova verificação. Considere preparação interna, disponibilidade de especialistas e trabalho de correção no orçamento. Não existe um preço universal que permita concluir, por si só, que o trabalho é suficiente. Um projeto bem contratado deixa uma cadeia clara entre pergunta inicial, execução autorizada, ocorrência demonstrada e proteção efetivamente melhorada.