Le masquage des données et la tokenisation protègent tous deux les données sensibles, mais ils résolvent des problèmes différents. Le masquage remplace une valeur réelle par une valeur fictive qui ne permet pas de remonter à l'originale, ce qui est utile pour les tests, le développement et l'analyse. La tokenisation remplace une valeur réelle par un token qui permet de retrouver la valeur originale via un coffre-fort sécurisé. Elle constitue la norme en matière de traitement des données de carte bancaire dans les systèmes de paiement en mode production.

Confondre les deux méthodes, ou utiliser l'une à la place de l'autre, peut créer des flux de travail défaillants d'un côté et une exposition inutile de l'autre. Pire encore, des pratiques inefficaces en matière de sécurité des données peuvent contribuer à des failles de sécurité dont le coût moyen s'élève à 5 millions de dollars et qui nécessitent plus de 280 jours pour être circonscrites.

Nous expliquons ci-dessous comment chaque méthode fonctionne, en quoi elles divergent sur la réversibilité et les cas d'usage, et comment déterminer celle dont votre entreprise a besoin pour un ensemble de données donné.

L’essentiel à retenir

• Le masquage des données remplace de manière permanente les valeurs sensibles par des valeurs fictives réalistes. Il est donc bien adapté aux environnements hors production, comme les tests et les analyses.

• La tokenisation remplace les valeurs sensibles par des tokens qui permettent de remonter à l'originale via un coffre-fort sécurisé. Il s'agit de la norme pour protéger les données de carte bancaire lors des transactions en mode production.

• Le choix de la mauvaise méthode pour un ensemble de données donné peut perturber le fonctionnement ou créer une exposition inutile en matière de conformité. Le bon choix dépend de la nécessité de récupérer la valeur réelle.

Qu'est-ce que le masquage des données par rapport à la tokenisation ?

Le masquage des données remplace une valeur réelle par une fausse valeur qui ressemble à l'originale et se comporte comme elle, mais qui n'y est pas liée. Dans le contexte de la sécurité des paiements, le masquage des données occulte les informations du titulaire de la carte et d'autres données sensibles.

La tokenisation remplace une valeur sensible par un token généré aléatoirement, puis stocke la mise en correspondance entre le token et la valeur originale dans un coffre-fort distinct et étroitement contrôlé. Le token ne présente aucune relation mathématique avec la valeur originale. Une personne qui vole un token n'obtient rien d'utilisable sans accès à ce coffre-fort.

Quelles sont les différences entre le masquage des données et la tokenisation ?

La distinction tient au fait que la valeur réelle doit exister dans un emplacement accessible pour que le système continue de fonctionner.

Voici les caractéristiques qui permettent de déterminer la solution la plus adaptée :

• Réversibilité : les données masquées ne permettent pas de remonter à la valeur originale. C'est le cas des données tokenisées, par l'intermédiaire du coffre-fort qui a émis le token.

• Cas d'usage : le masquage convient aux environnements hors production, comme les tests, le développement et l'analyse. La tokenisation s'applique aux flux de travail de production en temps réel pour lesquels une entreprise doit agir sur des données réelles sans les stocker directement.

• Portée de la protection : le masquage protège les données qui n'ont plus besoin de refléter la réalité. La tokenisation protège les données qui doivent continuer à fonctionner comme si elles étaient réelles, mais sans être hébergées dans les propres systèmes de l'entreprise.

• Applicabilité réglementaire : le masquage permet de respecter les principes de minimisation des données prévus par des cadres tels que le Règlement général sur la protection des données (RGPD) dans l'UE, en supprimant les données personnelles réelles des environnements qui n'en ont pas besoin. La tokenisation est le mécanisme que la norme de sécurité de l'industrie des cartes de paiement (PCI DSS) reconnaît explicitement pour réduire la portée de l'évaluation de conformité d'une entreprise.

Quand utiliser le masquage des données et quand utiliser la tokenisation ?

Utilisez le masquage lorsqu'une valeur réelle n'a aucun rôle fonctionnel dans l'environnement où elle est utilisée. Un développeur qui teste une nouvelle page de paiement, un analyste qui crée un modèle d'attrition et un ingénieur d'assurance qualité qui exécute des suites de tests automatisées ont tous besoin de données qui se comportent comme les données réelles sans pour autant l'être. Le masquage leur offre cette possibilité et supprime totalement le risque, car il ne reste plus rien à exposer.

Utilisez la tokenisation lorsque l'entreprise a véritablement besoin d'agir sur la valeur sensible par la suite. Ce besoin se manifeste dans quelques scénarios :

• Facturation récurrente : une entreprise à modèle d'abonnement qui traite des paiements mensuels a besoin d'un moyen de débiter la même carte bancaire à chaque cycle sans stocker le numéro de carte bancaire lui-même.

