Je suis sur le point d'écrire les directives de l'entreprise sur ce qui ne doit jamais apparaître dans les journaux (trace d'une application). En fait, certains développeurs tentent d'inclure autant d'informations que possible dans la trace, ce qui rend le stockage de ces journaux risqué et extrêmement dangereux de les soumettre , surtout lorsque le client ne sait pas que ces informations sont stockées, car il ne s'est jamais soucié de cela et ne jamais lire la documentation et / ou les messages d'avertissement.
Par exemple, lorsqu'ils traitent des fichiers, certains développeurs sont tentés de tracer les noms des fichiers . Par exemple, avant d'ajouter le nom du fichier à un répertoire, si nous suivons tout par erreur, il sera facile de remarquer par exemple que le nom ajouté est trop long, et que le bogue dans le code devait oublier de vérifier la longueur du chaîne concaténée. C'est utile, mais ce sont des données sensibles et ne doivent jamais apparaître dans les journaux .
De la même manière:
- Mots de passe ,
- Adresses IP et informations réseau (adresse MAC, nom d'hôte, etc.) ¹,
- Accès aux bases de données,
- Saisie directe à partir de l'utilisateur et des données d'entreprise stockées
ne doit jamais apparaître en trace.
Alors, quels autres types d'informations doivent être bannis des journaux? Y a-t-il des directives déjà écrites que je peux utiliser?
¹ Évidemment, je ne parle pas de choses comme les journaux IIS ou Apache. Ce dont je parle, c'est du type d'informations qui sont collectées dans le seul but de déboguer l'application elle-même, et non de retracer l'activité d'entités non fiables.
Edit: Merci pour vos réponses et vos commentaires. Comme ma question n'est pas trop précise, je vais essayer de répondre aux questions posées dans les commentaires:
- Qu'est-ce que je fais avec les journaux?
Les journaux de l'application peuvent être stockés en mémoire, ce qui signifie soit en clair sur le disque dur de l'hôte local, dans une base de données, encore en clair, soit dans les événements Windows. Dans tous les cas, la crainte est que ces sources ne soient pas suffisamment sûres. Par exemple, lorsqu'un client exécute une application et que cette application stocke les journaux dans un fichier texte brut dans le répertoire temporaire, toute personne ayant un accès physique au PC peut lire ces journaux.
Les journaux de l'application peuvent également être envoyés via Internet. Par exemple, si un client a un problème avec une application, nous pouvons lui demander d'exécuter cette application en mode trace complète et de nous envoyer le fichier journal. De plus, certaines applications peuvent nous envoyer automatiquement le rapport de plantage (et même s'il y a des avertissements sur les données sensibles, dans la plupart des cas, les clients ne les lisent pas).
- Suis-je en train de parler de domaines spécifiques?
Non. Je travaille uniquement sur des applications commerciales générales, donc les seules données sensibles sont les données commerciales. Il n'y a rien lié à la santé ou à d'autres domaines couverts par des réglementations spécifiques. Mais merci d'en parler, je devrais probablement jeter un coup d'œil sur ces champs pour quelques indices sur ce que je peux inclure dans les directives.
- N'est-il pas plus facile de crypter les données?
Non. Cela rendrait chaque application beaucoup plus difficile, surtout si nous voulons utiliser les diagnostics C # et TraceSource
. Il faudrait également gérer les autorisations, ce qui n'est pas le plus simple à penser. Enfin, si nous parlons des logs qui nous sont soumis par un client, nous devons pouvoir lire les logs, mais sans avoir accès aux données sensibles. Donc, techniquement, il est plus facile de ne jamais inclure d'informations sensibles dans les journaux et de ne jamais se soucier de savoir comment et où ces journaux sont stockés.
debug
un nom de fichier, mais pas àinfo
un nom de fichier.