Limiter le champ d'application de la conformité pour les environnements PCI dans Google Cloud

Ce document décrit les bonnes pratiques concernant la conception d'un environnement cloud conforme aux normes édictées par le Conseil des normes de sécurité PCI (Payment Card Industry). Ces bonnes pratiques sont utiles pour les organisations qui migrent ou conçoivent dans le cloud des systèmes soumis aux exigences de conformité PCI. Ce document fait référence aux exigences relatives à la norme PCI DSS 4.0 le cas échéant.

Comprendre le champ d'application de l'évaluation PCI DSS

Si votre organisation exerce des activités commerciales via Internet, vous devez assurer et maintenir la conformité PCI. La manière dont vous concevez et gérez votre environnement cloud a une incidence sur le champ d'application auquel sont soumis vos systèmes pour l'évaluation PCI DSS (Data Security Standard). Le champ d'application a des conséquences importantes sur la sécurité de vos ressources informatiques, ainsi que sur votre capacité à assurer et à maintenir la conformité PCI. Pour vous assurer que votre environnement PCI est soumis à un champ d'application adéquat, vous devez comprendre comment vos processus métier et vos décisions de conception affectent le champ d'application.

Qu'est-ce que le champ d'application ?

Tous les systèmes qui stockent, traitent ou transmettent des données des titulaires de cartes (CHD) sont couverts par le champ d'application de votre évaluation PCI DSS. La sécurité est importante pour l'ensemble de votre environnement cloud, mais si un système soumis au champ d'application est compromis, cela peut entraîner une violation des données et l'exposition des données CHD.

Dans la figure 1, l'environnement des données des titulaires de cartes (CDE), les systèmes associés (connected-to) et les systèmes ayant un impact sur la sécurité (security-impacting) sont couverts par le périmètre du champ d'application de l'évaluation, tandis que les systèmes non approuvés et hors champ d'application (untrusted and out-of-scope) se trouvent en dehors du périmètre du champ d'application de l'évaluation.

Selon la norme PCI DSS, les systèmes couverts sont approuvés. Les systèmes couverts par le champ d'application incluent votre environnement CDE et tous les systèmes qui sont liés à la sécurité de votre CDE ou susceptibles de l'affecter.

Un système est associé (connected-to) s'il se trouve sur le même réseau, partage des bases de données ou un stockage de fichiers, ou dispose d'un accès ou d'une connectivité à tout système ou processus situé dans le CDE, mais n'a pas d'accès direct aux données CDH.

Un système a un impact sur la sécurité (security-impacting) si, lorsqu'il est compromis, il peut permettre à un pirate informatique d'accéder au CDE. Tous les systèmes associés et ayant un impact sur la sécurité sont systématiquement couverts par le champ d'application.

Les systèmes hors champ d'application sont non approuvés par définition dans la norme PCI DSS, et ne présentent aucune valeur ajoutée pour un pirate informatique souhaitant accéder aux données CDH ou aux données d'authentification sensibles (SAD). Un système n'entre pas dans le champ d'application s'il ne peut pas impacter la sécurité d'un système couvert, et ce, même s'il est compromis. Bien que les systèmes hors champ d'application ne soient pas évalués directement, l'évaluateur de sécurité qualifié PCI (QSA) vérifie que votre champ d'application est exact et protège les données CHD conformément à la norme PCI DSS. Il est donc important que le périmètre de votre champ d'application soit fortement protégé, surveillé de manière continue et exhaustive, et clairement documenté.

Connexions dans le contexte PCI

