Logo

菜单

发布于 2026-01-06 10 阅读
0

8 种最佳日志记录实践，防止敏感数据泄露 DEV 全球展示挑战赛，由 Mux 呈现：展示你的项目！

保护敏感数据免受泄露的 8 种最佳日志记录实践

由 Mux 主办的 DEV 全球展示挑战赛：展示你的项目！

日志记录是软件开发过程中不可或缺的一部分。传统上，调试应用程序和基础设施性能一直高度依赖日志。日志有助于我们了解应用程序在每个基础设施组件中的运行情况。

日志数据包括内存不足错误和硬盘故障。这些信息非常有用，能够帮助我们找出问题根源，确定问题出现的原因。

日志数据通常包含有关应用程序、基础架构和数据库的关键信息。与用于控制生产数据库访问的安全机制相比，日志安全性可能不足。

日志语句

此外，人们很容易会忍不住记录敏感的客户数据，例如姓名和电子邮件地址，以此作为确定谁应对应用程序事件的发生负责以及在调试时生成全面审计跟踪的简单方法。

因此，数百万人的个人信息遭到泄露，这些信息经常在组织日志文件和数据库备份中被发现。

无论你从事的是医疗科技还是金融等高度敏感的行业，记录用户个人身份信息 (PII) 都存在合规性和安全风险，而这正是众多大数据泄露事件的根源。

在这篇文章中，我们将定义敏感数据，评估记录敏感数据的风险，并演示如何通过遵循记录敏感用户数据的最佳实践来避免这个问题。

让我们深入探讨一下！

敏感数据是什么意思？

在深入探讨最佳实践之前，我们先来谈谈什么是敏感数据。敏感数据是指必须采取措施防止未经授权访问的私人信息，例如个人信息、密码、凭证等等。

敏感数据大致可以分为以下几类：

  • 个人身份信息 (PII) - 这包括姓名、地址、电子邮件地址、驾驶证号码、安全密码、电话号码等信息。
  • 财务数据——银行账号、ATM密码等。
  • 医疗保健数据——包括医疗保健记录和病史等。
  • 密码
  • IP地址等。

尽管上述数据被视为敏感数据，并受 GDPR（通用数据保护条例）、PCI（支付卡行业数据安全标准）和 HIPAA（1996 年健康保险流通与责任法案）等合规要求的约束，但在您的业务和产品背景下评估数据敏感性至关重要。

在记录任何数据时，请考虑以下问题：“如果这些信息落入不法分子手中，可能会对我的组织造成什么影响？”

如果披露这些数据可能会损害贵公司的品牌或消费者信任，则应将其视为敏感信息，避免记录。

既然我们已经认识到必须将敏感数据从日志中排除，那么让我们来看看一些有助于我们实现这一目标的日志记录最佳实践。

为什么要将敏感数据排除在日志之外？

合规性和安全性是避免将敏感数据记录在日志中的主要原因。就合规性而言，根据隐私规则，用户有权了解其个人数据的收集情况、数据保存原因以及数据删除要求。

如果用户数据通过日志、数据库转储和备份等方式在系统中复制或分散，那么满足这些要求中的任何一项都将变得极其困难。

此外，日志经常成为数据入侵的目标，导致意外的数据泄露。例如，将敏感数据从日志中排除，可以大大降低任何攻击的影响。

既然我们已经了解了将敏感数据从日志中排除的重要性，那么让我们来学习一些在记录日志时可以遵循的最佳实践，以帮助实现这一目标。

如何将敏感数据排除在日志之外的最佳实践

1. 传输中数据加密

对传输中和静态数据进行加密，可以确保即使有人窃取了您的日志文件或数据库转储，他们也需要密钥才能解码和使用数据。

加密与解密

此外，由于网络服务器会频繁记录请求，因此传输中的数据（即使是在内部系统之间传输的数据）也必须确保安全。这将有助于防止加密的敏感数据泄露到您的记录中。

2. 隔离敏感数据

当您在系统间传输敏感数据（例如用户的姓名、电子邮件、地址和电话号码）时，某些 API 可能会记录这些数据，或者某些系统可能会将这些数据保存在您的数据库中。

对于敏感数据管理而言，单一数据源（例如数据隐私库）将是更好的解决方案。

数据隐私保险库可以帮助您隔离和保护保险库中的所有敏感数据，确保您的应用程序永远不会通过内部 API 传递敏感数据，也不会在应用程序数据库中存储敏感字段。

敏感数据不能包含在数据库备份、SQL 日志、应用程序日志或服务器日志中，因为它永远不会存在于被监控或备份的系统中。

3. 对敏感数据进行标记化

在向应用程序添加日志时，拥有用户标识符（例如姓名或电子邮件）可能对调试非常有帮助，并能节省大量时间，因此这看起来很诱人，但您应该避免这样做。

