Implémentation de la norme PCI DSS dans le Cloud (PFE Master Faculté des sciences Ain chock)

Faculté des sciences Ain Chock Casablanca
MASTER SPECIALISE UNIVERSITAIRE : Sécurité de l’Information et des Systèmes.
Implémentation de la norme PCI DSS
dans le Cloud
Cas d’un Cloud IaaS public hébergeant deux sites e-commerce
Nouh DROUSSI
2014/2015

Implémentation de la norme PCI DSS dans le Cloud
Faculté des sciences Ain Chock Page 1
Faculté des sciences Ain Chock Casablanca
MASTER SPECIALISE UNIVERSITAIRE : Sécurité de l’Information et des Systèmes.
INTELLCAP
Implémentation de la norme PCI DSS
dans le Cloud
Cas d’un Cloud IaaS public hébergeant deux sites e-commerce
Présenté par : Mr Nouh DROUSSI
Encadrant de la faculté : Mr Abderrahim SEKKAKI
Encadrant de l’entreprise : Mr Hamza AKASBI
2014/2015

Table des matières
Présentation de l’entreprise …………………………………………………...4
1 Généralités…………………………………………………………………….5
1.1 Terminologie……………………………………………………………………………….5
1.2 Conclusion générale ……………………………………………………………………….5
1.3 Utilisation prévue ………………………………………………………………………… 6
1.4 Publique…………………………………………………………………………………....6
1.6 Présentation du Cloud …………………………………………………………………….7
1.6 Problématique...……………………………………………………………………………8
1.7 Exemples de contremesures de sécurité - (exemple AWS Amazon Web Services) ……9
1.7.1 Vue générale ……………………………………………………………………………9
1.7.2 Contremesures …………………………………………………………………………..9
1.7.3 Compatibilité PCI DSS ………………………………………………………………..11
1.7.4 Conformité AWS ……………………………………………………………………11
2 Etapes pour certifier un client ……………………………………………………12
3 Valider le Client avec la norme PCI DSS ………………………………………13
3.1 Prudence et diligence raisonnable ………………………………………………………. 13
3.2 Les CSP compatibles et non compatibles ………………………………………………..14
3.3 Elaborer un SLA entre le client et son CSP ……………………………………………...16
3.4 Définir l'environnement ………………………………………………………………….17
3.5 Exiger un inventaire ……………………………………………………………………..17
3.6 Partage de rôles et responsabilités ……………………………………………………….19
3.7 Défis de conformité ……………………………………………………………………...28
3.8 Définir d'utilisation appropriée des outils de gestion …………………………………….29
3.9 Etablir des politiques et des procédures pour chaque exigence de sécurité PCI DSS, ainsi
que la gestion des rapports ……………………………………………………………….29
3.10 Considérations et recommandations pour l’environnement Cloud déployé ……………29
3.10.1 Considérations de segmentation ……………………………………………………...30
3.10.2 Recommandations pour les environnements en mode mixte ………………………...31
3.10.3 Considérations de scoping …………………………………………………………..32
3.10.4 Composants systèmes virtuels et le scoping …………………………………………32
3.11 Planning des documents que le client doit demander au CSP …………………………33
3.12 Considérations de sécurité ……………………………………………………………...34
3.12.1 Gestion de risque ……………………………………………………………………..34
3.12.2 Evaluer les risques associés aux technologies de virtualisation ……………………...35
3.12.3 Identifier les menaces ………………………………………………………………..36
3.12.4 Identifier les vulnérabilités …………………………………………………………...36
3.13 Installations et accès physique ………………………………………………………….36
3.14 Considérations sur la sécurité des données ……………………………………………..37
3.14.1 Images et clichés instantanés ………………………………………………………...37

3.14.2 Machines dormantes ou inactives ……………………………………………………38
3.14.3 Reconnaître la nature dynamique des VM …………………………………………..38
3.14.4 La gestion du cycle de vie des données ……………………………………………...39
3.14.5 Classification des données …………………………………………………………...39
3.14.6 Chiffrement des données et gestion des clés cryptographiques (HSM ou Cloud
HSM) ………………………………………………………………………………………...39
3.14.7 Elimination des données ……………………………………………………………...40
3.14.8 Identité et gestion d’accès …………………………………………………………….40
3.14.9 Introspection …………………………………………………………………………..41
3.14.10 Mettre en œuvre la défense en profondeur …………………………………………42
3.14.11 Isolation des fonctions de sécurité …………………………………………………42
3.14.12 Appliquer le moindre privilège et la séparation des fonctions ………………………43
3.14.13 Evaluer les technologies d'hyperviseur ……………………………………………...43
3.14.14 Solidifier l’hyperviseur ……………………………………………………………..43
3.14.15 Solidifier les machines virtuelles et autres composants ……………………………..44
3.14.16 Meilleures pratiques pour les applications de paiement …………………………….44
3.15 Considérations de Cloud pour PCI DSS ……………………………………………….46

Présentation de l’entreprise :
INTELLCAP est une société de droit marocain crée en 2008 à l’initiative de Monsieur
ILALI Idriss. INTELLCAP, spécialisé en la formation, la recherche, le développement et
l'innovation technologique, entre autres, dans les domaines des énergies renouvelables et de
l'eau, proposant des solutions intégrées et à la demande pour les entreprises et organisations,
déclare posséder l'expertise lui permettant de réaliser sa mission avec professionnalisme
INTELLCAP opère dans plusieurs domaines d’activités :
• Aéronautique, Aerospace, Energies renouvelables, véhicules
électriques, production et prototypages…
• La R&D, le développement technologique de solutions innovantes par
la réalisation de systèmes technologiques développés clés en main qui ont pour but
d’intégrer le pays dans l’ère de l’industrialisation.
• La formation des jeunes et leur accompagnement dans la création de
startups innovantes sur la base de technologies nationales.
De plus pour chaque domaine :
Recherche et Développement: INTELLCAP à tisser des partenariats avec des
organismes et bureaux d’études afin de développer des solutions innovantes en matières de
véhicules électriques, systèmes de stockages et de production de l’énergie propre,
l’aéronautique.
Technologie & Ingénierie : INTELLCAP à tisser des partenariats avec des
organismes et bureaux d’études afin de développer des solutions innovantes en matières de
véhicules électriques, systèmes de stockages et de production de l’énergie propre,
l’aéronautique.
Education & Formation : Education Par le recours au processus de l’apprentissage
par la pratique. INTELLCAP a développé dans le cadre de plusieurs partenariats le concept et
la pratique des ateliers pédagogiques qui ont pour but d’initier les jeunes scolarisés et non
scolarisés à des techniques industriels et technologiques respectueuses de l’environnement .
Services : Consiste en le Conseil juridique et financier, scientifique industriel et
technologique par l’accompagnement des STRATUPS dans leur montage juridique et
financier jusqu’à la phase de la création et de la mise en œuvre de leur stratégie de
développement.

Note importante :
• Ce document traite les exigences PCI DSS pour les réseaux physiques ordinaires,
ainsi il étudie les nouvelles menaces de Cloud, virtualisation, relations clients-CSP,
et contient de nouvelles considérations de sécurité du Cloud qui peuvent s’ajouter
aux exigences PCI DSS déjà existantes.
• Le but de ce document est de fournir une CHECKLIST additionnelle (non exhaustive)
pour vérifier les exigences PCI DSS v3.0, en y ajoutant les nouvelles menaces et
vulnérabilités du Cloud et Virtualisation.
• Les nouvelles menaces et considérations de sécurité qui doivent être ajoutées au SAQ
officiel de PCI DSS v3.0 sont en forme italique et gras.
• Ce document fait l’implémentation uniquement de 2 conditions PCI DSS v3.0 de
sécurité.

1Généralités :
1.1 Terminologie :
Entité : Une entité est une organisation qui a la responsabilité de protéger les données de
cartes et peut faire appel à un fournisseur de services tiers pour l’a soutenir dans les activités
de traitement de carte ou pour sécuriser les données de cartes.
CSP (Cloud Service Provider): Le CSP, ou fournisseur de Cloud, est l'entité fournissant le
service de Cloud. Le CSP acquiert et gère l'infrastructure nécessaire à la fourniture des
services, dirige le logiciel Cloud qui fournit les services, et offre les services de Cloud
Computing dans l'accès réseau.
Client Cloud : L'entité utilisant un service fourni par un fournisseur de Cloud. Inclut les
commerçants, prestataires de services, et d'autres entités qui utilisent les services de Cloud
Computing. Mais également peut être un locataire de Cloud.
TPSP (Third-Party Service Provider) : Un prestataire de services est une entreprise qui
n’est pas une marque de paiement, directement impliquée dans le traitement, le stockage ou la
transmission des données des détenteurs de cartes au nom d'une autre entité. Cela comprend
également les entreprises qui fournissent des services de contrôle ou qui peuvent avoir un
impact sur la sécurité des données des titulaires de cartes. Il existe de nombreux types
d'entreprises qui peuvent tomber dans la catégorie de «fournisseur de service », ça dépend des
services fournis.
1.2 Conclusion générale :
Le « Cloud Computing » est une méthode d’utilisation à la demande des applications,
plateformes ou infrastructures réseaux et systèmes distribuées sans la nécessité de savoir leurs
localisations géographiques. Il existe un certain nombre de facteurs à prendre en considération
lors de la migration à des services de Cloud Computing, et les organisations doivent
clairement comprendre leur besoins avant qu'ils puissent déterminer si et comment ils seront
accueillis par une solution ou fournisseur particulier. Comme le Cloud Computing est encore
une technologie en évolution, les évaluations des risques et des avantages peuvent changer
selon la technologie.
La sécurité du Cloud est une responsabilité partagée entre le fournisseur de services Cloud
(CSP) et ses clients. Si les données de la carte de paiement sont stockées, traitées ou
transmises dans un environnement de Cloud Computing, la norme PCI DSS sera applicable à
cet environnement, et impliquera typiquement la validation de l'infrastructure à la fois par le
CSP et le client. La répartition des responsabilités entre le client et le fournisseur pour la
gestion des contrôles de sécurité ne dispense pas un client de sa responsabilité à veiller à ce
que la sécurité de leurs données de titulaire de carte est correctement fixée selon les exigences
PCI DSS.

Des politiques et des procédures claires doivent être convenus entre le client et le fournisseur
de Cloud pour chaque exigence de sécurité, et les responsabilités pour le fonctionnement, la
gestion et les rapports doivent être clairement définis et compris pour chaque exigence.
Le commerce électronique, communément appelé e-commerce, est l'achat et la vente de
produits ou de services sur des systèmes électroniques tels que l'Internet. Dans notre cas le
commerçant a choisi de vendre ses biens et services en ligne en gardant des responsabilités
sur l’infrastructure:
• Le commerçant peut choisir de conserver les différents niveaux de contrôle et de
responsabilité pour la gestion de l'infrastructure Cloud. Par exemple, le commerçant
peut choisir de gérer une partie du réseau Cloud public avec le modèle de service
IaaS : externaliser les réseaux et les serveurs, la gestion de tous les systèmes et les
infrastructures pour les fournisseurs de service Cloud, et de gérer certains composants
à distance en utilisant l’interface Web ou les API du CSP. Cette option de modèle de
service ne supprime pas les responsabilités PCI DSS du fournisseur, mais garde la
responsabilité partagée entre les deux parties.
• Les applications de paiement e-commerce tels que les cartes d’achat doivent être
validées selon la norme PA-DSS, et confirmées pour être incluses sur la liste de PCI
SSC des applications de paiement validées. Pour les applications e-commerce
développées en interne, PA-DSS doit être utilisée comme une meilleure pratique au
cours du développement.
• Les relations avec les tiers et les responsabilités PCI DSS du marchand et chaque
tierce-partie doivent être clairement documentées dans un accord de niveau de service
SLA pour assurer que chaque partie comprend et met en œuvre les contrôles PCI DSS
appropriés.
1.3 Utilisation prévue :
Ce document est utilisé pour plusieurs facteurs :
• Il fournit des indications sur l'utilisation des technologies de Cloud Computing et les
considérations pour le maintien des exigences PCI DSS dans les environnements de
Cloud Computing.
• Le but est de fournir des conseils sur l'utilisation des technologies de e-commerce
conformément à la Payment Card Industry Data Security Standard (PCI DSS).
1.4 Publique :
Le public concerné par ce document est :
• Les marchands qui utilisent ou envisagent l'utilisation des technologies e-commerce
dans un environnement de données de titulaire de carte (CDE).
• Les fournisseurs de services tiers qui fournissent des services de e-commerce dans le
Cloud.

