翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
ビーコン
| クライアント側の暗号化ライブラリの名前が AWS Database Encryption SDK に変更されました。このデベロッパーガイドでは、引き続き DynamoDB Encryption Client に関する情報を提供します。 |
ビーコンは、切り捨てられたハッシュベースのメッセージ認証コード (HMAC) タグで、プレーンテキストのフィールド値を、データベース内の暗号化されたデータと共に保存される暗号化された検索可能な識別子にマッピングします。ビーコンはフィールドの暗号化状態を変更しません。検索可能な暗号化用に設定されたフィールドに値を書き込むと、AWS Database Encryption SDK はプレーンテキスト値で HMAC を計算し、パーティションのコンテキストでビーコンを取得します。完全な HMAC はプレーンテキスト値に一意に対応しますが、SDK は複数の個別のプレーンテキスト値を同じビーコンにマッピングできるように出力を意図的に切り捨てます。これらの衝突 (偽陽性) により、不正なユーザーが基盤となるプレーンテキストに関する情報を区別する能力が制限されます。
注記
Hash-based Message Authentication Code (HMAC) は、整合性と信頼性を提供するために一般的に使用されるキー付き暗号化ハッシュ関数です。検索可能な暗号化システムでは、HMAC はプレーンテキスト値から決定的にビーコンを導き出すためによく使用され、インデックスを作成してクエリを実行できます。
完全長 HMAC は決定論的です。特定のキーの場合、同じプレーンテキスト値は常に同じビーコンを生成します。この決定論により、プレーンテキスト値とビーコンが one-to-one でマッピングされ、データの元の頻度分布が保持されます。同じプレーンテキスト値を共有するすべてのレコードは、同じビーコンにマッピングされるため、等価クラスを形成します。各同等性クラスのサイズは、対応するプレーンテキスト値がデータセットに表示される頻度を直接反映します。
この頻度の保存により、観測者が観測されたビーコン頻度を既知のデータ分布または予想されるデータ分布と相関させることで、プレーンテキストの可能性が高い値を推測する頻度分析攻撃が可能になります。
頻度分析攻撃を軽減するために、SDK は切り捨てとパーティショニングを使用してビーコンを取得します。HMAC を切り捨てると制御された衝突が発生するため、同等性クラス内のすべてのレコードが同じビーコン値を共有するとは限りません。さらに、パーティション識別子をビーコン取得に組み込むことで、同じプレーンテキスト値をパーティション間で異なるビーコンにマッピングできます。これらの手法を組み合わせると、正確で効率的なクエリ動作を維持しながら、不均等に分散されたデータセットのランダム性が向上します。
ビーコンは、暗号化アクションSIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXTで ENCRYPT_AND_SIGN、SIGN_ONLY、または とマークされたフィールドからのみ構築できます。ビーコン自体は署名も暗号化もされません。DO_NOTHING とマークされているフィールドを使用してビーコンを構築することはできません。
ビーコンを設定した後、暗号化されたフィールドを検索する前に、各ビーコンについてセカンダリインデックスを設定する必要があります。詳細については、「ビーコンを使用したセカンダリインデックスの設定」を参照してください。
パーティション間のビーコン取得について
パーティション分割はビーコン設定の中核部分であり、単一のパーティションを使用するビーコンを含むすべてのビーコンに適用されます。このモデルにより、すべてのデータにわたって一貫した前方互換性のあるビーコン取得が保証され、データ量や分散の変化に応じて時間の経過とともにパーティションの数を増やすことができます。これにより、既存の項目を書き換えることなく、頻度の漏洩を減らし、不均等に分散されたデータセットの保護を強化できます。
パーティションは、複数の論理グループに項目を分散することで、制御されたランダム性を導入します。これにより、周波数漏洩が軽減され、ビーコン同等性クラスのサイズが制限され、分散が歪んだ属性のセキュリティとプライバシーが向上します。
項目がパーティションに割り当てられると、パーティション番号がビーコン取得に組み込まれます。同じパーティション内では、同じプレーンテキスト値が同じビーコンを生成し、等価検索セマンティクスを維持します。異なるパーティション間で、同じプレーンテキスト値が異なるビーコン値を生成します。これにより、大きな等価クラスがパーティションごとの小さなグループに分割され、ビーコンの全体的な頻度分布が平坦化されます。
各データベース項目をパーティションに割り当てる方法を完全に制御できます。項目は特定のパーティションに決定的に配置することも、ランダムに分散して不均一なデータ分散を滑らかにすることもできます。ランダム割り当ては、これらの値を複数のパーティションに分散し、単一のパーティションの可視濃度を低下させるため、高頻度の値に特に役立ちます。決定的割り当ては、ドメインの知識が、特定の値をより少ないパーティションに制限する必要があることを示している場合に使用できます。
パーティション識別子は、暗号化されたレコードでは公開されません。代わりに、パーティション番号はプレーンテキスト値と一緒にハッシュされたビーコン取得プロセスに組み込まれるため、暗号化されたデータまたはビーコン自体を調べることで推測することはできません。この設計により、パーティション割り当ての機密性を維持しながら、パーティション化されたビーコンの分散とプライバシーのメリットが得られます。
- クエリに対するパーティション分割の影響
-
パーティション分割は、
Queryオペレーションの実行方法に影響します。DynamoDB クエリではインデックス付きビーコン値に完全一致が必要であり、ビーコン値はパーティション間で異なるため、呼び出し元は各パーティションを個別にクエリする必要があります。テーブルにNパーティションがある場合:-
一致するすべての項目を取得するには、
N個別のクエリが必要です。 -
のみが影響を受け
Queryます。 -
ScanおよびGetオペレーションは、以前と同じように動作します。
理由は構造的です。 はすべての項目を
Scan読み取り、特定のキーでGet動作します。インデックスの正確な等価性にのみQuery依存し、パーティション固有になります。注記
ファンアウトとは、パーティション化されたビーコンを使用するときに 1 つの論理リクエストを満たすために発行する必要がある DynamoDB クエリの数を指します。システムは、制限されたファンアウトを提供します。つまり、パーティションレベルのクエリの最大数は、設定されたパーティション数に基づいて固定され、予測可能です。
パフォーマンスに関する考慮事項
パーティションを使用すると、論理リクエストごとに必要な DynamoDB クエリの数に影響します。パフォーマンスへの影響は、期待される結果サイズによって異なります。
-
大きな結果セット: クエリが多くのページを返す場合、追加のパーティションレベルのクエリはオーバーヘッドをほとんど追加しません。
-
単一項目ルックアップ: リクエストが通常 1 つの項目を返し、5 つのパーティションが設定されている場合、5 つのクエリが発行されます。4 つは結果を返さず、ほぼ線形のスローダウンになります。
-
ローカリティの低下: 項目はパーティションに分散され、取得時間が長くなる可能性があります。
各パーティションは追加のクエリをトリガーするため、ファンアウトはパフォーマンスと容量を計画する際の重要な要素です。
パフォーマンス上の利点
追加のクエリオーバーヘッドにもかかわらず、パーティションは特定のシナリオでパフォーマンスを向上させることができます。
-
大きな等価クラスを減らす: まれな値が切り捨てられたビーコンを頻繁に発生する値と共有する場合、まれな値のクエリは無関係なマッチングを多数処理する必要があります。パーティション分割は、各等価クラスのサイズを制限し、このオーバーヘッドを減らします。
-
より長いビーコン長のサポート: より多くのパーティションを設定すると、より長いビーコン長を使用できるため、偽陽性率が低下し、必要な復号後フィルタリングの量が減少します。
-
ビーコンタイプ
設定するビーコンのタイプによって、実行できるクエリのタイプが決まります。検索可能な暗号化をサポートするビーコンには 2 つのタイプがあります。標準ビーコンは、一致検索を実行します。複合ビーコンは、リテラルプレーンテキスト文字列と標準ビーコンを組み合わせて、複雑なデータベースオペレーションを実行します。
標準ビーコン
標準ビーコンは、データベースで検索可能な暗号化を実装する最も簡単な方法です。単一の暗号化されたフィールドまたは仮想フィールドについてのみ一致検索を実行できます。標準ビーコンの設定方法については、「標準ビーコンの設定」を参照してください。また、ビーコンを含むパーティションを使用して、基になるデータに不均等な分布がある場合にランダム性を高めることもできます。
以下は、標準ビーコンの重要な概念です。
- ビーコンソース
-
標準ビーコンが構築されるフィールドは、ビーコンソースと呼ばれます。これは、ビーコンがマッピングする必要があるデータの場所を識別します。ビーコンソースは、暗号化されたフィールドまたは仮想フィールドのいずれかです。各標準ビーコンのビーコンソースは一意である必要があります。同じビーコンソースで 2 つのビーコンを設定することはできません。
標準ビーコンを使用して、暗号化されたフィールドまたは仮想フィールドの等価検索を実行できます。または、複合ビーコンを構築して、より複雑なデータベースオペレーションを実行することもできます。標準ビーコンの整理と管理に役立つように、 AWS Database Encryption SDK には、標準ビーコンの用途を定義する以下のオプションビーコンスタイルが用意されています。詳細については、「ビーコンスタイルの定義」を参照してください。
単一の暗号化されたフィールドに対して等価検索を実行する標準ビーコンを作成することも、仮想フィールドを作成して複数の
ENCRYPT_AND_SIGN、、SIGN_ONLYおよびSIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXTフィールドの連結に対して等価検索を実行する標準ビーコンを作成することもできます。
- 仮想フィールド
-
仮想フィールドは、1 つ以上のソースフィールドから構築された概念的なフィールドです。仮想フィールドを作成しても、レコードに新しいフィールドは書き込まれません。仮想フィールドは、データベースに明示的に格納されません。これは、フィールドの特定のセグメントを識別する方法、またはレコード内の複数のフィールドを連結して特定のクエリを実行する方法についてビーコンに指示を与えるために、標準ビーコン設定で使用されます。仮想フィールドには少なくとも 1 つの暗号化されたフィールドが必要です。
注記
例えば、
FirstNameおよびLastNameフィールドの連結に対して一致検索を実行する場合は、次のいずれかの仮想フィールドを作成することが考えられます。-
FirstNameフィールドの最初の文字と、それに続くLastNameフィールドから構築される仮想NameTagフィールド (すべて小文字)。この仮想フィールドを使用すると、NameTag=mjonesをクエリできます。 -
LastNameフィールドと、それに続くFirstNameフィールドから構築される仮想LastFirstフィールド。この仮想フィールドを使用すると、LastFirst=JonesMaryをクエリできます。
または、暗号化されたフィールドの特定のセグメントに対して一致検索を実行する場合は、クエリを実行するセグメントを識別する仮想フィールドを作成します。
例えば、IP アドレスの最初の 3 つのセグメントを使用して暗号化された
IPAddressフィールドをクエリする場合は、次の仮想フィールドを作成します。-
Segments(‘.’, 0, 3)から構築された仮想IPSegmentフィールド。この仮想フィールドを使用すると、IPSegment=192.0.2をクエリできます。クエリは、「192.0.2」で始まるIPAddressの値を持つすべてのレコードを返します。
仮想フィールドは一意である必要があります。2 つの仮想フィールドをまったく同じソースフィールドから構築することはできません。
仮想フィールドとそれらを使用するビーコンの設定については、「仮想フィールドの作成」を参照してください。
-
複合ビーコン
複合ビーコンは、クエリのパフォーマンスを改善するインデックスを作成し、より複雑なデータベースオペレーションを実行できるようにします。複合ビーコンを使用して、リテラルプレーンテキスト文字列と標準ビーコンを組み合わせて、単一のインデックスから 2 つの異なるレコードタイプをクエリしたり、ソートキーを使用してフィールドの組み合わせをクエリしたりするなど、暗号化されたレコードに対して複雑なクエリを実行できます。複合ビーコンソリューションの例については、「ビーコンタイプを選択する」を参照してください。
複合ビーコンは、標準ビーコン、または標準ビーコンと署名付きフィールドの組み合わせから構築できます。これらは部分のリストから構築されます。すべての複合ビーコンには、ビーコンに含まれる ENCRYPT_AND_SIGN フィールドを識別する暗号化された部分のリストが含まれている必要があります。すべての ENCRYPT_AND_SIGN フィールドは、標準ビーコンによって識別される必要があります。より複雑な複合ビーコンには、ビーコンに含まれるプレーンテキストSIGN_ONLYまたはSIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXTフィールドを識別する署名付きパートのリスト、および複合ビーコンがフィールドをアセンブルできる可能性のあるすべての方法を識別するコンストラクタパートのリストが含まれる場合があります。
注記
AWS Database Encryption SDK は、プレーンテキストSIGN_ONLYとSIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXTフィールドから完全に設定できる署名付きビーコンもサポートしています。署名付きビーコンは、インデックスを作成し、暗号化されていない署名付きフィールドに対して複雑なクエリを実行する複合ビーコンの一種です。詳細については、「署名付きビーコンの作成」を参照してください。
複合ビーコンの設定については、「複合ビーコンの設定」を参照してください。
複合ビーコンを設定する方法によって、実行できるクエリのタイプが決まります。例えば、一部の暗号化および署名付きの部分をオプションにして、クエリの柔軟性を高めることができます。複合ビーコンが実行できるクエリのタイプの詳細については、「ビーコンのクエリ」を参照してください。
