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.

Auswahl einer Beacon-Länge und Partitionen

Wenn Sie einen neuen Wert in ein verschlüsseltes Feld schreiben, das für durchsuchbare Verschlüsselung konfiguriert ist, berechnet das AWS Database Encryption SDK anhand des Klartext-Werts in Kombination mit einer Partitions-ID einen HMAC-Wert. Innerhalb einer bestimmten Partition stellt der vollständige HMAC-Wert eindeutig den Klartext-Wert dar. Das SDK kürzt dann die HMAC-Ausgabe, sodass mehrere unterschiedliche Klartextwerte demselben Beacon zugeordnet werden können. Diese Kollisionen, auch als Fehlalarme bezeichnet, schränken die Fähigkeit eines nicht autorisierten Benutzers ein, Unterscheidungsmerkmale über den zugrundeliegenden Klartext abzuleiten.

Die durchschnittliche Anzahl der für jeden Beacon generierten Fehlalarme wird durch die Länge des Beacons nach der Kürzung und die Anzahl der verwendeten Partitionen bestimmt. Sie müssen nur die Beacon-Länge definieren, wenn Sie Standard-Beacons konfigurieren. Verbund-Beacons verwenden die Beacon-Längen der Standard-Beacons, aus denen sie aufgebaut sind. Durch die Verteilung von Werten auf mehrere Partitionen werden Kollisionen innerhalb jeder Partition aufrechterhalten, was dazu beiträgt, die Frequenzkonzentration zu reduzieren und gleichzeitig das korrekte Abfrageverhalten beizubehalten.

Der Beacon ändert den verschlüsselten Status des Feldes nicht. Bei der Verwendung von Beacons besteht jedoch ein inhärenter Kompromiss zwischen der Effizienz Ihrer Abfragen und der Menge an Informationen, die über die Verteilung Ihrer Daten preisgegeben werden. Kürzere Beacon-Längen und zusätzliche Partitionen erhöhen Kollisionen und reduzieren Frequenzverluste, während längere Beacon-Längen und weniger Partitionen die Abfragegenauigkeit verbessern.

Das Ziel der durchsuchbaren Verschlüsselung besteht darin, die mit clientseitig verschlüsselten Datenbanken verbundenen Leistungskosten zu senken, indem Beacons zur Durchführung von Abfragen verschlüsselter Daten verwendet werden. Beacons werden zusammen mit den verschlüsselten Feldern gespeichert, aus denen sie berechnet werden. Das bedeutet, dass sie aussagekräftige Informationen über die Verteilung Ihres Datensatzes preisgeben können. In extremen Fällen kann ein nicht autorisierter Benutzer die Informationen über Ihre Verteilung analysieren und anhand dieser Informationen den Klartextwert eines Felds ermitteln. Die Wahl geeigneter Beacon-Längen und Partitionszahlen trägt dazu bei, diese Risiken zu minimieren und die Vertraulichkeit Ihrer Daten zu wahren.

Überprüfen Sie Ihr Bedrohungsmodell, um das Sicherheitsniveau zu ermitteln, das Sie benötigen. Je mehr Personen beispielsweise Zugriff auf Ihre Datenbank haben, aber keinen Zugriff auf die Klartextdaten haben sollten, desto mehr möchten Sie möglicherweise die Vertraulichkeit Ihrer Datensatzverteilung schützen. Um die Vertraulichkeit zu erhöhen, müssen in der Regel mehr Falschmeldungen generiert werden (durch kürzere Beacon-Längen, zusätzliche Partitionen oder beides), was wiederum die Abfrageleistung verringern kann.

Auswahl eines Partitionierungsschemas

Das Partitionierungsschema bestimmt, wie Elemente bei der Ableitung von Beacons auf die Partitionen verteilt werden. Die Auswahl eines geeigneten Schemas ist wichtig, um ein Gleichgewicht zwischen Datenschutz, Leistung und betrieblicher Vorhersehbarkeit herzustellen.