• Ce document peut également avoir de la valeur pour les évaluateurs qualifiés de
sécurité (QSA) examinant les environnements e-commerce dans le cadre d'une
évaluation PCI DSS.
• Les acquéreurs (aussi connus comme "les banques acquéreuses», «banques d'affaires»,
ou «institutions d'acquisition financières") - en tant qu’entité qui initie et entretient des
relations avec les commerçants pour l'acceptation des cartes de paiement, un acquéreur
est responsable de veiller à ce que les marchands de son portefeuille s’engagent avec
des TPSP sécurisés.
1.5 Présentation du Cloud :
Par définition, le « Cloud Computing » fait référence à la fourniture à la demande de
ressources et d’applications informatiques qui peuvent être rapidement provisionnés et libérés
avec un effort minime de gestion pour le client.
Le Cloud Computing se décline en trois principaux types, généralement connus sous le nom
de IaaS (Infrastructure en tant que service), PaaS (Plate-forme en tant que service) et SaaS
(Logiciel en tant que service). En sélectionnant le type de Cloud Computing qui correspond le
mieux à nos besoins, nous pouvons combiner à la fois le niveau de contrôle approprié et éviter
un remaniement en profondeur.
Infrastructure en tant que service (IaaS) :
L'infrastructure en tant que service (IaaS) donne habituellement l’accès à des fonctionnalités
de mise en réseau, à des ordinateurs (virtuels ou sur du matériel dédié) et à de l'espace de
stockage de données. Le service IaaS offre le niveau le plus élevé de flexibilité et de contrôle
de gestion en ce qui concerne les ressources informatiques et est très similaire aux ressources
informatiques existantes avec lesquelles les services informatiques et les développeurs sont
aujourd'hui familiarisés.
Plate-forme en tant que service (PaaS) :
Grâce au service PaaS, les entreprises n'ont plus besoin de gérer l'infrastructure sous-jacente
(en règle générale, le matériel et les systèmes d'exploitation) et le client peut se concentrer sur
le déploiement et la gestion de ses applications. Le client sera ainsi plus efficace, car il n’a pas
à se soucier de l'approvisionnement des ressources, de la planification des capacités, de la
maintenance logicielle, de l'application de correctifs ou de toute autre charge indifférenciée
liée à l'exécution de son application.
Logiciel en tant que service (SaaS) :
Le logiciel en tant que service offre un produit final qui est exécuté et géré par le prestataire
de services. Dans la plupart des cas, les personnes qui font référence au service Saas pensent
aux applications des utilisateurs finaux. Avec une offre SaaS, le client n'a pas à songer à la
maintenance du service ou à la gestion de l'infrastructure sous-jacente, il doit juste réfléchir à
l'utilisation de ce logiciel spécifique. Une messagerie Web dans laquelle on peut envoyer et
recevoir des e-mails sans avoir à gérer des ajouts de fonctionnalités ni à effectuer la

maintenance des serveurs et des systèmes d'exploitation sur lesquels elle s'exécute est un
exemple courant d'application SaaS.
1.6 Problématique :
Le marché mondial du e-commerce :
1 000 milliards de dollars dépensés en 2012 - D’après eMarketer.com, ce sont 1 000 milliards
de dollars qui ont été dépensés dans le monde en 2012 sur le marché du e-commerce , soit une
croissance de 21,1% par rapport à 2011. Les Etats-Unis ont représenté à eux seuls 343,43
milliards de dollars de dépenses l’année dernière. Mais la plus forte croissance (33%) est à
inscrire au crédit de la région Asie-Pacifique (332,46 milliards en 2012).
Avantages du Cloud Computing :
• L'agilité dans la mutualisation des ressources : Il est possible d'affecter des
ressources technologiques supplémentaires aux départements métiers de l'entreprise
lorsque celles-ci sont nécessaires pour faire face à un pic d'activité par exemple, puis
de les libérer une fois la charge ramenée à la normale.
• La maîtrise et l'agilité de son outil informatique : Avec un Cloud Privé, l'entreprise
maîtrise la gestion de son système d'information de bout en bout car elle reste
propriétaire de son infrastructure.
Avantages du Cloud public :
• Plutôt que d'investir massivement dans des centres de données et des serveurs, les
clients peuvent ne payer que lorsqu’elles consomment des ressources de calcul. Ainsi,
les clients ne paient qu'en fonction de ce qu’elles consomment.
• À l'aide du Cloud Computing public, les clients peuvent obtenir un coût variable
moins élevé que celui que le client aurait de son côté. Dans la mesure où l'utilisation
de centaines de milliers de clients est regroupée dans le Cloud, les fournisseurs tels
qu'Amazon Web Services ou Google Cloud Computing peuvent bénéficier de plus
grandes économies d'échelle, ce qui se traduit par des prix moins élevés à l'utilisation.
• Le client ne pourra jamais deviner exactement quels seront ses besoins en termes de
capacités d'infrastructure. Grâce au Cloud Computing le client peut accéder à toutes
les ressources qu’il souhaite, et les augmenter ou les réduire en fonction de ses besoins
en quelques minutes.
• Le client peut se concentrer sur des projets qui permettent à son entreprise de se
démarquer, et non sur son infrastructure. L’équipe informatique est chez le CSP.
Problèmes de sécurité en Cloud Computing :
• L’idée que les informations confidentielles du client se trouvent entre les mains d’une
tierce-partie l’angoisse surement. L’une des conséquences du Cloud Computing peut
en effet être une perte de contrôle. Transférer le traitement de vos données vers un
tiers, c’est transférer également un peu de la responsabilité qui leur est associée en
matière de sécurité et de conformité. Il n’est donc pas étonnant que les professionnels

de la sécurité soient inquiets. Par conséquent, il est capital que le client ait entièrement
confiance en son CSP.
• La gouvernance en matière de sécurité des informations doit résulter d’une
collaboration entre les clients et les fournisseurs afin d’atteindre des objectifs fixés qui
permettent la mise en œuvre de la mission de l’entreprise et du programme de sécurité
des informations.
• L’une des premières mesures que les entreprises doivent prendre est d’acquérir une
véritable compréhension de la nature des données de leur organisation. Dans notre cas
on est censés stocker, traiter et transmettre des données de cartes de paiements, la
norme qui sera applicable dans ce cas est PCI DSS.
1.7 Exemples de contremesures de sécurité - (exemple
AWS Amazon Web Services) :
1.7.1 Vue générale :
• L'infrastructure du Cloud doit être hébergée dans des centres de données extrêmement
sécurisés.
• La sécurité doit être assurée par une surveillance électronique très sophistiquée et des
systèmes de contrôle d'accès multi-facteurs.
• Les centres de sécurité doivent être gardés 24h/24 et 7j/7 par des agents de sécurité
formés et l'accès sera strictement contrôlé en fonction du principe du moindre
privilège.
• Tous les membres du personnel font l'objet d'un contrôle lorsqu'ils quittent des zones
renfermant des données client.
• Des systèmes environnementaux sont intégrés aux centres de données afin de
minimiser l'impact des perturbations sur leur fonctionnement.
• Si possible, plusieurs régions géographiques et zones de disponibilité permettront une
résilience face à la plupart des modes de défaillance, y compris les catastrophes
naturelles ou les défaillances du système.
• Veiller à fournir une disponibilité optimale, tout en garantissant une confidentialité
complète et un isolement des clients.
• Une séparation du trafic réseau entre le réseau du CSP et son service de Cloud devra
être garantie.
1.7.2 Contremesures :
• Accès sécurisé – Les points d'accès des clients, également appelés points de
terminaison des API, autorisent un accès HTTP sécurisé (HTTPS) afin que les clients
puissent établir des sessions de communication sécurisées avec leurs services AWS
via SSL/TLS.
• Pare-feu intégrés – En configurant des règles de pare-feu intégrées, le client peut
déterminer le degré d'accessibilité de ses instances, depuis un accès totalement public
à un accès entièrement privé, en passant par différents échelons intermédiaires. Et

lorsque les instances du client résident dans un sous-réseau Virtual Private Cloud
(VPC), les clients peuvent contrôler aussi bien les sorties que les entrées.
• Utilisateurs uniques – L'outil AWS Identity and Access Management (IAM) permet
de contrôler le niveau d'accès d’utilisateurs clients par rapport aux services reposant
sur l'infrastructure AWS. Avec AWS IAM, chaque utilisateur peut posséder des
identifiants de sécurité uniques, ce qui évite d'avoir à partager les mots de passe ou
clés et permet d'appliquer les bonnes pratiques de sécurité telles que la séparation des
rôles et le principe de moindre privilège.
• Authentification multi-facteurs (MFA) – AWS intègre la prise en charge de
l'authentification multi-facteurs (MFA) sur le compte racine AWS ainsi que sur les
comptes individuels des utilisateurs IAM correspondants.
• Sous-réseaux privés – Le service AWS Virtual Private Cloud (VPC) permet d'ajouter
une couche de sécurité réseau supplémentaire aux instances en créant des sous-réseaux
privés et, même, en ajoutant un tunnel VPN IPsec entre le réseau interne client et son
VPC AWS.
• Stockage de données chiffrées – Les clients peuvent chiffrer automatiquement les
données et objets qu'ils stockent dans Amazon EBS, Amazon S3, Glacier, Redshift,
ainsi que sur RDS pour Oracle et SQL Server, en utilisant Advanced Encryption
Standard (AES) 256, une norme de chiffrement par clé symétrique sécurisée utilisant
des clés de chiffrement de 256 bits.
• Option de connexion dédiée – Le service AWS Direct Connect permet
l'établissement d'une connexion réseau dédiée depuis ses locaux vers AWS. Utilisant
des VLAN 802.1q aux normes de l'industrie, cette connexion dédiée peut être
partitionnée en plusieurs connexions logiques afin de permettre l'accès à des
environnements IP aussi bien publics que privés au sein du Cloud client AWS.
• Perfect Forward Secrecy (confidentialité persistante) – Pour une confidentialité
renforcée des communications, plusieurs services AWS tels qu'Elastic Load Balancer
et Amazon CloudFront offrent de nouvelles suites de chiffrement (cipher) plus
robustes. Ces suites de chiffrement permettent aux clients SSL/TLS d'utiliser la
technologie PFS (Perfect Forward Secrecy), laquelle est basée sur des clés de session
éphémères qui ne sont enregistrées nulle part. Ainsi, il est impossible de décoder les
données interceptées, même si la clé secrète à long terme est compromise.
• Journaux de sécurité – AWS CloudTrail fournit les journaux consignant les activités
de tous les utilisateurs au sein du compte client AWS. Le client peut voir quelles sont
les actions ayant été effectuées sur chacune des ressources AWS et leur auteur.
L'historique des appels d'API AWS généré par CloudTrail permet de réaliser une
analyse de sécurité, le suivi des modifications au niveau des ressources, ainsi que
l'audit de conformité.
• Identification et configuration des actifs – Le service AWS Config permet de
détecter immédiatement toutes les ressources AWS et de vérifier la configuration de
chacune d'entre elles. Le client peut choisir de recevoir une notification à chaque
modification de la configuration et explorer l'historique de configuration à des fins
d'analyse des incidents.
• Gestion centralisée des clés – Les clients ayant largement recours au chiffrement
nécessitent un contrôle strict de leurs clés. C'est pourquoi AWS Key Management

Service dispose d'une option de gestion particulièrement utile permettant de créer et de
gérer les clés utilisées pour chiffrer les données au repos.
• Région GovCloud isolée – Pour les clients ayant besoin de mesures supplémentaires
afin de se conformer à la réglementation américaine ITAR sur le trafic international
d'armes, AWS fournit une région totalement séparée, appelée AWS GovCloud (USA),
qui offre un environnement au sein duquel les clients peuvent exécuter des
applications conformes aux exigences ITAR et des points de terminaison spécifiques
qui utilisent le chiffrement FIPS 140-2.
• CloudHSM – Pour les clients qui doivent utiliser des modules de sécurité matériels ou
HSM (Hardware Security Module) pour le stockage de clés cryptographiques, AWS
CloudHSM constitue un moyen pratique et hautement sécurisé de stocker et gérer des
clés.
• Trusted Advisor – Fourni automatiquement lorsque le client s’inscrit au Premium
Support, le service Trusted Advisor est un moyen pratique de voir quels services on
peut sécuriser encore davantage. Il surveille les ressources AWS et avertit lorsqu'il
détecte des failles dans la configuration de sécurité, telles que l'accès trop vaste à
certains ports d'instance EC2 et compartiments de stockage S3, l'utilisation minimale
de la séparation des rôles avec IAM, et des politiques de gestion des mots de passe
fragiles.
1.7.3 Compatibilité PCI DSS :
PCI-DSS est une norme qui spécifie les meilleures pratiques et les divers contrôles de
sécurité. Toute entité qui stocke, traite ou transmet des données de titulaire de carte est censée
être certifiée PCI DSS. La certification de la norme PCI DSS exige aux organisations :
• Création et gestion d’un réseau et d’un système sécurisés.
• Protection des données du titulaire.
• Gestion d’un programme de gestion des vulnérabilités.
• Mise en œuvre de mesures de contrôle d’accès strictes.
• Surveillance et test réguliers des réseaux.
• Gestion d’une politique de sécurité des informations.
1.7.4 Conformité AWS :
L'infrastructure du nuage AWS est conçue et gérée conformément à diverses réglementations,
normes et bonnes pratiques, notamment :
• HIPAA : AWS permet aux entités et à leurs collaborateurs entrant dans le cadre de la
législation américaine HIPAA (Health Insurance Portability and Accountability Act)
de tirer parti de l'environnement sûr d'AWS pour traiter, gérer et stocker des données
de santé à caractère personnel.
• SOC 1/SSAE 16/ISAE 3402 : Ce rapport reposant sur deux normes américaines
répond à une grande variété de critères d'audit exigés par les organismes d'audit
américains et internationaux. L'audit du rapport SOC 1 atteste que les objectifs de

contrôle d'AWS sont définis de manière appropriée et que les contrôles établis pour
protéger les données des clients sont efficaces.
• SOC 2 : En plus du rapport SOC 1, AWS publie un rapport SOC 2 (Service
Organization Controls 2), de type II. A l'instar du SOC 1 en matière d'évaluation des
contrôles, le rapport SOC 2 est une attestation qui développe l'évaluation des contrôles
par rapport aux critères stipulés par l'AICPA (American Institute of Certified Public
Accountants) dans ses principes sur les services de confiance (« Trust Services
Principles »). . Ces principes définissent des contrôles portant sur les pratiques
majeures relatives à la sécurité, à la disponibilité, à l'intégrité de traitement, à la
confidentialité et au respect de la vie privée, et s'appliquent aux prestataires de
services tels qu'AWS.
• PCI DSS, niveau 1 : De plus, AWS a obtenu la certification de niveau 1
conformément à la norme de sécurité des données dans le secteur des cartes de
paiement : la norme PCI DSS (Payment Card Industry Data Security Standard). Nos
clients peuvent donc exécuter des applications sur notre infrastructure technologique
conforme à la norme PCI pour stocker, traiter et transmettre des informations relatives
aux cartes de paiement dans le nuage.
• ISO 27001 : AWS est certifié ISO 27001 conformément à la norme ISO 27001
édictée par l'Organisation internationale de normalisation. La norme ISO 27001 est
une norme de sécurité internationale très largement adoptée qui définit des exigences à
respecter pour les systèmes de gestion de la sécurité des informations. Elle fournit une
approche systématique pour la gestion des informations des entreprises et des clients
qui repose sur des évaluations régulières des risques.
• FedRAMP (SM) : FedRAMP est un programme mis en place par le gouvernement
américain afin de normaliser l'évaluation de la sécurité, les autorisations et la
surveillance continue des produits et services de Cloud Computing jusqu'à un niveau
Modéré.
Figure 1 : Niveaux de responsabilités pour les trois modèles de services :

2 Etapes pour certifier un client :
1. Valider le CSP avec la norme PCI DSS.
2. Effectuer une diligence raisonnable.
3. Etablir un accord SLA entre CSP et client.
4. Valider le client avec la norme PCI DSS.
5. Délivrance d’une attestation de conformité (AOC)
6. Délivrance d’un rapport de conformité (ROC).
7. Le client est maintenant conforme PCI DSS
3 Valider le Client avec la norme PCI DSS :
3.1 Prudence et diligence raisonnable :
Un examen minutieux des CSP par le biais de Diligence raisonnable, avant d'établir une
relation, aide les entités dans l'examen et la sélection des bons TPSP avec les compétences et
les expériences appropriées à l'engagement.
Mettre en place un processus de diligence raisonnable du CSP :
• Etudier l’image du CSP dans le marché au niveau mondial ou national.
• Chercher le nom du CSP qui a dit qu’il est conforme PCI DSS dans la liste des
entreprises conformes PCI DSS publiée par une marque de carte de paiement : il peut
se trouver dans la liste comme il peut ne pas se trouver.
• Etudier les procédures ressources humaines du CSP : La gestion des ressources
humaines du CSP est en grande partie hors du contrôle du client. Le processus
diligence raisonnable du client doit inclure une compréhension des ressources
humaines du CSP et ses pratiques d'engagement du personnel, car le personnel
inapproprié ou sous-qualifiés peut exposer les données à des risques inutiles.
L’exigence PCI DSS 12.7 fournit une base pour évaluer le processus de recrutement et
de licenciement du CSP.
• Confirmer que le fournisseur à une bonne réputation des pratiques de travail et qu’il
effectue légitimement les services que le client croit qu'elles sont faites.
• Vérifier que la réputation du fournisseur est compatible avec l'image de l'entreprise
cliente.
• Identifier les risques potentiels ou les circonstances associées au fournisseur qui
peuvent influer sur l’exploitation ou les activités du client.
• Les éléments du service qui ont besoin d'être clarifiées, et ce besoin identification à
inclure dans contrats ou des accords de services.

• Les CSP qui ont subi une évaluation PCI DSS indépendante pour valider leur
conformité auront les résultats résumés dans une attestation de conformité (AOC) et
détaillés dans un rapport sur la conformité (ROC), le client doit examiner ces
documents attentivement.
• Les CSP qui ont subi une évaluation PCI DSS de conformité et de validation doivent
être en mesure de fournir à leurs clients les éléments suivant:
Preuve de la documentation de conformité (comme l'AOC et les articles
applicables de la ROC), y compris la date de l'évaluation de la conformité.
Des preuves documentées de composants système et des services qui ont été inclus
dans l’évaluation de la norme PCI DSS.
Des preuves documentées de composants système et des services qui ont été
exclus de la norme PCI DSS l'évaluation, le cas échéant au service.
Etudier les rapports PCI DSS du CSP: quels services et composants du système
sont validés pour chaque exigence (Par exemple, les exigences PCI DSS 6.1 et 6.2
portent sur la nécessité que les vulnérabilités doivent être identifiées, selon leur
indice et selon le risque, et corrigées en un temps minime. Si pas correctement
défini, un client pourrait supposer que le CSP gère ce processus (Voir celui de
AWS) pour tout l'environnement Cloud, alors que le CSP pourrait gérer
uniquement les vulnérabilités de son infrastructure sous-jacente, en supposant que
le client gère des vulnérabilités des systèmes d'exploitation, des applications et des
sites web (pour e-commerce)).
Figure 2 : Processus engagement CSP
Figure 3: Exemple de processus diligence raisonnable.

3.2 Les CSP compatibles et non compatibles :
Comme avec tous les services hébergés dans le périmètre de la norme PCI DSS, l'organisation
du client doit demander la preuve et l'assurance suffisante de leur CSP que tous les processus
et composants dans-le-champ sont conformes PCI DSS. Cette vérification peut être remplie
par l'évaluateur du client (par exemple comme un QSA ou ISA) dans le cadre de l'évaluation
PCI DSS du client.
• Les CSP qui ont subi une évaluation PCI DSS de conformité et de validation doivent
être en mesure de fournir à leurs clients les éléments suivant:
Preuve de la documentation de conformité (comme l'AOC et les articles
applicables de la ROC), y compris la date de l'évaluation de la conformité.
inclus dans l’évaluation de la norme PCI DSS.
exclus de la norme PCI DSS l'évaluation, le cas échéant au service.
Etudier les rapports PCI DSS du CSP: quels services et composants du système
sont validés pour chaque exigence (Par exemple, les exigences PCI DSS 6.1 et
6.2 portent sur la nécessité que les vulnérabilités doivent être identifiées, selon
leur indice et selon le risque, et corrigées en un temps minime. Si pas
correctement défini, un client pourrait supposer que le CSP gère ce processus
pour tout l'environnement Cloud, alors que le CSP pourrait gérer uniquement
les vulnérabilités de son infrastructure sous-jacente, en supposant que le client

gère des vulnérabilités des systèmes d'exploitation, des applications et des sites
web (pour e-commerce)).
• Les CSP qui n’ont pas subi une évaluation de la conformité PCI DSS devront être
inclus dans l'évaluation du client. Le CSP devra accepter de permettre à l'évaluateur du
client un accès à leur environnement pour que le client puisse compléter leur
évaluation. Les assesseurs du client peuvent exiger sur place l’accès à des
informations détaillées du CSP, y compris, mais sans s'y limiter:
L'accès aux systèmes, les installations et le personnel pour les examens sur
place, des interviews, etc.
Les politiques et procédures, la documentation des processus, des normes de
configuration, dossiers de formation, les plans d'intervention sur l’incident, etc.
Preuve (telles que les configurations, des captures d'écran, des revues de
processus, etc.) pour montrer que toutes les exigences PCI DSS sont respectées
pour les composants in-scope de système.
Figure 4: Processus de certification de la partie CSP
• Vérifier que le service utilisé est validé : Les clients doivent d'abord vérifier que le
service qu'ils utilisent est celui qui a été validé.
3.3 Elaborer un SLA entre le client et son CSP :
L'utilisation de services de Cloud Computing comprend le déploiement d'un modèle de
service défini et doit toujours être souscrite par des accords globaux de niveau de service
(SLA). L'incapacité de développer des accords SLA appropriées peuvent entraîner des
problèmes pour le client si le service de Cloud ne répond pas aux besoins et aux exigences de
leur entreprise.

• Identifier toutes les relations entre le client et ses tiers est important pour comprendre
les ramifications potentielles à l'environnement d'un client.
• Les activités de tests définis et leurs contrôles et autorisations associées doivent être
détaillées dans le SLA.
• La délimitation des responsabilités entre les parties, y compris les responsabilités pour
la mise en œuvre et la gestion de différents contrôles de sécurité pour un modèle de
Cloud public/IAAS.
• Respecter le "up-time", la haute disponibilité et l'assurance de la sécurité.
• Les activités de validation PCI DSS et de test de conformité (avec les contrôles
associés, les autorisations et les tâches planifiées) doivent également être clairement
détaillées dans le SLA.
• Les performances, la disponibilité, l'intégrité et la confidentialité doivent être
envisagées dans le SLA pour chaque service géré.
• Dans le SLA exiger la délivrance des logs des services qui tombent in-scope du CSP
périodiquement.
3.4 Définir l'environnement :
Avant que les menaces et les vulnérabilités puissent être identifiées et évaluées, une entité doit
d'abord comprendre son environnement ainsi que les personnes, les processus et les
technologies qui interagissent avec cet environnement. Lors de la définition de
l'environnement à évaluer, les entités doivent tenir compte de tous aspects qui ont un impact
potentiel de risque, indépendamment du fait qu'ils sont considérés in-scope ou hors du champ
de la norme PCI DSS.
• Une entité doit d'abord comprendre leur environnement ainsi que les personnes, les
processus et les technologies qui comprennent ou interagissent avec cet
environnement.
• La définition de l'environnement virtuel doit inclure, au minimum, les activités
suivantes:
Identification de tous les composants, y compris les hyperviseurs, les charges de
travail, les hôtes, les réseaux, les consoles de gestion et d'autres composants;
Détails physiques du site pour chaque composant;
Description des fonctions primaires et les propriétaires affectés pour chaque
composant;
Détails de visibilité dans et entre les composants;
Identification des flux de trafic entre les différentes composantes, entre les
composants et les hyperviseurs, et entre les composants et les systèmes hôtes sous-
jacents ou les ressources matérielles;
Identification de toutes les communications intra-hôtes et les flux de données, ainsi
que celles entre les composants virtuels et les autres composants du système;

Détails de toutes les interfaces de gestion et des mécanismes d'accès à
l'hyperviseur, y compris les rôles et autorisations définis;
Tous les composants matériels physiques et virtuels tels que les lecteurs de disques
amovibles et USB, ports parallèle et série.
Détails sur le nombre et les types de composants virtuels sur chaque hôte, les types
de segmentation entre les composants et les hôtes, les fonctions et les niveaux de
tous les composants virtuels de sécurité, etc.
• Les recommandations pour réduire et simplifier les exigences PCI DSS à in-scope
dans un environnement de Cloud Computing comprennent:
Mettre en œuvre une infrastructure physique dédiée qui est utilisée seulement pour
l'environnement CDE.
Réduire la dépendance sur les CSP tiers pour protéger les données de cartes de
paiement.
3.5 Exiger un inventaire :
L’utilisation d'un inventaire peut aider à identifier les types de composants impliqués dans la
livraison du service et les responsables pour les sécuriser.
Tableau 1 : Exemple de tableau d’inventaire à remplir
Type / couche Composant
Description
/ But
Type de
composante
Nombre de
composants
Notes
d’implémentation
La
responsabilité
de sécurité
des
composants
Remarque:
couches réels
varieront en
fonction de la
structure de
Offres de
services CSP
Par exemple:
Pare-feu, OS,
l'application,
serveur web,
hyperviseur,
routeur, base
de données,
etc.
Par exemple:
Est
composante
physique,
logique ou
virtuelle?
Statique ou
dynamique?
Nombre de
composants
utilisé en
relation avec
ce client
service
Utilisation défini,
l'emplacement, etc.,
le cas échéant
Par exemple:
CSP seulement,
client
seulement, ou
partagée
Données
Interfaces (APIs,
GUIs)
Applications
Pile de Solution
(Languages de
programmation)
Système
d'exploitation
(OS)

Machines
virtuelles VMs
Infrastructure
réseau virtuel
Hyperviseurs
Processeur et
mémoire
Stockage de
données
(Disques durs-
disques
amovibles-
stockage..etc)
Réseau
(Interfaces et
périphériques-
infrastructure de
communications)
Installations
physiques/Centre
de données
3.6 Partage de rôles et responsabilités :
La responsabilité de la mise en œuvre, l'exploitation et la gestion des contrôles de sécurité
sera partagée entre le CSP et son client. Si ces responsabilités en matière de sécurité ne sont
pas correctement assignées, communiquées et comprises, des configurations et vulnérabilités
non sécurisées peuvent impacter la sécurité générale de l’environnement, en résultant un
exploit potentiel, la perte de données et d'autres compromis.
• Il faut partager les responsabilités entre le CSP et le client pour gérer la sécurité (La
segmentation et séparation est une responsabilité du CSP, et le client doit vérifier par
ses outils que son environnement est séparé de l’environnement des autres clients qui
pourront être non sécurisés.).
• Dresser des politiques et des procédures claires entre le client et le CSP pour chaque
exigence et responsabilité, et délivrer un rapport pour chacun.
• Dans un modèle Cloud public, la responsabilité est partagée, il faut déterminer le
niveau de responsabilité du CSP et celui du client. Il faut bien détailler ces niveaux de
responsabilités (Délivrer les journaux au client, le client doit analyser les logs, le client
ne doit jamais lever sa main sur la sécurité des données CHD, car c’est lui le
responsable finale.)

• Il faut détailler la nature de responsabilité partagée, c’est quoi ce partage ?=
(responsabilités sur les opérations techniques (Administration des composants
virtuels), la gestion et la génération de rapports pour chaque exigence)
• Les responsabilités délimitées entre le client et le CSP pour la gestion des contrôles
PCI DSS sont influencées par un certain nombre de variables, y compris, mais sans s'y
limiter:
Le but pour lequel le client utilise le service de Cloud.
Le scope des exigences PCI DSS que le client externalise au CSP.
Les services et les composants du système que le CSP a validé dans ses propres
opérations.
L'option de service que le client a choisi d'engager le CSP (IaaS, PaaS ou SaaS).
Le scope de tous les services supplémentaires le CSP fournit une gestion proactive
de la conformité du client (Par exemple, plus les services de sécurité gérés).
• Détailler les responsabilités PCI DSS pour uniquement le modèle de service IaaS.
• Il y a les rôles sur les composants de l’environnement virtuel, et les rôles sur les
exigences PCI DSS.
• Il doit être particulièrement nécessaire de définir des rôles granulaires d’utilisateurs
(par exemple, la séparation d’administrateur réseau de l'administrateur du serveur).
• Lorsque le CSP conserve la responsabilité des contrôles PCI DSS, le client est
toujours responsable de la surveillance de la conformité continue du CSP pour toutes
les exigences applicables (logs, les documents de conformité pour chaque exigence).
• Pour chaque control PCI DSS, il faut identifier le responsable.
• Le client doit avoir une visibilité sur les exigences de sécurité qui ne sont pas couverts
par le CSP et qui rentrent dans les responsabilités du client à gérer, implémenter et
valider comme leur propre exigence PCI DSS.
Tableau 2: La description de chaque couche du Cloud
Couche Description
Application Program Interface
(API) ou Interface graphique d’utilisateur
(GUI)
L'interface utilisée par le client ou leurs
clients pour interagir avec l’application.
L'API la plus courante est actuellement
RESTful http ou HTTPS. Le GUI le plus
utilisé est un site Web HTTP ou HTTPS.
Application L’application actuelle est utilisée par un ou
plusieurs clients ou leurs clients.
Suite de solutions Ceci est le langage de programmation utilisé
pour créer et déployer les applications.
Quelques exemples incluent .NET, Python,
Ruby, Perl, etc.
Les systèmes d'exploitation (OS) Dans un environnement virtuel, l'OS
fonctionne au sein de chaque VM.
Alternativement, s’il n'y a pas d’hyperviseur

sous-jacent présent, le système d'exploitation
s’exécute directement sur le matériel de
stockage.
Machine virtuelle (VM) Le conteneur virtuel assigné pour une
utilisation client.
Infrastructure de réseau virtuel Pour les communications à l'intérieur et entre
les machines virtuelles
Hyperviseur Lorsque la virtualisation est utilisée pour
gérer les ressources, l'hyperviseur est
responsable de l'allocation des ressources à
chaque machine virtuelle. Il est également
possible de l’utiliser pour mettre en œuvre la
sécurité.
Traitement et mémoire Le matériel physique qui fournit de temps
CPU et de la mémoire physique.
Stockage de données Le matériel physique utilisé pour le stockage
de fichiers.
Réseau Cela peut être un réseau physique ou virtuel.
Il est responsable de l'exécution les
communications entre les systèmes et
éventuellement l'internet.
Installation physique Le bâtiment physique réel où se trouvent les
systèmes de Cloud Computing .
Tableau 3 : Exemple de comment les contrôles peuvent être affectés entre le CSP et le
Client au niveau du modèle de service IaaS.
Client
CSP
Couche Cloud IaaS
Données
Interfaces (APIs, GUIs)
Applications
Pile de Solution (Languages de
programmation)
Système d'exploitation (OS)
Machines virtuelles VMs
Infrastructure réseau virtuel
Hyperviseurs
Processeur et mémoire
Stockage de données (Disques durs-disques

amovibles-stockage..etc)
Réseau (Interfaces et périphériques-
infrastructure de communications)
Installations physiques/Centre de données
Tableau 4 : exemple de comment les responsabilités peuvent être partagées entre le CSP
et le client
Client
CSP
Les deux Client et
CSP
Exigence PCI DSS IaaS
1: Installer et gérer une configuration de pare-feu pour protéger
les données du titulaire
Les
deux
2: Ne pas utiliser les mots de passe système et autres paramètres
de sécurité par défaut définis par le fournisseur Les
deux
3: Protéger les données du titulaire stockées Les
deux
4: Crypter la transmission des données du titulaire sur les réseaux
publics ouverts Client
5: Protéger tous les systèmes contre les logiciels malveillants et
mettre à jour régulièrement les logiciels anti-virus ou
programmes
Client
6: Développer et gérer des systèmes et des applications sécurisés Les
deux
7: Restreindre l’accès aux données du titulaire aux seuls
individus qui doivent les connaître
Les
deux
8: Identifier et authentifier l’accès aux composants du système Les
deux
9: Restreindre l’accès physique aux données du titulaire CSP
10: Effectuer le suivi et surveiller tous les accès aux ressources
réseau et aux données du titulaire
Les
deux

11: Tester régulièrement les processus et les systèmes de sécurité Les
deux
12: Maintenir une politique qui adresse les informations de
sécurité pour l’ensemble du personnel
Les
deux
Tableau 5 : Partage de responsabilité pour chaque exigence.
Exigences PCI DSS Considérations communes IaaS
1: Installer et gérer une
configuration de pare-feu
pour protéger les données du
titulaire
IaaS: Typiquement, la sécurité du réseau est
une responsabilité partagée: le client est
responsable de la sécurisation des réseaux au
sein et entre leurs propres environnements,
tandis que le CSP offre la sécurité du réseau au
niveau du périmètre de nuages et entre les
clients du CSP. Le CSP gère les pare-feu sur le
réseau de CSP-gérés et les pare-feu et non
d'infrastructure visibles pour le client de Cloud.
Tout pare-feu au-dessus de la couche de
l'infrastructure peuvent être le responsabilité du
client de Cloud. Les pare-feu de CSP gérés
peuvent également être partagés par plusieurs
clients de nuages.
Client et
CSP
2: Ne pas utiliser les mots de
passe système et autres
paramètres de sécurité par
défaut définis par le
fournisseur
IaaS: Configuration sécurisée de l'OS et des
applications est généralement la responsabilité
du client tandis que la configuration sécurisée
des appareils sous-jacents est de la
responsabilité du CSP. Il peut y avoir être aussi
des périphériques virtuels que le client est
responsable du maintien.
Client et
CSP
3: Protéger les données du
titulaire stockées
IaaS et PaaS: Le client est généralement
responsable de la manière informations qui est
fixé (comme l'utilisation de mécanismes de
chiffrement) et dans quel format pour- par
exemple, fichiers plats, bases de données
entrées, etc. Emplacements physiques des
magasins de l'information peuvent être
inconnus pour le client, et peuvent avoir besoin
d'être identifié emplacements de stockage.
Données rétention est défini par le client;
toutefois, le CSP contrôle les zones de stockage
réels. L'utilisation de contrôles pour prévenir la
rétention involontaire ou supplémentaires (par
exemple, par l'intermédiaire instantanés, les
Client et
CSP

sauvegardes, etc.) doivent également être pris
en considération.
4: Crypter la transmission
des données du titulaire sur
les réseaux publics ouverts
IaaS et PaaS: Typiquement mécanismes de
transmission sont commandés par le client
tandis que le la technologie sous-jacente est
géré par le CSP; toutefois, cela dépendra des
technologies en usage. Contrôle pour prévenir
la transmission involontaire de données en
dehors de environnement client sont
généralement mis à jour par le DSP, en fonction
du particulier service. Le client doit être
conscient de la façon dont les données sont
transmises entre les composants dans Afin
d'assurer que les données sont cryptées pour
toutes les transmissions sur des canaux non-
privés. Cette peut comprendre des émissions
dans l'environnement propre au client (par
exemple, entre client VM).
Client
5: Protéger tous les systèmes
contre les logiciels
malveillants et mettre à jour
régulièrement les logiciels
anti-virus ou programmes
IaaS: Protection de l'OS et le client VM est
généralement la responsabilité du client. Anti-
mises à jour antivirus appliquent à l'OS hôte
ainsi que toute VM dans l'environnement client
exécutant leur propre OS. Il peut aussi y avoir
des périphériques virtuels que le client est
responsable de tenir à jour. La protection anti-
malware pour les appareils sous-jacente /
infrastructures reste de la responsabilité du
CSP.
Client
6: Développer et gérer des
systèmes et des applications
sécurisés
IaaS: Patcher et la maintenance de l'OS et les
applications sont généralement à la
responsabilité du client, tout en rapiéçage et la
maintenance des dispositifs sous-jacents reste le
responsabilité du CSP. Il peut aussi y avoir des
périphériques virtuels que le client est
responsable pour le maintien. Codage sécurisé
est typiquement de la responsabilité du client
(ils peuvent soit utiliser leurs propres
applications ou choisir des applications
commerciales sécurisées).
Client et
CSP
7: Restreindre l’accès aux
données du titulaire aux seuls
individus qui doivent les
IaaS et PaaS: En général, le client est
responsable de définir l'accès à des fichiers de
données Hwy. Emplacement physique des
Client et
CSP

connaître magasins de l'information pourrait être inconnu
du client et peut avoir besoin à identifier. Le
CSP contrôle les zones de stockage physiques
et CSP gérés les contrôles d'accès sont souvent
cumulatifs aux commandes définies par le
client. L'utilisation de contrôles pour empêcher
l'accès involontaire aux données (par exemple,
pour les données saisies par l'intermédiaire des
clichés, sauvegardes, etc.) doivent également
être considérés.
8: Identifier et authentifier
l’accès aux composants du
système
IaaS et PaaS: Le client est responsable pour
assurer que tous les comptes sous contrôle Hwy
utiliser des identifiants uniques et
l'authentification forte. Le CSP est chargé de
veiller à forte authentification est utilisée pour
l'infrastructure sous-jacente. Par rapport au
modèle IaaS, le CSP conserve les droits d'accès
administratif important dans Modèles SaaS et
PaaS.
Client et
CSP
9: Restreindre l’accès
physique aux données du
titulaire
Tous les modèles de service: En général gérés
par le service CSP pour tous les modèles. Le
client a rarement accès physique aux systèmes
de Cloud Computing ; et le CSP pourrait
permettre pas sur place visites ou audits client.
Cela dépendra de la CSP particulier, ainsi que
la distribution de données à travers différents
endroits; les clients ne peuvent pas savoir à
quel endroit abrite leur donnée.
CSP
10: Effectuer le suivi et
surveiller tous les accès aux
ressources réseau et aux
données du titulaire
IaaS et PaaS: Le CSP Gère Typiquement
surveillance et la journalisation pour sous-
jacente dispositifs et des infrastructures, y
compris les hyperviseurs, alors que le client est
responsable de le suivi et l'exploitation
forestière au sein de leurs propres
environnements virtuels. La capacité à associer
divers fichiers journaux afin de reconstituer les
événements peuvent nécessiter corrélation entre
client- journaux contrôlés et ceux contrôlés par
le CSP. Certaines activités de surveillance
peuvent être intégrées à l'entente de service
pour le CSP à gérer le compte de clients.
Détails de ce que les données seront saisies et
ce seront faits à la disposition du client devra
Client et
CSP

