如何转换机密数据集中的名称以使其匿名,但保留名称的某些特征?


42

动机

我使用的数据集包含个人身份信息(PII),有时需要与第三方共享数据集的一部分,以免暴露PII并使我的雇主承担责任。我们通常的做法是完全保留数据,或者在某些情况下降低其分辨率。例如,将确切的街道地址替换为相应的县或人口普查区。

这意味着即使第三方拥有更适合该任务的资源和专业知识,某些类型的分析和处理也必须在内部完成。由于未公开源数据,因此我们进行此分析和处理的方式缺乏透明度。结果,任何第三方执行QA / QC,调整参数或进行细化的能力可能都非常有限。

匿名机密数据

一项任务涉及在用户提交的数据中通过姓名识别个人,同时考虑到错误和不一致之处。私人可能在一个地方被记录为“戴夫”,而在另一地方被记录为“大卫”,商业实体可以具有许多不同的缩写,并且总是有一些错别字。我已经基于许多标准开发了脚本,这些标准确定两条具有不同名称的记录何时代表同一个人,并为其分配一个通用ID。

此时,我们可以通过保留名称并将其替换为该个人ID号来使数据集匿名。但这意味着接收者几乎没有关于例如比赛强度的信息。我们希望能够传递尽可能多的信息而不会泄露身份。

什么不起作用

例如,在保留编辑距离的同时能够加密字符串将是很棒的。这样,第三方可以执行自己的一些QA / QC,或选择自己进行进一步的处理,而无需访问(或可能进行反向工程)PII。也许我们在内部将编辑距离<= 2的字符串匹配起来,接收者想看看收紧该公差以编辑距离<= 1的含义。

但是我所熟悉的唯一做到这一点的方法是ROT13(更一般地说,是任何移位密码),它几乎不算作加密。就像颠倒地写下名字,然后说:“保证您不会把纸翻过来吗?”

另一个不好的解决办法是简化所有内容。“艾伦·罗伯茨”变成“ ER”,依此类推。这是一个较差的解决方案,因为在某些情况下,姓名缩写与公共数据结合会透露一个人的身份,而在另一些情况下,则太含糊了;“本杰明·奥赛罗·埃姆斯”和“美国银行”将使用相同的首字母缩写,但名称不同。因此,它无法满足我们的任何需求。

另一个不错的选择是引入其他字段来跟踪名称的某些属性,例如:

+-----+----+-------------------+-----------+--------+
| Row | ID | Name              | WordChars | Origin |
+-----+----+-------------------+-----------+--------+
| 1   | 17 | "AMELIA BEDELIA"  | (6, 7)    | Eng    |
+-----+----+-------------------+-----------+--------+
| 2   | 18 | "CHRISTOPH BAUER" | (9, 5)    | Ger    |
+-----+----+-------------------+-----------+--------+
| 3   | 18 | "C J BAUER"       | (1, 1, 5) | Ger    |
+-----+----+-------------------+-----------+--------+
| 4   | 19 | "FRANZ HELLER"    | (5, 6)    | Ger    |
+-----+----+-------------------+-----------+--------+

我称其为“无意义的”,因为它要求预期哪些质量可能很有趣,而且相对较粗略。如果名称被删除,则关于行2和行3之间的匹配强度或行2和行4之间的距离(即,它们与匹配的距离有多近),您将无法做出合理的结论。

结论

目的是对字符串进行转换,以在保留原始字符串的同时尽可能保留原始字符串的许多有用质量。无论数据集的大小如何,解密都应该是不可能的,或者实际上是不可能的。特别地,保留任意字符串之间的编辑距离的方法将非常有用。

我发现了几篇可能相关的论文,但它们让我有些头疼:

Answers:


19

我在OP中提到的参考文献之一使我找到了一个潜在的解决方案,该解决方案似乎非常强大,如“使用Bloom过滤器的隐私保护记录链接”(doi:10.1186 / 1472-6947-9-41)中所述:

已经开发了一种新的协议,该协议用于与加密标识符保持隐私的记录链接,从而允许标识符中的错误。该协议基于标识符q-gram上的Bloom过滤器。

本文详细介绍了该方法,在此将尽我所能进行总结。

布隆过滤器是固定长度的一系列位,用于存储一组固定的独立哈希函数的结果,每个哈希函数均基于相同的输入值进行计算。每个哈希函数的输出应该是过滤器中可能的索引中的索引值;即,如果您有一个由0索引的10位序列,则散列函数应返回(或映射到)从0到9的值。

