View a markdown version of this page

Leuchtfeuer - AWS SDK für Datenbankverschlüsselung
Grundlegendes zur partitionsübergreifenden Beacon-AbleitungBeacon-Typen

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.

Leuchtfeuer

Unsere clientseitige Verschlüsselungsbibliothek wurde in AWS Database Encryption SDK umbenannt. Dieses Entwicklerhandbuch enthält weiterhin Informationen zum DynamoDB Encryption Client.

Ein Beacon ist ein gekürztes HMAC-Tag ( Hash-Based Message Authentication Code), das einen Klartext-Feldwert einer verschlüsselten, durchsuchbaren Kennung zuordnet, die zusammen mit den verschlüsselten Daten in Ihrer Datenbank gespeichert wird. Der Beacon ändert den verschlüsselten Status des Felds nicht. Wenn Sie einen Wert in ein Feld schreiben, das für durchsuchbare Verschlüsselung konfiguriert ist, berechnet das AWS Database Encryption SDK einen HMAC über den Klartext-Wert und leitet den Beacon im Kontext einer Partition ab. Der vollständige HMAC entspricht eindeutig dem Klartext-Wert, aber das SDK kürzt die Ausgabe absichtlich, sodass mehrere unterschiedliche Klartext-Werte demselben Beacon zugeordnet werden können. Diese Kollisionen (Fehlalarme) schränken die Fähigkeit eines nicht autorisierten Benutzers ein, Unterscheidungsmerkmale über den zugrunde liegenden Klartext abzuleiten.

Anmerkung

Ein Hash-based Message Authentication Code (HMAC) ist eine verschlüsselte kryptografische Hash-Funktion, die häufig verwendet wird, um Integrität und Authentizität zu gewährleisten. In durchsuchbaren Verschlüsselungssystemen wird HMAC häufig verwendet, um Beacons deterministisch aus Klartextwerten abzuleiten, sodass sie indexiert und abgefragt werden können.

Ein HMAC in voller Länge ist deterministisch: Für einen bestimmten Schlüssel erzeugt derselbe Klartextwert immer denselben Beacon. Dieser Determinismus führt zu einer Eins-zu-Eins-Zuordnung zwischen Klartextwerten und Beacons, wobei die ursprüngliche Häufigkeitsverteilung der Daten erhalten bleibt. Alle Datensätze, die denselben Klartext-Wert verwenden, werden demselben Beacon zugeordnet und bilden daher eine Äquivalenzklasse. Die Größe jeder Äquivalenzklasse spiegelt direkt wider, wie häufig der entsprechende Klartextwert im Datensatz vorkommt.

Diese Frequenzerhaltung ermöglicht Angriffe zur Frequenzanalyse, bei denen ein Beobachter wahrscheinliche Klartextwerte ableitet, indem er die beobachteten Beacon-Frequenzen mit bekannten oder erwarteten Datenverteilungen korreliert.

Um Angriffe mit Frequenzanalysen abzuwehren, leitet das SDK Beacons mithilfe von Kürzung und Partitionierung ab. Das Kürzen des HMAC führt zu kontrollierten Kollisionen, sodass nicht alle Datensätze innerhalb einer Äquivalenzklasse unbedingt denselben Beacon-Wert haben. Darüber hinaus ermöglicht die Einbindung einer Partitions-ID in die Beacon-Ableitung, dass identische Klartextwerte unterschiedlichen Beacons partitionsübergreifend zugeordnet werden können. Zusammen sorgen diese Techniken für eine größere Zufälligkeit bei ungleichmäßig verteilten Datensätzen und sorgen gleichzeitig für ein korrektes und effizientes Abfrageverhalten.

Beacons können nur aus markierten Feldern oder SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT in Ihren ENCRYPT_AND_SIGN kryptografischen SIGN_ONLY Aktionen erstellt werden. Der Beacon selbst ist weder signiert noch verschlüsselt. Sie können kein Beacon mit markierten Feldern erstellen. DO_NOTHING

Nachdem Sie Ihre Beacons konfiguriert haben, müssen Sie für jedes Beacon einen sekundären Index konfigurieren, bevor Sie in den verschlüsselten Feldern suchen können. Weitere Informationen finden Sie unter Konfiguration sekundärer Indizes mit Beacons.

Grundlegendes zur partitionsübergreifenden Beacon-Ableitung

