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.

Richtlinien für den C3R-Verschlüsselungsclient

Der C3R-Verschlüsselungsclient ist ein Tool, mit dem Unternehmen sensible Daten zusammenführen können, um aus Datenanalysen neue Erkenntnisse zu gewinnen. Das Tool schränkt kryptografisch ein, was von jeder Partei und AWS während des Prozesses gelernt werden kann. Dies ist zwar von entscheidender Bedeutung, aber der Prozess der kryptografischen Sicherung von Daten kann zu einem erheblichen Mehraufwand sowohl in Bezug auf Rechen- als auch Speicherressourcen führen. Daher ist es wichtig, die Kompromisse bei der Verwendung der einzelnen Einstellungen zu verstehen und zu verstehen, wie die Einstellungen optimiert und gleichzeitig die gewünschten kryptografischen Garantien beibehalten werden können. Dieses Thema konzentriert sich auf die Auswirkungen verschiedener Einstellungen im C3R-Verschlüsselungsclient und in den Schemas auf die Leistung.

Alle Verschlüsselungseinstellungen des C3R-Verschlüsselungsclients bieten unterschiedliche kryptografische Garantien. Die Einstellungen auf Kollaborationsebene sind standardmäßig am sichersten. Durch die Aktivierung zusätzlicher Funktionen bei gleichzeitiger Schaffung einer Zusammenarbeit werden die Datenschutzgarantien geschwächt, sodass Aktivitäten wie Frequenzanalysen anhand des Chiffretextes durchgeführt werden können. Weitere Informationen darüber, wie diese Einstellungen verwendet werden und welche Auswirkungen sie haben, finden Sie unter. Kryptografisches Rechnen für Clean Rooms

Auswirkungen auf die Leistung von Spaltentypen

C3R verwendet drei Spaltentypen: cleartextfingerprint, undsealed. Jeder dieser Spaltentypen bietet unterschiedliche kryptografische Garantien und hat unterschiedliche Verwendungszwecke. In den folgenden Abschnitten werden die Auswirkungen des Spaltentyps auf die Leistung sowie die Auswirkungen der einzelnen Einstellungen auf die Leistung erörtert.

CleartextSpalten

CleartextSpalten werden gegenüber ihrem ursprünglichen Format nicht verändert und in keiner Weise kryptografisch verarbeitet. Dieser Spaltentyp kann nicht konfiguriert werden und beeinträchtigt weder die Speicher- noch die Rechenleistung.

FingerprintSpalten

FingerprintSpalten sollen verwendet werden, um Daten aus mehreren Tabellen zu verbinden. Zu diesem Zweck muss die resultierende Chiffretextgröße immer dieselbe sein. Diese Spalten werden jedoch von den Einstellungen auf Kollaborationsebene beeinflusst. FingerprintSpalten können sich unterschiedlich stark auf die Größe der Ausgabedatei auswirken, je nachdem, was in der Eingabe cleartext enthalten ist.

Basis-Overhead für fingerprint Spalten

Es gibt einen Basisgemeinkosten für fingerprint Spalten. Dieser Overhead ist konstant und ersetzt die Größe der cleartext Bytes.

Die Daten in den fingerprint Spalten werden mithilfe einer Hash-basierten HMAC-Funktion (Message Authentication Code) kryptografisch verarbeitet, die die Daten in einen 32-Byte-Nachrichtenauthentifizierungscode (MAC) umwandelt. Diese Daten werden dann über einen Base64-Encoder verarbeitet, wodurch die Bytegröße um etwa 33 Prozent erhöht wird. Ihm wird eine 8-Byte-C3R-Bezeichnung vorangestellt, um den Spaltentyp zu bezeichnen, zu dem die Daten gehören, und die Client-Version, die sie erzeugt hat. Das Endergebnis ist 52 Byte. Dieses Ergebnis wird dann mit der Zeilenanzahl multipliziert, um den gesamten Basis-Overhead zu erhalten (verwenden Sie die Anzahl der gesamten null Nichtwerte, wenn der Wert auf „true“ gesetzt preserveNulls ist).

Die folgende Abbildung zeigt, wie BASE_OVERHEAD = C3R_DESIGNATION + (MAC * 1.33)

Der ausgegebene Chiffretext in den fingerprint Spalten wird immer 52 Byte lang sein. Dies kann zu einer erheblichen Verringerung des Speicherplatzes führen, wenn die cleartext Eingabedaten im Durchschnitt mehr als 52 Byte umfassen (z. B. vollständige Straßenadressen). Dies kann eine erhebliche Speichererweiterung bedeuten, wenn die cleartext Eingabedaten im Durchschnitt weniger als 52 Byte enthalten (z. B. aufgrund des Alters des Kunden).