过滤器从将每个位设置为0开始。使用哈希函数集中的每个函数对输入值进行哈希处理后,与任何哈希函数返回的索引值对应的每个位都设置为1。除了一个哈希函数,该索引的位仅设置一次。您可以将Bloom过滤器视为哈希集在固定位范围上的叠加。

上面链接的文章中描述的协议将字符串分为n-gram,在这种情况下为字符集。例如,"hello"可能会产生以下2克集:

["_h", "he", "el", "ll", "lo", "o_"]

构造n-gram时,用空格填充正面和背面似乎通常是可选的。提出该方法的论文中给出的示例都使用了这种填充。

可以对每个n-gram进行哈希运算以生成布隆过滤器,并且可以将这组布隆过滤器自身叠加(按位或运算)以生成字符串的布隆过滤器。

如果过滤器包含的位数比哈希函数或n-gram的位数多,则任意字符串相对不太可能产生完全相同的过滤器。但是,两个字符串共有的n-gram越多,它们的过滤器最终共享的位就越多。然后,您可以A, B通过它们的Dice系数比较任何两个过滤器:

D A,B = 2h /(a + b)

其中h,是在两个过滤器中均设置为1的位数,是a在过滤器A中设置为1的位数,在过滤器B中设置为1的位数。如果字符串完全相同,骰子系数将为1;它们之间的差异越大,系数就越接近。b0

因为哈希函数将不确定数量的唯一输入映射到少量可能的位索引,所以不同的输入可能会产生相同的过滤器,因此系数仅表示字符串相同或相似的概率。不同散列函数的数量和滤波器中的位数是确定误报可能性的重要参数-输入对与通过此方法预测的Dice系数相近得多。

我发现本教程对于理解Bloom过滤器非常有帮助。

该方法的实现具有一定的灵活性。另请参见此2010年论文(也在问题末尾链接),以了解与其他方法以及各种参数相比,性能如何。


将其标记为可接受的答案,因为在建议的方法中,对于我的特定用例而言,这是最有希望的。

感谢您提供所有这些详细信息和背景信息。您是否遇到过这种方法的任何实现(例如,在Python中)?
amball

@amball我没有。
航空

8

在阅读您的问题一半时,我意识到Levenshtein距离可以很好地解决您的问题。很高兴看到您有关于该主题的论文的链接,让我看看我能否对Levenshtein解决方案的外观有所了解。

Levenshtein距离在许多行业中用于实体解析,这使它有用的是它可以测量两个序列之间的差异。在字符串比较的情况下,它只是序列字符。

通过允许您提供一个数字来衡量另一个字段的文本有多相似,这可以帮助解决您的问题。

这是在您提供的数据中使用Levenshtein的基本方法示例:

在此处输入图片说明

这提供了一个好的解决方案,距离8可以提供某种关系的指示,并且非常符合PII。但是,它仍然不是超级有用,让我们看看如果做一些文字魔术仅取名字的名字首字母和全名放在中间的任何东西,会发生什么情况:

在此处输入图片说明

如您所见,Levenshtein距离0很好地表明了这种关系。通常,数据提供者会将一堆姓氏和名字的Levenshtein排列与1、2或所有字符组合在一起,只是为了提供一些关于实体之间如何关联的维度,同时仍保持数据内部的匿名性。


1
我对链接的论文感兴趣的是它声称展示了一种无需知道两个输入字符串即可执行这种计算的方法。在本文中,每个演员都具有一个字符串的知识,这对我的目的没有帮助;我需要一个演员来执行计算而无需任何字符串的知识。事先计算它们仅适用于非常小的数据集或非常有限的产品。我的数据集上整数距离的完整叉积将需要〜10 PB的存储空间。
航空

这就是为什么我提出替换密码(ROT13)的想法,因为它保留了字符串之间的距离。但是它并不安全,我怀疑在保留编辑距离的同时安全地加密字符串是不可能的。(真想错了!)
空中

是的,我只过滤矩阵,使其仅包含低于某个临界值的Levenshteins,因此您仅在出现重叠的可能性较高的地方进行填充。此外,在涉及PII时,我的想法是,如果您包含足够的信息来确定数据集中不同实体之间的关系,那么您不太可能保留客户的匿名性。匿名化数据的目的是避免潜在的与PII相关的监管难题(标准可以随时收紧),所以我个人不会冒险。
neone4373 2014年

7

