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

C3R 暗号化クライアントのガイドライン

C3R 暗号化クライアントは、組織が機密データをまとめてデータ分析から新しいインサイトを引き出すために使用するツールです。このツールは、任意の当事者およびプロセス AWS で学習できる内容を暗号的に制限します。これはきわめて重要ですが、データを暗号化によって保護するプロセスでは、コンピューティングリソースとストレージリソースの両面で大きなオーバーヘッドが生じる可能性があります。そのため、各設定を使用する際のトレードオフや、必要な暗号化保証を維持しながら最適な設定を行う方法を理解することが重要です。このトピックでは、C3R 暗号化クライアントとスキーマのさまざまな設定がパフォーマンスに与える影響に焦点を当てています。

C3R 暗号化クライアントの暗号化設定はすべて、異なる暗号化保証を提供します。コラボレーションレベルの設定が、デフォルトでは最も安全です。コラボレーションの作成中に追加機能を有効にすると、暗号文で頻度分析などのアクティビティを実行できるようになり、プライバシーの保証が弱まります。これらの設定がどのように使用され、どのような影響を及ぼすかの詳細については、「Cryptographic Computing for Clean Rooms」を参照してください。

列タイプがパフォーマンスに与える影響

C3R ではcleartext、fingerprint、sealedの 3 つの列タイプを使用します。これらの列タイプはそれぞれ異なる暗号化保証を提供し、使用目的も異なります。以下のセクションでは、列タイプがパフォーマンスに与える影響と、各設定がパフォーマンスに与える影響について説明します。

Cleartext列

Cleartext列は元の形式から変更されておらず、暗号化処理もされていません。この列タイプを設定することはできず、ストレージやコンピューティングのパフォーマンスにも影響はありません。

Fingerprint列

Fingerprint列は複数のテーブルにまたがるデータを結合するために使用されます。そのためには、生成される暗号文のサイズが常に同じでなければなりません。ただし、これらの列はコラボレーションレベルの設定による影響を受けます。Fingerprint列は、入力に含まれるcleartextに応じて、出力ファイルのサイズにさまざまな程度の影響を与える可能性があります。

fingerprint列の基本オーバーヘッド

fingerprint列には基本オーバーヘッドがあります。このオーバーヘッドは一定であり、cleartextのバイトサイズに代わるものです。

fingerprint列内のデータは、Hash-based Message Authentication Code (HMAC)関数によって暗号化処理され、データが 32 バイトのメッセージ認証コード (MAC) に変換されます。その後、このデータは base64 エンコーダで処理され、バイトサイズが約 33% 増加します。先頭には、データが属する列の種類とそれを生成したクライアントバージョンを示す 8 バイトの C3R 指定子が付加されます。最終結果は 52 バイトです。次に、この結果に行数を掛けて、基本オーバーヘッドの合計を求めます (preserveNulls が true に設定されている場合は、null 値以外の合計数を使用します)。

以下の図は、 BASE_OVERHEAD = C3R_DESIGNATION + (MAC * 1.33) を表しています。

fingerprint列の出力暗号文は常に 52 バイトです。cleartextの入力データの平均が 52 バイトを超える場合 (完全な住所など) は、これによってストレージサイズが大幅に減少する可能性があります。cleartextの入力データの平均が 52 バイト未満の場合 (顧客の年齢など) は、ストレージサイズが大幅に増える可能性があります。

fingerprint列のコラボレーション設定

preserveNulls の設定

コラボレーションレベルの preserveNulls 設定が false (デフォルト) の場合、各 null 値は固有のランダムな 32 バイトに置き換えられ、null ではないかのように処理されます。結果として、各 null 値は 52 バイトになります。これにより、データが非常に少ないテーブルでは、この設定が true で null 値が null として渡される場合と比べて、ストレージ要件が大幅に増加する可能性があります。

この設定によるプライバシー保証が不要で、null 値をデータセット内に保持する場合は、コラボレーションの作成時に preserveNulls 設定を有効にしてください。コラボレーションの作成後に preserveNulls 設定を変更することはできません。

fingerprint列のデータ例

以下は、再現可能な設定を含むfingerprint列の入出力データのサンプルセットです。allowCleartext や allowDuplicates などの他のコラボレーションレベルの設定は結果に影響せず、ローカルで再現を試みる場合は true または false に設定できます。

共有シークレットの例: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

コラボレーション ID の例: a1b2c3d4-5678-90ab-cdef-EXAMPLE11111

allowJoinsOnColumnsWithDifferentNames: True。この設定はパフォーマンスやストレージ要件には影響しません。ただし、この設定を行うと、次の表に示す値を再現するときに、列名の選択は重要ではなくなります。

fingerprint列のトラブルシューティング

fingerprint列の暗号文が、入力されたcleartextのサイズより数倍大きいのはなぜですか?