Einstellungen für die Zusammenarbeit für fingerprint Spalten

preserveNulls-Einstellung

Wenn die Einstellung preserveNulls auf Kollaborationsebene false (Standard) lautet, wird jeder null Wert durch eindeutige, zufällige 32 Byte ersetzt und so verarbeitet, als ob dies nicht der Fall wäre. null Das Ergebnis ist, dass jeder null Wert jetzt 52 Byte groß ist. Dies kann zu erheblichen Speicheranforderungen für Tabellen führen, die nur sehr wenige Daten enthalten, verglichen mit der Einstellung, bei der null Werte übergeben werden. true null

Wenn Sie die Datenschutzgarantien dieser Einstellung nicht benötigen und es vorziehen, null Werte in Ihren Datensätzen beizubehalten, aktivieren Sie die preserveNulls Einstellung bei der Erstellung der Kollaboration. Die preserveNulls Einstellung kann nach der Erstellung der Kollaboration nicht mehr geändert werden.

Beispieldaten für eine fingerprint Spalte

Im Folgenden finden Sie ein Beispiel für Eingabe- und Ausgabedaten für eine fingerprint Spalte mit Einstellungen zur Reproduktion. Andere Einstellungen auf Kollaborationsebene wirken sich wie allowCleartext und allowDuplicates nicht auf die Ergebnisse aus und können so eingestellt werden, als true false ob versucht wird, lokal zu reproduzieren.

Beispiel für ein geteiltes Geheimnis: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

Beispiel für eine Kollaborations-ID: a1b2c3d4-5678-90ab-cdef-EXAMPLE11111

allowJoinsOnColumnsWithDifferentNames: True Diese Einstellung hat keinen Einfluss auf die Leistungs- oder Speicheranforderungen. Diese Einstellung macht die Wahl des Spaltennamens jedoch irrelevant, wenn die Werte in den folgenden Tabellen wiedergegeben werden.

Problembehandlung bei fingerprint Spalten

Warum ist der Chiffretext in meinen fingerprint Spalten um ein Vielfaches größer als cleartext der Inhalt?

Der Chiffretext in einer fingerprint Spalte ist immer 52 Byte lang. Wenn Ihre Eingabedaten klein waren (z. B. das Alter der Kunden), wurde sie deutlich größer. Dies kann auch passieren, wenn die preserveNulls Einstellung auf gesetzt istfalse.

Warum ist der Chiffretext in meinen fingerprint Spalten um ein Vielfaches kleiner als cleartext der Inhalt?

Der Chiffretext in einer fingerprint Spalte ist immer 52 Byte lang. Wenn Ihre Eingabedaten umfangreich sind (z. B. die vollständigen Straßenadressen von Kunden), ist die Größe deutlich geringer.

Woher weiß ich, ob ich die kryptografischen Garantien von benötige? preserveNulls

Leider lautet die Antwort, dass es darauf ankommt. Zumindest Kryptografische Rechenparameter sollte überprüft werden, wie die preserveNulls Einstellung Ihre Daten schützt. Wir empfehlen Ihnen jedoch, die Datenverarbeitungsanforderungen Ihres Unternehmens und alle Verträge, die für die jeweilige Zusammenarbeit gelten, zu beachten.

Warum muss ich den Overhead von Base64 auf mich nehmen?

Um die Kompatibilität mit tabellarischen Dateiformaten wie CSV zu gewährleisten, ist eine Base64-Kodierung erforderlich. Zwar unterstützen einige Dateiformate wie z. Parquet B. binäre Darstellungen von Daten, es ist jedoch wichtig, dass alle Teilnehmer einer Zusammenarbeit Daten auf die gleiche Weise darstellen, um korrekte Abfrageergebnisse zu gewährleisten.

SealedSpalten

SealedSpalten sollen für die Übertragung von Daten zwischen Mitgliedern einer Kollaboration verwendet werden. Der Geheimtext in diesen Spalten ist nicht deterministisch und hat je nach Konfiguration der Spalten erhebliche Auswirkungen sowohl auf die Leistung als auch auf den Speicherplatz. Diese Spalten können individuell konfiguriert werden und haben oft den größten Einfluss auf die Leistung des C3R-Verschlüsselungsclients und die daraus resultierende Größe der Ausgabedatei.

