可搜索加密

我們的用戶端加密程式庫已重新命名為AWS資料庫加密 SDK。本開發人員指南仍提供 DynamoDB 加密用戶端的相關資訊。

可搜索的加密使您無需解密整個數據庫即可搜索加密記錄。這是使用信標（Beacon）完成的，該信標會在寫入字段的純文本值和實際存儲在數據庫中的加密值之間創建一個映射。資AWS料庫加密 SDK 會將信標儲存在新增至記錄的新欄位中。根據您使用的信標類型，您可以對加密的資料執行完全比對搜尋或更自訂的複雜查詢。

注意

AWS資料庫加密 SDK 中的可搜尋加密與學術研究中定義的可搜尋對稱加密不同，例如可搜尋的對稱加密。

信標 (Beacon) 是截斷的雜湊型訊息驗證碼 (HMAC) 標記，可在欄位的純文字和加密值之間建立對應。當您將新值寫入設定為可搜尋加密的加密欄位時，AWS資料庫加密 SDK 會透過純文字值計算 HMAC。此 HMAC 輸出是該欄位的純文字值的一對一 (1:1) 相符項目。HMAC 輸出會被截斷，以便多個不同的明文值對應到相同的截斷 HMAC 標籤。這些誤報會限制未經授權的使用者識別有關純文字值的區別資訊的能力。當您查詢信標時，AWS資料庫加密 SDK 會自動篩選掉這些誤報，並傳回查詢的純文字結果。

針對每個信標產生的平均誤判數，取決於截斷後剩餘的信標長度。如需決定實作適當信標長度的說明，請參閱判斷信標長度。

注意

可搜索的加密被設計為在新的，未填充的數據庫中實現。在現有資料庫中設定的任何信標只會對應上傳至資料庫的新記錄，信標無法對應現有資料。

主題

• 信標是否適合我的數據集？

• 可搜尋加密案例

信標是否適合我的數據集？

使用信標對加密資料執行查詢，可降低與用戶端加密資料庫相關的效能成本。當您使用信標時，查詢的效率和有關數據分佈的信息量之間存在固有的權衡。信標不會改變欄位的加密狀態。當您使用AWS資料庫加密 SDK 加密和簽署欄位時，欄位的純文字值永遠不會公開給資料庫。資料庫會儲存欄位的隨機加密值。

信標與計算它們的加密字段一起存儲。這表示即使未經授權的使用者無法檢視加密欄位的純文字值，他們也可以對信標執行統計分析，進一步瞭解資料集的分佈情況，並在極端情況下識別信標對應的純文字值。您設定信標的方式可以減輕這些風險。特別是，選擇正確的信標長度可以幫助您保持數據集的機密性。

安全性與效能

• 信標長度越短，保留的安全性就越高。

• 信標長度越長，保留的效能就越多。

可搜尋的加密可能無法為所有資料集提供所需的效能和安全性等級。在設定任何信標之前，請先檢閱您的威脅模型、安全需求和效能需求。

判斷可搜尋的加密是否適合您的資料集時，請考量下列資料集唯一性需求。

發佈

Beacon 保留的安全性量取決於資料集的分佈情況。當您設定可搜尋加密的加密欄位時，AWS資料庫加密 SDK 會根據寫入該欄位的純文字值來計算 HMAC。針對指定欄位計算的所有信標均使用相同的索引鍵計算，但對每個承租人使用不同索引鍵的多租戶資料庫除外。這表示如果將相同的純文字值寫入欄位多次，則會針對該純文字值的每個執行個體建立相同的 HMAC 標籤。

您應該避免從包含非常常見值的字段構建信標。例如，考慮一個存儲伊利諾伊州每個居民的地址的數據庫。如果您從加密City字段構建信標，則由於居住在芝加哥的伊利諾伊州人口的比例很大，因此在「芝加哥」上計算出的信標將被過度佔用。即使未經授權的使用者只能讀取加密的值和信標值，如果信標保留此分配，他們也許能夠識別哪些記錄包含芝加哥居民的資料。為了最大限度地減少顯示有關分佈的區別信息量，您必須充分截斷您的信標。隱藏這種不均勻分佈所需的信標長度具有可能無法滿足您應用程式需求的顯著效能成本。

您必須仔細分析數據集的分佈情況，以確定需要截斷多少信標。截斷後剩餘的信標長度與可識別的有關分佈的統計資訊量直接相關。您可能需要選擇較短的信標長度，以充分減少顯示有關資料集的區別資訊量。