être défini.
11: Tester régulièrement les
processus et les systèmes de
sécurité
IaaS et PaaS: Généralement Testing est géré
par celui qui a le contrôle du particulier aspect
de l'environnement. Cependant, les CSP peut
interdire les tests de client, dans ce cas, peuvent
avoir besoin les clients de compter sur le CSP.
Si le CSP effectue des balayages, le client doit
vérifier quelles instances / VM sont couverts.
IDS / IPS ne peut être fourni par le CSP. En
général, le client peut utiliser FIM pour
surveiller leurs propres environnements virtuels
(y compris données, les applications et les
journaux), tandis que la surveillance des
fichiers système / de l'appareil est géré par le
CSP.
Client et
CSP
12 Maintenir une politique
qui adresse les informations
de sécurité pour l’ensemble
du personnel
Tous les modèles de service: Bien que le CSP
et le client peut définir de procédures
convenues (pour par exemple, dans le SLA),
chaque partie conserve leurs propres politiques
de sécurité et interne procédures. Rôles et
responsabilités définis, la formation et la
sécurité des personnelles exigences sont de la
responsabilité de chaque partie pour leur
personnel respectif. Les clients doivent veiller à
ce que les politiques et procédures CSP sont
appropriées pour le Les besoins en matière de
risque et de sécurité du client. réponse à
l'incident en particulier nécessite une
sensibilisation et la coordination entre les deux
parties.
Client et
CSP