Basis-Overhead für Spalten sealed

Es gibt einen Basisgemeinkosten für sealed Spalten. Dieser Overhead ist konstant und kommt zu der Größe der Byte cleartext und der Füllmenge (falls vorhanden) hinzu.

Vor jeder Verschlüsselung wird den Daten in den sealed Spalten ein 1-Byte-Zeichen vorangestellt, das angibt, welcher Datentyp enthalten ist. Wenn Padding ausgewählt ist, werden die Daten aufgefüllt und mit 2 Byte angehängt, die die Pad-Größe angeben. Nachdem diese Byte hinzugefügt wurden, werden die Daten mithilfe von AES-GCM kryptografisch verarbeitet und mit IV (12 Byte), (32 Byte) und nonce (16 Byte) gespeichert. Auth Tag Diese Daten werden dann durch einen Base64-Encoder verarbeitet, wodurch die Bytegröße um etwa 33 Prozent erhöht wird. Den Daten wird eine 7-Byte-C3R-Bezeichnung vorangestellt, um anzugeben, zu welchem Spaltentyp die Daten gehören und welche Client-Version verwendet wurde, um sie zu erzeugen. Das Ergebnis ist ein endgültiger Basisaufwand von 91 Byte. Dieses Ergebnis kann dann mit der Zeilenanzahl multipliziert werden, um den gesamten Basis-Overhead zu erhalten (verwenden Sie die Anzahl der Gesamtwerte ungleich Null, wenn der Wert auf true gesetzt preserveNulls ist).

Die folgende Abbildung zeigt, wie BASE_OVERHEAD = C3R_DESIGNATION + ((NONCE + IV + DATA_TYPE + PAD_SIZE + AUTH_TAG) * 1.33)

Einstellungen für die Zusammenarbeit für sealed Spalten

preserveNulls-Einstellung

Wenn die Einstellung auf Kollaborationsebene auf false (Standard) gesetzt preserveNulls ist, ist jeder null Wert einmalig, hat 32 Byte Zufallswerte und wird so verarbeitet, als ob dies nicht der Fall wäre. null Das Ergebnis ist, dass jeder null Wert jetzt 91 Byte groß ist (mehr, wenn er aufgefüllt wird). Dies kann zu erheblichen Speicheranforderungen für Tabellen führen, die nur sehr wenige Daten enthalten, als wenn diese Einstellung aktiviert ist true und null Werte als null übergeben werden.

Wenn Sie die Datenschutzgarantien dieser Einstellung nicht benötigen und es vorziehen, null Werte in Ihren Datensätzen beizubehalten, aktivieren Sie die preserveNulls Einstellung bei der Erstellung der Kollaboration. Die preserveNulls Einstellung kann nach der Erstellung der Kollaboration nicht mehr geändert werden.

sealedSpalten mit Schemaeinstellungen: Polstertypen

Pad-Typ von none

Durch die Auswahl des Padtyps von none wird dem zuvor beschriebenen Grund-Overhead keine Polsterung hinzugefügt cleartext und auch kein zusätzlicher Overhead hinzugefügt. Wenn keine Polsterung vorhanden ist, ergibt sich die platzsparendste Ausgabegröße. Es bietet jedoch nicht die gleichen Datenschutzgarantien wie die Polstertypen fixed undmax. Das liegt daran, dass die Größe des Basistextes anhand der Größe des Chiffretextes erkennbar cleartext ist.

Pad-Typ von fixed

Die Auswahl des Pad-Typs von fixed dient dem Schutz der Privatsphäre, um die Länge der in einer Spalte enthaltenen Daten zu verbergen. Dies wird erreicht, indem das gesamte Feld mit dem angegebenen Feld ausgefüllt wirdcleartext, pad_length bevor es verschlüsselt wird. Alle Daten, die diese Größe überschreiten, führen dazu, dass der C3R-Verschlüsselungsclient fehlschlägt.

Da das Padding cleartext vor der Verschlüsselung hinzugefügt wird, hat AES-GCM eine 1-zu-1-Zuordnung von Chiffretext-Bytes. cleartext Durch die Base64-Kodierung werden 33 Prozent hinzukommen. Der zusätzliche Speicheraufwand des Padding kann berechnet werden, indem die durchschnittliche Länge von vom Wert von subtrahiert pad_length und mit 1,33 multipliziert wird. cleartext Das Ergebnis ist der durchschnittliche Mehraufwand für das Auffüllen pro Datensatz. Dieses Ergebnis kann dann mit der Anzahl der Zeilen multipliziert werden, um den gesamten Auffüllaufwand zu erhalten (verwenden Sie die Anzahl der gesamten null Nichtwerte, falls preserveNulls auf gesetzt). true

