Authentification multifactorielle pour tout accès à l’environnement des données du titulaire de carte : explication de l’exigence 8.4.2

Depuis le 31/03/2025, la norme PCI DSS impose l’authentification multifactorielle (MFA) à un bien plus grand nombre de personnes qu’auparavant. Dans les versions antérieures, la MFA était principalement attendue pour les administrateurs et pour les accès à distance depuis l’extérieur du réseau. L’exigence 8.4.2 l’étend désormais à tout accès à l’environnement des données du titulaire de carte (CDE). Pour de nombreuses organisations, il s’agit du changement le plus visible de la norme PCI DSS v4.

Ce que dit l’exigence 8.4.2, en termes simples

La MFA doit être utilisée pour tout accès autre que par console à l’environnement CDE, quel que soit le rôle, depuis n’importe quel emplacement, à l’intérieur comme à l’extérieur du réseau. Cette exigence a été introduite dans la v4.0 en tant que bonne pratique et est devenue obligatoire le 31/03/2025, en même temps que les autres exigences à date d’application différée.

En pratique, un responsable de magasin, un agent du service client, un développeur ou le technicien d’un prestataire qui se connecte à un système du CDE doit utiliser la MFA, et pas seulement les administrateurs informatiques. Les organismes d’évaluation précisent que cela couvre les environnements cloud, les systèmes hébergés, les applications sur site, les équipements réseau, les serveurs et les postes de travail qui composent le CDE.

Ce que signifie « l’accès à l’environnement CDE »

Le mot clé est « à ». La MFA s’applique au point où une personne pénètre dans le CDE. Si votre réseau est segmenté et que l’accès au CDE se fait via un serveur rebond ou un point d’accès dédié, la MFA appliquée à ce point d’entrée peut suffire à satisfaire l’exigence. Si le CDE n’est pas segmenté et se confond avec le reste du réseau de bureau, le nombre de systèmes nécessitant la MFA augmente rapidement. C’est l’une des raisons pour lesquelles une bonne segmentation est rentable.

L’accès à distance depuis l’extérieur du réseau vers n’importe quelle partie de l’environnement reste soumis à la MFA au titre d’une exigence distincte. Certains utilisateurs devront donc valider la MFA plusieurs fois : une première fois pour accéder au réseau, puis une seconde fois pour accéder au CDE.

Ce qui a changé dans la v4.0.1

La révision limitée publiée en 2024 a ajouté une note sur la MFA et les facteurs d’authentification résistants au hameçonnage, ainsi qu’une définition de « l’authentification résistante au hameçonnage » dans le glossaire. Si votre organisation a adopté des méthodes résistantes au hameçonnage, telles que des clés de sécurité matérielles ou des authentificateurs de plateforme reposant sur la cryptographie à clé publique, examinez cette note avec votre auditeur afin de déterminer comment elle s’applique à votre situation.

Comment le système de MFA lui-même doit être configuré

Une MFA qui peut être contournée n’est pas une véritable MFA. L’exigence 8.5.1 de la norme PCI DSS précise le fonctionnement attendu du système. En résumé, celui-ci doit résister aux attaques par rejeu, empêcher tout contournement sauf approbation explicite de la direction, utiliser au moins deux types de facteurs différents, et n’accorder l’accès que lorsque tous les facteurs sont validés avec succès.

L’indépendance des facteurs est essentielle. Les directives antérieures du Conseil précisent que « l’accès à un facteur ne doit pas donner accès à un autre facteur ». Par exemple, l’envoi d’un code à usage unique vers une boîte e-mail ouverte avec le même mot de passe que l’utilisateur vient de saisir ne constitue pas deux facteurs indépendants.

Problèmes fréquemment constatés

• Comptes partagés ou génériques qui ne peuvent pas être associés à une personne en particulier et qui, de ce fait, ne peuvent pas utiliser correctement la MFA.
• Outils d’accès à distance des prestataires laissés en dehors de la solution de MFA « parce que le prestataire a besoin d’un accès rapide ».
• Applications obsolètes présentes dans le CDE, qui ne prennent pas en charge la MFA et n’ont jamais été placées derrière un point d’accès protégé par MFA.
• Paramètres « Se souvenir de cet appareil » qui désactivent silencieusement le second facteur pendant de longues périodes.
• Comptes d’urgence (« break-glass ») sans approbation ni surveillance documentées.

Une démarche de mise en œuvre concrète

1. Cartographiez qui accède au CDE et de quelle manière. Incluez les employés, les prestataires et les fournisseurs de services.
2. Réduisez les points d’entrée. Faites transiter les accès par le plus petit nombre possible de passerelles contrôlées.
3. Choisissez des méthodes de MFA adaptées à chaque groupe d’utilisateurs. Privilégiez les méthodes résistantes au hameçonnage pour les utilisateurs disposant de privilèges élevés.
4. Documentez les exceptions. Tout contournement doit faire l’objet d’une approbation de la direction, d’une durée limitée et d’un enregistrement.
5. Testez le dispositif. Essayez d’accéder aux systèmes du CDE sans MFA, et intégrez ce scénario à votre test d’intrusion.
6. Conservez les preuves. Des captures d’écran de configuration, des journaux d’accès et des listes d’utilisateurs vous seront demandés lors de l’évaluation.

Pour en savoir plus, consultez notre présentation de la norme PCI DSS. Ubitrak évalue la MFA dans le cadre de ses évaluations PCI DSS et peut tester les chemins d’accès lors de tests d’intrusion. Si vous avez besoin d’aide pour choisir ou déployer une solution de MFA, KW Consulting accompagne les projets de remédiation. Contactez-nous pour démarrer.

Sources

• Blog du PCI SSC : Just Published: PCI DSS v4.0.1
• Blog du PCI SSC : Now is the time to adopt the future-dated requirements of PCI DSS v4.x
• Blog du PCI SSC : Understanding new PCI guidance on MFA
• Schellman : New MFA requirements in PCI DSS v4
• SecurityMetrics : A guide to new requirements in PCI DSS 4.0.1