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:

Weitere Informationen zum Einstellen von Parametern für diese Szenarien finden Sie unter. Kryptografische Rechenparameter

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 undState. 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 derIllinois. Im Gegensatz dazu, wenn eine Spalte City und die andere Spalte istEmailAddress, ist es unwahrscheinlich, dass a cleartext City etwas über eine verschlüsselte Spalte aussagtEmailAddress.

Weitere Informationen zu dem Parameter für dieses Szenario finden Sie unterParameter „Spalten zulassencleartext“.

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 anState, 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 unterParameter „Duplikate zulassen“.

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 Yorkhat den gleichen Zufallswert in den Spalten City undState. 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 unterParameter „Zulassen JOIN von Spalten mit unterschiedlichen Namen“.

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 unterParameter „NULLWerte beibehalten“.