Die Partitionierung ist ein zentraler Bestandteil der Beacon-Konfiguration und gilt für alle Beacons, auch für solche, die eine einzelne Partition verwenden. Dieses Modell gewährleistet eine konsistente und vorwärtskompatible Beacon-Ableitung für alle Daten und ermöglicht es Ihnen, die Anzahl der Partitionen im Laufe der Zeit zu erhöhen, wenn sich das Datenvolumen oder die Verteilung ändert. Auf diese Weise können Sie Frequenzverluste reduzieren und den Schutz für ungleichmäßig verteilte Datensätze verbessern, ohne bestehende Elemente neu schreiben zu müssen.

Partitionen führen zu kontrollierter Zufälligkeit, indem sie Elemente auf mehrere logische Gruppen verteilen. Dadurch werden Frequenzverluste reduziert, die Größe der Beacon-Äquivalenzklassen begrenzt und die Sicherheit und der Datenschutz für Attribute mit schiefen Verteilungen verbessert.

Wenn ein Element einer Partition zugewiesen wird, wird die Partitionsnummer in die Beacon-Ableitung einbezogen. Innerhalb derselben Partition erzeugen identische Klartextwerte dasselbe Beacon, wobei die Semantik der Gleichheitssuche erhalten bleibt. In verschiedenen Partitionen erzeugt derselbe Klartext-Wert unterschiedliche Beacon-Werte. Dies unterteilt große Äquivalenzklassen in kleinere Gruppen pro Partition und trägt dazu bei, die allgemeine Häufigkeitsverteilung von Beacons zu verringern.

Sie haben die volle Kontrolle darüber, wie jedes Datenbankelement einer Partition zugewiesen wird. Elemente können deterministisch in bestimmten Partitionen platziert werden, oder sie können nach dem Zufallsprinzip verteilt werden, um ungleichmäßige Datenverteilungen auszugleichen. Die zufällige Zuweisung ist besonders nützlich für Werte mit hoher Frequenz, da sie diese Werte auf mehrere Partitionen verteilt und die sichtbare Konzentration in einer einzelnen Partition reduziert. Die deterministische Zuweisung kann verwendet werden, wenn aufgrund von Domänenwissen bestimmte Werte auf weniger Partitionen beschränkt werden sollten.

Die Partitions-ID ist im verschlüsselten Datensatz nicht enthalten. Stattdessen wird die Partitionsnummer in den Beacon-Ableitungsprozess integriert und zusammen mit dem Klartextwert gehasht, sodass sie nicht durch Untersuchung der verschlüsselten Daten oder des Beacons selbst abgeleitet werden kann. Dieses Design stellt sicher, dass Partitionszuweisungen vertraulich bleiben und gleichzeitig die Vorteile partitionierter Beacons in Bezug auf Verteilung und Datenschutz erhalten bleiben.

Auswirkungen der Partitionierung auf Abfragen

Die Partitionierung wirkt sich darauf aus, wie Query Operationen ausgeführt werden. Da DynamoDB-Abfragen eine exakte Übereinstimmung mit dem indizierten Beacon-Wert erfordern und sich die Beacon-Werte von Partition zu Partition unterscheiden, muss der Aufrufer jede Partition unabhängig abfragen. Wenn eine Tabelle Partitionen hat: N

  • Das Abrufen aller übereinstimmenden Elemente erfordert N separate Abfragen.

  • Nur Query ist betroffen.

  • Scanund der Get Betrieb verhält sich wie zuvor.

Der Grund ist struktureller Natur: Scan liest alle Elemente und Get arbeitet mit einem bestimmten Schlüssel; Query hängt nur von der exakten Gleichheit im Index ab, der partitionsspezifisch wird.

Anmerkung

Fan-out bezieht sich auf die Anzahl der DynamoDB-Abfragen, die ausgegeben werden müssen, um eine einzelne logische Anforderung zu erfüllen, wenn partitionierte Beacons verwendet werden. Das System bietet ein begrenztes Fan-Out, d. h. die maximale Anzahl von Abfragen auf Partitionsebene ist fest und auf der Grundlage der konfigurierten Anzahl von Partitionen vorhersehbar.

Überlegungen zur Leistung

Die Verwendung von Partitionen wirkt sich auf die Anzahl der DynamoDB-Abfragen aus, die pro logischer Anforderung erforderlich sind. Die Auswirkungen auf die Leistung hängen von der erwarteten Ergebnisgröße ab:

  • Große Ergebnismengen: Wenn Abfragen viele Seiten zurückgeben, verursachen die zusätzlichen Abfragen auf Partitionsebene nur wenig Mehraufwand.

  • Single-item Suchvorgänge: Wenn eine Anfrage normalerweise ein Element zurückgibt und fünf Partitionen konfiguriert sind, werden fünf Abfragen ausgegeben, von denen vier keine Ergebnisse liefern, was zu einer nahezu linearen Verlangsamung führt.

  • Reduzierte Lokalität: Elemente können auf mehrere Partitionen verteilt sein, wodurch sich die Abrufzeit verlängert.

