Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Überlegungen zur Verwendung von Cryptographic Computing für Clean Rooms
Cryptographic Computing for Clean Rooms (C3R) zielt darauf ab, den Datenschutz zu maximieren. Einige Anwendungsfälle könnten jedoch von einem geringeren Datenschutzniveau im Austausch für zusätzliche Funktionen profitieren. Sie können diese spezifischen Kompromisse eingehen, indem Sie C3R von der sichersten Konfiguration aus ändern. Als Kunde sollten Sie sich dieser Kompromisse bewusst sein und entscheiden, ob sie für Ihren Anwendungsfall geeignet sind. Zu den Kompromissen, die es zu berücksichtigen gilt, gehören:
**Topics**
+ [Zulassen gemischter cleartext und verschlüsselter Daten in Ihren Tabellen](#allow-mixed-plaintext-and-encrypted-data)
+ [Wiederholte Werte in fingerprint Spalten zulassen](#allow-repeated-values)
+ [Lockerung der Beschränkungen für die Benennung von fingerprint Spalten](#loose-restrictions-on-join-column-names)
+ [Bestimmen, wie NULL Werte dargestellt werden](#determine-null-values)
Weitere Informationen zum Einstellen von Parametern für diese Szenarien finden Sie unter. [Kryptografische Rechenparameter](crypto-computing-parameters.md)
## Zulassen gemischter cleartext und verschlüsselter Daten in Ihren Tabellen
Die clientseitige Verschlüsselung aller Daten bietet maximalen Datenschutz. Dadurch werden jedoch bestimmte Arten von Abfragen eingeschränkt (z. B. die SUM Aggregatfunktion). Das Risiko, cleartext Daten zuzulassen, besteht darin, dass es möglich ist, dass jeder, der Zugriff auf die verschlüsselten Tabellen hat, Informationen über verschlüsselte Werte ableiten kann. Dies könnte durch eine statistische Analyse der Daten cleartext und der zugehörigen Daten geschehen.
Stellen Sie sich zum Beispiel vor, Sie hätten die Spalten `City` und`State`. Die `City` Spalte ist cleartext und die `State` Spalte ist verschlüsselt. Wenn Sie den Wert `Chicago` in der `City` Spalte sehen, können Sie mit hoher Wahrscheinlichkeit feststellen, `State` dass der`Illinois`. Im Gegensatz dazu, wenn eine Spalte `City` und die andere Spalte ist`EmailAddress`, ist es unwahrscheinlich, dass a cleartext `City` etwas über eine verschlüsselte Spalte aussagt`EmailAddress`.
Weitere Informationen zu dem Parameter für dieses Szenario finden Sie unter[Parameter „Spalten zulassencleartext“](crypto-computing-parameters.md#parameter-allowcleartext).
## Wiederholte Werte in fingerprint Spalten zulassen
Für den sichersten Ansatz gehen wir davon aus, dass jede fingerprint Spalte genau eine Instanz einer Variablen enthält. Kein Element kann in einer fingerprint Spalte wiederholt werden. Der C3R-Verschlüsselungsclient ordnet diese cleartext Werte eindeutigen Werten zu, die nicht von Zufallswerten zu unterscheiden sind. Daher ist es unmöglich, aus diesen Zufallswerten Informationen über die abzuleiten. cleartext
Das Risiko wiederholter Werte in einer fingerprint Spalte besteht darin, dass wiederholte Werte zu wiederholten zufällig aussehenden Werten führen. Somit könnte theoretisch jeder, der Zugriff auf die verschlüsselten Tabellen hat, eine statistische Analyse der fingerprint Spalten durchführen, die Informationen über cleartext Werte liefern könnte.
Nehmen wir erneut an`State`, die fingerprint Spalte entspricht einem US-Haushalt und jede Zeile der Tabelle entspricht. Durch eine Frequenzanalyse könnte man ableiten, um welchen Bundesstaat es sich handelt `California` und welcher `Wyoming` mit hoher Wahrscheinlichkeit. Diese Schlussfolgerung ist möglich, weil es viel mehr Einwohner `California` hat als. `Wyoming` Nehmen wir dagegen an, die fingerprint Spalte bezieht sich auf eine Haushalts-ID und jeder Haushalt tauchte in der Datenbank ein- bis viermal in einer Datenbank mit Millionen von Einträgen auf. Es ist unwahrscheinlich, dass eine Frequenzanalyse nützliche Informationen liefern würde.
Weitere Informationen zu den Parametern für dieses Szenario finden Sie unter[Parameter „Duplikate zulassen“](crypto-computing-parameters.md#parameter-allowduplicates).
## Lockerung der Beschränkungen für die Benennung von fingerprint Spalten
Standardmäßig gehen wir davon aus, dass, wenn zwei Tabellen mithilfe verschlüsselter fingerprint Spalten verknüpft werden, diese Spalten in jeder Tabelle denselben Namen haben. Der technische Grund für dieses Ergebnis ist, dass wir standardmäßig einen anderen kryptografischen Schlüssel für die Verschlüsselung jeder Spalte ableiten. fingerprint Dieser Schlüssel wird aus einer Kombination aus dem gemeinsamen geheimen Schlüssel für die Zusammenarbeit und dem Spaltennamen abgeleitet. Wenn wir versuchen, zwei Spalten mit unterschiedlichen Spaltennamen zu verbinden, leiten wir unterschiedliche Schlüssel ab und können keinen gültigen Join berechnen.
Um dieses Problem zu beheben, können Sie die Funktion deaktivieren, die Schlüssel aus jedem Spaltennamen ableitet. Anschließend verwendet der C3R-Verschlüsselungsclient einen einzigen abgeleiteten Schlüssel für alle fingerprint Spalten. Das Risiko besteht darin, dass eine andere Art der Frequenzanalyse durchgeführt werden kann, die Informationen preisgeben könnte.
Lassen Sie uns das `State` Beispiel `City` und noch einmal verwenden. Wenn wir für jede fingerprint Spalte dieselben Zufallswerte ableiten (indem wir den Spaltennamen nicht einbeziehen). `New York`hat den gleichen Zufallswert in den Spalten `City` und`State`. New York ist eine der wenigen Städte in den USA, in denen der `City` Name mit dem `State` Namen identisch ist. Wenn Ihr Datensatz dagegen in jeder Spalte völlig unterschiedliche Werte enthält, werden keine Informationen durchgesickert.
Weitere Informationen zum Parameter für dieses Szenario finden Sie unter[Parameter „Zulassen JOIN von Spalten mit unterschiedlichen Namen“](crypto-computing-parameters.md#parameter-allowjoin).
## Bestimmen, wie NULL Werte dargestellt werden
Sie haben die Wahl, ob Sie Werte wie alle anderen NULL Werte kryptografisch (verschlüsseln und HMAC) verarbeiten möchten. Wenn Sie Werte nicht wie alle anderen NULL Werte verarbeiten, können Informationen preisgegeben werden.
Nehmen wir zum Beispiel an, dass NULL in der `Middle Name` Spalte in der Personen ohne zweiten Vornamen cleartext angegeben werden. Wenn Sie diese Werte nicht verschlüsseln, können Sie durchsickern lassen, welche Zeilen in der verschlüsselten Tabelle für Personen ohne zweiten Vornamen verwendet werden. Diese Informationen könnten für einige Menschen in bestimmten Bevölkerungsgruppen ein Identifikationssignal sein. Wenn Sie NULL Werte jedoch kryptografisch verarbeiten, verhalten sich bestimmte SQL-Abfragen anders. Beispielsweise gruppieren GROUP BY Klauseln fingerprint NULL Werte in fingerprint Spalten nicht zusammen.
Weitere Informationen zum Parameter für dieses Szenario finden Sie unter[Parameter „NULLWerte beibehalten“](crypto-computing-parameters.md#parameter-preservenulls).