Tableau 6 : Exemple de partage de responsabilité pour chaque exigence.
Responsa
bilité Couverture
spécifique
Couverture
spécifique
Comment et
quand le CSP
Exigence PCI DSS
(CSP
seul,
client
In-scope
client In-scope CSP
fournira la
preuve de la
seul, ou
partagé)
Responsabilit
é
Responsabilit
é
conformité à la
clientèle
1.1 Inspecter les normes de
configuration de pare-feu et
de routeurs et autres
documents spécifiés ci-
dessous pour vérifier que les
normes sont complètes et
mises en œuvre comme suit :
1.1.1 Processus formel
d’approbation et de test de
toutes les connexions
réseau et des modifications
in-scopes aux
configurations des pare-feu
et des routeurs
1.1.1 Processus formel
d’approbation et de test de
toutes les connexions
réseau et des modifications
in-scopes aux
configurations des pare-feu
et des routeurs
1.1.2 Diagramme du réseau
actuel qui identifie toutes
les connexions entre
l’environnement de

données du titulaire et les
autres réseaux, y compris
tout réseau sans fil
3.7 Défis de conformité :
Le stockage, le traitement ou la transmission de données de titulaire de carte dans le Cloud
signifie que cet environnement de Cloud est dans-le-champs pour la norme PCI DSS, et il
peut être difficile de valider la conformité PCI DSS pour une infrastructure dynamique et
distribuée: comme un Cloud public ou autre partagé.
• Les architectures distribuées des environnements de Cloud ajoutent des couches de
technologie et de complexité qui remettent en question les méthodes d'évaluation
traditionnelles :
• Des exemples de défis de conformité comprennent, mais ne sont pas limités à:
Les clients peuvent avoir ou pas de visibilité sur l'infrastructure sous-jacente
du CSP et des contrôles de sécurité liés.
Les clients peuvent avoir le droit à la surveillance ou le contrôle sur le
stockage des données des titulaires de cartes ou ne pas avoir. Les organisations
ne peuvent pas savoir où les données des titulaires de cartes sont physiquement
stockées car l'emplacement (s) peut changer régulièrement. Pour la redondance
ou pour des raisons de haute disponibilité, des données peuvent être stockées
dans des emplacements multiples à un moment donné.
Certains composants virtuels ne possèdent pas le même niveau de contrôle
d'accès, les logs d’audit, et de suivi que leurs homologues physiques.
Les limites de périmètre entre les environnements clients peuvent être fluides.
Les environnements de Cloud public sont généralement conçus pour permettre
l'accès à partir de n'importe où sur Internet.
Il peut être difficile de vérifier qui a accédé aux données des titulaires de
cartes, traitées, transmises ou stockées dans la environnement de Cloud.
Il peut être difficile de recueillir, corréler, et / ou archiver tous les journaux
nécessaires pour répondre aux exigences PCI DSS.
Les organisations qui utilisent des outils de découverte de données pour
identifier les données des titulaires de cartes dans leur environnement, et
d'assurer que ces données ne sont pas stockées dans des endroits inattendus,
peuvent trouver que l'exécution de ces outils dans un environnement de Cloud
Computing peut être difficile et entraîne des résultats incomplets. Il peut être
difficile pour les organismes de vérifier que les données de titulaire carte ne
sont pas "fuites" dans le Cloud.
De nombreux grands fournisseurs peuvent ne pas soutenir le droit à la
vérification par leurs clients. Les clients doivent discuter leurs besoins avec le

fournisseur afin de déterminer comment le CSP peut fournir l'assurance que les
contrôles nécessaires sont en place.
• L’utilisation d'un CSP compatible PCI DSS ne résulte pas que les clients sont en
conformité PCI DSS. et le client est également l'ultime responsable de la sécurité
quotidienne de l’externalisation de CHD.
En ce qui concerne l'applicabilité de la conformité d'une partie à l'autre, envisager les
mesures suivantes:
a) Si un CSP est conforme, cela ne signifie pas que leurs clients le sont.
b) Si les clients d'un CSP sont conformes, cela ne signifie pas que le CSP l’est.
c) Si un CSP et le client sont conformes, cela ne signifie pas que tous les autres clients
le sont.
• Le client doit assurer que les services de son côté qui doivent être conformes aux
exigences le sont vraiment : Par exemple le client doit assurer que l’antivirus est
installé et est mis à jour dans les systèmes de son côté utilisés pour se connecter au
Cloud.
3.8 Définir d'utilisation appropriée des outils de gestion :
Les outils de gestion permettent aux administrateurs d'effectuer des fonctions telles que :
• Les outils de système de sauvegarde, de restauration, la connectivité à distance, la
migration et des changements de configuration des systèmes virtuels.
• Les outils de gestion pour les composants faisant partie du champ seraient également
considérés in-scope : Il faut définir les outils in-scope.
• Séparer les rôles et responsabilités pour les outils de gestion.
• Surveiller et enregistrer l'utilisation des outils de gestion.
Ces outils doivent être inventoriés et on doit étudier leurs impacts sur la sécurité si elles sont
compromises.
3.9 Etablir des politiques et des procédures pour chaque exigence de sécurité PCI DSS,
ainsi que la gestion des rapports.
3.10 Considérations et recommandations pour l’environnement Cloud déployé :
• Elaborer un scénario de déploiement de deux sites e-commerce qui respectent les
éléments suivants :-Veiller à ce que ces deux environnements CDE des deux clients
seront séparés par des moyens technologiques, comme s’ils l’étaient physiquement. Et
qu’ils soient séparés pour isoler les composants CDE des composants non CDE afin de
réduire le scope PCI DSS.
• Isolement des données qui sont stockées.
• Tous les systèmes ou composants partagées par les environnements clients, y compris
les systèmes d'hyperviseurs sous-jacents, ne doivent pas fournir un chemin d'accès
entre les environnements.

• Une fois qu’une couche de l'architecture en nuage est partagée par les environnements
CDE et non-CDE, la segmentation devient de plus en plus complexe : Les données
non-CDE doivent être dans des hyperviseurs séparés. Cette complexité ne se limite pas
aux hyperviseurs partagés; toutes les couches de l'infrastructure qui peuvent fournir un
point d'entrée à un environnement CDE doivent être incluses lors de la vérification
segmentation.
• Il faut déterminer les couches partagées.
• Il faut dresser un tableau qui regroupe les composants de l’environnement virtuels, et
comment le client ou le CSP responsable assure son rôle de segmentation.
3.10.1 Considérations de segmentation :
En dehors d'un environnement de Cloud Computing, les environnements clients particuliers
doivent normalement être physiquement séparés l'un de l'autre, sur le plan organisationnel, et
sur le plan administratif. Les clients qui utilisent un Cloud public ou partagé doivent
autrement compter sur le CSP à veiller à ce que leur environnement est suffisamment isolé
des autres environnements clients.
Exemples de contrôles à considérer lors de l'évaluation des options de segmentation
comprennent, mais ne sont pas limités à:
• Les firewalls physiques et la segmentation du réseau au niveau de l'infrastructure.
• Les firewalls au niveau de l'hyperviseur et de VM.
• Le zonage VLAN, en plus de pare-feu.
• Des IPS au niveau de l'hyperviseur et / ou au niveau des VM qui détectent et bloquent
le trafic indésirable.
• Outils informatiques de prévention des pertes de données au niveau de l'hyperviseur et
/ ou au niveau VM.
• Des contrôles pour empêcher les communications hors-bande qui se produisent via
l'infrastructure sous-jacente.
• L'isolement des processus communs et des ressources du milieu des clients.
• Magasins de données segmentés pour chaque client.
• L'authentification forte à deux facteurs.
• La séparation des fonctions et la supervision administrative.
• Enregistrement continu et surveillance du trafic de périmètre, et réponse en temps réel
• Tracer une politique pour faire des frontières entre les clients, et entre le client et le
CSP, et entre le client et le réseau internet.
• Il faut demander d’isoler les services compatibles PCI DSS des services non
compatibles.
• Remédier au problème de communications-out-of-band
• L'évaluateur PCI DSS doit valider l'efficacité de la segmentation pour garantir qu'il
fournit un isolement adéquat.
• Le client doit avoir le droit de tester dans le réseau du CSP que l’isolement des
frontières entre les clients, ou entre le client et le CSP, ou entre le client et le réseau
internet sont établis. Si le fournisseur n’accepte pas, le client y sera dépendant.