如果可行,我将链接相关记录(例如Dave,David等),并用序列号(1、2、3等)或用于表示所有相关记录的字符串盐腌 哈希替换它们(例如,戴维(David)而非戴夫(Dave)。

我认为第三方不必知道真实名称是什么,否则您也可以将其提供给他们。

编辑:您需要定义并证明第三方需要执行哪种操作。例如,使用首字母后跟数字(例如BOA-1,BOA-2等)来将美国银行与本杰明·奥赛罗·埃姆斯区分开来,这是怎么回事?如果太暴露了,您可以将某些字母或名称分类;例如[AE]-> 1,[FJ]-> 2,等等,因此BOA将变为1OA,或[[Bank],“ Barry”,“ Bruce”等]-> 1,因此美国银行再次成为1OA。

有关更多信息,请参见k-anonymity


欣赏k-匿名性参考和bin建议-这给了我一些新的思考的内容。
航空

6

一种选择(取决于您的数据集大小)是仅提供编辑距离(或您正在使用的其他相似性度量)作为附加数据集。

例如:

  1. 在数据集中生成一组唯一的名称
  2. 对于每个名称,计算彼此之间的编辑距离
  3. 为每个名称生成一个ID或不可逆的哈希
  4. 用此ID替换原始数据集中的名称
  5. 提供ID编号之间的编辑距离矩阵作为新数据集

尽管仍然可以做很多工作来消除来自这些数据的匿名性。

例如,如果已知“ Tim”是男孩的最受欢迎名字,那么ID的频率计数与整个人口中Tims的已知百分比非常匹配,则可能会忽略这一点。然后,您可以从那里查找编辑距离为1的名称,并得出结论,这些ID可能引用“ Tom”或“ Jim”(当与其他信息结合使用时)。


5

我不太确定,但是对位置敏感的哈希可能是一个很好的解决方案。它会对输入数据(在您的情况下为名称)进行哈希处理,因此将保留原始字符串。另一方面,LSH的主要思想是使相似项目的散列可能性最大化。有很多不同的LSH实现。我尝试使用Nilsimsa-hash来比较tweet文本,并且效果很好。但是我不确定在短字符串(名称)的情况下它将如何工作-这个问题需要测试。我尝试了您的示例,这是结果(名称A,名称B,“距离”-最大值为120):

1. AMELIA BEDELIA  - CHRISTOPH BAUER - 107
2. AMELIA BEDELIA  - C J BAUER       - 82
3. AMELIA BEDELIA  - FRANZ HELLER    - 91
4. CHRISTOPH BAUER - C J BAUER       - 81
5. CHRISTOPH BAUER - FRANZ HELLER    - 98
6. C J BAUER       - FRANZ HELLER    - 83

如您所见,CHRISTOPH BAUER和CJ BAUER成为最接近的一对。但是差异并不大。仅作为示例-这些名称的哈希表示:

AMELIA BEDELIA  6b208299602b5000c3005a048122a43a828020889042240005011c1880864502
CHRISTOPH BAUER 22226448000ab10102e2860b52062487ff0000928e0822ee106028016cc01237
C J BAUER       2282204100961060048050004400240006032400148000802000a80130402002
FRANZ HELLER    58002002400880080b49172044020008030002442631e004009195020ad01158

3

这是我未曾提及的一种方法:将流程分为两个步骤:第一步着重于编码名称,以便相同名称的替代版本被编码为相同(或几乎相同),第二步着重于他们匿名。

对于第一步,您可以使用以各种顺序应用于名字,姓氏和首字母的语音算法(Soundex和变体)之一。(另请参见本文)。在此步骤中,您将解决名称的相似性与差异,以平衡误报与误报。

第二步,您可以选择任何喜欢的哈希或加密方法,而不必担心该方法如何影响名称匹配。这使您可以自由选择使用性能,鲁棒性和匿名性均最佳的方法。


我认为这个建议不能解决问题中提出的问题。灵活性后加密在哪里?如何在不访问原始数据的情况下优化分析?
航空

@AirThomas对不起,但我不明白您的两个问题。“灵活性后加密”是什么意思?在您的问题/说明中,我什么都没看到。您的意思是“无需访问原始数据即可优化分析”?我对“提炼”一无所知。
MrMeritology 2014年

1
我试图在动机部分的第二段中找到问题所在。例如,想象一下,您想将数据集发布给想要进行建模的各种研究人员。可以采用许多聪明有效的方法,每个研究人员的工作方式也有所不同。您无法在数据集中透露私人姓名。如果您在发布数据之前执行那部分分析,则将迫使您选择适用于所有人的方法。

如果您还提供名称的哈希,则好处是第三方可以区分确切的身份,但不能再区分。因此,问题是,您如何才能提供有关无法发布的数据的更多信息?例如,是否有一种方法可以在散列/加密输出中保留任意输入之间的编辑距离?我发现至少一种至少可以近似该功能的方法(有关更多信息,请参阅我自己的答案)。我希望这可以使事情变得更清楚。
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.