快速搜索加密数据？

Question

我已经要求加密应用程序数据库中的个人身份信息（PII）数据。该应用程序在系统中使用智能搜索，如名称根和部分词搜索快速查找姓名和地址。

如果我们对这些字段（在应用层加密的PII数据）进行加密，搜索将受到记录量的影响，因为我们无法以正常方式依赖SQL，并且搜索引擎（在应用程序）将切换到读取所有值，解密它们并执行搜索。

有没有解决这个问题的简单方法，所以我们总是可以加密PII数据，并为我们的用户提供快速搜索功能？

我们使用PHP Web/App层（Zend Server和SQL Server DB）。该应用目前不使用类似技术的Lucene等

感谢

干杯

Answer 1

加密也使得它看起来很大像随机比特串数据。这排除了通过索引进行快捷搜索的任何操作。

对于一些加密数据，例如社会安全号码，您可以将数字的散列存储在单独的列中，然后索引此散列字段并搜索散列。这显然有用，并且在搜索名称中没有任何价值，如'ROB％'

如果您的数据库安全得当，听起来不错，但如果坏人可以入侵并窃取您的信息，则很难实现服务器或备份。如果它是真正的要求（不仅仅是一个可协商的营销驱动项目），你必须遵守。

您可能能够协商以未加密方式存储部分数据，例如姓氏的前3个字符或类似内容，以便您仍然可以使用有用的索引（如果不是完美的）。

ADDED

我应该补充说，你可能会被允许散列名称字段的一部分，并在该散列搜索 - 假设你是不是允许存储部分名称未加密的 - 你再次失去效用，但它可能仍然比没有指数更好。

为了使这个散列有用，它不能被播种 - 即所有记录必须基于相同的种子（或没有种子）散列，否则你会被卡在执行表扫描。

您还可以创建一个覆盖索引，当然仍然是加密的，但由于需要的I/O内存减少，表扫描可能会更快。

Answer 2

有时，“加密数据”的确意味着“静态加密数据”。也就是说，您可以使用透明数据加密来保护数据库文件，备份等，但通过查询可以清楚地看到数据。看看这是否足以满足你试图满足的任何规定，这将使你的工作变得更容易。

Answer 3

我会尽力写这个，因为经常加密社区可能很难理解（我抵制插入双关语的冲动）。

我用一个具体的解决方案，很好地工作的名称是创建您要的东西指数索引表和快速搜索像姓氏，然后只加密这些索引列（S）。

例如，你可以在关键列包含一个3个字母字符串中的字符A-Z的每一个可能的组合中的一个条目（并包括为所有，但第一个字符空格），创建一个表。就像这样：

A__ 
AA_ 
AAA 
AAB 
AAC 
AAD 
.. 
.. 
.. 
ZZY 
ZZZ 

然后，当你添加一个人到你的数据库，你的索引添加到第二列这只是人的ID列表。

例子：在你的病人表，你会喜欢这个史密斯的条目：

231 Smith John A  1/1/2016 .... etc 

这个条目将被加密，也许所有列，但该ID 231.你会再加入此人索引表：

SMH [342, 2342, 562, 12] 
SMI [123, 175, 11, 231] 

现在你加密这第二列（ID的列表）。因此，当您搜索姓氏时，可以输入'smi'并快速检索以该字母组合开头的所有姓氏。如果你没有钥匙，你只会看到一个密码文本。实际上，您可以在这样的表格中创建两列，一个用于名字，另一个用于姓氏。

，此方法只作为一个纯文本索引快速和使用了一些相同的基本原则。你可以用soundex（'听起来像'）做同样的事情，通过构建一张所有可能的soundex模式作为你的左列，而人（患者？）Id作为另一列。通过创建多个这样的索引，你可以开发一个很好的方式来磨练你正在寻找的名字。

您还可以，如果你喜欢，但显然，这延长了你的表超过大小的每个字母的顺序延伸到多个字符。它的确具有让您的索引更具体的优势（并非总是您想要的）。事实上任何类型的直方图，你可以使用他们的名字将人分类。我已经看到这与出生日期完成。任何你需要搜索的东西。

类似这样的表存在一些漏洞，尤其是因为某些桶的条目数量可能非常短，攻击者可能会确定哪些名称在系统中没有条目。但是，在索引列表中使用某种随机'盐'可以帮助解决这个问题。其他问题包括每次更新值时都需要不断更新所有索引。

但即便如此，这种方法创建一种超越数据在休息一个很好的加密系统。静止数据只保护您免受攻击者无法获得系统授权的危险，但该系统为DBA和其他可能需要在数据库中工作但不需要（或希望）看到个人资料内包含。他们只会看到密文。因此，实际需要/想要访问此信息的用户或系统需要额外的密钥。阿什利麦迪逊应该采取这种策略是明智的。

希望这会有所帮助。