• Remboursements et litiges : une équipe de service client qui effectue un remboursement doit faire référence à une transaction spécifique sans avoir à récupérer l'intégralité du numéro de compte (PAN).

• Paiement avec carte bancaire enregistrée : un client qui revient sur le site s'attend à une expérience d'achat en un clic. Cela ne fonctionne que si un token remplace un numéro de carte bancaire que l'entreprise ne détient jamais.

Dans tous ces cas, le masquage ne fonctionnerait pas car il est impossible de démasquer une valeur masquée pour finaliser le paiement.

Quels sont les risques d'un mauvais choix de méthode pour protéger les données sensibles ?

Utiliser le masquage là où la tokenisation est requise perturbe immédiatement le fonctionnement. Un système de facturation récurrente reposant sur des données de carte bancaire masquées ne dispose d'aucun moyen de débiter le client le mois suivant, car la valeur permettant de le faire n'existe plus.

L'utilisation de la tokenisation au lieu du masquage entraîne un autre type de problème : une exposition inutile. Si un système intermédiaire extrait des données tokenisées en production au lieu de données masquées et que cet environnement ne dispose pas des mêmes contrôles d'accès que l'environnement de production, l'entreprise a étendu les données réelles des titulaires de carte à un environnement moins sécurisé sans aucun avantage concret. Les auditeurs de conformité peuvent signaler ce modèle car il intègre dans le champ d'application PCI des systèmes qui n'auraient jamais dû y figurer.

Comment décider de la méthode adaptée à votre entreprise ?

Commencez par une seule question pour chaque ensemble de données : les processus en aval ont-ils besoin de récupérer la valeur réelle ? Si la réponse est non, le masquage est l'outil le plus simple et le plus approprié. Si la réponse est oui, la tokenisation justifie l'ajout d'une infrastructure car la réversibilité est une exigence incontournable.

Quelques vérifications permettent de confirmer la décision :

• Tracez l'utilisation des données : listez tous les systèmes qui utilisent la valeur et déterminez si chacun d'eux a besoin des données réelles ou simplement d'une donnée qui y ressemble.

• Vérifiez les exigences de conformité : si l'objectif est de réduire le champ d'application de la norme PCI DSS, la tokenisation des paiements est le mécanisme reconnu par les organismes de réglementation. La minimisation des données (type RGPD) dans les environnements de test oriente plutôt vers le masquage.

• Examinez la séparation des environnements : les systèmes en production qui gèrent des transactions en mode production nécessitent généralement une tokenisation. Les environnements hors production font plutôt appel au masquage. Mélanger les deux sans raison apparente a tendance à créer plus de risques qu'à en éliminer.

Pour les entreprises qui utilisent Stripe, une partie de cette décision est déjà prise en ce qui concerne les données de paiement collectées via les intégrations Stripe. Le numéro de compte (PAN) est tokenisé au moment de la collecte et l'entreprise n'a jamais à développer cette couche elle-même. Il lui suffit de décider de la marche à suivre concernant le reste de ses données sensibles, par exemple les dossiers internes des clients utilisés à des fins de test ou d'analyse, pour lesquels le masquage fait généralement l'affaire.

Comment Stripe Payments peut vous aider

Stripe Payments propose une solution de paiement unifiée et mondiale qui aide toutes les entreprises, des startups en pleine croissance aux multinationales, à accepter des paiements en ligne, en personne et dans le monde entier.

Stripe Payments peut vous aider à :

• Optimisez votre expérience de paiement : créez une expérience client fluide et économisez des milliers d'heures d'ingénierie grâce à des interfaces utilisateur de paiement préconfigurées, un accès à plus de 125 moyens de paiement et Link, un wallet conçu par Stripe.

• Accéder plus rapidement à de nouveaux marchés : atteignez des clients dans le monde entier et réduisez la complexité et le coût de la gestion multidevise grâce aux options de paiement transfrontalier, disponibles dans 195 pays et plus de 135 devises.

• Unifier les paiements en ligne et en personne : créez une expérience commerciale unifiée, en ligne et en personne, pour personnaliser les interactions, récompenser la fidélité client et booster vos revenus.

• Améliorer les performances de paiement : boostez vos revenus grâce à des outils de paiement personnalisables et simples à configurer, comprenant une protection contre la fraude no-code et des fonctionnalités avancées d’optimisation des taux d’autorisation.

• Accélérer votre croissance avec une plateforme flexible et fiable : appuyez-vous sur une plateforme conçue pour évoluer avec votre activité, offrant un temps de disponibilité historique de 99,999 % et une fiabilité de premier plan.

Découvrez comment Stripe Payments peut vous aider à optimiser vos paiements en ligne et en personne, ou démarrez dès aujourd’hui.