Beachten Sie bei der Auswahl eines Partitionierungsschemas die folgenden Ziele:

Standardmäßige zufällige Verteilung

Die empfohlene Standardeinstellung ist ein zufälliges Verteilungsschema. In diesem Modell wird jedes Element mithilfe eines kryptografisch sicheren Zufallswerts einer Partition zugewiesen. Die zufällige Verteilung führt im Laufe der Zeit zu ungefähr gleichen Partitionsgrößen und stellt sicher, dass häufig vorkommende Werte gleichmäßig verteilt werden.

Verwenden Sie die Zufallsverteilung, wenn:

Deterministische Verteilung

In einigen Fällen muss die Partitionszuweisung deterministisch sein. Ein deterministisches Schema weist Partitionen auf der Grundlage einer stabilen Funktion von Elementattributen zu. Diese Schemata müssen sorgfältig entworfen werden, da schiefe oder sensible Eingaben zu ungleichmäßiger Partitionierung oder unbeabsichtigten Informationslecks führen können.

Verwenden Sie die deterministische Verteilung in folgenden Fällen:

Umgang mit bekannten aktuellen Werten

Wenn Ihr Datensatz bekannte aktuelle Werte enthält, können Sie zufällige und deterministische Strategien kombinieren. Sie können beispielsweise einen kleinen Satz hochfrequenter Werte nach dem Zufallsprinzip verteilen, während Sie alle anderen Werte deterministisch zuweisen.

Dieser Ansatz reduziert die Konzentration bei heißen Werten und behält gleichzeitig das vorhersehbare Verhalten für den Rest des Datensatzes bei. Da dieser Ansatz zusätzliche Komplexität mit sich bringt, sollten Sie ihn sorgfältig prüfen, um unbeabsichtigte Informationsverluste zu vermeiden.

Beispiele für Partitionierungsschemata

Die folgenden Beispiele veranschaulichen gängige Partitionierungsschemata und zeigen, wie unterschiedliche Dateneigenschaften die Partitionszuweisung beeinflussen. Jedes Beispiel zeigt, wie Datenschutz, Leistung und einfache Bedienung in Einklang gebracht werden können.

Beispiel 1: Gleichmäßig verteilte Daten

Sie erstellen ein Beacon für Telefonnummern, und die Werte in Ihrem Datensatz sind ungefähr gleichmäßig verteilt. Keine einzelne Telefonnummer erscheint signifikant häufiger als andere.

In diesem Fall ist die Konfiguration einer einzelnen Partition ausreichend. Zusätzliche Partitionen bieten kaum Vorteile und würden nur die Anzahl der Abfragen erhöhen.

Beispiel 2: Binäre Ergebnisse mit verzerrter Häufigkeit

Sie haben eine Datenbank, in der medizinische Testergebnisse mit zwei möglichen Werten gespeichert sind: NEGATIV und POSITIV. NEGATIVE Ergebnisse treten ungefähr fünfmal häufiger auf als POSITIVE Ergebnisse.

Verwenden Sie eine gemischte Strategie, um Frequenzverluste zu reduzieren:

Bei diesem Ansatz wird der überrepräsentierte Wert verteilt, während der seltenere Wert stabil bleibt, wodurch große Äquivalenzklassen reduziert werden, ohne dass unnötiges Auffällen entsteht.

Beispiel 3: Bekannte aktuelle Werte in einem großen Bereich

Sie haben eine Datenbank mit Vornamen in den Vereinigte Staaten. Ein relativ kleiner Satz gebräuchlicher Namen (z. B. die 500 häufigsten Namen) kommt weitaus häufiger vor als die anderen.

Dieser hybride Ansatz zielt auf bekannte wichtige Werte ab und hält gleichzeitig die Partitionierung für die meisten Namen einfach und vorhersehbar.

