Cuprins
În 30 de secunde
- Un pentest e o metodă de a obține asigurare asupra securității unui sistem, nu în primul rând de a găsi vulnerabilități; obiectivul se scrie înainte de perimetru 1.
- Perimetrul se fixează în scris, cu limitele tehnice ale testului și cu excluderile explicite 1.
- Testul în producție e posibil și uneori cerut (TLPT în DORA, BNM pct. 33.3), dar planificat și agreat cu conducerea 456.
- Cu cât testerul primește mai puține informații, cu atât mai mult din timpul plătit merge pe descoperire și pot rămâne vulnerabilități negăsite 1.
- Regulile pentru datele întâlnite și pentru păstrarea dovezilor se stabilesc înainte de test, nu după 2.
De ce contează pregătirea
Un test de penetrare se plătește pe zile de specialist. Cât din acele zile ajunge în testare efectivă și cât se pierde pe așteptat acces, clarificat perimetrul și căutat persoana care poate aproba ceva se decide înainte de început. Din practica noastră, prima zi a unui test nepregătit se duce aproape întreagă pe conturi și acorduri.
NCSC, autoritatea britanică de securitate cibernetică, descrie testul de penetrare ca pe o metodă de a obține asigurare că sistemul rezistă unei încercări de a-i încălca securitatea, nu ca pe principalul mijloc de a găsi vulnerabilități 1. Diferența contează la pregătire: asigurarea se cere pentru un obiectiv anume, iar obiectivul hotărăște tot restul.
1. Obiectivul, înaintea perimetrului
Un test comandat „ca să avem un raport” și unul comandat „ca să aflăm dacă cineva poate ajunge la datele clienților” arată diferit din prima zi. Formulați obiectivul într-o propoziție, iar furnizorul își construiește planul în jurul ei:
- conformitate cu un cadru anume (PCI DSS, ISO 27001, DORA, Legea 48/2023);
- verificarea unei lansări sau a unei schimbări majore;
- cerința unui client sau a unui partener;
- măsurarea detecției: dacă echipa vede atacul și reacționează.
2. Perimetrul, în scris și complet
NCSC recomandă ca etapa de definire a perimetrului să se încheie cu un document care stabilește, printre altele, limitele tehnice ale testului 1. Concret, documentul cuprinde:
- domeniile, subdomeniile și adresele IP incluse — și, explicit, cele excluse;
- aplicațiile și API-urile, cu versiunea și mediul pe care rulează;
- cine deține fiecare sistem: dacă găzduirea e la un furnizor extern, aveți nevoie de acordul lui;
- sistemele terțe integrate — plăți, identitate — care nu se testează fără acordul lor.
3. Producție sau copie
Testarea în producție dă rezultate reale, dar cere reguli de precauție și o fereastră agreată. Pentru unele organizații nu e opțională:
| Cadrul | Ce spune despre producție |
|---|---|
| DORA, art. 26 | TLPT se face pe sisteme de producție live, cu controale de risc stabilite de entitate 4 |
| BNM, pct. 33.3 | Testele de penetrare după scenarii validate, pe producție live 5 |
| ISO 27001, 8.34 | Testele pe sistemele în funcțiune se planifică și se convin între tester și conducere 6 |
| Ghidul PCI | Limitările — ferestre orare, lățime de bandă, sisteme vechi — se scriu în raport 2 |
O copie de preproducție elimină riscul operațional, cu condiția să fie identică: aceleași versiuni, aceleași reguli de firewall, aceeași configurație de autentificare — altfel testați un sistem care nu există. Datele contează la fel de mult: un mediu cu trei înregistrări nu permite verificarea autorizării între clienți. Pregătiți un set realist, anonimizat.
4. Câtă informație dați testerului
În practică se folosesc trei variante: black box — testerul pornește fără informații, ca un atacator din afară; grey box — primește conturi de test și o documentație de bază; white box — are acces și la cod sau la configurații. NCSC avertizează că lipsa informațiilor poate face ca unele vulnerabilități să rămână negăsite în timpul alocat 1. Din practica noastră, grey box dă cel mai mult pe zi plătită; black box are sens doar când vreți exact perspectiva unui atacator din afară.
5. Conturile și accesul
- Două conturi pentru fiecare rol de utilizator: testul pentru referințe directe nesigure la obiecte (IDOR) din ghidul OWASP verifică dacă un utilizator ajunge la obiectele altuia, ceea ce cere cel puțin doi utilizatori 78.
- Conturi care nu expiră și nu se blochează după câteva încercări eșuate.
- MFA rezolvat dinainte — altfel prima zi se duce pe coduri SMS.
- Acces VPN sau adrese permise în firewall, dacă testul e intern.
- Documentația: diagrama de arhitectură, specificația API, lista de roluri. Nu trebuie să fie frumoasă, trebuie să fie corectă.
6. Regulile de angajament
Regulile de angajament spun ce are voie testerul să facă și ce nu. Fără ele, o acțiune legitimă de testare poate declanșa o procedură de incident sau o problemă contractuală cu furnizorul de găzduire.
| Punct | Ce se stabilește |
|---|---|
| Fereastra de testare | Zilele și orele în care se poate testa, în afara vârfului de trafic |
| Tehnici excluse | De obicei blocarea serviciului (DoS) și ștergerea de date |
| Criterii de oprire | Ce oprește testul pe loc și cine decide |
| Raportare imediată | Ce gravitate se comunică pe loc, nu în raportul final |
| Adresele testerilor | IP-urile de la care vine traficul de test, ca echipa să-l deosebească de un atac real |
| Datele și dovezile | Ce se poate extrage, cum se păstrează dovezile și când se distrug — stabilit înainte de test 2 |
| Curățarea | Ce lasă testerul în urmă (conturi, fișiere) și cum se șterge 2 |
7. Oamenii
Trei roluri, cu nume și număr de telefon: un contact tehnic care rezolvă un acces blocat în aceeași zi, un decident care aprobă extinderea perimetrului sau oprirea testului și un contact de urgență disponibil în afara orelor. Hotărâți și dacă echipa de operare e anunțată: dacă nu, testul măsoară și detecția, dar cineva din conducere trebuie să știe.
Pe partea furnizorului, NCSC recomandă ca testele făcute de terți să fie executate doar de personal calificat și cu experiență 1. Cereți numele și certificările testerilor înainte de semnare.
Lista de pregătire, pe tipul testului
Fiecare tip de test cere altceva. Alegeți-l pe al dumneavoastră și bifați ce aveți deja gata; lista vine cu dumneavoastră în cererea de ofertă.
Lista de pregătire, pe tipul testului
Alegeți tipul testului și mediul; bifați ce aveți gata. Bifele rămân doar în pagina deschisă, nu se trimit nicăieri.
0 din 0 pregătite
De început Pe drum Gata de start lista pregătită Trimiteți lista cu cererea de ofertă →8. Ce urmează după raport
Un raport livrat fără timp alocat pentru remediere rămâne un document. NCSC recomandă ca raportul să cuprindă o metodă de rezolvare pentru fiecare problemă găsită, dar amintește că evaluarea riscului și decizia de a aplica corecțiile rămân ale organizației 1. Planificați din start:
- Prezentarea raportului
O ședință în care echipa tehnică întreabă direct testerii.
- Fereastra de remediere
Capacitate de dezvoltare rezervată pentru intervalul de după test.
- Re-testul
Confirmarea scrisă că problemele au fost închise; ghidul PCI descrie și un raport de re-test separat 2.
- Păstrarea rezultatelor
PCI DSS cere păstrarea rezultatelor testelor și a remedierilor cel puțin 12 luni (11.4.1) 3.
Întrebări frecvente
Cât durează pregătirea unui test de penetrare?
Trebuie să anunț echipa internă că are loc un test?
Testul se face pe producție sau pe un mediu de test?
De ce are nevoie testerul de două conturi pe fiecare rol?
Ce se întâmplă cu datele pe care testerul le găsește?
Surse
Fiecare afirmație despre lege sau standard trimite la sursa ei oficială. Consultate la data indicată.
- NCSC — Penetration testing (ghid)ncsc.gov.uk · consultat 23 octombrie 2026
- PCI SSC — Information Supplement: Penetration Testing Guidance v1.1 (2017)pcisecuritystandards.org · consultat 23 octombrie 2026
- PCI DSS v4.0.1 — SAQ D pentru furnizori de servicii, r2 (textul cerinței 11.4.1)pcisecuritystandards.org · consultat 23 octombrie 2026
- Regulamentul (UE) 2022/2554 (DORA), art. 26eur-lex.europa.eu · consultat 23 octombrie 2026
- BNM — Regulamentul privind cerințele minime pentru gestionarea riscurilor TIC (HCE nr. 29/2025)bnm.md · consultat 23 octombrie 2026
- ISO/IEC 27001:2022 — Securitatea informației, cerințe (controlul 8.34)iso.org · consultat 23 octombrie 2026
- OWASP Web Security Testing Guide (WSTG) v4.2owasp.org · consultat 23 octombrie 2026
- WSTG-ATHZ-04 — referințe directe nesigure la obiecte (IDOR)owasp.org · consultat 23 octombrie 2026
Despre autori
Ghidurile le scrie echipa care face testele, nu un departament de marketing. Le actualizăm când se schimbă legea, standardul sau ce vedem în teste.