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

# 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)」を参照してください。