PAN Primary Account Number PCI-DSS
conformiteDéfinition
Le Primary Account Number (PAN) est le numéro de carte de paiement, typiquement un numéro à 16 chiffres embossé sur les cartes bancaires (Visa, Mastercard, American Express, etc.). La protection du PAN est l'objectif central de la norme PCI-DSS (Payment Card Industry Data Security Standard) : c'est parce que le PAN identifie de façon unique le compte du titulaire et peut permettre des transactions frauduleuses qu'il est soumis aux contrôles les plus stricts de la norme. PCI-DSS classe le PAN comme la donnée cardholder la plus sensible (Primary Account Data). Toute organisation qui stocke, traite ou transmet des PAN est soumise à PCI-DSS dans son intégralité, quel que soit son volume de transactions. Par contraste, si une organisation ne stocke pas de PAN mais traite d'autres données cardholder moins sensibles (nom du titulaire seul, sans PAN), les exigences PCI-DSS applicables sont réduites. PCI-DSS impose plusieurs mesures spécifiques pour la protection du PAN. L'exigence fondamentale est que les PAN stockés doivent être rendus illisibles par tout moyen : hachage fort (SHA-256 minimum du PAN entier), troncature (ne conserver que les premiers 6 et les 4 derniers chiffres, comme •••• •••• •••• 1234), tokenisation (remplacement du PAN par un token non déductible), ou chiffrement fort avec gestion sécurisée des clés. La troncature est la méthode la plus courante pour les interfaces utilisateur et les reçus : l'affichage du PAN est masqué en ne montrant que les 4 à 6 derniers chiffres, permettant à l'utilisateur d'identifier sa carte sans exposer le PAN complet. PCI-DSS v4.0 (Requirement 3.3.1) précise qu'au maximum les 6 premiers et les 4 derniers chiffres peuvent être affichés, jamais plus. La tokenisation va plus loin en remplaçant le PAN par un token (identifiant fictif, sans valeur intrinsèque) dans tous les systèmes de l'organisation, ne conservant le PAN réel que dans un vault hautement sécurisé. Cette approche permet de réduire drastiquement le périmètre PCI-DSS (scope) car les systèmes utilisant des tokens ne traitent pas de PAN.
Protection du PAN et exigences PCI-DSS Requirement 3
Le PAN est la donnée cardholder la plus protégée sous PCI-DSS. La Requirement 3 (Protect Stored Account Data) impose que les PAN stockés soient rendus illisibles via : hachage fort (algorithme robuste comme SHA-256 appliqué au PAN entier), troncature (6 premiers + 4 derniers chiffres maximum affichés), tokenisation (remplacement par un token dans un système de tokens sécurisé), ou chiffrement fort (AES-256) avec gestion des clés conforme PCI-DSS.
La Requirement 3.3.2 interdit formellement le stockage du PAN en clair (plaintext) à l'issue de l'autorisation de la transaction. Des audits réguliers via des outils de découverte des données (Data Discovery) doivent rechercher les PANs stockés en clair dans les bases de données, fichiers, logs, et emails — une découverte fréquente lors des audits PCI-DSS.
Tokenisation et réduction du périmètre PCI-DSS
La tokenisation est la méthode la plus efficace pour réduire le périmètre PCI-DSS (scope reduction) : en remplaçant le PAN par un token non-réversible dans tous les systèmes opérationnels, seul le système de tokenisation (vault) et les interfaces de paiement traitent des PAN réels. Tous les autres systèmes de l'organisation (ERP, CRM, facturation) manipulent des tokens, réduisant considérablement le nombre de systèmes dans le périmètre PCI-DSS.
Les solutions de tokenisation peuvent être hébergées sur site (HSM avec vault local), dans le cloud (Azure Vault, AWS Payment Cryptography, GCP Cloud HSM), ou via des fournisseurs de paiement (Stripe, Braintree, Adyen) qui gèrent la tokenisation pour leurs clients. L'utilisation d'un acquéreur ou d'une passerelle de paiement gérant la tokenisation est l'approche la plus commune pour les e-commerçants souhaitant minimiser leur périmètre PCI-DSS.
PAN et données sensibles d'authentification (SAD)
PCI-DSS distingue le PAN (Primary Account Data) des Sensitive Authentication Data (SAD) : données de piste magnétique, CVV/CVC (code de sécurité au dos de la carte), et PIN. Les SAD ne doivent JAMAIS être stockées après autorisation de la transaction, même sous forme chiffrée — c'est une interdiction absolue PCI-DSS (Requirement 3.2). La différence : le PAN peut être stocké sous forme protégée (chiffré, tronqué, hashé, tokenisé), mais les SAD doivent être purgées immédiatement après autorisation.
Un audit PCI-DSS examinera systématiquement les logs d'application pour détecter les captures accidentelles de CVV ou de données de piste dans les logs, une non-conformité fréquente. Des revues de code et des configurations de logging sont essentielles pour prévenir ces captures inadvertantes.
Ce terme vous interpelle ?
Nos experts interviennent sur toutes les thématiques de ce glossaire — pentest, conformité NIS 2 / ISO 27001, forensics, sécurité IA. Réponse sous 24h, devis gratuit et sans engagement.