ビーコンの長さの選択

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

検索可能な暗号化が設定されている暗号化されたフィールドに新しい値を書き込むと、AWS Database Encryption SDK は、プレーンテキストの値について HMAC を計算します。この HMAC 出力は、そのフィールドのプレーンテキストの値と 1 対 1 (1:1) で一致します。HMAC 出力は切り詰められ、複数の個別のプレーンテキストの値が、切り詰められた同じ HMAC タグにマッピングされます。これらのコリジョン、つまり誤検知により、不正ユーザーは、プレーンテキストの値に関する特徴的な情報を識別しにくくなります。

各ビーコンについて生成される誤検知の平均数は、切り詰めた後に残っているビーコンの長さによって決まります。標準ビーコンを設定する場合、必要なのはビーコンの長さを定義することだけです。複合ビーコンは、その構築元となる標準ビーコンのビーコン長を使用します。

ビーコンはフィールドの暗号化状態を変更しません。ただし、ビーコンを使用する場合、クエリの効率性と、データの分布に関して明らかになる情報の量との間には、固有のトレードオフが存在します。

検索可能な暗号化の目標は、ビーコンを使用して暗号化されたデータをクエリすることにより、クライアント側の暗号化されたデータベースに関連するパフォーマンスコストを削減することです。ビーコンは、計算元の暗号化されたフィールドと一緒に格納されます。これは、データセットの分布に関する特徴的な情報を明らかにできることを意味します。極端な場合には、不正ユーザーが分布に関して明らかになった情報を分析し、それを使用してフィールドのプレーンテキストの値を特定できる可能性があります。ビーコンの長さを適切に選択すると、これらのリスクを軽減し、分布の機密性を維持するのに役立ちます。

脅威モデルを確認して、必要なセキュリティのレベルを決定します。例えば、データベースにアクセスできるが、プレーンテキストデータにはアクセスすべきではないユーザーが増えるほど、データセットの分布の機密性を保護する必要が高まる可能性があります。機密性を高めるには、ビーコンはより多くの誤検知を生成する必要があります。機密性が高まると、クエリのパフォーマンスが低下します。

セキュリティとパフォーマンス

ビーコンが過度に長い場合には、生成される誤検知が過度に少なくなるため、データセットの分布に関する特徴的な情報が明らかになる可能性があります。
ビーコンが過度に短い場合には、生成される誤検知が過度に多くなるため、データベースの広範なスキャンが必要になり、これに伴ってクエリのパフォーマンスコストが増加します。

ソリューションのために適切なビーコンの長さを決定する際には、クエリのパフォーマンスに必要以上に影響を及ぼすことなく、データのセキュリティを適切に維持できる長さを見つける必要があります。ビーコンによって維持されるセキュリティの量は、データセットの分布と、ビーコンの構築元となるフィールドの相関関係によって異なります。次のトピックは、ビーコンが統一的に分布しており、相関データが含まれていないことを前提としています。

ビーコンの長さの計算

ビーコンの長さはビット単位で定義され、切り詰め後に保持される HMAC タグのビット数を指します。推奨されるビーコンの長さは、データセットの分布、相関値の存在、セキュリティとパフォーマンスに関する具体的な要件によって異なります。データセットが統一的に分布している場合は、実装に最適なビーコンの長さを特定するために、次の方程式と手順を役立てることができます。これらの方程式は、ビーコンが生成する誤検知の平均数を推定するだけであり、データセット内のすべての一意の値が特定の数の誤検知を生成することを保証するものではありません。

注記

これらの方程式の有効性は、データセットの分布によって異なります。データセットが統一的に分布していない場合は、「ビーコンが適しているデータセット」を参照してください。

一般に、データセットが統一的な分布から離れるほど、ビーコンを短くする必要があります。

母集団を推定する

母集団は、標準ビーコンの構築元となるフィールド内の一意の値の想定される数であり、フィールドに格納される値の想定される合計数ではありません。例えば、従業員のミーティングの場所を特定する暗号化された Room フィールドについて考えてみましょう。Room フィールドには合計 100,000 の値が格納されることが想定されますが、従業員がミーティングのために予約できる部屋は 50 室しかありません。これは、Room フィールドに格納できる一意の値が 50 個しかないため、母集団が 50 であることを意味します。

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

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

母集団は正確である必要はありません。まず、現在のデータベース内の一意の値の数を特定するか、または最初の 1 年間に格納されることが想定される一意の値の数を見積もります。次に、以下の質問を使用して、今後 5 年間で予測される一意の値の増加を判断します。
- 一意の値が 10 倍になることが想定されますか?
- 一意の値が 100 倍になることが想定されますか?
- 一意の値が 1,000 倍になることが想定されますか?
一意の値が 50,000 個である場合と 60,000 個である場合の差は大きくなく、推奨されるビーコンの長さは両方とも同じです。しかし、一意の値が 50,000 個である場合と 500,000 個である場合、その差は、推奨されるビーコンの長さに大きく影響します。

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

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

