PCI DSS, Cloud et Virtualisation

Publiée en 2011 par le PCI SSC, la guidance Virtualisation avait pour objectif d’aider les entreprises à mieux comprendre les implications de l’utilisation de la virtualisation au sein de l’environnement PCI dans leurs processus de certification PCI DSS. Ainsi, les sujets abordés dans cette guidance traitent de la définition du périmètre en y incluant les composants virtuels et des nouveaux défis posés par l’utilisation de cette technologie pour être conforme aux exigences du standard PCI DSS.

Avec l’essor du Cloud, la virtualisation attire depuis quelques années de plus en plus d’entreprises, car cette technologie permet de réduire les coûts associés au maintien d’une infrastructure opérationnelle tout en rendant la gestion des réseaux sous-jacents plus efficace et agile. En 2018, la guidance Cloud du PCI SSC vient compléter celle sur la Virtualisation de 2011 pour y apporter de nouvelles précisions.

Ces guidances (guides d’utilisation) permettent aux entreprises de se poser les bonnes questions sur l’utilisation de la virtualisation dans le Cloud. En effet, bien que les avantages de cette technologie sont nombreux, les problèmes engendrés en termes de conformité PCI DSS sont à étudier de manière précise pour ne pas se faire piéger.

1. Répartition des responsabilités entre fournisseur Cloud et client

Il est aujourd’hui reconnu que les services Cloud se répartissent en 3 grandes catégories :

• Software as a Service (SaaS)
• Platform as a Service (PaaS)
• Infrastructure as a Service (IaaS)

Chacune de ces catégories implique le fournisseur du service Cloud et le client de manière différente en termes de sécurité et donc de conformité PCI DSS. Le thème le plus souvent abordé dans la guidance Cloud est celui de la “répartition des responsabilités” entre les différentes parties. Ainsi, les exigences portées par le client et celles portées par le fournisseur doivent permettre de couvrir l’ensemble des exigences du standard PCI DSS. 

Alors que la responsabilité du client dans un modèle SaaS est limité aux données importées par le client dans l’application, le fournisseur Cloud doit donc assurer la sécurité de la plateforme qui héberge l’application, de l’infrastructure associée ainsi que la sécurité physique de cette dernière. Dans un modèle IaaS, l’intégralité des responsabilités mentionnées précédemment revient au client à l’exception de la sécurité physique de l’infrastructure. Ce sujet de “répartition des responsabilités” est celui qui pose le plus de problème lorsqu’un incident de sécurité survient, car le plus souvent, ces responsabilités ne sont pas définies de manière précise dans les contrats liant fournisseurs et clients. 

Chaque partie est persuadée que c’est l’autre qui est responsable d’une certaine tâche et finalement rien n’est fait. Par exemple, le client peut penser qu’ayant souscrit à une offre IaaS, le fournisseur Cloud est responsable de l’entière gestion de l’environnement Cloud. Cependant, de son côté, le fournisseur Cloud ne gère véritablement que l’infrastructure sous-jacente en croyant que c’est le client qui va lui-même s’occuper de la correction des vulnérabilités affectant les systèmes d’exploitation et les applications. Ainsi, dans cet exemple, la conformité au chapitre 6 du standard PCI DSS demandant l’application de correctif de manière régulière, nécessite d’investir du temps et beaucoup d’énergie pour éclaircir ces sujets entre le fournisseur et le client.

Pour chacune des exigences du standard PCI DSS, le client et le fournisseur Cloud doivent définir leurs responsabilités respectives en termes de conformité et de contrôle. Dans tous les cas, le client devra se montrer particulièrement attentif à ce que son fournisseur reste conforme. Un exemple de tableau à remplir est donné dans la guidance Cloud. Il s’agit d’une manière d’être certain que les responsabilités pour chacune des exigences ont été réparties :

2. Utilisation de la virtualisation sur le périmètre PCI : conséquences et recommandations