在極端情況下，您無法計算分佈不均勻的資料集的信標長度，以有效平衡效能和安全性。例如，您不應從儲存罕見疾病醫學測試結果的欄位建構信標。由於預計NEGATIVE結果在數據集中顯著更加普遍，因此可以通過它們的稀有程度輕鬆識別POSITIVE結果。當欄位只有兩個可能的值時，隱藏分佈是非常具有挑戰性的。如果您使用的信標長度足以隱藏分佈，則所有純文字值都會對應至相同的 HMAC 標籤。如果使用較長的信標長度，很明顯哪個信標映射到純文POSITIVE本值。

相关性

我們強烈建議您避免從具有相關值的欄位建構不同的信標。從相關欄位建構的信標需要較短的信標長度，以便充分減少每個資料集散佈給未經授權使用者的相關資訊量。您必須仔細分析資料集，包括其熵和相關值的聯合分佈，以判斷需要截斷多少信標。如果產生的信標長度不符合您的效能需求，則信標可能不適合您的資料集。

例如，您不應該從City和ZIPCode欄位建構兩個不同的信標，因為郵遞區號可能只與一個城市產生關聯。通常，信標產生的誤報會限制未經授權的使用者識別資料集相關資訊的能力。但是City和ZIPCode欄位之間的關聯意味著未經授權的使用者可以輕鬆識別哪些結果是誤報，並區分不同的郵遞區號。

您也應該避免從包含相同純文字值的欄位建構信標。例如，您不應從mobilePhone和preferredPhone欄位建構信標，因為它們可能包含相同的值。如果您從這兩個欄位建構不同的信標，AWS資料庫加密 SDK 會在不同金鑰下為每個欄位建立信標。這會為相同的純文字值產生兩個不同的 HMAC 標籤。這兩個不同的信標不太可能具有相同的誤報，並且未經授權的用戶可能能夠區分不同的電話號碼。

即使您的資料集包含相關欄位或分佈不均，您也可以使用較短的信標長度來建構保護資料集機密性的信標。但是，Beacon length 並不保證資料集中的每個唯一值都會產生一些誤報，這些誤報可有效地減少資料集所揭露的區別資訊量。信標長度僅估計產生誤報的平均數量。您的資料集分佈越不均，信標長度的效率就越低，就是決定產生的誤報的平均數目。

仔細考慮從中構建信標的字段的分佈情況，並考慮截斷信標長度以滿足您的安全需求所需的數量。本章的下列主題假設您的信標均勻分佈，且不包含相關資料。

可搜尋加密案例

下列範例會示範簡單的可搜尋加密解決方案。在應用程式中，此範例中使用的範例欄位可能不符合信標的分佈和相互關聯唯一性建議。當您閱讀本章中可搜尋的加密概念時，您可以使用此範例作為參考。

考慮一個名Employees為跟踪公司員工數據的數據庫。在數據庫中的每個記錄包含稱為員工 ID，LastNameFirstName，和地址字段。Employees數據庫中的每個字段由主鍵標識EmployeeID。

以下是資料庫中的明文記錄範例。

{
    "EmployeeID": 101,
    "LastName": "Jones",
    "FirstName": "Mary",
    "Address": {
                "Street": "123 Main",
                "City": "Anytown",
                "State": "OH",
                "ZIPCode": 12345
    }
}

如果您ENCRYPT_AND_SIGN在加密動作中將LastName和FirstName欄位標示為，則這些欄位中的值在上傳到資料庫之前會先在本機加密。上傳的加密數據是完全隨機的，數據庫不會將此數據識別為受保護。它只是檢測典型的數據條目。這意味著實際存儲在數據庫中的記錄可能如下所示。

{
    "PersonID": 101,
    "LastName": "1d76e94a2063578637d51371b363c9682bad926cbd",
    "FirstName": "21d6d54b0aaabc411e9f9b34b6d53aa4ef3b0a35",
    "Address": {
                "Street": "123 Main",
                "City": "Anytown",
                "State": "OH",
                "ZIPCode": 12345
    }
}

如果您需要查詢資料庫LastName欄位中的完全相符項目，請設定名為的標準信標，LastName將寫入LastName欄位的純文字值對應至儲存在資料庫中的加密值。

此信標會根據欄位中的純文字值計算 HMAC。LastName每個 HMAC 輸出都會被截斷，使其不再與純文字值完全相符。例如，完整的雜湊值和截斷的雜湊值Jones可能如下所示。

完整雜湊

2aa4e9b404c68182562b6ec761fcca5306de527826a69468885e59dc36d0c3f824bdd44cab45526f70a2a18322000264f5451acf75f9f817e2b35099d408c833

截斷散列

b35099d408c833

設定標準信標之後，您可以在LastName欄位上執行相等搜尋。例如，如果您要搜尋Jones，請使用LastName信標 (Beacon) 來執行下列查詢。

LastName = Jones

資AWS料庫加密 SDK 會自動篩選出誤報，並傳回查詢的純文字結果。