【问题标题】:Hiding sensitive/confidential information in log files在日志文件中隐藏敏感/机密信息
【发布时间】:2010-11-30 19:33:43
【问题描述】:

您将如何隐藏敏感信息以防止进入日志文件?是的,您可以有意识地选择不首先记录敏感信息,但在一般情况下,您可能会在调查问题时盲目地记录错误消息或跟踪消息等,最终导致敏感信息进入您的日志文件。

例如,您可能尝试将包含客户信用卡号的订单记录插入数据库。在数据库发生故障时,您可能希望记录刚刚执行的 SQL 语句。然后,您最终会在日志文件中获得客户的信用卡号。

是否有一种设计范式可用于将某些信息“标记”为敏感信息,以便通用日志管道可以过滤掉它们?

【问题讨论】:

  • 关于将这个问题移至 serverfault.com 的建议:否。这个问题是从软件的角度来看的。你想确保你的软件足够聪明,可以帮助用户屏蔽敏感信息。这实际上是我从现实客户那里看到的现实需求。
  • *你是 -> 你的(7 年后)

标签: security language-agnostic logging privacy


【解决方案1】:

我目前针对该案例的做法是记录此类敏感信息的哈希值。这使我们能够识别属于特定声明(例如特定信用卡号)的日志记录,但不会赋予任何人获取日志并将敏感信息用于其邪恶目的的权力。

当然,这样做始终需要良好的编码实践。我通常选择使用 toString 重载(在 Java 或 .NET 中)记录所有对象,这会序列化标记有 Sensitive 属性的字段值的哈希值。

当然,SQL 字符串问题更大,但是我们更多地依赖我们的 ORM 来进行数据持久化,并在各个阶段记录系统的状态,然后记录 SQL 查询,因此这不是问题。

【讨论】:

  • 我喜欢覆盖 toSource 的想法;这样,日志记录代码就不必关心正在记录的内容。虽然它没有解决内存转储的问题,但我会接受这是最佳答案,因为它直接回答了原始问题。谢谢!
  • 是的,但是信用卡号码的哈希对于暴力破解(或构建彩虹表)来说是微不足道的
  • @AndreyFedorov 好点,当然是这样。最好使用应用程序已知的密钥记录这些类型的恒定长度字符串的 HMAC。因此,当/如果出现索赔时,可以再次计算 HMAC 以进行查找,但获得日志的攻击者将无法使用暴力破解或构建彩虹表来恢复 HMAC。
  • 是的,除非攻击者当然也获得了“应用程序已知密钥”。然而,这似乎是不可避免的。
【解决方案2】:

我个人会将日志文件本身视为敏感信息,并确保限制对它们的访问。

【讨论】:

  • 真的!我正在考虑您是软件供应商并要求您的客户从他们的系统向您发送日志文件以诊断系统崩溃等的情况。客户是否有责任首先清理他们的日志文件敏感信息?如果您的系统有办法让客户免费获得它,那不是很好吗?
  • “限制访问”不够具体,无法为信用卡信息提供足够的保护。日志需要加密,并且需要在安全策略中说明对解密密钥的访问权限。
【解决方案3】:

记录信用卡号可能违反 PCI。如果您不符合 PCI 标准,您将被收取更高的卡处理费用。要么不记录敏感信息,要么加密整个日志文件。

您“标记”敏感信息的想法很有趣。对于Sensitive 信息,您可以有一个特殊的数据类型,它包装了真实的底层数据类型。每当此对象呈现为字符串时,它只会返回 "***" 或其他任何内容。

但是,这可能需要进行广泛的编码更改,并且需要有一定程度的自觉警惕,类似于一开始就避免记录敏感信息所需的警惕。

【讨论】:

    【解决方案4】:

    在您的示例中,您应该加密信用卡号,或者更好的是,甚至不首先存储它。

    例如,如果您正在记录其他内容,例如登录,您可能希望明确地将密码替换为 *****。

    但是,这可以巧妙地避免回答您最初提出的问题。通常,在处理敏感信息时,应在将其传输到任何形式的永久存储(无论是数据库文件还是日志文件)的过程中对其进行加密。假设一个坏人将能够得到他们的手,并相应地保护信息。

    【讨论】:

    • 我认为加密可以解决问题:一旦敏感信息进入您的系统,它就会被加密并以加密方式存在。因此,如果您正在执行低级别日志记录(与语义无关),甚至进行内存转储,则信息将相当安全。我想我喜欢加密信息而不是其他答案中建议的整个日志文件的想法。
    【解决方案5】:

    如果您知道要过滤的内容,则可以在记录之前通过正则表达式清理表达式运行日志输出。

    【讨论】:

    • 是的,我想到了。事实上,这可能是一个可行的解决方案,因为总会有一些不同类型的“敏感”字符串,您可以使用正则表达式来识别这些字符串。
    【解决方案6】:

    特别是关于 SQL 语句,如果你的语言支持它,你应该使用参数而不是在语句本身中放置值。换句话说:

    select * from customers where credit_card = ?
    

    然后将参数设置为信用卡号。

    当然,如果你打算用填充参数记录 SQL 语句,你需要一些其他的方法来过滤掉敏感数据。

    【讨论】:

    • 是的。但这仅涵盖 SQL 语句。
    • 这就是为什么我以“特别关注 SQL 语句”作为开头的原因。它不是 100% 通用的。
    • 注明。我实际上是在寻找更多的灵丹妙药解决方案,而不是逐案分析,但感谢您的回答!
    【解决方案7】:

    参考这个工具,专为这个用例创建。

    如果您只想屏蔽选定的字段,在记录期间并保持其他字段值不变。你可以试试这个。

    https://github.com/senthilaru/sp-util

    <dependency>
        <groupId>com.immibytes</groupId>
        <artifactId>sp-utils</artifactId>
        <version>1.0.0-RELEASE</version>
    </dependency>
    

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2012-01-01
      • 1970-01-01
      • 2018-01-31
      • 2018-07-01
      • 1970-01-01
      • 2020-11-24
      • 1970-01-01
      相关资源
      最近更新 更多