Implementierung von Differential Privacy¶

Dieses Thema enthält Informationen für den Datenanbieter, der Differential Privacy (differentielle Privatsphäre) für sein Konto implementiert.

Bei der Implementierung von Differential Privacy (differentiellen Privatsphäre) für Ihr Datenset müssen Sie drei Schlüsselkonzepte berücksichtigen:

Datenschutzrichtlinien. Eine Tabelle oder Ansicht ist erst dann durch Differential Privacy (differentielle Privatsphäre) geschützt, wenn Sie ihr eine Datenschutzrichtlinie zuweisen. Eine Tabelle oder Ansicht mit einer Datenschutzrichtlinie gilt als datenschutzgeschützt.
Datenschutzbudgets. Wenn Analysten eine datenschutzgeschützte Tabelle abfragen, können Sie die Datenschutzbudgets verwalten, die mit diesem Analysten verbunden sind.
Datenschutzbereiche. Sie sollten einen Datenschutzbereich für Fakten- und Dimensionsspalten in einer datenschutzgeschützten Tabelle oder Ansicht definieren.

Einschränkungen

Sie können nicht derselben Tabelle oder Ansicht eine Datenschutzrichtlinie und eine Aggregationsrichtlinie oder Maskierungsrichtlinie zuweisen.
Abgesehen von der Abfrage des Rauschintervalls <label-diff_privacy_understand_results> wissen Analysten nicht, ob sie eine datenschutzgeschützte Tabelle abfragen. Daher sollte der Datenanbieter sie darüber informieren, dass die Abfrageergebnisse Rauschen enthalten.
Ein Datenanbieter kann den Datenschutzverlust nicht überwachen, der entsteht, wenn Analysten Abfragen in einem anderen Konto durchführen.
Das Anwenden mehrerer Datenschutzrichtlinien auf eine Tabelle wird derzeit nicht unterstützt. Aus diesem Grund ist es nicht möglich, mehr als eine Entität mit Differential Privacy (differentiellem Datenschutz) auf Entitätsebene in einer einzigen Tabelle zu schützen.
Abfragen auf replizierte oder geklonte Tabellen, bei denen eine Datenschutzrichtlinie mit einem Entitätsschlüssel verknüpft ist, sind derzeit blockiert.

Allgemeine Informationen zum Datenschutz auf Entitätsebene¶

Eine Entität bezieht sich auf eine Klasse von Datensubjekten, die geschützt werden sollten, z. B. Personen, Organisationen oder Speicherorte. Wenn jede einzelne Entität nur in einer Zeile auftauchen würde, wäre der Datenschutz auf Zeilenebene ausreichend, um ihre Identität zu schützen. Wenn jedoch Daten, die zu einer einzelnen Entität gehören, in mehreren Zeilen auftauchen (z. B. in Transaktionsdaten), muss differentielle Privatsphäre für den Datenschutz auf Entitätsebene konfiguriert werden, um jede Entität korrekt zu schützen.

Um den Datenschutz auf Entitätsebene zu gewährleisten, können Sie in Snowflake festlegen, welches Attribut zur Identifizierung einer Entität verwendet werden kann (ein Entitätsschlüssel). Damit kann Snowflake alle Datensätze identifizieren, die zu einer bestimmten Entität innerhalb eines Datensets gehören. Wenn zum Beispiel die Spalte email als der Entitätsschlüssel definiert ist, kann Snowflake feststellen, dass alle Datensätze, in denen email=joe.smith@example.com vorkommt, zur selben Entität gehören.

In den meisten Fällen wird der Datenschutz auf Entitätsebene dem Datenschutz auf Zeilenebene vorgezogen, der Datenschutz auf Zeilenebene kann für eine Tabelle jedoch gut geeignet sein, wenn Folgendes zutrifft:

Keine Spalte in der Tabelle identifiziert Entitäten eindeutig. Der Datenschutz auf Entitätsebene erfordert eine identifizierende Spalte.
Jede einzelne Entität wird nur einmal angezeigt.
Die Tabelle wird nicht in einer Verknüpfung verwendet. Verknüpfungen mit Tabellen, die durch Datenschutz auf Zeilenebene geschützt sind, sind möglich, haben aber Beschränkungen.

Sie können wählen, ob Sie den Datenschutz auf Entitäts- oder Zeilenebene implementieren möchten, wenn Sie einer Tabelle oder Ansicht eine Datenschutzrichtlinie zuweisen. Weitere Informationen dazu finden Sie unter Datenschutzrichtlinie zuweisen. Wenn Sie sich für die Implementierung des Datenschutzes auf Entitätsebene entscheiden, müssen die Daten auch die strukturellen Anforderungen von <label-diff_privacy_admin_entity_reqs> erfüllen, um sicherzustellen, dass der Entitätsbezeichner korrekt verwendet wird.

Tipp

Wenn Sie zwei getrennte Tabellen mit derselben Datenschutzrichtlinie schützen möchten, die jedoch nicht dieselben Entitätsschlüsselwerten haben, können Sie eine neue Tabelle erstellen, die die beiden identifizierenden Spalten zuordnet, eine Ansicht erstellen, die zwei der Tabellen verknüpft, und die Datenschutzrichtlinie auf die Ansicht anwenden. Sie könnten diese Strategie zum Beispiel verwenden, wenn der Entitätsschlüssel in einer Tabelle email und in einer anderen Tabelle user_id lautet, sich aber beide auf die gleichen Entitäten beziehen.

Strukturelle Anforderungen an den Datenschutz auf Entitätsebene¶

Die Struktur der Daten, die durch Differential Privacy (differentielle Privatsphäre) auf Entitätsebene geschützt werden, muss bestimmten Anforderungen entsprechen. Diese Anforderungen müssen erfüllt werden, damit Snowflake den mit Entitäten verbundenen Datenschutzverlust genau verfolgen kann.

Sie sollten Ihre Daten so strukturieren, dass sie diese Anforderungen erfüllen, bevor Sie Datenschutzrichtlinien zur Umsetzung der differentiellen Privatsphäre anwenden. Snowflake kann nicht feststellen, ob die Daten diesen strukturellen Anforderungen entsprechen, da sie die Bedeutung der Daten und nicht die Implementierung der differentiellen Privatsphäre betreffen. Wenn zum Beispiel die Entitätsschlüssel für zwei verschiedene Tabellen beide auf die Spalte user_id eingestellt sind, aber eine der Spalten Werte für einen numerischen Bezeichner enthält, während die andere Spalte E-Mail-Adressen enthält, kann Snowflake die Entitätsinformationen der beiden Tabellen nicht korrekt verknüpfen.

Um den Datenschutz auf Entitätsebene zu gewährleisten, müssen Ihre Daten die folgenden Anforderungen erfüllen:

Jede Zeile gehört nur zu einer Person innerhalb einer Entität – Nehmen wir als Beispiel an, eine Tabelle enthält Benutzer und Haushalte. Wenn die zu schützende Entität Benutzer sind, kann die Tabelle nicht so strukturiert werden, dass jede Zeile ein Haushalt ist und alle Benutzer in diesem Haushalt in anderen Spalten erfasst werden. Sie müssten die Tabelle so umstrukturieren, dass es nur eine Zeile pro Benutzer gibt, mit einer Spalte household_id, die angibt, zu welchem Haushalt ein Benutzer gehört.
Konsistenter Entitätsbezeichner in allen Tabellen – Sie können eine Datenschutzrichtlinie erstellen, die den Schutzbedarf für eine einzelne Entität darstellt, und diese Richtlinie dann auf mehrere Tabellen anwenden, die Informationen über die Entität enthalten. Wenn Sie die Datenschutzrichtlinie den einzelnen Tabellen zuordnen, müssen Sie die Spalte angeben, die die Entität eindeutig identifiziert (d. h. den Entitätsschlüssel). Der Wert, der eine Entität innerhalb dieser Schlüsselspalten eindeutig identifiziert, muss derselbe sein. Nehmen wir zum Beispiel an, dass die Spalte email der Schlüssel für zwei Tabellen ist, die Informationen über eine Entität enthalten. Wenn die E-Mail-Adresse einer Entität in einer Tabelle joe@company.com ist, muss die E-Mail-Adresse in der anderen Tabelle ebenfalls joe@company.com sein.

