PCI DSS 4.0.1 : votre hébergeur est-il conforme ?

PCI DSS 4.0.1 en 2026 : qui est concerné et pourquoi l’hébergement compte

PCI DSS est le standard de sécurité élaboré par le PCI Security Standards Council pour protéger les données des cartes de paiement. La version PCI DSS 4.0.1 constitue une révision limitée de PCI DSS v4.0 : elle clarifie et corrige certains éléments du standard, sans introduire de nouvelles exigences de sécurité.

Ce référentiel concerne les organisations qui stockent, traitent ou transmettent des données de titulaires de cartes. Il concerne également les systèmes susceptibles d’avoir un impact sur la sécurité de l’environnement de données de cartes, souvent appelé CDE pour Cardholder Data Environment.

Pour un e-commerçant, le sujet ne se limite donc pas au module de paiement. Le serveur web, le pare-feu, les comptes d’administration, les journaux techniques, les sauvegardes et les outils de déploiement peuvent entrer dans le périmètre s’ils hébergent ou influencent le parcours de paiement.

L’hébergement est particulièrement important pour trois raisons :

il porte une partie des composants techniques exposés sur Internet ;
il détermine les possibilités de cloisonnement entre la boutique, l’administration et les services de paiement ;
il fournit, selon l’offre choisie, des mécanismes essentiels de sécurité : filtrage réseau, journalisation, sauvegardes, contrôle d’accès ou protection applicative.

Attention toutefois : un hébergeur reconnu, un serveur correctement administré ou la présence d’un certificat TLS ne suffisent pas à déclarer une boutique conforme. La conformité PCI DSS s’évalue sur un périmètre précis, des contrôles concrets, des preuves et des responsabilités explicitement réparties.

Les règles applicables dépendent aussi du modèle de paiement. Une redirection complète vers une page hébergée par un prestataire de paiement peut réduire le périmètre PCI du marchand. À l’inverse, une page de paiement intégrée, des scripts chargés sur la page de commande ou un serveur qui reçoit directement le numéro de carte élargissent fortement les contrôles à appliquer.

Avant toute décision d’infrastructure, il est utile de cartographier le parcours réel de la donnée : navigateur du client, boutique, scripts tiers, passerelle de paiement, API, outils de support, sauvegardes et éventuels systèmes de reporting.

Ce que PCI DSS protège réellement : données de carte, données sensibles et périmètre technique

Le numéro principal de carte, ou PAN, est la donnée centrale protégée par PCI DSS. Associé à d’autres éléments comme le nom du porteur ou la date d’expiration, il constitue des données de titulaire de carte lorsqu’il est stocké, traité ou transmis.

Certaines données sont encore plus sensibles. Les données d’authentification sensibles, telles que le cryptogramme visuel (CVV/CVC), les données de piste ou le code PIN, ne doivent pas être conservées après l’autorisation, même sous forme chiffrée. Une sauvegarde de base de données qui contiendrait accidentellement ces données constitue donc un risque majeur, au-delà du seul sujet de l’hébergement.

Dans la pratique, de nombreux marchands s’appuient sur la tokenisation proposée par leur prestataire de paiement. Un jeton peut limiter l’exposition du SI marchand au PAN. Mais il ne faut pas déduire automatiquement qu’un jeton fait sortir l’ensemble de la boutique du périmètre : une compromission des scripts de paiement, d’un compte administrateur ou d’une intégration API peut toujours avoir un impact sur la sécurité de la transaction.

Réduire le périmètre PCI DSS est une stratégie utile. Le réduire sans le documenter ni le vérifier crée surtout un angle mort de conformité.

Le niveau de validation demandé par les marques de cartes et l’acquéreur dépend notamment du volume de transactions et du modèle d’acceptation des paiements. Selon le cas, l’entreprise peut devoir compléter un questionnaire d’auto-évaluation, ou SAQ, et une attestation de conformité, ou AOC. Les organisations les plus exposées peuvent être soumises à une évaluation par un QSA, un auditeur qualifié PCI.

Le bon SAQ ne se choisit pas parce qu’il est plus court : son éligibilité doit correspondre exactement à l’architecture de paiement. En cas de doute, l’acquéreur, le prestataire de paiement et un QSA sont les interlocuteurs appropriés. La bibliothèque documentaire du PCI Security Standards Council donne accès aux documents de référence du standard et aux questionnaires concernés.