Scénario Description de l'environnement
Orientations de in-scope
PCI DSS
Cas 1: Tierce-partie CSP
hébergeant un Cloud public
compatible "PCI DSS"
prenant en charge plusieurs
clients, avec une
segmentation validée pour
les environnements clients.
*Les machines virtuelles peuvent
être sur un ou plusieurs
hyperviseurs, tous les
hyperviseurs et les machines
virtuelles sont configurés par CSP
pour soutenir les exigences PCI
DSS.
*Plusieurs clients hébergés sur
chaque hyperviseur.
*Une segmentation validée des
environnements clients utilisant
une combinaison de contrôles
physiques et logiques.
Le CSP est responsable de
la
conformité de tous les
éléments du service de
Cloud fourni. La in-scope
de chaque client inclurait
leur propre environnement
(par exemple, les machines
virtuelles, applications, etc.)
et tous les autres éléments
qui ne sont pas gérés par le
CSP. La segmentation doit
être validée comme offrant
une isolation efficace entre
les clients dans le cadre de
la validation de la CSP, et
peut nécessiter une
validation supplémentaire
dans le cadre de la
validation de chaque client.
Cas 2: Tierce-partie CSP
hébergeant un Cloud public
compatible "PCI DSS"
prenant en charge plusieurs
clients, pas de segmentation
client.
*Les machines virtuelles peuvent
être sur un ou plusieurs
hyperviseurs, tous les
hyperviseurs sont configurés par
le CSP pour soutenir les
exigences PCI DSS.
*Plusieurs clients hébergés sur
chaque hyperviseur, la
configuration VM gérée par
chaque client.
*Segmentation entre les
environnements des clients ne
sont pas vérifiées.
Le service Cloud en entier
et tous
les Environnements clients
sont in-scope. Notez que la
validation de la conformité
PCI DSS peut être
intraitable et infaisable
quand chaque
environnement client aurait
besoin d'être inclus dans
l'évaluation.
3.10.2 Recommandations pour les environnements en mode mixte
Il est fortement recommandé (et un principe de sécurité de base) que les machines virtuelles
de différents niveaux de sécurité ne soient pas hébergées sur le même hyperviseur ou même
hôte physique; la préoccupation principale étant qu'une VM avec des exigences de sécurité
inférieurs auront des contrôles de sécurité moindre, et peuvent être utilisées pour lancer une
attaque ou donner accès à des machines virtuelles plus sensibles sur le même système.

• Il est fortement recommandé que les machines virtuelles dans-le-champ et hors-du-
champ ne soient pas hébergées sur le même hyperviseur ou même hôte physique;
• Pour que les machines virtuelles en in-scope et hors de in-scope coexistent sur le
même hôte ou hyperviseur, les machines virtuelles doivent être isolées les unes des
autres de telle sorte qu'ils peuvent effectivement être considérées comme un matériel
distinct sur les différents segments de réseau sans la connectivité de l’une à l'autre.
3.10.3 Considérations de scoping :
• Les recommandations pour réduire et simplifier les normes PCI DSS à in-scope dans
un environnement de Cloud Computing comprennent:
Ne pas stocker, traiter ou transmettre des données de cartes de paiement dans le
Cloud. Ceci est le moyen le plus efficace pour maintenir un environnement Cloud
hors de in-scope, car les contrôles PCI DSS ne seront pas nécessaires s’il n'y a pas
de données de cartes de paiement à protéger.
Mettre en œuvre une infrastructure physique dédiée qui est utilisée seulement pour
l'environnement Cloud dans la in-scope.
• Veiller à ce que les données du compte en texte clair ne sont jamais accessibles dans le
Cloud peut également aider à réduire le nombre d’exigences PCI DSS applicables à
l'environnement de Cloud.
• Il faut déterminer les exigences PCI DSS qui sont in-scope pour le CSP.
• Identifier les composants virtuels qui sont in scope pour PCI DSS dans notre cas ?
• Dresser un tableau qui décrit :
Les composants qui sont in-scope validés et non validés.
L’exigence qui concerne le composant.
La date d’obtention de validation
3.10.4 Composants systèmes virtuels et le scoping :
Hyperviseur :
Orientation in-scope: Si un composant virtuel connecté à (ou hébergé sur) l'hyperviseur est à
in-scope pour la norme PCI DSS, l'hyperviseur lui-même sera toujours à in-scope.
Machine virtuelle :
Orientation in-scope: Un ensemble de VM sera à in-scope si elle stocke, traite ou transmet
des données de titulaire, ou si elle se connecte ou fournit un point d'entrée au CDE. Si une
machine virtuelle n’est dans la in-scope, à la fois le système hôte sous-jacent et l'hyperviseur
seraient également considérés in-scope, car ils sont directement reliés à et ont un impact
fondamental sur le fonctionnement et la sécurité de la machine virtuelle.
Application virtuelle :
Orientation in-scope: Les applications virtuelles utilisées pour se connecter ou fournir des
services à un système in-scope des composants ou des réseaux seraient considérés dans le
champ. Toute VSA / SVA qui pourraient influer sur la sécurité du CDE serait également
considérée comme in-scope.

