Tokeniser des données de titulaire de carte sensibles conformément à la norme PCI DSS

Last reviewed 2025-04-28 UTC

Ce document explique comment configurer un service de tokenisation de carte de paiement à accès contrôlé dans Cloud Run Functions. Pour configurer le service, le déploiement décrit dans ce document utilise les Google Cloud services : Identity and Access Management (IAM) et Cloud Key Management Service (KMS).

La tokenisation est le processus qui consiste à remplacer des informations sensibles telles que des données de carte de crédit par une valeur d'espace réservé anodine, ou jeton. La Partie 3 de la norme de sécurité des données de l'industrie des cartes de paiement (PCI DSS, Payment Card Industry Data Security Standard) exige que la plupart des données stockées sur une carte de crédit soient traitées comme des informations sensibles.

Un jeton en lui-même n'a aucun sens, sauf en tant que moyen de rechercher des données tokenisées dans un contexte particulier. Toutefois, vous devez toujours vous assurer que vos jetons ne contiennent aucune information propre aux utilisateurs et qu'ils ne sont pas directement déchiffrables. Ainsi, si vous perdez le contrôle des jetons de carte de paiement de vos clients, personne ne peut les utiliser pour compromettre les données des titulaires de cartes.

Un service de traitement des informations sensibles

De nombreux services et plates-formes vous permettent de stocker votre environnement de données de titulaire de carte (CDE, Cardholder Data Environment). Ce document vous guide tout au long d'un exemple de déploiement à l'aide de Cloud Run Functions et vous aide à passer aux étapes suivantes pour obtenir une solution prête pour la production.

Cloud Run Functions est une plate-forme sans serveur qui héberge et exécute du code. C'est un endroit pratique pour lancer rapidement une application qui évolue sans intervention. Sachez que, dans un environnement de stockage conforme à la norme PCI DSS, vous devez limiter l'ensemble du trafic entrant et sortant aux connexions autorisées. Ces contrôles précis ne sont actuellement pas disponibles pour Cloud Run Functions. Par conséquent, vous devez mettre en œuvre des contrôles compensatoires ailleurs (comme dans votre application) ou choisir une autre plate-forme. Le même service de tokenisation peut être exécuté de manière conteneurisée, par exemple dans un groupe d'instances géré à autoscaling à autoscaling ou dans un cluster Kubernetes. Ces environnements de production incluent des contrôles complets du réseau VPC et sont préférables.

Cloud KMS est le service de gestion de clés de Google Cloud Google Cloud. Cloud KMS héberge vos clés de chiffrement, les alterne régulièrement, et chiffre ou déchiffre les données du compte stockées.

IAM est utilisé dans ce document pour fournir un contrôle strict sur toutes les ressources utilisées dans le service de tokenisation. Vous devez disposer d'un compte de service spécial dont les jetons expirent fréquemment pour accorder l'accès à Cloud KMS et exécuter la fonction de tokenisation.

La figure suivante illustre l'architecture de l'application de tokenisation que vous créez dans ce document.

Objectifs

• Créez un compte de service.
• Configurez Cloud KMS
• Créez deux fonctions Cloud Run Functions
• Créez un jeton d'authentification.
• Appeler la fonction de tokenisation.

Coûts

Dans ce tutoriel, vous utilisez les composants facturables de suivants Google Cloud:

• Cloud KMS
• Cloud Run functions
• Cloud Build

Obtenez une estimation des coûts en fonction de votre utilisation prévue, utilisez le simulateur de coût.

Les nouveaux utilisateurs de Google Cloud peuvent bénéficier d'un essai sans frais.

Avant de commencer

1. Assurez-vous de disposer du rôle IAM Créateur de projet (roles/resourcemanager.projectCreator). Découvrez comment attribuer des rôles.

2. Dans la Google Cloud console, accédez à la page de sélection du projet.

   Accéder au sélecteur de projet

3. Cliquez sur Create Project (Créer un projet).

4. Attribuez un nom à votre projet. Notez l'ID du projet généré.

5. Modifiez les autres champs si nécessaire.

6. Cliquez sur Créer.

7. Vérifiez que la facturation est activée pour votre Google Cloud projet.

