PCI DSS: niveluri și conformitate
1) Ce este PCI DSS și cine are nevoie de el
PCI DSS (Payment Card Industry Data Security Standard) este un standard industrial pentru securitatea cardurilor de plată (Visa, Mastercard, AmEx, Discover, JCB). Pentru iGaming, este necesar dacă:- acceptă plăți cu cardul (direct sau printr-un PSP/gateway)
- procesarea/stocarea/transferul datelor cardurilor (PAN, termen, CVV) sau a formularelor lor scurtate/criptate,
- sunt un furnizor de servicii pentru alți comercianți (găzduire, procesare, antifraudă, orchestrare de plăți etc.) dacă puteți afecta securitatea acestor carduri.
Versiune și sincronizare: versiunea curentă este PCI DSS v4. 0. Cerințe v3. 2. 1 pensionar; „future-datat” items v4. 0 sunt acum în vigoare. Nou în v4. 0: AMF îmbunătățită, „Abordare personalizată”, analiza de risc țintită a frecvenței procedurii, a segmentării și a rafinamentelor de criptare.
2) Niveluri de conformitate: comercianți și furnizori de servicii
2. 1 Negustori (negustori)
Nivelul este determinat de volumul anual al tranzactiilor cu cardul (toate canalele) si/sau de incidentele de compromis. Model tipic (conform celor mai mari scheme de plată):- Nivelul 1:> 6 milioane de tranzacții/an sau a fost compromis. Necesită anual ROC (Raport privind conformitatea) de la QSA sau ISA interne la reconciliere, + scanări trimestriale ASV.
- Nivelul 2: ~ 1-6 milioane/an. De obicei - SAQ (autoevaluare) + scanări ASV; unele scheme/achizitori pot necesita ROC.
- Nivelul 3: ~ 20k-1 milion e-commerce/an. De obicei - SAQ + ASV scanează.
- Nivelul 4: Sub pragurile L3. SAQ; cerinţele pot varia prin achiziţionarea băncii.
2. 2 Furnizori de servicii
De obicei, 2 niveluri; pentru nivelul 1 (volum mare/rol critic în lanț), este necesară o ROC de la QSA, pentru nivelul 2 - SAQ-D SP (uneori - ROC la cererea contrapărților/schemelor). În iGaming, mulți parteneri PSP/gateway/hosting sunt SP Level 1.
3) SAQ vs ROC: Cum de a alege
ROC este obligatorie pentru L1 metri și L1 SP. În alte cazuri - unul dintre SAQ:- SAQ A - numai câmpuri redirecționate/iframe/găzduite; nu există nici o procesare/transfer/stocare de carduri cu tine.
- SAQ A-EP este comerțul electronic, unde site-ul dvs. afectează securitatea paginii de plată (de exemplu, găzduiește scripturi), dar PAN este introdus în mediul furnizorului.
- SAQ B/B-IP - terminale/imprimante fără stocare electronică; B-IP - terminale conectate.
- SAQ C-VT/C - terminale virtuale/mediu de procesare mic, fără stocare.
- SAQ P2PE este doar o soluție P2PE certificată PCI.
- SAQ D (comerciant/furnizor de servicii) - opțiune „largă” pentru orice procesare/transfer/stocare, integrări personalizate, orchestratori etc.
Practica pentru iGaming: calea țintă este SAQ A/A-EP datorită fluxurilor PAN-safe, tokenization și câmpuri găzduite. Dacă aveți propriile servicii de plată/walts - de obicei SAQ D sau ROC.
4) Scoping: Ce intră în CDE și cum să-l restrângeți
CDE (Cardholder Data Environment) - sisteme în care datele cardului sunt procesate/stocate/transmise și toate segmentele conectate/influente.
Abrevierea domeniului de aplicare:- Câmpuri găzduite/iframe/TSP - Introduceți PAN în afara domeniului dvs.
- Tokenizarea și jetoanele de rețea: Serviciile dvs. operează pe jetoane, nu pe PAN.
- P2PE: criptare end-to-end cu o soluție certificată.
- Segmentarea rețelei: ACL-uri dure, izolarea CDE de restul mediului.
- Obligatoriu DLP și log mascare, interzicerea dumps cu PAN/CVV.
În v4. 0 a adăugat flexibilitate metodelor pentru atingerea obiectivelor, dar dovezile privind eficacitatea și analiza de risc orientată sunt obligatorii.
5) PCI DSS v4 "12 cerințe. "0 (adică blocuri)
1. Securitatea și segmentarea rețelei (firewall-uri, ACL, izolarea CDE).
2. Configurare securizată gazdă/dispozitiv (întărire, linii de bază).
3. Protecția datelor deținătorului cardului (stocare PAN - numai dacă este necesar, criptografie puternică).
4. Protecția datelor în timpul transmiterii (TLS 1. 2 + și echivalente).
5. Antivirus/anti-malware și controlul integrității.
6. Dezvoltare și modificare sigură (SDLC, SAST/DAST, control bibliotecă).
7. Acces după cum este necesar (cel mai puțin privilegiu, RBAC).
8. Identificare și autentificare (MFA pentru admin și acces la distanță, parole de v4. 0).
9. Securitate fizică (centre de date, birouri, terminale).
10. Logare și monitorizare (centralizarea jurnalelor, imutabilitate, alerte).
11. Testarea siguranței (ASV scanează trimestrial, pentestes anual și după modificări, test de segmentare).
12. Gestionarea politicilor și a riscurilor (proceduri, instruire, incident-răspuns, evaluări ale riscurilor, documente „Abordare personalizată”).
6) Activități obligatorii și frecvență
Scanări ASV (externe) - trimestriale și după modificări semnificative.
Vulnerabilități/patching - cicluri regulate (frecvențele sunt justificate de TRA - analiza țintită a riscurilor).
Teste de penetrare (interne/externe) - anual și după modificări semnificative; verificarea segmentării este obligatorie.
Busteni si monitorizare - continuu, cu retentie si protectie impotriva modificarilor.
Instruirea personalului - atunci când angajarea și apoi în mod regulat.
MFA - pentru toate admin și acces la distanță la CDE.
Inventarul sistemelor/fluxurilor de date - actualizați constant.
7) Matricea de selecție SAQ (scurtă)
Numai iframe/redirecționare, fără PAN → SAQ A.
E-commerce, site-ul dvs. afectează pagina de plată → SAQ A-EP.
Terminale/imprimante → SAQ B/B-IP.
Terminal virtual → SAQ C-VT.
Rețea mică "card' fără stocare → SAQ C.
soluție P2PE → SAQ P2PE.
Alte/complexe/stocare/prelucrare → SAQ D (sau ROC).
8) Artefacte și dovezi pentru audit
Pregătiți și mențineți:- Diagrame de rețea și fluxul de date, registru de active, registru de vânzători, contabilitate/registru de acces.
- Politici/proceduri: dezvoltare securizată, managementul schimbărilor, logare, incidente, vulnerabilități, chei/cripto, acces la distanță, backup-uri.
- Rapoarte: ASV, pentests (segmentare inclusiv), scanări de vulnerabilitate, rezultate de corecție.
- Jurnale/alerte: sistem centralizat, imutabilitate, analiza incidentelor.
- Crypto management: proceduri KMS/HSM, rotații, inventarul cheilor/certificatelor.
- Dovezi „Abordare personalizată” (dacă se aplică): obiective de control, metodă, măsurători de performanță, TRA.
- Contururi de responsabilitate din partea terților: parteneri AoC (PSP, hosting, CDN, anti-fraudă), matrice Responsabilitate partajată.
9) Proiectul de conformitate (pas cu pas)
1. Copiați și Gap Analysis-Define CDE, segmente adiacente, pauze curente.
2. Victorii rapide: PAN-safe stream (iframe/campuri gazduite), tokenizare, ban PAN in busteni, inchide vulnerabilitatile crete „externe”.
3. Segmentare și rețea: izolați CDE, mTLS, firewall-ACL, accesorii cu cel mai mic privilegiu, MFA.
4. Observabilitate: exploatare forestiera centralizata, retentie/lant de custodie, alerte.
5. Vulnerabilitate și gestionarea codului: SAST/DAST, patch-uri, SBOM, controlul dependenței.
6. Teste: scanări ASV, teste de penetrare interne/externe, verificare segmentare.
7. Documente și instruire: proceduri, IR-playbook-uri, training-uri, înregistrări de formare.
8. Selectarea formularului de certificare: SAQ (tip) sau ROC; să fie de acord cu achizitorul/mărcile.
9. Ciclul anual: suport, dovezi, revizuirea riscului/frecvenței, repurposing.
10) Integrarea cu arhitectura iGaming
Orchestratorul de plăți funcționează numai cu jetoane; PAN nu poate vedea.
Multi-PSP: controale de sănătate, rutare inteligentă, idempotență, ретраи; AOC din fiecare PSP.
Event-driven bus/DWH: fără PAN/CVV; mascarea ultimelor 4 cifre; Porti DLP in CI/CD.
verificări 3DS/SCA: stocați numai artefactele necesare (ID-uri de tranzacție), fără date sensibile.
11) Erori frecvente
Logare PAN/CVV și măști nevalide.
Rutare PAN „temporară” prin API-uri/autobuze interne.
Lipsa unui test de segmentare pentest.
Frecvența nerezonabilă a procedurilor (fără TRA cu v4. 0).
Dependenţa de un PSP fără AOC şi fără rezerve.
Segmente „influente” necontabilizate (admin-jump-hosts, monitorizare, backup-uri).
12) Lista de verificare a începerii rapide (iGaming)
- Du-te la câmpurile găzduite/iframe; eliminați intrarea PAN din formularele dvs.
- Activați tokenizarea/jetoanele de rețea; excludeți PAN din evenimente/jurnale.
- Efectuați copierea CDE și izolarea segmentului (MFA, RBAC, mTLS).
- Configurați jurnale centralizate și alerte (imutabilitate, retenție).
- Rula ASV scanează, elimina critic/ridicat.
- Efectuați teste de penetrare (intern/extern) + test de segmentare.
- Pregătiți politici/proceduri și dovezi de punere în aplicare.
- Sunt de acord formularul de calificare cu achizitorul (tip SAQ/ROC).
- Obțineți și păstrați AoC al tuturor vânzătorilor din Creta.
- Integrarea controalelor PCI în ciclul de eliberare (SDLC, întărirea IaC, DLP în CI/CD).
13) Întrebări frecvente scurt
Am nevoie de un QSA? Pentru ROC, da. Auto-certificarea este adesea suficientă pentru SAQ, dar mulți achizitori/mărci pot avea nevoie de un partener QSA/ASV.
Dacă nu păstrăm PAN? Încă se încadrează în PCI DSS dacă acceptați carduri. Scopul este de a realiza SAQ A/A-EP.
3DS rezolvă PCI? Nu, nu este. 3DS - despre autentificare; PCI - despre protecția datelor.
Este suficient TLS? Nu, nu este. Sunt necesare toate cerințele relevante v4. 0, inclusiv procese și dovezi.
14) Rezumat
Pentru iGaming, strategia optimă este de a minimiza domeniul de aplicare (PAN-safe, tokenization, câmpuri găzduite, P2PE acolo unde este posibil), segmentul greu CDE, automatizarea testelor de logare/vulnerabilități/penetrare, colectarea unui pachet complet de artefacte și alegerea formei corecte de confirmare (SAQ sau ROC) la nivelul dvs. Acest lucru reduce riscul, accelerează integrarea cu PSP și menține conversia și monetizarea stabile în timp ce îndeplinesc cerințele de brand card.