fingerprint列の暗号文の長さは常に 52 バイトです。入力データが小さい場合 (顧客の年齢など) は、サイズが大幅に増加します。この現象は、preserveNulls 設定が false に設定されている場合にも発生する可能性があります。

fingerprint列の暗号文が、入力されたcleartextのサイズより数倍小さいのはなぜですか?

fingerprint列の暗号文の長さは常に 52 バイトです。入力データが大きい場合 (顧客の完全な住所など) は、サイズが大幅に減少します。

preserveNulls による暗号保証が必要かどうかはどうすればわかりますか?

答えは状況により異なります。少なくとも、preserveNulls 設定によってデータがどのように保護されるかを「暗号コンピューティングパラメータ」で確認する必要があります。ただし、組織のデータ処理要件と、それぞれのコラボレーションに適用される契約を参照することをお勧めします。

base64 のオーバーヘッドが発生するのはなぜですか?

CSV などの表形式のファイル形式との互換性を保つには、base64 エンコーディングが必要です。Parquet などの一部のファイル形式はデータのバイナリ表現をサポートしていますが、適切なクエリ結果を得るためには、コラボレーションのすべての参加者が同じ方法でデータを表現することが重要です。

Sealed列

Sealed列は、コラボレーションのメンバー間でデータを転送するために使用します。これらの列の暗号文は非確定的であり、列の構成方法によってはパフォーマンスとストレージの両方に大きな影響を与えます。これらの列は個別に設定でき、多くの場合、C3R 暗号化クライアントのパフォーマンスとそれに伴う出力ファイルサイズに最も大きな影響を与えます。

sealed列の基本オーバーヘッド

sealed列には基本オーバーヘッドがあります。このオーバーヘッドは一定であり、cleartextとパディング (ある場合) のバイトサイズに追加されるものです。

暗号化の前に、sealed列のデータの先頭には、含まれるデータのタイプを示す 1 バイトの文字が付加されます。パディングを選択すると、データがパディングされ、パッドサイズを示す 2 バイトが追加されます。これらのバイトが追加された後、データは AES-GCM を使用して暗号化処理され、IV (12 バイト)、nonce (32 バイト)、Auth Tag (16 バイト) と共に格納されます。その後、このデータは base64 エンコーダで処理され、バイトサイズが約 33% 増加します。データの先頭には、データが属する列の種類とその生成に使用されたクライアントバージョンを示す 7 バイトの C3R 指定子が付加されます。その結果、最終的な基本オーバーヘッドは 91 バイトになります。次に、この結果に行数を掛けて、基本オーバーヘッドの合計を求めます (preserveNulls が true に設定されている場合は、null 値以外の合計数を使用します)。

以下の図は、 BASE_OVERHEAD = C3R_DESIGNATION + ((NONCE + IV + DATA_TYPE + PAD_SIZE + AUTH_TAG) * 1.33) を表しています。

sealed列のコラボレーション設定

preserveNulls の設定

コラボレーションレベルの preserveNulls 設定が false (デフォルト) の場合、各 null 値は固有のランダムな 32 バイト値となり、null ではないかのように処理されます。結果として、各 null 値は 91 バイト (パディングされている場合はそれ以上) になります。これにより、データが非常に少ないテーブルでは、この設定が true で null 値が null として渡される場合と比べて、ストレージ要件が大幅に増加する可能性があります。

この設定によるプライバシー保証が不要で、null 値をデータセット内に保持する場合は、コラボレーションの作成時に preserveNulls 設定を有効にしてください。コラボレーションの作成後に preserveNulls 設定を変更することはできません。

スキーマ設定sealed列: パディングタイプ

パディングタイプ none

none のパディングタイプを選択すると、cleartextにパディングは追加されず、前述の基本オーバーヘッドにさらにオーバーヘッドが追加されることもありません。パディングがないと、最もスペース効率の良い出力サイズになります。ただし、fixed や max のパディングタイプと同じプライバシー保証は提供されません。これは、基になるcleartextのサイズが暗号文のサイズから識別できるためです。

パディングタイプ fixed

fixed のパディングタイプを選択すると、列に含まれるデータの長さが隠蔽され、プライバシーを保護する手段となります。これは、暗号化の前に、すべてのcleartextを指定された pad_length にパディングすることで行われます。このサイズを超えるデータがあると、C3R 暗号化クライアントは機能しなくなります。

暗号化の前にcleartextにパディングが追加される場合、AES-GCM で、cleartextと暗号文のバイトとの 1 対 1 のマッピングが行われます。base64 エンコーディングによってサイズが 33% 増加します。パディングによって増加するストレージのオーバーヘッドは、pad_length の値からcleartextの長さの平均値を引き、1.33 を掛けることで算出できます。その結果が、レコードごとのパディングの平均オーバーヘッドになります。次に、この結果に行の数を掛けて、パディングのオーバーヘッドの合計を求めます (preserveNulls が true に設定されている場合は、null 値以外の合計数を使用します)。

