2

我正在生成有关用户操作的日志记录。出于隐私原因，这些需要在 N 天后匿名。但是，我还需要针对这些匿名数据运行报告。

我希望真实用户 A 的所有操作都列在匿名日志中的假用户 X 下 - 一个用户的记录必须仍然是日志中一个（假）用户的记录。这显然意味着我需要在真实用户和虚假用户之间进行一些映射，我在匿名新记录时使用它。当然，这完全违背了匿名化的意义——如果有映射，则可以恢复原始用户数据。

例子：

用户 Frank Müller 买了 3 罐汤。

三天后，用户 Frank Müller 要求退款 3 罐汤。

当我匿名化第二个日志条目时，第一个已经被匿名化了。我仍然希望两个日志记录都指向同一个用户。嗯，这在实践中对我来说似乎几乎是不可能的，所以我想使用一些拆分数据的方法，希望能让我在数据中保持尽可能多的完整性。也许将日志用作数据仓库 - 将所有内容分解为事实并接受某些维度无法分析的事实？

你以前遇到过这样的场景吗？我在这里有什么选择？我显然需要做出某种妥协——什么对你有效？如何充分利用这些数据？

4

1 回答 1

7

冒着迂腐的风险，你描述的不是匿名数据，而是假名数据。也就是说，您是否考虑过使用某种键控散列函数（例如HMAC-SHA1）来执行假名生成？您可以通过以下方案达成公平妥协：

  • 分离您的分析和 OLTP 数据库。尽量减少可以同时访问两者的人数。
  • 将 HMAC 密钥保留给将数据复制到分析数据库的应用程序私有，不能从任一数据库访问。也许让应用程序在安装时生成它并使用硬编码的密钥对其进行混淆，这样系统管理员和软件开发人员都不会发现在没有串通的情况下获得它是微不足道的。
  • 不要从 OLTP 数据库中复制真实姓名和地址或任何等效或易于链接的键，例如用户编号、发票编号等，而不对其进行散列处理。

如果这样做，则有两种主要的攻击途径可以从假名中获取真实身份。

  • 直接攻击：获取 HMAC 密钥，计算每个已知用户的假名，并在结果表中反向查找。（HMAC 是不可逆的：只给定一个假名和密钥，您无法获得原始值。）
  • 信息融合攻击：在不知道密钥和身份列表的情况下，下一个最好的方法就是尝试将假名数据与其他数据相关联——甚至可能是 OLTP 数据库的被盗副本。

众所周知，假名数据集容易受到信息融合攻击——您必须剥离或“模糊”许多关键的相关信息才能使数据集抵抗此类攻击，但究竟需要剥离多少是当前的话题研究。

于 2009-05-12T08:33:55.840 回答