Entrega de acesso para testes de segurança: escopo, contas e revogação
Um testador que pede credenciais de VPN precisa de uma entrega com escopo definido, não de um login extra. Valide a autorização, nomeie os alvos, emita contas e depois revogue.
Um testador pede um endereço de gateway, detalhes de DNS interno e credenciais de VPN, e o pedido é encaminhado para você com o assunto «é preciso acesso». O pedido sozinho não lhe diz se é uma avaliação interna, um teste de aplicação autenticada ou um trabalho num site público em que alguém entendeu mal o escopo. Execute a entrega como uma sequência com uma porta em cada passo e pare na primeira porta que não se abre. Isso transforma um pedido vago em algo que pode autorizar, entregar e depois revogar.
Comece pela autorização, não pelas credenciais
Antes de qualquer endereço sair da sua caixa de entrada, estabeleça quem é dono dos alvos e quem pode aprovar testes sobre eles. Verifique o testador através do contacto do trabalho que a sua organização já usa, e não através da pessoa que reencaminhou o e-mail. Uma relação com um cliente não é permissão para testar todos os sistemas acessíveis a partir de uma conta, e uma nota de encomenda não é um documento de escopo.
Escreva o objetivo aprovado numa só frase e mantenha-a junto da entrega. «Avalie a autenticação do portal do cliente» e «avalie a rede interna» levam a pacotes completamente diferentes, e a diferença tem de ser resolvida antes do aprovisionamento, não depois de chegar um achado. A frase também lhe dá algo para apontar quando o pedido cresce a meio do trabalho.
Se houver um fornecedor de alojamento ou outro terceiro no caminho, os requisitos dele vêm antes do seu conforto. Testar a infraestrutura de outra pessoa sem a autorização dela é um problema diferente de testar a aplicação que corre nela.
Nomeie o ponto de vista e os alvos
O ponto de vista é a pergunta a que a avaliação tenta responder, e determina o pacote de acesso mais do que qualquer ferramenta que o testador planeie usar. Um teste público não autenticado precisa de um URL e de uma janela temporal. Um teste autenticado precisa de contas dedicadas para as funções concretas no escopo, e uma avaliação interna precisa de um ponto de entrada definido com intervalos de alvos explícitos.
| Viewpoint | What you hand over | What it does not authorize |
|---|---|---|
| Public website | Approved URL, TLS hostname, testing window | Internal network entry, adjacent hosts |
| Authenticated app | URL plus per-role test accounts | Other tenants, admin consoles outside scope |
| Private staging | Named private path and test accounts | Production systems behind the same gateway |
| Internal network | Entry point and written target ranges | Anything outside those ranges, including the gateway itself |
Onde um túnel entra não é o mesmo facto que que aplicação está por trás dele, e de modo algum autoriza sondar o ponto de entrada. Diga isso explicitamente na entrega, porque a frase «deste-me acesso a essa sub-rede» chega depressa quando um achado é contestado. Uma lista escrita de alvos é a única coisa que resolve isso depois.
Indique o nome do anfitrião TLS junto com o URL. Um endereço IP nu obriga o testador a adivinhar o nome, e um nome adivinhado produz erros de certificado que são reportados como achados em vez de como erro de entrega.
Emita identidades dedicadas com uma validade
Aprovisione contas que só existam para este trabalho; não empreste o login diário de um funcionário. Ajuste a alcançabilidade de rede e as permissões da aplicação às tarefas acordadas, organize o registo de autenticação por uma via suportada e anexe uma data de validade com uma pessoa nomeada responsável pela revogação. Entregue as credenciais por um canal seguro acordado, separadamente do documento de escopo que é reencaminhado por toda a gente.
sudo useradd -m -e 2026-12-31 tester01 sudo passwd -S tester01 id tester01 lastlog -u tester01
Registe quem recebeu o quê, e quando. Esse registo é a diferença entre uma entrega controlada e uma palavra-passe partilhada que ninguém consegue rastrear, e é a primeira coisa que qualquer pessoa pede após um incidente. Guarde-o junto do documento de escopo em vez de num fio de conversa, e anote o canal de entrega ao lado do destinatário. Uma linha com marca temporal ganha a uma memória todas as vezes.
O campo de validade é uma rede de segurança, não o plano. Alguém tem de remover ainda o caminho de rede e a função da aplicação no fim, porque um login expirado numa rede ainda acessível não é acesso revogado.
Prove que a entrega funciona antes de a janela abrir
Execute você mesmo o primeiro salto do testador, de uma posição o mais próxima possível da dele. Resolva o nome, verifique a identidade do certificado e confirme que o caminho chega ao endereço pretendido e não a um vizinho.
dig +short app.example.com openssl s_client -connect app.example.com:443 -servername app.example.com </dev/null> 2>/dev/null | openssl x509 -noout -subject -dates ip route get 10.60.0.25
Se o caminho não conseguir alcançar um alvo, pare e reconcilie a entrega em vez de deixar o testador descobrir uma rota alternativa. A alcançabilidade improvisada é a forma como uma avaliação se expande silenciosamente para além do seu escopo, e quase nunca é documentada depois.
Envie o contacto operacional, as horas permitidas, as ações excluídas e as condições de paragem junto com as credenciais. Um testador que não consegue contactar ninguém às 02:00 tomará uma decisão que você não autorizou, e essa decisão será descrita no relatório como se estivesse dentro do escopo.
NIST SP 800-115 enquadra uma avaliação técnica como testes planeados seguidos de análise e mitigação, e é essa a forma que esta entrega segue. As portas acima são decisões editoriais de conceção para um engenheiro de suporte, não uma lista de verificação citada dessa publicação.
Encerre o trabalho removendo o acesso
Revogue pela ordem inversa do aprovisionamento: funções da aplicação, depois acesso de rede, depois a própria identidade. Confirme cada passo em vez de assumir que a consola fez o que o botão prometia. Bloqueie a conta antes de matar as sessões, ou a sessão simplesmente reautentica-se pelo caminho antigo. Depois verifique as ligações estabelecidas mais uma vez antes de o declarar encerrado.
sudo passwd -l tester01 sudo pkill -u tester01 ss -tn state established '( sport = :443 )'
Resolva os dados de teste retidos e depois acompanhe a remediação através do processo de relatórios acordado no início. O relatório deve indicar o ambiente, o nível de acesso, o escopo e as limitações, porque registra achados de uma avaliação e não é uma declaração permanente de que o site é seguro.
Guarde o registo de revogação junto do registo da entrega. Quando o próximo trabalho abrir, vai querer saber exatamente o que foi removido da última vez e quem o aprovou, em vez de reconstruir o quadro de memória.