日志记录/安全注意事项和敏感数据

Posted 2023-03-05

【中文标题】日志记录/安全注意事项和敏感数据

【英文标题】：Logging/Security considerations and sensitive data

【发布时间】：2016-02-13 18:04:06

【问题描述】：

我正在研究与 Web 应用程序的日志记录和安全性相关的一般“架构”。据我所知，记录所有请求/响应数据（不仅是访问日志，还有请求/响应的正文）被认为是最佳实践。它适用于安全分析、调试目的、审计等等。

存在一个问题，即在某些请求中传输敏感信息，例如密码和/或信用卡数据。

（请注意：当然，我使用的是 HTTPS，但密码和/或信用卡数据将在日志或日志文件中显示为纯文本。顺便说一下，我不存储信用卡数据，因为我是不符合 PCI DSS，我们将此数据传输给我们的合作伙伴，该合作伙伴符合 PCI DSS）。

目前，我记录和存储异地访问日志（所以日志没有请求/响应主体，但带有 GET 参数数据），我在应用程序代码中记录请求/响应主体数据（所以我能够决定什么样的数据去记录，并在将敏感数据写入日志之前将其擦除）。

但是，我正在考虑在应用程序之外实现（请求/响应主体的）日志记录，让我们通过一些模块（例如 mod_dumpio 或类似的东西）在服务器级别说，但在这种情况下，记录敏感信息可能是个大问题。

我应该如何实现/配置它？

【问题讨论】：

如果您能告诉我们您使用哪种框架进行日志记录，那么对我们来说会更容易。如果您使用的是 log4j，请尝试阅读此 ***.com/questions/2461726/…。

"...密码和/或信用卡数据将在日志或日志文件中显示为纯文本。" 无论您做什么，都不要永远 记录信用卡信息或密码！！！！！！

【参考方案1】：

在处理敏感数据时，您应该考虑几种最佳做法。

首先，尽量减少您传输的所有敏感数据。通过在架构中尽早对密码进行哈希处理，您可以确保任何下游组件都不会冒暴露敏感数据的风险。

其次，与前一点相关联，您应该限制/隔离曾经收到此敏感信息的组件。对于密码，只有身份验证服务器才需要此信息 - 其余组件实际上应该只处理授权令牌（或类似的东西）。关于信用卡，这可能只应该关联与那些永远需要它的服务一起使用 - 例如您系统的结帐/计费组件。

第三，对于那些确实需要为逻辑获取敏感信息的实际价值的系统（例如信用卡），您应该考虑创建/使用类似令牌的系统。这基本上是您可以存储敏感信息并提供替换原始敏感数据元素的 ID 参考的地方（例如，将信用卡号交换为信用卡号 ID）。

要结束解决方案，请在尽可能靠近边缘的位置（例如您获取信用卡的位置）交换敏感数据，以换取此令牌。将此令牌交换为敏感信息值（具有正确的授权）以取回该值，然后在可能的最晚时刻使用它。最后，审核在这些敏感点完成的日志记录，以确保它没有被明文记录。

这种设计模式是世界上一些最大的电子商务网站如何做到的。 （对不起，我不能透露是谁。）希望对您有所帮助！

【讨论】：

您是否建议对数据库中的敏感数据进行加密？或者对数据库的访问控制是否足够？

“在传输中和静态时加密数据”的旧规则仍然适用，因此，是的，您应该加密驻留在数据库中的数据。原因有很多，但也许最简单的方法就是说明它。如果您只考虑有人备份磁盘并恢复它 - 数据未加密，那么该系统可能会被利用。最后一件事，您可能需要考虑在字段级别加密数据 - 而不仅仅是整个数据库。它将为您在未来如何管理数据方面提供更大的灵活性 - 用于分片或归档等。

【参考方案2】：

您不应将敏感信息（例如用户密码或信用卡详细信息）存储在日志文件中，使用信用卡详细信息执行此操作将意味着您违反 PCI 合规性（如您所述）。对于用户密码，应该不需要记录它们 - 您应该检查用户的输入密码，使用您使用的任何方法进行哈希处理，并使用您存储在数据库中的密码。

在不知道您使用的是什么技术的情况下，最佳做法是建议过滤掉这些参数。例如，Ruby on Rails 框架有（有？）filter_parameter_loggingmethod，您可以将要过滤的输入传递给它 - 然后这些输入将在您的日志文件中被屏蔽。在你的应用程序中实现类似的东西可能是值得的，这样任何名为“password”、“card_number”或任何你定义黑名单的字段都不会被记录。