代码之家 › 专栏 › 技术社区 › Sander

如何匿名化新的日志记录而不破坏新旧数据之间的关系?

privacy foreign-keys logging

Sander · 技术社区 · 15 年前

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

我希望真实用户A的所有操作都列在匿名日志中的假用户X下-一个用户的记录必须仍然保留日志中一个(假)用户的记录。这显然意味着我需要在真实用户和假用户之间建立一些映射,这是我在匿名化新记录时使用的。当然,这完全颠覆了匿名化的观点——如果有一个映射,原始用户数据就可以恢复。

例子:

用户Frank M_¼ller购买了3罐汤。

三天后,用户Frank M_¼ller要求退款3罐汤。

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

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

1 回复 | 直到 15 年前

stonecrusher 7 年前

冒着学究的危险,你所描述的并不是 匿名的 数据,而是 假名的 数据。也就是说,您是否考虑过使用某种键控哈希函数,例如 HMAC-SHA1 要执行笔名生成吗?你可以通过这样的计划达成一个公平的妥协:

分离您的分析和OLTP数据库。最小化可以同时访问这两者的人数。
将HMAC密钥保留为将数据复制到分析数据库的应用程序的私有,这两个数据库都无法访问。也许让应用程序在安装时生成它,并使用硬编码密钥将其混淆,这样系统管理员和软件开发人员都不会发现不合谋就能轻松应对。
不要复制真实姓名和地址 或任何等效或容易链接的密钥,如用户编号、发票编号等。 在没有散列的情况下从OLTP数据库。

如果你这样做,有两个主要的攻击途径,以从假名中获得真实身份。

匿名数据集是 notoriously vulnerable 对于信息融合攻击——您必须去除或“模糊”大量关键的相关信息,以使数据集能够抵御此类攻击,但是您需要去除的确切数量是 topic of current research .