Sommaire
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.
- Niveau 1: plus 6 millions de transactions par an
- Niveau 2: de 1 à 6 millions de transactions par an
- Niveau 3: de 20 000 à 1 million de transactions par an
- Niveau 4: moins de 20 000 transactions par an
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.
La Conception de l'environnement AWS
Stratégie multi-souscription
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 :
- 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-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.
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é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 :
- un bucket S3 et une table Dynamodb au service d’un backend Terraform
- GuardDuty, afin de centraliser la détection continue des menaces
- ECR pour avoir un unique référentiel d’images de conteneurs
- Scanner de vulnérabilité
- Outils de CI / CD
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.
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).
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 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.
Utiliser l'authentification forte
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 :
- Ê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 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.
La Conception de l'infrastructure AWS
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.
Durcissement OS
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.
Durcissement des conteneurs
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.
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 Lambda. Pour rappel, AWS KMS est un service CloudHSM mutualisé.
Protection contre la perte des données (DLP) :
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 partout
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é.
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 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.
Analyse de vulnérabilité
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.
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 .... et plus .
Scan de PAN / carte de crédit
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.
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.
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.
Conception AWS IaC
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.
La documentation
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 :
- 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 AD / 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.
Conclusion
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 :
- 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 must en particulier pour les infrastructures à grande échelle ;
- le Well-Architected framework d’AWS est votre guide des bonnes pratiques pendant 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. :-)
Références pour aller plus loin
- Specification PCI-DSS
- PCI-DSS Compliance Levels
- Notary
- AWS Blog - Set up outbound proxy with domain whitelisting
- Security best practices for AWS IAM
- Data loss prevention and strategies
- Practical Linux hardening guide
- Docker hardening guide
- AWS Control Tower vs AWS Landing Zone
- 6 Benefits of adopting an AWS multi-account strategy