想定されるコリジョン数は 2 以上、かつ、母集団の平方根未満にすることをお勧めします。次の方程式は、母集団に 16 個以上の一意の値がある場合にのみ機能します。
```
2 ≤ number of collisions < √(Population)
```
コリジョン数が 2 未満の場合、ビーコンが生成する誤検知が過度に少なくなります。想定されるコリジョンの最小数として 2 が推奨されます。これは、平均して、フィールド内のすべての一意の値が、他の 1 つの一意の値にマッピングされることによって、少なくとも 1 つの誤検知を生成することを意味するためです。
ビーコンの長さの推奨範囲を計算する

想定されるコリジョンの最小数と想定されるコリジョンの最大数を特定したら、次の方程式を使用して適切なビーコンの長さの範囲を特定します。
```
number of collisions = Population * 2^{-(beacon length)}
```
まず、想定されるコリジョン数が 2 (想定されるコリジョンの推奨最小数) である場合のビーコンの長さを求めます。
```
2 = Population * 2^{-(beacon length)}
```
その後、想定コリジョン数が母集団の平方根 (想定されるコリジョンの推奨最大数) である場合のビーコンの長さを求めます。
```
√(Population) = Population * 2^{-(beacon length)}
```
この方程式によって生成される結果を切り捨ててビーコンの長さを算出します。例えば、方程式を解くとビーコンの長さが 15.6 になる場合、その値を 16 ビットになるように切り上げるのではなく、15 ビットになるように切り捨てることをお勧めします。
ビーコンの長さを選択する

これらの方程式は、フィールドのビーコンの長さの推奨範囲を特定するだけです。データセットのセキュリティを維持するために、可能な場合は常に、ビーコンを短くすることをお勧めします。ただし、実際に使用するビーコンの長さは、脅威モデルによって決まります。脅威モデルを確認する際にパフォーマンス要件を考慮して、フィールドに最適なビーコンの長さを決定します。

ビーコンを短くするとクエリのパフォーマンスが低下し、ビーコンを長くするとセキュリティが低下します。一般的に、データセットが不均一に分布している場合、または相関フィールドから個別のビーコンを構築する場合は、ビーコンをより短くして、データセットの分布に関して明らかになる情報の量を最小限に抑える必要があります。

脅威モデルを確認し、フィールドの分布に関して明らかになる特徴的な情報がセキュリティ全体に脅威を与えるものではないと判断した場合は、計算した推奨範囲よりもビーコンを長くすることを選択することもできます。例えば、フィールドのビーコンの長さの推奨範囲を計算したところ、9～16 ビットと算出されたとしても、パフォーマンスの低下を避けるために 24 ビットのビーコン長を使用することを選択できます。

ビーコンの長さは慎重に選択してください。ビーコンを持つ新しいレコードを書き込んだ後に、そのビーコンの長さを更新することはできません。

例

暗号化アクションで unit フィールドを ENCRYPT_AND_SIGN としてマークしたデータベースを考えてみましょう。unit フィールドの標準ビーコンを設定するには、unit フィールドについて想定される誤検知の数とビーコンの長さを決定する必要があります。

母集団を推定する

脅威モデルと現在のデータベースソリューションを確認した結果、unit フィールドには最終的に 100,000 個の一意の値が存在することになると想定されます。

つまり、母集団 = 100,000 です。
想定されるコリジョン数の推奨範囲を計算します。

この例では、想定されるコリジョン数は 2～316 です。
```
2 ≤ number of collisions < √(Population)
```
1. ```
2 ≤ number of collisions < √(100,000)
```
2. ```
2 ≤ number of collisions < 316
```
ビーコンの長さの推奨範囲を計算します。

この例では、ビーコンの長さは 9～16 ビットである必要があります。
```
number of collisions = Population * 2^{-(beacon length)}
```
1. 想定されるコリジョンの最小数がステップ 2 で特定された数である場合のビーコンの長さを計算します。
```
2 = 100,000 * 2^{-(beacon length)}
```
  ビーコンの長さ = 15.6、または 15 ビット
2. 想定されるコリジョンの最大数がステップ 2 で特定された数である場合のビーコンの長さを計算します。
```
316 = 100,000 * 2^{-(beacon length)}
```
  ビーコンの長さ = 8.3、または 8 ビット
セキュリティとパフォーマンスの要件に適したビーコンの長さを決定します。

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

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

ビーコンのタイプの選択

ビーコン名の選択