Livelli e conformità PCI DSS
1) Cos'è un DSS PCI e chi ne ha bisogno
PCI DSS (Payment Card Industry Data Security Standard) è uno standard industriale per la sicurezza delle carte di pagamento (Visa, Mastercard, AmEx, Discover, JCB). È obbligatorio se lei:- accetta pagamenti con carte (direttamente o tramite PSP/gateway),
- elaborare/memorizzare/trasmettere i dati di carta (PAN, scadenza, CVV) o i relativi moduli ridotti/crittografati,
- è un provider di servizi per altri merchant (hosting, processing, anti-frod, pianificazione dei pagamenti, ecc.) se si può influire sulla sicurezza dei dati delle carte.
Versione e data: la versione attuale è PCI DSS v4. 0. Requisiti v3. 2. 1 fuori uso; «future-dated» v4. 0 ora funzionano. Nuovo in v4. 0: MFA rinforzata, «Customized Approach», analisi targata rischio della frequenza delle procedure, perfezionamento della segmentazione e crittografia.
2) Livelli di conformità: misuratori e provider di servizi
2. 1 Merchant (commercianti)
Il livello è determinato dal volume annuo di transazioni su carte (tutti i canali) e/o da incidenti di compromissione. Modello tipico (secondo i maggiori circuiti di pagamento):- Level 1:> 6 milioni di transazioni/anno o compromissione. Richiede ROC annuo (Report on Compliance) da QSA o ISA interno durante la negoziazione, + scan ASV trimestrali.
- Level 2: not 1-6 milioni/anno. Solitamente - SAQ (autostima) + ASV-scan; alcuni schemi/equaieri possono richiedere ROC.
- Level 3:} 20k-1 milione di e-commerce/anno. Solitamente SAQ + ASV-scan.
- Level 4: sotto le soglie L3. SAQ; i requisiti possono variare in base al barattolo equier.
2. 2 Provider di servizi (Service Provider)
Generalmente di livello 2; per Level 1 (grande volume/ruolo critico nella catena), ROC di QSA è obbligatorio, per Level 2 è SAQ-D SP (talvolta ROC su richiesta di controparti/schemi). Nel iGaming molti PSP/gateway/partner di hosting - SP Level 1.
3) SAQ vs ROC: come scegliere
ROC è obbligatorio per i merchant L1 e SP L1. In altri casi, uno della SAQ:- SAQ A - solo redirect/iframe/hosted fields; non avete l'elaborazione/trasferimento/memorizzazione delle carte.
- SAQ A-EP - e-commerce, dove il tuo sito influisce sulla sicurezza della pagina di pagamento (ad esempio, gli script hostit), ma PAN viene immesso nell'ambiente del provider.
- SAQ B/B-IP - terminali/importatori senza storage elettronico Terminali collegati B-IP.
- SAQ C-VT/C - terminali virtuali/piccoli ambienti di elaborazione, senza storage.
- SAQ P2PE è solo una soluzione PCI certificata P2PE.
- SAQ D (Merchant/Service Provider) è un'opzione «ampia» per qualsiasi tipo di elaborazione/trasferimento/archiviazione, integrazioni di custome, orchestratori, ecc.
Il percorso di destinazione è SAQ A/A-EP grazie ai flussi PAN-safe, al tornasole e ai campi host. Se si dispone di servizi di pagamento/valt personalizzati, solitamente SAQ D o ROC.
4) Coping: cosa entra nel CDE e come restringerlo
CDE (Cardholder Data Environment) - Tutti i segmenti connessi/influenti vengono elaborati/memorizzati/trasferiti.
Riduzione scoop:- Hosted fields/iframe/TSP: input PAN fuori dal tuo dominio.
- Tokening e network tokens: i tuoi servizi operano token, non PAN.
- P2PE: crittografia fine-fine con una soluzione certificata.
- Segmentazione della rete: ACL rigide, isolamento CDE dal resto dell'ambiente.
- DLP obbligatorio e occultamento dei fogli, disattivazione dei dampi con PAN/CVV.
Nel v4. 0 è stata aggiunta la flessibilità dei metodi per raggiungere gli obiettivi, ma le prove di efficacia e l'analisi targata rischio sono obbligatorie.
5) «12 requisiti» PCI DSS v4. 0 (blocchi di significato)
1. Protezione di rete e segmentazione (file, ACL, isolamento CDE).
2. Configurazione sicura host/dispositivi (hardning, linee base).
3. Protezione dei dati dei titolari di carte (storage PAN solo se necessario, crittografia forte).
4. Protezione dei dati in trasferimento (TLS 1. 2 + e equivalenti).
5. Antivirus/anti-malware e controllo dell'integrità.
6. Sviluppo e modifica sicuri (SDLC, SAST/DAST, DAST).
7. Accesso per necessità (least privilege, RBAC).
8. Identificazione e autenticazione (MFA per accesso admin e remoto, password v4. 0).
9. Sicurezza fisica (data center, uffici, terminali).
10. Loging e monitoraggio (centralizzazione dei logi, invariabilità, alert).
11. Test di sicurezza (ASV-Scan trimestrali, pentesti annuali e successivi, test di segmentazione).
12. Gestione delle politiche e dei rischi (procedure, formazione, incidente-rispetto, rischi-valutazione, documenti «Customized Approach»).
6) Attività obbligatorie e frequenza
Gli scani ASV (esterni) sono trimestrali e successivi a modifiche significative.
Vulnerabilità/patching - cicli regolari (le frequenze sono stabilite da TRA - targeted risk analysis).
Pentesti (intravedimenti/cerchi) - ogni anno e dopo cambiamenti significativi; il controllo della segmentazione è obbligatorio.
I registri e il monitoraggio sono costanti e protetti dalle modifiche.
Formazione del personale - all'assunzione e a seguire regolarmente.
MFA - per tutto l'accesso adminiano e remoto al CDE.
Inventario di sistemi/flussi di dati - Aggiornare costantemente.
7) matrice di selezione SAQ (breve)
Solo iframe/readyrett, senza PAN hai un SAQ A.
E-commerce, il tuo sito influisce sulla pagina di pagamento della SAQ A-EP.
Terminali/importatori → SAQ B/B-IP.
Terminale virtuale SAQ C-VT.
Una piccola rete di carte senza → SAQ C.
Soluzione P2PE → SAQ P2PE.
Diverso/complesso/elaborazione del → SAQ D (o ROC).
8) Manufatti e prove per il controllo
Preparare e supportare:- Diagrammi di rete e flussi di dati, registro delle risorse, registro dei fornitori, registro dei dati/disponibilità.
- Regole/procedure: sviluppo sicuro, gestione delle modifiche, loging, incidenti, vulnerabilità, chiavi/cripto, accesso remoto, backup.
- Report: ASV, pentesti (segmentazione inclusa), scansioni di vulnerabilità, risultati delle modifiche.
- Riviste/alert, sistema centralizzato, invariabile, controllo degli incidenti.
- Crypto Management: procedure KMS/HSM, rotazioni, inventario chiavi/certificati.
- Prove di Customized Approach (se applicato): obiettivi di controllo, metodo, metriche di efficienza, TRA.
- Tracciati di responsabilità da terzi: partner PSP, hosting, CDN, anti-frod, matrice Shared Responibility.
9) Progetto di conformità (passo passo)
1. Copia e analisi GAP - Definisce CDE, segmenti adiacenti, interruzioni correnti.
2. Vincite veloci: PAN-safe flusso (iframe/hosted fields), tornitura, disabilitazione PAN nel cavo, chiusura delle vulnerabilità crit «esterne».
3. Segmentazione e rete: isola CDE, mTLS, firewall-ACL, accesso least-privilege, MFA.
4. Osservabilità: logica centralizzata, retenza/catena di sicurezza, alert.
5. Gestione delle vulnerabilità e del codice: SAST/DAST, patch, SBOM, controllo delle dipendenze.
6. Test: scani ASV, pentesti interni/esterni, controllo di segmentazione.
7. Documenti e formazione: procedure, playbook IR, corsi di formazione, registrazioni di formazione.
8. Selezione del modulo di certificazione SAQ (tipo) o ROC; concordare con l'equayer/marchi.
9. Ciclo annuale: supporto, prove, revisione dei rischi/frequenze, ripetizione.
10) Integrazione con l'architettura dell' iGaming
L'orchestratore di pagamento funziona solo con i token; PAN non vede.
Multi-PSP: health-checks, smart-routing, idempotency, ретраи; AoC da ogni PSP.
Bus Event-driven/DWH: niente PAN/CVV; occultamento degli ultimi 4 numeri DLP-gate in CI/CD.
Assegni 3DS/SCA - Memorizza solo gli elementi necessari (ID transazioni), senza dati sensibili.
11) Errori frequenti
Loging PAN/CVV e maschere non calde.
Stesura PAN temporanea tramite API/pneumatici interni.
Nessun test di segmentazione per il pentesto.
Frequenza delle procedure ingiustificata (nessun TRA v4. 0).
Dipendenza da un PSP senza AoC e senza fallback.
Segmenti «influenti» non registrati (admine-jump-hosts, monitoraggio, bacap).
12) Lista degli assegni di partenza rapida (iGaming)
- Vai a hosted fields/iframe; eliminare l'input PAN dai moduli.
- Attivare la tornitura/token di rete escludere PAN da eventi/logi.
- Copiare CDE e isolare il segmento (MFA, RBAC, mTLS).
- Configura i loghi e gli alert centralizzati (invariabile, retenzioni).
- Esegui le scansioni ASV, elimina quelle critiche/elevate.
- Condurre i pentesti (intra/stereo). + test di segmentazione.
- Preparare regole/procedure e prove di esecuzione.
- Allineare il modulo di certificazione con l'equatore (SAQ tipo/ROC).
- Riceve e memorizza tutti i fornitori di creta.
- Incorporare i controlli PCI nel ciclo di lancio (SDLC, IaC-hardning, DLP in CI/CD).
13) FAQ breve
C'è bisogno di QSA? Per la ROC, sì. Per SAQ è spesso sufficiente l'auto-identificazione, ma molti equaieri/marchi possono richiedere QSA/ASV partner.
Se non teniamo il PAN? È comunque soggetto a PCI DSS se accetta le carte. Cercare di raggiungere SAQ A/A-EP.
3DS risolve PCI? No, no. 3DS - sull'autenticazione Il PCI parla di protezione dei dati.
Abbastanza TLS? No, no. Ci servono tutti i requisiti validi v4. 0, inclusi processi e prove.
14) Riepilogo
Per iGaming, la strategia ottimale è quella di ridurre al minimo il set (PAN-safe, tokenizzazione, hosted fields, P2PE dove possibile), segmentare il CDE in modo rigoroso, automatizzare loging/vulnerabilità/pentest, raccogliere un pacchetto completo di manufatti e scegliere una forma di conferma corretta (SAQ o ROC) al vostro livello. Ciò riduce i rischi, accelera l'integrazione con PSP e mantiene la conversione e la monetizzazione stabili nel rispetto dei requisiti dei marchi di mappe.