Plusieurs exigences relatives à la norme PCI DSS font référence aux connexions, mais la norme PCI DSS ne définit pas explicitement les connexions. Vous pouvez interpréter la signification du terme connexion dans ce contexte en analysant l'arbre de décision du champ d'application figurant dans le document PDF PCI SSC Guidance for PCI DSS scoping and network segmentation (Guide PCI SSC pour le champ d'application et la segmentation réseau pour la norme PCI DSS).

Dans le cadre de l'évaluation de votre champ d'application PCI, une connexion est définie comme suit :

• Un transport actif d'informations reliant deux ordinateurs ou systèmes
• Parmi les deux tiers impliqués, lequel a initié l'appel

Lorsque vous documentez votre environnement, il est préférable d'indiquer clairement qui est autorisé à établir une connexion. Un pare-feu configuré pour n'autoriser le trafic que dans une seule direction peut appliquer une connexion à sens unique. Par exemple, une application de traitement des paiements soumise au champ d'application peut adresser des requêtes à un serveur de base de données hors champ d'application, sans que ce serveur n'entre dans le périmètre du champ d'application si toutes les conditions suivantes sont remplies :

• La connexion et la base de données hors champ d'application ne stockent, ne traitent, ni ne transmettent de données CHD ou SAD.
• La base de données se trouve sur un réseau distinct ou est séparée du CDE.
• La base de données ne peut pas initier d'appels, directement ou indirectement, à destination du CDE.
• La base de données ne fournit pas de services de sécurité au CDE.
• La base de données n'a aucune incidence sur la configuration ni sur la sécurité du CDE.
• La base de données est conforme aux exigences de la norme PCI DSS.

Le diagramme suivant illustre les facteurs déterminant le champ d'application du système :

Dans la figure 2, le champ d'application du système est déterminé comme suit :

• Composants système couverts par la norme PCI DSS :

  • Systèmes faisant partie du CDE et pour lesquels l'une des conditions suivantes est vraie :
    • Un composant système stocke, traite ou transmet des données CHD ou SAD.
    • Un composant système se trouve sur le même segment réseau, par exemple sur le même sous-réseau ou VLAN, que des systèmes qui stockent, traitent ou transmettent des données CHD.
  • Systèmes associés ou ayant un impact sur la sécurité pour lesquels l'une des affirmations suivantes est vraie :
    • Un composant système se connecte directement au CDE.
    • Un composant système a une incidence sur la configuration ou la sécurité du CDE.
    • Un composant système segmente les systèmes du CDE vis-à-vis de systèmes et réseaux hors champ d'application.
    • Un composant système se connecte indirectement au CDE.
    • Un composant système fournit des services de sécurité au CDE.
    • Un composant système est compatible avec les exigences de la norme PCI DSS.

• Les composants système peuvent être considérés comme non approuvés et hors champ d'application de la norme PCI DSS lorsque toutes les conditions suivantes sont remplies :

  • Un composant système ne stocke, ne traite, ni ne transmet de données CHD ou SAD.
  • Un composant système n'appartient pas au même segment réseau, par exemple le même sous-réseau ou VLAN, que des systèmes qui stockent, traitent ou transmettent des données CHD ou SAD.
  • Un composant système ne peut se connecter à aucun système du CDE.
  • Un composant système ne répond à aucun des critères pour les systèmes associés ou ayant un impact sur la sécurité.

  Les systèmes hors champ d'application peuvent inclure des systèmes qui se connectent à un composant associé ou ayant un impact sur la sécurité, où des contrôles sont mis en place pour empêcher le système hors champ d'application d'accéder au CDE à l'aide du composant système couvert par le champ d'application.

En termes pratiques, la définition du champ d'application système de la norme PCI DSS peut signifier que le magasin de sessions et la base de données d'e-commerce de votre application Web peuvent être considérés comme étant hors du champ d'application si la segmentation est correctement mise en œuvre et documentée. Le diagramme suivant illustre le fonctionnement des connexions en lecture et en écriture entre les systèmes couverts et les systèmes hors champ d'application :

La figure 3 illustre les connexions suivantes :

• Lecture seule :
  • Une application de traitement des paiements couverte par le champ d'application lit un ID de panier à partir d'une base de données de paniers hors champ d'application, et lit des données à partir de serveurs DNS et NTP.
• Écriture seule :
  • Une application de traitement des paiements soumise au champ d'application écrit des données dans une base de données principale de l'application et dans Cloud Logging, tous deux hors champs d'application.
  • L'application Web principale, hors champ d'application, écrit des données dans un service de journalisation. Ces données n'incluent pas de données CHD ou SAD.
• Lecture et écriture :
  • Un utilisateur sur le Web public lit et écrit des métadonnées de requête comme suit :
    • L'utilisateur lit et écrit dans une application de traitement des paiements soumise au champ d'application. Ces métadonnées de requête sont constituées de l'ID du panier et de la clé d'authentification du panier, qui contiennent des données CHD et SAD.
    • L'utilisateur lit et écrit dans l'application Web principale, hors champ d'application. Ces métadonnées de requête sont constituées d'un ID de session, qui ne contient aucunes données CHD ou SAD.
  • L'application Web principale, hors champ d'application, lit et écrit des données dans une base de données de paniers, un magasin de sessions et une base de données principale de l'application, tous hors champs d'application. Ces données n'incluent pas de données CHD ou SAD.
  • Une application de traitement des paiements soumise au champ d'application lit et écrit des données dans un service de tokenisation de carte et un service de traitement de carte de crédit, situés sur le Web public et tous deux couverts par le champ d'application. Ces données incluent des données CHD et SAD.

L'architecture de la figure 3 décrit deux applications Web distinctes : l'application Web principale (main Web application), qui se trouve hors du champ d'application de la norme PCI, et l'application de traitement des paiements (payment processing application), qui est couverte. Dans cette architecture, une connexion ne peut être établie entre deux entités que dans les directions décrites dans la liste précédente. Du point de vue de l'appelant, les connexions entre entités peuvent être en lecture seule, en lecture/écriture ou en écriture seule. Toute direction de chemin ou de requête qui n'est pas explicitement décrite est bloquée par la segmentation. Par exemple, l'application de traitement des paiements peut lire des données dans la base de données de paniers et écrire des données dans le service de journalisation, ce qui implique d'établir une connexion avec ces entités.

Il est fréquent que les systèmes couverts par le champ d'application appellent des systèmes et services hors champ d'application. Ces connexions restent sécurisées, car la segmentation empêche tout appelant distant (autre qu'un titulaire de carte) d'établir directement ou indirectement une connexion dans le CDE. La figure 3 montre que le seul chemin d'entrée vers l'application de paiement émane de l'utilisateur.

Dans la figure 3, aucun service ou application hors champ d'application ne fournit d'informations de configuration ou de sécurité à l'application de traitement des paiements. Les données transitent par l'architecture de la manière suivante :

1. L'application principale redirige l'utilisateur vers l'application de paiement et utilise un code HTTP POST pour transmettre le paramètre CartID et un paramètre de validation appelé CartAuthKey. L'élément CartAuthKey est un hachage de la ressource CartID et d'un secret préalablement partagé connu uniquement des applications principale et de paiement.
2. L'application de paiement valide l'utilisateur en calculant le hachage du CartID avec le secret et en comparant cette valeur à CartAuthKey.
3. Une fois les données utilisateur authentifiées, l'élément CartID permet de lire le contenu du panier depuis la base de données de paniers. Toutes les données du titulaire de la carte sont envoyées directement par l'utilisateur à l'application de règlement.
4. Si des profils de paiement sont utilisés, les données du titulaire de la carte sont stockées dans le service de tokenisation.
5. Une fois le paiement traité, le résultat est inséré dans la base de données de l'application principale à l'aide d'un compte de service de base de données ayant accès en écriture seule.

Considérations concernant le champ d'application

Dans le Guide pour le champ d'application et la segmentation réseau pour la norme PCI DSS (Guidance for PCI DSS scoping and network segmentation), le conseil des normes de sécurité PCI recommande de partir du principe que tout élément est couvert par le champ d'application jusqu'à preuve du contraire. Cette recommandation SSC ne signifie pas que vous devez étendre le périmètre de votre champ d'application aussi largement que possible. Cela signifie plutôt que le QSA évalue tous les systèmes comme étant approuvés, à moins que vous ne puissiez démontrer qu'un système ne présente aucune connectivité à votre CDE ou aucun impact sur sa sécurité. Pour respecter les exigences de conformité réglementaire et assurer la sécurité de vos ressources informatiques, vous devez déterminer le champ d'application de votre environnement conformément au principe du moindre privilège en approuvant le nombre de systèmes le plus restreint possible.

Avant votre évaluation, examinez votre environnement pour comprendre et documenter le périmètre séparant vos systèmes couverts des systèmes hors champs d'application. La première tâche du QSA consiste à confirmer que le champ d'application documenté encapsule raisonnablement l'environnement CDE et les systèmes connectés. Dans le cadre de l'évaluation globale, le QSA vérifie ensuite que les systèmes hors champ d'application ne sont pas en mesure d'affecter négativement les systèmes couverts.

Assurez-vous de bien comprendre les circonstances particulières spécifiques à votre environnement, telles que les éléments suivants :

• Si vous collectez les données des titulaires de cartes par téléphone ou via un système de VOIP, tenez compte des problèmes de champ d'application supplémentaires décrits dans le document PDF Protecting telephone-based payment card data (Protéger les données de carte de paiement fournies par téléphone).
• Si votre fournisseur de services a besoin d'accéder à votre CDE (document PDF) pour exploiter un système de point de vente, le système utilisé par votre fournisseur de services peut être considéré comme un système associé. Cela peut nécessiter des considérations supplémentaires en matière de champ d'application et d'obligations de diligence.

Les bonnes pratiques de Google en matière de sécurité peuvent vous aider à établir et à démontrer une frontière claire et défendable entre les systèmes couverts et les systèmes non approuvés, ce qui facilitera votre évaluation. Lorsque vous gérez l'accès et la sécurité en utilisant le principe du moindre privilège, vous contribuez à minimiser le nombre de points d'exposition des données des titulaires de cartes, à réduire la surface d'attaque de votre CDE, et donc à réduire votre champ d'application. Lorsque vous réduisez l'étendue des systèmes couverts, vous contribuez à limiter la complexité du système et à optimiser votre évaluation PCI DSS.

Risques d'erreur de champ d'application

Un champ d'application trop étendu peut entraîner des évaluations coûteuses et accroître les risques de conformité. Pour restreindre le champ d'application, approuvez aussi peu de systèmes que possible et n'accordez l'accès qu'à quelques utilisateurs désignés. Grâce à une évaluation minutieuse et à une auto-évaluation, vous pouvez identifier les systèmes qui ne devraient pas être couverts par le champ d'application de la norme PCI DSS, vérifier qu'ils répondent aux consignes relatives aux systèmes hors champ d'application, puis réduire le champ d'application en conséquence. Ce processus d'élimination est le moyen le plus sûr d'identifier les systèmes non approuvés et de s'assurer qu'ils ne sont pas en mesure d'affecter les systèmes couverts.

Si vous avez besoin d'une infrastructure étendue pour répondre aux exigences de la norme PCI DSS, cela peut entraîner l'inclusion de systèmes superflus dans le champ d'application de l'évaluation. Si vous incluez des systèmes superflus dans votre champ d'application, vous risquez de compromettre votre capacité à être en conformité. Cela peut également nuire à votre stratégie de sécurité globale en élargissant la surface d'attaque de votre environnement approuvé et couvert par le champ d'application.

L'un des principes de base de la sécurité réseau et de la norme PCI DSS est de partir du principe que tout ou partie de votre réseau a déjà été compromis. Ce principe est consacré par le modèle de sécurité "zéro confiance" de Google, qui refuse la sécurité basée uniquement sur le périmètre au profit d'un modèle dans lequel chaque système est responsable de sa propre sécurité. Le modèle de sécurité de Google est conforme à la norme PCI DSS, qui recommande que le CDE et ses systèmes associés soient déployés dans un espace approuvé restreint, séparé et distinct de votre environnement informatique au sens large.

Dans votre environnement couvert par le champ d'application PCI, ne placez pas votre CDE dans un espace approuvé étendu au périmètre trop vaste. Cela peut créer un sentiment de sécurité trompeur et risque de compromettre une stratégie globale de défense en profondeur. Si un pirate informatique parvient à passer outre la sécurité du périmètre, il peut alors profiter facilement d'un intranet privé de confiance. Réfléchissez aux manières de renforcer l'espace approuvé de sorte qu'il ne contienne que ce qui est nécessaire à son bon fonctionnement et à sa sécurité, et évitez d'exploiter uniquement le modèle de sécurité périmétrique. En comprenant et en suivant ces principes, vous pouvez concevoir un environnement cloud contribuant à sécuriser vos systèmes critiques et à réduire le risque de propagation depuis des systèmes compromis.

Un environnement étendu de systèmes approuvés couverts par le champ d'application requiert un appareil de gestion d'envergure comparable pour garantir la surveillance, la maintenance, l'audit et l'inventaire continus de ces systèmes. La complexité de l'architecture du système, des processus de gestion du changement et des stratégies de contrôle des accès peut créer des risques pour la sécurité et la conformité. Des difficultés à assurer la gestion de ces processus de surveillance peuvent entraîner des difficultés à répondre aux exigences 10 et 11 de la norme PCI DSS. Il est important de comprendre ces risques et de mettre en œuvre des stratégies visant à limiter le champ d'application de l'environnement évalué. Pour plus d'informations, consultez la section Garantir la conformité continue plus loin dans ce document.

Services Google Cloud conformes à la norme PCI DSS

Avant de commencer à réduire le champ d'application de votre environnement PCI, identifiez les services Google Cloud conformes à la norme PCI DSS. Ces services offrent une infrastructure sur laquelle vous pouvez vous appuyer pour créer votre propre service ou application qui stocke, traite ou transmet les données des titulaires de cartes.

Stratégies visant à réduire le champ d'application

Cette section aborde les stratégies suivantes permettant de réduire le champ d'application de l'évaluation : les contrôles sur la hiérarchie des ressources, la segmentation VPC Service Controls et la tokenisation. Plutôt que de choisir une seule approche, envisagez d'appliquer toutes ces stratégies afin de maximiser la réduction potentielle de votre champ d'application.

Il n'existe pas de solution universelle pour limiter le champ d'application PCI. Vous avez peut-être déjà mis en place une segmentation dans un réseau sur site, ou une solution de traitement des cartes susceptible de rendre votre infrastructure légèrement différente de celle décrite ici. Utilisez ces stratégies comme des principes que vous pouvez appliquer à votre propre environnement.

Établir des contrôles sur la hiérarchie des ressources

Les ressources Google Cloud sont organisées de façon hiérarchique comme suit :

• La ressource Organisation est le nœud racine de la hiérarchie des ressources Google Cloud. Les ressources d'organisation contiennent des ressources de dossier et de projet. Les stratégies de contrôle des accès de la gestion de l'authentification et des accès (IAM) appliquées à la ressource Organisation s'appliquent à l'ensemble de la hiérarchie sur toutes les ressources de l'organisation.
• Les dossiers peuvent contenir des projets et d'autres dossiers, et contrôler l'accès à leurs ressources à l'aide d'autorisations IAM au niveau des dossiers. Les dossiers sont couramment utilisés pour regrouper des projets semblables.
• Les projets constituent une limite de confiance pour toutes vos ressources. Il s'agit d'un point d'application IAM.

Pour réduire le champ d'application de votre évaluation, suivez les bonnes pratiques recommandées par Google pour définir la hiérarchie de vos ressources. L'image suivante illustre un exemple de hiérarchie de ressources pour la conformité PCI :

Dans la figure 4, tous les projets couverts par la norme PCI sont regroupés dans un même dossier afin de les isoler au niveau du dossier. Le dossier couvert par la norme PCI contient le CDE et un autre projet contenant des services partagés. Lorsque vous mettez en œuvre une hiérarchie de ressources similaire, le dossier couvert par la norme PCI constitue la racine logique de votre champ d'application de la norme PCI. En vous assurant que seuls les utilisateurs désignés ont accès à ce dossier et à ses projets, vous pouvez exclure du champ d'application de votre évaluation les autres dossiers, projets et ressources de votre hiérarchie.

Lorsque vous restreignez l'accès des utilisateurs uniquement aux dossiers et aux projets dont ils ont besoin, vous garantissez que seuls les utilisateurs désignés ont accès aux composants couverts par votre champ d'application. Cela répond entre autres aux exigences PCI DSS 7.2 et 7.3 (document PDF). Pour vous assurer que les autorisations de l'organisation et des dossiers parents sont correctement définies, assurez-vous de bien comprendre les implications de l'héritage des stratégies. Pour répondre à l'exigence PCI DSS 8.4.1, assurez-vous d'appliquer l'authentification multifacteur (MFA) pour les utilisateurs désignés, et consultez le guide PCI DSS complémentaire pour l'authentification multifacteur (document PDF). Pour appliquer la conformité dans votre hiérarchie de ressources, assurez-vous de bien comprendre comment définir les contraintes liées aux règles d'administration. Ces contraintes contribuent à garantir la continuité de la conformité et peuvent protéger vos environnements approuvés contre l'élévation des privilèges.

Comme pour l'ensemble de la conformité PCI, une journalisation et une surveillance adéquates de votre environnement et ses composants couverts par le champ d'application sont nécessaires pour établir clairement le périmètre du champ d'application. La hiérarchie des ressources est étroitement liée à la gestion de l'authentification et des accès, et la journalisation, l'audit et la surveillance efficaces des actions des utilisateurs sont nécessaires pour appliquer et maintenir la séparation.

Mettre en œuvre la segmentation du réseau

La segmentation du réseau est un modèle d'architecture important qui vous aide à sécuriser votre environnement CDE et les systèmes associés, comme décrit dans le guide PCI SSC complémentaire sur la segmentation du réseau (document PDF). Une fois la mise en œuvre correctement effectuée, la segmentation du réseau réduit le champ d'application de votre évaluation en supprimant les routes réseau que les systèmes non approuvés sont susceptibles d'utiliser pour accéder à votre CDE ou aux composants associés. Définissez uniquement les routes nécessaires pour permettre la communication entre les composants approuvés. Lorsque les systèmes non approuvés n'ont pas de route à travers laquelle envoyer ou recevoir des paquets en provenance de systèmes approuvés, ces systèmes non approuvés ne sont pas couverts par le champ d'application et ne peuvent pas avoir d'incidence sur la sécurité de vos éléments couverts.

Pour mettre en œuvre la segmentation du réseau, placez votre CDE dans un cloud privé virtuel (VPC) dédié sur lequel VPC Service Controls est activé. Créez ce VPC en mode personnalisé pour vous assurer qu'aucun sous-réseau ou route superflu n'est créé qui pourrait autoriser l'accès par défaut aux réseaux approuvés. Mettez en œuvre des contraintes liées aux règles d'administration pour vous assurer que ce VPC ne peut pas être partagé avec d'autres projets et qu'il ne peut être appairé qu'avec d'autres réseaux approuvés.

Le diagramme suivant montre le lien étroit qui existe entre votre stratégie de segmentation réseau et votre hiérarchie de ressources. Ce diagramme suppose une hiérarchie de ressources comportant un seul dossier pour votre environnement PCI couvert par le champ d'application, ainsi que deux projets dans ce dossier pour l'environnement CDE et les services partagés.

Dans la figure 5, le projet de services partagés ne fait pas partie du CDE, mais s'il s'agit d'un système associé qui est donc couvert par le champ d'application de la norme PCI. L'accès au CDE est limité au niveau du réseau par l'équilibreur de charge et les règles de pare-feu ou stratégies de pare-feu afin de protéger ces réseaux et de répondre aux exigences PCI DSS 1.2 et 1.3. Le système de tokenisation et le système de paiement sont placés dans des sous-réseaux distincts, et leur communication est régie par des règles de pare-feu entre chaque sous-réseau qui autorisent uniquement les communications nécessaires. Les fonctions de journalisation, de surveillance et d'alerte nécessaires qui répondent aux exigences PCI DSS 10.2, 10.4 et 10.5 sont hébergées dans un projet distinct. Les services partagés et le CDE se trouvent à l'intérieur d'un périmètre de sécurité VPC Service Controls afin de les protéger contre toute erreur de configuration accidentelle ou tout piratage des contrôles d'accès IAM.

Si votre déploiement est effectué sur Google Kubernetes Engine (GKE), les méthodes suivantes constituent des solutions supplémentaires pour segmenter votre CDE et protéger les données des titulaires de cartes contre tout système non approuvé :

• Les espaces de noms offrent une couche d'isolation supplémentaire du contrôle des accès, grâce à laquelle les utilisateurs ne peuvent accéder qu'à certains pods, services et déploiements au sein de votre cluster Kubernetes. Cette fonctionnalité est utile pour fournir un accès plus précis aux utilisateurs désignés.
• Les règles de réseau peuvent isoler les pods et les services les uns des autres afin de restreindre les flux de données, et ainsi fournir une couche supplémentaire de segmentation du réseau au sein de votre cluster.
• PodSecurity est un contrôleur d'admission Kubernetes qui vous permet d'appliquer les normes de sécurité des pods aux pods exécutés sur votre cluster GKE.

Chacune de ces couches constitue une part importante de votre stratégie de sécurité en profondeur. Elles contribuent à restreindre votre champ d'application en isolant et en protégeant vos composants approuvés de l'environnement. Si vous déployez tout ou partie de votre CDE avec Kubernetes, découvrez plus en détail comment exécuter votre environnement conforme à la norme PCI sur GKE.

Mettre en œuvre la tokenisation

La tokenisation est le processus consistant à masquer de manière irréversible un numéro de compte principal (primary account number ou PAN). Un PAN tokenisé, ou jeton, ne permet pas de reconstituer le PAN d'origine par des moyens mathématiques. Le conseil PCI SSC fournit des conseils sur l'impact de la tokenisation en matière de champ d'application dans le chapitre 3 des consignes supplémentaires pour la tokenisation (document PDF). Le champ d'application de la norme PCI DSS est fortement influencé par l'ensemble des composants qui stockent et transmettent les données des titulaires de cartes. Lorsqu'elle est mise en œuvre correctement, la tokenisation peut contribuer à réduire le champ d'application de l'évaluation en minimisant l'occurrence et la transmission des numéros de comptes principaux.

La tokenisation constitue également une forme de segmentation par flux de données, car elle sépare les systèmes qui stockent et transmettent les données des titulaires de cartes de ceux qui ne peuvent effectuer des opérations qu'à l'aide de jetons. Par exemple, les systèmes qui analysent l'activité des consommateurs pour détecter des fraudes n'ont pas nécessairement besoin des PAN, mais peuvent effectuer leurs analyses à l'aide de données tokenisées. La tokenisation ajoute également une couche de séparation entre les systèmes qui stockent et transmettent des PAN, et votre application Web d'e-commerce. Lorsque votre application Web n'interagit qu'avec des systèmes utilisant des jetons, elle peut potentiellement être retirée de l'ensemble des systèmes associés, ce qui réduit le champ d'application.

Le diagramme suivant montre comment les CHD, un PAN et les données tokenisées sont gérés dans un système de tokenisation classique :

Dans la figure 6, un PAN et les données du titulaire de la carte sont reçus de l'utilisateur, puis les données sont immédiatement envoyées au service de tokenisation. Le service de tokenisation chiffre le PAN, génère un jeton, puis les stocke tous deux dans un système de stockage sécurisé de jetons. Seuls les services désignés, tels que le service de règlement, peuvent accéder à ce stockage sécurisé sur le réseau et sont autorisés à récupérer un PAN sur la base d'un jeton généré. Le service de règlement utilise le PAN uniquement pour l'envoyer au service de traitement des paiements. Ni le PAN, ni aucune autre donnée de titulaire de carte ne sortent de ce flux de données étroitement contrôlé. Dans le cadre d'une stratégie de défense en profondeur, l'architecture utilise également la protection des données sensibles comme couche de défense supplémentaire contre toute fuite involontaire de PAN ou autres données de titulaires de cartes.

Dans la figure 6, le système de tokenisation utilise Hashicorp Vault, un magasin de secrets étroitement surveillé pour gérer les mappages entre PAN et jetons. Seuls les utilisateurs et les services autorisés peuvent récupérer un PAN sur la base d'un jeton à l'aide d'un processus de recherche. Les composants autorisés à accéder système de stockage des jetons peuvent recevoir un accès limité dans le temps. Ainsi, le composant ne peut récupérer un PAN que lors de la fenêtre temporelle qui lui est nécessaire pour exécuter sa fonction. D'autres datastores peuvent également être appropriés suivant les besoins de votre entreprise.

Exemple d'architecture

Le diagramme suivant illustre un exemple d'architecture pour le traitement de transactions tokenisées à l'aide de Pub/Sub et de Dataflow, et en stockant les enregistrements de transactions tokenisés dans Spanner.

Dans la figure 7, le projet de traitement des transactions est un système associé, qui entre donc dans le champ d'application de la norme PCI. Il n'a pas d'impact sur la sécurité, car le piratage de n'importe quel composant du projet de traitement des transactions ne permet pas à un pirate informatique d'obtenir l'accès aux CHD. Le projet webapp est hors champ d'application, car il ne se connecte pas au CDE et n'interagit qu'avec des données nettoyées.

Les données tokenisées sont envoyées depuis le CDE vers Pub/Sub. Avant que les données tokenisées ne soient publiées pour d'autres abonnés, la protection des données sensibles vérifie qu'elles ne contiennent aucune donnée CHD. Les données tokenisées sont traitées par Dataflow et stockées dans la base de données de transactions Spanner. Les transactions peuvent être associées à des utilisateurs spécifiques à l'aide des jetons sans nécessiter l'accès aux PAN. La base de données de transactions Spanner peut également être utilisée pour générer des rapports et analyser des données à l'aide d'outils d'informatique décisionnelle (BI) tels que Looker.

Garantir la conformité continue

La sécurité et la conformité vont au-delà d'une architecture correcte et d'une bonne ingénierie. Une architecture correcte peut démontrer que votre environnement est conçu de manière sécurisée en théorie. Vous avez également besoin de processus efficaces d'audit, de journalisation, de surveillance et de résolution des problèmes afin de garantir la sécurité de votre environnement en pratique.

Afin de garantir la conformité avec chacune des 12 catégories d'exigences PCI DSS, vous devez surveiller votre mise en œuvre de ces exigences de manière continue. Vous devez prouver à vous-même et à votre évaluateur qu'un composant couvert par le champ d'application restera sécurisé à l'avenir, bien après la fin de l'évaluation PCI DSS. Une surveillance appropriée associée à des actions de correction rapides est appelée conformité continue. La conformité continue est une exigence de la norme PCI DSS. Lorsqu'elle est mise en œuvre correctement, elle peut contribuer à amplifier l'effet des autres stratégies de réduction du champ d'application.

Google Cloud vous permet de consigner tout ce qui se passe dans votre réseau à l'aide des journaux de règles de pare-feu, des journaux de flux VPC, des journaux VPC Service Controls et des journaux Cloud Load Balancing. Vous pouvez surveiller l'activité de vos systèmes et de vos utilisateurs à l'aide des journaux d'audit Cloud. Surveiller régulièrement ces journaux vous aide à vous conformer à l'exigence PCI DSS 10.4, ainsi qu'à réagir rapidement en cas de menaces de sécurité potentielles et à les corriger. Pour plus d'informations, consultez le guide complémentaire PCI DSS sur la surveillance quotidienne efficace des journaux (document PDF).

Security Command Center vous permet de comprendre votre surface d'attaque de sécurité et des données en vous offrant des fonctions d'inventaire, d'identification, de recherche et de gestion des éléments. Security Command Center permet d'examiner les résultats des analyses Protection des données sensibles afin d'identifier les données de titulaires de cartes ayant pu faire l'objet de fuites et de s'assurer que votre système de tokenisation n'est pas utilisé de manière abusive et malveillante pour obtenir les PAN. Utiliser Event Threat Detection et Security Command Center peut vous aider à détecter de manière proactive les menaces ou une activité inhabituelle sur votre réseau et dans vos VM, susceptibles d'indiquer qu'un pirate informatique teste votre système afin d'identifier ses capacités défensives. Security Command Center vous permet également de créer des sources de sécurité personnalisées spécifiques à votre environnement.

Google Cloud Armor peut offrir une protection supplémentaire pour vos applications Web Google Cloud destinées au public et vous aider à vous conformer à l'exigence PCI DSS 6.4. Google Cloud Armor évalue les requêtes entrantes par rapport à diverses attaques Web courantes. Il peut vous aider à éviter les revues de code manuelles fastidieuses requises par l'exigence 6.4. La mise en place d'une configuration WAF vous permet de maintenir la conformité continue, tout en réduisant vos coûts et risques de conformité.

Étapes suivantes

• Consultez les bonnes pratiques de gestion des obligations de conformité.
• Consultez la page Conformité avec la norme de sécurité des données PCI sur Google Cloud.
• Document PDF PCI Council guidance for PCI DSS scoping and network segmentation (Guide du conseil PCI pour le champ d'application et la segmentation réseau pour la norme PCI DSS).
• Essayez le plan PCI sur GKE.
• Sécurisez vos charges de travail Kubernetes conformément à la norme PCI DSS.
• Déployez le projet Terraform PCI Starter.
• Découvrez des architectures de référence, des schémas et des bonnes pratiques concernant Google Cloud. Consultez notre Cloud Architecture Center.