PADDING_OVERHEAD = (PAD_LENGTH - AVG_CLEARTEXT_LENGTH) * 1.33 * ROW_COUNT

pad_length の最小値には、列内の最大値が収まる値を選択することをお勧めします。例えば、最大値が 50 バイトの場合は、50 バイトの pad_length で十分です。これより大きい値では、ストレージのオーバーヘッドが増えるだけです。

固定長のパディングでは、コンピューティングのオーバーヘッドは大幅に増加しません。

パディングタイプ max

max のパディングタイプを選択すると、列に含まれるデータの長さが隠蔽され、プライバシーを保護する手段となります。これは、暗号化の前に、すべての cleartext を列内の最大値に追加の pad_length を加算した値までパディングすることで行われます。一般に、max のパディングは 1 つのデータセットに対して fixed のパディングと同様の保証を提供しますが、列内のcleartextの最大値を把握していなくてもかまいません。ただし、更新時には、個々のデータセットの最大値が変わる場合があるため、max のパディングで fixed のパディングと同様のプライバシー保証が提供されるとは限りません。

max のパディングを使用するときは、0 の pad_length を追加で選択することをお勧めします。この長さにより、すべての値が列の最大値と同じサイズにパディングされます。これより大きい値では、ストレージのオーバーヘッドが増えるだけです。

特定の列の cleartext の最大値がわかっている場合は、代わりに fixed のパディングタイプを使用することをお勧めします。fixed のパディングを使用すると、データセットの更新前後で一貫性が保たれます。max のパディングを使用すると、データの各サブセットが、そのサブセットにあった最大値までパディングされます。

sealed列のデータ例

以下は、再現可能な設定を含む sealed 列の入出力データのサンプルセットです。allowCleartext、allowJoinsOnColumnsWithDifferentNames、allowDuplicates などの他のコラボレーションレベルの設定は結果に影響せず、ローカルで再現を試みる場合は true または false に設定できます。これらは再現するための基本設定ですが、sealed 列は非確定的であり、値は毎回変動します。目標は、入力されたバイトと出力されたバイトを比較することです。サンプルの pad_length 値は意図的に選択されています。ここでは、fixed のパディングが、推奨される最小 pad_length 設定を使用した max のパディングと同じ値になること、または追加のパディングが望ましいケースが示されています。

共有シークレットの例: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

コラボレーション ID の例: a1b2c3d4-5678-90ab-cdef-EXAMPLE11111

パディングタイプ none

パディングタイプ fixed (例 1)

この例では、pad_length は 62 で最大入力値は 62 バイトです。

パディングタイプ fixed (例 2)

この例では、pad_length は 162 で最大入力値は 62 バイトです。

パディングタイプ max (例 1)

この例では、pad_length は 0 で最大入力値は 62 バイトです。

パディングタイプ max (例 2)

この例では、pad_length は 100 で最大入力値は 62 バイトです。

sealed列のトラブルシューティング

sealed列の暗号文が、入力されたcleartextのサイズより数倍大きいのはなぜですか?

これはいくつかの要因によって異なります。第一に、Cleartext 列の暗号文の長さは必ず 91 バイト以上になります。入力データが小さい場合 (顧客の年齢など) は、サイズが大幅に増加します。第二に、preserveNulls が false に設定されており、入力データに多数の null 値が含まれていた場合、それらの null 値がそれぞれ 91 バイトの暗号文に変換されます。そして最後に、パディングを使用すると、当然のことながら、暗号化の前に cleartext データにバイトが追加されます。

sealed 列のほとんどのデータは非常に小さいのですが、パディングを使う必要があります。スペースを節約するために、大きな値を除外して別途処理することはできますか?

大きな値を除外して別途処理することはお勧めしません。そうすることで、C3R 暗号化クライアントで提供されるプライバシー保証が変わります。脅威の一例として、観察者が暗号化された両方のデータセットを見ることができると仮定します。あるデータサブセットの列のパディングが別のサブセットよりも大幅に大きかったり小さかったりすることを観察者に知られると、各サブセット内のデータのサイズが推測されるおそれがあります。例えば fullName 列が、あるファイルでは合計 40 バイトにパディングされ、別のファイルでは 800 バイトにパディングされているとします。この場合観察者は、一方のデータセットに世界で最も長い名前 (747 バイト) が含まれていると仮定する可能性があります。

max のパディングタイプを使用する場合、追加のパディングは必要ですか?

いいえ。max のパディングを使用するときは、pad_length (列の最大値を超える追加パディングとも呼ばれます) を 0 に設定することをお勧めします。