PADDING_OVERHEAD = (PAD_LENGTH - AVG_CLEARTEXT_LENGTH) * 1.33 * ROW_COUNT

Es wird empfohlen, das Minimum auszuwählenpad_length, das den größten Wert in einer Spalte umfasst. Wenn der größte Wert beispielsweise 50 Byte beträgt, ist ein Wert pad_length von 50 ausreichend. Ein höherer Wert erhöht nur zusätzlichen Speicheraufwand.

Eine feste Polsterung erhöht keinen nennenswerten Rechenaufwand.

Pad-Typ von max

Die Auswahl des Pad-Typs von max dient dem Schutz der Privatsphäre, um die Länge der in einer Spalte enthaltenen Daten zu verbergen. Dies wird erreicht, indem der cleartext gesamte Wert mit dem größten Wert in der Spalte und dem zusätzlichen Wert aufgefüllt wird, pad_length bevor die Spalte verschlüsselt wird. Im Allgemeinen bietet max das Auffüllen die gleiche Sicherheit wie das Auffüllen fixed eines einzelnen Datensatzes, ermöglicht jedoch, dass der größte cleartext Wert in der Spalte nicht bekannt ist. Das Auffüllen max bietet jedoch möglicherweise nicht die gleichen Datenschutzgarantien wie fixed das Auffüllen bei Aktualisierungen, da der größte Wert in den einzelnen Datensätzen unterschiedlich sein kann.

Wir empfehlen, dass Sie bei der Verwendung von Padding einen zusätzlichen Wert pad_length von 0 wählen. max Bei dieser Länge werden alle Werte so aufgefüllt, dass sie dieselbe Größe wie der größte Wert in der Spalte haben. Ein höherer Wert erhöht nur zusätzlichen Speicheraufwand.

Wenn der größte cleartext Wert für eine bestimmte Spalte bekannt ist, empfehlen wir, stattdessen den fixed Pad-Typ zu verwenden. Die Verwendung von fixed Padding sorgt für Konsistenz zwischen aktualisierten Datensätzen. Die Verwendung max von Auffüllung führt dazu, dass jede Teilmenge der Daten mit dem größten Wert aufgefüllt wird, der in der Teilmenge enthalten war.

Beispieldaten für eine Spalte sealed

Im Folgenden finden Sie ein Beispiel für Eingabe- und Ausgabedaten für eine sealed Spalte mit Einstellungen zur Reproduktion. Andere Einstellungen auf Kollaborationsebene wie allowCleartextallowJoinsOnColumnsWithDifferentNames, und wirken sich allowDuplicates nicht auf die Ergebnisse aus und können so eingestellt werden, als true false ob versucht wird, sich lokal zu reproduzieren. Dies sind zwar die Grundeinstellungen für die Reproduktion, aber die sealed Spalte ist nicht deterministisch und die Werte ändern sich jedes Mal. Das Ziel besteht darin, die eingehenden Byte im Vergleich zu den ausgehenden Bytes anzuzeigen. Die pad_length Beispielwerte wurden bewusst ausgewählt. Sie zeigen, dass beim fixed Auffüllen die gleichen Werte wie max beim Auffüllen mit den empfohlenen pad_length Mindesteinstellungen erzielt werden oder wenn zusätzliche Polsterung gewünscht wird.

Beispiel für einen gemeinsamen geheimen Schlüssel: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

Beispiel für eine Kollaborations-ID: a1b2c3d4-5678-90ab-cdef-EXAMPLE11111

Pad-Typ von none

Pad-Typ von fixed (Beispiel 1)

In diesem Beispiel pad_length ist es 62 und die größte Eingabe ist 62 Byte.

Pad-Typ von fixed (Beispiel 2)

In diesem Beispiel pad_length ist es 162 und die größte Eingabe ist 62 Byte.

Pad-Typ von max (Beispiel 1)

In diesem Beispiel pad_length ist der Wert 0 und die größte Eingabe ist 62 Byte.

Pad-Typ von max (Beispiel 2)

In diesem Beispiel pad_length ist es 100 und die größte Eingabe ist 62 Byte.

sealedSpalten zur Problembehandlung