更简单的解决方案是通过令牌化过程将原始值的引用附加到日志记录中。这样一来，您就可以用敏感数据交换令牌。

分词示例

在您的敏感数据被隔离并存储在数据隐私库后，所有应用程序引用都将变成令牌。数据隔离和令牌化相结合，既能保障数据隐私，又能方便快捷地在您的信息中保留某种身份标识。

如有必要，您可以对令牌进行反令牌化处理，以获取原始敏感数据。

4. 避免在URL中包含敏感数据

在 Web 服务器上记录 URL 请求是一种常见的做法，如果您有类似 users/ 或 users/ 的 URL 模式，则用户的姓名和电子邮件地址很可能会被记录在服务器上，从而使服务器变得容易受到攻击。

为了缓解这个问题，请将 URL 中的敏感数据替换为任意用户 ID。这可以是用户的主密钥、UUID（通用唯一标识符）或任何其他形式的令牌。

UUID

5. 屏蔽或编辑敏感数据

除了令牌化之外，结合使用编辑和掩码也是防止敏感信息泄露到日志中的有效方法。某些应用程序可能只需要信用卡号或社会安全号码 (SSN) 的后四位数字。

数据脱敏是一种不可逆的单向处理方法，用于保护敏感数据。脱敏会生成一个与原始数据结构完全相同的敏感数据版本，但会隐藏字段中包含的最敏感数据。

与掩码不同，编辑会隐藏字段中的所有信息。

掩蔽

编辑

有些情况下，应用程序甚至不需要知道部分信息，在这种情况下，可以对敏感数据进行编辑而不是屏蔽。

如果正确遵循上述建议的做法，就可以有效地将敏感数据排除在日志之外；然而，只要有人参与，错误就不可避免。

以下是一些避免记录敏感数据以减少和消除记录过程中人为错误的技术最佳实践：

6. 代码审查

由于代码审查是软件开发中一项例行且频繁的活动，审查人员在进行代码审查时应确保没有可能泄露敏感数据的日志语句。

如果您使用的是 Pull Request 模板，请考虑添加一个复选框，以便审核人员确认他们已验证修改中的日志语句。

7. 结构化日志记录

结构化日志将日志转换为关系型数据集（例如键值对），而不是纯文本。结构化日志的优势在于易于检测和评估。它还有助于防止敏感信息泄露到日志中。

由于 JSON 的简洁性和适应性，它是构建结构化日志语句的绝佳选择；日志数据可以自动检索和检查，但消息对人来说仍然易于理解。

所有主流计算机语言都原生支持或通过库支持 JSON 日志记录。

例如，合并后的日志格式如下所示 -

31.22.86.126 - - 17/May/2015:08:05:24 +0000 "GET /downloads/product_1 HTTP/1.1" 304 0 "-" "Debian APT-HTTP/1.3 (0.8.16~exp12ubuntu10.16)"
Enter fullscreen mode Exit fullscreen mode

而由 Nginx Web 服务器生成的 JSON 格式的日志示例行看起来会像这样：

{
"time": "17/May/2015:08:05:24 +0000",
"remote_ip": "31.22.86.126",
"remote_user": "-",
"request": "GET /downloads/product_1 HTTP/1.1",
"response": 304,
"bytes": 0,
"referrer": "-",
"agent": "Debian APT-HTTP/1.3 (0.8.16~exp12ubuntu10.16)"
}
Enter fullscreen mode Exit fullscreen mode

在日志记录过程中，您可以利用启发式方法来确定数据集中的任何键是否与已知的敏感数据字段相关联。如果存在这种情况，则不应将这些数据集发布到日志中。

可以使用启发式方法来比较姓名、电子邮件和密码等字段。这种方法并非完美无缺，但它包含一些自动化测试。

8. 自动警报

最后一步是创建一个自动化服务，用于搜索现有日志中的敏感信息，并在发现任何敏感信息时通知团队。这看似多余或不必要，但却有助于检测系统缺陷。

以下是一些警报中经常提及的要点：

  • 时间和日期
  • 主机名
  • 应用程序名称
  • 受此错误影响的客户或账户
  • 访客的 IP 地址或其他地理指标
  • 未处理的异常数据
  • 它所在的行号（如有）
  • 错误分类（致命错误、警告错误等）

结论

简而言之，无论是有意还是无意，都必须尽一切努力防止日志系统成为基础设施安全性和隐私性的薄弱环节。

因此，我们在本文中探讨了八项最佳实践，这些实践可以帮助您和您的团队将敏感数据排除在日志之外。

培养一种重视记录敏感信息风险的工程文化，有助于避免未来出现问题。确保敏感数据不被记录应该是整个技术组织的共同责任，而不是某个人的唯一责任。

希望对您有所帮助。如有遗漏之处，请告知。

文章来源：https://dev.to/pragativerma18/8-best-logging-practices-to-keep-sensitive-data-out-39p9
调试的艺术
微前端详解