这里显然有两条不同的防线。

首先，绝不能记录高度敏感的数据（秘密，通常是密码），以避免通过日志泄露。

但是，攻击者对系统了解得越多，构建/使用目标攻击的风险就越高。例如，软件版本不是高度敏感的，可以合理地提供日志，但它们可以帮助选择攻击向量。

所以第二道防线是不需要访问日志的人不应该能够读取它们。这是最小特权规则的直接应用。

向开发/维护团队提供日志访问是很常见的，但您应该根据您的访问安全工具评估风险/收益比。最安全的系统是任何用户都无法访问的系统，但它的可用性也很低......

对原始日志数据的访问应仅限于授权用户。

原因很简单，即使在正常操作条件下，您的应用程序可能 不应该记录任何过于敏感而无法公开的数据（并且关于确切内容的意见/法规可能会有所不同），几乎可以肯定会有一段时间您的日志确实包含敏感数据：

• 除非您非常熟悉您的应用程序，否则您不会事先知道当应用程序抛出错误或异常时会记录哪些详细信息。
  大多数应用程序旨在限制它们呈现给最终用户的错误消息中的详细信息量，但会在其日志中记录（更多）详细信息，以帮助管理员和开发人员排除这些错误和异常的原因。

• 您可能需要将故障排除的日志详细程度提高到日志将包含通常会被抑制的敏感详细信息的级别。

• 正如人们评论的那样：人们使用 GET 方法而不是 POST 为登录名和开发人员输入密码，以及无数类似的人为错误可能会导致日志事件中更无害的字段被敏感数据“污染”。

有些产品允许您授予经过身份验证的用户基于 Web 的访问权限，并将 ACL 设置为仅聚合报告、清理/过滤的日志数据和/或所有原始日志事件，例如 Splunk、Kibana 等。

尽管应该限制对原始日志数据的访问，您仍然可以决定更公开地发布经过清理的日志子集或您将基于日志生成的报告，即发布使用情况报告和访问者统计数据，而不是原始访问日志

它有更多的观点：

1) 通过不隐藏日志，您会暴露您的基础架构。

2) 欧盟有 GDPR。禁止公开 IP、姓名、电子邮件或任何个人信息。（至少是不道德和不良行为）gdpr-info.eu/art-32-gdpr

如果您需要将记录的数据显示给第三方或易于访问，请使用专用工具。例如，在我的办公室里，它是灰色日志。您可以轻松地收获日志、存储它们并控制对它们的访问。

写入日志文件的信息类型可能产生的漏洞在 Common Weakness Enumeration 数据库中被列举为CWE-532 。

写入日志文件的信息可能具有敏感性质，可为攻击者提供有价值的指导或暴露敏感的用户信息。

正如上面@KOLEGA 的回答中所述，受保护的个人身份信息问题也非常相关。