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.

Durchsuchbare Verschlüsselung

Mit der durchsuchbaren Verschlüsselung können Sie verschlüsselte Datensätze durchsuchen, ohne die gesamte Datenbank entschlüsseln zu müssen. Dies wird mithilfe von Beacons erreicht, die eine Zuordnung zwischen dem Klartextwert, der in ein Feld geschrieben wird, und dem verschlüsselten Wert, der tatsächlich in Ihrer Datenbank gespeichert ist, erstellen. Das AWS Database Encryption SDK speichert den Beacon in einem neuen Feld, das es dem Datensatz hinzufügt. Je nach verwendetem Beacontyp können Sie nach Ihren verschlüsselten Daten nach exakten Übereinstimmungen suchen oder individuellere komplexe Abfragen durchführen.

Ein Beacon ist ein gekürztes HMAC-Tag ( Hash-Based Message Authentication Code), das einen Klartext-Feldwert einer verschlüsselten, durchsuchbaren Kennung zuordnet. Wenn Sie einen 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 einen HMAC. Bei dieser HMAC-Ausgabe handelt es sich um eine 1:1 -Übereinstimmung mit dem Klartextwert dieses Felds. Das SDK kürzt die HMAC-Ausgabe absichtlich, sodass mehrere unterschiedliche Klartextwerte auf demselben Beacon kollidieren. Diese Kollisionen (Fehlalarme) schränken die Fähigkeit eines nicht autorisierten Benutzers ein, vertrauliche Informationen aus Frequenzmustern abzuleiten. Wenn Sie einen Beacon abfragen, filtert das AWS Database Encryption SDK diese Fehlalarme automatisch heraus und gibt das Klartextergebnis Ihrer Abfrage zurück. Um dieses Problem des Frequenzverlusts weiter zu lösen, werden Beacons partitioniert, sodass identische Klartextwerte partitionsübergreifend unterschiedliche Beacon-Werte erzeugen können. Wenn die Tabelle nur eine einzige Partition verwendet, entspricht dieses Verhalten natürlich herkömmlichen, nicht partitionierten Beacons.

Die durchschnittliche Anzahl von Fehlalarmen für jeden Beacon hängt von der verbleibenden Beacon-Länge nach der Kürzung und der Anzahl der Partitionen ab. Hilfe bei der Bestimmung der geeigneten Beacon-Länge für Ihre Implementierung finden Sie unter Bestimmung der Beacon-Länge.

Sind Beacons das Richtige für meinen Datensatz?

Die Verwendung von Beacons zur Durchführung von Abfragen verschlüsselter Daten reduziert die Leistungskosten, die mit clientseitig verschlüsselten Datenbanken verbunden sind. Wenn Sie Beacons verwenden, gibt es einen inhärenten Kompromiss zwischen der Effizienz Ihrer Abfragen und der Menge an Informationen, die über die Verteilung Ihrer Daten preisgegeben werden. Der Beacon verändert den verschlüsselten Zustand des Feldes nicht. Wenn Sie ein Feld mit dem AWS Database Encryption SDK verschlüsseln und signieren, wird der Klartextwert des Felds niemals der Datenbank zugänglich gemacht. Die Datenbank speichert den zufälligen, verschlüsselten Wert des Felds.

Beacons werden zusammen mit den verschlüsselten Feldern gespeichert, aus denen sie berechnet werden. Das heißt, selbst wenn ein nicht autorisierter Benutzer die Klartextwerte eines verschlüsselten Felds nicht einsehen kann, kann er möglicherweise statistische Analysen der Beacons durchführen, um mehr über die Verteilung Ihres Datensatzes zu erfahren und im Extremfall die Klartextwerte zu identifizieren, denen ein Beacon zugeordnet ist. Die richtige Konfiguration der Beacons ist unerlässlich, um diese Risiken zu minimieren. Durch die Auswahl einer geeigneten Beacon-Länge und eines geeigneten Partitionierungsschemas wird die Vertraulichkeit gewahrt, indem ausreichend Kollisionen gewährleistet und frequenzbasierte Angriffe durch die Begrenzung der Wertekonzentration in einem einzelnen Beacon abgeschwächt werden.

In vielen praktischen Szenarien kann eine gut gewählte Konfiguration diese konkurrierenden Ziele ausgleichen. Eine durchsuchbare Verschlüsselung kann jedoch möglicherweise nicht für jeden Datensatz das gewünschte Maß an Sicherheit und Leistung bieten.

Bevor Sie Beacons konfigurieren, sollten Sie Ihr Bedrohungsmodell, Ihre Sicherheits- und Leistungsanforderungen sorgfältig prüfen und die Einzigartigkeitsmerkmale Ihres Datensatzes berücksichtigen, um festzustellen, ob eine durchsuchbare Verschlüsselung die richtige Wahl ist.

Selbst wenn Ihr Datensatz korrelierte Felder enthält oder eine ungleichmäßige Verteilung aufweist, können Sie möglicherweise Beacons erstellen, die die Vertraulichkeit Ihres Datensatzes wahren, indem Sie kürzere Beacon-Längen verwenden. Die Beacon-Länge garantiert jedoch nicht, dass jeder eindeutige Wert in Ihrem Datensatz zu einer Reihe von Fehlalarmen führt, wodurch die Menge an Unterscheidungsinformationen, die über Ihren Datensatz preisgegeben werden, effektiv minimiert wird. Mit der Beacon-Länge wird lediglich die durchschnittliche Anzahl der generierten Fehlalarme geschätzt. Je ungleichmäßiger Ihr Datensatz verteilt ist, desto weniger effektiv ist die Beacon-Länge bei der Bestimmung der durchschnittlichen Anzahl der erzeugten Fehlalarme.

