PCI DSS et sécurité des données de paiement. 8 chapitres et un QCM final.

Chapitre 1. Aux origines de PCI DSS : ce que le standard protège.

PCI DSS (Payment Card Industry Data Security Standard) est le référentiel mondial de sécurité des données de cartes de paiement. Ce n'est pas une loi, mais une obligation contractuelle. Les réseaux (Visa, Mastercard, Amex, Discover, JCB) l'imposent via les banques acquéreuses et les PSP à toute entité qui stocke, traite ou transmet des données de cartes, du kiosque de boulangerie au géant du e-commerce. Le standard est publié et maintenu par le PCI Security Standards Council (PCI SSC), fondé en 2006 par les cinq réseaux pour unifier leurs programmes de sécurité respectifs.

Les deux familles de données : CHD et SAD

Le standard sépare deux familles, à commencer par les données de titulaire de carte (CHD, Cardholder Data), stockables sous conditions strictes. Le stockage des données d'authentification sensibles (SAD, Sensitive Authentication Data) après autorisation est interdit en toutes circonstances, même chiffré.

PCI DSS s'articule avec les cadres légaux sans s'y substituer. Une fuite de PAN est presque toujours aussi une violation de données personnelles au sens du RGPD. L'autorité de contrôle compétente doit alors être notifiée sous 72 h, la CNIL en France. Les opérateurs critiques européens y ajoutent NIS2. Être conforme PCI ne dispense d'aucune obligation légale, alors que la non-conformité constatée au moment d'une compromission aggrave systématiquement la facture.

Chapitre 2. Le périmètre : CDE, systèmes connectés et segmentation.

Le CDE (Cardholder Data Environment) regroupe les personnes, processus et technologies qui stockent, traitent ou transmettent des CHD ou des SAD. Le périmètre PCI DSS ne s'arrête pas au CDE, englobant aussi les systèmes connectés au CDE et ceux qui peuvent impacter sa sécurité, même sans jamais voir un PAN. Les oublier reste l'erreur de cadrage la plus fréquente, et la plus coûteuse en audit.

• Dans le CDE : serveurs de paiement, bases stockant des PAN, TPE et POI, applications de caisse, enregistreurs d'appels du centre de contact, flux réseau transportant des CHD.
• Même segment réseau : tout composant partageant un segment non filtré avec le CDE est de facto dans le périmètre, même s'il ne touche aucune donnée carte.
• Systèmes connectés : annuaire (Active Directory), DNS, NTP, serveurs de patchs, antivirus centralisé, supervision, sauvegardes. Ils « parlent » au CDE.
• Systèmes impactant la sécurité : bastions d'administration, hyperviseurs hébergeant des VM du CDE, orchestrateurs, pipelines CI/CD déployant le code de paiement, outils de gestion des secrets.
• Tiers : prestataires d'hébergement, infogérants, PSP. Leur conformité doit être suivie contractuellement (12.8) et leur part de responsabilité documentée dans une matrice de responsabilités.

La v4.0.x tranche un point de doctrine, le cadrage n'étant plus une bonne pratique implicite mais une exigence testée. L'entité doit prouver chaque année qu'elle a confirmé son périmètre, et l'évaluateur doit le vérifier. Un périmètre sous-évalué découvert en audit peut invalider tout un cycle de conformité.

Chapitre 3. Les 12 exigences de la v4.0.x.

Les 12 exigences se regroupent en 6 objectifs : bâtir et maintenir un réseau sûr (1-2), protéger les données de comptes (3-4), gérer les vulnérabilités (5-6), contrôler les accès (7-9), surveiller et tester (10-11), gouverner la sécurité (12). Derrière ces 12 têtes de chapitre se cachent environ 250 à 300 contrôles testables, dont la v4.0.x a durci un grand nombre. Le tableau ci-dessous en donne la lecture experte.

Approche définie ou approche personnalisée

La v4.0 ouvre deux voies pour satisfaire une même exigence. L'approche définie applique le contrôle tel qu'écrit, testé selon les procédures du standard, tandis que l'approche personnalisée (customized approach) laisse l'entité concevoir un contrôle différent qui atteint l'objectif de sécurité énoncé. Elle le documente et produit une analyse de risque ciblée, puis l'évaluateur conçoit ses propres procédures de test. Outil puissant pour les organisations matures, mais exigeant en preuve.

