翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# ビーコンの長さとパーティションの選択
<a name="choosing-beacon-length"></a>



|  | 
| --- |
| クライアント側の暗号化ライブラリの名前が AWS Database Encryption SDK に変更されました。このデベロッパーガイドでは、引き続き [DynamoDB Encryption Client](legacy-dynamodb-encryption-client.md) に関する情報を提供します。 | 

検索可能な暗号化用に設定された暗号化されたフィールドに新しい値を書き込むと、 AWS Database Encryption SDK はパーティション識別子と組み合わせたプレーンテキスト値で HMAC を計算します。特定のパーティション内では、完全な HMAC はプレーンテキスト値を一意に表します。次に、SDK は 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>

 場合によっては、パーティションの割り当ては決定的である必要があります。決定論的なスキームは、項目属性の安定した関数に基づいてパーティションを割り当てます。これらのスキームは、歪んだ入力や機密性の高い入力によってパーティショニングが不均一になったり、意図しない情報漏洩が発生する可能性があるため、慎重に設計する必要があります。

決定論的分布は、次の場合に使用します。
+  運用ワークフローは、一貫したパーティション配置に依存します。
+  1 つのパーティションに意図的にグループ化された一意の値のセットがあります。

### 既知のホット値の処理
<a name="w2aac15c25c29c17c13"></a>

 データセットに既知のホット値が含まれている場合は、ランダムな戦略と決定論的な戦略を組み合わせることができます。たとえば、他のすべての値を決定的に割り当てながら、少数の高頻度値をランダムに分散できます。

 このアプローチにより、データセットの残りの部分の予測可能な動作を維持しながら、ホット値の集中力が低下します。複雑さが増すため、意図しない情報漏洩を避けるために慎重に確認してください。

### パーティションスキームの例
<a name="w2aac15c25c29c17c15"></a>

 次の例は、一般的なパーティション分割スキームと、さまざまなデータ特性がパーティションの割り当てにどのように影響するかを示しています。各例は、プライバシー、パフォーマンス、運用のシンプルさのバランスを取る方法を示しています。

#### 例 1: 均等に分散されたデータ
<a name="w2aac15c25c29c17c15b5"></a>

 電話番号のビーコンを作成し、データセット内の値はほぼ均一に分散されます。1 つの電話番号が他の電話番号よりも大幅に頻繁に表示されることはありません。

 この場合、1 つのパーティションを設定するだけで十分です。追加のパーティションは利点がほとんどなく、クエリファンアウトを増やすだけです。

#### 例 2: 歪んだ頻度のバイナリ結果
<a name="w2aac15c25c29c17c15b7"></a>

 否定と否定の 2 つの可能な値を持つ医療テスト結果を保存するデータベースがあります。負の結果は、正の結果の約 5 倍の頻度で発生します。

 周波数漏洩を減らすには、混合戦略を使用します。
+  5 つのパーティションに負の結果をランダムに割り当てます。
+  正の結果を 1 つのパーティションに決定的に割り当てます。

 このアプローチは、よりまれな値を安定させながら、過剰に表される値を分散し、不要なファンアウトなしで大きな等価クラスを減らします。

#### 例 3: 大きなドメインの既知のホット値
<a name="w2aac15c25c29c17c15b9"></a>

 米国にファーストネームのデータベースがある。一般的な名前の比較的小さなセット (上位 500 の最も頻繁な名前など) は、他の名前よりもはるかに頻繁に表示されます。
+  上位 500 の最も頻度の高い名前を 4 つのパーティションにランダムに割り当てます。
+  残りのすべての名前を 1 つのパーティションに決定的に割り当てます。
+  各パーティションに割り当てられたデータがほぼ均一な分布を示すまで、パーティションの数を徐々に増やします。

 このハイブリッドアプローチは、ほとんどの名前に対してシンプルで予測可能なパーティショニングを維持しながら、既知のホット値をターゲットにします。

 これらの例は、パーティション分割スキームをさまざまなデータ特性にどのように適用できるかを示しています。ほとんどの場合、ランダム分散で十分ですが、ドメインの知識を組み込むことで、慎重に適用するとプライバシーとパフォーマンスをさらに向上させることができます。

