PCI DSS 4.0: ce cer de fapt cerințele 11.3 și 11.4 la testare

Există un moment care se repetă aproape identic la fiecare evaluare PCI DSS: documentația arată curată, diagrama de rețea are un VLAN frumos desenat „în afara perimetrului", iar evaluatorul cere să se demonstreze asta. Câteva minute mai târziu, o regulă de firewall uitată sau un salt prin stația de administrare readuce CDE-ul în aceeași rețea cu tot restul. Segmentarea nedovedită nu reduce perimetrul — îl mărește, tăcut. Exact de asta PCI DSS este singurul cadru din seria noastră de ghiduri care spune explicit „test de penetrare" și îi fixează frecvența, iar versiunea 4.0 a strâns șuruburile.

Ce intră de fapt în perimetru

Prima surpriză pentru mulți comercianți este că perimetrul nu este „serverul de plăți". Mediul de date ale deținătorilor de carduri (CDE) este doar nucleul. În perimetru intră tot ce se poate conecta la el sau îi poate influența securitatea: stații de administrare, sisteme de autentificare, soluții de monitorizare, furnizori de servicii conectați, chiar și un laptop de IT care are o sesiune deschisă către un server din CDE.

Un sistem exclus din perimetru trebuie să fie exclus și tehnic — nu doar declarat așa într-un document. Iar asta se dovedește printr-un singur lucru: testarea segmentării. De aici vine cea mai frecventă surpriză la evaluare, un VLAN considerat „separat" în documentație, dar prin care se ajunge la CDE printr-o regulă de firewall rămasă de la un proiect vechi sau printr-un salt prin stația de administrare. Fiecare astfel de cale uitată trage după ea toate cerințele PCI DSS, pentru că sistemul respectiv devine parte din perimetru.

Atenție: dacă segmentarea nu este testată și dovedită, nu ai un perimetru mai mic — ai un perimetru mai mare, cu mai multe sisteme de apărat și mai multe dovezi de produs.

Cerința 11.3 — scanarea de vulnerabilități

Cerința 11.3 este partea automată, ritmică, a conformității. Standardul cere scanări interne și externe cel puțin trimestrial și după orice schimbare semnificativă. Scanările externe trebuie făcute de un ASV (Approved Scanning Vendor) autorizat de PCI SSC — nu de orice tool de scanare cumpărat de companie. Scanările interne pot fi făcute cu resurse proprii, dar de personal independent de cel care administrează sistemele scanate.

Aici apare o confuzie care costă timp: un rezultat „trecut" nu înseamnă că scanarea a rulat fără erori sau că vulnerabilitățile au fost notate într-un registru. Înseamnă zero vulnerabilități de severitate ridicată rămase nerezolvate. Dacă raportul ASV listează o vulnerabilitate critică „acceptată", scanarea nu este trecută, indiferent cât de bine arată documentul de risc acceptat.

Independența nu este o formalitate

Cerința ca scanarea internă să fie făcută de personal independent de cel care administrează sistemele nu este birocrație. Administratorul care își scanează propriile servere are un conflict de interese subtil: tinde să excludă din scope exact acele sisteme pe care le consideră „ale lui" și sigure. Un evaluator va cere să vadă cine a rulat scanarea și cine administrează sistemele — iar dacă e aceeași persoană, cerința cade.

Cerința 11.4 — testele de penetrare

Aici standardul devine neobișnuit de specific. Nu lasă loc de interpretare: cere o metodologie documentată, testare externă și internă cel puțin anual și după schimbări semnificative de infrastructură sau aplicație, acoperirea întregului perimetru CDE și a ambelor straturi — rețea și aplicație — și corectarea vulnerabilităților exploatabile urmată de re-testare.

Diferența față de scanare este esențială. Scanarea găsește vulnerabilități cunoscute pe servicii expuse. Testul de penetrare încearcă să le exploateze, să le înlănțuie și să ajungă efectiv la datele de card. Un scanner nu va observa niciodată că o combinație de trei vulnerabilități medii — o aplicație internă cu autentificare slabă, o credențială refolosită și o regulă de firewall prea permisivă — duce direct la baza de date cu carduri. Un om cu metodologie, da. De aceea standardul le cere pe amândouă, nu una în locul celeilalte.

Furnizorii de servicii joacă după alte reguli

