Predarea accesului pentru testarea de securitate: scop, conturi și revocare
Un tester care cere acreditări VPN are nevoie de o predare cu scop definit, nu de o autentificare de rezervă. Verificați autorizarea, numiți țintele, emiteți conturi și apoi revocați.
Un tester cere o adresă de gateway, detalii DNS interne și acreditări VPN, iar cererea vă este transmisă cu subiectul „este nevoie de acces”. Cererea în sine nu vă spune dacă este o evaluare internă, un test al unei aplicații autentificate sau o lucrare pe un site public în care cineva a înțeles greșit scopul. Derulați predarea ca o succesiune cu o poartă la fiecare pas și opriți-vă la prima poartă care nu se deschide. Astfel o cerere vagă devine ceva ce puteți autoriza, preda și revoca mai târziu.
Începeți cu autorizarea, nu cu acreditările
Înainte ca vreo adresă să vă părăsească inboxul, stabiliți cine deține țintele și cine are voie să aprobe testarea pe ele. Verificați testerul prin contactul proiectului pe care organizația dumneavoastră îl folosește deja, nu prin persoana care a redirecționat e-mailul. O relație cu un client nu este permisiunea de a testa fiecare sistem accesibil dintr-un cont, iar o comandă de achiziție nu este un document de scop.
Scrieți obiectivul aprobat într-o singură propoziție și țineți-o lângă predare. „Evaluați autentificarea portalului clientului” și „evaluați rețeaua internă” duc la pachete complet diferite, iar diferența trebuie lămurită înainte de pregătire, nu după ce apare o constatare. Propoziția vă dă și ceva la care să arătați când cererea crește la mijlocul lucrării.
Dacă pe traseu este un furnizor de găzduire sau o altă terță parte, cerințele lor vin înaintea confortului dumneavoastră. Testarea infrastructurii altcuiva fără permisiunea lui este o problemă separată de testarea aplicației care rulează pe ea.
Numiți punctul de vedere și țintele
Punctul de vedere este întrebarea la care evaluarea încearcă să răspundă și determină pachetul de acces mai mult decât orice instrument pe care testerul intenționează să îl folosească. Un test public neautentificat are nevoie de un URL și de o fereastră de timp. Un test autentificat are nevoie de conturi dedicate pentru rolurile concrete din scop, iar o evaluare internă are nevoie de un punct de intrare definit, cu intervale de ținte explicite.
| 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 |
Locul pe unde intră un tunel nu este același fapt cu ce aplicație stă în spatele lui și cu siguranță nu autorizează sondarea punctului de intrare. Spuneți asta explicit în predare, pentru că fraza „mi-ai dat acces la subrețeaua aceea” apare repede când o constatare este contestată. O listă scrisă de ținte este singurul lucru care lămurește asta ulterior.
Dați numele de gazdă TLS împreună cu URL-ul. O adresă IP simplă îl obligă pe tester să ghicească numele, iar un nume ghicit produce erori de certificat raportate ca constatări, nu ca o greșeală de predare.
Emiteți identități dedicate cu o dată de expirare
Pregătiți conturi care există doar pentru această lucrare; nu împrumutați autentificarea zilnică a unui angajat. Setați accesibilitatea rețelei și permisiunile aplicației pentru sarcinile convenite, organizați înregistrarea autentificării pe o cale suportată și atașați o dată de expirare cu o persoană numită responsabilă de revocare. Predați acreditările printr-un canal securizat convenit, separat de documentul de scop care este redirecționat peste tot.
sudo useradd -m -e 2026-12-31 tester01 sudo passwd -S tester01 id tester01 lastlog -u tester01
Înregistrați cine a primit ce, și când. Acea evidență este diferența dintre o predare controlată și o parolă partajată pe care nimeni nu o poate urmări, și este primul lucru pe care îl cere oricine după un incident. Păstrați-o lângă documentul de scop, nu într-un fir de chat, și notați canalul de livrare lângă destinatar. O linie cu marcă de timp câștigă mereu în fața unei amintiri.
Câmpul de expirare este o plasă de siguranță, nu planul. Cineva tot trebuie să elimine calea de rețea și rolul aplicației la final, pentru că o autentificare expirată pe o rețea încă accesibilă nu este acces revocat.
Dovediți că predarea funcționează înainte de deschiderea ferestrei
Executați dumneavoastră primul salt al testerului, dintr-o poziție cât mai apropiată de a lui. Rezolvați numele, verificați identitatea certificatului și confirmați că traseul ajunge la adresa intenționată, nu la una vecină.
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
Dacă traseul nu poate ajunge la o țintă, opriți-vă și reconciliați predarea, în loc să lăsați testerul să descopere o rută alternativă. Accesibilitatea improvizată este felul în care o evaluare se extinde în tăcere dincolo de scop, și aproape niciodată nu este documentată după aceea.
Trimiteți contactul operațional, orele permise, acțiunile excluse și condițiile de oprire împreună cu acreditările. Un tester care la 02:00 nu poate contacta pe nimeni va lua o decizie pe care nu ați autorizat-o, iar decizia va fi descrisă în raport ca și cum ar fi fost în scop.
NIST SP 800-115 încadrează o evaluare tehnică drept testări planificate urmate de analiză și atenuare, iar aceasta este forma pe care o urmează predarea de față. Porțile de mai sus sunt decizii editoriale de proiectare pentru un inginer de suport, nu o listă de verificare citată din acea publicație.
Închideți lucrarea eliminând accesul
Revocați în ordinea inversă a pregătirii: rolurile aplicației, apoi accesul la rețea, apoi identitatea în sine. Confirmați fiecare pas în loc să presupuneți că consola a făcut ce promitea butonul. Blocați contul înainte de a-i opri sesiunile, altfel sesiunea se reautentifică pur și simplu pe traseul vechi. Apoi verificați încă o dată conexiunile stabilite înainte de a declara totul închis.
sudo passwd -l tester01 sudo pkill -u tester01 ss -tn state established '( sport = :443 )'
Soluționați orice date de test reținute, apoi urmăriți remedierea prin procesul de raportare convenit la început. Raportul trebuie să precizeze mediul, nivelul de acces, scopul și limitările, pentru că înregistrează constatări dintr-o singură evaluare și nu este o declarație permanentă că site-ul este sigur.
Păstrați evidența revocării împreună cu evidența predării. Când se deschide următoarea lucrare, veți vrea să știți exact ce a fost eliminat ultima dată și cine a aprobat, în loc să reconstruiți imaginea din memorie.