Switch ou routeur virtuel :
Orientation in-scope: Réseaux provisionnés sur un commutateur virtuel basé sur
l'hyperviseur sera in-scope si approvisionné avec un composant dans le champ ou si elles
fournissent des services ou se connecter à un dans le champ composant. Les dispositifs
physiques d'hébergement commutateurs virtuels ou des routeurs seraient considérés dans le
champ si l'un des composants hébergés se connecte à un réseau dans le champ.
3.11 Planning des documents que le client doit demander au CSP :
La liste des documents que le client doit avoir de son CSP :
• Le client doit envoyer un document qui demande au CSP les exigences qui ont
été validées et celles non validées. (Il faut envoyer une lettre)
• Les Clients doivent demander à leurs CSP de leur fournir une assurance
continue que les exigences sont toujours respectées,
• Demander les documents applicables pour- par exemple, les journaux d'audit
montrant tous les accès aux données des clients.
• Le Client doit savoir les détails précis applicables aux méthodes de maintien en
cours de la conformité PCI DSS. Par exemple, selon le service fourni, le CSP
peut avoir besoin de produire des copies de fichiers journaux, les dossiers de
mise à jour de patch, ou l’ensemble de règles pare-feu applicables
spécifiquement à un l'environnement de chaque client. (Il faut trouver d’autres
choses à ajouter)
• Il faut que le CSP donne tous les documents nécessaires qui expliquent
clairement les parties des services qui ont été validées et celle qui n’ont pas été
validées.
• Si le CSP fournit au client les documents qui justifient que son QSA l’a certifié
PCI DSS pour les composants systèmes qui rentrent dans son périmètre (IaaS),
le QSA du client doit s’appuyer sur les documents du CSP et compléter la
validation des autres composants virtuels qui rentrent dans le périmètre du
client, vérifier que la validation CSP est encore valable à partir de la date.
• Les CSP qui ont subi une évaluation PCI DSS indépendante pour valider leur
conformité auront les résultats résumés dans une attestation de conformité
(AOC) et détaillés dans un rapport sur la conformité (ROC).
• Citer tous les accords et documents qui doivent être établis entre le client et le
CSP.
• Preuve de la documentation de conformité (comme l'AOC et les articles
applicables de la ROC), y compris la date de l'évaluation de la conformité
• Des preuves documentées des composants systèmes et des services qui ont été
inclus dans l’évaluation de la norme PCI DSS
• Des preuves documentées de composants système et des services qui ont été
exclus de la norme PCI DSS l'évaluation, le cas échéant au service
• Etudier les rapports PCI DSS du CSP: quels services et composants du système
sont validés pour chaque exigence (Par exemple, les exigences PCI DSS 6.1 et

6.2 portent sur la nécessité que les vulnérabilités doivent être identifiées, selon
leur indice et selon le risque, et corrigées en un temps minime. Si pas
correctement défini, un client pourrait supposer que le CSP gère ce processus
pour tout l'environnement Cloud, alors que le CSP pourrait gérer uniquement
les vulnérabilités de son infrastructure sous-jacente, en supposant que le client
gère des vulnérabilités des systèmes d'exploitation, des applications et des sites
web (pour e-commerce)).
3.12 Considérations de sécurité :
Bien que l'utilisation des services de Cloud Computing peut fournir une opportunité
intéressante pour les organisations de toutes tailles, les organisations doivent également être
conscientes des risques et défis associés à un choix de Cloud particulier avant de passer leurs
données ou services sensibles dans l’environnement de Cloud. Cette section explore certaines
de ces considérations de sécurité supplémentaires.
• Le client est responsable de la bonne configuration de tout contrôle de segmentation
mis en œuvre au sein de leur propre environnement (par exemple, en utilisant des
pare-feu virtuels pour séparer le dans-le-champ VM de l'extérieur-du-champ VM), et
pour veiller à ce qu’une isolation efficace est maintenue entre dans les composants in-
scope et hors-champ.
• Considérations pour le client peuvent inclure:
Combien de temps le CSP a été conforme PCI DSS? Quand est ce qu’était leur
dernière validation?
Quels sont les services spécifiques et les exigences PCI DSS ont été incluses
dans la validation?
Quelles sont les installations et les composants systèmes spécifiques qui ont
été inclus dans la validation?
Y a-t-il des composants système que le CSP repose sur pour la prestation du
service qui n’était pas inclus dans la validation PCI DSS?
Comment les CSP garantissent que les clients qui utilisent le service conforme
PCI DSS ne peuvent pas présenter des composants non conformes à
l'environnement ou même peuvent contourner des contrôles PCI DSS?
• Bâtir une structure solide de gouvernance et de gestion de risques, qui est partagée
entre le client et le CSP.
• Elaborer une stratégie de gouvernance claire (COBIT).
• Le CSP doit être conscient des éléments de services côté client qui peuvent impacter
sa compatibilité PCI DSS.
• Il faut avoir une stratégie claire de gouvernance partagée entre le client et le CSP.
3.12.1 Gestion de risque :
Les services de Cloud externalisés doivent être évalués par rapport aux critères de risque
d'une organisation dans le but de l'identification des actifs critiques, analyse les vulnérabilités
et les menaces potentielles à ces actifs, et l’élaboration d'une stratégie d'atténuation des
risques appropriée (Voir Exigences PCI DSS 12.1.2).

• (Appliquer les consignes du document « Risk acessement for PCI DSS » en utilisant
des outils dédiés.)
• Les formes traditionnelles de l'évaluation des risques peuvent notamment ne pas
prendre en considération les caractéristiques du Cloud, et peut donc nécessiter des
procédures nouvelles ou modifiées.
• Développer un plan de continuité de service BCP et reprise après sinistre DR.
• Le client doit avoir la capacité d’effectuer des tests de capacités BCP et DR et / ou
d'observer les résultats des tests effectués par le CSP.
• L'évaluation des risques doit identifier si des contrôles supplémentaires sont
nécessaires pour assurer et protéger les données des titulaires de carte et autres
informations sensibles dans un environnement virtuel.
3.12.2 Evaluer les risques associés aux technologies de virtualisation :
• Le flux et le stockage des données des titulaires de cartes doivent être correctement
documentés dans le cadre du processus d'évaluation des risques pour veiller à ce que
toutes les zones de risque sont identifiées et atténuées de manière appropriée.
• Si un composant fonctionnant sur un hyperviseur est dans la in-scope, il est
recommandé que tous les composants que l'hyperviseur soient considérés in-scope,
ainsi, y compris, mais sans s'y limiter, les machines virtuelles, les applications
virtuelles, et plug-ins de l'hyperviseur
• Les vulnérabilités dans l'environnement physique s’appliquent dans l’environnement
virtuel et s’y ajoutent d’autres vulnérabilités.
• Les attaques liées à l’hyperviseur :
Lui appliquer une configuration sécurisée, choisir l’hyperviseur avec plus de
choix de contrôles de sécurité.
L'hyperviseur crée une nouvelle surface d'attaque qui n’existe pas dans le
monde physique.
Mettre un plan d’action pour remédier aux problèmes de faiblesses dans la
technologie d'isolation de l'hyperviseur, contrôles d'accès, renforcement de la
sécurité, et mises à jours.
Ne pas garder la configuration out-of-the-box car elle n’est pas la plus
sécurisée.
Il est essentiel que l'accès à l'hyperviseur soit limité en fonction du moindre
privilège et la nécessité de savoir, et que la surveillance indépendante de toutes
les activités soit appliquée.
Les hyperviseurs ne sont pas créés égaux, et il est particulièrement important
de choisir une solution qui prend en charge les fonctions de sécurité requises
pour chaque environnement.
• Empêcher les communications intra-hôtes : Les machines virtuelles peuvent
transmettre des données entre eux à travers l'hyperviseur, ainsi que sur des connexions
de réseaux virtuels et à travers les applications virtuelles de sécurité de réseau tels que
les pare-feu virtuels.

• Le compromis d'une fonction virtuelle du système pourrait conduire à un compromis
d'autres fonctions sur le même système physique.
• Imposer la séparation des processus entre les différentes fonctions.
• Dans le contexte virtuel, une VM de confiance inférieure aura typiquement moins de
contrôles de sécurité que les machines virtuelles des niveaux de confiance plus élevés.
• Théoriquement, les machines virtuelles de différents niveaux de confiance sur le
même hôte ou hyperviseur peuvent réduire la sécurité globale pour tous les
composants à celle du composant le moins protégé (également connu sous le nom –la
sécurité est aussi forte que la fonction la plus faible).
• Le risque de mélange des données sensibles avec les données de confiance plus faible
doit être soigneusement évalué.
• La séparation appropriée des fonctions est cruciale dans un environnement virtuel.
3.12.3 Identifier les menaces :
• Identifier les menaces spécifiques aux technologies de virtualisation : exp ; menaces
de l'hyperviseur et communications out-of-band
3.12.4 Identifier les vulnérabilités :
Identifier les vulnérabilités spécifiques aux technologies de virtualisation
• Les vulnérabilités ne sont pas limitées à des questions techniques. Les failles sont dans
les processus opérationnels, l’insuffisante de formation du personnel, le manque de
control de surveillance, et des lacunes dans la sécurité physique sont des exemples
d'autres domaines où les vulnérabilités potentielles peuvent exister et être exploitées.
• Les organisations qui utilisent la virtualisation doivent évaluer leur environnement
particulier, évaluer les risques associés et identifier les contrôles appropriés pour
régler ce risque.
• Utiliser les méthodologies et outils d'évaluation de risques acceptés par l'industrie
disponibles pour aider à guider le processus d'évaluation des risques.
3.13 Installations et accès physique :
Les services Cloud ne sont «nuage» que dans le concept. En réalité, les services de Cloud
impliquent des ressources physiques situés dans l’environnement CSP qui sont accessibles à
distance à partir de l'environnement du client. Les contrôles pauvres de sécurité physique dans
une installation de CSP peuvent exposer les données de nombreux clients à des risques
inutiles, et les pauvres contrôles environnementaux peuvent influer sur les performances et
l'intégrité de la prestation de service.
• Les contraintes pour un Cloud public : 1- Le CSP pourra ne pas donner accès au QSA
du client pour accéder à leurs locaux physiques, et il a le droit.

• Lors de l'utilisation d'un Cloud public, différents éléments de l'environnement, tels que
les machines virtuelles, les hyperviseurs, et les périphériques réseau virtuels, etc.,
peuvent être souvent déménagés en fonction de la stratégie d'équilibrage de charge du
CSP.
• Utiliser des mécanismes et procédures afin de savoir où se trouvent les données CDE
en temps réel, à cause de la mobilité continue des machines virtuelles, des
hyperviseurs, et des périphériques réseau virtuels, etc… soit des outils informatiques,
soit des rapports rédigés par le CSP.(voir l’offre de AWS et Google concernant les
zones géographiques)
• Par exemple, l'infrastructure du CSP peut entraîner le déplacement de données ou son
stockage dans des pays politiquement ou économiquement instables.
• Il faut comprendre les juridictions du pays où se trouvent les données dans le temps
réel. (Cas du Maroc, loi 09/08)
• Restreindre l'accès physique : l'hébergement de plusieurs composants sur un seul
système physique pourrait accroître considérablement l'impact potentiel si un
attaquant a eu un accès physique à ce système hôte.
• Veiller à ce que toutes les interfaces physiques inutilisés sont désactivées, et que
l’accès physique ou au niveau de la console est restreint et surveillé.
3.14 Considérations sur la sécurité des données :
• Il est recommandé que les besoins de sécurité de données soient évalués pour toutes
les informations dans le Cloud et non seulement CHD. Par exemple, les données
opérationnelles, les politiques et procédures de sécurité, configurations de système, et
documents des normes, les fichiers journaux, les rapports d'audit, les informations
d'authentification, clés de chiffrement, les plans de réponse aux incidents, et
coordonnées employés sont quelques-uns des types de données avec différents
exigences de sécurité qui peuvent avoir besoin d'être pris en considération.
• Il faut documenter où sont situées les données des titulaires de cartes et comment
traversent-ils l'infrastructure (voir Exigences PCI DSS 1.1.2).
• Un accès potentiel de l'hyperviseur aux données en mémoire doit également être pris
en considération, veiller à ce que les contrôles d'accès définies par le client ne sont pas
involontairement contournées par le personnel administrateur du CSP.
3.14.1 Images et clichés instantanés :
Les images et les clichés instantanés des machines virtuelles fournissent un moyen rapide de
déployer ou restaurer les systèmes virtuels dans un court laps de temps. Une attention
particulière doit être accordée à la préparation d'images et de clichés VM, car ils peuvent
capturer des données sensibles présentes sur le système au moment où l’image a été prise, y
compris le contenu de la mémoire active.
• Une attention particulière doit être accordée à la préparation d'images et de clichés
VM, car un intrus peut capturer des données sensibles présentes sur le système au
moment où l’image a été prise, y compris le contenu de la mémoire active.

• Sécuriser les images systèmes contre les modifications par un hacker.
• Chercher les bonnes solutions de surveillance et journalisation des composants virtuels
(les réseaux virtuels, les pare-feu virtuels, les applications systèmes virtuelles).
• Idéalement, les capacités de virtualisation sur tous les trois plans de l'exploitation de
l'infrastructure réseau doivent fournir des contrôles et des fonctionnalités pour
sécuriser l'infrastructure virtuelle à un niveau équivalent à des dispositifs physiques
individuels. Quelles sont les mesures et composants à mettre en place pour empêcher
les fuites de données entre les segments réseaux?
• Les fuites d'informations entre les composants virtuels peuvent se produire lorsque
l'accès aux ressources partagées permet à un composant de collecter des informations
sur un autre composant sur le même hôte
• Chercher quelles sont les méthodes de fuites de données entre composants physiques
(accès mémoire, CPU, réseau, etc.) et comment y remédier ?
• Des environnements où les clients exécutent leurs applications dans des images
systèmes distinctes, le stockage des donnée doit se faire dans des partitions logiques
distinctes en utilisant des bases de données séparées, et ne partagent pas le stockage
sur le même disque ou autres ressources, deux réseaux distincts, et en utilisant des
mesures de sécurité connues.
• En plus de la gamme connue des emplacements de stockage destinés, les données
peuvent également être présentes dans d'autres systèmes CSP utilisés pour l'entretien
de l'infrastructure Cloud, tels que les images de VM, les sauvegardes, les journaux de
surveillance, la mémoire et ainsi de suite.
• Des outils et des processus spécialisés peuvent être nécessaires pour localiser et gérer
les données archivées, off-line, les images relocalisées.
3.14.2 Machines dormantes ou inactives :
• Mettre en place un processus de gestion des machines dormantes ou inactives.
• Si une machine dormante ou inactive doit être reprise en service, il faut éliminer ses
vulnérabilités, et lui appliquer toutes les politiques de sécurité avant qu’elle soit active
de nouveau.
• Utiliser des contrôles de sécurité supplémentaires basés sur l'hôte pour surveiller et
contrôler le trafic VM-VM.
• Choisir les meilleures solutions de sécurité qui n’impactent pas la performance des
processeurs et mémoires dans le Cloud.
• Planifier les scans et les mises à jour dans des intervalles de temps décalées afin de ne
pas entraîner une extrême charge sur le système sous-jacent et réduire la performance
globale de toutes les machines virtuelles hébergées.
• Les VM inactives contenant les données de cartes de paiement peuvent devenir
inconnus, des magasins de données non garantis, qui sont souvent seulement
redécouvert dans le cas d'une violation de données.
• Les clients doivent également examiner comment le CSP gère les VMs déconnectées
ou machines virtuelles inactives, et si les VM dans-le-champ et hors-du-champ

probablement peuvent être stockés ensemble par le CSP sans contrôles de
segmentation actifs.
• Parce que les machines virtuelles dormantes ne sont pas activement utilisées, elles
peuvent facilement être négligées et laissées hors les procédures de sécurité.
• Une VM en sommeil ne sera probablement pas mise à jour avec les derniers patchs de
sécurité, résultant que le système sera exposé à des vulnérabilités connues que
l'organisation pense les avoir déjà éliminés.
3.14.3 Reconnaître la nature dynamique des VM :
Les VMs sont effectivement juste des données qui peuvent résider dans des états actifs (sur un
hyperviseur) ou des états inactifs (N'importe où). Les VMs inactives ou dormantes sont
effectivement des données stockées qui peuvent contenir des informations sensibles et les
détails de configuration des appareils virtuels. Une personne ayant accès à une VM en
sommeil pourrait la copier et l’activer dans un autre endroit, ou ils peuvent analyser les
données de carte de paiements et autres informations sensibles.
• L'accès aux machines virtuelles inactives doit donc être limitée, surveillé, et
soigneusement contrôlé.
• Le CSP doit communiquer au client toutes les VM qui contiennent des données CDE
sensibles, leurs états, leurs emplacement, comment sont-elles protégées ?
• Valider le fournisseur de Cloud (Cloud public, IAAS) avec la norme PCI DSS
• Valider le du client (Cloud public, IAAS) avec la norme PCI DSS
• Délivrance d’une attestation de conformité (AOC)
• Délivrance d’un rapport de conformité (ROC).
• Le client est maintenant conforme PCI DSS
3.14.4 La gestion du cycle de vie des données :
Pour tous les modèles de Cloud Computing, des exigences claires pour la conservation des
données, le stockage et l'élimination sécuritaire doivent veiller à ce que les données sensibles
sont:
Conservés aussi longtemps que nécessaire,
Non retenu plus longtemps que nécessaire,
Stockées uniquement dans des endroits appropriés et sécurisés,
Accessibles seulement à ceux avec un besoin de l'entreprise,
Traitées conformément à la politique de sécurité du client
• Il faut sécuriser la transmission des données sensibles par le cryptage.
• Dans un environnement de Cloud distribué, vérifier que toutes les instances de
données des titulaires ont été supprimées en toute sécurité conformément à la politique
de rétention des données du client.
• L’élimination des données du titulaire de carte doit être effectuée en utilisant des
méthodes sûres, conformément aux exigences PCI DSS
• La méthode d'élimination doit veiller à ce que les données ne sont pas récupérables à
la fin du processus de cession.
3.14.5 Classification des données :

• Un système informatique de classification définie peut aider les organisations à
identifier les données qui sont sensibles ou confidentielles et les données ayant des
besoins de sécurité spécifiques.
3.14.6 Chiffrement des données et gestion des clés cryptographiques (HSM ou Cloud
HSM)
Dans un environnement Cloud public, les données d'un client sont généralement stockées
avec des données appartenant à plusieurs autres clients. Ce qui fait de ce Cloud public une
cible attrayante pour les attaquants, car le potentiel de gain peut être supérieure qu’en
attaquant des organisations individuellement. Un niveau de chiffrement fort de données doit
être appliqué sur toutes les données sensibles ou potentiellement sensibles stockées dans un
Cloud public. Parce que tout incident sécuritaire d'un CSP pourrait entraîner l'accès non
autorisé à de multiples magasins de données.
• Il est recommandé que les clés cryptographiques utilisées pour crypter / décrypter les
données sensibles sont stockées et gérées indépendamment du service de Cloud, où se
trouvent les données.
• Au minimum, les serveurs de gestion des clés doivent être situés dans un segment de
réseau séparé et protégé avec des références d'accès distincts des machines virtuelles
qui utilisent les clés et les données cryptées avec eux.
• Elaborer une procédure pour gérer les clés de chiffrement déchiffrement, où sont-elles
stockées, comment sont-elles archivées, les logs d’accès à ces clés.
• Seuls les définies, et les dépositaires de clés autorisés doivent avoir accès aux clés
cryptographiques.
• Les clients devront vérifier qui a accédé aux clés cryptographiques, qui a accédé aux
données chiffrées, et qui a accédé aux deux à la fois.
• Il est préférable que le client ne partage pas les clés de cryptage avec le CSP, ou
engage le CSP en tant que gardien de clé, dans un cas pareil, les détails d’autorisations
et les processus d'accès des CSP devront être examinés et vérifiés.
• Ne pas stocker ou héberger les clés cryptographiques par un tiers CSP qui accueille
aussi les données chiffrées.
• Les clients doivent choisir de conserver toutes les opérations de chiffrement
/déchiffrement et de gestion des clés dans leurs propres locaux, et n'utiliser le Cloud
public que pour le stockage des données cryptées.
• Mettre en place un processus de gestion de clés dans l’environnement Cloud public.
3.14.7 Elimination des données :
En plus de l'élimination des données, les exigences de déclassement de ressources doivent être
définies pour soutenir les clients dans les décisions futures de migrer vers un nouveau CSP.
• Mettre en place un processus d’élimination de données :
• Le CSP devrait fournir des mécanismes d'élimination des données qui fournissent une
assurance au client que toutes les données ont été correctement retirées et supprimées
à partir de l'environnement de Cloud.
• Etre sûr que les données ont été correctement retirées et supprimées à partir de
l'environnement de Cloud.

• Il faut considérer que laissant potentiellement des quantités inconnues de données
chiffrées sur les systèmes CSP après que leur convention a été résiliée est une
violation par le CSP des politiques de conservation des données.
3.14.8 Identité et gestion d’accès:
L’identification de l'utilisateur individuel et l'authentification du personnel de CSP et les
clients est essentielle pour le contrôle d'accès et la reddition de comptes.
• Mettre en place un processus et une politique de gestion d’accès des CSP et clients à
l’infrastructure Cloud IaaS public.
• Utiliser double authentification.
• Les comptes des clients et les mots de passe doivent être uniques pour chaque service.
• Les CSP doivent être en mesure de séparer les données des journaux applicables pour
chaque client sans exposer les données des journaux d'autres clients aux risques.
• Exiger les logs de tous les niveaux de l'infrastructure.
• La configuration de l'hyperviseur et l'accès est particulièrement important car il fournit
un point d'entrée unique à tous ses VM.
• Choisir un hyperviseur avec les fonctions de sécurité les plus développées dans le
marché de Cloud.
3.14.9 Introspection :
L’introspection est la fonctionnalité qui permet à l'hyperviseur de contrôler et de surveiller
chaque activité VM de l'extérieur de la VM s’appelle « introspection »
• Il faut bien profiter des fonctionnalités de l’introspection.
• Le problème avec l’introspection est qu’il ne laisse pas de traces de vérification
judiciaire au sein de la machine virtuelle elle-même.
• Avec l'introspection, les fichiers peuvent être accessibles à partir de l'intérieur de l'état
privilégié de l'hyperviseur sans laisser de traces.
• Les CSP utilisant l'introspection doivent être en mesure de fournir à leurs clients tous
les journaux d'introspection applicables pour l'environnement de ce client, y compris,
mais sans s'y limiter, les détails d'authentification, et l'accès au disque, à la mémoire,
les demandes et les appels API.
• Etablir un processus de gestion sécurisé d’introspection.
• Sécuriser les API et les interfaces web.
• Définir les systèmes clients utilisés pour accéder à l'environnement de Cloud.
• Comment sécuriser les systèmes clients utilisés pour accéder à l'environnement de
Cloud?
• Le client devra donc assurer que leurs dispositifs côté client sont fixés de manière
appropriée et protégés de l'accès physique et logique non autorisé.
• Les systèmes côté client utilisés pour l'accès aux données de titulaire de carte dans le
Cloud seraient également dans la in-scope de toutes les exigences PCI DSS
applicables.
• Les clients doivent également demander au CSP les contrôles qu'ils ont mis en place
pour veiller à ce que la posture de sécurité d'un client ne peut pas affecter la posture de
sécurité d'un autre client.

• Les clients doivent examiner comment le CSP vérifie que ses clients sont bien ceux
qu’ils disent qu'ils sont.
• Comment le CSP détecte un comportement potentiellement suspect une fois que les
clients sont à bord.
• Réponse aux incidents et enquêtes
• Les clients ont besoin de savoir l'impact sur leur environnement et / ou sur leurs
données quand un problème, un incident ou violation a eu lieu.
• Les enjeux, incidents et violations de données doivent être communiquées par le CSP
dans un temps minime.
• Les clients doivent savoir si leur CSP exige que tous les clients doivent aviser
immédiatement le CSP des infractions potentielles dans leurs environnements,
permettant au CSP de se rattraper plus rapidement pour contenir la violation et
minimiser son impact sur d'autres clients.
• Définir un processus et les délais de notification au CSP.
• Mettre une politique qui remédie au problème que les données clients soient capturés
par des tiers au cours d'une enquête de violation.
• Etablir un document qui répertorie tous les genres d’incidents qui peuvent parvenir et
leurs contremesures, essayer de rassembler le maximum.
3.14.10 Mettre en œuvre la défense en profondeur :
Dans un environnement physique, une approche de défense en profondeur englobe la
prévention, la détection, et les contrôles de sécurité adaptés est une pratique commune pour
sécuriser les données et autres actifs. Les contrôles de sécurité logiques sont généralement
appliqués au niveau du réseau, hôte, application, et couche de données, et les contrôles de
sécurité physiques sont mises en œuvre pour protéger les médias, des systèmes et installations
d’accès physique non autorisé.
• Le suivi de l'efficacité des contrôles et de la capacité à répondre rapidement et
efficacement à une violation potentielle est également d'une importance primordiale.
• Une approche de défense en profondeur comprend également la formation du
personnel et leur éducation à la bonne utilisation des actifs sensibles, l'identification
des menaces potentielles à la sécurité, et les mesures appropriées à prendre en cas de
violation.
• En outre, un environnement de défense en profondeur est bien défini et ses politiques
sont documentées, les processus et les procédures sont comprises et respectées par
tous le personnel.
• Examiner comment la sécurité peut être appliquée pour protéger chaque couche
technique.
3.14.11 Isolation des fonctions de sécurité :
Les fonctions de sécurité fournies par les machines virtuelles doivent être mises en œuvre
avec la même séparation nécessaire dans le monde physique. Il est recommandé que cette
exigence soit encore très rigoureuse forcée.

• Les fonctions de sécurité fournies par les machines virtuelles doivent être mises en
œuvre avec la même séparation des processus nécessaire dans le monde physique.
• Par exemple, les contrôles préventifs tels un pare-feu de réseau ne doit jamais être
combiné sur un seul hôte logique avec les données de carte de paiements qu’il est
configuré pour protéger.
• Les processus de segmentation du réseau et de la fonction d'agrégation des logs qui
permettraient de détecter la falsification des contrôles de segmentation du réseau ne
doivent pas être mixtes.
• Si ces fonctions de sécurité doivent être hébergées sur le même hyperviseur ou hôte, le
niveau d’isolement entre les fonctions de sécurité devrait être tel qu'ils peuvent être
considérés comme étant installé sur des machines distinctes.
3.14.12 Appliquer le moindre privilège et la séparation des fonctions :
Les comptes et informations d'identification pour l'accès administratif à l'hyperviseur doivent
être soigneusement contrôlés.
• La mise en œuvre d'authentification à deux facteurs.
• Etablir dual ou split-contrôle de mots de passe administratifs entre plusieurs
administrateurs.
• Mettre en place des processus forts de contrôle d’accès pour administration de
l’hyperviseur.
• Les contrôles d'accès doivent être évalués à la fois pour l'accès local et à distance au
système de gestion et l'hyperviseur
• Mettre en place un RBAC (Role based access controle) pour tous les composants
virtuels.
• Comme meilleure pratique, il faut restreindre l’accès administratif par fonction VM
spécifique, réseau virtuel, hyperviseur, le matériel, l'application, et stockage des
données.
3.14.13 Evaluer les technologies d'hyperviseur :
S’assurer que la sécurité de l'hyperviseur a été soigneusement testée avant le déploiement :
• Tracer une gestion de patch appropriée de l'hyperviseur.
• Identifier et mettre en œuvre des technologies qui facilitent des pratiques de sécurité
solides.
3.14.14 Solidifier l’hyperviseur :
Plates-formes de Hyperviseur doivent être déployées de manière sécurisée conformément aux
meilleures pratiques et directives de sécurité acceptées par l'industrie.

•Restreindre l'utilisation des fonctions administratives à des réseaux finaux et
dispositifs définis, tels que les ordinateurs portables ou ordinateurs de bureau
spécifiques qui ont été approuvés pour un tel accès.
• Exiger l'authentification multi-facteur pour toutes les fonctions administratives.
• Veiller à ce que tous les changements sont mis en œuvre et testés correctement.
Envisager d'exiger plus de gestion de surveillance, au-dessus et au-delà de ce qui est
nécessaire à travers le processus de changement de gestion normale.
• Les fonctions administratives distinctes, telles que les administrateurs de
l'hyperviseur, ne doivent pas posséder la capacité de modifier, supprimer ou désactiver
les journaux d'audit de l'hyperviseur.
• Envoyer les journaux d'hyperviseur à des endroits de stockage sécurisés
physiquement séparés dans le temps réel le plus possible.
• Surveillez les journaux d'audit pour identifier les activités qui peuvent indiquer une
brèche dans l'intégrité de segmentation, les contrôles de sécurité, ou les canaux de
communication entre les charges de travail.
•Séparer les tâches pour les fonctions administratives, de tel façon les informations
d'authentification pour l’hyperviseur ne donne pas accès à des applications, des
données ou des composants virtuels individuels.
•Avant de mettre en œuvre une solution de virtualisation, vérifier quels contrôles de
sécurité ces solutions offrent et comment ils minimisent le risque de compromis
d'hyperviseur.
3.14.15 Solidifier les machines virtuelles et autres composants :
Il est également essentiel que toutes les machines virtuelles individuelles sont installés et
configurés en toute sécurité et selon les meilleures pratiques et directives de sécurité de
l'industrie.
• Désactiver ou supprimer tous les interfaces inutiles, les ports, les dispositifs et les
services;
• Configurer solidement toutes les interfaces réseau virtuelles et les zones de stockage;
Établir des limites sur l'utilisation des ressources VM;
Assurer que tous les systèmes d'exploitation et applications en cours
d'exécution dans la machine virtuelle sont également solidifiés;
Envoyer les journaux à des zones de stockage séparées et sécurisées aussi
proches du temps réel que possible;
Valider l'intégrité des opérations de gestion de clés cryptographiques;
Solidifier le matériel virtuel individuel et les conteneurs de VM;
Autres contrôles de sécurité le cas échéant.
3.14.16 Meilleures pratiques pour les applications de paiement :
• Utiliser SSL / TLS lors de la transmission des données des titulaires de carte en interne
(par exemple, aux points d’entrée des données des titulaires de cartes et points de
sortie) au sein du réseau du marchand.

• En raison de la nature dynamique des environnements e-commerce et des
changements fréquents vers des sites Web et des applications Web, et comme les pare-
feu traditionnels ne peuvent pas inspecter le contenu du trafic réseau crypté, envisager
d'appliquer un pare-feu d’application web (WAF) ou une technologie supplémentaire
de détection d'intrusion.
• Suivre PA-DSS lors de l'élaboration et la mise en œuvre des applications de paiement /
achats pour aider à assurer que l'application supporte la conformité PCI DSS interne.
• Envisager d'utiliser des applications de paiement tiers qui sont en norme PA-DSS et
qui sont noté sur la liste des applications de paiement validées comme «acceptable
pour les nouveaux déploiements" (voir le site Web du Conseil PCI pour la liste
actuelle des applications de paiement validées).
Notez que certaines marques de paiement nécessitent l'utilisation d'applications de
paiement validées PA-DSS où les demandes de paiement tiers-parties sont en
cours d'utilisation. Les commerçants devraient consulter leurs acquéreurs ou les
marques de paiement pour comprendre les exigences applicables.
L'installation correcte d'une application de paiement est essentielle à la protection
des données de cartes de paiement. Le guide de mise en œuvre PA-DSS des
applications de paiement (obtenu à partir de l'éditeur de l'application de paiement)
doit être suivi lors de l'installation et la configuration de l'application de paiement
afin d'assurer que le produit est mis en œuvre d'une manière qui prend en charge la
conformité PCI DSS.
Examiner régulièrement les liens (tels que les URL, les iFrames, API, etc.) depuis
le site du marchand à une passerelle de paiement pour confirmer que les liens ne
sont pas modifiés pour rediriger vers des endroits non autorisés.
3.15 Considérations de PCI DSS pour le Cloud:
Exigences PCI DSS v3.0 déjà existantes :
Condition 1 : Installer et gérer une configuration de pare-feu pour protéger les données
Condition 2 : Ne pas utiliser les mots de passe système et autres paramètres de sécurité par défaut
définis par le fournisseur

Nouvelles considérations de sécurité de Cloud qui peuvent s’ajouter aux exigences PCI
DSS : Condition 1 et 2
Question PCI DSS Tests attendus Réponse
Oui
Oui,
avec
CCW Non S.O.
Comment est assurée la séparation
entre les clients?
• Examiner les politiques et
procédures
• Examiner les outils de séparation
mis en place.
Comment les limites sont forcées entre
les réseaux de confiance (internes au
client) et les réseaux non sécurisés
(comme les CSP, autre client, ou les
réseaux publics)?
procédures
• Définir les composants virtuels
nécessaires pour séparer les
réseaux.
Ya-t-il des pare-feu physiques ou
virtuels?
• Examiner la nature des pare-feu.
Qui gère et contrôle la configuration du
pare-feu?
• Définir par nom le personnel
responsable du contrôle du pare-
feu.
Comment sont détectés et gérés les
changements de configuration des
pare-feu et réseau ?
• Examiner le processus de gestion
de changement de configurations.
1
Est-ce que nous avons une liste
complète de tous les composants
matériels et logiciels dans cet
environnement?
• Etablir un inventaire complet des
composants physiques et virtuels
dans l’environnement Cloud.

2
Peut-on identifier les composants
actuels utilisés par un client particulier?
• Etablir une Checklist pour chaque
client contenant les composants
qu’il utilise en temps réel.
• Détecter tous les changements en
temps réel pat des outils précis.
Est-ce que les interfaces API sont
standardisées?
procédures
• Développer les interfaces API en
suivant la norme PA DSS.
Quel processus pour le
provisionnement de nouveaux
composants?
• Examiner les processus mis en
place.
Les images virtuelles ont été solidifiées
avant qu’elles soient activées?
• Examiner la procédure de
solidifications des images, VMs
inactives et dormantes.
Est-ce que les images solidifiées sont
protégées contre l’accès non autorisé?
• Appliquer des RBAC sur l’accès
aux images
• Créer des alertes suite à un accès
non souhaité.
Comment sont séparés les systèmes
classifiés hautement sécurisés des
systèmes classifiés bas sécurisés ?
• Séparer le réseau, le lieu de
stockage et le personnel qui a la
main sur les composants
hautement sécurisés du réseau, lieu
de stockage et personnel qui a la
main sur les composants bas
sécurisés.
• Définir les outils technologiques,
et les processus qui assurent cette
séparation.
Comment sont gérées les ressources
partagées (comme le processeur, la
mémoire, et le stockage) pour assurer
qu'elles ne seront pas manipulées-par
exemple par surcharge (Buffer
Overflow)-dans le but d'accéder à
d'autres environnements ou données
clients?
procédures
• Faire un test d’intrusion par buffer
overflow afin de remédier à ce
problème.
• S’assurer que les droits d’accès
déployés sont efficaces.

Condition 3 : Protéger les données du titulaire stockées
Condition 4 : Crypter la transmission des données du titulaire sur les réseaux publics ouverts
Oui
Oui,
avec
CCW Non S.O.
Où se trouvent les données stockées
« connues » ? où se trouvent les
centres de données?
procédures
• Définir l’endroit en temps réel de
stockage des données CHD
• Définir la localisation
géographique de tous les centres
de données en temps réel.
Quelles lois s’appliquent au client?
• Examiner les lois que le CSP
applique sur le client.
• Examiner les législations que le
pays qui accueille le Cloud
applique sur le client.
Est-ce que le CSP a des affaires,
exigences légales ou réglementaires
qui peuvent influer sur la conservation
des données des clients?
procédures
• Définir l’impact du fournisseur
sur la conservation des données
des clients.
Comment est restreint l’accès aux
données clients à seulement les
utilisateurs et applications de ce
client?
procédures
• S’assurer que seuls les utilisateurs
et applications autorisés accèdent
aux données clients en :
Analysant les logs
Réexaminant les RBAC.
Comment sont gérés les images,
clichés instantanées et stockages pour
empêcher des captures inutiles des
données sensibles?
procédures
• Définir les endroits où se trouvent
les images et clichés instantanées
en temps réel.
• S’assurer que les images et
clichés instantanées sont sécurisés
en temps réel : mises à jour
appliquées, politiques de sécurité
appliqués.
• Examiner les logs d’accès aux
images et clichés instantanées.
Comment les données sont supprimées
de la mémoire et des images stockées?
• Examiner les procédures de
suppression des données de la

mémoire et des images stockées.
3
Si les clés cryptographiques sont
fournies par le CSP, est ce qu’on
génère des clés uniques pour chaque
client?
• S’assurer qu’on génère des clés
cryptographiques uniques pour
chaque client.
4
Où sont effectués les processus de
cryptage/décryptage? Qui contrôle
chaque processus ?
procédures
• Le processus de
cryptage/décryptage s’effectue
chez le client : définir qui
contrôle chaque processus
• Le processus de
cryptage/décryptage s’effectue
chez le CSP : définir qui contrôle
chaque processus
Où sont stockées les clés de cryptage
et qui contrôle les clés? Est-ce que les
données de clés de cryptage sont
stockées dans des endroits autres que
les données qu’ils chiffrent?
procédures
• Le stockage des clés
cryptographiques s’effectue chez
le client
• Le responsable de contrôle des
clés est un personnel du client
• Séparer les clés de chiffrement
des données à chiffrer
Où sont stockées les données cryptées,
et qui a normalement accès aux clés et
données cryptées?
procédures
• Le personnel du client est le seul
à avoir accès aux clés
cryptographiques
• Les données cryptées sont chez le
client
• Les données cryptées sont chez le
CSP
Comment est traitée la sécurité et
l’accès (local ou à distance) aux
ressources virtuels pour la génération
des clés cryptographiques?
procédures
• S’assurer que les méthodes
d’accès aux ressources virtuels
pour la génération des clés
cryptographiques sont sécurisées.
• Définir les moyens d’accès aux
ressources virtuels pour la
génération des clés
cryptographiques.
Quel processus est utilisé dans le cas
d’un incident suspect de clé?
procédures
• S’assurer que le client est informé
de l’incident en temps réel.
• Identifier l’impact de l’incident

sur la confidentialité, intégrité et
disponibilité des données CHD.
Est-ce que toutes les données du client
sont détruites d’une manière sécurisée
lors de suspension de contrat avec
CSP ?
• Examiner le processus de
destruction des données client
lors d’une suspension de contrat.
Comment les communications sont
sécurisées entre le client et les autres
environnements ? Comment les
données sont sécurisées dans le Cloud
même ?
procédures
• La séparation et la segmentation
sont assurées
• Le mot de passe pour l’accès à
chaque environnement est unique
et non partagé.
Est-ce que les API sont configurées
pour renforcer une cryptographie et
authentification forte?
• Examiner que la double
authentification est appliquée
pour les API
• S’assurer qu’une cryptographie
forte est déployée.
Est-ce que l’authentification mutuelle
est implémentée entre le CSP et les
systèmes clients ?
procédures
• Ne pas utiliser l’authentification
mutuelle entre le CSP et les
systèmes clients

Exigences PCI DSS v3.0 déjà existantes :
Condition 5 : Protéger tous les systèmes contre les logiciels malveillants et mettre à jour
régulièrement les logiciels ou programmes anti-virus
Condition 6 : Développer et gérer des systèmes et des applications sécurisés

Oui
Oui,
avec
CCW Non S.O.
Est-ce que les machines virtuelles
sont protégées des autres VM ou de
l’hyperviseur?
• Examiner les procédures
Comment assure-t-on que les anti-
virus et mises à jour des VM sont à
jour (y compris les VM inactives et
répliquées) avant qu’elles soient
activées pour une utilisation prévue ?
• Définir des tâches planifiées de
mises à jour de l’antivirus et VM
5
Quel processus pour chaque couche
du service Cloud? Exp : Les
périphériques réseau physiques,
systèmes d’exploitation hôte,
hyperviseurs, composants virtuels (y
compris les VM, les périphériques
réseaux virtuel), les applications,
etc. ?
processus pour :
Les périphériques réseau physiques
Les systèmes d’exploitation hôte
Les hyperviseurs
Les machines virtuelles
Les applications virtuelles
6
Comment les API et services WEB
sont protégées des vulnérabilités?
procédures
mises à jour des API et services
WEB
• Des tests d’intrusion sont
planifiés périodiquement
• Une adresse de contact est
fournie aux collaborateurs et
pirates blancs pour communiquer
une éventuelle vulnérabilité en
temps réel.
• Une manière de motivation des
pirates blancs et collaborateurs
est mise en place.
Comment sont empêchés les systèmes
et données de test et développement
de migrer vers l’environnement de
production? Et vice versa. (exp : à
travers les mécanismes de réplication
virtuelle, les images et de clichés
instantanés)?
procédures
• Utiliser un outil informatique de
notification qui alerte lors du
passage d’un système de test vers
un environnement de production
et vice versa

DSS : Condition 7, 8, 9
Condition 7 : Restreindre l’accès aux données du titulaire aux seuls individus qui doivent les
connaître
Condition 8 : Identifier et authentifier l’accès aux composants du système
Condition 9 : Restreindre l’accès physique aux données des titulaires de cartes
Oui
Oui,
avec
CCW Non S.O.
Comment est appliquée
l’authentification de l’utilisateur à
travers différents niveaux?
procédures
• Associer un mot de passe
différent pour chaque niveau de
sécurité
Comment sont gérées les contrôles
d’accès afin d’assurer que l’accès
n’est pas plus qu’attendu?
procédures
Quel personnel du CSP a le droit
d’accéder aux données client?
procédures
• Ne pas autoriser au personnel du
CSP à accéder aux données
client.
Comment sont revues et contrôlées les
attributions de privilèges?
procédures
• Revoir les RBAC périodiquement
• Examiner les logs d’accès aux
systèmes et les analyser
Est-ce que l’accès administratif aux
systèmes et l’hyperviseur est séparé
de l’accès aux VMs et données du
client?
procédures
• S’assurer que l’accès
administratif aux systèmes et
l’hyperviseur est séparé de
l’accès aux VMs et données du
client
Est-ce qu’on utilise les mêmes
informations d’authentifications pour
différents fonctions de sécurité ?
• S’assurer que les informations
d’authentifications pour
différents fonctions de sécurité ne
sont pas identiques
Est-ce que l’accès aux systèmes et
hyperviseurs est séparé de l’accès aux
VM et données client ?
• S’assurer que l’accès aux
systèmes et hyperviseurs est
séparé de l’accès aux VM et
données client

Est-ce que des informations
d’authentification séparées sont
utilisées pour différents fonctions de
sécurité?
procédures
• S’assurer que les informations
d’authentifications pour
différents fonctions de
sécurité sont séparées.
7
Comment est « le moindre privilège »
et « le nécessaire à savoir » est affecté
pour le personnel du CSP?
procédures
• Définir pour chaque personnel du
CSP le minimum de privilège et
le nécessaire à savoir.
• S’assurer que le personnel du
CSP possède uniquement le
minimum de privilège et connait
juste le nécessaire.
8
Est-ce que l’accès à partir de réseaux
non sécurisés est autorisé aux
personnel CSP ?
procédures
• Ne pas autoriser l’accès à partir
de réseaux non sécurisés aux
personnel CSP
9
Est-ce qu’il y a des mesures afin
d’empêcher la capture d’informations
dans la mémoire?
procédures
• Se protéger contre les failles
Buffer Overflow
• Ne pas autoriser l’accès aux
machines virtuelles à partir de
l’hyperviseur
• Contrôler et solidifier
l’introspection
• Revoir les logs d’introspection et
hyperviseur qui concernent le
client
Est-ce qu’il y a des mesures qui
assurent que les images virtuelles ne
contiennent pas des informations
d’authentification ?
procédures
• S’assurer qu’il y a des mesures
qui assurent que les images
virtuelles ne contiennent pas des
informations d’authentification
Est-ce que la double authentification
est requise pour l’accès client?
procédures
• Exiger la double authentification
pour l’accès client
•
Est-ce que le CSP utilise des mots de
passes partagés (exp pour la
maintenance) ?
procédures
• S’assurer que le CSP n’utilise pas
des mots de passes partagés pour
le client

Est-ce que le CSP garde une
possession et un contrôle total sur
toutes ses installations et ses centres
de stockage de données ?
procédures
• S’assurer que les contrôles de
sécurité sur les installations et
centres de stockage de
données sont appliqués par :
Le CSP
Les fournisseurs des CSP
Qui a l’accès physique aux centres de
données et les systèmes ?
• Définir les personnes ayant accès
physique aux centres de données
et les systèmes
Comment sont protégés les systèmes
de stockage de données contre l’accès
physique ou accès direct par console ?
procédures d’accès physique ou
par console.
• Permettre au client d’auditer les
mesures d’accès physique
• Permettre au QSA du client de se
déplacer chez le CSP pour
appliquer les exigences de
contrôles physiques.
Comment sont sécurisés les
sauvegardes des données et machines
virtuelles ?
procédures
Comment les médias physiques sont
inventoriés, sécurisés, surveillés, et
suivis ?
procédures
• Etablir un inventaire des médias
physiques
• Sécuriser ces médias :
Les lecteurs de disques amovibles
USB
Ports parallèle et série.
Cartes réseaux
Disques durs
Lecteurs de bande magnétiques
Disques optiques
• Contrôler et auditer l’accès aux
médias physiques
• Suivre le cycle de vie des médias
suivants :
Les disques amovibles de stockage
Disques durs
Bandes magnétiques
Disques optiques
Est-ce que les médias sont réutilisés ?
Comment les données sont
supprimées en permanence des
médias retirées du service ou les
médias réutilisables ?
procédures
• S’assurer que les données CHD
dans les médias suivants sont
carrément détruites avant une
éventuelle réutilisation :

Les disques amovibles de stockage
Disques durs
Bandes magnétiques
Disques optiques
• Utiliser des outils de destruction
physiques des médias de stockage
en fin de vie.

Condition 10 : Effectuer le suivi et surveiller tous les accès aux ressources réseau et aux données du
titulaire
Condition 11 : Tester régulièrement les processus et les systèmes de sécurité
Oui
Oui,
avec
CCW Non S.O.
Est-ce que les composants systèmes
spécifiques utilisés par un client
spécifique peuvent être identifiés à un
moment donné ?
procédures qui permettent d’avoir
un tableau mis à jours en temps
réel contenant les composants
utilisés par chaque client
Quels types d’évènements sont tracés
dans les journaux d’audits?
• Les évènements suivants doivent
être tracés dans les journaux
d’audits :
1. Données
2. Interfaces (APIs, GUIs, Web)
3. Applications
4. Pile de Solution (Languages de
programmation)
5. Système d'exploitation (OS)
6. Machines virtuelles VMs
7. Infrastructure réseau virtuel
8. Hyperviseurs
9. Processeur et mémoire
10. Stockage de données (Disques
durs-disques amovibles-
stockage..etc)
11. Réseau (Interfaces et
périphériques-
12. infrastructure de
communications)
13. Installations physiques/Centre de
données
14. Accès par consoles
15. Accès physique
16. Accès à l’introspection
17. Etc …
Comment les logs d’audit sont gérés
et surveillés ?
procédures
Comment les logs d’audit sont
corrélés entre les environnements
clients (comme l’image VM) et
l’infrastructure CSP (comme
l’hyperviseur et les systèmes sous-
jacents) ?
procédures
• S’assurer que chaque client reçoit
uniquement ses logs d’audit

Comment les horloges sont
synchronisées entre les instances
virtuelles et le système/matériel hôte?
• Déployer un système de
synchronisation d’horloges entres
les instances virtuelles et le
système/matériel hôte
Comment les machines virtuelles sont
scannées des vulnérabilités?
procédures
• Définir une date périodique de
scan de vulnérabilités et tests
d’intrusion
• Définir ce que le client doit
scanner et ce que le CSP doit
scanner
mises à jour des VMs
• Une adresse de contact est
fournie aux collaborateurs et
pirates blancs pour communiquer
une éventuelle vulnérabilité en
temps réel.
• Une manière de motivation des
pirates blancs et collaborateurs
est mise en place.
Comment sont provisionnées les
informations d’authentification ?
procédures
10
Est-ce que l’accès à distance du
personnel du CSP est autorisé à partir
de réseaux non sécurisés?
procédures
• Ne pas autoriser l’accès du
personnel du CSP à partir de
réseaux non confiants
11 Est-ce que double authentification est
mise en place pour l’accès client ?
• S’assurer que double
authentification est mise en place
pour l’accès client
Comment sont gérées et testées les
technologies de Wireless ?
procédures et la conformité avec
les exigences PCI DSS
Comment les machines virtuelles
(Dans toutes ses états : actives,
dormantes, inactives, en maintenance)
sont scannées contre les
vulnérabilités ?
procédures qui traitent le scan
contre les vulnérabilités des VMs
dans toutes ses états.
Quelles défenses sont en place afin de
se protéger contre les attaques
«internes» (provenant du CSP ou
autre réseau client) et les attaques
"externes" (provenant de l'Internet ou
tout autre réseau public)?
procédures
• Implémenter des IPS/IDS contre
les trafics intra-VM et externes.
Est-ce que le test d’intrusion est
effectué à travers toutes les couches
procédures

de l'environnement (par exemple,
entre les machines virtuelles et le
réseau de gestion du CSP, ou entre
des clients sur une infrastructure
partagée)?
• Effectuer des tests d’intrusions
sur toutes les couches de
l’environnement CDE.
Quels tests de sécurité le client est
autorisé à faire sur ses interfaces
web ?
procédures
• Autoriser les tests d’intrusion sur
les interfaces API et WEB
• Ne pas autoriser l’exploitation
des failles DOS et DDOS
• Autoriser les tests d’intrusion sur
les couches qui sont sous la
responsabilité des Clients
Comment les clients sont empêchés
de faire des tests d’intrusion sur les
environnements des autres clients ?
procédures
• Le client n’est autorisé à faire un
test d’intrusion que suite à un
accord écrit et encadré par le CSP