Diese Beispiele zeigen, wie Partitionierungsschemata an unterschiedliche Dateneigenschaften angepasst werden können. In den meisten Fällen ist eine zufällige Verteilung ausreichend, aber die Einbeziehung von Fachwissen kann den Datenschutz und die Leistung weiter verbessern, wenn sie sorgfältig angewendet wird.

Die Länge des Beacons wird berechnet

Die Länge des Beacons wird in Bit angegeben und bestimmt, wie viele Bits der HMAC-Ausgabe nach der Kürzung erhalten bleiben. Die empfohlene Länge hängt davon ab, wie die Werte innerhalb der einzelnen Partitionen verteilt sind, ob die Daten korrelierte Werte enthalten und von Ihren Sicherheits- und Leistungsanforderungen. Wenn ein Datensatz nach Anwendung eines geeigneten Partitionierungsschemas ungefähr einheitlich ist, können Sie einfache Gleichungen und Optimierungsverfahren verwenden, um die effektive Beacon-Länge zu schätzen. Diese Gleichungen liefern eine Schätzung der durchschnittlichen Anzahl falsch positiver Ergebnisse, die ein Beacon erzeugen kann, sie garantieren jedoch nicht, dass für jeden Einzelwert im Datensatz eine bestimmte Anzahl von Fehlalarmen angegeben wird. Der erste Schritt besteht darin, die Population zu schätzen.

Schätzen Sie die Population

Bei der Grundgesamtheit handelt es sich um die erwartete Anzahl von Einzelwerten in dem Feld, aus dem Ihr Standard-Beacon erstellt wurde, nicht um die erwartete Gesamtanzahl der im Feld gespeicherten Werte. Stellen Sie sich zum Beispiel ein verschlüsseltes Room Feld vor, das den Ort von Mitarbeiterversammlungen identifiziert. Es wird erwartet, dass das Room Feld insgesamt 100.000 Werte speichert, aber es gibt nur 50 verschiedene Räume, die Mitarbeiter für Besprechungen reservieren können. Das bedeutet, dass die Population 50 beträgt, weil es nur 50 mögliche Einzelwerte gibt, die in dem Room Feld gespeichert werden können.

Achten Sie bei der Schätzung Ihrer Population darauf, das prognostizierte Wachstum des Datensatzes zu berücksichtigen. Nachdem Sie mit dem Beacon neue Datensätze geschrieben haben, können Sie die Länge des Beacons nicht mehr aktualisieren. Überprüfen Sie Ihr Bedrohungsmodell und alle vorhandenen Datenbanklösungen, um eine Schätzung der Anzahl der Einzelwerte zu erstellen, die dieses Feld voraussichtlich in den nächsten fünf Jahren speichern wird.

Ihre Population muss nicht genau sein. Identifizieren Sie zunächst die Anzahl der Einzelwerte in Ihrer aktuellen Datenbank, oder schätzen Sie die Anzahl der Einzelwerte, die Sie voraussichtlich im ersten Jahr speichern werden. Verwenden Sie als Nächstes die folgenden Fragen, um das prognostizierte Wachstum der Einzelwerte in den nächsten fünf Jahren zu ermitteln.

Der Unterschied zwischen 50.000 und 60.000 Einzelwerten ist nicht signifikant und beide führen zu derselben empfohlenen Beacon-Länge. Der Unterschied zwischen 50.000 und 500.000 Einzelwerten wirkt sich jedoch erheblich auf die empfohlene Beacon-Länge aus.

Erwägen Sie, öffentliche Daten zur Häufigkeit gängiger Datentypen wie Postleitzahlen oder Nachnamen zu überprüfen. In den Vereinigte Staaten gibt es beispielsweise 41.707 Postleitzahlen. Die von Ihnen verwendete Population sollte proportional zu Ihrer eigenen Datenbank sein. Wenn das ZIPCode Feld in Ihrer Datenbank Daten aus den gesamten Vereinigte Staaten enthält, können Sie Ihre Bevölkerung als 41.707 definieren, auch wenn das ZIPCode Feld derzeit keine 41.707 Einzelwerte enthält. Wenn das ZIPCode Feld in Ihrer Datenbank nur Daten aus einem einzigen Bundesstaat enthält und immer nur Daten aus einem einzigen Bundesstaat enthalten wird, können Sie Ihre Bevölkerung als die Gesamtzahl der Postleitzahlen in diesem Bundesstaat statt als 41.704 definieren.

