差分プライバシーの実装¶

このトピックには、アカウントに差分プライバシーを実装するデータプロバイダー向けの情報が含まれています。

データセットに差分プライバシーを実装するとき、タスクには次の3つの重要なコンセプトが含まれます。

プライバシーポリシー。プライバシーポリシーを割り当てるまでは、テーブルやビューは差分プライバシーによって保護されません。プライバシーポリシーのあるテーブルやビューは、 プライバシー保護 されているとみなされます。
プライバシーバジェット。アナリストがプライバシー保護されたテーブルをクエリすると、当該アナリストに関連するプライバシーバジェットを管理することができます。
プライバシードメイン。プライバシー保護されたテーブルまたはビューのファクト列およびディメンション列には、プライバシードメインを定義する必要があります。

制限事項

プライバシーポリシーと集計ポリシーまたはマスキングポリシーを同じテーブルまたはビューに割り当てることはできません。
ノイズ間隔のクエリを除き、アナリストはプライバシー保護されたテーブルをクエリしているのかどうかがわからないため、データプロバイダーはクエリ結果にノイズが含まれることをアナリストに伝える必要があります。
データプロバイダーは、アナリストが別のアカウントでクエリを実行することによって発生するプライバシーロスをモニターすることはできません。
1つのテーブルに複数のプライバシーポリシーを適用することは現在サポートされていません。このため、1つのテーブルで複数のエンティティをエンティティレベルの差分プライバシーで保護することはできません。
エンティティキーにプライバシーポリシーが関連付けられている、複製されたまたはクローニングされたテーブルに対するクエリは現在ブロックされています。

エンティティレベルのプライバシーについて¶

エンティティ とは、人、組織、場所など、保護されるべきデータ主体のクラスを指します。各エンティティが1行にのみ現れる場合は、行レベルのプライバシーがあればエンティティのアイデンティティを十分保護できます。しかし、個々のエンティティに属するデータが複数の行に現れる場合（たとえば、トランザクションデータ）、各エンティティを正しく保護するために、差分プライバシーをエンティティレベルのプライバシーに構成する必要があります。

エンティティレベルのプライバシーを実現するために、Snowflakeではエンティティの識別に使用できる属性（エンティティキー）を指定できます。これにより、Snowflakeはデータセット内の特定のエンティティに属するすべての記録を識別子化することができます。たとえば、エンティティキーが列 email として定義されている場合、Snowflakeは email=joe.smith@example.com のすべての記録が同じエンティティに属していると判断できます。

ほとんどの場合、エンティティレベルのプライバシーが行レベルのプライバシーより優先されますが、以下が該当する場合は、行レベルのプライバシーがテーブルに適している可能性があります。

テーブルにエンティティを一意に識別する列がない。エンティティレベルのプライバシーに識別のための列が必要である。
各エンティティは一度しか現れない。
テーブルは結合では使用されない。行レベルのプライバシーで保護されたテーブルとの結合は可能ですが、制限があります。

テーブルやビューにプライバシーポリシーを割り当てる際に、エンティティレベルのプライバシーを実装するか、行レベルのプライバシーを実装するかを選択します。詳細については、プライバシーポリシーの割り当てをご参照ください。エンティティレベルのプライバシーを実装することを選択した場合、データは構造要件も満たし、エンティティ識別子が正しく使用されることを保証しなければなりません。

Tip

同じプライバシーポリシーで2つの別々のテーブルを保護したいが、同じエンティティキー値を持っていない場合、識別のための2つの列をマッピングする新しいテーブルを作成し、2つのテーブルを結合するビューを作成した上で、プライバシーポリシーをビューに適用することができます。たとえば、あるテーブルのエンティティキーが email で、別のテーブルのエンティティキーが user_id で、どちらも同じエンティティを参照している場合、この戦略を使用できます。

エンティティレベルのプライバシーの構造要件¶

エンティティレベルの差分プライバシーによって保護されるデータの構造は、特定の要件に適合する必要があります。Snowflakeがエンティティに関連するプライバシーロスを正確に追跡できるように、これらの要件を満たさなければなりません。

プライバシーポリシーを適用して差分プライバシーを実装する前に、これらの要件を満たすようにデータを構造化する必要があります。Snowflakeは、データがこれらの構造要件に適合しているかどうかを判断することはできません。なぜなら、これらの構造要件はデータの意味に関するものであり、差分プライバシーの実装に関するものではないからです。たとえば、2つの異なるテーブルのエンティティキーが両方とも列 user_id に設定されており、一方の列には数値識別子の値が含まれ、もう一方の列にはメールアドレスが含まれる場合、Snowflakeは2つのテーブル間でエンティティ情報を正しくリンクできません。

エンティティレベルのプライバシーを実現するには、データが以下の要件に適合している必要があります。

各行がエンティティ内の1個人のみに属する --- たとえば、あるテーブルにユーザーと世帯が含まれているとします。保護する必要があるエンティティがユーザーである場合は、各行が世帯であり、その世帯のすべてのユーザーが他の列にキャプチャされるようにテーブルを構造化することはできません。テーブルを再構築して、ユーザーがどの世帯に属するかを示す household_id 列で、1ユーザーにつき1行しかないようにする必要があります。
すべてのテーブルで一貫性のあるエンティティ識別子 --- 1つのエンティティに必要な保護を表すプライバシーポリシーを作成し、そのポリシーを当該エンティティに関する情報を含む複数のテーブルに適用することができます。各テーブルにプライバシーポリシーを割り当てるときは、エンティティを一意に識別する列（つまり、エンティティキー）を指定する必要があります。これらのエンティティキー列内でエンティティを一意に識別する値は、同一にしなければなりません。たとえば、 email 列が、あるエンティティに関する情報を含む2つのテーブルのエンティティキーであるとします。あるエンティティのメールアドレスが1つのテーブルで joe@company.com になっていると、もう1つのテーブルのメールアドレスも joe@company.com にする必要があります。

