Sommaire
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.
Lisez-moi avant l'article
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.
La Conception de l'environnement AWS
Stratégie multi souscriptions
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 :
- la sécurité et la gouvernance pour minimiser le périmètre de risque ;
- l’isolement administratif ;
- la maîtrise et la lisibilité de sa facturation.
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.
Compte transverse
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 :
- Un Bucket S3 et une table Dynamodb au service d’un backend Terraform
- AWS GuardDuty, afin de centraliser la détection continue des menaces
- AWS CloudTrail sur tous les comptes, avec la centralisation des trails sur un Bucket S3 commun
- AWS ECR pour avoir un unique référentiel d’images de conteneurs
- Scanner de vulnérabilité
- Outils de CI / CD
- Transit Gateway
- …
Centralisation des journaux et métriques
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).
Accès à différents niveaux
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.
Utiliser l'authentification forte
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 :
- Être changé tous les 90 jours
- Respectez un nombre minimum de caractères (> = 9)
- Respecter une variété de caractères minimum
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.
Conception AWS IaC (Infrastructure as Code)
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.
La Conception de l'infrastructure AWS
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 :
- AWS TrustedAdvisor afin de vous remonter les recommandations, de sécurité notamment
- AWS Security Hub dans le but de gérer les aspects conformité de façon centralisé
- AWS Well-Architected afin de vous aider lors de l’audit, sur les bonnes pratiques globales recommandées par AWS.
En guise de lecture, nous vous recommandons les publications suivantes :
- La FAQ AWS concernant PCI DSS, avec tous les liens vers les guides et recommandations : https://aws.amazon.com/fr/compliance/pci-dss-level-1-faqs/
- Et bien sûr la ressource officielle de documentation PCI DSS : https://www.pcisecuritystandards.org/document_library/
Durcissement OS
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.
Durcissement des conteneurs
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.
Gestion des secrets et protection des données
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.
Protection contre la perte des données (DLP)
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.
SSL / TLS partout
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.
La restriction et filtrage du réseau
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.
Analyse de vulnérabilité
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.
Analyse antivirus du serveur
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.
Scan de carte de crédit / PAN (Primary Account Number)
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.
Administration de l’environnement AWS
L'accès d'administration sur AWS peut être séparé sur deux niveaux
Traçabilité des accès aux services AWS
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.
Traçabilité des accès aux serveurs
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.
Mise en place d’un SIEM
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.
Preuves
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 :
- Le schéma d'organisation AWS, expliquez bien comment les environnements sont séparés les uns des autres
- Le schéma d'infrastructure système AWS
- Les schémas des flux réseau, y compris AWS VPC, sous-réseaux, tables de routage, NatGateway, InternetGateway, points de terminaison VPC, etc.
- La configuration des protocoles et des ports réseau dans AWS NACL et SG
- Montrer comment les données sont acheminées au sein de votre infrastructure et comment les services communiquent entre eux.
- Décrire le déroulement de l’authentification sur l’environnement AWS et la gestion des utilisateurs, vous devez expliquer comment ajouter, mettre à jour et supprimer un utilisateur.
- L'accès au compte racine AWS doit être délégué à une seule personne identifiée dans l'entreprise.
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 :
- Journaux AWS CloudTrail
- Journaux de session AWS SSM
- Captures d'écran de la configuration AWS Active Directory / IAM
- Rapports d'analyse AWS Inspector
- Rapports d'analyse des vulnérabilités internes et externes
- Informations sur les paniers / cartes de crédit, rapports d'analyse du système de fichiers
- Les attestations de conformité AWS, à récupérer dans AWS Artifacts
Conclusion
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 :
- Les bonnes choses commencent dès le début, avoir une bonne conception (organisation, infrastructure système, IaC) vous permet de corriger plus rapidement pendant l'audit.
- Automatisation, on peut dire que c'est un incontournable, en particulier pour les infrastructures à grande échelle.
- Le Well-Architected d’AWS est votre guide des bonnes pratiques durant la réalisation.
- Prenez soin de la documentation et démarrez-la dès le début. Il doit être inclus dans la « Definition Of Done ».
- Préparez une réponse pour chaque point qui n'est pas conforme et qui ne peut pas être corrigé pour certaines raisons techniques
- Sachez que, malheureusement, dans certains cas, AWS s'appuie sur des outils tiers pour répondre aux exigences PCI DSS
- Consultez toutes les directives PCI DSS Cloud Computing et les améliorations de version ici
- Consultez les détails de la certification sur le site Web AWS
- Enfin, PCI DSS consiste à ne configurer que ce dont vous avez besoin et à ne pas laisser les portes ouvertes dans votre infrastructure.
Et le plus important de tous : profitez de ce que vous faites et bon courage. :-)
