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

ビーコンの長さとパーティションの選択

検索可能な暗号化用に設定された暗号化されたフィールドに新しい値を書き込むと、 AWS Database Encryption SDK はパーティション識別子と組み合わせたプレーンテキスト値で HMAC を計算します。特定のパーティション内では、完全な HMAC はプレーンテキスト値を一意に表します。次に、SDK は HMAC 出力を切り捨てて、複数の個別のプレーンテキスト値を同じビーコンにマッピングできるようにします。これらの衝突は誤検出とも呼ばれ、基になるプレーンテキストに関する識別情報を推測する権限のないユーザーの能力を制限します。

各ビーコンに対して生成された誤検出の平均数は、切り捨て後のビーコンの長さと使用中のパーティションの数によって決まります。標準ビーコンを設定する場合、必要なのはビーコンの長さを定義することだけです。複合ビーコンは、その構築元となる標準ビーコンのビーコン長を使用します。複数のパーティションに値を分散することで、各パーティション内で衝突が維持されるため、正しいクエリ動作を維持しながら頻度の集中を減らすことができます。

ビーコンはフィールドの暗号化状態を変更しません。ただし、ビーコンを使用する場合、クエリの効率性と、データの分布に関して明らかになる情報の量との間には、固有のトレードオフが存在します。ビーコンの長さを短くしてパーティションを追加すると、衝突が増加し、頻度の漏洩が軽減されます。一方、ビーコンの長さを長くしてパーティションを減らすと、クエリの精度が向上します。

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

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

パーティショニングスキームの選択

パーティショニングスキームは、ビーコンが導出されたときにパーティション間で項目を分散する方法を決定します。プライバシー、パフォーマンス、運用上の予測可能性のバランスを取るには、適切なスキームを選択することが重要です。

パーティショニングスキームを選択するときは、次の目標を考慮してください。

デフォルトのランダム分散

推奨されるデフォルトはランダム分散スキームです。このモデルでは、各項目は暗号的に安全なランダム値を使用してパーティションに割り当てられます。ランダム分散では、時間の経過とともにほぼ同じパーティションサイズが生成され、頻繁な値が均等に分散されます。

次の場合は、ランダム分散を使用します。

決定的分布

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

決定論的分布は、次の場合に使用します。

既知のホット値の処理

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

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

パーティションスキームの例

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

例 1: 均等に分散されたデータ

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

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

例 2: 歪んだ頻度のバイナリ結果

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

周波数漏洩を減らすには、混合戦略を使用します。

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

例 3: 大きなドメインの既知のホット値

米国にファーストネームのデータベースがある。一般的な名前の比較的小さなセット (上位 500 の最も頻繁な名前など) は、他の名前よりもはるかに頻繁に表示されます。

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

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

ビーコンの長さの計算

ビーコンの長さはビット単位で指定され、切り捨て後に保持される HMAC 出力のビット数を決定します。推奨される長さは、各パーティション内の値の分散方法、データに相関値が含まれているかどうか、セキュリティとパフォーマンスの要件によって異なります。適切なパーティショニングスキームを適用した後にデータセットがほぼ均一である場合は、単純な方程式と調整手順を使用して、有効なビーコンの長さを推定できます。これらの式は、ビーコンが生成する可能性のある誤検出の平均数の推定値を提供しますが、データセット内の一意の値ごとに特定の数の誤検出を保証するわけではありません。最初のステップは、母集団を推定することです。

母集団を推定する

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

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

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

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

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

母集団サイズからのビーコンの長さの計算

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

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

b = log₂(p) − 1
  

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

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

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

ビーコンの長さに関する高度なトピック

上級ユーザーは、ソリューションに適したビーコンの長さを選択する柔軟性が高まります。クエリパフォーマンスへの不要な影響を最小限に抑えながら、データの機密性を適切に保護する長さを選択する必要があります。ビーコンによって維持されるセキュリティの量は、データセットの分布と、ビーコンの構築元となるフィールドの相関関係によって異なります。

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

高度なビーコンの長さの例

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