在日志文件中隐藏敏感/机密信息
您将如何隐藏敏感信息以免进入日志文件?是的，您可以有意识地选择不首先记录敏感信息，但是在某些情况下，您通常会在失败时盲目记录错误消息，或者在调查问题时跟踪消息等，最终导致敏感信息落入您的系统中日志文件.
How would you go about hiding sensitive information from going into log files? Yes, you can consciously choose not to log sensitive bits of information in the first place, but there can be general cases where you blindly log error messages upon failures or trace messages while investigating a problem etc. and end up with sensitive information landing in your log files.
例如，您可能试图将包含客户信用卡号的订单记录插入数据库中.数据库发生故障时，您可能希望记录刚刚执行的SQL语句.然后，您将在日志文件中获得客户的信用卡号.
For example, you could be trying to insert an order record that contains the credit card number of a customer into the database. Upon a database failure, you may want to log the SQL statement that was just executed. You would then end up with the credit card number of the customer in a log file.
是否存在一种设计范例可以用来将某些信息位标记"为敏感信息，以便通用日志记录管道可以将其过滤掉?
Is there a design paradigm that can be employed to "tag" certain bits of information as sensitive so that a generic logging pipeline can filter them out?
我目前针对该案例的做法是记录此类敏感信息的哈希值.这样一来，我们就可以识别属于特定索赔(例如特定信用卡号)的日志记录，但是却没有赋予任何*力来抓取日志并将敏感信息用于其邪恶目的.
My current practice for the case in question is to log a hash of such sensitive information. This enables us to identify log records that belong to a specific claim (for example a specific credit-card number) but does not give anybody the power to just grab the logs and use the sensitive information for their evil purposes.
当然，始终如一地进行此操作涉及良好的编码习惯.我通常选择使用所有对象的 toString 重载(在Java或.NET中)记录所有对象，该重载会序列化标记有应用了对象的 Sensitive 属性的字段的值的哈希值.
Of course, doing this consistently involves good coding practices. I usually choose to log all objects using their toString overloads (in Java or .NET) which serializes the hash of the values for fields marked with a Sensitive attribute applied to them.
当然，SQL字符串存在更多问题，但是我们更加依赖ORM进行数据持久化，并在各个阶段记录系统状态，然后记录SQL查询，因此这不是问题.
Of course, SQL strings are more problematic, but we rely more on our ORM for data persistence and log the state of the system at various stages then log SQL queries, thus it is becomes a non-issue.