Entitätsbezeichner in allen Tabellen – Obwohl es nicht erforderlich ist, den Datenschutz auf Entitätsebene zu implementieren, können Sie es Analysten ermöglichen, das Rauschen in Abfrageverknüpfungen zu minimieren, indem Sie den Entitätsbezeichner in alle Tabellen aufnehmen, die sich auf eine Entität beziehen. In manchen Fällen müssen Sie die Spalte mit dem Entitätsschlüssel denormalisieren, um diese Anforderung zu erfüllen. Nehmen wir zum Beispiel an, Sie hätten die folgenden Tabellen, deren Entität Kunden sind:

Tabelle	Beschreibung
`customer`	Kundenverzeichnis, wobei jede Zeile ein Kunde ist und eine `customer_id` hat.
`transactions`	Kundentransaktionen, wobei jede Zeile eine Transaktion ist und eine `transaction_id` hat. Jeder Kunde kann mehrere Transaktionen haben.
`transaction_lines`	Eindeutige Element, die in einer Transaktion gekauft wurden. Es kann mehrere Zeilen in einer Transaktion geben.

Gemäß den bewährten Verfahren für die Normalisierung würde die Tabelle transaction_lines die transaction_id, aber nicht die customer_id enthalten. Die Tabelle transaction_lines wäre mit der Tabelle transactions verknüpft, die wiederum mit der Tabelle customers über customer_id verknüpft werden könnte.

Für die differentielle Privatsphäre möchten Sie jedoch wahrscheinlich die Daten für den Analysten optimieren, indem Sie den Bezeichner customer_id zur Tabelle transaction_lines hinzufügen. Dies ermöglicht es dem Analysten, das Rauschen zu minimieren, indem er customer_id in den Verknüpfungsschlüssel einbezieht, wenn er die Tabelle transaction_lines mit einer anderen Tabelle verbindet.

Interaktionen mit Snowflake-Features¶

In diesem Abschnitt wird erläutert, wie die folgenden Objekte differentieller Privatsphäre mit anderen Features von Snowflake zusammenwirken. Er erörtert die Auswirkungen auf Datenschutzrichtlinien, Datenschutzbudgets und Datenbereichen.

Replikation¶

Hinweise zu Replikation von Datenschutzrichtlinien und datenschutzgeschützten Tabellen und Ansichten finden Sie unter Datenschutzrichtlinien.

Bemerkung

Es gibt derzeit eine Beschränkung bei der Abfrage von replizierten Tabellen, bei denen eine Datenschutzrichtlinie mit einem Entitätsschlüssel verknüpft ist. Abfragen auf diese Tabellen sind blockiert, bis die Beschränkung aufgehoben wird.

Cloud-übergreifende automatische Ausführung¶

Beachten Sie Folgendes, wenn Sie Cloud-übergreifende automatische Ausführung zur Replikation eines Datenprodukts verwenden:

Administratoren des Kontos, auf das das Datenprodukt repliziert wurde, können das Datenschutzbudget nicht anpassen.
Administratoren können nicht mit einem einzigen Konto den in allen Regionen entstandenen Datenschutzverlust anzeigen.

Klonen¶

Zu den Auswirkungen des Klonens von datenschutzgeschützten Tabellen und Ansichten siehe Klonen und Differential Privacy (differentielle Privatsphäre).

Bemerkung

Es gibt derzeit eine Beschränkung bei der Abfrage von geklonten Tabellen, bei denen eine Datenschutzrichtlinie mit einem Entitätsschlüssel verknüpft ist. Abfragen auf diese Tabellen sind blockiert, bis die Beschränkung aufgehoben wird.

