Personnalisation de la journalisation log4j pour les données sensibles

Question

J'ai une classe qui contient des informations sensibles (informations de carte de crédit, numéros de téléphone, etc.).

Je veux être capable de passer cette classe à log4j, mais j'ai des informations obscures.

Si j'ai une classe UserInformation qui a des méthodes getPhoneNumber, getCreditCardNumber, comment est-ce que je personnaliserais log4j ou cette classe afin qu'elle obscurcisse les nombres correctement. Je souhaite que le numéro de carte de crédit soit indiqué en tant que xxxx-xxxx-xxxx-1234 et que le numéro de téléphone soit xxxx-xxx-xxx étant donné que ceux-ci sont 1234-1234-1234-1234 et 1234-567 -890

Merci

Answer 1

Vous pouvez essayer de mettre en œuvre en écrivant un formateur d'enregistrement de journal personnalisé qui obscurcit ces motifs. Mais je pense que c'est un peu douteux ... parce que quelqu'un pourrait accidentellement ou délibérément contourner cela en peaufinant les fichiers de configuration de l'enregistreur, etc

Je pense qu'il serait mieux de faire l'une des choses suivantes, selon la façon dont vous rassemblons les messages du journal:

• Modifier les appels de l'enregistreur dans votre code pour assembler les messages du journal en utilisant des méthodes alternatives de getter sur UserInformation qui obscurcissent les champs sensibles. Remplacez la méthode toString par UserInformation pour masquer les détails.

Answer 2

Mise à jour: La meilleure option est probablement pour envelopper vos objets réels dans un emballage Obfuscated-ClassName qui implémente la même interface mais retourne les versions brouillées (en déléguant à l'objet réel et obscurcissant le résultat) et remettre ceux à la système de journalisation. Cela ne fonctionne que si vous passez réellement ces objets vous-même, et non s'ils font partie d'un arbre d'objets - cela pourrait rendre la situation un peu plus complexe.

ancienne:

Peut-être que vous devriez simplement ajouter getPhoneNumberForLogging()/getObfuscatedPhoneNumber() type fonctions? (Bien sûr, vous devez tenir compte du fait que si vous remettez un objet contenant ces données à un autre objet/processus, vous ne pouvez pas contrôler l'accès aux fonctions «normales», donc techniquement vous ne protégez pas les données - bien que cela soit possible de rendre les méthodes qui montrent ensemble de données sensibles local uniquement accessibles)

vous pourrait aussi investigate the call stack à chaque appel et essayer de savoir si vous voulez retourner les données complètes ou la version obscurcie - cela va ajouter assez peu de frais généraux et pourrait être très difficile à déboguer.

Answer 3

J'écrirais un formateur obfuscating pour ces champs et l'utiliserais pour écrire dans le fichier journal.

Je vous demanderais également pourquoi vous continueriez à utiliser des primitives de chaîne au lieu d'objets qui pourraient encapsuler le comportement approprié.