本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 選擇信標長度和分割區
<a name="choosing-beacon-length"></a>



|  | 
| --- |
| 我們的用戶端加密程式庫已重新命名為 AWS 資料庫加密 SDK。此開發人員指南仍提供有關 [DynamoDB 加密用戶端](legacy-dynamodb-encryption-client.md)的資訊。 | 

當您將新值寫入設定為可搜尋加密的加密欄位時， AWS 資料庫加密 SDK 會透過結合分割區識別符的純文字值計算 HMAC。在指定的分割區中，完整的 HMAC 是唯一代表純文字值。開發套件接著會截斷 HMAC 輸出，讓多個不同的純文字值可以映射到相同的信標。這些碰撞也稱為*誤報*，會限制未經授權的使用者推斷有關基礎純文字的辨別資訊的能力。

為每個信標產生的偽陽性平均數量取決於截斷後剩餘的信標長度和使用中的分割區數量。您只需要在設定標準信標時定義信標長度。複合信標會使用其建構之標準信標的信標長度。透過將值分散到多個分割區，碰撞會維持在每個分割區中，這有助於減少頻率集中，同時保留正確的查詢行為。

信標不會變更 欄位的加密狀態。不過，當您使用信標時，查詢的效率與資料分佈的公開資訊量之間存在固有權衡。較短的信標長度和其他分割區會增加碰撞並減少頻率洩漏，而較長的信標長度和較少的分割區可改善查詢精確度。

可搜尋加密的目標是使用信標對加密資料執行查詢，以降低與用戶端加密資料庫相關的效能成本。信標會與其計算來源的加密欄位一起存放。這表示他們可以顯示有關資料集分佈的辨別資訊。在極端情況下，未經授權的使用者可能可以分析發佈的相關資訊，並使用它來識別欄位的純文字值。選擇適當的信標長度和分割區計數有助於降低這些風險，並維護資料的機密性。

檢閱您的威脅模型，以判斷您需要的安全層級。例如，擁有資料庫存取權但不應存取純文字資料的人員越多，您可能想要保護資料集分佈的機密性就越多。提高機密性通常需要透過較短的信標長度、額外的分割區或兩者產生更多誤報，進而降低查詢效能。