Ansichten, die auf einem datenschutzgeschützte Basisobjekt aufbauen¶

Sie können eine Ansicht auf eine datenschutzrechtlich geschützte Tabelle oder Ansicht erstellen. Die Datenschutzbereiche der Basistabelle oder Ansicht werden jedoch nicht vererbt. Beachten Sie daher Folgendes:

Die Datenschutzbereiche müssen auf die Spalten der neuen Ansicht eingestellt werden.
Die Anpassung des Datenschutzbereichs der Basistabelle hat keine Auswirkungen auf die Datenschutzbereiche der darauf aufbauenden Ansicht.

Materialisierte Ansichten¶

Sie können einer materialisierten Ansicht eine Datenschutzrichtlinie zuweisen, damit sie datenschutzgeschützt ist.

Weitere Wechselwirkungen zwischen Datenschutzrichtlinien und materialisierten Ansichten sind:

Sie können keine materialisierte Ansicht erstellen, die auf einer datenschutzgeschützten Tabelle oder Ansicht basiert.
Sie können einer Tabelle keine Datenschutzrichtlinie zuweisen, wenn sie als Basistabelle einer materialisierten Ansicht referenziert wird.

UDFs¶

Analysten können keine benutzerdefinierte Funktion verwenden, um eine datenschutzgeschützte Tabelle abzufragen.

Streams¶

Sie können keinen Stream abfragen, der auf einer datenschutzgeschützten Tabelle basiert.

Sie können einem Stream keine Datenschutzrichtlinie zuweisen.

Andere Richtlinien¶

Die Datenschutzrichtlinien interagieren auf folgende Weise mit anderen Snowflake-Richtlinien:

Maskierungsrichtlinien: Sie können nicht derselben Tabelle oder Ansicht eine Datenschutzrichtlinie und eine Maskierungsrichtlinie zuweisen.
Zeilenzugriffsrichtlinien: Zeilenzugriffsrichtlinien haben Vorrang vor einer Datenschutzrichtlinie. Wenn eine Zeile durch die Zeilenzugriffsrichtlinie gesperrt ist, wird sie nicht in die Ergebnisse der Abfrage mit differentieller Privatsphäre aufgenommen.
Projektionsrichtlinien: Der gleichzeitige Schutz einer Tabelle mit einer Datenschutzrichtlinie und einer ihrer Spalten mit einer Projektionsrichtlinie wird derzeit nicht unterstützt. Auch wenn Sie die Richtlinien auf diese Weise zuweisen können, schlagen Abfragen auf die Tabelle fehl.
Aggregationsrichtlinien: Sie können nicht derselben Tabelle oder Ansicht eine Datenschutzrichtlinie und eine Aggregationsrichtlinie zuweisen.

Dynamische Tabellen¶

Sie können keine dynamische Tabelle erstellen, wenn die referenzierte Quelltabelle datenschutzgeschützt ist.

Sie können einer Tabelle, die von einer bestehenden dynamischen Tabelle referenziert wird, eine Datenschutzrichtlinie zuweisen. Sobald die Richtlinie zugewiesen ist, wird die dynamische Tabelle jedoch nicht mehr aktualisiert.

Externe Tabellen¶

Sie können einer externen Tabelle eine Datenschutzrichtlinie zuweisen. Wenn ein Analyst versucht, eine VARIANT-Spalte zu aggregieren, schlägt die Abfrage fehl. Wenn ein Analyst jedoch versucht, eine virtuelle Spalte zu aggregieren, ist dies erfolgreich.

Time Travel¶

Wenn für Time Travel eine frühere Version einer Tabelle als neue Tabelle kopiert wird, wird die aktuelle Version eines Datenschutzbereichs für die Tabelle verwendet, da Snowflake keine früheren Versionen des Datenschutzbereichs in Tabellenmetadaten speichert.