DSS : Condition 12
Condition 12 : Maintenir une politique de sécurité des informations pour l’ensemble du personnel
Oui
Oui,
avec
CCW Non S.O.
Comment le CSP identifie les
risques potentiels?
• Effectuer une évaluation de risque
périodiquement
Est-ce que les clients sont notifiés
lors des changements de la sécurité
et/ou des politiques privées ?
• Examiner le processus de
notification des clients lors des
changements de la sécurité et/ou
des politiques privées
Le CSP a-t-il des mécanismes en
place pour assurer que des
procédures opérationnels sécurisés
sont pratiquées ?
procédures
Est-ce que différents niveaux de
dépistage sont utilisés pour
différents rôles ou régions?
procédures
Est-ce que le dépistage couvre tout
le personnel ayant un accès physique
aux centres de données à tous les
endroits?
• Etablir une liste du personnel CSP
ayant accès physique
Est-ce que le CSP sous traite
n’importe quel aspect de son service
Cloud à d’autres fournisseurs (ex :
stockage de données, services de
sécurité, etc.)?
procédures
• Etablir une liste des fournisseurs
du CSP
12
Quelles mesures sont prises afin
d’assurer que les politiques de
sécurité du CSP sont maintenues par
leurs fournisseurs tierces-parties?
procédures
• Exiger des documents du CSP
décrivant les mesures de sécurité
déployés par ses fournisseurs
Quels mécanismes sont mis en place
afin de reporter au CSP une
éventuelle menace ?
procédures
• Exiger une adresse e-mail de
l’équipe de sécurité pour traiter
les menaces de sécurité trouvée
par une personne étrangère du
CSP
Quel mécanisme est utilisé afin de
détecter qu'un "incident" ou "une
menace" a eu lieu?
procédures
• Examiner les journaux d’audit en
temps réel possible.
Quelles notifications sont mises en • Examiner les politiques et

