Tokenisation vs Chiffrement : Protéger les Données

La confusion entre tokenisation et chiffrement coûte cher aux organisations qui déploient la mauvaise solution pour le mauvais cas d'usage. Un retailer qui chiffre ses numéros de carte bancaire en base de données au lieu de les tokeniser maintient l'intégralité de son infrastructure dans le périmètre PCI DSS, multipliant les coûts d'audit et la surface d'attaque. À l'inverse, une organisation qui tokenise des communications confidentielles au lieu de les chiffrer de bout en bout expose les données à toute personne ayant accès au vault de correspondance. La distinction fondamentale réside dans la nature de la protection : le chiffrement protège mathématiquement les données (sécurité par transformation), la tokenisation élimine les données sensibles du système en les remplaçant par des substituts sans valeur (sécurité par suppression). Les deux approches répondent à des exigences différentes et sont complémentaires dans une architecture de sécurité des données complète. L'intégration avec les solutions de DSPM et de masquage des données permet de construire une stratégie de protection cohérente. La classification automatique des données sensibles identifie les données nécessitant une protection, puis le choix entre tokenisation et chiffrement dépend du niveau de conformité requis et des contraintes architecturales de chaque système. Les standards de référence PCI DSS v4.0 et le NIST SP 800-38G encadrent les implémentations conformes de ces deux mécanismes de protection.

Mécanismes techniques comparés

La tokenisation génère un jeton aléatoire (UUID, numérique ou alphanumérique) pour chaque valeur sensible et stocke la correspondance jeton-valeur dans un vault sécurisé. Le jeton n'a aucun lien mathématique avec la valeur d'origine : il est impossible de retrouver le numéro de carte bancaire à partir du jeton sans accéder au vault. Cette propriété est fondamentale pour la conformité PCI DSS car elle permet de sortir du périmètre d'audit tous les systèmes qui manipulent uniquement des jetons. Le vault devient le seul composant critique, complétant la stratégie de chiffrement bout en bout des données sensibles qui protège les données en transit et au repos. nécessitant une protection renforcée.

Le chiffrement symétrique AES-256 transforme les données en ciphertext déchiffrable uniquement avec la clé secrète correspondante. Chaque donnée chiffrée maintient un lien mathématique avec l'original via la clé de chiffrement : quiconque possède la clé peut retrouver les données en clair. Le chiffrement Format-Preserving Encryption (FPE) selon NIST FF1/FF3-1 chiffre les données en préservant leur format d'origine : un numéro à 16 chiffres reste un numéro à 16 chiffres après chiffrement FPE, facilitant l'intégration dans les applications existantes sans modification des schémas de base de données.

Cas d'usage PCI DSS : avantage tokenisation

La norme PCI DSS v4.0 exige que tout système stockant, traitant ou transmettant des données de carte bancaire (PAN) soit inclus dans le périmètre d'audit. La tokenisation permet de réduire ce périmètre en remplaçant le PAN par un jeton dès le point de capture (terminal de paiement, formulaire web) et en stockant la correspondance dans un vault certifié PCI DSS. Les systèmes backend (ERP, CRM, analytics) qui manipulent uniquement des jetons sortent du périmètre d'audit, réduisant les coûts de conformité de 50 à 80% selon la complexité de l'infrastructure.

Les vault de tokenisation certifiés PCI DSS comme Thales CipherTrust, Voltage SecureData et les services managés Stripe et Adyen offrent des API REST standardisées pour l'intégration applicative. Le processus de tokenisation s'effectue en deux appels : le premier envoie le PAN au vault et reçoit le jeton, le second appelle le vault pour dé-tokeniser lorsque le PAN est nécessaire (autorisation bancaire, remboursement). Le vault implémente des contrôles d'accès granulaires (RBAC) définissant quelles applications et quels utilisateurs sont autorisés à dé-tokeniser, avec une journalisation exhaustive de chaque opération pour la traçabilité d'audit exigée par PCI DSS.

Cas d'usage RGPD : chiffrement et pseudonymisation

Le RGPD reconnaît le chiffrement comme mesure technique de protection des données personnelles dans ses articles 32 (sécurité du traitement) et 34 (notification de violation). En cas de violation de données, l'article 34 dispense l'organisation de notifier les personnes concernées si les données volées étaient chiffrées avec un algorithme et une clé conformes à l'état de l'art, réduisant considérablement l'impact réputationnel et les amendes potentielles. Cette protection juridique ne s'applique pas à la tokenisation car le RGPD ne la mentionne pas explicitement comme mesure de protection suffisante.

La pseudonymisation par tokenisation est néanmoins reconnue par l'article 25 du RGPD comme mesure de protection par défaut et dès la conception. La tokenisation des identifiants directs (nom, email, numéro de sécurité sociale) avec stockage séparé de la table de correspondance constitue une pseudonymisation valide au sens du RGPD. L'approche recommandée combine les deux techniques : chiffrement AES-256 pour les données au repos et en transit, tokenisation pour les identifiants directs dans les bases applicatives, créant une défense en profondeur conforme aux exigences du RGPD et aux recommandations de la CNIL sur la protection des données personnelles.

HashiCorp Vault et les solutions DevOps

HashiCorp Vault Transit Secrets Engine offre une approche unifiée combinant tokenisation et chiffrement pour les environnements DevOps et cloud-native. Le moteur Transit chiffre les données via API REST sans stocker les données en clair dans Vault, éliminant le risque de compromission du vault lui-même. Le moteur Transform implémente la tokenisation et le FPE avec des templates personnalisables pour chaque type de donnée sensible. L'intégration native avec Kubernetes (injection de secrets via sidecar), Terraform (provider Vault) et les pipelines CI/CD (plugin Jenkins, GitHub Actions) fait de Vault la solution de référence pour les équipes DevSecOps.

Conclusion

La tokenisation et le chiffrement sont deux piliers complémentaires de la protection des données sensibles. La tokenisation excelle pour la réduction du périmètre PCI DSS et la pseudonymisation RGPD, le chiffrement pour la protection mathématique des données en transit et au repos. L'architecture de sécurité optimale combine les deux approches selon le type de donnée et le cas d'usage, avec un vault centralisé pour la tokenisation et une gestion de clés robuste pour le chiffrement.

Protégez vos données sensibles

Audit RGPD, classification, chiffrement, DLP — mise en conformité complète.

Audit données — Devis gratuit [email protected]

Choisir entre Tokenisation et Chiffrement : Tableau de Décision par Cas d'Usage

Le choix entre tokenisation et chiffrement n'est pas une décision binaire mais dépend du cas d'usage précis et des contraintes spécifiques de l'architecture applicative. La tokenisation est préférable pour les numéros de carte bancaire dans les systèmes PCI DSS (le token peut être stocké et partagé sans réduire le périmètre de conformité), pour les numéros de sécurité sociale dans les bases de données RH (le token permet les recherches sans exposer la valeur réelle), et pour tout identifiant sensible qui doit circuler dans des systèmes tiers non habilités à traiter la donnée originale.

Le chiffrement est préférable lorsque la récupération de la valeur originale doit pouvoir s'effectuer dans n'importe quel contexte sans dépendance à un vault central — backups hors ligne, archives longue durée, flux de données batch avec accès offline. La clé de déchiffrement peut être dérivée d'un secret maître selon les besoins, sans nécessiter une connexion réseau vers un service de tokenisation. Pour les bases de données analytiques où l'on a besoin de la donnée réelle pour les traitements statistiques, le chiffrement au niveau des colonnes avec des clés différentes par client (multi-tenant) est souvent l'architecture la plus appropriée.