Consegna dell'accesso per i test di sicurezza: perimetro, account e revoca
Un tester che chiede credenziali VPN ha bisogno di una consegna con perimetro definito, non di un login di riserva. Verificate l'autorizzazione, nominate gli obiettivi, emettete gli account e poi revocate.
Un tester chiede un indirizzo di gateway, dettagli DNS interni e credenziali VPN, e la richiesta vi viene inoltrata con oggetto «serve accesso». La richiesta da sola non vi dice se si tratta di una valutazione interna, di un test di applicazione autenticata o di un incarico su un sito pubblico in cui qualcuno ha frainteso il perimetro. Eseguite la consegna come una sequenza con un cancello a ogni passo e fermatevi al primo cancello che non si apre. Così una richiesta vaga diventa qualcosa che potete autorizzare, consegnare e poi revocare.
Cominciate dall'autorizzazione, non dalle credenziali
Prima che un indirizzo esca dalla vostra casella, stabilite chi possiede gli obiettivi e chi è autorizzato ad approvare test su di essi. Verificate il tester tramite il contatto dell'incarico che la vostra organizzazione già usa, non tramite la persona che ha inoltrato l'e-mail. Un rapporto con un cliente non è il permesso di testare ogni sistema raggiungibile da un account, e un ordine di acquisto non è un documento di perimetro.
Scrivete l'obiettivo approvato in una frase e tenetela accanto alla consegna. «Valutate l'autenticazione del portale clienti» e «valutate la rete interna» portano a pacchetti completamente diversi, e la differenza va risolta prima del provisioning, non dopo l'arrivo di un risultato. La frase vi dà anche qualcosa a cui puntare quando la richiesta cresce a metà incarico.
Se un provider di hosting o un'altra terza parte è sul percorso, i suoi requisiti vengono prima della vostra comodità. Testare l'infrastruttura altrui senza il loro permesso è un problema distinto dal testare l'applicazione che vi gira sopra.
Nominate il punto di vista e gli obiettivi
Il punto di vista è la domanda a cui la valutazione cerca di rispondere, e determina il pacchetto di accesso più di qualsiasi strumento che il tester intenda usare. Un test pubblico non autenticato richiede un URL e una finestra temporale. Un test autenticato richiede account dedicati per i ruoli specifici nel perimetro, e una valutazione interna richiede un punto d'ingresso definito con intervalli di obiettivi espliciti.
| 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 |
Dove entra un tunnel non è lo stesso fatto di quale applicazione stia dietro, e di certo non autorizza a sondare il punto d'ingresso. Ditelo esplicitamente nella consegna, perché la frase «mi hai dato accesso a quella sottorete» arriva in fretta quando un risultato viene contestato. Un elenco scritto di obiettivi è l'unica cosa che lo risolve dopo.
Date il nome host TLS insieme all'URL. Un indirizzo IP nudo costringe il tester a indovinare il nome, e un nome indovinato produce errori di certificato che vengono segnalati come risultati invece che come errore di consegna.
Emettete identità dedicate con una scadenza
Procurate account che esistano solo per questo incarico; non prestate il login quotidiano di un dipendente. Impostate la raggiungibilità di rete e i permessi dell'applicazione sulle attività concordate, organizzate l'enrollment dell'autenticazione tramite un percorso supportato e allegate una data di scadenza con una persona nominata responsabile della revoca. Consegnate le credenziali tramite un canale sicuro concordato, separatamente dal documento di perimetro che viene inoltrato in giro.
sudo useradd -m -e 2026-12-31 tester01 sudo passwd -S tester01 id tester01 lastlog -u tester01
Registrate chi ha ricevuto cosa, e quando. Quel registro è la differenza tra una consegna controllata e una password condivisa che nessuno può tracciare, ed è la prima cosa che chiunque chiede dopo un incidente. Conservatelo con il documento di perimetro invece che in un thread di chat, e annotate il canale di consegna accanto al destinatario. Una riga con marca temporale batte un ricordo ogni volta.
Il campo di scadenza è una rete di sicurezza, non il piano. Qualcuno deve comunque rimuovere il percorso di rete e il ruolo applicativo alla fine, perché un login scaduto su una rete ancora raggiungibile non è accesso revocato.
Dimostrate che la consegna funziona prima che la finestra si apra
Eseguite voi stessi il primo salto del tester, da una posizione il più vicina possibile alla sua. Risolvete il nome, controllate l'identità del certificato e confermate che il percorso raggiunga l'indirizzo previsto e non uno vicino.
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 il percorso non raggiunge un obiettivo, fermatevi e riconciliate la consegna invece di lasciare che il tester scopra un percorso alternativo. La raggiungibilità improvvisata è il modo in cui una valutazione si estende silenziosamente oltre il perimetro, e non viene quasi mai documentata dopo.
Inviate il contatto operativo, gli orari consentiti, le azioni escluse e le condizioni di arresto insieme alle credenziali. Un tester che alle 02:00 non raggiunge nessuno prenderà una decisione che non avete autorizzato, e quella decisione sarà descritta nel rapporto come se fosse nel perimetro.
NIST SP 800-115 inquadra una valutazione tecnica come test pianificati seguiti da analisi e mitigazione, ed è la forma che segue questa consegna. I cancelli qui sopra sono scelte editoriali di progettazione per un ingegnere di supporto, non una checklist citata da quella pubblicazione.
Chiudete l'incarico rimuovendo l'accesso
Revocate nell'ordine inverso al provisioning: ruoli applicativi, poi accesso di rete, poi l'identità stessa. Confermate ogni passo invece di supporre che la console abbia fatto ciò che il pulsante prometteva. Bloccate l'account prima di terminare le sue sessioni, altrimenti la sessione si riautentica semplicemente sul vecchio percorso. Poi controllate ancora una volta le connessioni stabilite prima di dichiararlo chiuso.
sudo passwd -l tester01 sudo pkill -u tester01 ss -tn state established '( sport = :443 )'
Definite gli eventuali dati di test trattenuti, poi seguite la remediation tramite il processo di reportistica concordato all'inizio. Il rapporto deve indicare l'ambiente, il livello di accesso, il perimetro e i limiti, perché registra i risultati di una valutazione e non è una dichiarazione permanente che il sito sia sicuro.
Conservate il registro di revoca con il registro della consegna. Quando si apre l'incarico successivo, volete sapere esattamente cosa è stato rimosso l'ultima volta e chi lo ha approvato, invece di ricostruire il quadro a memoria.