Comment utiliser les jetons pour se conformer aux règles de sécurité des données ?

Or, il n’est pas du tout facile de crypter rétroactivement ces dernières. En effet, les données cryptées sont souvent différentes des données originales : par exemple, un numéro de Sécurité Sociale entièrement numérique à neuf chiffres peut devenir une valeur binaire de 16 caractères.

Le code de cryptage/décryptage doit se propager sur de nombreuses applications à l’intérieur d’un système, avec les risques d’erreurs qu’on devine. Et, pour couronner le tout, la gestion des clés vient s’ajouter au processus de déploiement applicatif.

Comment utiliser les jetons pour se conformer aux règles de sécurité des données ?

D’où l’idée de générer une valeur de substitution qui remplacera les données originales. Ce remplaçant, appelée jeton, servira ensuite de clé pour référencer les données originales et les valeurs connexes dans une base de données hors application, qui peuvent être stockées dans la base de données existante ou gérée par un fournisseur tiers.

La pratique du jeton (jetonisation, tokenization en anglais) présente un double avantage : réduction des changements des applications et isolation et meilleure protection des informations sensibles.

Exemple de jeton

Soit une application de e-commerce qui reçoit des commandes en ligne payées par carte de crédit. Actuellement, une application web stocke ces numéros de cartes de crédit, avec leurs codes de sécurité à trois chiffres, l’adresse de facturation du détenteur de la carte, et d’autres détails sur les références du paiement.

À ce jour, les règles PCI DSS exigent le cryptage de cette information pour empêcher sa divulgation en cas de violation de la base de données ou de l’application. Pourtant, l’application doit conserver les données pour la suite des événements (remboursements et facturation récurrente).

Le principe du jeton pourrait ici s’appliquer de manière très simple : remplacer le numéro de carte de crédit par un numéro séquentiel dans la base de données, puis utiliser ce dernier comme une clé dans le stockage de jetons externe, lequel est crypté et accessible à un ensemble d’applications complètement différent.

Quant à l’application existante, le seul changement la concernant est le suivant : adresser un appel externe au système de jetons, passer les données sensibles et recevoir un échange un jeton qui est stocké dans la base de données. Désormais, quand il faudra extraire les données originales, par exemple pour traiter un remboursement, cette extraction pourra se faire par l’interface de jetonisation, en dehors de l’application originale.

Parfois certaines applications demandent certaines caractéristiques dans les champs concernés par les jetons. Ainsi, l’application de e-commerce pourrait s’assurer que le numéro de carte présente un format valide, avec, en préfixe, un numéro de banque reconnu et, en suffixe, un numéro de compte légal. Le système de jetonisation peut facilement générer un jeton aléatoire répondant à ces exigences, pour satisfaire l’ancienne application tout en protégeant les données sensibles.

Premiers pas avec les jetons

Si vous devez construire un système de jetons à partir de zéro, la tâche s’annonce ardue. Heureusement des tiers sont là pour vous aider, au moyen de progiciels et de software-as-a-service (SaaS). L’offre tierce vise souvent un créneau ou un type d’application bien particulier. Par exemple, il existe des bibliothèques de jetonisation destinées à des systèmes e-commerce sur le web, écrites en Java, PHP, et autres langages de développement sur le web. Les fournisseurs tiers proposent aussi des services de jetons complètement autonomes, accessibles par des services web ou par un simple HTML, qui délèguent (proxy) ce processus en utilisant un serveur hors site.

Les bibliothèques et services fonctionnent à peu près de la même manière. Quand une application reçoit pour la première fois une donnée sensible, comme un numéro de carte de crédit, à partir d’une source d’entrée telle qu’une commande en ligne, elle la transmet, par un canal sécurisé, à la bibliothèque ou au service de jetonisation.

Ce dernier stocke la donnée sensible originale et renvoie le jeton, que l’ancienne application stocke alors à la place de la donnée originale. La bibliothèque ou le service a des interfaces supplémentaires pour extraire les données originales d’un jeton. Dans le cas d’une bibliothèque, la donnée originale peut être utilisée par un programme pour une fonction automatisée, comme une facturation récurrente. Le modèle service est légèrement différent : la donnée ne peut être extraite que par un utilisateur autorisé, pas forcément celui qui a traité la transaction originale. La sécurité est ainsi renforcée en restreignant l’accès aux données en fonction des rôles.

L’extraction des données originales peut aussi servir à l’audit des transactions. Ce genre d’extraction est légèrement différent, parce qu’un rapport d’audit collecte forcément beaucoup de données en un seul endroit. Il vaut mieux limiter l’audit aux seules données jetonisées, avec un échantillonnage des transactions individuelles permis pendant le processus de jetonisation. Abstenez-vous de toute déjetonisation massive qui collecterait des données sensibles et non cryptées dans un seul endroit. En effet, c’est exactement ce que la jetonisation veut empêcher.

Si vous utilisez votre propre système de jetonisation, vous devez employer des pratiques de haute disponibilité IT standard : bases de données bien répliquées, systèmes de stockage redondants, serveurs en basculement et sauvegarde en réseau. Le fait de confier la jetonisation à un tiers présente l’avantage d’intégrer la résilience dans le package. Il vous faudra peut-être une connectivité réseau redondante pour parer aux défaillances de communication locales, mais le service de jetonisation peut appliquer la redondance de données à meilleur compte que le site IT moyen.

L’étendue de la jetonisation

La jetonisation ne rend pas ipso facto une application conforme aux paiements par carte (PCI, Payment Card Industry) ni à tout autre réglementation financière. Ce n’est qu’un outil qu’il faut utiliser judicieusement en fonction de chaque cas. Il réduit alors considérablement le coût de la conformité réglementaire en limitant l’étendue de celle-ci.

Par exemple, le standard PCI DSS 1.2  exige la détection d’intrusion dans le réseau, ainsi que des évaluations de vulnérabilité périodiques des éléments du réseau : routeurs, commutateurs, serveurs, clients et pare-feu, qui transmettent un numéro de carte de crédit en clair. Bien souvent, cela pourrait recouvrir tout le réseau de l’entreprise, rendant la conformité PCI coûteuse en temps et en argent. En jetonisant le numéro de carte de crédit, ou Personal Account Number, PAN, vous pouvez affranchir de cette exigence la grande majorité des éléments du réseau, en limitant ces protections coûteuses à un ou deux endroits où le PAN n’a pas encore été jetonisé.

Au fur et à mesure que les applications deviennent plus complexes, il est de plus en plus difficile de verrouiller tous les endroits et les processus traitant des données sensibles. Quand je regarde les architectures logicielles Service Oriented Architecture (SOA) actuelles qui sont déployées, je ne vois pas comment protéger entièrement les données sensibles. La jetonisation réduit le travail de protection des données à un niveau réaliste, un niveau qui ne se compliquera pas au fil du temps.