Quelles informations ne doivent jamais apparaître dans les journaux? [fermé]

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.

Je crois que la meilleure façon de gérer cela est de traiter les fichiers journaux comme une autre interface utilisateur de l'application. Le fait que les informations soient stockées dans des fichiers texte ne rend pas le contenu différent des informations affichées sur les écrans normaux de l'interface utilisateur.

Réfléchissez à la manière dont vous protégeriez les mêmes informations si elles devaient être affichées dans une interface utilisateur standard. Vous devez identifier qui était l'utilisateur, puis exposer uniquement les informations que cet utilisateur était autorisé à voir.

Les informations contenues dans les fichiers journaux doivent être traitées de la même manière. Vous devez d'abord répondre exactement à qui doit avoir le droit de voir le fichier journal et quelles informations il doit être autorisé à voir.

La transmission de fichiers journaux mal conçus représente un énorme risque pour la sécurité. Je ne pense pas que vous obtiendrez une bonne solution à cela en mettant sur liste noire certaines sortes de données. Une meilleure stratégie consiste à mettre en liste blanche ce qui pourrait se trouver dans chaque fichier journal et à concevoir les fichiers journaux de bas en haut.

Les informations de carte de crédit ne doivent jamais être enregistrées.

Numéros d'identification (tels que SSN aux États-Unis ou Teudat Zehut # en Israël).

Noms d'ordinateurs réseau, chemins de partage réseau.

Informations personnelles identifiables sur la santé couvertes par la loi de 1996 sur la transférabilité et la responsabilité en matière d'assurance maladie (HIPAA). Cet article répertorie les exemples suivants:

• Les demandes de remboursement de soins de santé ou les informations sur les soins de santé, telles que la documentation des visites chez le médecin et les notes prises par les médecins et les autres membres du personnel soignant;
• Conseils en matière de paiement et d'envoi de soins de santé;
• Coordination des prestations de soins de santé;
• Statut de réclamation de soins de santé;
• Inscription et désinscription dans un plan de santé;
• Admissibilité à un plan de santé;
• Paiement des primes du plan de santé;
• Certifications et autorisation de référence;
• Premier rapport de blessure;
• Pièces jointes aux allégations santé.

si la sécurité est un problème, cryptez le fichier journal

Du haut de ma tête....

Les informations de carte de crédit ne doivent pas figurer dans les journaux. Les données SSN (ou SIN) ne doivent pas figurer dans les journaux.

... bien sûr, il y a des exceptions, si vous travaillez pour un magasin de données central pour une société de cartes de crédit ou un organisme gouvernemental qui gère les données du NAS, vous devrez peut- être les enregistrer, car c'est la principale viande de ce que vous suis en train de traiter / gérer.

Oui mais.

Pour déboguer certains problèmes, vous avez besoin de données réelles.

Il faut donc jouer un jeu d'équilibre: vous devez en effet discuter et convenir avec vos principaux clients de ce qu'ils considèrent comme confidentiel ou sensible et non. Si plusieurs clients ne sont pas d'accord, prenez le pire des scénarios pour chaque aspect de celui-ci, à moins que vous ne puissiez le justifier auprès des clients qui pourraient exagérer en étiquetant tout ce qui est sensible.

J'ai travaillé dans le contrôle du trafic aérien, la finance et la banque. Dans chaque situation, il existe des données sensibles. Il y a des tâches pour lesquelles il est inévitable de traiter des données sensibles, dans ces cas, vous devez vous assurer que vous travaillez avec des personnes de confiance. Ce risque peut être quelque peu atténué par des clauses légales à convenir avant d'accéder à ces données (accords de non-divulgation, utilisation des données uniquement pour des raisons commerciales valables, accès limité aux données, sanctions pénales pour non-respect ou application des accords ...) - et des processus pertinents qui permettent de suivre ces choses.

Si les données sont essentielles, vous devez payer le prix de la mise en place de systèmes qui protègent l'intégrité, la cohérence et la sécurité de ces données.

Cela dit, vous avez raison de poser la question «quelles données». Vraiment, vous y répondez vous-même: la plupart sont liés aux affaires. Demandez donc à vos clients si vous ne pouvez pas répondre vous-même - en gardant à l'esprit tout ce qui précède et en conservant un moyen d'identifier et de résoudre les problèmes qui peuvent survenir.

Je dirais, enregistrez des messages qui semblent drôles pendant que vous codez. Vous ne les trouverez pas drôles sur toute la ligne et ils seront là pour toujours - tout comme ce blog / facebook / twiter mal avisé!

Gardez les messages du journal ennuyeux :)