Hébergeur, marchand et prestataire de paiement : comprendre la responsabilité partagée

La notion de responsabilité partagée est indispensable, en particulier avec un cloud public, un hébergement infogéré ou une plateforme e-commerce SaaS. L’hébergeur peut sécuriser le bâtiment, le réseau, les hyperviseurs, le matériel et certains services managés. Le marchand reste néanmoins responsable de son application, de ses comptes, de ses configurations, de ses extensions et de l’usage qu’il fait des services fournis.

Un hébergeur peut disposer d’une attestation PCI DSS pour une partie de ses activités. C’est un élément utile, mais il faut en examiner le périmètre exact. Une AOC peut concerner certains centres de données, une offre d’infrastructure donnée ou des services managés spécifiques, sans couvrir automatiquement toutes les options du catalogue.

Demandez à votre fournisseur :

une AOC à jour, lorsque le service est présenté comme couvert par PCI DSS ;
la description exacte des services, sites et composants inclus dans le périmètre de cette attestation ;
une matrice de responsabilités indiquant clairement qui administre le système d’exploitation, les correctifs, les pare-feu, les sauvegardes, les certificats et les journaux ;
les modalités d’accès aux preuves nécessaires à votre propre évaluation ;
les engagements de notification et de coopération en cas d’incident de sécurité.

Le statut d’un prestataire de services peut aussi être vérifié dans le registre des prestataires validés du PCI Security Standards Council. Cette vérification ne remplace pas l’analyse contractuelle : l’inscription confirme une validation pour les services déclarés, pas l’adéquation automatique à votre architecture.

Voici un exemple concret. Sur un serveur dédié infogéré, l’hébergeur peut appliquer les correctifs du système d’exploitation et opérer le pare-feu réseau. L’e-commerçant reste souvent chargé de mettre à jour Magento, PrestaShop ou WooCommerce, de supprimer les comptes inutilisés, de contrôler les extensions et de configurer les droits dans le back-office. Si une extension vulnérable permet d’injecter un script sur la page de paiement, la conformité de l’infrastructure seule n’empêche pas l’incident.

À l’inverse, une plateforme SaaS peut gérer une part importante de l’infrastructure et des mises à jour. Le marchand doit toujours protéger ses comptes d’administration, limiter les droits, contrôler les applications tierces et sécuriser les postes utilisés par ses équipes.

Segmentation réseau : réduire le périmètre sans créer une fausse frontière

La segmentation consiste à isoler le CDE des autres environnements : site vitrine, préproduction, postes bureautiques, outils marketing, entrepôts de données ou services internes. Bien mise en œuvre, elle réduit le nombre de systèmes soumis aux contrôles PCI DSS.

Mais une séparation déclarative ne suffit pas. Deux machines placées dans des sous-réseaux différents restent potentiellement dans le même périmètre si des flux trop larges, des identifiants partagés ou des accès d’administration permettent de contourner l’isolement.

Pour évaluer l’hébergeur, vérifiez notamment :

la possibilité d’utiliser des réseaux privés, des règles de pare-feu restrictives et des groupes de sécurité dédiés ;
la limitation des flux aux seuls ports, protocoles et destinations nécessaires ;
l’absence d’accès direct inutile entre les environnements de développement, de recette et de production ;
la séparation des comptes et des rôles d’administration ;
la documentation des règles réseau et un processus de revue après chaque changement significatif.

Une segmentation utilisée pour réduire le périmètre doit être testée. PCI DSS prévoit des tests de pénétration visant à vérifier l’efficacité des contrôles de segmentation lorsque celle-ci est mise en avant. Ces tests doivent notamment être réalisés périodiquement et après des changements importants dans les contrôles de segmentation.

Un exemple simple : une base de données contenant des informations liées aux commandes ne devrait pas être accessible depuis Internet. Seul le serveur applicatif strictement nécessaire devrait pouvoir y accéder, avec un compte dédié et des droits minimaux. Une règle du type « tout le réseau privé peut joindre la base » est plus simple à exploiter, mais elle agrandit la surface d’attaque.

Les environnements modernes utilisent souvent des conteneurs ou Kubernetes. Ces technologies n’apportent pas automatiquement une isolation suffisante : politiques réseau, secrets, comptes de service et droits du plan de contrôle doivent également être examinés. Si cette approche vous concerne, notre guide sur Kubernetes managé et l’hébergement aide à cadrer les questions à poser à un fournisseur.

