Conformité avec la norme de sécurité des données PCI

Ce guide vous apprend à assurer la conformité avec la norme de sécurité des données de l'industrie des cartes de paiement (PCI DSS, Payment Card Industry Data Security Standard) pour votre entreprise sur Google Cloud. Il dépasse le cadre du document PCI SSC Cloud Computing Guidelines (PDF, en anglais) pour vous fournir des informations de base sur la norme, vous expliquer votre rôle dans la mise en conformité des applications cloud, puis pour présenter la conception, le déploiement et la configuration d'une application de traitement des paiements conforme à la norme PCI DSS. Le tutoriel explique également les méthodes de surveillance, de journalisation et de validation de l'application.

La norme de sécurité des données PCI, créée par le Conseil des normes de sécurité PCI, est une norme de sécurité des informations destinée aux entreprises qui gèrent des informations relatives aux cartes de paiement (cartes de crédit et cartes de débit). Le PCI SSC regroupe toutes les grandes sociétés de cartes de paiement. Les entreprises qui acceptent les cartes Visa, MasterCard, Discover, American Express ou JCB sont également tenues de se conformer à la norme PCI DSS et peuvent se voir infliger une amende ou une sanction dans le cas contraire.

La norme PCI DSS classe les marchands en plusieurs types allant de ceux qui collectent les informations de paiement par eux-mêmes à ceux qui externalisent entièrement le traitement des paiements. Ce guide couvre les types de marchands suivants : SAQ A, SAQ A-EP et SAQ D.

Objectifs

  • Passer en revue l'architecture de l'application de traitement des paiements
  • Configurer votre environnement de traitement des paiements
  • Déployer et configurer vos serveurs d'applications
  • Configurer la journalisation et la surveillance
  • Valider votre environnement de traitement des paiements

Définitions

Ce guide utilise de nombreux termes et expressions particuliers. En voici quelques-uns des plus courants. Pour plus d'informations, reportez-vous au glossaire PCI DSS.

CDE : acronyme de Cardholder Data Environment (environnement de données de titulaire de carte). Cet acronyme fait référence à toute partie d'une application contenant ou transférant des données de titulaire de carte, telles que le numéro de compte de paiement ou toute information personnelle associée à la carte.

Contrôles compensatoires : solutions alternatives à toute exigence donnée, qui respectent l'intention et la rigueur de l'exigence d'origine et qui offrent un niveau de défense équivalent. Selon la définition officielle, les contrôles compensatoires doivent aller "au-delà" des autres exigences de la norme PCI DSS et doivent être proportionnés au risque supplémentaire que représente le non-respect de l'exigence initiale.

PAN : acronyme de Primary Account Number (numéro de compte principal), également appelé numéro de compte. C'est le numéro unique d'une carte de paiement permettant d'identifier l'émetteur et le compte du titulaire.

QSA : acronyme de Qualified Security Assessor (évaluateur de sécurité qualifié). Les QSA sont qualifiés par le PCI SSC pour effectuer des audits de conformité PCI DSS sur site. Reportez-vous à la page QSA Qualification Requirements (Critères de certification QSA) pour plus d'informations sur les exigences applicables aux sociétés QSA et aux employés.