8. Activez les API Cloud Build, Cloud Run Functions et Cloud KMS, si ce n'est pas déjà fait.

   Rôles requis pour activer les API

   Pour activer les API, vous avez besoin de l'autorisation serviceusage.services.enable. Si vous avez créé le projet, vous disposez probablement déjà de cette autorisation via le rôle Propriétaire (roles/owner). Sinon, vous pouvez obtenir cette autorisation via le rôle Administrateur d'utilisation du service (roles/serviceusage.serviceUsageAdmin). Découvrez comment attribuer des rôles.

   Activer les API

Une fois que vous avez terminé les tâches décrites dans ce document, vous pouvez éviter de continuer à payer des frais en supprimant les ressources que vous avez créées. Pour en savoir plus, consultez la section Effectuer un nettoyage.

Créer le compte de service

Le compte de service d'exécution par défaut pour Cloud Run Functions dispose du rôle d'éditeur, qui permet un accès étendu à de nombreux Google Cloud services. Bien qu'il s'agisse du moyen le plus rapide de développer des fonctions, Google recommande de n'utiliser le compte de service par défaut que pour les tests et le développement. Vous pouvez créer un compte de service pour limiter les API que la fonction peut utiliser conformément au principe du moindre privilège. Pour créer un compte de service, procédez comme suit :

1. Dans la Google Cloud console, accédez à la page Comptes de service.

   Accéder à la page "Comptes de service"

2. Sélectionnez votre projet.

3. Cliquez sur Créer un compte de service.

4. Dans le champ Nom du compte de service, saisissez Tokenization Service User. La Google Cloud console remplit le champ ID du compte de service en fonction de ce nom.

5. Facultatif : dans le champ Description du compte de service, saisissez une description du compte de service.

6. Cliquez sur Créer et continuer.

7. Cliquez sur Sélectionner un rôle, puis sélectionnez Chiffreur/Déchiffreur de CryptoKey Cloud KMS.

8. Pour terminer la création du compte de service, cliquez sur OK.

   Vous disposez désormais d'un utilisateur de compte de service associé à l'adresse e-mail suivante :

   tokenization-service-user@YOUR_PROJECT_ID.iam.gserviceaccount.com

Configurer Cloud KMS

1. Dans la Google Cloud console, ouvrez Gestion des clés.

   Accéder à la page Clés de chiffrement

2. Cliquez sur + Créer un trousseau de clés. Dans la boîte de dialogue qui apparaît, procédez comme suit :

   1. Nommez le trousseau de clés tokenization-service-kr.
   2. Sous Key ring location (Emplacement du trousseau de clés), sélectionnez global. Il s'agit d'un choix courant qui suffit pour cet exemple de déploiement. Toutefois, avant de prendre des décisions concernant l'architecture de production, assurez-vous de comprendre les différences entre les différents emplacements Cloud KMS.
   3. Vérifiez bien vos choix, car vous ne pourrez plus renommer les trousseaux de clés une fois qu'ils auront été créés.
   4. Cliquez sur Créer.

   Le système crée le trousseau de clés et vous redirige vers la page de création de clés.

3. Dans la boîte de dialogue Create key (Créer une clé), procédez comme suit :

   1. Nommez la clé cc-tokenization.
   2. Dans le champ Objectif, sélectionnez Symmetric encrypt/decrypt.

   3. Pour Rotation period (Période de rotation), indiquez la valeur de votre choix, puis cliquez sur Create (Créer).

      Remarque : Pensez à noter les entrées que vous avez spécifiées. Vous aurez besoin du nom du projet, du nom du trousseau de clés, de l'emplacement du trousseau de clés et du nom de la clé à utiliser dans les fonctions Cloud Run.

Créer des fonctions Cloud Run

Ce document suppose que vous allez employer Cloud Shell. Si vous utilisez un autre terminal, assurez-vous de disposer de la dernière version de Google Cloud CLI.

1. Dans la Google Cloud console, ouvrez Cloud Shell.

   Accéder à Cloud Shell

2. Clonez le dépôt du projet GitHub et accédez au dossier de travail :

   git clone https://github.com/GoogleCloudPlatform/community gcp-community
   cd gcp-community/tutorials/pci-tokenizer/
   

   Le dossier gcs-cf-tokenizer contient le fichier index.js, qui est la source de deux fonctions Cloud Run différentes que vous allez créer. Il contient également package.json, qui indique à Cloud Run Functions les packages à exécuter.

