Payment Card Industry Data Security Standard (PCI-DSS) compliance is a requirement for any business that stores, processes, or transmits cardholder data.
PCI-DSS est l'une des certifications les plus précieuses du cloud computing. Cette certification prouve 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 normes à appliquer, mais pas les outils à utiliser, ce qui est le choix du client.
Il existe quatre niveaux de conformité PCI, qui sont déterminés par le nombre de transactions que l'organisation traite chaque année.
Cet article est un ensemble de flashcards qui expliqueront 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 de environnement 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 supposons que vous avez déjà une bonne connaissance des services AWS afin d'avoir une bonne compréhension de cet article. Nous allons mentionner uniquement les services AWS et comment les utiliser. Nous vous invitons également à consulter la description complète de ces services sur le site web officiel d'AWS.
Il est très important d'avoir une stratégie AWS Organization robuste dès le début. AWS recommande d'utiliser une architecture multi compte afin notamment, de garantir :
On pourrait se demander ce que cela a à voir avec PCI-DSS. Si le multi-compte n'est pas une exigence en soi, l'isolation des environnements (dev, staging, prod) l'est. Cette isolation peut être mise en place au niveau réseau mais nous recommandons l'architecture multi-comptes qui est le plus fort niveau d’isolation disponible et permet plus de flexibilité et de rapidité pour les évolutions futures.
Pensez à analyser l’utilisation de vos services par vos différents environnements. Il peut rapidement émerger le besoin d’un compte qui héberger des services utiles à tous. AWS SES par exemple, est utilisé pour l’envoi d’emails via des domaines validés. L'étape de validation nécessite une configuration dans SES et 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, et le service peut être partagé via 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.
Parmi les services qu’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.
Pour les journaux et les métriques système, le VPC peering peut être utilisé pour les collecter au point de collecte de données, tout en restant privé.
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 tels que : AWSMaster, AWSAdmin, AWSDevelopper, AWSSecurityAuditor, AWSCostManager, ... 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 bien documentés et expliqués, avec la liste des utilisateurs et leurs profils.
PCI-DSS exige que tous les accès à l'environnement AWS utilisent un second facteur d’authentification (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 ou AD 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.
AWS propose Landing Zone et ControlTower qui vous permettent de traiter toutes les exigences et recommandations mentionnées précédemment. Je vous conseille AWS ControlTower qui est une implémentation des meilleures pratiques AWS, simple à utiliser. AWS est en train d'abandonner progressivement son offre Landing Zone au profit de ControlTower.
PCI-DSS ne nécessite pas de modèle d'infrastructure spécifique à mettre en œuvre, mais il exige la présence de certains composants et l’application de bonnes pratiques. Le framework AWS Well-Architected peut être utilisé comme guide de référence.
il existe différents types de normes de durcissement qui peuvent être implémentées : CIS, ISO, SANS, NIST…. PCI-DSS exige d’en choisir une et de l'appliquer. AWS Inspector peut être utilisé pour vérifier la conformité des serveurs Linux par rapport à la norme CIS. Cet agent peut être programmé pour exécuter une évaluation de sécurité sur un serveur et produire une liste détaillée du résultat.
Le durcissement d'un système d'exploitation prend du temps, en particulier lorsque vous avez beaucoup d’alertes à corriger. L’utilisation d’AMI renforcées CIS tirées 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 vérifier 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 embarque 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 ne fournit pas de service pour cette tâche et vous devez utiliser des outils tiers comme Notary.
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 Lambda. Pour rappel, AWS KMS est un service CloudHSM mutualisé.
PCI-DSS exige 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 par exemple McAfee, Endpoint Protector ou Clamav.
SSL/TLS doit être utilisé pour chiffrer les données en transit, à l'intérieur et à l'extérieur de votre SI. Le service ACM peut être utilisé pour fournir des certificats à la demande. Ils peuvent être utilisés au niveau des load balancers 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, Nomad ou autre, le mode TLS doit systématiquement être activé.
PCI-DSS exige que les flux entrants et sortants soient limités et filtrés. AWS fournit les Security Groups et les NACLs 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 par exemple Squid. 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.
PCI-DSS nécessite l'utilisation d'un scanner de vulnérabilité pour prouver que votre plate-forme ne présente pas de risque important. AWS fournit de nombreux services pour renforcer la sécurité des environnements AWS tels que IAM, VPC, Config, GuardDuty, WAF et Inspector. Ce dernier ne fonctionne qu'au niveau système, ce qui en fait un service d'analyse de vulnérabilité non complet pour le moment.
Dans ce cas, vous devez 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 fournir un rapport très détaillé. Ce dernier sera demandé lors de l'audit pour validation. À savoir : toutes les constatations “de niveau 5” (critiques) doivent être clôturées avant la fin de l'audit. Les autres doivent être traitées le plus tôt possible après.
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 .... et plus .
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.
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 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é. 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.
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, Pulimi 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 dans un endroit sûr et les utiliser de façon plus sécurisée dans vos applications.
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.
Il faut également 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 l'un des projets les plus stimulants que j’ai eu à mener dans ma carrière. J’ai beaucoup appris et fait beaucoup de choses formidables sur AWS. Un grand merci à mes collègues de Wescale, pour leurs corrections et suggestions d’amélioration de cet article. 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. :-)