PCI DSS : niveaux et conformité

1) Qu'est-ce que PCI DSS et qui en a besoin

• accepter les paiements par carte (directement ou via PSP/passerelle),
• Traiter/stocker/transmettre des données de carte (PAN, terme, CVV) ou leurs formes abrégées/cryptées,
• vous êtes fournisseur de services pour d'autres merchants (hébergement, traitement, antifrod, orchestration de paiement, etc.) si vous pouvez affecter la sécurité de vos cartes.

Version et délais : la version à jour est PCI DSS v4. 0. Exigences v3. 2. 1 hors d'usage ; « futur-daté », points v4. 0 est maintenant en vigueur. Nouveau dans le v4. 0 : MFA renforcé, « Approche personnalisée », analyse de risque ciblée de la fréquence des procédures, raffinement par segmentation et cryptage.

2) Niveaux de conformité : Merchants et fournisseurs de services

2. 1 Merchants (commerçants)

• Niveau 1:> 6 millions de transactions/an ou il y a eu une compromission. Un ROC annuel (Rapport sur la conformité) de la QSA ou d'un ISA interne est requis lors de l'harmonisation, + balayages ASV trimestriels.
• Niveau 2 : ~ 1-6 millions/an. Habituellement - SAQ (autoévaluation) + scans ASV ; certains circuits/acquéreurs peuvent exiger un ROC.
• Niveau 3 : ~ 20k-1 million e-commerce/an. Habituellement, les scans SAQ + ASV.
• Niveau 4 : en dessous des seuils L3. SAQ; les exigences peuvent varier selon le pot d'acquisition.

2. 2 Fournisseurs de services (Fournisseurs de services)

Généralement 2 niveaux ; pour le niveau 1 (grand volume/rôle critique dans la chaîne), le ROC de QSA est obligatoire, pour le niveau 2 - SAQ-D SP (parfois - ROC à la demande des contreparties/régimes). Dans iGaming, de nombreux partenaires PSP/passerelles/hébergement sont SP Level 1.

3) SAQ vs ROC : comment choisir

• SAQ A - uniquement les sites de redirect/iframe/hosted ; pas de traitement/transfert/stockage de cartes chez vous.
• SAQ A-EP est un e-commerce où votre site affecte la sécurité de la page de paiement (par exemple, l'hébergement des scripts), mais le PAN est introduit dans l'environnement du fournisseur.
• SAQ B/B-IP - terminaux/imprimantes sans stockage électronique ; B-IP - terminaux connectés.
• SAQ C-VT/C - terminaux virtuels/petit environnement de traitement, sans stockage.
• SAQ P2PE est seulement une solution PCI certifiée P2PE.
• SAQ D (Merchant/Service Provider) est une option « large » pour tout traitement/transfert/stockage, intégrations personnalisées, orchestrateurs, etc.

Pratique pour iGaming : la voie cible est la SAQ A/A-EP au détriment des flux PAN-safe, de la tokenization et des champs hébergés. Si vous avez vos propres services de paiement/valte - généralement SAQ D ou ROC.

4) Scoping : ce qui entre dans le CDE et comment le réduire

CDE (Cardholder Data Environment) - systèmes où les données de cartes sont traitées/stockées/transmises, et tous les segments connectés/influents.

• Sites hébergés/iframe/TSP : entrée PAN hors de votre domaine.
• Tokenization et tokens réseau : vos services opèrent avec des tokens, pas avec un PAN.
• P2PE : cryptage fin-fin avec solution certifiée.
• Segmentation du réseau : ACL rigide, isolation CDE du reste de l'environnement.
• DLP obligatoire et masquage des logs, interdiction des décharges avec PAN/CVV.

En v4. 0 la flexibilité des méthodes pour atteindre les objectifs a été ajoutée, mais les preuves d'efficacité et l'analyse ciblée des risques sont obligatoires.

5) « 12 exigences » PCI DSS v4. 0 (blocs de sens)

1. Protection réseau et segmentation (firewall, ACL, isolation CDE).
2. Configuration sécurisée des hôtes/périphériques (hardning, lignes de base).
3. Protection des données des détenteurs de cartes (stockage PAN - seulement si nécessaire, cryptographie forte).
4. Protection des données en transmission (TLS 1. 2 + et équivalents).
5. Antivirus/anti-malware et contrôle de l'intégrité.
6. Développement et modification sécurisés (SDLC, SAST/DAST, contrôle des bibliothèques).
7. Accès par nécessité (least privilège, RBAC).
8. Identification et authentification (MFA pour admin-and remote access, mots de passe v4. 0).
9. Sécurité physique (centres de données, bureaux, terminaux).
10. Loging et monitoring (centralisation des logs, invariabilité, alertes).
11. Tests de sécurité (scans ASV trimestriels, pentestes annuels et après changements, test de segmentation).
12. Gestion des politiques et des risques (procédures, formation, incident-respect, évaluation des risques, documents d'approche personnalisée).

6) Activités obligatoires et périodicité

Les scans ASV (externes) - trimestriels et après des changements significatifs.
Vulnérabilités/patchings - cycles réguliers (les fréquences sont justifiées par TRA - targeted risk analysis).
Pentesta (interne/externe) - chaque année et après des changements significatifs ; la vérification de la segmentation est obligatoire.
Journaux et surveillance - en continu, avec rétention et protection contre les modifications.
Formation du personnel - lors de l'embauche et au-delà régulièrement.
IFA - Pour tous les admins et accès à distance au CDE.
Inventaire des systèmes/flux de données - actualiser en permanence.