3. Appliquez la configuration KMS. Copiez le fichier de modèle de configuration et ouvrez-le pour le modifier :

   cp config/default.json config/local.json
   nano config/local.json
   

   L'environnement d'exécution Node.js vous oblige à définir explicitement l' Google Cloud ID de projet :

   "project_id":              "YOUR_PROJECT_ID"

4. Recherchez la configuration KMS et appliquez les valeurs KMS que vous avez créées à la section précédente :

   "location":                "global",
   "key_ring":                "tokenization-service-kr",
   "key_name":                "cc-tokenization"
   

5. Déployez la fonction de tokenisation.

   gcloud functions deploy tokenize --runtime=nodejs18 --trigger-http \
       --entry-point=kms_crypto_tokenize --memory=256MB \
       --service-account=tokenization-service-user@YOUR_PROJECT_ID.iam.gserviceaccount.com \
       --no-allow-unauthenticated --source=.
   

   Cette fonction transforme les informations de carte de crédit en jeton.

6. Recherchez la valeur de l'URL sous httpsTrigger dans le résultat de la commande gcloud functions deploy. Stockez la valeur de l'URL dans la variable d'environnement TOK_URL :

   TOK_URL="TOK_URL"

   Vous allez utiliser la variable d'environnement TOK_URL pour appeler la fonction tokenize.

7. Déployez la fonction de détokenisation en mode KMS.

   gcloud functions deploy detokenize --runtime=nodejs18 --trigger-http \
       --entry-point=kms_crypto_detokenize --memory=256MB \
       --service-account=tokenization-service-user@YOUR_PROJECT_ID.iam.gserviceaccount.com \
       --no-allow-unauthenticated --source=.
   

   Cette fonction inverse le processus de tokenisation.

8. Recherchez la valeur de l'URL sous httpsTrigger dans le résultat de la commande gcloud functions deploy. Stockez la valeur de l'URL dans la variable d'environnement DETOK_URL :

   DETOK_URL="DETOK_URL"

   Vous allez utiliser la variable d'environnement DETOK_URL pour appeler la fonction de détokenisation.

   Vous avez créé deux fonctions Cloud Run Functions distinctes. La première permet de transformer le numéro de carte en jeton, et la seconde d'inverser le processus. Les points d'entrée différents dirigent l'exécution vers la fonction de démarrage appropriée dans le fichier index.js.

9. Une fois les fonctions déployées, ouvrez la console Cloud Run Functions.

   Ouvrir la console Cloud Run Functions

10. Vérifiez que les fonctions ont bien été créées. Si le processus s'est déroulé correctement, vos deux fonctions apparaissent avec une coche à côté d'elles.

Créer un jeton d'authentification

L'option no-allow-unauthenticated de la commande gcloud functions deploy signifie qu'un appelant qui appelle les fonctions doit présenter un jeton d'authentification pour valider l'identité de l'appelant. L'appelant doit disposer de l'autorisation cloudfunctions.functions.invoke. Les rôles prédéfinis suivants disposent de cette autorisation : Demandeur Cloud Functions, Administrateur Cloud Functions et Développeur Cloud Functions.

• Créez le jeton d'authentification :

  AUTH_TOKEN=$(gcloud auth print-identity-token)
  echo $AUTH_TOKEN
  

Ces commandes génèrent une chaîne de jeton d'authentification, la stockent dans la variable d'environnement $AUTH_TOKEN, puis affichent le jeton. Vous appellerez ensuite les fonctions Cloud Run que vous avez déployées avec le jeton.

Appeler la fonction de tokenisation

1. Créez des exemples de données à transmettre à la fonction de tokenisation :

   export TOK_CC=4000300020001000
   export TOK_MM=11
   export TOK_YYYY=2028
   export TOK_UID=543210
   

2. Générez un jeton d'authentification comme décrit dans la section précédente, puis appelez la fonction de tokenisation :

   CC_TOKEN=$(curl -s \
   -X POST "$TOK_URL" \
   -H "Content-Type:application/json" \
   -H "Authorization: Bearer $AUTH_TOKEN" \
   --data '{"cc": "'$TOK_CC'", "mm": "'$TOK_MM'", "yyyy": "'$TOK_YYYY'", "user_id": "'$TOK_UID'"}' \
   )
   echo $CC_TOKEN
   

   La chaîne de tokenisation représentant les données de carte de crédit s'affiche. Cette chaîne est stockée dans la variable d'environnement CC_TOK. Vous pouvez récupérer les informations associées à la carte en appelant la fonction de détokenisation.