• Fil rouge n°1, l'authentification : MFA partout vers le CDE, résistante au rejeu et au contournement (8.4.2, 8.5.1), mots de passe 12 caractères ou plus.
• Fil rouge n°2, le e-skimming : le duo 6.4.3 + 11.6.1 attaque frontalement les compromissions de pages de paiement (chapitre dédié plus loin).
• Fil rouge n°3, la conformité continue : TRA pour justifier les fréquences, détection des pannes de contrôles, revues documentées. La « photo annuelle » laisse place à un processus permanent (BAU, business as usual).

Chapitre 4. Niveaux marchands et validation : SAQ, ROC, AOC.

Tout le monde doit être conforme, mais tout le monde ne le prouve pas de la même façon. Les réseaux classent les marchands en quatre niveaux selon leur volume annuel de transactions. Le niveau détermine le mode de validation, soit un audit sur site sanctionné par un ROC (Report on Compliance) signé par un QSA (Qualified Security Assessor) ou un ISA interne, soit une auto-évaluation via un SAQ (Self-Assessment Questionnaire). Dans tous les cas, une AOC (Attestation of Compliance) est remise à l'acquéreur.

Les prestataires de services (PSP, hébergeurs, processeurs, opérateurs de coffres de tokens) suivent une grille à deux niveaux. Au-delà de 300 000 transactions traitées, le ROC annuel devient obligatoire, avec inscription possible sur les registres de prestataires conformes de Visa et Mastercard, argument commercial autant qu'obligation.

Choisir son SAQ : la carte d'identité de votre canal d'encaissement

En pratique, votre acquéreur (ou votre PSP) valide in fine le SAQ applicable et la fréquence des preuves. En cas de doute entre deux SAQ, documentez le raisonnement d'éligibilité, première pièce demandée après un incident.

Chapitre 5. Réduire le périmètre : tokenisation, iframe, redirection, P2PE.

Le meilleur contrôle de sécurité consiste à ne pas détenir la donnée. La stratégie moderne de conformité PCI déplace la donnée carte vers des acteurs spécialisés (PSP, prestataires P2PE, coffres de tokens), un chantier SAQ D de 250+ contrôles se transformant alors en un SAQ A d'une trentaine de questions. Quatre leviers dominent.

Tokenisation, deux familles. Les tokens de coffre (vault tokens) sont émis par votre PSP. Parfaits pour le paiement en un clic et les abonnements, ils vous lient en revanche à ce PSP. Les network tokens (Visa VTS, Mastercard MDES), émis par les réseaux, suivent la carte (mise à jour automatique en cas de réémission), sont portables entre acquéreurs et améliorent les taux d'autorisation. Dans les deux cas, un token hors du CDE n'est pas une donnée carte, et tout l'intérêt du procédé tient dans cette bascule.

P2PE : le chiffrement de bout en bout validé

Une solution P2PE validée PCI chiffre la donnée dès sa capture dans un terminal agréé (fonction SRED des terminaux PTS), sous une gestion de clés stricte. Celle-ci repose généralement sur DUKPT, avec une clé dérivée unique par transaction. Le déchiffrement n'ayant lieu que dans le HSM de l'environnement sécurisé du prestataire, le marchand ne peut pas techniquement accéder au clair, si bien que ses caisses, son réseau et son back-office sortent du périmètre. Attention à la nuance. Une solution E2EE « maison » non inscrite sur la liste du PCI SSC ne donne pas droit au SAQ P2PE, la réduction de périmètre restant alors à la discrétion de l'acquéreur.

Chapitre 6. 6.4.3 et 11.6.1 : contrer le web skimming Magecart.

Magecart désigne une constellation de groupes criminels spécialisés dans le skimming numérique. Le procédé consiste à injecter quelques lignes de JavaScript dans une page de paiement pour copier les données carte au moment où le client les tape, puis à les exfiltrer vers un serveur tiers. L'attaque est invisible pour le marchand (la transaction aboutit normalement) et pour le client (la page semble intacte). Les vecteurs sont connus, avec la compromission du site lui-même et surtout la chaîne d'approvisionnement des scripts tiers, où un tag manager, un chatbot, un widget d'avis ou un script analytics est modifié à la source.