L’utilisation de la virtualisation augmente la surface d’attaque. En effet, l’hyperviseur est le seul point d’entrée vers l’environnement virtuel. Ainsi, la compromission de ce dernier impacterait toutes les systèmes virtuels associés à cet hyperviseur. Aussi, une mauvaise configuration pourrait être répliquée sur l’ensemble des systèmes virtuels.

Lorsque la virtualisation est utilisée au sein d’un périmètre PCI, il est nécessaire de conserver à l’esprit les points suivants :

• L’existence d’un composant virtuel dans le périmètre PCI impose que l’hyperviseur associé soit également dans le périmètre.
• Un VSA (Virtual Security Appliance), défini comme un OS durci avec une seule fonctionnalité de sécurité, fournissant un service à un composant du périmètre PCI, est de fait inclus dans le périmètre PCI.
• Les VM ne proposent pas encore de systèmes de surveillance (monitoring) aussi matures que leurs équivalents physiques.

Les hyperviseurs sont des composants très sensibles dont le durcissement est essentiel. Ce durcissement est similaire à celui qui est appliqué aux équivalents physiques des hyperviseurs concernant :

• La gestion des accès (authentification multi-facteurs pour les actions d’administration) ;
• La gestion des changements (les changements de configuration doivent être testés avant leur déploiement) ;
• Le principe de moindre privilèges (séparation des fonctions d’administration pour que les administrateurs ne puissent pas accéder aux logs) ;
• La centralisation des logs (envoi de logs en temps réel à un système physique de manière sécurisée) ;
• La désactivation des services, ports et interfaces non utilisés ; 

Il convient d’être particulièrement vigilant sur les spécificités de ces systèmes virtuels. En effet, il s’agit entre autres :

• D’établir des limites en termes d’utilisation de ressources ; 
• De prendre en compte le fait que les chemins de migration des VM pourraient inclure de nouveaux éléments dans le périmètre ; 
• D’effacer de manière sécurisée les sauvegardes des VM ou de leurs données lorsqu’elles ne sont plus nécessaires.

3. Minimiser le périmètre PCI DSS tout en utilisant des solutions de virtualisation

Nous avons donc vu que la conformité PCI DSS est bien plus complexe à atteindre dans le cas où un fournisseur Cloud entrerait dans le périmètre de certification. La guidance Cloud prend donc le soin de donner quelques recommandations pour minimiser le périmètre d’audit PCI DSS dans un contexte Cloud : 

• Ne pas stocker, traiter ou transmettre de données de carte dans le Cloud (chapitre 3) ;
• L’utilisation de technologies qui dévaluent les données de carte comme la tokenisation permettent de diminuer la taille du périmètre ; 
• Dans le cas où la virtualisation est utilisée, il est recommandé d’implémenter une infrastructure physique dédiée aux composants de l’environnement Cloud. Ainsi, il est nécessaire de distinguer :
  • L’hyperviseur/serveur dédié pour les machines virtuelles et les containers dans le CDE (Cardholder Data Environment) ; 
  • Les hyperviseurs/serveurs qui hébergent les machines virtuelles qui ne sont pas dans le CDE.
• Minimiser le recours à des fournisseurs de service pour assurer la sécurité des données de carte. Plus le fournisseur a de contrôles de conformité à effectuer, plus le périmètre PCI est large. 

Alors que l’utilisation de services Cloud et de composants virtuels au sein des environnements de certification était jusqu’à maintenant déconseillée par la guidance Cloud de 2018, il semble que de nouvelles perspectives s’ouvrent. En effet, la newsletter de janvier 2020 du PCI SSC a annoncé la constitution d’un groupe de travail pour réfléchir aux meilleures pratiques de déploiement de services cryptographiques dans le Cloud. Peut-être que dans le PCI SSC donnera prochainement de nouvelles possibilités pour répondre aux exigences de PCI DSS via l’utilisation de services cryptographiques dans le Cloud.