**Topics**
+ [選擇分割方案](#choosing-partitioning-scheme)
+ [計算信標長度](#calculate-beacon-length)
+ [進階信標長度範例](#beacon-length-example)

## 選擇分割方案
<a name="choosing-partitioning-scheme"></a>

 當信標衍生時，分割方案會決定項目在分割區之間的分佈方式。選擇適當的方案對於平衡隱私權、效能和營運可預測性至關重要。

選取分割方案時，請考慮下列目標：
+  分佈高頻率值，以減少大型信標等效類別。
+  避免引入可能洩漏敏感資訊的可預測模式。
+  在寫入和查詢之間維持穩定的行為。

### 預設隨機分佈
<a name="w2aac15c25c29c17b9"></a>

 建議的預設值是隨機分佈方案。在此模型中，每個項目都會使用密碼編譯安全隨機值指派給分割區。隨機分佈會隨著時間產生大約相等的分割區大小，並確保頻繁的值均勻分散。

在下列情況下使用隨機分佈：
+  您沒有關於價值分佈的強大網域知識。
+  資料集包含未知或不斷發展的偏斜。
+  您想要將屬性相依洩漏降至最低。

### 確定性分佈
<a name="w2aac15c25c29c17c11"></a>

 在某些情況下，分割區指派必須具有決定性。決定性方案會根據項目屬性的穩定函數指派分割區。這些機制必須仔細設計，因為扭曲或敏感的輸入可能會導致分割區不均勻或意外的資訊洩漏。

在下列情況下使用確定性分佈：
+  操作工作流程取決於一致的分割區置放。
+  您有一組唯一值，刻意分組為單一分割區。

### 處理已知的熱值
<a name="w2aac15c25c29c17c13"></a>

 如果您的資料集包含眾所周知的熱值，您可以結合隨機和決定性策略。例如，您可以隨機分配一組高頻率值，同時確定指派所有其他值。

 此方法可減少熱值的集中，同時保留其他資料集的可預測行為。由於它會帶來額外的複雜性，請仔細檢閱以避免意外的資訊洩漏。

### 分割結構描述範例
<a name="w2aac15c25c29c17c15"></a>

 下列範例說明常見的分割區配置，並顯示不同的資料特性如何影響分割區指派。每個範例都會示範如何平衡隱私權、效能和操作簡單性。

#### 範例 1：統一分散式資料
<a name="w2aac15c25c29c17c15b5"></a>

 您正在建立電話號碼的信標，資料集中的值大致均勻分佈。沒有單一電話號碼出現的頻率明顯高於其他電話號碼。

 在這種情況下，設定單一分割區就已足夠。其他分割區提供很少的好處，只會增加查詢廣發。

#### 範例 2：具有偏態頻率的二進位結果
<a name="w2aac15c25c29c17c15b7"></a>

 您有一個資料庫，存放有兩個可能值的醫療測試結果：NEGATIVE 和 POSITIVE。負面結果的發生頻率約為正面結果的五倍。

 若要減少頻率洩漏，請使用混合策略：
+  在五個分割區之間隨機指派陰性結果。
+  以決定性方式將 POSITIVE 結果指派給單一分割區。

 這種方法會分散過度表示的值，同時保持較罕見的值穩定，減少大型等效類別，而不會不必要的廣發。

#### 範例 3：大型網域中的已知熱值
<a name="w2aac15c25c29c17c15b9"></a>

 您在美國有一個名字的資料庫。一組相對較小的常用名稱 （例如，前 500 個最常用的名稱） 出現的頻率遠高於其他名稱。
+  在四個分割區之間隨機指派前 500 個最常見的名稱。
+  以決定性方式將所有剩餘的名稱指派給單一分割區。
+  逐漸增加分割區數量，直到指派給每個分割區的資料呈現大致統一的分佈。

 這種混合方法以已知的熱值為目標，同時保持大多數名稱的分割簡單且可預測。

 這些範例示範如何根據不同的資料特性調整分割方案。在大多數情況下，隨機分佈已足夠，但在謹慎套用時，整合網域知識可以進一步改善隱私權和效能。

## 計算信標長度
<a name="calculate-beacon-length"></a>

信標長度以位元指定，並決定在截斷後保留多少位元的 HMAC 輸出。建議的長度取決於值在每個分割區中的分佈方式、資料是否包含相關值，以及您的安全和效能需求。當資料集在套用適當的分割方案後大致一致時，您可以使用簡單的方程式和調校程序來估計有效的信標長度。這些方程式提供信標可能產生的偽陽性平均數量的估計，但不保證資料集中每個唯一值的特定偽陽性數量。第一步是估計人口。

**注意**  
這些方程式的有效性取決於每個分割區內資料集的分佈。如果您的資料集未統一分佈，請參閱 [信標是否適合我的資料集？](searchable-encryption.md#are-beacons-right-for-me)。

### 估計人口
<a name="estimate-population"></a>

人口是標準信標建構來源欄位中唯一值的預期數量，不是欄位中存放值的預期總數。例如，請考慮可識別員工會議位置的加密`Room`欄位。`Room` 欄位預計會儲存總計 100，000 個值，但只有 50 個不同的會議室可供員工預留用於會議。這表示人口為 50，因為只有 50 個可能的唯一值可以存放在 `Room` 欄位中。

**注意**  
如果您的標準信標是從[虛擬欄位](beacons.md#virtual-field)建構的，則用於計算信標長度的人口是虛擬欄位建立的唯一組合數目。

估算人口時，請務必考慮資料集的預計增長。使用信標撰寫新記錄之後，您就無法更新信標長度。檢閱您的威脅模型和任何現有的資料庫解決方案，以建立您預期此欄位在未來五年內存放的唯一值數量的預估值。

您的人口不需要精確。首先，識別目前資料庫中的唯一值數目，或估計您預期在第一年存放的唯一值數目。接著，使用下列問題來協助您判斷未來五年內唯一值的預計增長。
+ 您是否預期唯一值會乘以 10？ 
+ 您是否預期唯一值會乘以 100？ 
+ 您是否預期唯一值會乘以 1000？ 

50，000 和 60，000 個唯一值之間的差異並不顯著，它們都會產生相同的建議信標長度。不過，50，000 和 500，000 個唯一值之間的差異將大幅影響建議的信標長度。

請考慮檢閱常見資料類型頻率的公有資料，例如郵遞區號或姓氏。例如，美國有 41，707 個郵遞區號。您使用的人口應與您自己的資料庫成比例。如果資料庫中`ZIPCode`的欄位包含來自整個美國的資料，則可以將人口定義為 41，707，即使該`ZIPCode`欄位*目前*沒有 41，707 個唯一值。如果資料庫中`ZIPCode`的欄位只包含來自單一狀態的資料，而且只包含來自單一狀態的資料，則您可以將人口定義為該狀態的郵遞區號總數，而不是 41，704。

### 從人口大小計算信標長度
<a name="calculating-beacon-length"></a>

 當您的資料大約平均分佈在每個分割區中，且不包含相關值時，您可以使用簡單的以人口為基礎的公式來估計適當的信標長度。

 讓 *p* 成為信標的人口大小，也就是信標從單一分割區中建構的不同純文字值數量。信標長度 *b* （以位元為單位） 的常見起點為：

```
b = log₂(p) − 1
```

 此公式會保留不可忽略的碰撞機率，同時保持可管理誤報的數量。從對數中減去一個位元可確保預期多個不同的值會映射到相同的信標，這有助於限制頻率洩漏並支援匿名性。

 此計算提供整個資料集的平均碰撞行為的預估值。它不保證每個值會產生相同數量的誤報，也不會考慮偏斜分佈、相關值或對手資料模式。

 使用此公式作為初始準則，而不是嚴格的要求。一律根據您的威脅模型、效能期望和觀察到的資料特性來驗證產生的組態，並視需要調整信標長度或分割區數量。

### 信標長度的進階主題
<a name="w2aac15c25c29c19c11"></a>

 身為進階使用者，您在為解決方案選取適當的信標長度時，有更大的彈性。您必須選擇適當保護資料機密性的長度，同時盡量減少對查詢效能的任何不必要的影響。信標保留的安全數量取決於資料集的[分佈](searchable-encryption.md#searchable-encryption-distribution)，以及信標建構來源欄位的[相互關聯](searchable-encryption.md#searchable-encryption-correlated-values)性。
+  **過長**的信標長度會產生太少的誤報，並可能顯示有關資料集分佈的辨別資訊。
+  **過短**的信標長度會產生太多誤報，並提高查詢的效能成本，因為它需要更廣泛的資料庫掃描。

如果您的資料集大致均勻分佈，您可以使用下列方程式和程序來協助估算實作的適當信標長度。這些方程式提供信標可能產生的偽陽性平均數量的估計，但不保證資料集中每個唯一值的特定偽陽性數量。下列主題假設您的信標是統一分佈的，且不包含相互關聯的資料。

1. **計算預期碰撞次數的建議範圍**

   若要判斷指定欄位的適當信標長度，您必須先識別預期碰撞數量的適當範圍。預期的碰撞數量代表映射到特定 HMAC 標籤的唯一純文字值的平均預期數量。一個唯一純文字值的預期誤報數量小於預期的碰撞數量。

   我們建議預期的碰撞數量大於或等於兩個，且小於人口的平方根。下列方程式只有在您的人口有 16 個或更多唯一值時才有效。

   ```
   2 ≤ number of collisions < √(Population)
   ```

   如果碰撞次數少於兩個，則信標會產生太少的誤報。我們建議使用兩個 作為預期碰撞的最小數量，因為它表示平均而言，欄位中的每個唯一值都會映射到另一個唯一值來產生至少一個偽陽性。

1. **計算信標長度的建議範圍**

   識別預期碰撞的最小和最大數量之後，請使用下列方程式來識別適當的信標長度範圍。

   ```
   number of collisions = Population * 2-(beacon length)
   ```

   首先，解決預期碰撞數量等於兩個 （預期碰撞的最低建議數量） 的**信標長度**。

   ```
   2 = Population * 2-(beacon length)
   ```

   然後，解決預期碰撞數量等於人口平方根的**信標長度** （建議的最大預期碰撞數量）。

   ```
   √(Population) = Population * 2-(beacon length)
   ```

   我們建議將此方程式產生的輸出四捨五入至較短的信標長度。例如，如果方程式產生 15.6 的信標長度，我們建議將該值四捨五入到 15 位元，而不是四捨五入到 16 位元。

1. **選擇信標長度**

   這些方程式只會識別您欄位的建議信標長度範圍。我們建議您盡可能使用較短的信標長度來維護資料集的安全性。不過，您實際使用的信標長度取決於您的威脅模型。在檢閱威脅模型以判斷欄位的最佳信標長度時，請考慮您的效能需求。

   使用較短的信標長度會降低查詢效能，而使用較長的信標長度則會降低安全性。一般而言，如果您的資料集[分佈](searchable-encryption.md#searchable-encryption-distribution)不均勻，或者如果您從[關聯](searchable-encryption.md#searchable-encryption-correlated-values)欄位建構不同的信標，則需要使用較短的信標長度，將資料集分佈的相關資訊量降至最低。

   如果您檢閱您的威脅模型，並決定顯示有關欄位分佈的任何辨別資訊不會對您的整體安全性造成威脅，您可以選擇使用比您計算的建議範圍更長的信標長度。例如，如果您將欄位的信標長度建議範圍計算為 9-16 位元，您可以選擇使用 24 位元的信標長度，以避免任何效能損失。

   請謹慎選擇您的信標長度。使用信標撰寫新記錄之後，您就無法更新信標長度。

## 進階信標長度範例
<a name="beacon-length-example"></a>

考慮在[密碼編譯動作](concepts.md#crypt-actions)`ENCRYPT_AND_SIGN`中將 `unit` 欄位標記為 的資料庫。若要設定 `unit` 欄位的標準信標，我們需要判斷該`unit`欄位的預期誤報數和信標長度。

1. 估計人口

   檢閱我們的威脅模型和目前的資料庫解決方案後，我們預期 `unit` 欄位最終會有 100，000 個唯一值。

   這表示**人口 = 100，000**。

1. 計算預期碰撞次數的建議範圍。

   在此範例中，預期的碰撞數量應介於 2 到 316 之間。

   ```
   2 ≤ number of collisions < √(Population)
   ```

   1. 

      ```
      2 ≤ number of collisions < √({{100,000}})
      ```

   1. 

      ```
      2 ≤ number of collisions < {{316}}
      ```

1. 計算信標長度的建議範圍。

   在此範例中，信標長度應介於 9-16 位元之間。

   ```
   number of collisions = Population * 2-(beacon length)
   ```

   1. 計算預期的碰撞次數等於**步驟 2 **中識別的最小值的信標長度。

      ```
      2 = 100,000 * 2-(beacon length)
      ```

      信標長度 = 15.6 或 15 位元

   1. 計算信標長度，其中預期的碰撞數量等於**步驟 2 **中識別的最大值。

      ```
      316 = 100,000 * 2-(beacon length)
      ```

      信標長度 = 8.3 或 8 位元

1. 判斷適合您安全和效能需求的信標長度。

   對於低於 15 的每個位元，效能成本和安全性會加倍。
   + 16 位元
     + 平均而言，每個唯一值都會對應至其他 1.5 個單位。
     + 安全性：具有相同截斷 HMAC 標籤的兩個記錄有 66% 可能有相同的純文字值。
     + 效能：查詢會為您實際請求的每 10 筆記錄擷取 15 筆記錄。
   + 14 位元
     + 平均而言，每個唯一值都會對應至 6.1 個其他單位。
     + 安全性：具有相同截斷 HMAC 標籤的兩個記錄有 33% 可能具有相同的純文字值。
     + 效能：查詢會為您實際請求的每 10 筆記錄擷取 30 筆記錄。