Da jede Partition eine zusätzliche Abfrage auslöst, ist Fan-Out ein wichtiger Faktor bei der Planung von Leistung und Kapazität.

Leistungsvorteile

Trotz des zusätzlichen Abfrageaufwands können Partitionen die Leistung in bestimmten Szenarien verbessern:

  • Reduzierung großer Äquivalenzklassen: Wenn ein seltener Wert ein abgeschnittenes Beacon mit einem häufig vorkommenden Wert gemeinsam hat, müssen Abfragen für den seltenen Wert viele irrelevante Treffer verarbeiten. Durch die Partitionierung wird die Größe jeder Äquivalenzklasse begrenzt und dieser Overhead reduziert.

  • Unterstützung längerer Beacon-Längen: Durch die Konfiguration von mehr Partitionen können längere Beacon-Längen verwendet werden, wodurch die Falsch-Positiv-Raten gesenkt und der Umfang der nach der Entschlüsselung erforderlichen Filterung reduziert wird.

Beacon-Typen

Der Typ des Beacons, den Sie konfigurieren, bestimmt die Art der Abfragen, die Sie ausführen können. Es gibt zwei Arten von Beacons, die durchsuchbare Verschlüsselung unterstützen. Standard-Beacons führen Gleichheitssuchen durch. Zusammengesetzte Beacons kombinieren wörtliche Klartext-Zeichenketten und Standard-Beacons, um komplexe Datenbankoperationen durchzuführen.

Standard-Beacons

Standard-Beacons sind die einfachste Methode, eine durchsuchbare Verschlüsselung in Ihrer Datenbank zu implementieren. Sie können nur Gleichheitssuchen für ein einzelnes verschlüsseltes oder virtuelles Feld durchführen. Informationen zur Konfiguration von Standard-Beacons finden Sie unter Konfiguration von Standard-Beacons. Sie können auch Partitionen mit Beacons verwenden, um Zufälligkeit zu fördern, wenn die zugrunde liegenden Daten ungleichmäßig verteilt sind.

Im Folgenden werden wichtige Konzepte für Standard-Beacons beschrieben.

Quelle des Beacons

Das Feld, aus dem ein Standard-Beacon erstellt wird, wird als Beacon-Quelle bezeichnet. Es identifiziert den Standort der Daten, die der Beacon für die Kartierung benötigt. Die Beacon-Quelle kann entweder ein verschlüsseltes Feld oder ein virtuelles Feld sein. Die Beacon-Quelle in jedem Standard-Beacon muss eindeutig sein. Sie können nicht zwei Beacons mit derselben Beacon-Quelle konfigurieren.

Standard-Beacons können verwendet werden, um Gleichheitssuchen für ein verschlüsseltes oder virtuelles Feld durchzuführen. Sie können auch verwendet werden, um zusammengesetzte Beacons zu erstellen, um komplexere Datenbankoperationen durchzuführen. Um Ihnen bei der Organisation und Verwaltung von Standard-Beacons zu helfen, bietet das AWS Database Encryption SDK die folgenden optionalen Beacon-Stile, die den Verwendungszweck eines Standard-Beacons definieren. Weitere Informationen finden Sie unter Beacon-Stile definieren.

Sie können ein Standard-Beacon erstellen, das Gleichheitssuchen für ein einzelnes verschlüsseltes Feld durchführt, oder Sie können ein Standard-Beacon erstellen, das Gleichheitssuchen bei der Verkettung mehrererENCRYPT_AND_SIGN, und SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT -Felder durchführtSIGN_ONLY, indem Sie ein virtuelles Feld erstellen.

Virtuelle Felder

Ein virtuelles Feld ist ein konzeptionelles Feld, das aus einem oder mehreren Quellfeldern besteht. Beim Erstellen eines virtuellen Felds wird kein neues Feld in Ihren Datensatz geschrieben. Das virtuelle Feld wird nicht explizit in Ihrer Datenbank gespeichert. Es wird in der Standard-Beacon-Konfiguration verwendet, um dem Beacon Anweisungen zu geben, wie ein bestimmtes Segment eines Feldes identifiziert oder mehrere Felder innerhalb eines Datensatzes verkettet werden kann, um eine bestimmte Abfrage durchzuführen. Ein virtuelles Feld erfordert mindestens ein verschlüsseltes Feld.

Anmerkung