SAQ : acronyme de Self-Assessment Questionnaire (questionnaire d'auto-évaluation), l'outil de création de rapport utilisé pour documenter les résultats de l'auto-évaluation PCI DSS d'une entité.

Champ d'application : systèmes, procédures et personnes soumis à une évaluation PCI DSS.

Tokenisation : processus qui remplace le numéro de compte principal (PAN) par une valeur de substitution appelée jeton. Le PAN est ensuite stocké dans une recherche sécurisée. La détokenisation est le processus inverse consistant à rechercher un PAN par son jeton. Un jeton peut être un hachage ou une valeur attribuée.

Contexte

La norme PCI DSS prescrit une liste d'exigences conçues pour améliorer la sécurité des titulaires de carte. Ces exigences sont divisées en douze parties principales numérotées et en nombreuses sous-parties. Ce document fait référence aux parties numérotées afin d'étayer le contexte, mais les références de section ne constituent pas une liste exhaustive des exigences applicables.

Les exigences de conformité avec la norme PCI DSS varient en fonction de la manière dont votre entreprise traite les transactions par carte de paiement (type) et du nombre de transactions effectuées chaque année (niveau).

À mesure que le nombre de transactions augmente, le niveau marchand PCI DSS augmente et les consignes de conformité avec la norme PCI DSS deviennent plus strictes. Au niveau marchand le plus élevé (1), la norme PCI DSS exige un audit. Les niveaux varient selon la marque de la carte. American Express définit le niveau 1 à 2,5 millions de transactions annuelles, tandis que MasterCard et Discover le définissent à 6 millions de transactions annuelles. Chaque marque de carte fait l'objet d'exigences de niveau supplémentaires qui dépassent le propos de ce document. Assurez-vous d'auditer votre environnement de traitement des paiements afin qu'il soit conforme à votre niveau marchand.

Étant donné que Google Cloud est un fournisseur de services conforme à la norme PCI DSS 3.2.1 de niveau 1, il peut répondre à vos besoins de conformité PCI DSS quel que soit le niveau marchand de votre société. La section Engagement à respecter la norme présente les domaines couverts par Google.

L'autre variable fondamentale est le type SAQ qui s'applique à votre entreprise. Le questionnaire SAQ décrit les critères à respecter pour se conformer à la norme PCI DSS. Le type SAQ applicable à votre entreprise est déterminé par l'architecture de votre application et par la manière dont vous traitez les données de carte de paiement. Les types suivants s'appliquent à la plupart des marchands :

Type SAQ Description
A Marchands qui externalisent entièrement le traitement des cartes de paiement à un site tiers. Les clients quittent votre domaine (par exemple, via un formulaire Web <iframe>), effectuent le paiement, puis reviennent dans votre application.

En d'autres termes, votre entreprise ne peut en aucun cas toucher aux données de la carte du client.
A-EP Marchands qui externalisent le traitement des paiements à un fournisseur tiers, mais qui peuvent accéder aux données de la carte du client à tout moment du processus. Ces marchands ont également accès à des éléments de page qu'ils contrôlent, tels que JavaScript ou CSS, intégrés à la page de paiement tierce.

En d'autres termes, soit votre application de traitement des paiements transmet les données de la carte à une société de traitement des paiements côté client, soit la société de traitement des paiements restitue le contenu que vous hébergez.
D Marchands qui acceptent les paiements en ligne, mais qui ne répondent pas aux critères du type SAQ A ou SAQ A-EP. Ce type inclut tous les marchands qui appellent une API de société de traitement des paiements à partir de leurs propres serveurs, indépendamment de la tokenisation.

En d'autres termes, si vous n'êtes pas du type SAQ A ou SAQ A-EP, vous êtes du type SAQ D.

Le type SAQ D établit une distinction entre marchands et fournisseurs de services. Ces derniers ne sont pas abordés dans ce document. Toutes les références au type SAQ D s'adressent aux marchands tels que définis dans la norme PCI DSS.
Diagramme de Venn des exigences SAQ. Le type SAQ A-EP englobe le type SAQ A et le type SAQ D englobe le type SAQ A-EP.
Diagramme de Venn des exigences SAQ. Le type SAQ A-EP englobe le type SAQ A et le type SAQ D englobe le type SAQ A-EP.

Comme les marchands peuvent correspondre à n'importe quelle combinaison de niveau et de type, les exigences de conformité applicables à votre entreprise varient considérablement en fonction de la situation.

Engagement à respecter la norme

Google utilise diverses technologies et processus pour sécuriser les informations stockées sur ses serveurs. Les exigences PCI DSS validées indépendamment par Google s'appliquent aux technologies et infrastructures Google Cloud gérées par Google. Si Google offre aux marchands une marge de contrôle importante sur leurs instances de calcul exécutées sur son infrastructure, Google ne contrôle pas la sécurité du système d'exploitation, des packages, ni des applications qu'ils déploient sur Google Cloud. Il vous incombe de respecter les exigences PCI DSS pour les packages de système d'exploitation et les applications que vous déployez, en plus des autres personnalisations requises par votre architecture.

Google Cloud respecte les exigences PCI DSS définies pour un fournisseur de services de niveau 1 ainsi que toutes les exigences applicables aux fournisseurs de services. La matrice de responsabilité partagée de Google Cloud décrit les obligations de conformité PCI DSS. Elle peut constituer une référence utile pour la mise en conformité avec la norme PCI DSS et l'exécution de vos propres audits PCI DSS.

Conseils relatifs aux produits

App Engine

Les règles de pare-feu d'entrée sont disponibles dans App Engine, mais ce n'est pas le cas des règles de sortie pour le moment. Conformément aux exigences 1.2.1 et 1.3.4, vous devez vous assurer que tout le trafic sortant est autorisé. Les marchands de type SAQ A-EP et SAQ D doivent effectuer des contrôles compensatoires ou utiliser un autre produit Google Cloud. Compute Engine et GKE sont les alternatives préférées.

Cloud Functions

Tout comme dans App Engine, les règles de pare-feu de sortie ne sont pas disponibles dans Cloud Functions pour le moment. Les marchands de type SAQ A-EP et SAQ D doivent effectuer des contrôles compensatoires ou utiliser un autre produit Google Cloud. Compute Engine et GKE sont les alternatives préférées.

Google Kubernetes Engine

Vous gérez les nœuds et les pods d'un cluster GKE de la même manière que n'importe quel serveur géré par un marchand. Vous mettez en œuvre la journalisation, l'instrumentation et les correctifs au niveau du nœud et du pod. Vous ne devez pas conserver les données des titulaires de carte au niveau du nœud. Cependant, les nœuds entrent toujours dans le champ d'application s'ils contiennent ou pourraient contenir des pods soumis aux exigences de conformité.

Pour restreindre l'accès à votre plan de contrôle (maître de cluster), utilisez des réseaux autorisés afin de bloquer les adresses IP non approuvées extérieures à l'environnement Google Cloud. Ces règles de routage interdomaine sans classe (CIDR) sont compatibles avec les clusters privés et agissent comme une liste d'autorisations (ou liste blanche).

Si vos projets soumis aux exigences de conformité contiennent différents types de pods, mettez en œuvre des règles de réseau dans le cluster GKE. Elles fonctionnent de la même manière que les pare-feu de cloud privé virtuel (VPC) que vous connaissez peut-être déjà. Vous pouvez autoriser ou refuser le trafic en fonction des règles IP ou des libellés.

L'exigence 2.2.1 stipule qu'une seule fonction principale peut être mise en œuvre par serveur. Cependant, elle n'interdit pas le cas d'un seul cluster GKE hébergeant plus d'un type de pod. La principale fonction des nœuds GKE est de diffuser et de gérer des conteneurs. S'ils sont conçus correctement, les pods individuels peuvent également adhérer à cette règle de fonction principale dans un seul cluster.

Cloud Storage

L'exigence 3.4 stipule qu'un PAN soit illisible où qu'il soit stocké. Si Google offre systématiquement le cryptage au repos, il n'effectue pas automatiquement les hachages à sens unique, la troncature ni la tokenisation comme l'exigent également les règles.

Exemple d'architectures

Cette section illustre les méthodes permettant de mettre en œuvre un environnement conforme aux types SAQ A, SAQ A-EP et SAQ D.

Présentation de l'architecture

SAQ A

L'architecture de type SAQ A est l'architecture de traitement des paiements la plus élémentaire. D'une part, les paiements sont traités par des tiers et d'autre part, les applications et pages des marchands n'accèdent pas aux données de la carte.

À un niveau élevé, le flux de traitement des paiements s'effectue comme suit :

  1. Le client effectue ses sélections et procède au paiement.

  2. L'application de paiement redirige le client vers une société de traitement des paiements tierce.

  3. Le client saisit les informations de sa carte de paiement dans un formulaire détenu et géré par la société tierce.

  4. La société de traitement des paiements tierce vérifie les informations de la carte de paiement, puis débite le montant ou refuse la carte.

  5. Après le traitement de la transaction, la société tierce renvoie le client à l'application du marchand avec les détails de la transaction.

  6. L'application du marchand envoie une demande de vérification à la société de traitement des paiements pour confirmer la transaction.

  7. La société répond pour vérifier les détails de la transaction.

Traitement des informations entre le navigateur du client, le site du marchand, la société de traitement des paiements et la passerelle de paiement.
Architecture d'un environnement SAQ A tiers de traitement des paiements

SAQ A-EP

L'architecture de traitement des paiements de type SAQ A-EP est centrée sur une application de traitement des paiements qui s'exécute sur des instances de machine virtuelle Compute Engine. Ces instances appartiennent à un réseau privé sécurisé et communiquent avec des services hors réseau sur des canaux sécurisés.

À un niveau élevé, le flux de traitement des paiements s'effectue comme suit :

  1. Le client saisit les informations de sa carte de paiement dans un formulaire détenu et géré par votre société.

  2. Lorsque le client envoie ses informations, les informations du formulaire sont transmises de manière sécurisée à une société de traitement des paiements tierce.

  3. La société de traitement des paiements tierce vérifie les informations de la carte de paiement, puis débite le montant ou refuse la carte.

  4. La société de traitement des paiements renvoie une réponse à votre application de paiement, qui transmet ensuite un message à votre application principale.

Toutes ces interactions sont enregistrées et surveillées avec Cloud Logging et Cloud Monitoring.

Architecture d&#39;un environnement de traitement des paiements de type SAQ A-EP
Architecture d'un environnement de traitement des paiements de type SAQ A-EP

SAQ D

L'architecture de traitement des paiements de type SAQ D est centrée sur une application de traitement des paiements qui s'exécute sur des instances de machine virtuelle Compute Engine. Ces instances appartiennent à un réseau privé sécurisé et communiquent avec des services hors réseau à l'aide de canaux sécurisés.

À un niveau élevé, le flux de traitement des paiements s'effectue comme suit :

  1. Le client saisit les informations de sa carte de paiement dans un formulaire détenu et géré par votre société.

  2. Lorsque le client envoie ses informations, votre application de paiement reçoit les informations du formulaire.

  3. Votre application de paiement valide les informations de paiement et les transmet en toute sécurité à une société de traitement des paiements tierce via une API backend.

  4. La société de traitement des paiements tierce vérifie les informations de la carte de paiement, puis débite le montant ou refuse la carte.

  5. La société de traitement des paiements renvoie une réponse à votre application de paiement, qui transmet ensuite un message à votre application principale.

Toutes ces interactions sont enregistrées et surveillées avec Logging et Monitoring.

Architecture d&#39;un environnement de traitement des paiements de type SAQ D
Architecture d'un environnement de traitement des paiements de type SAQ D

Flux de traitement des paiements du point de vue des clients

SAQ A

Cette section décrit le flux de traitement tiers des paiements du point de vue des clients utilisant votre application.

Flux de traitement SAQ A tiers des paiements du point de vue des clients
Flux de traitement SAQ A tiers des paiements du point de vue des clients

Lorsque votre client accède au formulaire de paiement, l'application présente un <iframe> hébergé par la société de traitement des paiements. Votre application ne peut pas accéder au contenu de l'<iframe> ni le surveiller en raison des limites Cross-Origin Resource Sharing. Lorsque le client transmet ses informations de carte de paiement, la société de traitement des paiements accepte ou refuse la carte, puis le renvoie vers votre application. Votre application vérifie ensuite la réponse de la société de traitement des paiements quant à la transaction et agit en conséquence. Votre application n'a pas accédé aux informations de carte de paiement et ne les a pas traitées.

SAQ A-EP

Cette section décrit le même flux interne de traitement des paiements que décrit précédemment, mais du point de vue des clients utilisant votre application.

Flux de traitement SAQ A-EP tiers des paiements du point de vue des clients
Flux de traitement SAQ A-EP tiers des paiements du point de vue des clients

Lorsque votre client accède à l'URL du formulaire de paiement, le site présente un formulaire hébergé par votre application de paiement. Lorsque le client envoie ses informations de carte de paiement, le formulaire est directement transmis à la société de traitement des paiements. Celle-ci accepte ou refuse la carte, puis renvoie le client vers votre application. Votre application vérifie ensuite la réponse de la société de traitement des paiements quant à la transaction et agit en conséquence. Il se peut que le client ne voie pas l'intervention de la société de traitement des paiements tierce, mais quoi qu'il en soit, votre application n'a pas accédé aux informations de la carte de paiement côté serveur.

SAQ D

Cette section décrit le flux de traitement interne des paiements du point de vue des clients utilisant votre application.

Flux de traitement SAQ D tiers des paiements du point de vue des clients
Flux de traitement SAQ D tiers des paiements du point de vue des clients

Lorsque votre client accède à l'URL du formulaire de paiement, il est dirigé de manière sécurisée vers le formulaire via un équilibreur de charge HTTPS. Lorsque le client envoie ses informations de carte de paiement, votre application de traitement des paiements transmet les informations du formulaire de manière sécurisée à une société de traitement des paiements tierce. Celle-ci accepte ou refuse la carte, puis renvoie une réponse à votre application de traitement des paiements.

Flux interne de traitement des paiements

SAQ A et SAQ A-EP

Cette section décrit le flux de traitement des paiements du point de vue des serveurs exécutant votre application.

Flux interne SAQ A et SAQ A-EP
Flux interne SAQ A et SAQ A-EP

Votre application de traitement des paiements reçoit et analyse la réponse renvoyée par la société de traitement des paiements tierce, puis envoie une partie ou la totalité des données de réponse à l'application principale. À ce stade, l'application de traitement des paiements a terminé de traiter la transaction. L'application principale se charge alors de notifier vos clients.

SAQ D

Cette section décrit le flux interne de traitement des paiements du point de vue des serveurs exécutant votre application.

Flux interne SAQ D
Flux interne SAQ D

Votre application de traitement des paiements valide les informations de carte de paiement envoyées par le client, puis les transmet à la société de traitement des paiements via une API backend. La société de traitement des paiements tente alors de débiter la carte et répond en transmettant les détails de la transaction. Votre application reçoit et traite la réponse, puis envoie une partie ou la totalité des données de réponse à l'application principale. À ce stade, l'application de traitement des paiements a terminé de traiter la transaction. L'application principale se charge alors de notifier le client et de livrer le produit.

Flux de surveillance et de journalisation des données

Le flux de surveillance et de journalisation s'effectue comme suit :

Flux de surveillance et de journalisation
Flux de surveillance et de journalisation

Configurer votre environnement de traitement des paiements

Cette section explique comment configurer l'environnement de traitement des paiements. La configuration comprend les tâches suivantes :

  • Créer un compte Google Cloud pour isoler votre environnement de traitement des paiements de l'environnement de production
  • Restreindre l'accès à votre environnement
  • Configurer vos ressources virtuelles
  • Concevoir l'image de base Linux que vous utiliserez pour configurer les serveurs d'applications
  • Mettre en œuvre une solution de gestion sécurisée des paquets

Créer un compte

Pour simplifier la restriction des accès et les audits de conformité, créez un environnement de traitement des paiements de type "production", totalement isolé de l'environnement de production standard et de tout environnement de développement ou d'assurance qualité (exigence 6.4.1). Pour assurer l'isolation, créez et utilisez un compte Google Cloud distinct du compte d'environnement de production principal. Les utilisateurs expérimentés dans la configuration de IAM (Identity and Access Management) peuvent réaliser une isolation équivalente en utilisant des projets distincts pour les tâches soumises aux exigences de conformité.

Restreindre l'accès à votre environnement

Autorisez l'accès à l'environnement de traitement des paiements uniquement aux personnes qui déploient le code de votre système de paiement ou qui en gèrent les machines (section 7.1 et exigence 8.1.1). C'est ce qu'on appelle le principe du moindre privilège. Définissez des rôles IAM pour restreindre les accès. Les bonnes pratiques incluent, dans la mesure du possible, l'utilisation de rôles de façon à n'accorder que les autorisations requises pour effectuer le travail attendu, et l'affectation exclusive du rôle de propriétaire aux membres ayant légitimement besoin d'un accès racine complet à vos services. Reportez-vous au guide de sécurité IAM pour en savoir plus.

L'accès automatisé à tout service géré doit s'appuyer sur des comptes de service. Ces comptes simplifient le cycle de vie de la gestion des applications en offrant un moyen de gérer l'authentification et l'autorisation des applications. Ces comptes offrent un moyen flexible, mais sécurisé, de regrouper des instances de machine virtuelle avec des applications et des fonctions similaires ayant une identité commune. Vous pouvez appliquer la sécurité et le contrôle des accès au niveau du compte de service via les rôles IAM et les règles de pare-feu VPC.

Tous les éléments contenus dans un dossier héritent des règles IAM que vous appliquez au dossier. Les autorisations par défaut sont "Tout refuser" (exigence 7.2.3), et chaque règle que vous appliquez n'ajoute que des autorisations.

L'exigence 8.2.3 prévoit certaines règles de base pour les mots de passe utilisateur. L'Institut national des normes et de la technologie (NIST, National Institute of Standards and Technology) définit un ensemble de règles plus sécurisé pour les mots de passe sécurisés dans la section 5.1.1 de la publication NIST SP800-63B. Dans la mesure du possible, Google recommande de respecter les consignes d'identification numérique du NIST.

La section 12.7 de la norme PCI DSS SAQ D exige que les personnes ayant accès à l'environnement concerné par les exigences de conformité se soumettent à une vérification des antécédents, conformément aux lois locales, avant de pouvoir accéder à l'environnement. Pour réduire le risque de non-conformité, envisagez d'effectuer ces vérifications des antécédents criminels et des références pour chaque personne, quel que soit le type de conformité.

Sécuriser votre réseau

Pour sécuriser le trafic entrant et sortant en provenance et à destination de votre réseau d'applications de traitement des paiements, vous devez créer les éléments suivants :

  • Règles de pare-feu Compute Engine
  • Tunnel de réseau privé virtuel (VPN) Compute Engine
  • Équilibreur de charge HTTPS Compute Engine

Pour créer votre VPC, nous recommandons Cloud NAT comme couche de sécurité réseau supplémentaire. Il existe de nombreuses options efficaces pour sécuriser les réseaux d'instances GKE et Compute Engine.

Créer des règles de pare-feu

Créez des règles de pare-feu pour limiter le trafic entrant à chacune de vos instances Compute Engine (exigences 1.2.1 et 1.3.2). N'autorisez le trafic entrant qu'à partir des trois sources suivantes :

  • Réseau public HTTPS, afin que les clients puissent accéder à votre page de paiement.
  • Votre réseau d'applications, de sorte que votre application de traitement des paiements puisse recevoir des réponses de la société de traitement des paiements tierce.
  • Votre réseau de bureau interne, de sorte que vous puissiez accéder aux instances à des fins d'audit et de gestion.

Limitez le trafic sortant en appliquant des règles de pare-feu aux instances individuelles. Vous pouvez appliquer ces règles localement avec des règles "iptable" ou, plus généralement, en définissant des règles de pare-feu VPC et des tags réseau. N'autorisez le trafic sortant que depuis le formulaire de paiement vers la société de traitement des paiements tierce. Cette connexion ne doit reposer que sur le protocole HTTPS. Reportez-vous à la section Journalisation des règles de pare-feu ci-dessous pour tester votre travail.

Cloud DNS offre des zones DNS privées vous permettant de nommer en toute sécurité des hôtes au sein de votre CDE sans risquer de divulguer publiquement des données de topologie réseau sensibles.

Restreignez le trafic comme suit :

Source Destination Port Direction et raison
Équilibreur de charge public Formulaire de paiement tiers tcp:443 Entrant
Accès public à l'application de traitement des paiements
Formulaire de paiement tiers Société de traitement des paiements tierce tcp:443 Sortant
Transmission des requêtes AUTH au fournisseur de services de paiement
Société de traitement des paiements tierce Votre application de traitement des paiements tcp:5480 Entrant
Acceptation des requêtes AUTH des systèmes de paiement (ne contient aucune donnée de titulaire de carte)
Réseau de bureau de votre entreprise Passerelle VPN tcp:8000 Entrant
Accès à l'environnement de traitement des paiements pour accéder aux journaux et aux ordinateurs de développement

De plus, le trafic suivant se produit en toute sécurité sur le réseau interne de votre application de traitement des paiements :

Source Destination Port Motif
Formulaire de carte Proxy PCI tcp:5480 Échange de données de carte chiffrées contre un jeton de mode de paiement
Tous les hôtes Serveurs Google NTP udp:123 Synchronisation horaire
Passerelle VPN Tous les hôtes tcp:22 Connexions Secure Shell (SSH)

Mettre en place un tunnel VPN sécurisé

Compute Engine fournit un service VPN que vous pouvez utiliser pour établir un tunnel VPN sécurisé entre votre environnement sur site et votre environnement de traitement des paiements (sections 2.3 et 4.1).

Créer un équilibreur de charge HTTPS

Pour vous assurer que le trafic client entrant est sécurisé, créez un équilibreur de charge HTTP(S) Compute Engine (sections 2.3 et 4.1). Pour ce faire, vous avez besoin des éléments suivants :

  • Un sous-domaine de votre site Web utilisé pour héberger votre formulaire de traitement des paiements, par exemple payments.your-domain-name.com.
  • Un certificat SSL valide et signé qui a été enregistré pour votre sous-domaine

Vérifiez la validité de votre domaine en consultant ses paramètres DNS dans l'interface de configuration de domaine de votre bureau d'enregistrement Web.

Créer une image de base Linux

La norme PCI DSS contient des exigences décrivant la configuration des machines faisant partie d'une architecture de traitement des paiements conforme. Vous pouvez assurer le respect de ces exigences de plusieurs manières, mais la méthode la plus simple est la suivante :

  1. Créez une liste des logiciels et bibliothèques à installer sur chaque serveur soumis aux exigences de conformité pour votre application de traitement des paiements. Pour éviter d'introduire des failles inutiles dans votre système (exigence 2.2.2), n'incluez que le minimum de logiciels et de bibliothèques dont vous avez besoin pour exécuter votre application. Parmi ces logiciels et bibliothèques peuvent figurer le SDK Cloud, des environnements d'exécution et des bibliothèques spécifiques à un langage, ou un serveur Web.

  2. Créez une instance Compute Engine qui utilise l'une des images de système d'exploitation préconfigurées Compute Engine.

  3. Installez les bibliothèques et les logiciels que vous avez répertoriés précédemment.

  4. Installez et configurez ntp de façon à maintenir la synchronisation des horloges système. La gestion des horloges de serveur avec le protocole NTP garantit l'intégrité des horodatages dans les journaux (section 10.4).

  5. Assurez-vous que l'image respecte les bonnes pratiques de création d'une image Compute Engine sécurisée (section 2.2).

  6. Après avoir configuré l'image de base, utilisez-la pour créer une image disque Compute Engine personnalisée. Cette image vous permet de créer des instances de machine virtuelle à l'aide de l'image de base Linux.

Utiliser la gestion sécurisée des packages

La gestion des packages est un élément clé d'un environnement d'hébergement à sécurité renforcée. Selon la section 2.2, vous devez assurer le respect des normes de renforcement acceptées par l'industrie. Un gestionnaire de packages tel que RPM, Yum ou Apt est probablement installé, sauf si vous utilisez le système d'exploitation Container-Optimized OS de Google. Votre application peut utiliser son propre gestionnaire de packages spécifique au langage de programmation, tel que NPM, PyPi ou Composer, et télécharger des dépendances lors de la première exécution.

Si votre application récupère des mises à jour sur Internet, vous devez traiter les sources de mises à jour comme un risque potentiel pour la sécurité. Les attaques côté offre, ou en amont, qui sont incluses de manière malveillante dans les packages hébergés publiquement, deviennent de plus en plus courantes. Imaginez les effets de l'installation d'une mise à jour vers SSH contenant du code malveillant.

Vous pouvez réduire le risque d'attaques côté offre en créant une liste de destinataires sécurisés pour vos packages et en vérifiant qu'ils correspondent à la liste. Conservez une liste des numéros de version testés et approuvés pour chaque package que vous utilisez. Enregistrez le numéro de version avec son hachage ou sa signature. Avant d'installer ou de mettre à jour une application, assurez-vous que le gestionnaire de packages valide le hachage ou la signature.

La plupart des systèmes de gestion de packages permettent un hébergement privé. Si possible, lancez votre propre serveur de gestion de packages privé, et uniquement les logiciels testés et approuvés par l'hôte. Verrouillez le gestionnaire de packages afin qu'il ne puisse pas contacter d'autres serveurs pour les mises à jour.

Dans l'idéal, votre processus de création d'application va chercher et valider tous les packages, puis créer une révision de l'image de disque personnalisée qui inclut tout ce dont le conteneur a besoin. De cette façon, vos serveurs se lancent et se développent sans délai d'installation, ce qui réduit les risques d'erreurs aléatoires au moment du lancement. Vous pouvez également revoir n'importe quelle version précédente de votre application exactement telle qu'elle était en production. Pour cela, il vous suffit de lancer son image. Cela peut faciliter les diagnostics et l'investigation.

Déploiement et configuration

À présent, configurez le déploiement et les instances à partir de l'image de base.

Déployer votre environnement

Pour satisfaire aux exigences de la norme PCI DSS, assurez-vous de déployer l'application correcte chaque fois, de manière sécurisée, et de ne pas installer d'autres packages logiciels pendant le déploiement. Pour simplifier le processus de déploiement, envisagez de créer un déploiement automatisé pour votre application à l'aide de Cloud Deployment Manager.

Deployment Manager vous permet de décrire l'ensemble de votre environnement de traitement des paiements, y compris ses règles de pare-feu, ses passerelles, ses équilibreurs de charge et ses instances. Par ailleurs, Deployment Manager peut vous aider à créer une piste d'audit qui montre comment chaque environnement d'application a été créé, et vous permet de définir la version des environnements à mesure que vous les améliorez et les modifiez.

Dans un déploiement automatisé, vous devez vérifier l'intégrité du logiciel en cours de déploiement, qu'il s'agisse d'un logiciel tiers ou du vôtre. Pour ce faire, vous pouvez exécuter un hachage automatisé sur chaque package à mesure de son installation. Une fois le hachage vérifié, vous pouvez exécuter des tests de sécurité ou autres à l'aide d'un framework de test automatisé et vérifier leur réussite.

Enfin, lors du déploiement d'instances de Compute Engine, concevez un plan de reprise après sinistre en cas d'échec de vos instances. Si le temps d'arrêt acceptable est suffisamment long, un plan de reprise manuel peut suffire. Sinon, vous devez concevoir un plan de reprise automatisé. Pour obtenir des conseils, consultez les pages Guide de planification de reprise après sinistre, Concevoir des systèmes robustes et Créer des applications Web évolutives et résilientes.

Configurer votre environnement

Une fois vos instances déployées, vérifiez si elles sont correctement configurées. Installez des logiciels et des bibliothèques supplémentaires au-dessus de chaque image de base d'instance, selon vos besoins. Pour éviter la complexité, les coûts et le risque global associés à une configuration manuelle, utilisez un outil de gestion de configuration automatisé tel que Skaffold, Chef, Puppet, Ansible ou Salt.

Les attaques de chaîne d'approvisionnement sur les sources en amont deviennent une préoccupation majeure. Ainsi, en plus des images de base Linux, vous pouvez utiliser un outil tel que l'API Grafeas pour auditer le code en amont.

Mettre en œuvre Forseti Security

Forseti Security est un ensemble d'outils Open Source conçus par la communauté pour vous aider à améliorer la sécurité de vos environnements Google Cloud. Son architecture modulaire vous permet d'activer des composants individuels, dont plusieurs peuvent répondre à des exigences spécifiques dans le cadre de la norme PCI DSS.

Inventory crée un instantané d'inventaire de vos ressources Google Cloud pour que vous disposiez d'un enregistrement historique de votre architecture.

Scanner utilise les informations collectées par Forseti Inventory pour comparer régulièrement les règles d'accès basées sur les rôles de vos ressources Google Cloud. Scanner applique des règles pour auditer les ressources Google Cloud, comme par exemple les suivantes :

  • Stratégies de gestion de l'authentification et des accès (IAM) pour les organisations, les dossiers et les projets
  • LCA pour les buckets
  • LCA pour les ensembles de données BigQuery
  • Réseaux autorisés par Cloud SQL

Avec Scanner, vous pouvez spécifier les utilisateurs, groupes et domaines autorisés, obligatoires ou exclus des ressources, et vous assurer que ces règles d'accès demeurent cohérentes. Si Scanner trouve des règles d'accès qui ne correspondent pas à vos règles Scanner, il peut enregistrer des informations sur les violations de ces règles dans Cloud SQL ou Cloud Storage. Vous êtes ainsi protégé contre les modifications dangereuses ou involontaires.

Enforcer utilise les règles que vous avez créées pour comparer l'état actuel de votre pare-feu Compute Engine à un état spécifié. Enforcer est un outil de ligne de commande à la demande, qui compare les règles selon un mode de traitement par lot, sur l'ensemble des projets gérés ou bien sur des projets sélectionnés. Si Enforcer détecte des différences de règle, il utilise les API Google Cloud pour apporter des modifications et afficher la sortie des résultats.

Le module complémentaire Explain offre une visibilité sur vos stratégies IAM. Explain peut vous aider à déterminer les éléments suivants :

  • Qui a accès à quelles ressources et comment cet utilisateur peut interagir avec ces ressources.
  • Pourquoi un compte principal dispose d'une autorisation sur une ressource, ou pourquoi il n'en a pas et comment corriger le problème.
  • Quels rôles accordent une autorisation et quels rôles ne sont pas synchronisés avec les modifications récentes.

Une fois que vous l'avez configurée, la fonctionnalité de notifications par e-mail peut envoyer des notifications par courrier électronique pour Inventory et Scanner.

Mettre en œuvre la journalisation d'audit immuable

Stackdriver génère automatiquement des journaux d'audit pour une grande variété d'activités sur de nombreux produits. À long terme, vous pouvez stocker en toute sécurité des journaux immuables à l'aide de verrous de bucket Cloud Storage (section 10.5). Les verrous de bucket vous permettent de définir une stratégie visant à rendre tous les objets immuables et non supprimables pendant une durée que vous spécifiez, de quelques secondes à plusieurs années. Si vous avez besoin d'accéder au programme de manière anticipée, contactez votre représentant Google Cloud.

Mettre en œuvre des journaux de flux de cloud privé virtuel

Le service de journaux de flux VPC est conçu pour enregistrer les flux de réseau envoyés ou reçus par des instances de machine virtuelle. Vous pouvez utiliser ces journaux pour la surveillance du réseau (section 10.2), l'analyse judiciaire (exigence 10.6.3) et l'analyse de la sécurité en temps réel.

Installer l'agent Logging

Une fois que vous avez configuré des règles "iptable" sur vos serveurs, chaque serveur enregistre chaque activité dans son bloc de stockage. Consultez la page des tarifs de Logging pour en savoir plus sur les tarifs de l'attribution gratuite et du transfert de données. Pour conserver ces journaux et générer des alertes en cas d'activité anormale, transmettez-les à Logging et Monitoring en installant l'agent Logging sur chaque serveur (exigence 10.5.3).

Intégrer un système de détection des intrusions

Pour garantir la sécurité de votre environnement de traitement des paiements, décrit à la section 11.4, intégrez un système de détection des intrusions (IDS, Intrusion Detection System). Cela vous permettra de savoir quand des utilisateurs malveillants tentent d'attaquer le système. Il existe deux manières d'intégrer un IDS à un environnement de traitement des paiements : soit vous l'intégrez à chaque point d'entrée, soit vous l'installez sur chaque serveur.

Pour réduire la complexité de l'architecture de votre environnement et simplifier la mise en conformité avec la section 11.5, installez un IDS sur chaque serveur. Après avoir recherché et choisi le logiciel IDS à utiliser, intégrez l'installation de l'IDS au script d'installation de démarrage de chaque serveur.

Les journaux IDS étant soumis aux exigences de conformité avec la norme PCI DSS, ils doivent être transmis à Stackdriver Logging et Stackdriver Monitoring pour la génération de rapports, les alertes et l'audit.

Mettre en œuvre Security Command Center

Le service Security Command Center (bêta) aide les équipes de sécurité à rassembler des données, à identifier les menaces et à réagir avant qu'elles ne nuisent à leur activité. Il apporte une vision complète des risques liés aux applications et aux données, de sorte que vous puissiez rapidement limiter les menaces pesant sur vos ressources cloud et en évaluer la santé globale. Avec Security Command Center, vous pouvez afficher et surveiller l'inventaire de vos ressources cloud, identifier les données sensibles présentes sur vos systèmes de stockage, détecter les failles Web courantes et examiner les droits d'accès accordés à vos ressources critiques, le tout à partir d'un tableau de bord centralisé. Cela peut vous aider à respecter plusieurs exigences, y compris les sections 5 et 6.6.

Automatiser le déploiement de vos applications

Créez votre outil de gestion de la configuration de façon à récupérer et lancer en toute sécurité la dernière version de votre application. Votre application peut être récupérée à partir de n'importe quel emplacement, comme par exemple Cloud Storage, à condition que cet emplacement soit sécurisé.

La plupart des outils de gestion de la configuration mentionnés ci-dessus prennent en charge les workflows d'intégration et de déploiement continus (CI/CD), qui peuvent également être utilisés pour effectuer une analyse automatisée (exigence 11.2.3) et garantir la révision du code (exigence 6.3.2).

Capturer les journaux du gestionnaire de configuration

Lors de la configuration du gestionnaire de configuration, assurez-vous qu'il enregistre tous les détails de l'installation. Une fois le processus de configuration terminé, vérifiez s'il envoie les journaux à Stackdriver Logging et Stackdriver Monitoring.

Journalisation et surveillance

Pour garantir la conformité avec la norme PCI DSS en application de la section 10, assurez-vous que chaque étape de votre environnement de traitement des paiements est surveillée et enregistrée. Chaque activité de serveur sur chaque instance doit être consignée, et chaque action d'utilisateur doit pouvoir être examinée ultérieurement.

Activer Access Transparency

Grâce à une fonctionnalité appelée Access Transparency, Logging offre désormais des journaux en temps quasi réel lorsque les administrateurs Google Cloud accèdent à votre contenu. Les journaux d'audit Cloud offrent déjà une visibilité sur les actions de vos propres administrateurs. Toutefois, cette piste d'audit exclut généralement les actions entreprises par l'équipe d'assistance ou d'ingénierie de votre fournisseur de services cloud. Par exemple, avant la journalisation Access Transparency, si vous ouvriez une demande d'assistance auprès de Google pour laquelle un accès à vos données était requis, cet accès n'était pas suivi dans les journaux d'audit Cloud. Access Transparency comble cette lacune en effectuant une journalisation en quasi-temps réel des accès ciblés manuels accordés aux équipes d'assistance ou aux ingénieurs.

Google a récemment publié le service Access Approval (actuellement en phase de lancement d'accès anticipé). Alors qu'Access Transparency fournit des informations sur les accès de l'assistance et des ingénieurs Google, Access Approval vous permet d'approuver explicitement l'accès à vos données ou configurations sur Google Cloud avant que cet accès ne soit effectif. Pour plus de précisions et demander un accès anticipé, consultez la page liée.

Activer la journalisation des règles de pare-feu

La journalisation des règles de pare-feu vous permet d'activer la journalisation individuellement pour chacune des règles de pare-feu. Vous pouvez enregistrer les connexions TCP et UDP dans un VPC pour toutes les règles que vous créez vous-même. Cela peut vous être utile pour auditer l'accès au réseau ou pour identifier le plus tôt possible les cas d'utilisation non approuvée du réseau.

Utiliser VPC Service Controls

VPC Service Controls (bêta) vous permet de définir un périmètre de sécurité autour des ressources Google Cloud, telles que les buckets Cloud Storage, les instances Cloud Bigtable et les ensembles de données BigQuery afin de contraindre les données d'un VPC et de limiter les risques d'exfiltration de données (exigences 1.2.1 et 1.3.4). Grâce à VPC Service Controls, vous pouvez assurer la confidentialité de vos données sensibles tout en tirant parti des capacités de stockage et de traitement entièrement gérées de Google Cloud. Pour en savoir plus, demandez un accès anticipé.

Configurer les journaux de flux VPC

Environnement de données de titulaire de carte avec activation des journaux de flux VPC
CDE avec activation des journaux de flux VPC

Les journaux de flux VPC enregistrent les flux de trafic réseau envoyés ou reçus par les instances de VM. Dans le cadre de la norme PCI DSS, les journaux sont utiles pour la surveillance, l'audit, l'investigation et l'analyse de la sécurité en temps réel. Ils peuvent être activés ou désactivés indépendamment les uns des autres. De plus, vous pouvez réduire la quantité de données de journal en n'activant que les journaux de flux sur l'environnement de données de carte soumis aux exigences de conformité.

Les journaux de flux, associés aux règles de pare-feu de sortie, vous permettent de limiter le trafic sortant aux points de terminaison autorisés de manière contrôlable et difficile à contourner (exigences 1.2.1 et 1.3.4).

Si vous avez besoin de données plus détaillées que celles que peuvent fournir les journaux de flux, telles que les données de journalisation des requêtes HTTP individuelles, vous pouvez mettre en œuvre des contrôles dans votre application ou sur les requêtes sortantes du proxy. Pour ce faire, vous devez utiliser votre propre serveur proxy inversé configuré de manière à transférer les journaux d'accès à Logging. Pour obtenir des instructions sur la configuration d'un serveur proxy Squid sur Compute Engine, consultez la section Configurer un proxy réseau. Pour éviter les goulots d'étranglement, configurez au moins deux serveurs proxy redondants.

Journaliser les données d'accès interne

Outre la journalisation des menaces externes, vous pouvez surveiller et enregistrer l'activité des personnes disposant d'un accès administrateur à votre environnement de traitement des paiements (section 10.2). Pour ce faire, vous pouvez journaliser des commandes shell. Plusieurs outils Open Source peuvent auditer les commandes shell et les envoyer à la journalisation. Les options les plus populaires pour effectuer cette tâche sont OSSEC et Tripwire.

Configurer des alertes de surveillance

Configurez Stackdriver Monitoring pour envoyer des alertes en cas de problème dans votre environnement de traitement des paiements (section 10.6). Assurez-vous que ces alertes couvrent les événements relatifs à l'environnement, à l'audit et aux applications internes. Basez votre stratégie d'alerte sur les vecteurs de risque ou d'attaque potentiels pour chaque composant de votre application de traitement des paiements. Par exemple, déclenchez des alertes Monitoring si votre système IDS détecte des tentatives d'intrusion, qu'elles aboutissent ou non. Vous pouvez également utiliser la journalisation des règles de pare-feu pour déclencher des alertes en réponse à des tentatives de violation de règles de réseau spécifiques.

Transférer des journaux vers BigQuery

Transfert des journaux par Logging vers Cloud Storage et BigQuery
Transfert des journaux par Logging vers Cloud Storage et BigQuery

Vous pouvez éventuellement exporter les journaux Logging vers BigQuery pour les analyser ultérieurement. Étant donné que BigQuery est optimisé pour interroger de grands ensembles de données, c'est un outil idéal pour l'analyse de journaux à grande échelle. Pour les journaux nécessitant une analyse en temps quasi réel, Logging peut même se connecter directement à BigQuery (exigence 10.6.1).

Utiliser l'API Cloud Data Loss Prevention pour nettoyer les données

Il existe de nombreuses raisons d'utiliser une partie des données contenues dans l'application soumise aux exigences de conformité, mais n'étant pas elles-mêmes soumises à ces exigences, par exemple à des fins d'analyse ou de développement. Accordez aux applications l'accès aux données PCI uniquement après les avoir nettoyées à l'aide de l'API Cloud Data Loss Prevention (exigence 6.4.3).

Sécurité des applications

Pour sécuriser votre application, vous devez d'abord évaluer l'interface d'administration, mais vous pouvez également utiliser Cloud Key Management Service.

Évaluer l'interface d'administration

La plupart des applications d'e-commerce disposent de leur propre interface d'administration non basée sur une console, telle que le portail de facturation d'un service client. Un tel outil doit être capable d'effectuer des contrôles d'accès robustes. Pour cela, il doit permettre un accès individualisé basé sur l'authentification multifactorielle (section 8.3) et doit être instrumenté avec l'enregistrement d'audit (section 10.2).

Tous les journaux que vous créez doivent répondre aux questions suivantes : qui a fait quoi, où et quand. Selon la section 2.3, tout accès à un tel outil doit utiliser un cryptage de transport fort. Utilisez l'API Cloud Data Loss Prevention pour filtrer les informations sensibles avant de les afficher dans un outil d'administration.

Utiliser Cloud Key Management Service (Cloud KMS)

Cloud KMS est un service qui vous permet de gérer des clés de chiffrement. Avec ce service, vous pouvez générer, utiliser, alterner et détruire des clés de chiffrement AES-256, RSA 2048, RSA 3072, RSA 4096, EC P256 et EC P384. Cloud KMS vous permet de supprimer les mots de passe en texte brut stockés dans des fichiers de code ou de configuration, ce qui simplifie la conformité aux exigences 3.5, 3.6, 6.3.1 et 8.2.

Valider votre environnement

Une fois votre environnement mis en œuvre, vous devez faire valider l'environnement avant que tout flux de production n'y transite :

  • Si vous êtes un marchand de niveau 1, l'environnement doit être validé par un évaluateur de sécurité qualifié (QSA, Qualified Security Assessor). Un QSA est une entreprise ou une personne agréée par le PCI SSC pour valider les environnements PCI et apposer son sceau d'approbation.
  • Si vous êtes un marchand de niveau 2 ou inférieur, vous pouvez faire valider votre environnement en remplissant le questionnaire d'auto-évaluation.

Étapes suivantes