Die Länge des Beacons anhand der Bevölkerungsgröße wird berechnet

Wenn Ihre Daten innerhalb jeder Partition ungefähr gleichmäßig verteilt sind und keine korrelierten Werte enthalten, können Sie mithilfe einer einfachen, auf der Population basierenden Formel eine angemessene Beacon-Länge schätzen.

Sei p die Populationsgröße des Beacons, d. h. die Anzahl der unterschiedlichen Klartextwerte, aus denen der Beacon innerhalb einer einzigen Partition erstellt wird. Ein üblicher Ausgangspunkt für die Beacon-Länge b (in Bits) ist:

b = log₂(p) − 1
  

Mit dieser Formel wird eine nicht zu vernachlässigende Kollisionswahrscheinlichkeit beibehalten und gleichzeitig die Anzahl falsch positiver Ergebnisse überschaubar gehalten. Durch die Subtraktion eines Bits vom Logarithmus wird sichergestellt, dass mehrere unterschiedliche Werte demselben Beacon zugeordnet werden, was zur Begrenzung von Frequenzverlusten beiträgt und die Anonymität unterstützt.

Diese Berechnung liefert eine Schätzung des durchschnittlichen Kollisionsverhaltens im gesamten Datensatz. Sie garantiert nicht, dass jeder Wert dieselbe Anzahl falsch positiver Ergebnisse hervorruft, noch berücksichtigt sie schiefe Verteilungen, korrelierte Werte oder kontradiktorische Datenmuster.

Verwenden Sie diese Formel als erste Richtlinie und nicht als strikte Anforderung. Überprüfen Sie die resultierende Konfiguration immer anhand Ihres Bedrohungsmodells, Ihrer Leistungserwartungen und der beobachteten Datenmerkmale und passen Sie die Länge des Beacons oder die Anzahl der Partitionen nach Bedarf an.

Thema für Fortgeschrittene zur Länge von Beacons

Als erfahrener Benutzer haben Sie mehr Flexibilität bei der Auswahl einer geeigneten Beacon-Länge für Ihre Lösung. Sie müssen eine Länge wählen, die die Vertraulichkeit Ihrer Daten angemessen schützt und gleichzeitig unnötige Auswirkungen auf die Abfrageleistung minimiert. Der Sicherheitsgrad, den ein Beacon gewährleistet, hängt von der Verteilung Ihres Datensatzes und der Korrelation der Felder ab, aus denen Ihre Beacons aufgebaut sind.

Wenn Ihr Datensatz ungefähr gleichmäßig verteilt ist, können Sie die folgenden Gleichungen und Verfahren verwenden, um die für Ihre Implementierung geeignete Beacon-Länge abzuschätzen. Diese Gleichungen liefern eine Schätzung der durchschnittlichen Anzahl falsch positiver Ergebnisse, die ein Beacon erzeugen kann, sie garantieren jedoch nicht, dass für jeden Einzelwert im Datensatz eine bestimmte Anzahl von Fehlalarmen angegeben wird. In den folgenden Themen wird davon ausgegangen, dass Ihre Beacons gleichmäßig verteilt sind und keine korrelierten Daten enthalten.

Beispiel für eine erweiterte Beacon-Länge

Stellen Sie sich eine Datenbank vor, die das unit Feld als ENCRYPT_AND_SIGN in den kryptografischen Aktionen markiert hat. Um einen Standard-Beacon für das unit Feld zu konfigurieren, müssen wir die erwartete Anzahl von Fehlalarmen und die Länge des Beacons für das Feld ermitteln. unit