place et quand? procédures
Comment une menace (qui a touché
un client) peut affecter la sécurité
d’un autre client sur la même
infrastructure ?
procédures
• Lors d’un incident qui a affecté
un client, s’assurer qu’il n’a pas
touché les autres clients
immédiatement.
Comment les preuves sont
collectées, gérées et partagées?
procédures
Quel était l’impact sur les données
du client lors d’une infraction?
• Etudier l’impact d’un incident de
sécurité sur les données CHD
Est-ce que les données d'un client
peuvent être collectées dans le cadre
d’une enquête de violation d'un autre
client (ou de CSP) (soit par les
autorités les par les enquêteurs d'un
tiers-parti)?
procédures
• Etablir une liste contenant le nom,
prénom, fonction du personnel
autorisé à faire une investigation
ainsi que la date de l’investigation
• Auditer la nature des
investigations relevées dans des
documents qui seront fournies
aux clients par la suite
Est ce qu’on a des processus
implémentés de reprise après
sinistres, systèmes et installations
avec le même contrôle de sécurité
que les environnements de
production ?
procédures
• Examiner les processus du plan
de continuité de service BCP et
de reprise après sinistre DR

Implémentation de la norme PCI DSS dans le Cloud (PFE Master Faculté des sciences Ain chock)

Contenu connexe

Tendances

Similaire à Implémentation de la norme PCI DSS dans le Cloud (PFE Master Faculté des sciences Ain chock)

Dernier

Implémentation de la norme PCI DSS dans le Cloud (PFE Master Faculté des sciences Ain chock)