fixed のパディングを使用するときに、最大値が確実に収まるよう pad_length に大きい値を選択してもよいですか？

はい。ただし、パディングの長さが長いと効率が低下し、必要以上に多くのストレージを消費します。最大値の大きさを確認し、pad_length にその値を設定することをおすすめします。

preserveNulls による暗号保証が必要かどうかはどうすればわかりますか?

答えは状況により異なります。少なくとも、preserveNulls 設定によってデータがどのように保護されるかを「Cryptographic Computing for Clean Rooms」で確認する必要があります。ただし、組織のデータ処理要件と、それぞれのコラボレーションに適用される契約を参照することをお勧めします。

base64 のオーバーヘッドが発生するのはなぜですか?

CSV などの表形式のファイル形式との互換性を保つには、base64 エンコーディングが必要です。Parquet などの一部のファイル形式はデータのバイナリ表現をサポートしていますが、適切なクエリ結果を得るためには、コラボレーションのすべての参加者が同じ方法でデータを表現することが重要です。

暗号文のサイズが予期せず大きくなった場合のトラブルシューティング

データを暗号化し、生成されたデータのサイズが驚くほど大きかったとしましょう。次の手順は、サイズが増加している場所と、実行できるアクション (ある場合) を特定するのに役立ちます。

サイズの増加が発生した場所の特定

暗号化されたデータが cleartext データよりも大幅に大きくなった理由をトラブルシューティングする前に、まずサイズが増加している場所を特定する必要があります。Cleartext 列は変更されていないため、無視しても問題ありません。残りの fingerprint 列と sealed 列を見て、大幅に増えている列を 1 つ選びます。

サイズが増加した理由の特定

fingerprint 列または sealed 列がサイズ増加の原因となっている可能性があります。

fingerprint列が原因でサイズの増加が生じている場合

ストレージ増加の最も大きな原因となっているのがfingerprint列である場合は、cleartextデータが小さいこと (顧客の年齢など) が要因と考えられます。生成される各fingerprint暗号文の長さは 52 バイトになります。残念ながら、この問題について列単位で対処できることは何もありません。ストレージ要件への影響など、この列の詳細については「fingerprint列の基本オーバーヘッド」を参照してください。

fingerprint列のサイズが大きくなるもう 1 つの原因として、preserveNulls のコラボレーション設定が考えられます。preserveNulls のコラボレーション設定が無効 (デフォルト設定) になっていると、fingerprint 列の null 値はすべて 52 バイトの暗号文になります。現在のコラボレーションでは、これに対してできることは何もありません。preserveNulls 設定はコラボレーションの作成時に設定され、正しいクエリ結果を得るためにすべてのコラボレーターが同じ設定を使用する必要があります。preserveNulls 設定の詳細と、この設定を有効にした場合にデータのプライバシー保護にどのような影響が及ぶかについては、「Cryptographic Computing for Clean Rooms」を参照してください。

sealed 列が原因でサイズの増加が生じている場合

ストレージ増加の最も大きな原因となっているのが sealed 列である場合、サイズの増加を引き起こしている可能性のある要因がいくつかあります。

cleartext データが小さい場合 (顧客の年齢など)、生成される各 sealed 暗号文の長さは 91 バイト以上になります。残念ながら、この問題についてできることは何もありません。ストレージ要件への影響など、この列の詳細については「sealed列の基本オーバーヘッド」を参照してください。

sealed列でストレージが増加する 2 つ目の主な要因はパディングです。パディングとは、データセット内の個々の値のサイズを隠蔽するために、暗号化の前にcleartextに余分なバイトを追加することです。データセットにとって最小限の値でパディングを設定することをお勧めします。少なくとも、fixed パディングの pad_length は、列内で考えられる最大の値が収まるように設定する必要があります。これより大きい値を設定しても、プライバシー保証は追加されません。例えば、列内で考えられる最大の値が 50 バイトであることがわかっている場合は、pad_length を 50 バイトに設定することをお勧めします。ただし、sealed 列で max のパディングを使用している場合は、pad_length を 0 バイトに設定することをお勧めします。これは、max のパディングが、列内の最大値を超える追加のパディングを指すためです。

sealed列のサイズが大きくなる原因として考えられる最後の要因は、preserveNulls のコラボレーション設定です。preserveNulls のコラボレーション設定が無効 (デフォルト設定) になっていると、sealed 列の null 値はすべて 91 バイトの暗号文になります。現在のコラボレーションでは、これに対してできることは何もありません。preserveNulls 設定はコラボレーションの作成時に設定され、正しいクエリ結果を得るためにすべてのコラボレーターが同じ設定を使用する必要があります。この設定の詳細と、設定を有効にした場合にデータのプライバシー保護にどのような影響が及ぶかについては、「Cryptographic Computing for Clean Rooms」を参照してください。