Exigence 6.4.3 : gouverner les scripts

• Inventaire exhaustif de tous les scripts chargés et exécutés dans le navigateur du consommateur sur les pages de paiement, y compris les scripts tiers et leurs dépendances chargées en cascade.
• Justification écrite de la nécessité de chaque script : un script sans raison d'être documentée doit disparaître.
• Autorisation : un mécanisme (processus + technique) garantit que seuls des scripts approuvés peuvent être ajoutés.
• Intégrité : une méthode assure que chaque script n'a pas été altéré (SRI, CSP, ou solution de surveillance dédiée).

Exigence 11.6.1 : détecter la falsification

Un mécanisme de détection de changement et de falsification doit alerter sur toute modification non autorisée des en-têtes HTTP à impact sécurité (CSP notamment). Il couvre aussi le contenu des scripts des pages de paiement, tels que reçus par le navigateur du consommateur. La nuance porte sur le mot « reçus », ce qu'il faut surveiller étant le rendu côté client, pas seulement les fichiers déposés sur le serveur. La fréquence est au moins hebdomadaire, ou celle que définit une analyse de risque ciblée (TRA).

<!-- En-tete HTTP : politique CSP restrictive sur la page de paiement -->
Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://js.psp-exemple.com;
  frame-src https://checkout.psp-exemple.com;
  connect-src 'self' https://api.psp-exemple.com;
  report-uri https://csp-report.marchand-exemple.com/collect

<!-- Verification d'integrite (SRI) d'un script tiers versionne -->
<script
  src="https://js.psp-exemple.com/v3/checkout.js"
  integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6R9GqQ8KvuXy9rx7HNQlGYl1kPzQho1wxJwY8wC7q"
  crossorigin="anonymous"></script>

En pratique, l'arsenal combine plusieurs défenses. La CSP passe en mode blocage, avec collecte des violations (report-uri). Le SRI couvre les scripts versionnés, mais reste inefficace sur les scripts auto-mis à jour des PSP, d'où l'intérêt des domaines dédiés autorisés en CSP. Les solutions de surveillance de pages de paiement rejouent un parcours d'achat par crawling synthétique et comparent les scripts reçus, la surveillance du DOM en temps réel venant s'y ajouter. Même en iframe PSP (SAQ A), la page parente peut être détournée pour superposer un faux formulaire, et la vigilance ne se délègue jamais totalement.

Chapitre 7. Prouver la robustesse : scans ASV et tests d'intrusion.

L'exigence 11 impose un cycle de tests permanent sur deux registres complémentaires, les scans de vulnérabilités (automatisés, larges, fréquents) et les tests d'intrusion (manuels, profonds, scénarisés). Confondre les deux est un motif classique de non-conformité.

L'ASV (Approved Scanning Vendor) est un prestataire agréé par le PCI SSC, et lui seul peut produire les scans externes recevables. La discipline compte autant que la technique, avec quatre scans conformes par an, datés et suivis de re-scans jusqu'à éradication des constats bloquants. Un trimestre manqué ne se rattrape pas rétroactivement.

Tests d'intrusion (11.4)

• Fréquence : au moins annuel et après tout changement ou mise à niveau significatifs de l'infrastructure ou des applications.
• Portée : externe et interne, couche réseau et couche applicative (OWASP en référence), sur tout le périmètre CDE et ses points d'entrée critiques.
• Méthodologie documentée : approche reconnue de l'industrie, testeur qualifié et indépendant de l'exploitation des systèmes testés, règles d'engagement écrites.
• Segmentation : les contrôles d'isolement du CDE sont testés au moins une fois par an (marchands) et tous les six mois (prestataires de services), selon 11.4.5/11.4.6.
• Remédiation : les vulnérabilités exploitables découvertes sont corrigées puis re-testées.

Chapitre 8. Incident, notification et le vrai coût de la non-conformité.

L'exigence 12.10 impose un plan de réponse à incident opérationnel, avec rôles et contacts définis, disponibilité 24/7, procédures spécifiques par scénario, test au moins annuel du plan et formation du personnel. La v4 y ajoute des procédures dédiées au cas où du PAN est découvert là où il ne devrait pas être, dans des exports sauvages, des logs ou des tickets (12.10.7). Le jour J, l'improvisation coûte des millions.

La facture de la non-conformité