Pentru furnizorii de servicii, cerința 11.4.6 ridică ștacheta la testarea segmentării la fiecare șase luni, nu anual. Iar 11.4.7 adaugă testarea izolării între clienți pentru furnizorii multi-tenant — o cerință care prinde din urmă exact modelul de operare al platformelor SaaS de plăți, unde un client nu trebuie să poată ajunge, nici accidental, la datele altui client. Dacă operezi o platformă partajată, aceasta este proba pe care un QSA o va cere prima.

Cine, ce și cât de des: tabelul complet

Standardul grupează cerințele într-un mod care poate părea birocratic, dar fiecare rând are un scop. Iată cum arată în practică:

Un detaliu care se pierde des: „după schimbări semnificative" nu înseamnă doar migrarea unui server. O aplicație de plăți care primește un modul nou de checkout, o schimbare majoră de versiune la un framework sau deschiderea unui nou punct de acces în rețea pot declanșa obligația de re-testare. Calendarul trimestrial nu te scutește de testarea declanșată de schimbare.

Ce cere QSA-ul de fapt, în raport

Partea cea mai frustrantă pentru echipele tehnice este că un test de penetrare excelent, dar documentat slab, nu trece evaluarea. QSA-ul nu evaluează doar dacă ai fost testat, ci dacă poți dovedi ce s-a testat și de ce. Iată ce se cere, în ordinea în care se caută:

• Metodologia declarată și acceptată în industrie — PTES, OWASP sau NIST SP 800-115.
• Justificarea perimetrului: de ce aceste sisteme și nu altele, cu referire la diagrama de flux al datelor de card.
• Dovada că testarea a acoperit atât stratul de rețea, cât și stratul de aplicație.
• Pentru segmentare: ce controale au fost încercate din afara CDE și rezultatul fiecărei încercări.
• Re-test documentat pentru fiecare vulnerabilitate exploatabilă, cu dată și stare finală.
• Independența testerului față de echipa care administrează sistemele testate.

Ultimul punct este cel care blochează cele mai multe rapoarte. Un test făcut de echipa internă de IT, oricât de competentă, ridică întrebarea independenței. Iar lipsa re-testului documentat este a doua capcană frecventă: ai găsit vulnerabilitatea, ai remediat-o, dar nu ai dovada că ai re-testat-o și că a dispărut.

Notă: un raport care spune „am găsit 14 vulnerabilități" fără metodologie, fără scope justificat și fără re-test este, pentru evaluator, aproape echivalent cu un raport inexistent.

Ce s-a schimbat de la 3.2.1 la 4.0

Structura cerințelor de testare a fost renumerotată — 11.3 este acum scanarea, 11.4 este pentest-ul — iar o serie de cerințe considerate anterior „bune practici" au devenit obligatorii după 31 martie 2025. Au apărut cerințe noi pentru izolarea multi-tenant și pentru autentificarea multifactor. A apărut și abordarea personalizată, care permite atingerea obiectivului unei cerințe prin controale alternative — dar cu documentație și validare semnificativ mai grele, ceea ce în practică o face potrivită doar acolo unde cerința standard chiar nu se aplică.

Pentru companiile din Moldova, un lucru merită spus clar: PCI DSS nu este lege, ci o cerință contractuală impusă de schemele de carduri prin bănci și procesatori. Se aplică oricărei entități care stochează, procesează sau transmite date de card, indiferent de țară. Cerința vine de obicei prin banca acceptatoare sau prin procesatorul partener, iar nivelul de validare depinde de volumul anual de tranzacții. Am livrat testare pentru procesatori de plăți și instituții financiare din Moldova, inclusiv în procese de înregistrare la Banca Națională a Moldovei, și am văzut de aproape cum arată un perimetru CDE înainte și după o testare serioasă de segmentare.

De unde începi, practic

Dacă ai un termen PCI DSS anul acesta, ordinea corectă a pașilor nu este cea intuitivă. Nu începi cu scanarea, ci cu harta. Desenează fluxul datelor de card, marchează clar ce sisteme ating CDE-ul și validează fiecare presupunere de segmentare printr-un test real, nu printr-o diagramă. Apoi programează scanările trimestriale și testul de penetrare anual, asigurându-te că perimetrul testat corespunde cu cel documentat. În final, construiește de la bun început dosarul de dovezi — metodologie, scope, rezultate, re-test — pentru că evaluatorul nu vede munca ta, vede doar documentele pe care i le pui pe masă. Conformitatea nu este un eveniment anual, ci un proces care se dovedește prin teste repetate și documentate riguros.