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

検索可能な暗号化

検索可能な暗号化を使用すると、データベース全体を復号することなく、暗号化されたレコードを検索できます。これはビーコンを使用して実現されます。ビーコンは、フィールドに書き込まれるプレーンテキストの値と、実際にデータベースに格納される暗号化された値との間のマップを作成します。 AWS Database Encryption は、レコードに追加する新しいフィールドにビーコンSDKを保存します。使用するビーコンのタイプに応じて、暗号化されたデータに対して、完全一致検索や、よりカスタマイズされた複雑なクエリを実行できます。

ビーコンは、フィールドのプレーンテキストと暗号化された値の間にマップを作成する、切り捨てられたハッシュベースのメッセージ認証コード (HMAC) タグです。検索可能な暗号化用に設定された暗号化されたフィールドに新しい値を書き込むと、 AWS Database Encryption はプレーンテキスト値HMACで をSDK計算します。このHMAC出力は、そのフィールドのプレーンテキスト値に対する 1 対 1 (1:1) の一致です。HMAC 出力は切り捨てられ、複数の個別のプレーンテキスト値が同じ切り捨てられたHMACタグにマッピングされます。これらの誤検知により、不正ユーザーは、プレーンテキストの値に関する特徴的な情報を識別しにくくなります。ビーコンをクエリすると、 AWS Database Encryption SDKは自動的にこれらの誤検出を除外し、クエリのプレーンテキストの結果を返します。

各ビーコンについて生成される誤検知の平均数は、切り詰めた後に残っているビーコンの長さによって決まります。実装に適切なビーコンの長さを決定する方法については、「ビーコンの長さの決定」を参照してください。

ビーコンが適しているデータセット

ビーコンを使用して、暗号化されたデータをクエリすると、クライアント側の暗号化されたデータベースに関連するパフォーマンスコストが削減されます。ビーコンを使用する場合、クエリの効率性と、データの分布に関して明らかになる情報の量との間には、固有のトレードオフが存在します。ビーコンはフィールドの暗号化状態を変更しません。 AWS Database Encryption を使用してフィールドを暗号化して署名するとSDK、フィールドのプレーンテキスト値がデータベースに公開されることはありません。データベースには、フィールドのランダム化および暗号化された値が格納されます。

ビーコンは、計算元の暗号化されたフィールドと一緒に格納されます。これは、不正ユーザーが暗号化されたフィールドのプレーンテキストの値を表示できない場合でも、ビーコンに対して統計分析を実行してデータセットの分布の詳細を知ることができ、極端な場合には、ビーコンがマッピングするプレーンテキストの値を識別できる場合があることを意味します。ビーコンを設定する方法によって、これらのリスクを軽減できます。特に、適切なビーコンの長さを選択することは、データセットの機密性を維持するのに役立ちます。

検索可能な暗号化では、すべてのデータセットについて、必要なレベルのパフォーマンスとセキュリティの両方を提供できない場合があります。ビーコンを設定する前に、脅威モデル、セキュリティ要件、パフォーマンスのニーズを確認してください。

検索可能な暗号化がデータセットに適しているかどうかを判断する際には、データセットの一意性に関する次の要件を考慮してください。

相関するフィールドがデータセットに含まれている場合や、分布が不均一である場合でも、ビーコンをより短くすることで、データセットの機密性を維持するビーコンを構築できる場合があります。ただし、ビーコンの長さは、データセット内のすべての一意の値が多数の誤検知を生成し、データセットに関して明らかになる特徴的な情報の量を効果的かつ最小限に抑えることを保証するものではありません。ビーコンの長さによって推定されるのは、生成される誤検知の平均数のみです。データセットが不均一に分布しているほど、生成される誤検知の平均数を決定する際のビーコンの長さの有効性は低くなります。

ビーコンを構築するフィールドの分布を慎重に検討し、セキュリティ要件を満たすためにビーコンの長さをどの程度切り詰める必要があるのかを検討してください。この章の次のトピックは、ビーコンが統一的に分布しており、相関データが含まれていないことを前提としています。

検索可能な暗号化のシナリオ

次の例は、検索可能な暗号化のシンプルなソリューションを示しています。アプリケーションでは、この例で使用されているフィールド例は、ビーコンの分布および相関の一意性に関する推奨事項を満たしていない可能性があります。この章の検索可能な暗号化の概念を読む際に、この例を参考として使用できます。

会社の従業員データを追跡する Employees という名前のデータベースについて考えてみましょう。データベース内の各レコードには、EmployeeID、LastName、FirstNameおよびアドレス というフィールドが含まれています。Employees データベース内の各フィールドは、プライマリキー EmployeeID によって識別されます。

データベース内のプレーンテキストレコードの例を次に示します。

{
    "EmployeeID": 101,
    "LastName": "Jones",
    "FirstName": "Mary",
    "Address": {
                "Street": "123 Main",
                "City": "Anytown",
                "State": "OH",
                "ZIPCode": 12345
    }
}

暗号化アクションで LastName フィールドと FirstName フィールドを ENCRYPT_AND_SIGN とマークした場合、これらのフィールドの値は、データベースにアップロードされる前にローカルで暗号化されます。アップロードされる暗号化データは完全にランダム化されており、データベースはこのデータが保護されているとは認識しません。典型的なデータエントリを検出するだけです。つまり、実際にデータベースに格納されるレコードは次のようになります。

{
    "PersonID": 101,
    "LastName": "1d76e94a2063578637d51371b363c9682bad926cbd",
    "FirstName": "21d6d54b0aaabc411e9f9b34b6d53aa4ef3b0a35",
    "Address": {
                "Street": "123 Main",
                "City": "Anytown",
                "State": "OH",
                "ZIPCode": 12345
    }
}

LastName フィールドでデータベースに完全一致をクエリする必要がある場合は、 という名前の標準ビーコンを設定して、LastNameフィールドに書き込まれたプレーンテキストの値をデータベースに保存されている暗号化された値にLastNameマッピングします。

このビーコンは、 LastNameフィールドのプレーンテキスト値HMACsから計算します。各HMAC出力は切り捨てられるため、プレーンテキスト値と完全に一致しなくなります。例えば、Jones の完全なハッシュと切り詰められたハッシュは次のようになります。

完全なハッシュ

2aa4e9b404c68182562b6ec761fcca5306de527826a69468885e59dc36d0c3f824bdd44cab45526f70a2a18322000264f5451acf75f9f817e2b35099d408c833

切り詰められたハッシュ

b35099d408c833

標準ビーコンを設定した後、LastName フィールド上で一致検索を実行できます。例えば、 を検索する場合はJones、LastNameビーコンを使用して次のクエリを実行します。

LastName = Jones

AWS Database Encryption は誤検出SDKを自動的に除外し、クエリのプレーンテキストの結果を返します。