7) Matrice de sélection SAQ (courte)

Seulement iframe/redirect, sans PAN vous avez un → SAQ A.
E-commerce, votre site affecte la page de paiement → la SAQ A-EP.
Terminaux/imprimantes → SAQ B/B-IP.
Terminal virtuel → SAQ C-VT.
Petit réseau de cartes sans stockage → SAQ C.
Solution P2PE → SAQ P2PE.
Différent/complexe/stockage/traitement → SAQ D (ou ROC).

8) Artefacts et preuves pour l'audit

• Diagrammes de réseau et de flux de données, registre des actifs, registre des fournisseurs, registre des comptes/accès.
• Politiques/procédures : développement sécurisé, gestion du changement, logging, incidents, vulnérabilités, clés/crypto, accès à distance, sauvegardes.
• Rapports : ASV, pentestes (segmentation inclusive), scans de vulnérabilités, résultats des amendements.
• Journaux/alertes : système centralisé, invariabilité, analyse des incidents.
• Gestion crypto : Procédures KMS/HSM, rotation, inventaire de clés/certificats.
• Preuve « Approche personnalisée » (si appliquée) : objectifs de contrôle, méthode, métriques d'efficacité, TRA.
• Les contours de responsabilité des tiers : Partenaires AoC (PSP, hébergement, CDN, anti-fred), matrice de responsabilité partagée.

9) Projet de conformité (étape par étape)

1. Scoping et analyse GAP : définissez les CDE, les segments adjacents, les discontinuités en cours.
2. Gains rapides : flux PAN-safe (iframe/champs hébergés), tokenization, interdiction du PAN dans les logs, fermer les vulnérabilités « externes » de la Crète.
3. Segmentation et réseau : Isoler CDE, mTLS, firewall-ACL, accès par least-privilège, MFA.
4. Observabilité : logage centralisé, rétention/chaîne de conservation, alertes.
5. Gestion des vulnérabilités et du code : SAST/DAST, patchs, SBOM, contrôle des dépendances.
6. Tests : scans ASV, pentestes internes/externes, contrôle de segmentation.
7. Documents et formation : procédures, pleybooks IR, formations, dossiers de formation.
8. Choix du formulaire d'attestation : SAQ (type) ou ROC ; négocier avec l'acquéreur/les marques.
9. Cycle annuel : soutien, preuves, révision des risques/fréquences, dépassement.

10) Intégration avec l'architecture iGaming

L'orchestrateur de paiement ne fonctionne qu'avec des tokens ; Le PAN ne voit pas.
Multi-PSP: health-checks, smart-routing, idempotency, ретраи; AoC de chaque PSP.
Pneu Event-driven/DWH : pas de PAN/CVV ; Masquage des 4 derniers chiffres ; Gates DLP en CI/CD.
Chèques par 3DS/SCA : ne stocker que les artefacts nécessaires (ID de transaction), sans données sensibles.

11) Erreurs fréquentes

Logage PAN/CVV et masques non valides.
Routage PAN « temporaire » via API/bus internes.
Aucun test de segmentation dans le penteste.
Fréquence déraisonnable des procédures (pas de TRA pour v4. 0).
Dépendance à un seul PSP sans AoC et sans fallback.
Segments « influents » non comptabilisés (admin-jump-hosts, surveillance, backaps).

12) Chèque de démarrage rapide (iGaming)

• Passer aux champs/iframe hébergés ; Supprimer l'entrée PAN de vos formulaires.
• Activer la tokenisation/jetons réseau ; Exclure le PAN des événements/logs.
• Effectuer le scoping CDE et l'isolation du segment (MFA, RBAC, mTLS).
• Configurer les logs centralisés et les alertes (invariabilité, rétention).
• Démarrer les scans ASV, éliminer critique/élevé.
• Effectuer des pentestes (intrinsèques/externes) + test de segmentation.
• Préparer des politiques/procédures et des preuves d'exécution.
• Harmoniser le formulaire d'attestation avec l'acquéreur (type SAQ/ROC).
• Obtenir et stocker l'AoC de tous les fournisseurs de Crète.
• Intégrer les contrôles PCI dans le cycle de sortie (SDLC, IaC-hardning, DLP dans CI/CD).

13) FAQ court

La QSA est-elle nécessaire ? Pour le ROC, oui. L'auto-certification est souvent suffisante pour la SAQ, mais de nombreux acquéreurs/marques peuvent exiger un partenaire QSA/ASV.
Si nous ne stockons pas le PAN ? Vous êtes toujours soumis au DSS PCI si vous acceptez les cartes. Essayez d'atteindre la SAQ A/A-EP.
3DS décide PCI ? Non. 3DS - sur l'authentification ; PCI - sur la protection des données.
Assez de TLS ? Non. Toutes les exigences pertinentes v4 sont nécessaires. 0, y compris les processus et les preuves.

14) Résumé

Pour iGaming, la stratégie optimale est de minimiser l'agrégat (PAN-safe, Tokenization, hosted fields, P2PE si possible), de segmenter le CDE de manière rigide, d'automatiser le logage/vulnérabilités/pentestes, d'assembler un paquet complet d'artefacts et de choisir la forme correcte de confirmation (SAQ ou RO) selon votre niveau. Cela réduit les risques, accélère les intégrations avec PSP et maintient une conversion et une monétisation stables tout en respectant les exigences des marques de cartes.