Prüfen Sie sorgfältig die Verteilung der Felder, die Sie als Beaconizer verwenden möchten, und ermitteln Sie, wie stark die Kürzung erforderlich ist, um Ihre Sicherheitsanforderungen zu erfüllen. Bei den folgenden Themen in diesem Kapitel wird davon ausgegangen, dass die Beacon-Werte innerhalb jeder Partition gleichmäßig verteilt sind und dass die zugrunde liegenden Daten keine Korrelationen enthalten, die diese Annahmen schwächen würden.

Durchsuchbares Verschlüsselungsszenario

Das folgende Beispiel zeigt eine durchsuchbare Verschlüsselungslösung und veranschaulicht die in diesem Kapitel erörterten Kernkonzepte. In diesem Szenario kommen bestimmte Feldwerte sehr häufig vor, was zu großen Äquivalenzklassen und vermehrten Frequenzverlusten führen würde, wenn eine einzelne Partition verwendet würde. Um diesem Problem zu begegnen, werden in der Konfiguration mehrere Partitionen verwendet, sodass häufig vorkommende Werte gleichmäßiger verteilt werden, wodurch Datenverlust reduziert wird und gleichzeitig die Möglichkeit erhalten bleibt, effiziente Gleichheitssuchen durchzuführen.

Stellen Sie sich eine Datenbank mit dem Namen vorEmployees, in der Mitarbeiterdaten eines Unternehmens erfasst werden. Jeder Datensatz in der Datenbank enthält Felder namens EmployeeID, LastNameFirstName, und Address. Jedes Feld in der Employees Datenbank wird durch den Primärschlüssel EmployeeID identifiziert.

Im Folgenden finden Sie ein Beispiel für einen Klartext-Datensatz in der Datenbank.

{
    "EmployeeID": 101,
    "LastName": "Jones",
    "FirstName": "Mary",
    "Address": {
                "Street": "123 Main",
                "City": "Anytown",
                "State": "OH",
                "ZIPCode": 12345
    }
}

Wenn Sie ENCRYPT_AND_SIGN in Ihren kryptografischen Aktionen die FirstName Felder LastName und als markiert haben, werden die Werte in diesen Feldern lokal verschlüsselt, bevor sie in die Datenbank hochgeladen werden. Die verschlüsselten Daten, die hochgeladen werden, sind vollständig randomisiert. Die Datenbank erkennt diese Daten nicht als geschützt. Sie erkennt nur typische Dateneinträge. Das bedeutet, dass der Datensatz, der tatsächlich in der Datenbank gespeichert ist, wie folgt aussehen könnte.

{
    "PersonID": 101,
    "LastName": "1d76e94a2063578637d51371b363c9682bad926cbd",
    "FirstName": "21d6d54b0aaabc411e9f9b34b6d53aa4ef3b0a35",
    "Address": {
                "Street": "123 Main",
                "City": "Anytown",
                "State": "OH",
                "ZIPCode": 12345
    }
}

Wenn Sie die Datenbank nach exakten Übereinstimmungen im LastName Feld abfragen müssen, konfigurieren Sie einen Standard-Beacon, der so benannt ist, LastNamedass er die in das LastName Feld geschriebenen Klartextwerte den in der Datenbank gespeicherten verschlüsselten Werten zuordnet.

Dieser Beacon berechnet HMACs anhand der Klartextwerte im Feld. LastName Jede HMAC-Ausgabe wird gekürzt, sodass sie nicht mehr exakt mit dem Klartext-Wert übereinstimmt. Der vollständige Hash und der gekürzte Hash für Jones könnten beispielsweise wie folgt aussehen.

Vollständiger Hash

2aa4e9b404c68182562b6ec761fcca5306de527826a69468885e59dc36d0c3f824bdd44cab45526f70a2a18322000264f5451acf75f9f817e2b35099d408c833

Verkürzter Hash

b35099d408c833

In einem Datensatz mit vielen Mitarbeitern kommen bestimmte Nachnamen wie Jones, Smith oder Johnson möglicherweise weitaus häufiger vor als andere. Um Frequenzverluste zu reduzieren und die Größe der Beacon-Äquivalenzklassen zu begrenzen, sollten Sie den LastNameBeacon so konfigurieren, dass er mehr als eine Partition verwendet.

Wenn Partitionen aktiviert sind, wird jedes Element beim Schreiben einer Partition zugewiesen, und die Partitionsnummer wird in die Beacon-Ableitung übernommen. Das hat zur Folge, dass Mitarbeiter mit demselben Nachnamen partitionsübergreifend unterschiedlichen Beacon-Werten zugeordnet werden. Dadurch werden häufig verwendete Namen auf mehrere Partitionen verteilt, wodurch die Überrepräsentation einzelner Beacon-Werte reduziert wird.

Nachdem der Standard-Beacon konfiguriert wurde, können Sie Gleichheitssuchen für das Feld durchführen. LastName Wenn Sie beispielsweise nach suchen möchtenJones, verwenden Sie den LastNameBeacon, um die folgende Abfrage durchzuführen.

LastName = Jones

Bei der Abfrage nach einem bestimmten häufig verwendeten Nachnamen, z. B. Jones, sollte die Anwendung mithilfe des Beacons eine Abfrage pro Partition ausgeben. LastName Das AWS Database Encryption SDK entschlüsselt dann die Ergebnisse und filtert automatisch alle Fehlalarme heraus, sodass die korrekten Klartext-Datensätze zurückgegeben werden.