Journaux, accès et MFA : les preuves qui manquent le plus souvent

Une conformité PCI DSS ne repose pas uniquement sur des protections préventives. Elle exige aussi de pouvoir comprendre ce qui s’est produit : qui a accédé à un système, depuis quelle source, à quel moment et avec quel résultat. Les journaux sont donc à la fois une mesure de sécurité et une source de preuve.

L’hébergeur doit pouvoir expliquer quels événements sont journalisés par ses services, combien de temps les données sont conservées, comment elles sont protégées et comment le client peut les exporter. Le marchand doit, de son côté, activer et exploiter les journaux qui relèvent de son application et de ses comptes.

Les points à examiner incluent :

les connexions et échecs de connexion aux interfaces d’administration ;
les opérations réalisées avec des privilèges élevés ;
les modifications de règles réseau, de comptes, de configurations et de droits ;
les événements de sécurité du serveur web, du système et des solutions de filtrage ;
la synchronisation de l’heure entre les composants ;
la protection des journaux contre l’effacement ou l’altération non autorisés.

PCI DSS impose une conservation minimale des historiques de journaux et une disponibilité immédiate d’une partie récente de ces données. Il est prudent de confirmer les modalités précises avec votre hébergeur, car une offre de logs standard peut être conçue pour le diagnostic opérationnel, et non pour répondre à vos obligations d’audit.

La gestion des accès mérite le même niveau d’exigence. Chaque personne doit utiliser un identifiant individuel ; les comptes partagés compliquent l’attribution des actions. Les privilèges doivent être attribués selon le besoin d’en connaître et revus régulièrement. Les comptes d’anciens employés, de prestataires ponctuels et de développeurs ayant quitté un projet doivent être supprimés ou désactivés sans délai inutile.

L’authentification multifacteur, ou MFA, est un contrôle majeur pour les accès au CDE et les accès distants concernés. Vérifiez concrètement que votre offre d’hébergement permet de l’activer sur le panneau client, les comptes techniques, les accès SSH, les consoles cloud et les outils de support. La MFA du back-office e-commerce ne remplace pas celle d’une console d’administration d’infrastructure.

Sauvegardes, chiffrement et WAF : des contrôles utiles, mais à cadrer

Les sauvegardes sont parfois oubliées lors de la définition du périmètre. Pourtant, si elles contiennent des données de titulaires de cartes ou des secrets donnant accès à l’environnement de paiement, elles doivent bénéficier d’un niveau de protection cohérent avec les données de production.

Interrogez l’hébergeur sur :

l’emplacement géographique des sauvegardes et de leurs répliques ;
le chiffrement en transit et au repos ;
la gestion des clés lorsque le fournisseur propose cette option ;
les droits nécessaires pour restaurer une sauvegarde ;
la durée de rétention, l’effacement et la possibilité de purger une sauvegarde ;
la capacité à tester une restauration sans réinjecter de données de production dans un environnement insuffisamment protégé.

PCI DSS ne se résume pas à « faire des sauvegardes ». Il faut savoir ce qu’elles contiennent, qui peut les restaurer et où elles sont stockées. Dans un contexte e-commerce, une restauration rapide est indispensable pour la continuité d’activité, mais une restauration non maîtrisée peut recréer une vulnérabilité, réactiver des comptes obsolètes ou exposer des données dans un environnement de test.

Un WAF, ou Web Application Firewall, peut également contribuer à la protection des applications web exposées. PCI DSS prévoit des contrôles destinés à détecter et prévenir les attaques web contre les applications accessibles au public. Cloudflare, AWS WAF, Imperva ou ModSecurity sont des exemples de solutions et de technologies fréquemment utilisées.

Le WAF n’est toutefois pas un correctif universel. Une règle mal configurée peut laisser passer une attaque ; une règle trop agressive peut bloquer des clients légitimes ou perturber le tunnel de commande. Sa valeur dépend de son positionnement, de la qualité des règles, de la surveillance des alertes et de la capacité de l’équipe à corriger la vulnérabilité applicative sous-jacente.

Le chiffrement TLS reste indispensable pour les flux réseau. Mais la conformité exige aussi une gestion rigoureuse des certificats, des protocoles et des configurations. Le passage progressif à des certificats à durée de vie plus courte renforce l’intérêt d’automatiser le renouvellement et la supervision ; consultez notre analyse sur les certificats SSL de 90 jours et leurs conséquences pour l’hébergement.

