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.
Ce document fait référence aux exigences relatives à la norme PCI DSS 4.0 le cas échéant.
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, JCB ou UnionPay 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 pouvant être envisagées si une entité ne peut pas répondre explicitement à une exigence, en raison de contraintes techniques ou commerciales légitimes et documentées. Les entités doivent atténuer suffisamment le risque associé à l'exigence lorsqu'elles implémentent ces autres contrôles. Pour obtenir des conseils sur l'utilisation des contrôles compensatoires, consultez les annexes B et C intitulées "Compensating Controls" (Contrôles compensatoires) dans le document PCI DSS Requirements and Security Assessment Procedures (Exigences PCI DSS et procédures d'évaluation de la sécurité).
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. Les Exigences de qualification pour les évaluateurs de sécurité qualifiés (QSA) fournissent des détails 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é. Cela ne s'applique qu'aux entités éligibles à l'auto-évaluation.
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 4.0 de niveau 1, il peut répondre à vos besoins de conformité PCI DSS quel que soit le niveau marchand de votre entreprise. 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 si vous êtes éligible à l'auto-évaluation. 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. |
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. Vous pouvez télécharger les rapports de conformité PCI DSS dans le gestionnaire des rapports de conformité. 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
Cette section contient des conseils sur les services Google Cloud couramment utilisés dans les architectures utilisées pour les environnements PCI DSS.
App Engine
Utilisez les règles de pare-feu d'entrée et les contrôles du trafic de sortie d'App Engine.
Cloud Run
Utilisez les paramètres d'entrée, VPC Service Controls et les contrôles de sortie des connecteurs VPC de Cloud Run. Si nécessaire, configurez une adresse IP sortante statique.
Fonctions Cloud Run
Utilisez les paramètres de réseau d'entrée et de sortie des fonctions Cloud Run.
Cloud Logging
Journalisez les interactions avec Cloud Logging.
Cloud Monitoring
Surveillez les interactions à l'aide de Cloud Monitoring.
Google Kubernetes Engine
Pour en savoir plus sur l'utilisation de Google Kubernetes Engine pour les environnements PCI DSS, consultez la section Conformité avec la norme PCI DSS sur GKE.
Cloud Storage
L'exigence 3.5 stipule qu'un numéro de compte principal (PAN) est sécurisé partout où il est 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 :
Le client effectue ses sélections et procède au paiement.
L'application de paiement redirige le client vers une société de traitement des paiements tierce.
Le client saisit les informations de sa carte de paiement dans un formulaire détenu et géré par la société tierce.
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.
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.
L'application du marchand envoie une demande de vérification à la société de traitement des paiements pour confirmer la transaction.
La société répond pour vérifier les détails de la transaction.
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 :
Le client saisit les informations de sa carte de paiement dans un formulaire détenu et géré par votre société.
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.
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.
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.
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 :
Le client saisit les informations de sa carte de paiement dans un formulaire détenu et géré par votre société.
Lorsque le client envoie ses informations, votre application de paiement reçoit les informations du formulaire.
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.
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.
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.
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.
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.
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.
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.
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.
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 :
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.5.3). 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.2 et exigence 8.2.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 comptes principaux ayant légitimement besoin d'un accès racine complet à vos services. Pour en savoir plus, consultez le guide de sécurité IAM.
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.3.6 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 :
- Stratégies de pare-feu Cloud nouvelle génération ou règles de pare-feu Compute Engine
- Un tunnel Cloud VPN
- Un équilibreur de charge d'application externe
Pour créer votre VPC, nous recommandons également 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
Utilisez des policies de pare-feu Cloud nouvelle génération ou des règles de pare-feu VPC pour limiter le trafic entrant dans chacune de vos instances Compute Engine (exigences 1.3 et 1.4). 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. Pour tester votre travail, consultez la section "Journalisation des règles de pare-feu" plus loin dans ce document.
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é
Vous pouvez utiliser Cloud VPN pour établir un tunnel VPN sécurisé entre votre environnement sur site et votre environnement de traitement des paiements (sections 2.2.7 et 4.2).
Créer un équilibreur de charge d'application externe
Pour vous assurer que le trafic client entrant est sécurisé, créez un équilibreur de charge d'application externe (sections 2.2.7 et 4.2). Pour créer un équilibreur de charge d'application externe, 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 :
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.4), 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 Google Cloud CLI, des environnements d'exécution et des bibliothèques spécifiques à un langage, ou un serveur Web.
Créez une instance Compute Engine qui utilise l'une des images de système d'exploitation préconfigurées Compute Engine.
Installez les bibliothèques et les logiciels que vous avez répertoriés précédemment.
Installez et configurez
ntpde 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.6).Assurez-vous que l'image respecte les bonnes pratiques de création d'une image Compute Engine sécurisée (section 2.2).
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 paquets
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 Terraform. Terraform 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 dans le code.
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.
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.3). 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.
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 et l'investigation des réseaux, ainsi que pour l'analyse de la sécurité en temps réel (section 10.2).
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é suspecte, 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.5, 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.
Cloud Intrusion Detection System (Cloud IDS) est un service de détection des intrusions qui permet d'identifier les menaces que représentent les intrusions, les logiciels malveillants, les logiciels espions, ainsi que les attaques de commande et de contrôle sur votre réseau. Cloud IDS offre une visibilité complète sur le trafic réseau, y compris le trafic nord-sud et est-ouest, ce qui vous permet de surveiller la communication entre les VM afin de détecter les mouvements latéraux. Vous pouvez également utiliser Cloud IDS pour simplifier la conformité avec l'exigence 11.5.
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
Security Command Center 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.4.
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 précédemment 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 (section 11.3) et garantir la révision du code (exigence 6.2.3).
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 à 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 Approval, 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 Approval 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.
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. Access Approval fournit également des informations sur les accès de l'assistance et des ingénieurs Google.
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 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 Bigtable et les ensembles de données BigQuery afin de contraindre les données d'un réseau VPC et de limiter les risques d'exfiltration de données (exigences 1.3.1 et 1.3.2). 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.
Configurer les 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).
Le diagramme suivant montre comment les journaux de flux VPC enregistrent les flux de trafic réseau envoyés ou reçus par les instances de VM."
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
Vous pouvez éventuellement router les journaux Logging vers BigQuery pour les analyser ultérieurement. Pour en savoir plus, consultez la section Présentation du routage et du stockage: récepteurs. É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.4.1).
Utiliser la protection des données sensibles 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 la Protection des données sensibles (exigence 6.5.1).
Sécurité des applications
Pour sécuriser votre application, vous devez d'abord évaluer l'interface d'administrateur, mais vous pouvez également utiliser Cloud Key Management Service.
Évaluer l'interface administrateur
La plupart des applications d'e-commerce disposent de leur propre interface d'administrateur 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.4) 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.2.7, tout accès à un tel outil doit utiliser un cryptage de transport fort. Utilisez la protection des données sensibles 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 sections 2.2.2, 3.6, 3.7 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
- Explorez la bibliothèque de documents sur la norme PCI DSS.
- Découvrez des architectures de référence, des schémas et des bonnes pratiques concernant Google Cloud. Consultez notre Cloud Architecture Center.