## ビーコンの長さの計算
<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 室しかありません。これは、`Room` フィールドに格納できる一意の値が 50 個しかないため、母集団が 50 であることを意味します。

**注記**  
標準ビーコンの構築元が[仮想フィールド](beacons.md#virtual-field)である場合、ビーコンの長さを計算するために使用される母集団は、仮想フィールドによって作成された一意の組み合わせの数です。

母集団を推定する際には、データセットの予測される増加を必ず考慮してください。ビーコンを持つ新しいレコードを書き込んだ後に、そのビーコンの長さを更新することはできません。脅威モデルと既存のデータベースソリューションを確認して、今後 5 年間にこのフィールドに格納されることが想定される一意の値の数の見積もりを作成します。

母集団は正確である必要はありません。まず、現在のデータベース内の一意の値の数を特定するか、または最初の 1 年間に格納されることが想定される一意の値の数を見積もります。次に、以下の質問を使用して、今後 5 年間で予測される一意の値の増加を判断します。
+ 一意の値が 10 倍になることが想定されますか?
+ 一意の値が 100 倍になることが想定されますか?
+ 一意の値が 1,000 倍になることが想定されますか?

一意の値が 50,000 個である場合と 60,000 個である場合の差は大きくなく、推奨されるビーコンの長さは両方とも同じです。しかし、一意の値が 50,000 個である場合と 500,000 個である場合、その差は、推奨されるビーコンの長さに大きく影響します。

郵便番号や姓などの一般的なデータタイプの出現頻度について、公開データを確認することを検討してください。例えば、米国には 41,707 の郵便番号があります。使用する母集団は、独自のデータベースに比例する必要があります。データベース内の `ZIPCode` フィールドに米国全土のデータが含まれている場合は、`ZIPCode` フィールドに現在 41,707 個の一意の値がない場合でも、母集団を 41,707 と定義することが考えられます。データベース内の `ZIPCode` フィールドに 1 つの州のデータのみが含まれ、今後も 1 つの州のデータのみが含まれる場合は、母集団を 41,704 ではなく、その州の郵便番号の合計数として定義できます。

### 母集団サイズからのビーコンの長さの計算
<a name="calculating-beacon-length"></a>

 データが各パーティション内にほぼ均一に分散され、相関値が含まれていない場合は、単純な母集団ベースの式を使用して適切なビーコンの長さを推定できます。

 *p* をビーコンの母集団サイズ、つまりビーコンが 1 つのパーティション内から構築される個別のプレーンテキスト値の数とします。ビーコンの長さ *b* (ビット単位) の一般的な開始点は次のとおりです。

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

 この式は、誤検出の数を管理できるようにしながら、衝突の可能性をごくわずかに保ちます。対数から 1 ビットを減算すると、複数の異なる値が同じビーコンにマッピングされることが期待されます。これにより、頻度の漏洩が制限され、匿名性がサポートされます。

 この計算は、データセット全体の平均衝突動作の推定値を提供します。すべての値が同じ数の誤検出を生成することは保証されず、歪んだ分布、相関値、または敵対的なデータパターンも考慮されません。

 この式は、厳格な要件ではなく、最初のガイドラインとして使用してください。結果の設定を脅威モデル、パフォーマンスの期待値、観測データ特性に対して常に検証し、必要に応じてビーコンの長さまたはパーティション数を調整します。

### ビーコンの長さに関する高度なトピック
<a name="w2aac15c25c29c19c11"></a>

 上級ユーザーは、ソリューションに適したビーコンの長さを選択する柔軟性が高まります。クエリパフォーマンスへの不要な影響を最小限に抑えながら、データの機密性を適切に保護する長さを選択する必要があります。ビーコンによって維持されるセキュリティの量は、データセットの[分布](searchable-encryption.md#searchable-encryption-distribution)と、ビーコンの構築元となるフィールドの[相関関係](searchable-encryption.md#searchable-encryption-correlated-values)によって異なります。
+  ビーコンが**過度に長い**場合には、生成される誤検知が過度に少なくなるため、データセットの分布に関する特徴的な情報が明らかになる可能性があります。
+  ビーコンの長さが**短すぎる**と誤検出が多すぎるため、データベースのより広範なスキャンが必要になるため、クエリのパフォーマンスコストが増加します。

データセットがほぼ均一に分散されている場合は、次の式と手順を使用して、実装に適したビーコンの長さを推定できます。これらの式は、ビーコンが生成する可能性のある誤検出の平均数の推定値を提供しますが、データセット内の一意の値ごとに特定の数の誤検出を保証するわけではありません。次のトピックは、ビーコンが統一的に分布しており、相関データが含まれていないことを前提としています。

1. **想定されるコリジョン数の推奨範囲を計算する**

   特定のフィールドについての適切なビーコンの長さを決定するには、まず、想定されるコリジョン数の適切な範囲を特定する必要があります。想定されるコリジョン数は、特定の HMAC タグにマッピングされる一意のプレーンテキストの値の平均想定数を表します。1 つの一意のプレーンテキストの値について想定される誤検知の数は、想定されるコリジョン数より 1 少ない数となります。

   想定されるコリジョン数は 2 以上、かつ、母集団の平方根未満にすることをお勧めします。次の方程式は、母集団に 16 個以上の一意の値がある場合にのみ機能します。

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

   コリジョン数が 2 未満の場合、ビーコンが生成する誤検知が過度に少なくなります。想定されるコリジョンの最小数として 2 が推奨されます。これは、平均して、フィールド内のすべての一意の値が、他の 1 つの一意の値にマッピングされることによって、少なくとも 1 つの誤検知を生成することを意味するためです。

1. **ビーコンの長さの推奨範囲を計算する**

   想定されるコリジョンの最小数と想定されるコリジョンの最大数を特定したら、次の方程式を使用して適切なビーコンの長さの範囲を特定します。

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

   まず、想定されるコリジョン数が 2 (想定されるコリジョンの推奨最小数) である場合の**ビーコンの長さ**を求めます。

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

   その後、想定コリジョン数が母集団の平方根 (想定されるコリジョンの推奨最大数) である場合の**ビーコンの長さ**を求めます。

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

   この方程式によって生成される結果を切り捨ててビーコンの長さを算出します。例えば、方程式を解くとビーコンの長さが 15.6 になる場合、その値を 16 ビットになるように切り上げるのではなく、15 ビットになるように切り捨てることをお勧めします。

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)で `unit` フィールドを `ENCRYPT_AND_SIGN` としてマークしたデータベースを考えてみましょう。`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 未満のビットごとに、パフォーマンスコストとセキュリティが 2 倍になります。
   + 16 ビット
     + 平均すると、それぞれの一意の値は他の 1.5 個のユニットにマッピングされます。
     + セキュリティ: 切り詰められた同じ HMAC タグを持つ 2 つのレコードは、同じプレーンテキストの値を持つ可能性が 66% あります。
     + パフォーマンス: クエリは、実際にリクエストした 10 件のレコードごとに 15 件のレコードを取得します。
   + 14 ビット
     + 平均すると、それぞれの一意の値は他の 6.1 個のユニットにマッピングされます。
     + セキュリティ: 切り詰められた同じ HMAC タグを持つ 2 つのレコードは、同じプレーンテキストの値を持つ可能性が 33% あります。
     + パフォーマンス: クエリは、実際にリクエストした 10 件のレコードごとに 30 件のレコードを取得します。