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

# Cryptographic Computing for Clean Rooms
<a name="crypto-computing"></a>

Cryptographic Computing for Clean Rooms (C3R) は、[分析ルール](analysis-rules.md)に加えて AWS Clean Rooms 使用できる の機能です。C3R を使うと、組織は機密データをまとめて、データ分析から新しいインサイトを引き出せると同時に、プロセスの中で関係者が知ることのできる事項を暗号化によって制限できます。C3R は、コラボレーションで機密データを扱いたいが、クラウド内の暗号化されたデータのみを使用する必要がある複数の関係者が使用できます。

C3R 暗号化クライアントは、 で使用するデータを[暗号化](glossary.md#glossary-encryption)するために使用できるクライアント側の暗号化ツールです AWS Clean Rooms。C3R 暗号化クライアントを使用する場合、 AWS Clean Rooms データはコラボレーションで使用中も暗号化によって保護されます。通常の AWS Clean Rooms コラボレーションと同様に、入力データはリレーショナルデータベーステーブルであり、計算は SQL クエリとして表されます。ただし、暗号化されたデータに対する SQL クエリについて、C3R は一部の限られたクエリしかサポートしていません。

具体的には、暗号で保護されたデータに対する SQL JOIN および SELECT のステートメントをサポートしています。入力テーブルの各列は、次の SQL ステートメントタイプのいずれか 1 つだけで使用できます。
+ JOIN ステートメントで使用される、暗号化によって保護された列は**fingerprint列**と呼ばれます。
+ SELECT ステートメントで使用される、暗号化によって保護された列は**sealed列**と呼ばれます。
+ JOIN または SELECT ステートメントで使用される、暗号化によって保護されていない列は**cleartext列**と呼ばれます。

場合によっては、GROUP BY ステートメントがfingerprint列でサポートされることもあります。詳細については、「[Fingerprint列](crypto-computing-column-types.md#fingerprint-columns)」を参照してください。現在 C3R では、関連する分析ルールで許可されている場合でも、WHERE 句、または SUM や AVERAGE といった集約関数など、他の SQL 構文の暗号化済みデータへの使用はサポートしていません。

C3R はテーブルの個々のセル内のデータを保護するように設計されています。C3R のデフォルト設定を使用すると、お客様がコラボレーションを通じてサードパーティに提供する基データは、コンテンツが AWS Clean Rooms内部で使用されている間は暗号化されたままになります。C3R では、すべてのsealed列に業界標準の AES-GCM 暗号化を使用し、fingerprint列の保護には Hash-based Message Authentication Code (HMAC) と呼ばれる業界標準の疑似ランダム機能を使用します。

C3R はテーブル内のデータを暗号化しますが、以下の情報は推測できる場合があります。
+ テーブルの列数、列名、行数など、テーブル自体に関する情報。
+ ほとんどの標準的な暗号化形式と同様、C3R では、暗号化された値の長さについては隠蔽を試みません。C3R には、暗号化された値をパディングしてクリアテキストの正確な長さを隠蔽する機能がありますが、各列のクリアテキストの長さの上限は、第三者に把握される可能性があります。
+ 暗号化された C3R テーブルに特定の行がいつ追加されたかなど、ログレベルの情報。

C3R の詳細については、以下のトピックを参照してください。

**Topics**
+ [Cryptographic Computing for Clean Rooms を使用する際の考慮事項](crypto-computing-considerations.md)
+ [Cryptographic Computing for Clean Rooms でサポートされているファイルとデータの種類](crypto-computing-file-types.md)
+ [Cryptographic Computing for Clean Rooms での列名](crypto-computing-column-names.md)
+ [Cryptographic Computing for Clean Rooms での列タイプ](crypto-computing-column-types.md)
+ [暗号コンピューティングパラメータ](crypto-computing-parameters.md)
+ [Cryptographic Computing for Clean Rooms のオプションフラグ](crypto-computing-optional-flags.md)
+ [クエリと Cryptographic Computing for Clean Rooms](crypto-computing-queries.md)
+ [C3R 暗号化クライアントのガイドライン](crypto-computing-guidelines.md)

# Cryptographic Computing for Clean Rooms を使用する際の考慮事項
<a name="crypto-computing-considerations"></a>

Cryptographic Computing for Clean Rooms (C3R) は、データ保護を最大限に強化することを目的としています。ただし、一部のユースケースでは、追加機能と引き換えにデータの保護レベルを下げることでメリットが得られる場合があります。こうした特定のトレードオフは、C3R を最も安全な設定から変更することで実現できます。ユーザーは、これらのトレードオフを認識し、それが自身のユースケースに適しているかどうかを判断する必要があります。考慮すべきトレードオフは次のとおりです。

**Topics**
+ [テーブル内でcleartextデータと暗号化データの混在を許可する](#allow-mixed-plaintext-and-encrypted-data)
+ [fingerprint列で値の繰り返しを許可する](#allow-repeated-values)
+ [fingerprint列の命名方法に関する制限を緩和する](#loose-restrictions-on-join-column-names)
+ [NULL 値の表現方法を決定する](#determine-null-values)

これらのシナリオでのパラメータの使用方法の詳細については、「[暗号コンピューティングパラメータ](crypto-computing-parameters.md)」を参照してください。

## テーブル内でcleartextデータと暗号化データの混在を許可する
<a name="allow-mixed-plaintext-and-encrypted-data"></a>

すべてのデータをクライアント側で暗号化することで、最大限のデータ保護が可能になります。ただし、これにより特定の種類のクエリ (SUM 集約関数など) が制限されます。cleartextデータを許可することのリスクは、暗号化されたテーブルにアクセスできる人なら誰でも暗号化された値に関する情報を推測できるようになることです。これは、cleartextおよび関連するデータを統計的に分析することで可能になります。

例えば、`City` と `State` の列があるとします。`City` 列はcleartextで、`State` 列は暗号化されています。`City` 列の値 `Chicago` を見れば、`State` の値が`Illinois` であることを高い確率で特定できます。逆に、一方の列が `City` で、もう一方の列が `EmailAddress` の場合、暗号化されている `EmailAddress` の情報がcleartext `City` によって明らかになることはまずありません。

このシナリオのパラメータの詳細については、「[[cleartext 列を許可] パラメータ](crypto-computing-parameters.md#parameter-allowcleartext)」を参照してください。

## fingerprint列で値の繰り返しを許可する
<a name="allow-repeated-values"></a>

最も安全な方法では、どのfingerprint列にも変数のインスタンスが 1 つだけ含まれていると想定されてます。1 つのfingerprint列で項目を繰り返すことはできません。C3R 暗号化クライアントは、これらのcleartext値をランダム値と見分けがつかない一意の値にマッピングします。したがって、これらのランダム値からcleartextに関する情報を推測することはできません。

fingerprint列で値が繰り返される場合のリスクは、値が繰り返されるとランダムに見える値も繰り返されることです。したがって理論的には、暗号化されたテーブルにアクセスできる人なら誰でもfingerprint列の統計分析を行って、cleartext値に関する情報を明らかにできる可能性があります。

例えば、fingerprint列が `State` で、テーブルのすべての行が米国の世帯に対応しているとします。頻度分析を行うことで、どの州が `California` でどの州が `Wyoming` であるかを高い確率で推測できます。この推測が可能なのは、`California` の方が `Wyoming` よりも住民の数がはるかに多いからです。逆に、fingerprint列が世帯識別子に関するもので、数百万件のエントリからなるデータベースの中で各世帯が 1 ～ 4 回出現したとします。この場合、頻度分析によって有用な情報が明らかになることはまずありません。

このシナリオのパラメータの詳細については、「[[複製を許可] パラメータ](crypto-computing-parameters.md#parameter-allowduplicates)」を参照してください。

## fingerprint列の命名方法に関する制限を緩和する
<a name="loose-restrictions-on-join-column-names"></a>

デフォルトでは、暗号化されたfingerprint列を使用して 2 つのテーブルが結合される場合、各テーブルのそれらの列は名前が同じであると想定されます。この結果の技術的な理由は、デフォルトでは、各fingerprint列を暗号化するために異なる暗号キーを派生させるからです。このキーは、コラボレーションの共有シークレットキーと列名の組み合わせから派生します。列名の異なる 2 つの列を結合しようとすると、異なるキーが派生し、有効な結合を処理できません。

この問題に対処するには、各列名からキーを派生させる機能をオフにします。すると、C3R 暗号化クライアントはすべてのfingerprint列に 1 つの派生キーを使用します。リスクは、別の種類の頻度分析を行うと、情報が明らかになる可能性があることです。

もう一度 `City` と `State` の例を使ってみましょう。各fingerprint列で同じランダム値を派生させる (列名を組み込まない) 場合、`New York` では `City` 列と `State` 列のランダム値が同じになります。ニューヨークは、米国でも数少ない、`City` と `State` の名前が同じ都市の 1 つです。逆に、データセットの各列の値がまったく異なれば、情報が漏れることはありません。

このシナリオのパラメータの詳細については、「[[名前の異なる列の JOIN を許可] パラメータ](crypto-computing-parameters.md#parameter-allowjoin)」を参照してください。

## NULL 値の表現方法を決定する
<a name="determine-null-values"></a>

選択肢は、NULL 値を他の値と同様に暗号化処理 (暗号化と HMAC) するかどうかです。NULL 値を他の値と同様に処理しないと、情報が漏洩する可能性があります。

例えば、`Middle Name` 列のcleartextの NULL が、ミドルネームのない人を示しているとします。これらの値を暗号化しないと、暗号化されたテーブルのどの行がミドルネームを持たない人に使われているかが漏れてしまいます。そうした情報は、一部の集団の一部の人々にとっては、ある種の識別信号となる可能性があります。しかし、NULL 値を暗号化処理すると、特定の SQL クエリが異なる動作になります。例えば GROUP BY 句では、fingerprint列内のfingerprint NULL 値がまとめてグループ化されなくなります。

このシナリオのパラメータの詳細については、「[[NULL 値を保存] パラメータ](crypto-computing-parameters.md#parameter-preservenulls)」を参照してください。

# Cryptographic Computing for Clean Rooms でサポートされているファイルとデータの種類
<a name="crypto-computing-file-types"></a>

C3R 暗号化クライアントは、以下の種類のファイルを認識します。
+ CSV ファイル
+ Parquet ファイル

C3R 暗号化クライアントの `--fileFormat` フラグを使用して、ファイル形式を明示的に指定できます。明示的に指定した場合、ファイル形式はファイル拡張子によって判断されません。

**Topics**
+ [CSV ファイル](#csv-file-type)
+ [Parquet ファイル](#parquet-file-type)
+ [文字列以外の値の暗号化](#encrypt-non-string-values)

## CSV ファイル
<a name="csv-file-type"></a>

.csv 拡張子の付いたファイルは CSV 形式で、UTF-8 でエンコードされたテキストを含むものとみなされます。C3R 暗号化クライアントはすべての値を文字列として扱います。

### .csv ファイルでサポートされるプロパティ
<a name="csv-properties"></a>

C3R 暗号化クライアントでは、.csv ファイルに次のプロパティが必要です。
+ 各列に一意の名前を付ける最初のヘッダー行 (含まれる場合と含まれない場合があります)。
+ カンマ区切り (現在、カスタム区切り文字はサポートされていません)。
+ UTF-8 でエンコードされたテキスト。

#### .csv エントリからの空白の削除
<a name="whitespace-trimming"></a>

.csv エントリから先頭および末尾の空白が両方とも削除されます。

#### .csv ファイルのカスタム NULL エンコーディング
<a name="custom-null-encoding"></a>

.csv ファイルではカスタム NULL エンコーディングを使用できます。

C3R 暗号化クライアントでは、`--csvInputNULLValue=<csv-input-null>` フラグを使用して入力データの NULL エントリにカスタムエンコーディングを指定できます。C3R 暗号化クライアントは、`--csvOutputNULLValue=<csv-output-null>` フラグを使用することで、生成された出力ファイル内の NULL エントリに対してカスタムエンコーディングを使用できます。

**注記**  
特に SQL テーブルのようなよりリッチな表形式のコンテキストでは、NULL エントリは欠落したコンテンツとみなされます**。.csv は歴史的な理由からこの特性を明示的にサポートしていませんが、空白だけを含む空のエントリは NULL と見なすのが一般的な慣習です。したがって、これは C3R 暗号化クライアントのデフォルト動作であり、必要に応じてカスタマイズできます。

### C3R による .csv エントリの解釈
<a name="interpretation-csv-entries"></a>

次の表は、`--csvInputNULLValue=<csv-input-null>` および `--csvOutputNULLValue=<csv-output-null>` のフラグに指定された値 (存在する場合) に基づいて、.csv エントリを (わかりやすくするために cleartext から cleartext に) 整列化する方法の例を示しています。引用符の外側にある先頭と末尾の空白は、C3R が値の意味を解釈する前に削除されます。


| `<csv-input-null>` | `<csv-output-null>` | 入力エントリ | 出力エントリ | 
| --- |--- |--- |--- |
| None | None | ,任意の製品, | ,任意の製品, | 
| None | None | , 任意の製品 , | ,任意の製品, | 
| None | None | ,"任意の製品", | ,任意の製品, | 
| None | None | , "任意の製品" , | ,任意の製品, | 
| None | None | ,, | ,, | 
| None | None | , , | ,, | 
| None | None | ,"", | ,, | 
| None | None | ," ", | ," ", | 
| None | None | , " " , | ," ", | 
| "任意の製品" | "NULL" | ,任意の製品, | ,NULL, | 
| "任意の製品" | "NULL" | , 任意の製品 , | ,NULL, | 
| "任意の製品" | "NULL" | ,"任意の製品", | ,NULL, | 
| "任意の製品" | "NULL" | , "任意の製品" , | ,NULL, | 
| None | "NULL" | ,, | ,NULL, | 
| None | "NULL" | , , | ,NULL, | 
| None | "NULL" | ,"", | ,NULL, | 
| None | "NULL" | ," ", | ," ", | 
| None | "NULL" | , " " , | ," ", | 
| "" | "NULL" | ,, | ,NULL, | 
| "" | "NULL" | , , | ,NULL, | 
| "" | "NULL" | ,"", | ,"", | 
| "" | "NULL" | ," ", | ," ", | 
| "" | "NULL" | , " " , | ," ", | 
| "\$1"\$1"" | "NULL" | ,, | ,, | 
| "\$1"\$1"" | "NULL" | , , | ,, | 
| "\$1"\$1"" | "NULL" | ,"", | ,NULL, | 
| "\$1"\$1"" | "NULL" | ," ", | ," ", | 
| "\$1"\$1"" | "NULL" | , " " , | ," ", | 

### ヘッダーのない CSV ファイル
<a name="csv-file-no-headers"></a>

ソースの .csv ファイルでは、各列に一意の名前を付けるヘッダーが最初の行になくてもかまいません。ただし、ヘッダー行のない .csv ファイルには位置暗号化スキーマが必要です。ヘッダー行のある .csv ファイルと Parquet ファイルの両方に使用される一般的なマッピングスキーマの代わりに、位置暗号化スキーマが必要になります。

位置暗号化スキーマは、出力列を名前ではなく位置で指定します。マッピング暗号化スキーマは、ソースの列名をターゲットの列名にマッピングします。両方のスキーマ形式の詳細な説明や例については、「[マッピングテーブルスキーマと位置テーブルスキーマ](create-schema.md#mapped-and-positional-schemas)」を参照してください。

## Parquet ファイル
<a name="parquet-file-type"></a>

.parquet 拡張子の付いたファイルは、Apache Parquet 形式であるとみなされます。

### サポートされている Parquet データ型
<a name="supported-parquet-data-types"></a>

C3R 暗号化クライアントでは、 AWS Clean Roomsでサポートされているデータ型を表す Parquet ファイル内の複雑でない (つまり、プリミティブ型の) データを処理できます。

ただし、sealed列には文字列の列しか使用できません。

以下の Parquet データ型 がサポートされています。
+ 以下の論理アノテーション付きの `Binary` プリミティブ型
  + `--parquetBinaryAsString` が設定されている場合は不要 (`STRING` データ型)
  + `Decimal(scale, precision)` (`DECIMAL` データ型)
  + `String` (`STRING` データ型)
+ 論理アノテーションのない `Boolean` プリミティブデータ型 (`BOOLEAN` データ型)
+ 論理アノテーションのない `Double` プリミティブデータ型 (`DOUBLE` データ型)
+ `Decimal(scale, precision)` 論理アノテーション付きの `Fixed_Len_Binary_Array` プリミティブ型 (`DECIMAL` データ型)
+ 論理アノテーションのない `Float` プリミティブデータ型 (`FLOAT` データ型)
+ 以下の論理アノテーション付きの `Int32` プリミティブ型
  + 不要 (`INT` データ型)
  + `Date` (`DATE` データ型)
  + `Decimal(scale, precision)` (`DECIMAL` データ型)
  + `Int(16, true)` (`SMALLINT` データ型)
  + `Int(32, true)` (`INT` データ型)
+ 以下の論理アノテーション付きの `Int64` プリミティブデータ型
  + 不要 (`BIGINT` データ型)
  + `Decimal(scale, precision)` (`DECIMAL` データ型)
  + `Int(64, true)` (`BIGINT` データ型)
  + `Timestamp(isUTCAdjusted, TimeUnit.MILLIS)` (`TIMESTAMP` データ型)
  + `Timestamp(isUTCAdjusted, TimeUnit.MICROS)` (`TIMESTAMP` データ型)
  + `Timestamp(isUTCAdjusted, TimeUnit.NANOS)` (`TIMESTAMP` データ型)

## 文字列以外の値の暗号化
<a name="encrypt-non-string-values"></a>

現在、sealed列では文字列値のみがサポートされています。

.csv ファイルの場合、C3R 暗号化クライアントはすべての値を UTF-8 でエンコードされたテキストとして扱い、暗号化前にそれらを異なる方法で解釈しようとはしません。

フィンガープリント列では、データ型は等価クラスにグループ化されます。等価クラスは、代表的なデータ型を使用して同等かどうかを明確に比較できるデータ型のセットです。

等価クラスを使用すると、元の表現に関係なく、同一のフィンガープリントを同じセマンティック値に割り当てることができます。ただし、2 つの等価クラスで同じ値があっても、同じフィンガープリント列にはなりません。

例えば、`42` の `INTEGRAL` 値には、元の値が `SMALLINT`、`INT`、または `BIGINT` であったかどうかにかかわらず、同じフィンガープリントが割り当てられます。また、`0` の `INTEGRAL` 値が `FALSE` の `BOOLEAN` 値 (値 `0` で表される) と一致することはありません。

フィンガープリント列では、次の等価クラスと対応する AWS Clean Rooms データ型がサポートされています。


| 等価クラス | サポートされている AWS Clean Rooms データ型 | 
| --- | --- | 
| BOOLEAN | BOOLEAN | 
| DATE | DATE | 
| INTEGRAL | BIGINT, INT, SMALLINT | 
|  STRING | CHAR, STRING, VARCHAR | 

# Cryptographic Computing for Clean Rooms での列名
<a name="crypto-computing-column-names"></a>

デフォルトでは、Cryptographic Computing for Clean Rooms においては列の名前が重要になります。

**[名前の異なる列の JOIN を許可]** パラメータの値が **[false]** の場合は、fingerprint列の暗号化時に列名が使用されます。このためデフォルトでは、コラボレーターが事前に調整して、クエリで JOIN ステートメントを使用するデータで同じターゲット列名を使用する必要があります。デフォルトでは、JOIN のために暗号化された名前の異なる列は、どの値でも JOIN が正常に処理されません。

**[名前の異なる列の JOIN を許可]** パラメータの値が **[true]** の場合、fingerprint列として暗号化された複数の列にわたる JOIN ステートメントは成功します。このパラメータを使用してデータを暗号化すると、cleartext値をある程度推測できる可能性があります。例えば、ある行の `City` 列と `State` 列の両方に同じ Hash-based Message Authentication Code (HMAC) 値がある場合、その値は `New York` である可能性があります。

## 列ヘッダー名の正規化
<a name="column-header-names-normalization"></a>

列ヘッダー名は C3R 暗号化クライアントによって正規化されます。変換後の出力では、先頭と末尾のスペースはすべて削除され、列名は小文字になります。

正規化は、列名の影響を受ける可能性のある他のすべての計算や操作の前に適用されます。出力されるファイルには、正規化された名前のみが含まれます。

# Cryptographic Computing for Clean Rooms での列タイプ
<a name="crypto-computing-column-types"></a>

このトピックでは、Cryptographic Computing for Clean Rooms での列タイプに関する情報を提供します。

**Topics**
+ [Fingerprint列](#fingerprint-columns)
+ [シール列](#sealed-columns)
+ [Cleartext列](#cleartext-columns)

## Fingerprint列
<a name="fingerprint-columns"></a>

**Fingerprint列は、JOIN ステートメントで使用される、暗号化によって保護された列です。

fingerprint列のデータを復号化することはできません。復号化できるのは、シール列のデータだけです。

Fingerprint列は次の SQL 句と関数でのみ使用する必要があります。
+ 他のfingerprint列に対する JOIN (INNER, OUTER, LEFT, RIGHT, or FULL) 
  + `allowJoinsOnColumnsWithDifferentNames` パラメータの値が `false` に設定されている場合、JOIN の両方のfingerprint列が同じ名前であることも必要になります。
+ `SELECT COUNT()`
+ `SELECT COUNT(DISTINCT )`
+ `GROUP BY` (コラボレーションで `preserveNulls` パラメータの値が `true` に設定されている場合にのみ使用)

これらの制約に違反するクエリは、誤った結果をもたらす可能性があります。

## シール列
<a name="sealed-columns"></a>

**シール列は、SELECT ステートメントで使用される、暗号化によって保護された列です。

シール列は、次の SQL 句と関数でのみ使用する必要があります。
+ `SELECT`
+ `SELECT ... AS`
+ `SELECT COUNT()`
**注記**  
`SELECT COUNT(DISTINCT )` はサポートされていません。

これらの制約に違反するクエリは、誤った結果をもたらす可能性があります。

### 暗号化前のsealed列のデータのパディング
<a name="padding-data"></a>

列をsealed列にするように指定すると、C3R からどの種類の**パディングを選択するかをたずねられます。暗号化前のデータのパディングは任意です。パディングを使用しない場合 (パディングタイプ `none`) は、暗号化されたデータの長さがcleartextのサイズを示します。状況によっては、cleartextのサイズによってプレーンテキストが明らかになる場合もあります。パディングを使用する場合 (パディングタイプ `fixed` または`max`) は、まずすべての値が共通のサイズにパディングされ、次に暗号化されます。パディングを使用すると、暗号化されたデータの長さによって、サイズの上限は示されるものの、元のcleartextの長さに関するそれ以外の情報は得られません。

特定の列のパディングが必要で、その列のデータの最大バイト長がわかっている場合は、`fixed` パディングを使用し、少なくともその列の最大バイト長と同じ大きさの `length` 値を使用してください。

**注記**  
値が指定した `length` 値より長いとエラーが発生し、暗号化は失敗します。

列のパディングが必要で、その列のデータの最大バイト長がわかっていない場合は、`max` パディングを使用します。このパディングモードは、すべてのデータを、最長値に追加の `length` バイトを加えた長さにパディングします。

**注記**  
データをまとめて暗号化したり、テーブルを新しいデータで定期的に更新したりする場合、`max` パディングを行うと、指定したバッチ内の最も長いプレーンテキストエントリの長さ (プラス `length` バイト) までエントリがパディングされることに注意してください。つまり、暗号文の長さはバッチごとに異なる可能性があります。したがって、列の最大バイト長がわかっている場合は、`max` の代わりに `fixed` 使用してください。

## Cleartext列
<a name="cleartext-columns"></a>

*Cleartext 列*は、JOIN または SELECT ステートメントで使用される、暗号によって保護されていない列です。

Cleartext列は SQL クエリのどの部分でも使用できます。

# 暗号コンピューティングパラメータ
<a name="crypto-computing-parameters"></a>

暗号コンピューティングパラメータは、[コラボレーションの作成](create-collaboration.md)時に、Cryptographic Computing for Clean Rooms (C3R) を使用してコラボレーションに指定できます。 AWS Clean Rooms コンソールまたは `CreateCollaboration` API オペレーションを使用してコラボレーションを作成できます。コンソールでは、**\$1暗号コンピューティングをサポート\$1** オプションをオンにすると、**[暗号コンピューティングパラメータ]** のパラメータ値を設定できます。詳細については、以下のトピックを参照してください。

**Topics**
+ [[cleartext 列を許可] パラメータ](#parameter-allowcleartext)
+ [[複製を許可] パラメータ](#parameter-allowduplicates)
+ [[名前の異なる列の JOIN を許可] パラメータ](#parameter-allowjoin)
+ [[NULL 値を保存] パラメータ](#parameter-preservenulls)

## [cleartext 列を許可] パラメータ
<a name="parameter-allowcleartext"></a>

コンソールでは、[コラボレーションの作成](create-collaboration.md)時に **[cleartext 列を許可]** パラメータを設定して、暗号化されたデータを含むテーブルで cleartext データを許可するかどうかを指定できます。

次の表で、**[cleartext 列を許可]** パラメータの値について説明します。


| パラメータ値 | 説明 | 
| --- | --- | 
| いいえ |  暗号化されたテーブルでCleartext 列を使用できません。すべてのデータは暗号で保護されます。  | 
| あり |  暗号化されたテーブルでCleartext 列を使用できます。 Cleartext 列は暗号化によって保護されず、cleartext として含まれます。行の cleartext データによって、テーブル内の他のデータについて明らかになるおそれがある情報をメモしておく必要があります。 特定の列で SUM または AVG を実行するには、その列が cleartext である必要があります。  | 

`CreateCollaboration` API オペレーションを使用して、`dataEncryptionMetadata` パラメータの `allowCleartext` 値を `true` または `false` に設定できます。API オペレーションの詳細については、「[AWS Clean Rooms API リファレンス](https://docs.aws.amazon.com/clean-rooms/latest/apireference/Welcome.html)」を参照してください。

Cleartext 列は、テーブル固有のスキーマで cleartext に分類される列に対応します。これらの列のデータは暗号化されておらず、どのような方法でも使用できます。Cleartext 列は、データの機密性が低い場合や、暗号化された sealed 列や fingerprint 列で許容される以上の柔軟性が必要な場合に役立ちます。

## [複製を許可] パラメータ
<a name="parameter-allowduplicates"></a>

コンソールでは、[コラボレーションの作成](create-collaboration.md)時に **[複製を許可]** パラメータを設定して、暗号化された列の JOIN クエリで NULL 値以外の重複する値を含めるかどうかを指定できます。

**重要**  
**[複製を許可]**、**[[名前の異なる列の JOIN を許可](#parameter-allowjoin)]**、**[[NULL 値を保存](#parameter-preservenulls)]** の各パラメータには、別々でありながら関連する効果があります。

次の表で、**[複製を許可]** パラメータの値について説明します。


| パラメータ値 | 説明 | 
| --- | --- | 
| いいえ  |  1 つの fingerprint 列で値の繰り返しは許可されません。1 つの fingerprint 列の値は、すべて一意でなければなりません。  | 
| あり |  1 つの fingerprint 列で値の繰り返しが許可されます。 値が繰り返される列を結合する必要がある場合は、この値を **[はい]** に設定します。**[はい]** に設定すると、C3R テーブルまたは結果の fingerprint 列に示される頻度パターンによって、cleartext データの構造に関するその他の情報が推察可能になるおそれがあります。  | 

`CreateCollaboration` API オペレーションを使用して、`dataEncryptionMetadata` パラメータの `allowDuplicates` 値を `true` または `false` に設定できます。API オペレーションの詳細については、「[AWS Clean Rooms API リファレンス](https://docs.aws.amazon.com/clean-rooms/latest/apireference/Welcome.html)」を参照してください。

デフォルトでは、暗号化されたデータを JOIN クエリで使用する必要がある場合、C3R 暗号化クライアントでは、それらの列に重複する値がないことが求められます。この要件は、データ保護を強化するためのものです。この動作によって、データ内で繰り返されるパターンが観測可能になることを防止できます。ただし、JOIN クエリで暗号化されたデータを処理するにあたって、値の重複を気にしない場合は、**[複製を許可]** パラメータでこの保守的なチェックを無効にできます。

## [名前の異なる列の JOIN を許可] パラメータ
<a name="parameter-allowjoin"></a>

コンソールでは、[コラボレーションの作成](create-collaboration.md)時に **[名前の異なる列の JOIN を許可]** パラメータを設定して、異なる名前の列間の JOIN ステートメントをサポートするかどうかを指定できます。

詳細については、[列ヘッダー名の正規化](crypto-computing-column-names.md#column-header-names-normalization)を参照してください。

次の表で、**[名前の異なる列の JOIN を許可]** パラメータの値について説明します。


| パラメータ値 | 説明 | 
| --- | --- | 
| いいえ  |  名前の異なる fingerprint 列の結合はサポートされません。JOIN ステートメントでは、同じ名前の列でのみ正確な結果が得られます。  **[いいえ]** を指定すると情報セキュリティは強化されますが、列名について事前にコラボレーション参加者の合意が必要になります。fingerprint列として暗号化したときに 2 つの列の名前が異なり、**[名前の異なる列の JOIN を許可]** が **[いいえ]** に設定されていると、それらの列の JOIN ステートメントは結果を生成しません。これは、暗号化後の値が 2 つの列の間で共有されないためです。   | 
| あり |  名前の異なるfingerprint列の結合がサポートされます。柔軟性を高めるために、ユーザーはこの値を **[はい]** に設定できます。これにより、名前に関係なく列に対して JOIN ステートメントを実行できます。 **[はい]** に設定すると、C3R 暗号化クライアントは fingerprint 列を保護する際に列名を考慮しません。その結果、C3R テーブルの異なる fingerprint 列で共通する値が観測可能になります。 例えば、ある行の `City` 列と `State` 列の両方に暗号化された同一の JOIN 値が存在する場合、その値は `New York` であると合理的に推測できます。  | 

`CreateCollaboration` API オペレーションを使用して、`dataEncryptionMetadata` パラメータの `allowJoinsOnColumnsWithDifferentNames` 値を `true` または `false` に設定できます。API オペレーションの詳細については、「[AWS Clean Rooms API リファレンス](https://docs.aws.amazon.com/clean-rooms/latest/apireference/Welcome.html)」を参照してください。

デフォルトでは、fingerprint 列の暗号化は、「[ステップ 4: 表形式ファイルの暗号化スキーマを生成する](gen-encryption-schema-csv.md)」で設定されたその列の `targetHeader` 設定の影響を受けます。そのため、同じ cleartext 値でも、暗号化対象の fingerprint 列ごとに暗号化表現は異なります。

このパラメータは、cleartext 値が推測されるのを防ぐのに役立つ場合があります。例えば、fingerprint 列 `City` と `State` に暗号化された同一の値が表示されている場合、その値は `New York` であると合理的に推測できます。ただし、このパラメータを使用するには、クエリで結合されるすべての列が共通の名前になるように、事前に追加の調整が必要になります。

**[名前の異なる列の JOIN を許可]** パラメータを使用すると、この制限を緩和できます。パラメータ値を `Yes` に設定すると、名前に関係なく、暗号化されたすべての列を JOIN で一緒に使用できます。

## [NULL 値を保存] パラメータ
<a name="parameter-preservenulls"></a>

コンソールでは、[コラボレーションの作成](create-collaboration.md)時に **[NULL 値を保存]** パラメータを設定して、その列に値がないことを示すことができます。

次の表で、**[NULL 値を保存]** パラメータの値について説明します。


| パラメータ値 | 説明 | 
| --- | --- | 
| いいえ |  NULL 値は保持されません。NULL 値は暗号化されたテーブルで NULL として表示されません。NULL 値は C3R テーブルに一意のランダム値として表示されます。  | 
| あり | NULL値は保持されます。NULL 値は暗号化されたテーブルで NULL として表示されます。NULL 値の SQL セマンティックが必要な場合は、この値を [はい] に設定できます。その結果、列が暗号化されているかどうか、および [複製を許可] パラメータの設定に関係なく、NULL エントリは C3R テーブルで NULL として表示されます。 | 

`CreateCollaboration` API オペレーションを使用して、`dataEncryptionMetadata` パラメータの `preserveNulls` 値を `true` または `false` に設定できます。API オペレーションの詳細については、「[AWS Clean Rooms API リファレンス](https://docs.aws.amazon.com/clean-rooms/latest/apireference/Welcome.html)」を参照してください。

コラボレーションの **[NULL 値を保存]** パラメータが **[いいえ]** に設定されている場合の動作は以下の通りです。

1. `cleartext` 列の NULL エントリは変更されません。

1. 暗号化された`fingerprint` 列の NULL エントリは、内容を隠すためにランダムな値として暗号化されます。暗号化された列をそのcleartext列の NULL エントリと結合しても、どの NULL エントリとも一致しません。それぞれが一意のランダムコンテンツを受け取るため、一致は生じません。

1. 暗号化された`sealed` 列の NULL エントリは暗号化されます。

コラボレーションの **[NULL 値を保存]** パラメータ値が **[はい]** に設定されている場合、列が暗号化されているかどうかに関係なく、すべての列の NULL エントリは NULL のままとなります。

**[NULL 値を保存]** パラメータは、データエンリッチメントなどのシナリオにおいて、情報が欠落し、NULL で表されているエントリを共有する場合に便利です。また、**[NULL 値を保存]** パラメータは、JOIN または GROUP BY を実行する列に NULL がある場合に、fingerprint または HMAC 形式でも役立ちます。

**[複製を許可]** パラメータと **[NULL 値を保存]** パラメータの値が **[いいえ]** に設定されている場合、1 つのfingerprint 列に複数の NULL エントリがあると、エラーが発生して暗号化が停止します。いずれかのパラメータ値が **[はい]** に設定されていれば、そのようなエラーは発生しません。

# Cryptographic Computing for Clean Rooms のオプションフラグ
<a name="crypto-computing-optional-flags"></a>

以下のセクションでは、表形式のファイルのカスタマイズとテストにおいて、C3R 暗号化クライアントを使って[データを暗号化](encrypt-data.md)するときに設定できるオプションフラグについて説明します。

**Topics**
+ [`--csvInputNULLValue` フラグ](#optional-flags-CSVinputNullValue)
+ [`--csvOutputNULLValue` フラグ](#optional-flags-CSVoutputNullValue)
+ [`--enableStackTraces` フラグ](#optional-flags-enablestacktraces)
+ [`--dryRun` フラグ](#optional-flags-dry-run)
+ [`--tempDir` フラグ](#optional-flags-working-dir)

## `--csvInputNULLValue` フラグ
<a name="optional-flags-CSVinputNullValue"></a>

C3R 暗号化クライアントを使用して[データを暗号化](encrypt-data.md)するときに、`--csvInputNULLValue` フラグを使用して入力データの NULL エントリにカスタムエンコーディングを指定できます。

次の表は、このフラグの使用方法とパラメータをまとめたものです。


| 使用方法 | パラメータ | 
| --- | --- | 
| オプション。ユーザーは入力データの NULL エントリにカスタムエンコーディングを指定できます。 | 入力 CSV ファイルの NULL 値に対するユーザー指定のエンコーディング | 

NULL エントリとは、特に SQL テーブルのようなよりリッチな表形式のコンテキストでは、欠落したコンテンツとみなされるエントリです。.csv は歴史的な理由からこの特性を明示的にサポートしていませんが、空白だけを含む空のエントリは NULL と見なすのが一般的な慣習です。したがって、これは C3R 暗号化クライアントのデフォルト動作であり、必要に応じてカスタマイズできます。

## `--csvOutputNULLValue` フラグ
<a name="optional-flags-CSVoutputNullValue"></a>

C3R 暗号化クライアントを使用して[データを暗号化](encrypt-data.md)するときに、`--csvOutputNULLValue` フラグを使用して出力データの NULL エントリにカスタムエンコーディングを指定できます。

次の表は、このフラグの使用方法とパラメータをまとめたものです。


| 使用方法 | パラメータ | 
| --- | --- | 
| オプション。ユーザーは、NULL エントリの生成された出力ファイルにカスタムエンコーディングを指定できます。 | 出力 CSV ファイルの NULL 値に対するユーザー指定のエンコーディング | 

NULL エントリとは、特に SQL テーブルのようなよりリッチな表形式のコンテキストでは、欠落したコンテンツとみなされるエントリです。.csv は歴史的な理由からこの特性を明示的にサポートしていませんが、空白だけを含む空のエントリは NULL と見なすのが一般的な慣習です。したがって、これは C3R 暗号化クライアントのデフォルト動作であり、必要に応じてカスタマイズできます。

## `--enableStackTraces` フラグ
<a name="optional-flags-enablestacktraces"></a>

C3R 暗号化クライアントを使用して[データを暗号化](encrypt-data.md)するときに `--enableStackTraces` フラグを使用すると、C3R でエラーが発生したときに、エラー報告用の追加のコンテキスト情報が提供されます。

AWS はエラーを収集しません。エラーが発生した場合は、スタックトレースを使用してエラーを自分でトラブルシューティングするか、スタックトレースを に送信してサポート サポート を依頼してください。

次の表は、このフラグの使用方法とパラメータをまとめたものです。


| 使用方法 | パラメータ | 
| --- | --- | 
| オプション。C3R 暗号化クライアントでエラーが発生したときに、エラー報告用の追加のコンテキスト情報を提供するために使用します。 | なし | 

## `--dryRun` フラグ
<a name="optional-flags-dry-run"></a>

C3R 暗号化クライアントの[暗号化](encrypt-data.md)コマンドと[復号化](decrypt-data.md)コマンドにはオプションの `--dryRun` フラグがあります。このフラグは、ユーザーが指定した引数をすべて受け取り、その有効性と一貫性をチェックします。

この `--dryRun` フラグを使用して、スキーマファイルが有効で対応する入力ファイルと一致しているかどうかを確認できます。

次の表は、このフラグの使用方法とパラメータをまとめたものです。


| 使用方法 | パラメータ | 
| --- | --- | 
| オプション。C3R 暗号化クライアントはパラメータの解析とファイルのチェックを行いますが、暗号化や復号化は行いません。 | なし | 

## `--tempDir` フラグ
<a name="optional-flags-working-dir"></a>

設定によっては、暗号化されたファイルは暗号化されていないファイルよりもサイズが大きくなることがあるため、一時ディレクトリを使用することができます。また、データセットを正常に機能させるには、コラボレーションごとに暗号化する必要があります。

C3R を使用して[データを暗号化](encrypt-data.md)する場合は、`--tempDir` フラグを使用して、入力の処理中に一時ファイルを作成する場所を指定できます。

次の表は、このフラグの使用方法とパラメータをまとめたものです。


| 使用方法 | パラメータ | 
| --- | --- | 
| ユーザーは、入力の処理中に一時ファイルを作成する場所を指定できます。 | デフォルトはシステム一時ディレクトリです。 | 

# クエリと Cryptographic Computing for Clean Rooms
<a name="crypto-computing-queries"></a>

このトピックでは、Cryptographic Computing for Clean Rooms で暗号化されたデータテーブルを使用するクエリの作成について情報を提供します。

**Topics**
+ [NULL で分岐するクエリ](#queries-branch-on-null)
+ [1 つのソース列を複数のターゲット列にマッピングする](#queries-mapping)
+ [JOIN クエリと SELECT クエリの両方に同じデータを使用する](#queries-using-same-data)

## NULL で分岐するクエリ
<a name="queries-branch-on-null"></a>

NULL ステートメントでクエリを分岐するということは、`IF x IS NULL THEN 0 ELSE 1` のような構文を使用することを意味します。

cleartext列では、NULL ステートメントで常にクエリを分岐させることができます。

sealed列やfingerprint列の場合は、**[NULL 値を保存]** パラメータ (`preserveNulls`) の値が `true` に設定されている場合のみ、NULL ステートメントでクエリを分岐させることができます。

これらの制約に違反するクエリは、誤った結果をもたらす可能性があります。

## 1 つのソース列を複数のターゲット列にマッピングする
<a name="queries-mapping"></a>

1 つのソース列を複数のターゲット列にマッピングできます。例えば、1 つの列で JOIN と SELECT の両方を実行することができます。

詳細については、「[JOIN クエリと SELECT クエリの両方に同じデータを使用する](#queries-using-same-data)」を参照してください。

## JOIN クエリと SELECT クエリの両方に同じデータを使用する
<a name="queries-using-same-data"></a>

列内のデータが機密情報ではない場合、そのデータはcleartextのターゲット列に表示され、あらゆる目的に使用できます。

列内のデータが機密情報で、JOIN クエリと SELECT クエリの両方に使用する必要がある場合は、そのソース列を出力ファイルの 2 つのターゲット列にマッピングします。1 つの列は `type` をfingerprint列として暗号化し、もう 1 つの列は `type` をシール列として暗号化します。C3R 暗号化クライアントのインタラクティブなスキーマ生成では、ヘッダーサフィックスとして `_fingerprint` と `_sealed` が提示されます。これらのヘッダーサフィックスは、このような列をすばやく区別するのに便利な規則です。

# C3R 暗号化クライアントのガイドライン
<a name="crypto-computing-guidelines"></a>

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

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

**Topics**
+ [列タイプがパフォーマンスに与える影響](#performance-implications)
+ [暗号文のサイズが予期せず大きくなった場合のトラブルシューティング](#troubleshooting-ciphertext-size)

## 列タイプがパフォーマンスに与える影響
<a name="performance-implications"></a>

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

**Topics**
+ [Cleartext列](#cleartext-columns)
+ [Fingerprint列](#guidelines-fingerprint-columns)
+ [Sealed列](#guidelines-sealed-columns)

### Cleartext列
<a name="cleartext-columns"></a>

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

### Fingerprint列
<a name="guidelines-fingerprint-columns"></a>

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

**Topics**
+ [fingerprint列の基本オーバーヘッド](#fingerprint-columns-base-overhead)
+ [fingerprint列のコラボレーション設定](#fingerprint-columns-collab-settings)
+ [fingerprint列のデータ例](#collab-set-sample-data)
+ [fingerprint列のトラブルシューティング](#fingerprint-columns-troubleshooting)

#### fingerprint列の基本オーバーヘッド
<a name="fingerprint-columns-base-overhead"></a>

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 バイトの基本オーバーヘッド。\]](http://docs.aws.amazon.com/ja_jp/clean-rooms/latest/userguide/images/base-overhead-fingerprint.PNG)


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

#### fingerprint列のコラボレーション設定
<a name="fingerprint-columns-collab-settings"></a>

##### `preserveNulls` の設定
<a name="collab-set-preserve-nulls"></a>

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

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

#### fingerprint列のデータ例
<a name="collab-set-sample-data"></a>

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

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

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

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


**例 1**  

|  |  | 
| --- |--- |
| Input | null | 
| preserveNulls | TRUE | 
| Output | null | 
| 確定的 | Yes | 
| 入力バイト数 | 0 | 
| 出力バイト数 | 0 | 


**例 2**  

|  |  | 
| --- |--- |
| Input | null | 
| preserveNulls | FALSE | 
| Output | 01:hmac:3lkFjthvV3IUu6mMvFc1a\$1XAHwgw/ElmOq4p3Yg25kk= | 
| 確定的 | No | 
| 入力バイト数 | 0 | 
| 出力バイト数 | 52 | 


**例 3**  

|  |  | 
| --- |--- |
| Input | empty string | 
| preserveNulls | - | 
| Output | 01:hmac:oKTgi3Gba\$1eUb3JteSz2EMgXUkF1WgM77UP0Ydw5kPQ= | 
| 確定的 | Yes | 
| 入力バイト数 | 0 | 
| 出力バイト数 | 52 | 


**例 4**  

|  |  | 
| --- |--- |
| Input | abcdefghijklmnopqrstuvwxyz | 
| preserveNulls | - | 
| Output | 01:hmac:kU/IqwG7FMmzzshr0B9scomE0UJUEE7j9keTctplGww= | 
| 確定的 | Yes | 
| 入力バイト数 | 26 | 
| 出力バイト数 | 52 | 


**例 5**  

|  |  | 
| --- |--- |
| Input | abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 | 
| preserveNulls | - | 
| Output | 01:hmac:ks3htnQbw2vdhCRFF6JNzW5LMndJaHG57uvE26mBtSs= | 
| 確定的 | Yes | 
| 入力バイト数 | 62 | 
| 出力バイト数 | 52 | 

#### fingerprint列のトラブルシューティング
<a name="fingerprint-columns-troubleshooting"></a>

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

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

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

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

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

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

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

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

### Sealed列
<a name="guidelines-sealed-columns"></a>

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

**Topics**
+ [sealed列の基本オーバーヘッド](#sealed-columns-base-overhead)
+ [sealed列のコラボレーション設定](#sealed-columns-collab-settings)
+ [スキーマ設定sealed列: パディングタイプ](#sealed-collab-pad-type)
+ [sealed列のデータ例](#sealed-collab-sample-data)
+ [sealed列のトラブルシューティング](#troubleshooting-sealed-columns)

#### sealed列の基本オーバーヘッド
<a name="sealed-columns-base-overhead"></a>

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列の 91 バイトの基本オーバーヘッド。\]](http://docs.aws.amazon.com/ja_jp/clean-rooms/latest/userguide/images/base-overhead-sealed.PNG)


#### sealed列のコラボレーション設定
<a name="sealed-columns-collab-settings"></a>

##### `preserveNulls` の設定
<a name="sealed-collab-set-preserve-nulls"></a>

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

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

#### スキーマ設定sealed列: パディングタイプ
<a name="sealed-collab-pad-type"></a>

**Topics**
+ [パディングタイプ `none`](#pad-type-none)
+ [パディングタイプ `fixed`](#pad-type-fixed)
+ [パディングタイプ `max`](#pad-type-max)

##### パディングタイプ `none`
<a name="pad-type-none"></a>

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

##### パディングタイプ `fixed`
<a name="pad-type-fixed"></a>

`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`
<a name="pad-type-max"></a>

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

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

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

#### sealed列のデータ例
<a name="sealed-collab-sample-data"></a>

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

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

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

**Topics**
+ [パディングタイプ `none`](#sealed-pad-type-none)
+ [パディングタイプ `fixed` (例 1)](#sealed-pad-type-fixed)
+ [パディングタイプ `fixed` (例 2)](#sealed-pad-type-fixed-2)
+ [パディングタイプ `max` (例 1)](#sealed-pad-type-max)
+ [パディングタイプ `max` (例 2)](#sealed-pad-type-max-2)

##### パディングタイプ `none`
<a name="sealed-pad-type-none"></a>


**例 1**  

|  |  | 
| --- |--- |
| Input | null | 
| preserveNulls | TRUE | 
| Output | null | 
| 確定的 | Yes | 
| 入力バイト数 | 0 | 
| 出力バイト数 | 0 | 


**例 2**  

|  |  | 
| --- |--- |
| Input | null | 
| preserveNulls | FALSE | 
| Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfssGSPbNIJfG3iXmu6cbCUrizuV | 
| 確定的 | No | 
| 入力バイト数 | 0 | 
| 出力バイト数 | 91 | 


**例 3**  

|  |  | 
| --- |--- |
| Input | empty string | 
| preserveNulls | - | 
| Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfstGSPEM6qR8DWC2PB2GMlX41YK | 
| 確定的 | No | 
| 入力バイト数 | 0 | 
| 出力バイト数 | 91 | 


**例 4**  

|  |  | 
| --- |--- |
| Input | abcdefghijklmnopqrstuvwxyz | 
| preserveNulls | - | 
| Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6pkx9sGL5VLDQeHzh6DmPpyWNuI= | 
| 確定的 | No | 
| 入力バイト数 | 26 | 
| 出力バイト数 | 127 | 


**例 5**  

|  |  | 
| --- |--- |
| Input | abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 | 
| preserveNulls | - | 
| Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6plwtH/8tRFnn2rF91bcB9G4\$1n8GiRfJNmqdP4/QOQ3cXb/pbvPcnnohrHIGSX54ua\$11/JfcVjc= | 
| 確定的 | No | 
| 入力バイト数 | 62 | 
| 出力バイト数 | 175 | 

##### パディングタイプ `fixed` (例 1)
<a name="sealed-pad-type-fixed"></a>

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


**例 1**  

|  |  | 
| --- |--- |
| Input | null | 
| preserveNulls | TRUE | 
| Output | null | 
| 確定的 | Yes | 
| 入力バイト数 | 0 | 
| 出力バイト数 | 0 | 


**例 2**  

|  |  | 
| --- |--- |
| Input | null | 
| preserveNulls | FALSE | 
| Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfssGSNWfMRp7nSb7SMX2s3JKLOhK1\$17r75Tk\$1Mx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcoNpATs0GzbnLkor4L\$1/aSuA= | 
| 確定的 | No | 
| 入力バイト数 | 0 | 
| 出力バイト数 | 175 | 


**例 3**  

|  |  | 
| --- |--- |
| Input | empty string | 
| preserveNulls | - | 
| Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfstGSNWfMRp7nSb7SMX2s3JKLOhK1\$17r75Tk\$1Mx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcoLB53l07VZpA6OwkuXu29CA= | 
| 確定的 | No | 
| 入力バイト数 | 0 | 
| 出力バイト数 | 175 | 


**例 4**  

|  |  | 
| --- |--- |
| Input | abcdefghijklmnopqrstuvwxyz | 
| preserveNulls | - | 
| Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6pkx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcutBAcO\$1Mb9tuU2KIHH31AWg= | 
| 確定的 | No | 
| 入力バイト数 | 26 | 
| 出力バイト数 | 175 | 


**例 5**  

|  |  | 
| --- |--- |
| Input | abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 | 
| preserveNulls | - | 
| Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6plwtH/8tRFnn2rF91bcB9G4\$1n8GiRfJNmqdP4/QOQ3cXb/pbvPcnnohrHIGSX54ua\$11/JfcVjc= | 
| 確定的 | No | 
| 入力バイト数 | 62 | 
| 出力バイト数 | 175 | 

##### パディングタイプ `fixed` (例 2)
<a name="sealed-pad-type-fixed-2"></a>

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


**例 1**  

|  |  | 
| --- |--- |
| Input | null | 
| preserveNulls | TRUE | 
| Output | null | 
| 確定的 | Yes | 
| 入力バイト数 | 0 | 
| 出力バイト数 | 0 | 


**例 2**  

|  |  | 
| --- |--- |
| Input | null | 
| preserveNulls | FALSE | 
| Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfssGSNWfMRp7nSb7SMX2s3JKLOhK1\$17r75Tk\$1Mx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcnkB0xbLWD7zNdAqQGR0rXoSESdW0I0vpNoGcBfv4cJbG0A3h1DvtkSSVc2B80OOGppzdDqhrUVN5wFNyn8vgfPMqDaeJk5bn\$18o4WtG/ClipNcjDXvXVtK4vfCohcCA6uwrmwv/xAySX\$1xcntotL703aBTBb | 
| 確定的 | No | 
| 入力バイト数 | 0 | 
| 出力バイト数 | 307 | 


**例 3**  

|  |  | 
| --- |--- |
| Input | empty string | 
| preserveNulls | - | 
| Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfstGSNWfMRp7nSb7SMX2s3JKLOhK1\$17r75Tk\$1Mx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcnkB0xbLWD7zNdAqQGR0rXoSESdW0I0vpNoGcBfv4cJbG0A3h1DvtkSSVc2B80OOGppzdDqhrUVN5wFNyn8vgfPMqDaeJk5bn\$18o4WtG/ClipNcjDXvXVtK4vfCohcCA6uwrmwv84lVaT9Yd\$16oQx65/\$1gdVT | 
| 確定的 | No | 
| 入力バイト数 | 0 | 
| 出力バイト数 | 307 | 


**例 4**  

|  |  | 
| --- |--- |
| Input | abcdefghijklmnopqrstuvwxyz | 
| preserveNulls | - | 
| Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6pkx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcnkB0xbLWD7zNdAqQGR0rXoSESdW0I0vpNoGcBfv4cJbG0A3h1DvtkSSVc2B80OOGppzdDqhrUVN5wFNyn8vgfPMqDaeJk5bn\$18o4WtG/ClipNcjDXvXVtK4vfCohcCA6uwrmwtX5Hnl\$1WyfO6ks3QMaRDGSf | 
| 確定的 | No | 
| 入力バイト数 | 26 | 
| 出力バイト数 | 307 | 


**例 5**  

|  |  | 
| --- |--- |
| Input | abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 | 
| preserveNulls | - | 
| Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6plwtH/8tRFnn2rF91bcB9G4\$1n8GiRfJNmqdP4/QOQ3cXb/pbvPcnkB0xbLWD7zNdAqQGR0rXoSESdW0I0vpNoGcBfv4cJbG0A3h1DvtkSSVc2B80OOGppzdDqhrUVN5wFNyn8vgfPMqDaeJk5bn\$18o4WtG/ClipNcjDXvXVtK4vfCohcCA6uwrmwjkJXQZOgPdeFX9Yr/8alV5i | 
| 確定的 | No | 
| 入力バイト数 | 62 | 
| 出力バイト数 | 307 | 

##### パディングタイプ `max` (例 1)
<a name="sealed-pad-type-max"></a>

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


**例 1**  

|  |  | 
| --- |--- |
| Input | null | 
| preserveNulls | TRUE | 
| Output | null | 
| 確定的 | Yes | 
| 入力バイト数 | 0 | 
| 出力バイト数 | 0 | 


**例 2**  

|  |  | 
| --- |--- |
| Input | null | 
| preserveNulls | FALSE | 
| Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfssGSNWfMRp7nSb7SMX2s3JKLOhK1\$17r75Tk\$1Mx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcoNpATs0GzbnLkor4L\$1/aSuA= | 
| 確定的 | No | 
| 入力バイト数 | 0 | 
| 出力バイト数 | 175 | 


**例 3**  

|  |  | 
| --- |--- |
| Input | empty string | 
| preserveNulls | - | 
| Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfstGSNWfMRp7nSb7SMX2s3JKLOhK1\$17r75Tk\$1Mx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcoLB53l07VZpA6OwkuXu29CA= | 
| 確定的 | No | 
| 入力バイト数 | 0 | 
| 出力バイト数 | 175 | 


**例 4**  

|  |  | 
| --- |--- |
| Input | abcdefghijklmnopqrstuvwxyz | 
| preserveNulls | - | 
| Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6pkx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcutBAcO\$1Mb9tuU2KIHH31AWg= | 
| 確定的 | No | 
| 入力バイト数 | 26 | 
| 出力バイト数 | 175 | 


**例 5**  

|  |  | 
| --- |--- |
| Input | abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 | 
| preserveNulls | - | 
| Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6plwtH/8tRFnn2rF91bcB9G4\$1n8GiRfJNmqdP4/QOQ3cXb/pbvPcnnohrHIGSX54ua\$11/JfcVjc= | 
| 確定的 | No | 
| 入力バイト数 | 62 | 
| 出力バイト数 | 175 | 

##### パディングタイプ `max` (例 2)
<a name="sealed-pad-type-max-2"></a>

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


**例 1**  

|  |  | 
| --- |--- |
| Input | null | 
| preserveNulls | TRUE | 
| Output | null | 
| 確定的 | Yes | 
| 入力バイト数 | 0 | 
| 出力バイト数 | 0 | 


**例 2**  

|  |  | 
| --- |--- |
| Input | null | 
| preserveNulls | FALSE | 
| Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfssGSNWfMRp7nSb7SMX2s3JKLOhK1\$17r75Tk\$1Mx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcnkB0xbLWD7zNdAqQGR0rXoSESdW0I0vpNoGcBfv4cJbG0A3h1DvtkSSVc2B80OOGppzdDqhrUVN5wFNyn8vgfPMqDaeJk5bn\$18o4WtG/ClipNcjDXvXVtK4vfCohcCA6uwrmwv/xAySX\$1xcntotL703aBTBb | 
| 確定的 | No | 
| 入力バイト数 | 0 | 
| 出力バイト数 | 307 | 


**例 3**  

|  |  | 
| --- |--- |
| Input | empty string | 
| preserveNulls | - | 
| Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfstGSNWfMRp7nSb7SMX2s3JKLOhK1\$17r75Tk\$1Mx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcnkB0xbLWD7zNdAqQGR0rXoSESdW0I0vpNoGcBfv4cJbG0A3h1DvtkSSVc2B80OOGppzdDqhrUVN5wFNyn8vgfPMqDaeJk5bn\$18o4WtG/ClipNcjDXvXVtK4vfCohcCA6uwrmwv84lVaT9Yd\$16oQx65/\$1gdVT | 
| 確定的 | No | 
| 入力バイト数 | 0 | 
| 出力バイト数 | 307 | 


**例 4**  

|  |  | 
| --- |--- |
| Input | abcdefghijklmnopqrstuvwxyz | 
| preserveNulls | - | 
| Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6pkx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcnkB0xbLWD7zNdAqQGR0rXoSESdW0I0vpNoGcBfv4cJbG0A3h1DvtkSSVc2B80OOGppzdDqhrUVN5wFNyn8vgfPMqDaeJk5bn\$18o4WtG/ClipNcjDXvXVtK4vfCohcCA6uwrmwtX5Hnl\$1WyfO6ks3QMaRDGSf | 
| 確定的 | No | 
| 入力バイト数 | 26 | 
| 出力バイト数 | 307 | 


**例 5**  

|  |  | 
| --- |--- |
| Input | abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 | 
| preserveNulls | - | 
| Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6plwtH/8tRFnn2rF91bcB9G4\$1n8GiRfJNmqdP4/QOQ3cXb/pbvPcnkB0xbLWD7zNdAqQGR0rXoSESdW0I0vpNoGcBfv4cJbG0A3h1DvtkSSVc2B80OOGppzdDqhrUVN5wFNyn8vgfPMqDaeJk5bn\$18o4WtG/ClipNcjDXvXVtK4vfCohcCA6uwrmwjkJXQZOgPdeFX9Yr/8alV5i | 
| 確定的 | No | 
| 入力バイト数 | 62 | 
| 出力バイト数 | 307 | 

#### sealed列のトラブルシューティング
<a name="troubleshooting-sealed-columns"></a>

**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](crypto-computing.md)」で確認する必要があります。ただし、組織のデータ処理要件と、それぞれのコラボレーションに適用される契約を参照することをお勧めします。

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

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

## 暗号文のサイズが予期せず大きくなった場合のトラブルシューティング
<a name="troubleshooting-ciphertext-size"></a>

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

### サイズの増加が発生した場所の特定
<a name="where-size-increase-occurred"></a>

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

### サイズが増加した理由の特定
<a name="why-size-increase-occurred"></a>

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

**Topics**
+ [fingerprint列が原因でサイズの増加が生じている場合](#size-increase-from-fingerprint)
+ [sealed 列が原因でサイズの増加が生じている場合](#size-increase-from-sealed)

#### fingerprint列が原因でサイズの増加が生じている場合
<a name="size-increase-from-fingerprint"></a>

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

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

#### sealed 列が原因でサイズの増加が生じている場合
<a name="size-increase-from-sealed"></a>

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

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

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](crypto-computing.md)」を参照してください。