Méthode pratique : auditer son hébergeur en quatre étapes

Un audit efficace ne commence pas par une liste générique de questions. Il commence par le périmètre de votre propre paiement.

1. Cartographier les flux et les composants

Listez les pages de paiement, les domaines, les serveurs, les bases de données, les services de CDN, les scripts tiers, les outils de supervision, les sauvegardes, les comptes à privilèges et les intégrations de paiement. Indiquez pour chacun s’il stocke, traite, transmet ou peut influencer les données de carte.

Cette carte doit inclure les prestataires parfois invisibles : solution de chat, outil de gestion de balises, service anti-fraude, support technique, agence de développement ou outil de déploiement continu.

2. Construire une matrice de responsabilités

Pour chaque contrôle, indiquez un responsable nommé : marchand, hébergeur, prestataire de paiement, agence ou fournisseur de sécurité. Ajoutez la preuve attendue et la fréquence de revue.

Par exemple : l’hébergeur fournit les journaux du pare-feu ; l’équipe interne les examine selon le processus défini ; l’agence corrige les vulnérabilités de l’application ; le prestataire de paiement produit son AOC. Cette matrice évite les zones grises où chaque acteur suppose que l’autre agit.

3. Réunir les preuves avant de remplir le SAQ

Récupérez les AOC pertinentes, les contrats, les schémas réseau, les exports de règles de pare-feu, les captures de configuration MFA, les politiques de sauvegarde, les rapports de scans et les procédures de réponse à incident. Conservez également les preuves de revue des accès et des journaux.

Les analyses de vulnérabilités externes exigées dans certains contextes PCI doivent être réalisées par un ASV, un Approved Scanning Vendor. Les scans, les correctifs et les nouvelles analyses doivent être intégrés à un cycle continu, notamment après un changement significatif.

4. Traiter les écarts selon leur risque

Priorisez d’abord les accès administrateurs sans MFA, les services exposés inutilement, les logiciels non corrigés, les journaux absents, les sauvegardes non maîtrisées et les scripts de paiement non inventoriés. Définissez pour chaque écart un propriétaire, une date cible, une preuve de correction et un contrôle de vérification.

Ne cherchez pas à résoudre PCI DSS dans un document annuel. Une boutique évolue : nouvelle extension, nouveau sous-traitant, migration d’hébergeur ou changement de tunnel de paiement. La conformité doit suivre ces changements par un processus de gestion des modifications.

Les erreurs fréquentes des e-commerçants exigeants

La première erreur est de confondre la conformité d’un fournisseur avec celle de la boutique. Une AOC de l’hébergeur est une pièce du dossier, pas le dossier entier.

La deuxième consiste à croire qu’une passerelle de paiement externalisée élimine toutes les responsabilités. Les scripts présents sur une page de paiement, la configuration DNS, les comptes d’administration et les redirections restent des actifs sensibles.

La troisième est d’acheter un WAF, un CDN ou une sauvegarde managée sans définir qui surveille, valide et teste ces services. Une fonctionnalité activée sans procédure n’est pas une mesure de sécurité pleinement opérante.

Enfin, beaucoup d’équipes abordent PCI DSS uniquement à l’approche d’un renouvellement d’attestation. Or les indisponibilités, compromissions et ralentissements associés à une mauvaise maîtrise de l’infrastructure ont aussi un coût commercial. La surveillance côté utilisateur, abordée dans notre guide sur le RUM appliqué à l’hébergement, complète utilement les indicateurs de sécurité et d’exploitation.

Conclusion : faire de l’hébergement un contrôle vérifiable

PCI DSS 4.0.1 impose une discipline plus large qu’un simple choix d’hébergeur : connaître les flux de paiement, réduire le périmètre, attribuer les responsabilités, protéger les accès et conserver des preuves exploitables.

Un hébergeur de qualité peut apporter des fondations solides, notamment sur l’infrastructure, le réseau, les sauvegardes et certains services de sécurité. Mais le marchand doit vérifier ce qui est réellement couvert, configurer correctement ce qui lui revient et maintenir une documentation adaptée à son architecture.

Commencez par demander l’AOC et la matrice de responsabilités de votre fournisseur, puis confrontez-les à votre propre cartographie des flux. Cette démarche concrète permet d’identifier rapidement les écarts qui méritent d’être corrigés avant qu’ils ne deviennent un risque de conformité ou un incident de paiement.