3. Inversez la tokenisation avec la commande suivante.

   DETOK_DATA=$(curl -s \
   -X POST "$DETOK_URL" \
   -H  "Content-Type:application/json" \
   -H "Authorization: Bearer $AUTH_TOKEN" \
   --data '{"user_id": "'$TOK_UID'", "token": "'$CC_TOKEN'"}' \
   )
   echo -e "$DETOK_DATA\n"
   

   Le résultat ressemble à ceci :

   {"cc":"4000300020001000","mm":"11","yyyy":"2028","userid":"543210"}
   

   Ces données sont celles qui ont été initialement envoyées à la fonction de tokenisation, déchiffrées, puis récupérées par votre application.

Développer en s'appuyant sur cet exemple

Le code d'exemple sur GitHub est un excellent début, mais il existe d'autres points à prendre en compte avant de passer à l'environnement de production.

Si vous choisissez de tokeniser des cartes de paiement à l'aide de Cloud Run Functions, vous devrez peut-être approfondir votre démarche pour satisfaire votre évaluateur de sécurité qualifié (QSA) ou votre questionnaire d'auto-évaluation. Plus précisément, les sections 1.2 et 1.3 de la norme PCI DSS exigent des contrôles stricts sur le trafic entrant et sortant. Cloud Run Functions et App Engine n'offrent pas de pare-feu bidirectionnel configurable. Vous devez donc créer des contrôles compensatoires ou déployer le service de tokenisation sur Compute Engine ou Google Kubernetes Engine. Si vous souhaitez explorer la conteneurisation, le code GitHub est compatible avec Docker et contient une documentation d'aide.

Cet exemple de code extrait également les dépendances npm (gestionnaire de paquets Node.js) sur le déploiement. Dans votre environnement de production, épinglez toujours les dépendances à des versions approuvées spécifiques. Ajoutez ensuite ces versions à l'application elle-même ou diffusez-les à partir d'un emplacement privé et fiable. Ces deux approches vous aident à prévenir les temps d'arrêt causés par une interruption au niveau du dépôt npm ou par une attaque à l'encontre de la chaîne d'approvisionnement infectant des packages que vous pensiez à l'abri. Si vous précompilez et regroupez l'ensemble de l'application, votre temps de déploiement diminue généralement, ce qui implique des lancements plus rapides et un scaling plus fluide.

Effectuer un nettoyage

Pour éviter que les ressources utilisées dans cet exemple de déploiement ne soient facturées sur votre Google Cloud compte, vous pouvez supprimer le projet contenant les ressources.

Attention : La suppression d'un projet entraîne les effets décrits ci-dessous :
• Tout le contenu du projet est supprimé. Si vous avez utilisé un projet existant pour les tâches décrites dans ce document et que vous le supprimez, vous supprimerez également tout autre travail effectué dans le projet.
• Les ID de projets personnalisés sont perdus. Lorsque vous avez créé ce projet, vous avez peut-être créé un ID de projet personnalisé que vous souhaitez utiliser à l'avenir. Pour conserver les URL qui utilisent l'ID du projet, telle qu'une appspot.com URL, supprimez les ressources sélectionnées dans le projet au lieu de supprimer l'ensemble du projet.
1. Dans la Google Cloud console, accédez à la page Gérer les ressources.

   Accéder à la page "Gérer les ressources"

2. Dans la liste des projets, sélectionnez le projet que vous souhaitez supprimer, puis cliquez sur Supprimer.
3. Dans la boîte de dialogue, saisissez l'ID du projet, puis cliquez Arrêter pour supprimer le projet.

Étape suivante

• Conformité avec la norme de sécurité des données PCI
• Utiliser le protocole OAuth 2.0 pour accéder aux API Google.
• Exigences relatives à la norme PCI DSS
• Supplément d'information : tokenisation conforme à la norme PCI DSS
• Pour découvrir d'autres architectures de référence, schémas et bonnes pratiques, explorez le Cloud Architecture Center.