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 bei der Verwendung von Cryptographic Computing für Clean Rooms

Kryptografisches Rechnen für Clean Rooms (C3R) ist bestrebt, den Datenschutz zu maximieren. In einigen Anwendungsfällen könnte jedoch ein niedrigeres Datenschutzniveau im Austausch für zusätzliche Funktionen von Vorteil sein. 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

Gemischt zulassen cleartext und verschlüsselte Daten in Ihren Tabellen

Die clientseitige Verschlüsselung aller Daten bietet maximalen Datenschutz. Dies schränkt jedoch bestimmte Arten von Abfragen ein (z. B. SUM Aggregatfunktion). Das Risiko des Zulassens cleartext Daten bestehen 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 cleartext und zugehörige Daten.

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 Illinois der Im Gegensatz dazu, wenn eine Spalte City und die andere Spalte ein EmailAddress cleartext Cityist unwahrscheinlich, dass etwas über eine verschlüsselte Datei preisgegeben wirdEmailAddress.

Weitere Informationen zu den Parametern für dieses Szenario finden Sie unterSobald Sie die Details auf dieser Seite überprüft haben, klicken Sie auf cleartext Parameter „Spalten“.

Zulassen wiederholter Werte in fingerprint Spalten

Für den sichersten Ansatz gehen wir davon aus, dass fingerprint Eine Spalte enthält genau eine Instanz einer Variablen. Kein Element kann in einem wiederholt werden fingerprint Spalte. Der C3R-Verschlüsselungsclient ordnet diese zu cleartext Werte werden in eindeutige Werte umgewandelt, die sich nicht von Zufallswerten unterscheiden lassen. Daher ist es unmöglich, Informationen über die abzuleiten cleartext aus diesen Zufallswerten.

Das Risiko wiederholter Werte in einem fingerprint Spalte besagt, 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, die Informationen enthalten könnten über cleartext Werte.

Nehmen wir noch einmal an fingerprint Spalte istState, und jede Zeile der Tabelle entspricht einem US-Haushalt. 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 Im Gegensatz dazu sagen die fingerprint Die Spalte bezieht sich auf eine Haushaltskennung, und jeder Haushalt ist in der Datenbank ein- bis viermal in einer Datenbank mit Millionen von Einträgen aufgetaucht. 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 in Bezug auf fingerprint Spalten sind benannt

Standardmäßig gehen wir davon aus, dass, wenn zwei Tabellen verschlüsselt verknüpft werden fingerprint Spalten, diese Spalten haben in jeder Tabelle den gleichen Namen. Der technische Grund für dieses Ergebnis ist, dass wir standardmäßig jeweils einen anderen kryptografischen Schlüssel für die Verschlüsselung ableiten fingerprint Spalte. 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. Dann verwendet der C3R-Verschlüsselungsclient einen einzigen abgeleiteten Schlüssel für alle fingerprint Spalten. Das Risiko besteht darin, dass eine andere Art von 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 jeden die gleichen Zufallswerte ableiten fingerprint Spalte (indem der Spaltenname nicht aufgenommen wird). New Yorkhat denselben Zufallswert in den State Spalten City und. 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 unterSobald Sie die Details auf dieser Seite überprüft haben, klicken Sie auf JOIN Parameter für Spalten mit unterschiedlichen Namen.

Feststellen, wie NULL Werte werden dargestellt

Ihnen steht die Option zur Verfügung, ob die Verarbeitung kryptografisch erfolgen soll (verschlüsseln und HMAC) NULL Werte wie jeder andere Wert. Wenn Sie nicht verarbeiten NULL Werte wie jeder andere Wert können Informationen preisgegeben werden.

Nehmen wir zum Beispiel an NULL in der Middle Name Spalte in der cleartext weist auf Personen ohne zweiten Vornamen hin. 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. Aber wenn Sie kryptografisch verarbeiten NULL Werte, bestimmte SQL-Abfragen verhalten sich unterschiedlich. Zum Beispiel GROUP BY Klauseln werden nicht gruppiert fingerprint NULL Werte in fingerprint Spalten zusammen.

Weitere Informationen zu den Parametern für dieses Szenario finden Sie unterBeibehalten NULL Werte, Parameter.