Warum ist der Chiffretext in meinen sealed Spalten um ein Vielfaches größer als cleartext der Inhalt?

Das hängt von mehreren Faktoren ab. Zum einen ist der Chiffretext in einer Cleartext Spalte immer mindestens 91 Byte lang. Wenn Ihre Eingabedaten klein wären (z. B. das Alter der Kunden), würden sie deutlich an Größe zunehmen. Zweitens, wenn preserveNulls wir auf eingestellt sind false und Ihre Eingabedaten viele null Werte enthielten, wurde jeder dieser null Werte in 91 Byte Chiffretext umgewandelt. Und wenn Sie Padding verwenden, werden den cleartext Daten per Definition Byte hinzugefügt, bevor sie verschlüsselt werden.

Die meisten meiner Daten in einer sealed Spalte sind sehr klein, und ich muss Padding verwenden. Kann ich einfach die großen Werte entfernen und sie separat verarbeiten, um Platz zu sparen?

Wir empfehlen nicht, große Werte zu entfernen und separat zu verarbeiten. Dadurch ändern sich die Datenschutzgarantien, die der C3R-Verschlüsselungsclient bietet. Gehen Sie als Bedrohungsmodell davon aus, dass ein Beobachter beide verschlüsselten Datensätze sehen kann. Wenn der Beobachter feststellt, dass bei einer Teilmenge von Daten eine Spalte deutlich mehr oder weniger aufgefüllt ist als bei einer anderen Teilmenge, kann er Rückschlüsse auf die Größe der Daten in jeder Teilmenge ziehen. Nehmen wir beispielsweise an, dass eine fullName Spalte in einer Datei auf insgesamt 40 Byte aufgefüllt ist und in einer anderen Datei auf 800 Byte aufgefüllt wird. Ein Beobachter könnte davon ausgehen, dass ein Datensatz den längsten Namen der Welt (747 Byte) enthält.

Muss ich zusätzliche Polsterung bereitstellen, wenn ich den max Padding-Typ verwende?

Nein. Bei der Verwendung max von Innenabständen empfehlen wirpad_length, die auch als zusätzliche Polsterung bezeichnet wird, die über den größten Wert in der Spalte hinausgeht, auf 0 zu setzen.

Kann ich pad_length bei der Verwendung von fixed Padding einfach einen Wert vom Typ L wählen, damit ich mir keine Gedanken darüber machen muss, ob der größte Wert passt?

Ja, aber die große Länge des Pads ist ineffizient und beansprucht mehr Speicherplatz als nötig. Wir empfehlen Ihnen, zu überprüfen, wie groß der größte Wert ist, und den Wert pad_length auf diesen Wert einzustellen.

Woher weiß ich, ob ich die kryptografischen Garantien von benötige? preserveNulls

Leider lautet die Antwort, dass es darauf ankommt. Zumindest Kryptografisches Rechnen für Clean Rooms sollte überprüft werden, wie die preserveNulls Einstellung Ihre Daten schützt. Wir empfehlen Ihnen jedoch, die Datenverarbeitungsanforderungen Ihres Unternehmens und alle Verträge, die für die jeweilige Zusammenarbeit gelten, zu beachten.

Warum muss ich den Overhead von Base64 auf mich nehmen?

Um die Kompatibilität mit tabellarischen Dateiformaten wie CSV zu gewährleisten, ist eine Base64-Kodierung erforderlich. Obwohl einige Dateiformate, wie z. Parquet B., binäre Darstellungen von Daten unterstützen, ist es wichtig, dass alle Teilnehmer einer Zusammenarbeit Daten auf die gleiche Weise darstellen, um korrekte Abfrageergebnisse zu gewährleisten.

Behebung unerwarteter Zunahmen der Chiffretext-Größe

Nehmen wir an, Sie haben Ihre Daten verschlüsselt und die Größe der resultierenden Daten ist überraschend groß. Mithilfe der folgenden Schritte können Sie ermitteln, wo der Größenzuwachs stattgefunden hat und welche Maßnahmen Sie gegebenenfalls ergreifen können.

Identifizieren Sie, wo die Größenzunahme stattgefunden hat

Bevor Sie herausfinden können, warum Ihre verschlüsselten Daten deutlich größer sind als Ihre cleartext Daten, müssen Sie zunächst herausfinden, wo die Zunahme liegt. CleartextSpalten können bedenkenlos ignoriert werden, da sie unverändert sind. Sehen Sie sich die verbleibenden sealed Spalten fingerprint und die anderen an und wählen Sie eine aus, die aussagekräftig erscheint.

