快速搜索加密數據？

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和其他可能需要在數據庫中工作但不需要（或希望）看到個人資料內包含。他們只會看到密文。因此，實際需要/想要訪問此信息的用戶或系統需要額外的密鑰。阿什利麥迪遜應該採取這種策略是明智的。

希望這會有所幫助。