Aller au contenu

QSA · QPA · 3DS Assessor

PCI DSS

Là où le standard n'est pas tranché : l'exigence 3.4.2

Des administrateurs accèdent par SSH aux bases contenant des données de cartes, et le standard dit qu'ils ne doivent pas pouvoir en copier les numéros, sauf s'ils y sont autorisés. Nous avons utilisé cette exception, et nous n'en sommes pas à l'aise. Voici notre raisonnement, et ce dont nous ne sommes pas sûrs.

Mis à jour 24 oct. 20264 min de lecture

Les clients attendent de leur QSA une réponse nette pour chaque exigence, et certains évaluateurs font semblant d’en avoir une. Nous préférons vous dire où le standard laisse de la marge, ce que nous faisons de cette marge, et où nous ne sommes toujours pas sûrs. Voici l’un de ces endroits.

L’exigence

L’exigence 3.4.2 demande des contrôles techniques qui empêchent la copie ou le déplacement des numéros de cartes lorsqu’ils sont consultés par accès distant, sauf pour le personnel disposant d’une autorisation documentée et explicite et d’un besoin métier légitime et défini.

Le cas pour lequel elle est écrite est évident : un agent de support en session de bureau à distance ne doit pas pouvoir coller des numéros de cartes dans un tableur chez lui. Le cas sur lequel elle est muette est celui que nous rencontrons dans la plupart des évaluations : des administrateurs de bases de données qui travaillent sur des systèmes contenant des données de cartes, par SSH, depuis un poste durci, avec chaque session journalisée.

Les deux raccourcis

Les évaluateurs prennent ici l’un de deux raccourcis. Le premier consiste à exiger que le copier-coller soit bloqué dans chaque session d’administration. C’est impraticable. Un administrateur avec un shell peut lire une table ; s’il peut la lire, il peut la déplacer, et un contrôle du presse-papiers n’y change rien.

Le second consiste à valider l’exigence parce que les données sont chiffrées au repos. C’est trop facile. Si l’administrateur peut atteindre les clés, ou peut s’accorder lui-même l’accès aux clés, alors copier des données de cartes chiffrées, c’est copier des données de cartes avec une étape de plus.

Le test que nous appliquons

La question que nous posons : qui peut déchiffrer ce qu’il pourrait copier ?

Si les administrateurs peuvent atteindre les clés, alors copier des données chiffrées est un vrai déplacement de données de cartes, et soit le contrôle technique, soit l’exception documentée doit être réel. « Réel » veut dire une personne nommée, un besoin métier écrit, une approbation effectivement donnée, et des sessions journalisées et revues.

Si les clés sont réellement séparées de l’accès d’administration, dans un module de sécurité matériel ou un service de clés cloud, avec un accès réservé à l’application et des administrateurs techniquement incapables de s’accorder des droits, alors la séparation des clés répond à l’objectif de l’exigence. Un administrateur qui copie la table a copié un texte chiffré qu’il ne peut pas lire. Nous le disons ouvertement dans le rapport, avec le raisonnement, plutôt que de le cacher derrière « en place ».

L’exception que nous avons utilisée

Voici la partie inconfortable. Sur plus d’une évaluation, les clés n’étaient pas assez séparées pour la seconde lecture, et bloquer la copie dans les sessions SSH n’était pas réaliste. Nous avons fini par prendre la voie administrative : les administrateurs ont reçu une justification métier documentée pour accéder aux données de cartes et, en principe, les déplacer, alors qu’ils n’ont en réalité pas besoin de les déplacer. L’exigence le permet. Nous avons réutilisé l’approche depuis, parce que nous n’en avons pas trouvé de meilleure et que nous ne voulons pas pousser les clients à mutiler les outils de leurs administrateurs pour un contrôle qui ne fonctionnerait de toute façon pas.

Nous n’en sommes pas à l’aise. Une justification écrite pour satisfaire une exception est un contrôle plus faible que celui que l’exigence voulait, et nous le savons. Nous lisons l’exigence largement, comme « ne déplacez pas de données de porteurs de cartes, même chiffrées », et nous tenons les clients à cette lecture en pratique. Mais un rapport honnête doit dire où le standard a été satisfait à la lettre et où il l’a été dans son esprit.

Un rapport honnête doit dire où le standard a été satisfait à la lettre et où il l’a été dans son esprit.

Ce que l’on fait de travers

On attend du QSA une règle pour tout. Le standard est écrit pour une très grande variété d’environnements, et par endroits il est délibérément large. Un évaluateur qui affiche une certitude là où le texte n’en a pas l’invente, et le suivant l’inventera peut-être autrement.

On prend « chiffré » pour la fin de la conversation. Le chiffrement déplace la question vers les clés. Si vous ne pouvez pas décrire qui peut atteindre les clés et comment, vous n’avez pas répondu à la question, vous l’avez renommée.

Une réponse franche sur votre périmètre PCI ?

Parlez à un QSA, pas à un commercial. Dès le premier échange, de vraies réponses.

Parler à un QSA

Ou joignez-nous directement

QSAQPA3DS AssessorAutorisés à évaluer en Europe et dans la région CEMEA