Identifizieren Sie den Grund für die Größenzunahme

Eine fingerprint Spalte oder eine sealed Spalte könnte zur Größenzunahme beitragen.

Kommt die Größenzunahme von einer fingerprint Spalte?

Wenn es sich bei der Spalte, die am meisten zur Speichererweiterung beiträgt, um eine fingerprint Spalte handelt, liegt das wahrscheinlich daran, dass die cleartext Daten klein sind (z. B. das Alter des Kunden). Jeder resultierende fingerprint Chiffretext hat eine Länge von 52 Byte. Leider kann gegen dieses Problem nichts auf der Grundlage unternommen werden. column-by-column Weitere Informationen zu dieser Spalte, einschließlich der Auswirkungen auf die Speicheranforderungen, finden Sie unter. Basis-Overhead für fingerprint Spalten

Die andere mögliche Ursache für die Vergrößerung einer fingerprint Spalte ist die Einstellung für die Zusammenarbeit,preserveNulls. Wenn die Einstellung für die Zusammenarbeit deaktiviert preserveNulls ist (die Standardeinstellung), werden aus allen null Werten in fingerprint Spalten 52 Byte Chiffretext. In der aktuellen Zusammenarbeit kann dafür nichts unternommen werden. Die preserveNulls Einstellung wird bei der Erstellung einer Kollaboration festgelegt, und alle Mitarbeiter müssen dieselbe Einstellung verwenden, um korrekte Abfrageergebnisse sicherzustellen. Weitere Informationen zu dieser preserveNulls Einstellung und dazu, wie sich ihre Aktivierung auf die Datenschutzgarantien Ihrer Daten auswirkt, finden Sie unter. Kryptografisches Rechnen für Clean Rooms

Ist die Größenzunahme auf eine sealed Spalte zurückzuführen?

Wenn es sich bei der Spalte, die am meisten zur Erhöhung des Speicherplatzes beiträgt, um eine sealed Spalte handelt, gibt es einige Details, die zur Vergrößerung beitragen könnten.

Wenn die cleartext Daten klein sind (z. B. das Alter des Kunden), ist jeder resultierende sealed Chiffretext mindestens 91 Byte lang. Leider kann nichts gegen dieses Problem unternommen werden. Weitere Informationen zu dieser Spalte, einschließlich der Auswirkungen auf die Speicheranforderungen, finden Sie unter. Basis-Overhead für Spalten sealed

Die zweite Hauptursache für die Erhöhung des Speicherplatzes in sealed Spalten ist die Polsterung. Beim Auffüllen werden zusätzliche Byte hinzugefügt, cleartext bevor es verschlüsselt wird, um die Größe einzelner Werte in einem Datensatz zu verbergen. Wir empfehlen Ihnen, das Padding auf den kleinstmöglichen Wert für Ihren Datensatz festzulegen. pad_lengthFür das fixed Padding muss mindestens so eingestellt werden, dass es den größtmöglichen Wert in der Spalte umfasst. Eine höhere Einstellung als diese bietet keine zusätzlichen Datenschutzgarantien. Wenn Sie beispielsweise wissen, dass der größtmögliche Wert in einer Spalte 50 Byte sein kann, empfehlen wir, den Wert pad_length auf 50 Byte festzulegen. Wenn in der sealed Spalte jedoch max Padding verwendet wird, empfehlen wir, den Wert pad_length auf 0 Byte zu setzen. Dies liegt daran, dass max sich das Auffüllen auf das zusätzliche Auffüllen bezieht, das über den größten Wert in der Spalte hinausgeht.

Die letzte mögliche Ursache für die Vergrößerung einer sealed Spalte ist die Einstellung für die Zusammenarbeit,. preserveNulls Wenn die Einstellung für die Zusammenarbeit deaktiviert preserveNulls ist (die Standardeinstellung), werden aus allen null Werten in sealed Spalten 91 Byte Chiffretext. In der aktuellen Zusammenarbeit kann dafür nichts unternommen werden. Die preserveNulls Einstellung wird bei der Erstellung einer Kollaboration festgelegt, und alle Mitarbeiter müssen dieselbe Einstellung verwenden, um korrekte Abfrageergebnisse sicherzustellen. Weitere Informationen zu dieser Einstellung und zu den Auswirkungen ihrer Aktivierung auf die Datenschutzgarantien Ihrer Daten finden Sie unter. Kryptografisches Rechnen für Clean Rooms