La norme de sécurité de l’industrie des cartes de paiement (Payment Card Industry Data Security Standard ou PCI DSS) est un standard de sécurité des données qui s'applique aux différents acteurs de la chaîne monétique.
La norme PCI DSS est établie par les cinq principaux réseaux cartes (Visa, MasterCard, American Express, Discover Card et JCB) et est gérée par le Conseil des normes de sécurité PCI (forum international ouvert pour l'amélioration, la diffusion et la mise en œuvre de normes de sécurité pour la protection des données de comptes). Ce standard a été créé afin d’augmenter le contrôle des informations du titulaire de la carte dans le but de réduire l'utilisation frauduleuse des instruments de paiement.
https://fr.wikipedia.org/wiki/Norme_de_s%C3%A9curit%C3%A9_de_l%27industrie_des_cartes_de_paiement
PCI DSS est l'une des certifications les plus reconnues du cloud computing. Cette certification atteste que votre plateforme suit les meilleures pratiques afin de gérer les données de cartes de crédit. Il s’agit d’imposer des exigences à appliquer, mais pas les outils à utiliser, ce qui est le choix du client.
Cet article explique notre expérience pour concevoir une plate-forme compatible PCI DSS sur AWS. Nous mettrons en évidence les principaux points à considérer pour la conception d'environnements AWS, les services que nous avons utilisés et comment renforcer cette conception par des outils externes pour répondre aux exigences de cette certification.
Nous présupposons que vous avez une bonne connaissance des services AWS afin d'avoir une bonne compréhension de cet article et de savoir les utiliser. Nous vous invitons également à consulter leur description sur le site web officiel d'AWS.
Cet article découle directement d’un retour d’expérience de consultants chez leur client, il est donc à contextualiser, les réponses apportées ne sont que des suggestions. Dans le cadre de PCI DSS, il est important d’avoir une lecture fine des responsabilités partagées. PCI DSS a des exigences, pour y répondre, il est nécessaire de comprendre en détail ce qui est de la responsabilité du cloud provider (ici AWS) et de la vôtre. Aucune réponse n'est absolue, cela dépend entièrement de la mise en œuvre et du contexte.
Il est très important d'avoir une stratégie AWS Organizations robuste dès le début. AWS recommande d'utiliser une architecture multi comptes afin, notamment, de garantir :
On pourrait se demander ce que cela a à voir avec PCI DSS. Si le multi comptes n'est pas une exigence en soi, l'isolation des environnements (dev, staging, prod) l'est. Certes, cette isolation peut être mise en place au niveau réseau, mais nous recommandons une architecture multi comptes. C’est le plus fort niveau d’isolation disponible et permet plus de flexibilité et de rapidité pour les évolutions futures. Cela permet principalement de restreindre le périmètre PCI DSS à la production uniquement.
AWS propose ControlTower qui vous permet de gérer la création et la conformité de tous vos comptes AWS.
Pensez à analyser l’utilisation de vos services par vos différents environnements. Il peut rapidement émerger le besoin d’un compte qui héberge des services utiles à tous. AWS SES (Amazon Simple Email Service) par exemple, est utilisé pour l’envoi d’emails via des domaines validés. L'étape de validation nécessite une configuration dans AWS SES et dans la zone DNS hébergée. Le fait d'avoir ce service au même endroit vous permet de n'avoir qu'une seule validation à effectuer. Ce service peut être partagé via AWS IAM avec le reste des comptes AWS. De plus, si vous utilisez un outil tiers à licence payante, la mutualisation peut vous apporter un gain financier.
Voici une liste non exhaustive des services que l’on peut songer à mutualiser dans un compte transverse :
PCI DSS nécessite la collecte de tous les journaux d’accès à l'API et au système sur l’ensemble des comptes AWS. Avoir ces journaux dans un point de collecte centralisé vous aide à effectuer une meilleure gestion. AWS fournit CloudTrail qui vous permet d'envoyer toutes les actions d'API à un point de collecte de données. Ces fichiers journaux peuvent être signés à l'aide de la fonctionnalité AWS CloudTrail Log File Integrity pour éviter toute altération.
La centralisation des logs et métriques peuvent se faire dans le même compte transverse, ou dans un autre compte de surveillance. Nous vous recommandons fortement de ne pas utiliser le même compte que pour vos environnements applicatifs (dev, staging, prod).
Il est fortement recommandé d'avoir plusieurs niveaux d'accès pour les utilisateurs sur l'environnement AWS. Cela permet de garantir la stratégie du moindre privilège (plus connu dans sa version anglaise : least privilege) aux utilisateurs. Vous pouvez utiliser différents profils en fonction du rôle de l’utilisateur. Cela peut être garanti en utilisant les rôles et stratégies AWS IAM.
Cependant, PCI DSS exige que ces niveaux d'accès soient documentés et expliqués, avec la liste des utilisateurs et leurs profils.
PCI DSS exige une authentification forte pour les accès d’administrations ou à des données sensibles (e.g : carte bancaire). Pour y répondre, on peut mettre en place une solution d’authentification à 2 ou plusieurs facteurs (2FA/MFA). En outre, il existe également des exigences en matière de mot de passe, qui doit :
De plus, l'utilisateur doit être verrouillé après 5 tentatives d'authentification échouées (maximum).
AWS IAM, AWS Service Directory et AWS Single Sign-On (nouveau nom du service : AWS IAM Identity Center) peuvent garantir ces exigences. Ceci peut être assuré à l'aide d'un compte AWS d'authentification pour gérer uniquement ce processus et centraliser tous les accès à la plateforme.
Cependant, l’utilisation de ces services ne vous exonère pas de consigner dans un document ou logiciel, les revues des habilitations ainsi que les changements de mots de passe. Tout cela afin d’apporter la preuve à l’auditeur que vous respectez bien les exigences de gestion de l'authentification.
De nombreux langages d'automatisation (Infrastructure as Code et Configuration Management) peuvent être utilisés pour coder le déploiement de l'infrastructure, dont : AWS CloudFormation, AWS CDK, Terraform, cdktf, Pulumi ou Ansible. L'utilisation de ces outils n'est pas une exigence PCI DSS mais elle est fortement recommandée. En plus des avantages régulièrement cités, l’automatisation vous permet de réagir rapidement et efficacement pour appliquer des corrections sur vos environnements, pendant la période d'audit. L’IaC peut aussi servir de preuve pour témoigner à l'auditeur de la conformité de vos environnements et faciliter la remédiation.
Vous devez réfléchir à la manière dont vous mettez en place votre IaC. Par exemple, les secrets ne doivent pas être codés en dur ni en clair. Cependant, vous pouvez utiliser AWS Secret Manager ou Parameter Store pour stocker ces secrets.
Les pratiques GitOps sont fortement recommandées et également appréciées par les auditeurs. Cela montre la capacité de l'équipe d'exploitation à gérer l’IaC, en utilisant les pratiques et les outils des développeurs, à savoir Git. L'utilisation de branches Git et les Merge requests (MR) permettent de gérer plus efficacement l'IaC. Les MR doivent être validées par un autre membre de l'équipe afin d'approuver la partie du code avant de l'appliquer sur l'environnement et cela améliore grandement la traçabilité des évolutions de l’infrastructure.
Et pour renforcer la sécurité, l'accès à la console peut être uniquement accessible en lecture seule.
PCI DSS ne nécessite pas de modèle d'infrastructure spécifique à mettre en œuvre, mais il impose la présence de certains composants et l’application de bonnes pratiques.
Concernant les services, on peut citer :
En guise de lecture, nous vous recommandons les publications suivantes :
Il existe différents types de référentiels de durcissement qui peuvent être implémentés : CIS, ISO, SANS, NIST, etc. PCI DSS exige d’en choisir une et de l'appliquer.
Le durcissement d'un système d'exploitation prend du temps. L’utilisation d’AMI renforcée CIS tirée de l’AWS Marketplace peuvent vous faire gagner du temps.
L'auditeur vous demandera de fournir le rapport d'évaluation de la sécurité pour contrôler la conformité. Parfois, nous ne pouvons pas corriger tous les résultats en raison de certains problèmes techniques. Par exemple, dans le cas d'un orchestrateur de conteneurs utilisant Docker, vous devez garder les règles iptables ouvertes pour que l'orchestrateur puisse fonctionner correctement. Ces explications doivent également être fournies à l'auditeur.
Une image de conteneur contient une grande partie de ce qui définit généralement un système, les règles de durcissement s’y appliquent de la même façon. Idéalement, les images de conteneur doivent être signées pour garantir leur intégrité. AWS Inspector propose d’analyser les images de conteneurs stockées dans AWS ECR.
Le chiffrement des données est obligatoire. Les données chiffrées et les clés de chiffrement ne doivent pas résider au même endroit. Assurez-vous que vous pouvez faire la rotation des secrets et les mettre à jour au moins une fois par an, c'est une exigence PCI DSS. Sur AWS, KMS et CloudHSM vous offrent un moyen de stocker et utiliser des clés de chiffrement au travers d’API. Vous pouvez aussi assurer leur rotation automatique à l’aide d’une fonction Lambda.
Au-delà de ce que PCI DSS exige, il est préférable de contrôler les flux empruntés par des données sensibles et que ces dernières soient authentifiées. Un DLP permet
de scanner les données sortantes de la plateforme pour empêcher toute perte de données sensibles, notamment les numéros de carte de crédit. Sur AWS sont proposés différents services qui intègrent le chiffrement afin de renforcer la protection de données, comme S3, EBS, KMS, RDS, Secrets Manager, etc. En revanche, elles s'appuient sur des outils tiers pour accomplir la fonctionnalité de scan de trafic sortant, comme McAfee, Endpoint Protector ou Clamav avec C-icap.
PCI DSS demande à ce que les échanges réseaux soient maîtrisés. Il faut entièrement les inventorier et identifier ceux par lesquels transitent des flux authentifiés ou contiennent des données sensibles.
SSL/TLS doit être utilisé pour chiffrer les données en transit, à l'intérieur et à l'extérieur de votre SI. Le service AWS ACM peut être utilisé pour fournir des certificats à la demande. Ils peuvent être utilisés au niveau des répartiteurs de charge AWS pour chiffrer les données entrantes. De plus, les communications internes doivent également être chiffrées. Si vous utilisez un orchestrateur de conteneurs comme Kubernetes ou Nomad, le mTLS (Mutual Transport Layer Security) peut être exploité en fonction de ce qui transite entre vos nœuds.
PCI DSS exige que les flux entrants et sortants soient limités et filtrés. AWS fournit les groupes de sécurité et les NACLs (Network ACL) pour restreindre le trafic réseau en utilisant différents critères tels que : protocole réseau, port, adresses IP source / destination. AWS WAF fournit une sécurité supplémentaire niveau 7 sur le trafic entrant, en protégeant vos applications Web ou API contre les attaques Web courantes. En revanche, pour le trafic sortant, AWS ne fournit pas encore un service assurant la fonctionnalité de proxy. Le recours à des outils tiers est requis, avec Squid par exemple. L'auditeur vous demandera de fournir le schéma réseau détaillé, ainsi que les explications des ports et protocoles ouverts dans l'infrastructure. Il effectuera également des vérifications dans l'environnement AWS pour valider la documentation que vous avez fournie.
Bon à savoir : AWS fournit par défaut AWS Shield avec le niveau de protection standard. C’est suffisant pour la plupart des cas.
Enfin, AWS fournit aussi la possibilité de découpé ses sous-réseaux au sein d’un VPC, en sous-réseaux privé et public. Ainsi, il est préférable d’avoir un ALB public dans un sous-réseau public et les applications dans des sous-réseaux privés afin de ne pas exposer directement les applications sur Internet.
PCI DSS nécessite l'utilisation d'un scanner de vulnérabilités pour prouver que votre plateforme ne présente pas de risques importants. Il y a 2 périmètres à identifier, l’interne et l’externe. Ce qui est exposé publiquement doit obligatoirement être audité par un ASV (Approved Scanning Vendors) PCI DSS. Pour le périmètre interne, c’est plus flexible, cela dépend de votre mise en œuvre.
AWS fournit de nombreux services pour renforcer la sécurité des environnements AWS tels que IAM, VPC, Config, GuardDuty, WAF et Inspector. L’utilisation conjointe de ses services peut être rassemblée dans AWS Security Hub, afin de joindre les alertes et scans de vulnérabilités.
Vous pouvez aussi vous fier à des outils tiers pour accomplir cette exigence, par exemple : Qualys, Rapid7, Beyond Security, etc. Ces outils peuvent exécuter des analyses approfondies de l'infrastructure, sur le réseau, le système et les applications et proposer un rapport très détaillé. Ce dernier sera demandé lors de l'audit pour validation.
La certification nécessite un agent antivirus qui exécute et analyse le système en continu. AWS Marketplace propose de nombreux choix d'agents pouvant être utilisés pour couvrir ce sujet. Aussi, des projets open source tels que : ClamAV, Comodo Antivirus, RootKit Hunter, etc.
Le but ici est de prouver que les systèmes de fichiers du serveur ne stockent aucune information sensible comme les numéros de carte de crédit. L'auditeur peut vous demander de vérifier ce point en exécutant un scanner de PAN / carte de crédit sur les serveurs. Il existe des projets open source qui peuvent être utilisés à cet effet comme CCSRCH ou Pantastic. Il existe aussi AWS Macie pour scanner le contenu de vos buckets S3.
L'accès d'administration sur AWS peut être séparé sur deux niveaux
Nous avons introduit ce point dans la section « La conception de l’environnement AWS, Accès à différents niveaux », et nous nous concentrerons sur la traçabilité dans cette partie. AWS CloudTrail fournit le moyen d’enregistrer toutes les actions API AWS effectuées par un utilisateur. Ces journaux peuvent être archivés et stockés sur un compartiment AWS S3 à des fins d'analyses et d'investigations. Cependant, AWS CloudTrail peut être renforcé par AWS GuardDuty qui permet de surveiller les journaux de l'API et détecter les activités malveillantes, comme des comportements non autorisés lors de l'authentification IAM.
Tous les accès aux serveurs doivent être limités aux seuls utilisateurs désignés, et toutes les actions du système doivent être suivies et archivées. AWS EC2 connect et SSM permettent de journaliser toutes les actions de session dans un groupe CloudWatch.
Outre la traçabilité, PCI DSS exige également que tous les journaux système soient collectés dans un SIEM (System Information and Event Management) pour détecter toute activité malveillante sur les serveurs. Pour le moment, AWS ne fournit pas de service pour garantir cela, c'est pourquoi nous avons besoin d'outils tiers que nous pouvons trouver sur le marché (par exemple : Wazuh) ou en créer un à partir d’un ensemble de services AWS. De plus, les journaux système doivent être conservés dans un format permettant d'identifier quel utilisateur a effectué quelle action sur quel serveur, et à quel moment.
Quel que soit le choix du service ou de la solution SIEM, ne négligez pas l’automatisation des analyses de sécurité et la génération de preuves pour l’audit PCI DSS.
Il faut par ailleurs souligner l'importance de la documentation, en particulier pour l'audit PCI DSS. Elle constitue la vitrine de votre environnement. Rassurez-vous, l'auditeur ne rentrera pas dans tous les détails de votre infrastructure, mais il est utile d'avoir une documentation claire qui explique son fonctionnement. Il vérifiera la cohérence par rapport à la réalité lors de l'audit. De plus, une grande partie de cette documentation servira de preuve pour l'auditeur. Vous devrez en fournir une pour passer l’audit, donc évitez-vous une charge de dernière minute en intégrant la documentation dans votre Definition-of-Done dès la construction de votre infrastructure.
Il n'y a aucune exigence sur le format de la documentation, mais elle doit être suffisamment claire et compréhensible. L’utilisation de schémas est fortement recommandée. De nombreux outils peuvent être utilisés, on peut citer: LucidChart , Draw.io, CloudMapper, etc.
Les points les plus importants à documenter sont :
Lors de l'audit, l'auditeur peut vous demander de fournir des preuves supplémentaires, pour valider la conformité de votre environnement AWS. Voici quelques points pour vous donner une idée :
Monter une infrastructure conforme PCI DSS sur AWS est un projet enrichissant. En synthèse, voici les points à garder en tête lors de votre préparation au passage PCI DSS :
Et le plus important de tous : profitez de ce que vous faites et bon courage. :-)