すべてのテーブルのエンティティ識別子 --- エンティティレベルのプライバシーを実装する必要はありませんが、エンティティに関連するすべてのテーブルにエンティティ識別子を含めることで、アナリストがクエリ結合のノイズを最小限に抑えることができます。場合によっては、この要件を満たすためにエンティティキー列を非正規化する必要があるかもしれません。たとえば、エンティティが複数の顧客である以下のようなテーブルがあるとします。

テーブル	説明
`customer`	各行が顧客であり、 `customer_id` を持つ顧客ディレクトリ。
`transactions`	各行がトランザクションであり、 `transaction_id` を持つ顧客トランザクション。各顧客は複数のトランザクションを持つことができます。
`transaction_lines`	トランザクションで購入された固有のアイテム。1つのトランザクションに複数の行が存在することもあります。

正規化のベストプラクティスでは、 transaction_lines テーブルは transaction_id を持つが、 customer_id は持たないようにします。 transaction_lines テーブルを transactions テーブルにリンクした上で、 customer_id で customers テーブルにリンクできます。

しかし、差分プライバシーのために、 transaction_lines テーブルに customer_id 識別子を追加して、アナリストのためにデータを最適化したい場合があります。これにより、 transaction_lines テーブルと別のテーブルを結合する際に、 customer_id を結合キーに含めることで、アナリストはノイズを最小限に抑えることができます。

Snowflake機能との相互作用¶

このセクションでは、以下の差分プライバシーオブジェクトが他のSnowflake機能とどのように相互作用するかについて説明します。プライバシーポリシー、プライバシーバジェット、プライバシードメインへの影響について説明します。

複製¶

プライバシーポリシーとプライバシー保護されたテーブルおよびビューを複製する際の考慮事項については、プライバシーポリシーをご参照ください。

注釈

現在、エンティティキーに関連付けられたプライバシーポリシーを持つ複製テーブルをクエリする際の制限があります。これらのテーブルに対するクエリは、制限が解除されるまでブロックされます。

クロスクラウドの自動フルフィルメント¶

データ製品の複製にクロスクラウドの自動フルフィルメントを使用する場合は、以下の点に留意してください。

データ製品が複製されたアカウントの管理者は、プライバシーバジェットを調整できません。
管理者は、1つのアカウントを使用して、すべてのリージョンで発生したプライバシーロスを表示することはできません。

クローニング¶

プライバシー保護されたテーブルとビューのクローニングの効果については、クローニングと差分プライバシーをご参照ください。

注釈

現在、エンティティキーに関連付けられたプライバシーポリシーを持つクローニングされたテーブルをクエリする際の制限があります。これらのテーブルに対するクエリは、制限が解除されるまでブロックされます。

プライバシー保護されたベースオブジェクト上に構築されたビュー¶

プライバシー保護されたテーブルやビューにビューを構築することができます。ただし、ベーステーブルやビューのプライバシードメインは継承されません。その結果、以下のようになる点にご注意ください。

プライバシードメインは、新しいビューの列に設定する必要があります。
ベーステーブルのプライバシードメインを調整しても、その上に構築されるビューのプライバシードメインには影響しません。

マテリアライズドビュー¶

マテリアライズドビューにプライバシーポリシーを割り当てて、プライバシー保護された状態にします。

プライバシーポリシーとマテリアライズドビューのその他の相互作用には、以下が含まれます。

プライバシー保護されたテーブルまたはビューに基づいてマテリアライズドビューを作成することはできません。
マテリアライズドビューのベーステーブルとして参照されるテーブルには、プライバシーポリシーを割り当てることはできません。

UDFs¶

アナリストは、ユーザー定義関数を使用してプライバシー保護されたテーブルをクエリすることはできません。

ストリーム¶

プライバシー保護されたテーブルに基づくストリームをクエリすることはできません。

ストリームにプライバシーポリシーを割り当てることはできません。

その他のポリシー¶

プライバシーポリシーは、以下のように他のSnowflakeポリシーと相互作用します。

マスキングポリシー: プライバシーポリシーとマスキングポリシーを同じテーブルまたはビューに割り当てることはできません。
行アクセスポリシー: 行アクセスポリシーは、プライバシーポリシーよりも優先されます。ある行が行アクセスポリシーによってブロックされている場合、その行は差分プライベートのクエリ結果には含まれません。
投影ポリシー: プライバシーポリシーを持つテーブルと、その列のいずれかを同時に投影ポリシーで保護することは、現在サポートされていません。この方法でポリシーを割り当てることはできますが、テーブルに対するクエリは失敗します。
集計ポリシー: プライバシーポリシーと集計ポリシーを同じテーブルまたはビューに割り当てることはできません。

動的テーブル¶

参照されるソーステーブルがプライバシー保護されている場合は、動的テーブルを作成できません。

既存の動的テーブルによって参照されているテーブルにプライバシーポリシーを割り当てることはできますが、ポリシーが割り当てられると、動的テーブルは更新されなくなります。

外部テーブル¶

プライバシーポリシーを外部テーブルに割り当てることができます。アナリストが VARIANT 列を集計しようとすると、クエリは失敗します。ただし、アナリストが仮想列で集計を試みる場合は、成功します。

Time Travel¶

Time Travelの場合、以前のバージョンのテーブルが新しいテーブルとしてコピーされると、Snowflakeは以前のバージョンのプライバシードメインをテーブルのメタデータに格納しないため、現行バージョンのプライバシードメインがテーブルに使用されます。