Logging/Security considerations and sensitive data

时间:2015-11-12 12:05:47

标签: security logging

I am working on general "architecture" related to logging and security of web applications. As far as I know, it is considered the best practice to log all request/response data (not only access logs, but the body of the requests/responses). It's good for security analysis, debugging purposes, audit and many more things.

There is an issue, that sensitive information is transferred in some requests, for example, passwords and/or credit card data.

(Please note: of course, I am using HTTPS, but passwords and/or credit card data will appear as plain text in logging or log files. And by the way, I do not store credit card data, because I am not PCI DSS compliant, we transfer this data to our partner, who is PCI DSS compliant).

Currently, I log and store offsite access logs (so logs without request/response bodies, but with GET parameters data) and I log request/response body data in application code (so I am able do decide what kind of data goes to log, and erase sensitive data before writing it to log).

However, I am thinking to implement the logging (of request/response bodies) outside the application, lets say on the server level via some module (for example, mod_dumpio or something similar), but in this case, logging the sensitive information might be a big issue.

How should I implement/configure it?

2 个答案:

答案 0 :(得分:4)

您不应将敏感信息(如用户密码或信用卡详细信息)存储在日志文件中,使用信用卡详细信息执行此操作将意味着您违反PCI合规性(正如您所指出的那样)。对于用户密码,不需要记录它们 - 您应该检查用户的输入密码,使用您使用的任何方法进行散列,并使用您存储在数据库中的密码。

在不知道您使用的技术的情况下,最佳做法会建议过滤掉这些参数。例如,Ruby on Rails框架已经(有?)一个filter_parameter_logging method,您可以将要过滤的输入传递给它 - 这些输入将在您的日志文件中被屏蔽。可能值得在您的应用程序中实现类似的东西,以便任何字段称为"密码"," card_number"或者你定义的黑名单都没有被记录。

答案 1 :(得分:4)

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

首先,最小化您传输的所有敏感数据。通过在架构中尽早散列密码,您可以确保任何下游组件都不会冒着暴露敏感数据的风险。

其次,与先前的点相关联,您应该约束/隔离曾经收到此敏感信息的组件。对于密码,只有身份验证服务器才需要这些信息 - 其余的组件应该只处理授权令牌(或类似的东西)。对于信用卡,这应该只是关联使用那些需要它的服务 - 例如系统的结账/计费组件。

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

要关闭解决方案,请尽可能靠近边缘交换敏感数据(例如,您获取信用卡的地方)以换取此令牌。将此令牌交换为敏感信息值(使用正确的授权)以获取值,然后在最近的可能时刻使用它。最后,审核在这些敏感点完成的日志记录,以确保它没有以明文形式登录。

这种设计模式是世界上一些最大的电子商务网站如何做到的。 (对不起,我不允许透露谁。)希望它有所帮助!