Das folgende Beispiel zeigt, welche Arten von Transformationen und Abfragen Sie mit einem virtuellen Feld durchführen können. In der Anwendung entsprechen die in diesem Beispiel verwendeten Beispielfelder möglicherweise nicht den Empfehlungen zur Verteilung und Korrelationseindeutigkeit für Beacons.

Wenn Sie beispielsweise Gleichheitssuchen für die Verkettung von FirstName und LastName -Feldern durchführen möchten, können Sie eines der folgenden virtuellen Felder erstellen.

  • Ein virtuelles NameTag Feld, das aus dem ersten Buchstaben des FirstName Felds, gefolgt vom Feld, gebildet wird, alles in Kleinbuchstaben. LastName Mit diesem virtuellen Feld können Sie Abfragen NameTag=mjones durchführen.

  • Ein virtuelles LastFirst Feld, das aus dem LastName Feld, gefolgt vom FirstName Feld, aufgebaut wird. Mit diesem virtuellen Feld können Sie Abfragen durchführenLastFirst=JonesMary.

Oder, wenn Sie Gleichheitssuchen für ein bestimmtes Segment eines verschlüsselten Feldes durchführen möchten, erstellen Sie ein virtuelles Feld, das das Segment identifiziert, das Sie abfragen möchten.

Wenn Sie beispielsweise ein verschlüsseltes IPAddress Feld anhand der ersten drei Segmente der IP-Adresse abfragen möchten, erstellen Sie das folgende virtuelle Feld.

  • Ein virtuelles IPSegment Feld, das aus erstellt wurdeSegments(‘.’, 0, 3). Mit diesem virtuellen Feld können Sie Abfragen durchführenIPSegment=192.0.2. Die Abfrage gibt alle Datensätze zurück, deren IPAddress Wert mit „192.0.2" beginnt.

Virtuelle Felder müssen eindeutig sein. Zwei virtuelle Felder können nicht aus exakt denselben Quellfeldern erstellt werden.

Hilfe zur Konfiguration virtueller Felder und der Beacons, die sie verwenden, finden Sie unter Virtuelles Feld erstellen.

Zusammengesetzte Beacons

Zusammengesetzte Beacons erstellen Indizes, die die Abfrageleistung verbessern und es Ihnen ermöglichen, komplexere Datenbankoperationen durchzuführen. Sie können zusammengesetzte Beacons verwenden, um literale Klartextzeichenfolgen und Standardbeacons zu kombinieren, um komplexe Abfragen an verschlüsselten Datensätzen durchzuführen, z. B. um zwei verschiedene Datensatztypen aus einem einzigen Index abzufragen oder um eine Kombination von Feldern mit einem Sortierschlüssel abzufragen. Weitere Lösungsbeispiele für zusammengesetzte Beacons finden Sie unter Wählen Sie einen Beacon-Typ.

Zusammengesetzte Beacons können aus Standardbeacons oder einer Kombination aus Standardbeacons und signierten Feldern erstellt werden. Sie bestehen aus einer Liste von Teilen. Alle zusammengesetzten Beacons sollten eine Liste verschlüsselter Teile enthalten, die die im Beacon enthaltenen ENCRYPT_AND_SIGN Felder identifiziert. Jedes ENCRYPT_AND_SIGN Feld muss durch einen Standard-Beacon identifiziert werden. Komplexere zusammengesetzte Beacons können auch eine Liste von signierten Teilen enthalten, die den Klartext SIGN_ONLY oder die SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT Felder identifizieren, die im Beacon enthalten sind, und eine Liste von Konstruktorteilen, die alle Möglichkeiten angeben, wie der Compound Beacon die Felder zusammenstellen kann.

Anmerkung

Das AWS Database Encryption SDK unterstützt auch signierte Beacons, die vollständig aus Klartext und Feldern konfiguriert werden können. SIGN_ONLY SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT Signierte Beacons sind eine Art von zusammengesetzten Beacons, die signierte, aber nicht verschlüsselte Felder indexieren und komplexe Abfragen in diesen ausführen. Weitere Informationen finden Sie unter Signierte Beacons erstellen.

Hilfe zur Konfiguration von zusammengesetzten Beacons finden Sie unter Konfiguration von zusammengesetzten Beacons.

Die Art und Weise, wie Sie Ihren Compound Beacon konfigurieren, bestimmt, welche Arten von Abfragen er ausführen kann. Sie können beispielsweise einige verschlüsselte und signierte Teile optional machen, um mehr Flexibilität bei Ihren Abfragen zu gewährleisten. Weitere Informationen zu den Abfragetypen, die Compound Beacons ausführen können, finden Sie unterBeacons abfragen.