Diagramme de flux de données PCI DSS : cartographier les données de carte et réduire le périmètre

Une évaluation PCI DSS commence presque toujours par la même demande : montrez-nous où vont les données de carte. Le diagramme de votre wiki montre des services et des flèches, mais pas quelles flèches portent un numéro de carte, lesquelles ne portent qu'un jeton, ni pourquoi l'entrepôt analytique est hors périmètre. Sans cela, chaque système devient une discussion de périmètre.

Cet article couvre ce que demande PCI DSS v4.0.1, les catégories de périmètre, un paiement détaillé avec champs de paiement hébergés, les jetons, la segmentation, les types de SAQ et la mise à jour. Ce n'est pas un conseil juridique ni de conformité : votre acquéreur ou votre évaluateur décide de ce qui s'applique, et les textes officiels se trouvent dans la PCI SSC Document Library.

Ce que demande PCI DSS v4.0.1

PCI DSS v4.0.1, publiée en juin 2024, est la version en vigueur au moment de la rédaction (novembre 2026). Ses exigences à échéance future sont devenues obligatoires le 31 mars 2025. Trois exigences façonnent vos diagrammes :

Les données de compte comprennent les données de titulaire de carte (PAN, nom du titulaire, date d'expiration, code de service) et les données d'authentification sensibles (données de piste complètes, code de vérification de carte, PIN et blocs PIN). Le PAN est l'élément déterminant : si vous le stockez, le traitez ou le transmettez, vous avez un environnement de données de titulaire de carte (CDE).

Le SAQ A ne contient ni l'exigence 1 ni la 12.5.2, le SAQ A-EP inclut 1.2.3 et 1.2.4, et le SAQ D comme les évaluations complètes incluent les trois. Même sous SAQ A, le diagramme reste votre preuve d'éligibilité la plus claire.

Trois types de systèmes

La section 4 applique les exigences au CDE et à tout ce qui « pourrait avoir un impact sur la sécurité des données de titulaire de carte et/ou des données d'authentification sensibles », formulation introduite par la v4.0.1 à la place de « la sécurité du CDE ». L'exemple de la norme elle-même est « un serveur web qui contrôle la génération d'un formulaire ou d'une page de paiement ». Le guide de définition du périmètre du PCI SSC classe les systèmes en trois catégories, vérifiées de haut en bas :

Un système appartient à la catégorie la plus haute qui lui correspond. La segmentation est facultative, mais sans elle tout le « réseau à plat » est dans le périmètre, et le chiffrement seul ne sort généralement pas les données de carte du périmètre.

L'exemple : un paiement avec champs de paiement hébergés

Une application web de boutique sert la page de paiement ; ses champs de carte sont un iframe du prestataire de paiement, souvent appelés champs hébergés (hosted fields). Un service de commandes débite les paiements, Postgres stocke les commandes, une tâche nocturne alimente un entrepôt et le CI/CD déploie la boutique :

1. Le navigateur charge la page de paiement ; le script du prestataire affiche les champs de carte dans son propre iframe.
2. Le client saisit le PAN, la date d'expiration et le CVC, et le navigateur les envoie en TLS directement au prestataire. La politique de même origine empêche les scripts de la page du commerçant d'accéder à l'iframe.
3. Le prestataire stocke le PAN dans son vault et renvoie un jeton.
4. La page envoie la commande et le jeton au service de commandes.
5. Le service de commandes débite le jeton via l'API du prestataire avec une clé secrète, et le prestataire demande l'autorisation via le réseau de cartes.
6. Un webhook confirme le résultat. Le service de commandes stocke l'identifiant du jeton, la marque de la carte et les quatre derniers chiffres.

Aucun système du commerçant ne stocke, ne traite ni ne transmet le PAN, donc le commerçant n'a pas de CDE ; vous gérez le prestataire, qui a sa propre évaluation, au titre de l'exigence 12.8. Le diagramme d'intégration d'une passerelle de paiement montre le même paiement sous forme de séquence, et le diagramme de la plateforme e-commerce le replace parmi les services de catalogue, de panier et de commandes.

L'application web reste dans le périmètre : un attaquant qui la modifie, ou modifie un script qu'elle charge, peut remplacer l'iframe par un faux formulaire. Cette attaque, l'e-skimming, est la raison pour laquelle la v4.0 a ajouté 6.4.3 (autoriser, contrôler l'intégrité et inventorier les scripts des pages de paiement) et 11.6.1 (détecter les modifications des pages de paiement). Le CI/CD est aussi dans le périmètre, puisque la norme compte les outils de déploiement parmi les composants du système.

Les jetons et ce qu'ils laissent dans le périmètre

Les lignes directrices sur la tokenisation du PCI SSC placent le système de tokenisation, y compris la détokenisation et le stockage du PAN, dans le CDE. Les systèmes qui ne détiennent que des jetons peuvent être hors périmètre si le PAN ne peut pas être retrouvé à partir des jetons, s'ils ne peuvent pas demander de détokenisation ni atteindre le vault, et s'ils sont segmentés du CDE.

Le prestataire possède le vault, donc le service de commandes et la base de données peuvent être qualifiés, avec un bémol : un jeton réutilisable associé à la clé d'API secrète peut créer des débits. Le guide indique que les jetons capables de lancer une transaction « peuvent être dans le périmètre de PCI DSS » et recommande aux commerçants de consulter leur acquéreur. Protégez la clé comme n'importe quel secret de production.

La segmentation et comment elle est testée

La segmentation désigne en général des règles de pare-feu, des security groups ou des comptes cloud distincts. Si elle isole un CDE, l'exigence 11.4.5 demande des tests d'intrusion de ces contrôles au moins tous les 12 mois et après des changements (tous les six mois pour les prestataires de services), par un testeur qualifié et indépendant. Sur le schéma réseau de 1.2.3, dessinez chaque segment et les contrôles qui les séparent, comme dans une topologie réseau logique.

Sans CDE chez le commerçant, la frontière qui compte entoure tout ce qui peut modifier la page de paiement : le service de commandes, l'entrepôt et leurs identifiants ne doivent pas pouvoir déployer vers la boutique.

Choix d'architecture et types de SAQ

La conception de votre paiement détermine en grande partie le questionnaire d'auto-évaluation (SAQ) ; votre acquéreur le confirme :

La révision de janvier 2025 du SAQ A a retiré 6.4.3 et 11.6.1 du questionnaire et ajouté un critère d'éligibilité : le commerçant confirme que « son site n'est pas vulnérable aux attaques par des scripts qui pourraient affecter le ou les systèmes e-commerce du commerçant ». La FAQ 1588 autorise deux voies : protéger votre page avec des techniques comme celles de 6.4.3 et 11.6.1, ou obtenir la confirmation de votre prestataire que sa solution le fait, lorsqu'elle est mise en œuvre selon les instructions. Le critère s'applique aux iframes intégrés, pas aux redirections, et les deux exigent toujours des analyses trimestrielles par un Approved Scanning Vendor (FAQ 1604). Un seul champ de carte affiché par votre propre page exclut le SAQ A.

Garder le diagramme à jour

La norme considère « tout changement dans le flux ou le stockage des données de compte » comme potentiellement important. Mettez le diagramme à jour chaque fois que vous ajoutez un moyen de paiement, un prestataire ou un canal, un script de paiement, ou un export, un pipeline de logs ou un outil de support qui touche aux données de paiement.

Surveillez les numéros de carte dans les tickets de support et les chats : pour un tel canal involontaire, la v4.0.1 demande de l'intégrer au CDE ou de supprimer les données de façon sécurisée et d'empêcher que le canal serve à cela. Indiquez la date, l'auteur et l'approbateur sur le diagramme ; le workflow de documentation vivante traite des responsables et des déclencheurs de mise à jour.

Le diagramme de flux des données de titulaire de carte

Comment le lire :

• Trois zones. Le rouge est le CDE du prestataire, l'ambre regroupe les systèmes du commerçant qui peuvent modifier la page de paiement, et le turquoise regroupe les systèmes qui ne manipulent que des jetons.
• Les couleurs suivent les données : rouge pour les données de carte, turquoise pour les jetons, gris pour aucun des deux ; les pointillés indiquent l'asynchrone.
• Les numéros suivent un seul achat. Le chemin rouge n'entre jamais dans un cadre du commerçant.
• Deux notes signalent les risques restants : les scripts de page et les jetons réutilisables.
• La légende résume les classes de données et le périmètre.

Dessiner clairement les diagrammes de flux de données PCI DSS

Étiquetez chaque flux et chaque stockage :

• Dessinez le périmètre sous forme de cadres et grisez les zones hors périmètre, comme le suggère le guide de 1.2.3.
• Dessinez un diagramme par canal : e-commerce, téléphone et terminaux diffèrent.
• Incluez les chemins discrets : remboursements, rétrofacturations, sauvegardes, logs et outils de support.
• Alignez-le sur le schéma réseau, que le diagramme de flux de données doit compléter.
• Omettez les appels sans données de compte ni jetons.

Une erreur courante est une ligne de PAN qui traverse des systèmes ne manipulant que des jetons, ce qui les fait entrer dans le périmètre sur le papier. Voir les exemples de diagrammes de flux de données pour la notation, le guide de modélisation des menaces pour les frontières de confiance et la cartographie des données RGPD pour un inventaire similaire.

Le construire dans Archboard

1. Connectez-vous avec Google ou GitHub et créez un diagramme.
2. Ajoutez une Personne du pack Modèle C4 pour le navigateur du client.
3. Ajoutez trois nœuds Cadre du pack Base pour le prestataire (rouge), le commerçant dans le périmètre (ambre) et le commerçant hors périmètre (turquoise).
4. Dans le cadre du prestataire, ajoutez deux nœuds Système externe du pack Modèle C4 pour les champs hébergés et l'API de paiement, et un Coffre-fort du pack Sécurité. Placez un Système externe pour les réseaux de cartes sous le cadre.
5. Dans le cadre ambre, ajoutez un Conteneur du pack Modèle C4 pour l'application web et un Pipeline CI/CD du pack DevOps.
6. Dans le cadre turquoise, ajoutez un Conteneur pour le service de commandes, ainsi que des nœuds Postgres et Entrepôt de données du pack Données.
7. Tracez des liens étiquetés : rouge pour les données de carte, turquoise pour les jetons, gris sinon, en pointillés pour le webhook et l'export.
8. Ajoutez une légende Markdown du pack Base et deux notes Texte du pack Base.

Pour le schéma réseau de 1.2.3, le convertisseur Terraform vous donne un premier brouillon à partir de vos fichiers .tf ; la page diagramme de flux de paiement présente des vues en séquence.

L'exemple utilise 14 nœuds de diagramme et reste dans les limites de l'offre Free.

FAQ

PCI DSS exige-t-elle un diagramme de flux de données ? Oui. L'exigence 1.2.4 de la v4.0.1 demande un diagramme de flux de données exact de tous les flux de données de compte, tenu à jour. Le SAQ A l'omet ; le SAQ A-EP, le SAQ D et les évaluations complètes l'incluent.

Quelle est la différence entre le schéma réseau PCI et le diagramme de flux de données ? Le schéma réseau (1.2.3) montre les connexions entre le CDE et les autres réseaux. Le diagramme de flux de données (1.2.4) montre où circulent et où sont stockées les données de compte. Les deux doivent concorder.

Un iframe ou une page de paiement hébergée sort-il mon site du périmètre PCI ? Non. Il garde les données de carte hors de vos systèmes, mais la page qui intègre l'iframe peut toujours être attaquée ; c'est pourquoi le SAQ A demande des analyses ASV trimestrielles et, pour les iframes, une protection contre les attaques par script.

Les systèmes qui ne stockent que des jetons sont-ils hors périmètre PCI DSS ? Ils peuvent l'être, si le PAN ne peut pas être retrouvé à partir des jetons et si les systèmes sont segmentés du système de tokenisation. Les jetons capables de lancer une transaction peuvent rester dans le périmètre.

À quelle fréquence le périmètre PCI et les diagrammes doivent-ils être revus ? Mettez à jour le diagramme de flux de données à chaque changement des flux de données de compte, et confirmez le périmètre au moins tous les 12 mois et après tout changement important (12.5.2), ou tous les six mois pour les prestataires de services.

Commencez gratuitement — un siège, sans carte bancaire.