Vous découvrez que les journaux de l'application contiennent des numéros de carte bancaire complets et des mots de passe en clair. Quelle est la priorité de correction ?

Le piège de cette question est de traiter des secrets journalisés comme un problème de contrôle d'accès alors que c'est en réalité un problème de minimisation des données. Ces données ne devraient pas être là du tout — donc le premier geste est d'arrêter de les créer.

Pourquoi le caviardage à la source vient en premier

Les journaux ne sont pas un coffre privé. Ils sont expédiés vers des SIEM, copiés dans des sauvegardes, répliqués entre régions, indexés par des outils de recherche et lus par des ingénieurs d'astreinte. Chacune de ces copies est désormais un stock d'identifiants et de données de porteurs de carte en clair. PCI DSS interdit explicitement de stocker des PAN complets sous cette forme et interdit de stocker des données d'authentification sensibles comme les CVV après autorisation ; les mots de passe ne devraient jamais être journalisés sous aucune forme. La première étape est donc de masquer ou caviarder à la source — empêcher l'application d'écrire les champs sensibles. Cela arrête l'hémorragie. Ce n'est qu'ensuite que vous remédiez aux journaux existants (purger ou nettoyer les entrées historiques, y compris les sauvegardes et copies en aval) et revoyez/resserrez les accès.

Pourquoi les distracteurs sont faux

• Laisser ainsi — les journaux sont internes. « Interne » n'est pas une frontière de sécurité. Des initiés, un compte compromis, un bucket mal configuré ou une intrusion transforment ces journaux en divulgation. C'est la réponse « ne rien faire ».
• Chiffrer tout le serveur, continuer à journaliser. Le chiffrement au repos protège contre des disques volés, mais l'application, le SIEM, chaque administrateur et chaque sauvegarde lisent toujours les secrets en clair. Les secrets sont toujours là. Vous avez verrouillé la pièce mais laissé le coffre ouvert à l'intérieur.
• Restreindre simplement qui peut lire les journaux. Resserrer les ACL est une bonne étape de soutien, mais à elle seule elle laisse des secrets actifs dans les journaux, se propageant via les pipelines et les sauvegardes, à une mauvaise config de l'exposition.

Ce que sonde l'interlocuteur

Il veut l'instinct de minimisation des données : corriger la source avant les symptômes. La bonne réponse nomme PCI DSS, reconnaît que « interne » et « chiffré au repos » ne résolvent pas le clair-dans-les-journaux, et ordonne correctement — cesser de l'écrire, puis nettoyer ce qui est déjà là, puis durcir l'accès.