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 **** | | | --- | | Unsere clientseitige Verschlüsselungsbibliothek wurde in AWS Database Encryption SDK umbenannt. Dieses Entwicklerhandbuch enthält weiterhin Informationen zum [DynamoDB Encryption Client](legacy-dynamodb-encryption-client.md). | 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. **Anmerkung** [Die durchsuchbare Verschlüsselung im AWS Database Encryption SDK unterscheidet sich von der durchsuchbaren symmetrischen Verschlüsselung, die in der akademischen Forschung definiert wurde, z. B. durchsuchbare symmetrische Verschlüsselung.](https://dl.acm.org/doi/10.1145/1180405.1180417) Ein Beacon ist ein gekürztes HMAC-Tag (Hash-Based Message Authentication Code), das eine Zuordnung zwischen Klartext- und verschlüsselten Werten eines Felds erstellt. 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 einen HMAC-Wert über dem Klartext-Wert. Bei dieser HMAC-Ausgabe handelt es sich um eine 1:1 -Übereinstimmung mit dem Klartextwert dieses Felds. Die HMAC-Ausgabe wird gekürzt, sodass mehrere unterschiedliche Klartextwerte demselben gekürzten HMAC-Tag zugeordnet werden. Diese Fehlalarme schränken die Fähigkeit eines nicht autorisierten Benutzers ein, charakteristische Informationen über den Klartext-Wert zu identifizieren. Wenn Sie einen Beacon abfragen, filtert das AWS Database Encryption SDK diese Fehlalarme automatisch heraus und gibt das Klartextergebnis Ihrer Abfrage zurück. Die durchschnittliche Anzahl der für jeden Beacon generierten Fehlalarme wird durch die Länge des Beacons bestimmt, die nach der Kürzung noch übrig ist. [Hilfe zur Bestimmung der geeigneten Beacon-Länge für Ihre Implementierung finden Sie unter Bestimmung der Beacon-Länge.](choosing-beacon-length.md) **Anmerkung** Die durchsuchbare Verschlüsselung ist so konzipiert, dass sie in neuen, nicht aufgefüllten Datenbanken implementiert werden kann. Jedes Beacon, das in einer vorhandenen Datenbank konfiguriert ist, ordnet nur neue Datensätze zu, die in die Datenbank hochgeladen wurden. Es gibt keine Möglichkeit für ein Beacon, bestehende Daten zuzuordnen. **Topics** + [Sind Beacons das Richtige für meinen Datensatz?](#are-beacons-right-for-me) + [Durchsuchbares Verschlüsselungsszenario](#beacon-overview-example) ## 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 Art und Weise, wie Sie Ihre Beacons konfigurieren, kann diese Risiken mindern. Insbesondere [die Wahl der richtigen Beacon-Länge](choosing-beacon-length.md) kann Ihnen helfen, die Vertraulichkeit Ihres Datensatzes zu wahren. **Sicherheit versus Leistung** + Je kürzer die Länge des Beacons, desto besser ist die Sicherheit gewährleistet. + Je länger die Länge des Beacons ist, desto mehr Leistung bleibt erhalten. Eine durchsuchbare Verschlüsselung kann möglicherweise nicht das gewünschte Leistungs- und Sicherheitsniveau für alle Datensätze bieten. Überprüfen Sie Ihr Bedrohungsmodell, Ihre Sicherheits- und Leistungsanforderungen, bevor Sie Beacons konfigurieren. Beachten Sie die folgenden Anforderungen an die Eindeutigkeit von Datensätzen, wenn Sie entscheiden, ob eine durchsuchbare Verschlüsselung für Ihren Datensatz geeignet ist. **Verteilung** Wie viel Sicherheit durch ein Beacon gewährleistet wird, hängt von der Verteilung Ihres Datensatzes ab. Wenn Sie ein verschlüsseltes Feld für durchsuchbare Verschlüsselung konfigurieren, berechnet das AWS Database Encryption SDK anhand der in dieses Feld geschriebenen Klartextwerte einen HMAC. Alle für ein bestimmtes Feld berechneten Beacons werden mit demselben Schlüssel berechnet, mit Ausnahme von Multitenant-Datenbanken, die für jeden Mandanten einen eigenen Schlüssel verwenden. Das heißt, wenn derselbe Klartextwert mehrmals in das Feld geschrieben wird, wird für jede Instanz dieses Klartextwerts derselbe HMAC-Tag erstellt. Sie sollten vermeiden, Beacons aus Feldern zu erstellen, die sehr häufig vorkommende Werte enthalten. Stellen Sie sich zum Beispiel eine Datenbank vor, in der die Adressen aller Einwohner des Bundesstaates Illinois gespeichert sind. Wenn Sie aus dem verschlüsselten `City` Feld einen Beacon konstruieren, wird der über „Chicago“ berechnete Beacon aufgrund des hohen Prozentsatzes der Bevölkerung von Illinois, der in Chicago lebt, überrepräsentiert sein. Selbst wenn ein nicht autorisierter Benutzer nur die verschlüsselten Werte und Beacon-Werte lesen kann, kann er möglicherweise feststellen, welche Datensätze Daten für Einwohner von Chicago enthalten, wenn das Beacon diese Verteilung beibehält. Um die Menge an identifizierenden Informationen, die über Ihre Verteilung preisgegeben werden, zu minimieren, müssen Sie Ihr Beacon ausreichend kürzen. Die Länge des Beacons, die erforderlich ist, um diese ungleichmäßige Verteilung zu verbergen, ist mit erheblichen Leistungseinbußen verbunden, die möglicherweise nicht den Anforderungen Ihrer Anwendung entsprechen. Sie müssen die Verteilung Ihres Datensatzes sorgfältig analysieren, um festzustellen, wie stark Ihre Beacons gekürzt werden müssen. Die Länge der Beacons, die nach der Kürzung noch übrig ist, steht in direktem Zusammenhang mit der Menge an statistischen Informationen, die über Ihre Verteilung ermittelt werden können. Möglicherweise müssen Sie kürzere Beacon-Längen wählen, um die Menge an Unterscheidungsinformationen, die über Ihren Datensatz preisgegeben werden, ausreichend zu minimieren. In extremen Fällen können Sie keine Beacon-Länge für einen ungleichmäßig verteilten Datensatz berechnen, der ein effektives Gleichgewicht zwischen Leistung und Sicherheit gewährleistet. Sie sollten beispielsweise keinen Beacon aus einem Feld erstellen, in dem das Ergebnis eines medizinischen Tests für eine seltene Krankheit gespeichert ist. Da davon ausgegangen wird, dass `NEGATIVE` Ergebnisse innerhalb des Datensatzes deutlich häufiger vorkommen, können `POSITIVE` Ergebnisse leicht anhand ihrer Seltenheit identifiziert werden. Es ist sehr schwierig, die Verteilung zu verbergen, wenn das Feld nur zwei mögliche Werte hat. Wenn Sie eine Beacon-Länge verwenden, die kurz genug ist, um die Verteilung zu verbergen, werden alle Klartextwerte demselben HMAC-Tag zugeordnet. Wenn Sie eine längere Beacon-Länge verwenden, ist es offensichtlich, welche Beacons den Klartext-Werten zugeordnet werden. `POSITIVE` **Korrelation** Wir empfehlen dringend, dass Sie vermeiden, unterschiedliche Beacons aus Feldern mit korrelierten Werten zu erstellen. Beacons, die aus korrelierten Feldern erstellt wurden, erfordern kürzere Beacon-Längen, um die Menge an Informationen, die über die Verteilung der einzelnen Datensätze an einen nicht autorisierten Benutzer preisgegeben werden, ausreichend zu minimieren. Sie müssen Ihren Datensatz sorgfältig analysieren, einschließlich seiner Entropie und der gemeinsamen Verteilung der korrelierten Werte, um festzustellen, wie stark Ihre Beacons gekürzt werden müssen. Wenn die resultierende Beacon-Länge nicht Ihren Leistungsanforderungen entspricht, sind Beacons möglicherweise nicht für Ihren Datensatz geeignet. Sie sollten beispielsweise nicht zwei separate Beacons aus `City` und `ZIPCode` -Feldern erstellen, da die Postleitzahl wahrscheinlich nur einer Stadt zugeordnet ist. In der Regel schränken die von einem Beacon generierten Fehlalarme die Fähigkeit eines nicht autorisierten Benutzers ein, charakteristische Informationen über Ihren Datensatz zu identifizieren. Die Korrelation zwischen den `ZIPCode` Feldern `City` und bedeutet jedoch, dass ein nicht autorisierter Benutzer leicht erkennen kann, welche Ergebnisse falsch positive Ergebnisse sind, und die verschiedenen Postleitzahlen unterscheiden kann. Sie sollten auch vermeiden, Beacons aus Feldern zu erstellen, die dieselben Klartextwerte enthalten. Beispielsweise sollten Sie kein Beacon aus `preferredPhone` Feldern `mobilePhone` und erstellen, da diese wahrscheinlich dieselben Werte enthalten. Wenn Sie aus beiden Feldern unterschiedliche Beacons erstellen, erstellt das AWS Database Encryption SDK die Beacons für jedes Feld unter unterschiedlichen Schlüsseln. Dies führt zu zwei verschiedenen HMAC-Tags für denselben Klartext-Wert. Es ist unwahrscheinlich, dass die beiden unterschiedlichen Beacons dieselben Fehlalarme haben, und ein nicht autorisierter Benutzer kann möglicherweise verschiedene Telefonnummern unterscheiden. 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. Berücksichtigen Sie sorgfältig die Verteilung der Felder, aus denen Sie Beacons erstellen, und überlegen Sie, um wie viel Sie die Beacon-Länge kürzen müssen, um Ihre Sicherheitsanforderungen zu erfüllen. Bei den folgenden Themen in diesem Kapitel wird davon ausgegangen, dass Ihre Beacons gleichmäßig verteilt sind und keine korrelierten Daten enthalten. ## Durchsuchbares Verschlüsselungsszenario Das folgende Beispiel zeigt eine einfache durchsuchbare Verschlüsselungslösung. In der Anwendung entsprechen die in diesem Beispiel verwendeten Beispielfelder möglicherweise nicht den Empfehlungen zur Verteilung und Korrelation zur Eindeutigkeit von Beacons. Sie können dieses Beispiel als Referenz verwenden, wenn Sie in diesem Kapitel mehr über die Konzepte der durchsuchbaren Verschlüsselung lesen. Stellen Sie sich eine Datenbank mit dem Namen vor`Employees`, die Mitarbeiterdaten eines Unternehmens verfolgt. Jeder Datensatz in der Datenbank enthält Felder namens *EmployeeID*, *LastName*FirstName**, 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](concepts.md#crypt-actions) 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](configure-beacons.md#config-standard-beacons), der so benannt ist, *LastName*dass er die in das `LastName` Feld geschriebenen Klartextwerte den in der Datenbank gespeicherten verschlüsselten Werten zuordnet. Dieser Beacon berechnet anhand HMACs der Klartextwerte im Feld. `LastName` Jede HMAC-Ausgabe wird gekürzt, sodass sie nicht mehr exakt dem Klartext-Wert entspricht. 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` Nachdem der Standard-Beacon konfiguriert wurde, können Sie Gleichheitssuchen für das `LastName` Feld durchführen. Wenn Sie beispielsweise nach suchen möchten`Jones`, verwenden Sie den *LastName*Beacon, um die folgende Abfrage durchzuführen. ``` LastName = Jones ``` Das AWS Database Encryption SDK filtert automatisch die Fehlalarme heraus und gibt das Klartextergebnis Ihrer Abfrage zurück. # Leuchtfeuer **** | | | --- | | Unsere clientseitige Verschlüsselungsbibliothek wurde in AWS Database Encryption SDK umbenannt. Dieses Entwicklerhandbuch enthält weiterhin Informationen zum [DynamoDB Encryption Client](legacy-dynamodb-encryption-client.md). | Ein Beacon ist ein gekürztes HMAC-Tag (Hash-Based Message Authentication Code), das eine Zuordnung zwischen dem Klartextwert, der in ein Feld geschrieben wird, und dem verschlüsselten Wert, der tatsächlich in Ihrer Datenbank gespeichert ist, erstellt. Der Beacon ändert den verschlüsselten Status des Feldes nicht. Der Beacon berechnet anhand des Klartextwerts des Felds einen HMAC und speichert ihn zusammen mit dem verschlüsselten Wert. Bei dieser HMAC-Ausgabe handelt es sich um eine 1:1 -Übereinstimmung mit dem Klartextwert dieses Felds. Die HMAC-Ausgabe wird gekürzt, sodass mehrere unterschiedliche Klartextwerte demselben gekürzten HMAC-Tag zugeordnet werden. Diese Fehlalarme schränken die Fähigkeit eines nicht autorisierten Benutzers ein, charakteristische Informationen über den Klartext-Wert zu identifizieren. [Beacons können nur aus Feldern erstellt werden, die markiert sind `ENCRYPT_AND_SIGN``SIGN_ONLY`, oder `SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT` in Ihren kryptografischen Aktionen enthalten sind.](concepts.md#crypt-actions) Der Beacon selbst ist weder signiert noch verschlüsselt. Sie können kein Beacon mit markierten Feldern erstellen. `DO_NOTHING` 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. Nachdem Sie [Ihre Beacons konfiguriert haben, müssen Sie für jedes Beacon](configure-beacons.md) 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](ddb-searchable-encryption.md#ddb-beacon-indexes). **Topics** + [Standard-Beacons](#standard-beacon-overview) + [Zusammengesetzte Beacons](#compound-beacon-overview) ## 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](configure-beacons.md#config-standard-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 für komplexere Datenbankoperationen zu erstellen. 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](configure-beacons.md#define-beacon-styles). 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 mehrerer`ENCRYPT_AND_SIGN`, und `SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT` -Felder durchführt`SIGN_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. 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](searchable-encryption.md#searchable-encryption-distribution) und [Korrelationseindeutigkeit](searchable-encryption.md#searchable-encryption-correlated-values) 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ühren`LastFirst=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, aufgebaut aus`Segments(‘.’, 0, 3)`. Mit diesem virtuellen Feld können Sie Abfragen durchführen`IPSegment=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](configure-beacons.md#create-virtual-field). ## 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.](choosing-beacon-type.md) 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](configure-beacons.md#encrypted-parts) 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](configure-beacons.md#signed-parts) 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](configure-beacons.md#constructor-parts), 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](configure.md#signed-beacons). Hilfe zur Konfiguration von zusammengesetzten Beacons finden Sie unter [Konfiguration von](configure-beacons.md#config-compound-beacons) 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 unter[Beacons abfragen](using-beacons.md#querying-beacons). # Leuchtfeuer planen **** | | | --- | | Unsere clientseitige Verschlüsselungsbibliothek wurde in AWS Database Encryption SDK umbenannt. Dieses Entwicklerhandbuch enthält weiterhin Informationen zum [DynamoDB Encryption Client](legacy-dynamodb-encryption-client.md). | Beacons sind so konzipiert, dass sie in neuen, nicht aufgefüllten Datenbanken implementiert werden können. Jedes Beacon, das in einer vorhandenen Datenbank konfiguriert ist, ordnet nur neue Datensätze zu, die in die Datenbank geschrieben wurden. Beacons werden anhand des Klartextwerts eines Felds berechnet. Sobald das Feld verschlüsselt ist, kann das Beacon keine vorhandenen Daten zuordnen. Nachdem Sie neue Datensätze mit einem Beacon geschrieben haben, können Sie die Konfiguration des Beacons nicht mehr aktualisieren. Sie können jedoch neue Beacons für neue Felder hinzufügen, die Sie Ihrem Datensatz hinzufügen. Um eine durchsuchbare Verschlüsselung zu implementieren, müssen Sie den [AWS KMS hierarchischen Schlüsselbund](use-hierarchical-keyring.md) verwenden, um die Datenschlüssel zu generieren, zu verschlüsseln und zu entschlüsseln, die zum Schutz Ihrer Datensätze verwendet werden. Weitere Informationen finden Sie unter [Verwendung des hierarchischen Schlüsselbunds für durchsuchbare Verschlüsselung](use-hierarchical-keyring.md#searchable-encryption-hierarchical-keyrings). Bevor Sie [Beacons](searchable-encryption.md#beacon-definition) für durchsuchbare Verschlüsselung konfigurieren können, müssen Sie Ihre Verschlüsselungsanforderungen, Datenbankzugriffsmuster und Ihr Bedrohungsmodell überprüfen, um die beste Lösung für Ihre Datenbank zu finden. Der [Typ des Beacons, den](beacons.md) Sie konfigurieren, bestimmt die Art der Abfragen, die Sie ausführen können. Die [Beacon-Länge](choosing-beacon-length.md), die Sie in der Standard-Beacon-Konfiguration angeben, bestimmt die erwartete Anzahl von Fehlalarmen, die für einen bestimmten Beacon erzeugt werden. Wir empfehlen dringend, die Arten von Abfragen, die Sie durchführen müssen, zu identifizieren und zu planen, bevor Sie Ihre Beacons konfigurieren. Sobald Sie ein Beacon verwendet haben, kann die Konfiguration nicht mehr aktualisiert werden. Wir empfehlen dringend, dass Sie die folgenden Aufgaben überprüfen und ausführen, bevor Sie Beacons konfigurieren. + [Stellen Sie fest, ob Beacons für Ihren Datensatz geeignet sind](searchable-encryption.md#are-beacons-right-for-me) + [Wählen Sie einen Beacon-Typ](choosing-beacon-type.md) + [Wählen Sie eine Beacon-Länge](choosing-beacon-length.md) + [Wählen Sie einen Beacon-Namen](choosing-beacon-name.md) Beachten Sie bei der Planung der durchsuchbaren Verschlüsselungslösung für Ihre Datenbank die folgenden Anforderungen an die Eindeutigkeit von Beacons. + **[Jeder Standard-Beacon muss über eine eindeutige Beacon-Quelle verfügen](beacons.md#beacon-source)** Es können nicht mehrere Standard-Beacons aus demselben verschlüsselten oder virtuellen Feld erstellt werden. Ein einziger Standard-Beacon kann jedoch verwendet werden, um mehrere zusammengesetzte Beacons zu erstellen. + **Vermeiden Sie es, ein virtuelles Feld mit Quellfeldern zu erstellen, die sich mit vorhandenen Standard-Beacons überschneiden** Die Konstruktion eines Standard-Beacons aus einem virtuellen Feld, das ein Quellfeld enthält, das zur Erstellung eines anderen Standard-Beacons verwendet wurde, kann die Sicherheit beider Beacons verringern. Weitere Informationen finden Sie unter [Sicherheitsüberlegungen für virtuelle Felder](configure-beacons.md#virtual-field-considerations). ## Überlegungen zu Mehrmandantendatenbanken Um Beacons abzufragen, die in einer Mehrmandantendatenbank konfiguriert sind, müssen Sie das Feld, das die Daten speichert, die dem Mandanten `branch-key-id` zugeordnet sind, der den Datensatz verschlüsselt hat, in Ihre Abfrage aufnehmen. Sie definieren dieses Feld, wenn Sie [die Beacon-Schlüsselquelle definieren](use-hierarchical-keyring.md#beacon-key-source). Damit die Abfrage erfolgreich ist, muss der Wert in diesem Feld die entsprechenden Beacon-Schlüsselmaterialien identifizieren, die für die Neuberechnung des Beacons erforderlich sind. Bevor Sie Ihre Beacons konfigurieren, müssen Sie entscheiden, wie Sie sie in Ihre Abfragen einbeziehen möchten. `branch-key-id` Weitere Informationen zu den verschiedenen Möglichkeiten, wie Sie die `branch-key-id` in Ihre Abfragen einbeziehen können, finden Sie unter[Abfragen von Beacons in einer mandantenfähigen Datenbank](searchable-encryption-multitenant.md#query-multitenant-beacons). # Auswahl eines Beacon-Typs **** | | | --- | | Unsere clientseitige Verschlüsselungsbibliothek wurde in AWS Database Encryption SDK umbenannt. Dieses Entwicklerhandbuch enthält weiterhin Informationen zum [DynamoDB Encryption Client](legacy-dynamodb-encryption-client.md). | *Mit durchsuchbarer Verschlüsselung können Sie verschlüsselte Datensätze durchsuchen, indem Sie die Klartextwerte in einem verschlüsselten Feld einem Beacon zuordnen.* Der Typ des Beacons, den Sie konfigurieren, bestimmt die Art der Abfragen, die Sie ausführen können. Wir empfehlen dringend, die Arten von Abfragen, die Sie ausführen müssen, zu identifizieren und zu planen, bevor Sie Ihre Beacons konfigurieren. Nachdem Sie [Ihre Beacons konfiguriert](configure-beacons.md) 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](ddb-searchable-encryption.md#ddb-beacon-indexes). Beacons erstellen eine Zuordnung zwischen dem Klartextwert, der in ein Feld geschrieben wird, und dem verschlüsselten Wert, der tatsächlich in Ihrer Datenbank gespeichert ist. Sie können die Werte von zwei Standard-Beacons nicht vergleichen, selbst wenn sie denselben zugrunde liegenden Klartext enthalten. Die beiden Standard-Beacons erzeugen zwei verschiedene HMAC-Tags für dieselben Klartext-Werte. Daher können Standard-Beacons die folgenden Abfragen nicht ausführen. + `beacon1 = beacon2` + `beacon1 IN (beacon2)` + `value IN (beacon1, beacon2, ...)` + `CONTAINS(beacon1, beacon2)` Sie können die obigen Abfragen nur durchführen, wenn Sie die [signierten Teile](configure-beacons.md#signed-parts) von zusammengesetzten Beacons vergleichen, mit Ausnahme des `CONTAINS` Operators, den Sie mit zusammengesetzten Beacons verwenden können, um den gesamten Wert eines verschlüsselten oder signierten Felds zu identifizieren, das der zusammengestellte Beacon enthält. Wenn Sie signierte Teile vergleichen, können Sie optional das Präfix eines [verschlüsselten Teils angeben](configure-beacons.md#encrypted-parts), nicht jedoch den verschlüsselten Wert eines Felds. Weitere Informationen zu den Abfragetypen, die Standard- und Verbundbeacons ausführen können, finden Sie unter [Abfragen](using-beacons.md#querying-beacons) von Beacons. Ziehen Sie bei der Überprüfung Ihrer Datenbankzugriffsmuster die folgenden durchsuchbaren Verschlüsselungslösungen in Betracht. In den folgenden Beispielen wird definiert, welcher Beacon konfiguriert werden muss, um unterschiedliche Verschlüsselungs- und Abfrageanforderungen zu erfüllen. ## Standard-Beacons [Standard-Beacons](beacons.md#standard-beacon-overview) können nur Gleichheitssuchen durchführen. Sie können Standard-Beacons verwenden, um die folgenden Abfragen durchzuführen. ### Fragen Sie ein einzelnes verschlüsseltes Feld ab Wenn Sie Datensätze identifizieren möchten, die einen bestimmten Wert für ein verschlüsseltes Feld enthalten, erstellen Sie einen Standard-Beacon. #### Beispiele Stellen Sie sich für das folgende Beispiel eine Datenbank mit dem Namen vor`UnitInspection`, die Inspektionsdaten für eine Produktionsanlage verfolgt. Jeder Datensatz in der Datenbank enthält Felder mit den Namen `work_id``inspection_date`,`inspector_id_last4`, und`unit`. Die vollständige Inspektor-ID ist eine Zahl zwischen 0 und 99.999.999. Um jedoch sicherzustellen, dass der Datensatz gleichmäßig verteilt ist, speichert The `inspector_id_last4` nur die letzten vier Ziffern der Inspektor-ID. Jedes Feld in der Datenbank wird durch den Primärschlüssel `work_id` identifiziert. Die `unit` Felder `inspector_id_last4` und sind `ENCRYPT_AND_SIGN` in den [kryptografischen Aktionen](concepts.md#crypt-actions) markiert. Das Folgende ist ein Beispiel für einen Klartext-Eintrag in der `UnitInspection` Datenbank. ``` { "work_id": "1c7fcff3-6e74-41a8-b7f7-925dc039830b", "inspection_date": 2023-06-07, "inspector_id_last4": 8744, "unit": 229304973450 } ``` **Fragen Sie ein einzelnes verschlüsseltes Feld in einem Datensatz ab** Wenn das `inspector_id_last4` Feld verschlüsselt werden muss, Sie es aber trotzdem nach exakten Übereinstimmungen abfragen müssen, erstellen Sie aus dem `inspector_id_last4` Feld ein Standard-Beacon. Verwenden Sie dann den Standard-Beacon, um einen sekundären Index zu erstellen. Sie können diesen sekundären Index verwenden, um das verschlüsselte `inspector_id_last4` Feld abzufragen. Hilfe zur Konfiguration von Standard-Beacons finden Sie unter [Konfiguration von Standard-Beacons](configure-beacons.md#config-standard-beacons). ### Fragen Sie ein virtuelles Feld ab Ein [virtuelles Feld](beacons.md#virtual-field) ist ein konzeptionelles Feld, das aus einem oder mehreren Quellfeldern besteht. Wenn Sie Gleichheitssuchen für ein bestimmtes Segment eines verschlüsselten Felds oder Gleichheitssuchen für die Verkettung mehrerer Felder durchführen möchten, konstruieren Sie ein Standard-Beacon aus einem virtuellen Feld. Alle virtuellen Felder müssen mindestens ein verschlüsseltes Quellfeld enthalten. #### Beispiele In den folgenden Beispielen werden virtuelle Felder für die `Employees` Datenbank erstellt. Im Folgenden finden Sie ein Beispiel für einen Klartext-Datensatz in der `Employees` Datenbank. ``` { "EmployeeID": 101, "SSN": 000-00-0000, "LastName": "Jones", "FirstName": "Mary", "Address": { "Street": "123 Main", "City": "Anytown", "State": "OH", "ZIPCode": 12345 } } ``` **Fragen Sie ein Segment eines verschlüsselten Felds ab** In diesem Beispiel ist das `SSN` Feld verschlüsselt. Wenn Sie das `SSN` Feld mit den letzten vier Ziffern einer Sozialversicherungsnummer abfragen möchten, erstellen Sie ein virtuelles Feld, das das Segment identifiziert, das Sie abfragen möchten. Ein virtuelles `Last4SSN` Feld, das aus erstellt wurde, `Suffix(4)` ermöglicht es Ihnen, Abfragen durchzuführen`Last4SSN=0000`. Verwenden Sie dieses virtuelle Feld, um einen Standard-Beacon zu erstellen. Verwenden Sie dann den Standard-Beacon, um einen sekundären Index zu erstellen. Sie können diesen sekundären Index verwenden, um das virtuelle Feld abzufragen. Diese Abfrage gibt alle Datensätze zurück, `SSN` deren Wert mit den letzten vier von Ihnen angegebenen Ziffern endet. **Fragen Sie die Verkettung mehrerer Felder ab** Das folgende Beispiel zeigt, welche Arten von Transformationen und Abfragen Sie mit einem virtuellen Feld ausführen können. In der Anwendung entsprechen die in diesem Beispiel verwendeten Beispielfelder möglicherweise nicht den Empfehlungen zur [Verteilung](searchable-encryption.md#searchable-encryption-distribution) und [Korrelationseindeutigkeit](searchable-encryption.md#searchable-encryption-correlated-values) für Beacons. Wenn Sie Gleichheitssuchen für eine Verkettung von `FirstName` und `LastName` -Feldern durchführen möchten, können Sie ein virtuelles `NameTag` Feld erstellen, das aus dem ersten Buchstaben des Felds, gefolgt von dem `FirstName` Feld, gebildet wird, alles in Kleinbuchstaben. `LastName` Verwenden Sie dieses virtuelle Feld, um einen Standard-Beacon zu erstellen. Verwenden Sie dann den Standard-Beacon, um einen sekundären Index zu erstellen. Sie können diesen sekundären Index verwenden, um das virtuelle Feld abzufragen`NameTag=mjones`. Mindestens eines der Quellfelder muss verschlüsselt sein. Entweder `FirstName` oder `LastName` könnte verschlüsselt werden, oder beide könnten verschlüsselt sein. Alle Klartext-Quellfelder müssen `SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT` in Ihren [kryptografischen `SIGN_ONLY`](concepts.md#crypt-actions) Aktionen als oder gekennzeichnet sein. Hilfe zur Konfiguration virtueller Felder und der Beacons, die sie verwenden, finden Sie unter [Virtuelles Feld erstellen](configure-beacons.md#create-virtual-field). ## Zusammengesetzte Beacons [Zusammengesetzte Beacons](beacons.md#compound-beacon-overview) erstellen einen Index aus wörtlichen Klartext-Zeichenketten und Standard-Beacons, um komplexe Datenbankoperationen durchzuführen. Sie können zusammengesetzte Beacons verwenden, um die folgenden Abfragen durchzuführen. ### Fragen Sie eine Kombination verschlüsselter Felder in einem einzelnen Index ab Wenn Sie eine Kombination von verschlüsselten Feldern in einem einzelnen Index abfragen müssen, erstellen Sie einen Verbundbeacon, der die einzelnen Standard-Beacons, die für jedes verschlüsselte Feld erstellt wurden, zu einem einzigen Index kombiniert. Nachdem Sie den Compound Beacon konfiguriert haben, können Sie einen sekundären Index erstellen, der den Compound Beacon als Partitionsschlüssel für Abfragen mit exakter Übereinstimmung oder mit einem Sortierschlüssel für komplexere Abfragen angibt. Sekundäre Indizes, die den Compound Beacon als Sortierschlüssel angeben, können Abfragen mit exakter Übereinstimmung und individuellere komplexe Abfragen ausführen. #### Beispiele Stellen Sie sich für die folgenden Beispiele eine Datenbank mit dem Namen vor`UnitInspection`, die Inspektionsdaten für eine Produktionsanlage verfolgt. Jeder Datensatz in der Datenbank enthält Felder mit den Namen `work_id``inspection_date`,`inspector_id_last4`, und`unit`. Die vollständige Inspektor-ID ist eine Zahl zwischen 0 und 99.999.999. Um jedoch sicherzustellen, dass der Datensatz gleichmäßig verteilt ist, speichert The `inspector_id_last4` nur die letzten vier Ziffern der Inspektor-ID. Jedes Feld in der Datenbank wird durch den Primärschlüssel `work_id` identifiziert. Die `unit` Felder `inspector_id_last4` und sind `ENCRYPT_AND_SIGN` in den [kryptografischen Aktionen](concepts.md#crypt-actions) markiert. Das Folgende ist ein Beispiel für einen Klartext-Eintrag in der `UnitInspection` Datenbank. ``` { "work_id": "1c7fcff3-6e74-41a8-b7f7-925dc039830b", "inspection_date": 2023-06-07, "inspector_id_last4": 8744, "unit": 229304973450 } ``` **Führen Sie Gleichheitssuchen in einer Kombination von verschlüsselten Feldern durch** Wenn Sie die `UnitInspection` Datenbank nach exakten Übereinstimmungen abfragen möchten`inspector_id_last4.unit`, erstellen Sie zunächst unterschiedliche Standard-Beacons für die `unit` Felder `inspector_id_last4` und. Erstellen Sie dann aus den beiden Standard-Beacons ein zusammengesetztes Beacon. Nachdem Sie den Compound Beacon konfiguriert haben, erstellen Sie einen sekundären Index, der den Compound Beacon als Partitionsschlüssel angibt. Verwenden Sie diesen sekundären Index, um nach exakten Übereinstimmungen zu suchen. `inspector_id_last4.unit` Sie könnten diesen Beacon beispielsweise abfragen, um eine Liste von Inspektionen zu finden, die ein Inspektor für eine bestimmte Einheit durchgeführt hat. **Führen Sie komplexe Abfragen für eine Kombination von verschlüsselten Feldern durch** Wenn Sie die `UnitInspection` Datenbank für `inspector_id_last4` und abfragen möchten`inspector_id_last4.unit`, erstellen Sie zunächst unterschiedliche Standardbeacons für die `unit` Felder `inspector_id_last4` und. Erstellen Sie dann ein zusammengesetztes Beacon aus den beiden Standard-Beacons. Nachdem Sie den zusammengesetzten Beacon konfiguriert haben, erstellen Sie einen sekundären Index, der den zusammengesetzten Beacon als Sortierschlüssel angibt. Verwenden Sie diesen sekundären Index, um die `UnitInspection` Datenbank nach Einträgen abzufragen, die mit einem bestimmten Inspektor beginnen, oder fragen Sie die Datenbank nach einer Liste aller Einheiten innerhalb eines bestimmten Einheiten-ID-Bereichs ab, die von einem bestimmten Inspektor geprüft wurden. Sie können auch nach exakten Übereinstimmungen suchen für`inspector_id_last4.unit`. Hilfe zur Konfiguration von zusammengesetzten Beacons finden Sie unter [Konfiguration von zusammengesetzten Beacons](configure-beacons.md#config-compound-beacons). ### Fragen Sie eine Kombination aus verschlüsselten Feldern und Klartextfeldern in einem einzigen Index ab Wenn Sie eine Kombination aus verschlüsselten Feldern und Klartextfeldern in einem einzigen Index abfragen müssen, erstellen Sie einen zusammengesetzten Beacon, der einzelne Standard-Beacons und Klartextfelder zu einem einzigen Index kombiniert. [Die Klartextfelder, die zur Erstellung des Verbund-Beacons verwendet werden, müssen markiert `SIGN_ONLY` oder in Ihren kryptografischen Aktionen enthalten sein. `SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT`](concepts.md#crypt-actions) Nachdem Sie den Compound Beacon konfiguriert haben, können Sie einen sekundären Index erstellen, der den Compound Beacon als Partitionsschlüssel für exakt passende Abfragen oder mit einem Sortierschlüssel für komplexere Abfragen angibt. Sekundäre Indizes, die den Compound Beacon als Sortierschlüssel angeben, können Abfragen mit exakter Übereinstimmung und individuellere komplexe Abfragen ausführen. #### Beispiele Stellen Sie sich für die folgenden Beispiele eine Datenbank mit dem Namen vor`UnitInspection`, die Inspektionsdaten für eine Produktionsanlage verfolgt. Jeder Datensatz in der Datenbank enthält Felder mit den Namen `work_id``inspection_date`,`inspector_id_last4`, und`unit`. Die vollständige Inspektor-ID ist eine Zahl zwischen 0 und 99.999.999. Um jedoch sicherzustellen, dass der Datensatz gleichmäßig verteilt ist, speichert The `inspector_id_last4` nur die letzten vier Ziffern der Inspektor-ID. Jedes Feld in der Datenbank wird durch den Primärschlüssel `work_id` identifiziert. Die `unit` Felder `inspector_id_last4` und sind `ENCRYPT_AND_SIGN` in den [kryptografischen Aktionen](concepts.md#crypt-actions) markiert. Das Folgende ist ein Beispiel für einen Klartext-Eintrag in der `UnitInspection` Datenbank. ``` { "work_id": "1c7fcff3-6e74-41a8-b7f7-925dc039830b", "inspection_date": 2023-06-07, "inspector_id_last4": 8744, "unit": 229304973450 } ``` **Führen Sie Gleichheitssuchen in einer Kombination von Feldern durch** Wenn Sie die `UnitInspection` Datenbank nach Inspektionen abfragen möchten, die von einem bestimmten Inspektor an einem bestimmten Datum durchgeführt wurden, erstellen Sie zunächst einen Standard-Beacon für das `inspector_id_last4` Feld. Das `inspector_id_last4` Feld ist `ENCRYPT_AND_SIGN` in den [kryptografischen Aktionen](concepts.md#crypt-actions) markiert. Alle verschlüsselten Teile benötigen einen eigenen Standard-Beacon. Das `inspection_date` Feld ist markiert `SIGN_ONLY` und benötigt keinen Standard-Beacon. Erstellen Sie als Nächstes ein Verbundsignal aus dem `inspection_date` Feld und dem `inspector_id_last4` Standardbeacon. Nachdem Sie den Compound Beacon konfiguriert haben, erstellen Sie einen sekundären Index, der den Compound Beacon als Partitionsschlüssel angibt. Verwenden Sie diesen sekundären Index, um die Datenbanken nach Datensätzen abzufragen, die exakt mit einem bestimmten Inspektor und einem bestimmten Inspektionsdatum übereinstimmen. Beispielsweise können Sie die Datenbank nach einer Liste aller Inspektionen abfragen, die der Inspektor, dessen ID auf endet, an einem bestimmten Datum `8744` durchgeführt hat. **Führen Sie komplexe Abfragen für eine Kombination von Feldern durch** Wenn Sie die Datenbank nach Inspektionen abfragen möchten, die innerhalb eines bestimmten `inspection_date` Bereichs durchgeführt wurden, oder die Datenbank nach Inspektionen abfragen möchten, die für einen bestimmten `inspection_date` eingeschränkten Wert von `inspector_id_last4` oder durchgeführt wurden`inspector_id_last4.unit`, erstellen Sie zunächst separate Standard-Beacons für die Felder `inspector_id_last4` und`unit`. Erstellen Sie dann einen Verbundbeacon aus dem `inspection_date` Klartextfeld und den beiden Standard-Beacons. Nachdem Sie den zusammengesetzten Beacon konfiguriert haben, erstellen Sie einen sekundären Index, der den zusammengesetzten Beacon als Sortierschlüssel angibt. Verwenden Sie diesen sekundären Index, um Abfragen für Inspektionen durchzuführen, die an bestimmten Terminen von einem bestimmten Inspektor durchgeführt wurden. Sie können beispielsweise die Datenbank nach einer Liste aller am selben Tag inspizierten Einheiten abfragen. Oder Sie können die Datenbank nach einer Liste aller Inspektionen abfragen, die an einer bestimmten Einheit zwischen einem bestimmten Zeitraum von Inspektionsterminen durchgeführt wurden. Hilfe zur Konfiguration von zusammengesetzten Beacons finden Sie unter [Konfiguration von zusammengesetzten Beacons](configure-beacons.md#config-compound-beacons). # Wahl einer Beacon-Länge **** | | | --- | | Unsere clientseitige Verschlüsselungsbibliothek wurde in AWS Database Encryption SDK umbenannt. Dieses Entwicklerhandbuch enthält weiterhin Informationen zum [DynamoDB Encryption Client](legacy-dynamodb-encryption-client.md). | 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 einen HMAC-Wert über dem Klartext-Wert. Bei dieser HMAC-Ausgabe handelt es sich um eine 1:1 -Übereinstimmung mit dem Klartextwert dieses Felds. Die HMAC-Ausgabe wird gekürzt, sodass mehrere unterschiedliche Klartextwerte demselben gekürzten HMAC-Tag zugeordnet werden. Diese Kollisionen oder *Fehlalarme* schränken die Fähigkeit eines nicht autorisierten Benutzers ein, charakteristische Informationen über den Klartext-Wert zu identifizieren. Die durchschnittliche Anzahl der für jeden Beacon generierten Fehlalarme wird durch die Länge des Beacons bestimmt, die nach der Kürzung noch übrig ist. Sie müssen die Beacon-Länge nur definieren, wenn Sie Standard-Beacons konfigurieren. Verbund-Beacons verwenden die Beacon-Längen der Standard-Beacons, aus denen sie aufgebaut sind. Der Beacon ändert den verschlüsselten Zustand 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. Das Ziel der durchsuchbaren Verschlüsselung besteht darin, die mit clientseitig verschlüsselten Datenbanken verbundenen Leistungskosten zu reduzieren, 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 der richtigen Beacon-Länge kann dazu beitragen, diese Risiken zu minimieren und die Vertraulichkeit Ihrer Verteilung 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, muss ein Beacon mehr Fehlalarme generieren. Eine erhöhte Vertraulichkeit führt zu einer verringerten Abfrageleistung. **Sicherheit versus Leistung** + Eine **zu lange Beacon-Länge erzeugt zu** wenige Fehlalarme und kann aussagekräftige Informationen über die Verteilung Ihres Datensatzes preisgeben. + Eine **zu kurze Beacon-Länge erzeugt zu** viele Fehlalarme und erhöht die Leistungseinbußen bei Abfragen, da dafür ein umfassenderer Scan der Datenbank erforderlich ist. Bei der Bestimmung der geeigneten Beacon-Länge für Ihre Lösung müssen Sie eine Länge wählen, die die Sicherheit Ihrer Daten angemessen gewährleistet, ohne die Leistung Ihrer Abfragen mehr als unbedingt erforderlich zu beeinträchtigen. Der Sicherheitsgrad, den ein Beacon gewährleistet, hängt von der [Verteilung](searchable-encryption.md#searchable-encryption-distribution) Ihres Datensatzes und der [Korrelation](searchable-encryption.md#searchable-encryption-correlated-values) der Felder ab, aus denen Ihre Beacons aufgebaut sind. In den folgenden Themen wird davon ausgegangen, dass Ihre Beacons gleichmäßig verteilt sind und keine korrelierten Daten enthalten. **Topics** + [Berechnung der Beacon-Länge](#calculate-beacon-length) + [Beispiel](#beacon-length-example) ## Berechnung der Beacon-Länge Die Länge des Beacons wird in *Bits* definiert und bezieht sich auf die Anzahl der Bits des HMAC-Tags, die nach der Kürzung beibehalten werden. Die empfohlene Beacon-Länge hängt von der Verteilung des Datensatzes, dem Vorhandensein korrelierter Werte und Ihren spezifischen Sicherheits- und Leistungsanforderungen ab. Wenn Ihr Datensatz gleichmäßig verteilt ist, können Sie die folgenden Gleichungen und Verfahren verwenden, um die beste Beacon-Länge für Ihre Implementierung zu ermitteln. Mit diesen Gleichungen wird nur die durchschnittliche Anzahl falsch positiver Ergebnisse geschätzt, die der Beacon erzeugt. Sie garantieren nicht, dass jeder einzelne Wert in Ihrem Datensatz eine bestimmte Anzahl falsch positiver Ergebnisse erzeugt. **Anmerkung** Die Wirksamkeit dieser Gleichungen hängt von der Verteilung Ihres Datensatzes ab. Wenn Ihr Datensatz nicht gleichmäßig verteilt ist, finden Sie weitere Informationen unter[Sind Beacons das Richtige für meinen Datensatz?](searchable-encryption.md#are-beacons-right-for-me). Generell gilt: Je weiter Ihr Datensatz von einer gleichmäßigen Verteilung entfernt ist, desto mehr müssen Sie Ihre Beacon-Länge verkürzen. 1. **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. **Anmerkung** Wenn Ihr Standard-Beacon aus einem [virtuellen Feld](beacons.md#virtual-field) besteht, entspricht die zur Berechnung der Beacon-Länge verwendete Population der Anzahl der eindeutigen Kombinationen, die durch das virtuelle Feld erzeugt werden. 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. + Erwarten Sie, dass sich die Einzelwerte mit 10 multiplizieren werden? + Erwarten Sie, dass sich die Einzelwerte mit 100 multiplizieren? + Erwarten Sie, dass sich die Einzelwerte mit 1000 multiplizieren? 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. 1. **Berechnen Sie den empfohlenen Bereich für die erwartete Anzahl von Kollisionen** Um die geeignete Beacon-Länge für ein bestimmtes Feld zu bestimmen, müssen Sie zunächst einen geeigneten Bereich für die erwartete Anzahl von Kollisionen ermitteln. Die erwartete Anzahl von Kollisionen stellt die durchschnittliche erwartete Anzahl eindeutiger Klartextwerte dar, die einem bestimmten HMAC-Tag zugeordnet sind. Die erwartete Anzahl falsch positiver Ergebnisse für einen eindeutigen Klartextwert liegt um eins unter der erwarteten Anzahl von Kollisionen. Wir empfehlen, dass die erwartete Anzahl von Kollisionen größer oder gleich zwei und kleiner als die Quadratwurzel Ihrer Grundgesamtheit ist. Die folgenden Gleichungen funktionieren nur, wenn Ihre Grundgesamtheit 16 oder mehr Einzelwerte hat. ``` 2 ≤ number of collisions < √(Population) ``` Wenn die Anzahl der Kollisionen weniger als zwei beträgt, erzeugt der Beacon zu wenige Fehlalarme. Wir empfehlen zwei als Mindestanzahl erwarteter Kollisionen, da dies bedeutet, dass im Durchschnitt jeder Einzelwert im Feld mindestens ein falsches Positiv generiert, wenn er einem anderen Einzelwert zugeordnet wird. 1. **Berechnen Sie den empfohlenen Bereich für die Länge der Beacons** Nachdem Sie die minimale und maximale Anzahl erwarteter Kollisionen ermittelt haben, verwenden Sie die folgende Gleichung, um einen Bereich geeigneter Beacon-Längen zu ermitteln. ``` number of collisions = Population * 2-(beacon length) ``` Ermitteln Sie zunächst die **Beacon-Länge**, bei der die Anzahl der erwarteten Kollisionen gleich zwei ist (die empfohlene Mindestanzahl erwarteter Kollisionen). ``` 2 = Population * 2-(beacon length) ``` Berechne dann nach der **Länge des Beacons**, wobei die erwartete Anzahl von Kollisionen der Quadratwurzel deiner Grundgesamtheit entspricht (der empfohlenen maximalen Anzahl erwarteter Kollisionen). ``` √(Population) = Population * 2-(beacon length) ``` Wir empfehlen, die mit dieser Gleichung erzeugte Ausgabe auf die kürzere Beacon-Länge abzurunden. Ergibt die Gleichung beispielsweise eine Beacon-Länge von 15,6, empfehlen wir, diesen Wert auf 15 Bit abzurunden, anstatt ihn auf 16 Bit aufzurunden. 1. **Wählen Sie eine Beacon-Länge** Diese Gleichungen geben nur einen empfohlenen Bereich von Beacon-Längen für Ihr Fachgebiet an. Wir empfehlen, eine kürzere Beacon-Länge zu verwenden, um die Sicherheit Ihres Datensatzes zu gewährleisten, wann immer dies möglich ist. Die Länge des Beacons, das Sie tatsächlich verwenden, hängt jedoch von Ihrem Bedrohungsmodell ab. Berücksichtigen Sie bei der Überprüfung Ihres Bedrohungsmodells Ihre Leistungsanforderungen, um die beste Beacon-Länge für Ihr Einsatzgebiet zu ermitteln. Die Verwendung einer kürzeren Beacon-Länge verringert die Abfrageleistung, während die Verwendung einer längeren Beacon-Länge die Sicherheit verringert. Wenn Ihr Datensatz ungleichmäßig [verteilt](searchable-encryption.md#searchable-encryption-distribution) ist oder Sie unterschiedliche Beacons aus [korrelierten](searchable-encryption.md#searchable-encryption-correlated-values) Feldern erstellen, müssen Sie im Allgemeinen kürzere Beacon-Längen verwenden, um die Menge an Informationen zu minimieren, die über die Verteilung Ihrer Datensätze preisgegeben werden. Wenn Sie Ihr Bedrohungsmodell überprüfen und zu dem Schluss kommen, dass alle offengelegten Unterscheidungsinformationen über die Verteilung eines Feldes keine Gefahr für Ihre allgemeine Sicherheit darstellen, können Sie eine Beacon-Länge verwenden, die länger ist als der von Ihnen berechnete empfohlene Bereich. Wenn Sie beispielsweise den empfohlenen Bereich der Beacon-Längen für ein Feld mit 9—16 Bit berechnet haben, könnten Sie sich für eine Beacon-Länge von 24 Bit entscheiden, um Leistungseinbußen zu vermeiden. Wählen Sie Ihre Beacon-Länge sorgfältig aus. Nachdem Sie mit dem Beacon neue Datensätze geschrieben haben, können Sie die Länge des Beacons nicht mehr aktualisieren. ## Beispiel Stellen Sie sich eine Datenbank vor, die das `unit` Feld als `ENCRYPT_AND_SIGN` in den [kryptografischen](concepts.md#crypt-actions) 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` 1. Schätzen Sie die Bevölkerung Nach der Überprüfung unseres Bedrohungsmodells und unserer aktuellen Datenbanklösung gehen wir davon aus, dass das `unit` Feld irgendwann 100.000 eindeutige Werte haben wird. Das bedeutet, dass **Bevölkerung = 100.000** ist. 1. Berechnet den empfohlenen Bereich für die erwartete Anzahl von Kollisionen. In diesem Beispiel sollte die erwartete Anzahl von Kollisionen zwischen 2 und 316 liegen. ``` 2 ≤ number of collisions < √(Population) ``` 1. ``` 2 ≤ number of collisions < √(100,000) ``` 1. ``` 2 ≤ number of collisions < 316 ``` 1. Berechnen Sie den empfohlenen Bereich für die Länge des Beacons. In diesem Beispiel sollte die Länge des Beacons zwischen 9 und 16 Bit liegen. ``` number of collisions = Population * 2-(beacon length) ``` 1. **Berechnen Sie die Länge des Beacons, bei der die erwartete Anzahl von Kollisionen dem in Schritt 2 ermittelten Minimum entspricht.** ``` 2 = 100,000 * 2-(beacon length) ``` Länge des Beacons = 15,6 oder 15 Bit 1. **Berechnen Sie die Länge des Beacons, wobei die erwartete Anzahl von Kollisionen dem in Schritt 2 ermittelten Maximum entspricht.** ``` 316 = 100,000 * 2-(beacon length) ``` Länge des Beacons = 8,3 oder 8 Bit 1. Ermitteln Sie die Beacon-Länge, die Ihren Sicherheits- und Leistungsanforderungen entspricht. Für jedes Bit unter 15 verdoppeln sich die Kosten für Leistung und Sicherheit. + 16 Bit + Im Durchschnitt wird jeder Einzelwert 1,5 anderen Einheiten zugeordnet. + Sicherheit: Bei zwei Datensätzen mit demselben gekürzten HMAC-Tag besteht eine Wahrscheinlichkeit von 66%, dass sie denselben Klartextwert haben. + Leistung: Eine Abfrage ruft 15 Datensätze für jeweils 10 Datensätze ab, die Sie tatsächlich angefordert haben. + 14 Bit + Im Durchschnitt wird jeder Einzelwert 6,1 anderen Einheiten zugeordnet. + Sicherheit: Bei zwei Datensätzen mit demselben gekürzten HMAC-Tag besteht eine Wahrscheinlichkeit von 33%, dass sie denselben Klartextwert haben. + Leistung: Eine Abfrage ruft 30 Datensätze für jeweils 10 Datensätze ab, die Sie tatsächlich angefordert haben. # Einen Beacon-Namen wählen **** | | | --- | | Unsere clientseitige Verschlüsselungsbibliothek wurde in AWS Database Encryption SDK umbenannt. Dieses Entwicklerhandbuch enthält weiterhin Informationen zum [DynamoDB Encryption Client](legacy-dynamodb-encryption-client.md). | *Jeder Beacon wird durch einen eindeutigen Beacon-Namen identifiziert.* Sobald ein Beacon konfiguriert ist, ist der Beacon-Name der Name, den Sie bei der Abfrage eines verschlüsselten Felds verwenden. Ein Beacon-Name kann derselbe Name wie ein verschlüsseltes Feld oder [virtuelles Feld](beacons.md#virtual-field) sein, er kann jedoch nicht derselbe Name wie ein unverschlüsseltes Feld sein. Zwei verschiedene Beacons können nicht denselben Beacon-Namen haben. [Beispiele, die zeigen, wie Beacons benannt und konfiguriert werden, finden Sie unter Konfiguration von Beacons.](configure-beacons.md) **Benennen von Standard-Beacons** Bei der Benennung von Standardbeacons empfehlen wir dringend, dass Ihr Beacon-Name nach Möglichkeit in die [*Beacon-Quelle*](beacons.md#beacon-source) aufgelöst wird. Das bedeutet, dass der Beacon-Name und der Name des verschlüsselten oder [virtuellen](beacons.md#virtual-field) Feldes, aus dem Ihr Standard-Beacon aufgebaut ist, identisch sind. Wenn Sie beispielsweise einen Standard-Beacon für ein verschlüsseltes Feld mit dem Namen erstellen`LastName`, sollte Ihr Beacon-Name ebenfalls lauten. `LastName` Wenn Ihr Beacon-Name mit der Beacon-Quelle identisch ist, können Sie die Beacon-Quelle aus Ihrer Konfiguration weglassen und das AWS Database Encryption SDK verwendet den Beacon-Namen automatisch als Beacon-Quelle. # Konfiguration von Beacons **** | | | --- | | Unsere clientseitige Verschlüsselungsbibliothek wurde in AWS Database Encryption SDK umbenannt. Dieses Entwicklerhandbuch enthält weiterhin Informationen zum [DynamoDB Encryption Client](legacy-dynamodb-encryption-client.md). | Es gibt zwei Arten von Beacons, die durchsuchbare Verschlüsselung unterstützen. Standard-Beacons führen Gleichheitssuchen durch. Sie sind der einfachste Weg, eine durchsuchbare Verschlüsselung in Ihrer Datenbank zu implementieren. Compound Beacons kombinieren wörtliche Klartext-Zeichenketten und Standard-Beacons, um komplexere Abfragen durchzuführen. Beacons sind so konzipiert, dass sie in neuen, nicht aufgefüllten Datenbanken implementiert werden können. Jedes in einer vorhandenen Datenbank konfigurierte Beacon ordnet nur neue Datensätze zu, die in die Datenbank geschrieben wurden. Beacons werden anhand des Klartextwerts eines Felds berechnet. Sobald das Feld verschlüsselt ist, kann das Beacon keine vorhandenen Daten zuordnen. Nachdem Sie neue Datensätze mit einem Beacon geschrieben haben, können Sie die Konfiguration des Beacons nicht mehr aktualisieren. Sie können jedoch neue Beacons für neue Felder hinzufügen, die Sie Ihrem Datensatz hinzufügen. Nachdem Sie Ihre Zugriffsmuster bestimmt haben, sollte die Konfiguration von Beacons der zweite Schritt in Ihrer Datenbankimplementierung sein. Nachdem Sie alle Ihre Beacons konfiguriert haben, müssen Sie einen [AWS KMS hierarchischen Schlüsselbund](use-hierarchical-keyring.md) erstellen, die Beacon-Version definieren, [einen sekundären Index für jedes Beacon konfigurieren](ddb-searchable-encryption.md#ddb-beacon-indexes), Ihre [kryptografischen Aktionen](concepts.md#crypt-actions) definieren und Ihre Datenbank und den Database Encryption SDK-Client konfigurieren. AWS [Weitere Informationen finden Sie unter Verwenden von Beacons.](using-beacons.md) Um die Definition der Beacon-Version zu vereinfachen, empfehlen wir, Listen für Standard- und Verbund-Beacons zu erstellen. Fügen Sie jedes Beacon, das Sie erstellen, bei der Konfiguration der jeweiligen Standard- oder Verbund-Beacons hinzu. **Topics** + [Konfiguration von Standard-Beacons](#config-standard-beacons) + [Konfiguration von Compound-Beacons](#config-compound-beacons) + [Beispielkonfigurationen](beacon-config-examples.md) ## Konfiguration von Standard-Beacons [Standard-Beacons](beacons.md#standard-beacon-overview) 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. ### Beispiel für eine Konfigurationssyntax ------ #### [ Java ] ``` List standardBeaconList = new ArrayList<>(); StandardBeacon exampleStandardBeacon = StandardBeacon.builder() .name("beaconName") .length(beaconLengthInBits) .build(); standardBeaconList.add(exampleStandardBeacon); ``` ------ #### [ C\$1 / .NET ] ``` var standardBeaconList = new List(); StandardBeacon exampleStandardBeacon = new StandardBeacon { Name = "beaconName", Length = 10 }; standardBeaconList.Add(exampleStandardBeacon); ``` ------ #### [ Rust ] ``` let standard_beacon_list = vec![ StandardBeacon::builder().name("beacon_name").length(beacon_length_in_bits).build()?, ``` ------ Um ein Standard-Beacon zu konfigurieren, geben Sie die folgenden Werte an. **Name des Beacons** Der Name, den Sie bei der Abfrage eines verschlüsselten Felds verwenden. Ein Beacon-Name kann derselbe Name wie ein verschlüsseltes Feld oder virtuelles Feld sein, er kann jedoch nicht derselbe Name wie ein unverschlüsseltes Feld sein. Wir empfehlen dringend, wann immer möglich den Namen des verschlüsselten Felds oder [virtuellen Feldes](beacons.md#virtual-field) zu verwenden, aus dem Ihr Standard-Beacon erstellt wird. Zwei verschiedene Beacons können nicht denselben Beacon-Namen haben. Hilfe bei der Bestimmung des besten Beacon-Namens für Ihre Implementierung finden Sie unter [Auswahl eines](choosing-beacon-name.md) Beacon-Namens. **Länge des Beacons** Die Anzahl der Bits des Beacon-Hashwerts, die nach der Kürzung beibehalten werden. Die Länge des Beacons bestimmt die durchschnittliche Anzahl von Fehlalarmen, die von einem bestimmten Beacon erzeugt werden. Weitere Informationen und Hilfe bei der Bestimmung der geeigneten Beacon-Länge für Ihre Implementierung finden Sie unter [Bestimmung](choosing-beacon-length.md) der Beacon-Länge. **Beacon-Quelle (optional)** Das Feld, aus dem ein Standard-Beacon erstellt wird. Die Beacon-Quelle muss ein Feldname oder ein Index sein, der auf den Wert eines verschachtelten Felds verweist. Wenn Ihr Beacon-Name mit der Beacon-Quelle identisch ist, können Sie die Beacon-Quelle aus Ihrer Konfiguration weglassen und das AWS Database Encryption SDK verwendet den Beacon-Namen automatisch als Beacon-Quelle. ### Ein virtuelles Feld erstellen Um ein [virtuelles Feld](beacons.md#virtual-field) zu erstellen, müssen Sie einen Namen für das virtuelle Feld und eine Liste der Quellfelder angeben. Die Reihenfolge, in der Sie der virtuellen Komponentenliste Quellfelder hinzufügen, bestimmt die Reihenfolge, in der sie zum Aufbau des virtuellen Felds verkettet werden. Im folgenden Beispiel werden zwei Quellfelder in ihrer Gesamtheit verkettet, um ein virtuelles Feld zu erstellen. **Anmerkung** Wir empfehlen, zu überprüfen, ob Ihre virtuellen Felder das erwartete Ergebnis liefern, bevor Sie Ihre Datenbank auffüllen. Weitere Informationen finden Sie unter [Beacon-Ausgaben testen](ddb-searchable-encryption.md#ddb-beacon-testing). ------ #### [ Java ] **[Sehen Sie sich das vollständige Codebeispiel an: .java VirtualBeaconSearchableEncryptionExample](https://github.com/aws/aws-database-encryption-sdk-dynamodb//blob/main/Examples/runtimes/java/DynamoDbEncryption/src/main/java/software/amazon/cryptography/examples/searchableencryption/VirtualBeaconSearchableEncryptionExample.java)** ``` List virtualPartList = new ArrayList<>(); virtualPartList.add(sourceField1); virtualPartList.add(sourceField2); VirtualField virtualFieldName = VirtualField.builder() .name("virtualFieldName") .parts(virtualPartList) .build(); List virtualFieldList = new ArrayList<>(); virtualFieldList.add(virtualFieldName); ``` ------ #### [ C\$1 / .NET ] **[Sehen Sie sich das vollständige Codebeispiel an: .cs VirtualBeaconSearchableEncryptionExample](https://github.com/aws/aws-database-encryption-sdk-dynamodb/tree/main/Examples/runtimes/net/src/searchableencryption/VirtualBeaconSearchableEncryptionExample.cs)** ``` var virtualPartList = new List { sourceField1, sourceField2 }; var virtualFieldName = new VirtualField { Name = "virtualFieldName", Parts = virtualPartList }; var virtualFieldList = new List { virtualFieldName }; ``` ------ #### [ Rust ] **Sehen Sie sich das vollständige Codebeispiel** [an: virtual\$1beacon\$1searchable\$1encryption.rs](https://github.com/aws/aws-database-encryption-sdk-dynamodb/blob/main/releases/rust/db_esdk/examples/searchableencryption/virtual_beacon_searchable_encryption.rs) ``` let virtual_part_list = vec![source_field_one, source_field_two]; let state_and_has_test_result_field = VirtualField::builder() .name("virtual_field_name") .parts(virtual_part_list) .build()?; let virtual_field_list = vec![virtual_field_name]; ``` ------ Um ein virtuelles Feld mit einem bestimmten Segment eines Quellfeldes zu erstellen, müssen Sie diese Transformation definieren, bevor Sie das Quellfeld zu Ihrer virtuellen Teileliste hinzufügen. #### Sicherheitsüberlegungen für virtuelle Felder Beacons ändern den verschlüsselten Zustand 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. Die Art und Weise, wie Sie Ihr Beacon konfigurieren, bestimmt das Sicherheitsniveau, das durch dieses Beacon gewährleistet wird. Vermeiden Sie es, ein virtuelles Feld mit Quellfeldern zu erstellen, die sich mit vorhandenen Standard-Beacons überschneiden. Das Erstellen virtueller Felder, die ein Quellfeld enthalten, das bereits zur Erstellung eines Standard-Beacons verwendet wurde, kann das Sicherheitsniveau für beide Beacons verringern. Das Ausmaß, in dem die Sicherheit reduziert wird, hängt von der Entropiestufe ab, die durch die zusätzlichen Quellfelder hinzugefügt wird. Der Grad der Entropie wird durch die Verteilung der Einzelwerte im zusätzlichen Quellfeld und die Anzahl der Bits bestimmt, die das zusätzliche Quellfeld zur Gesamtgröße des virtuellen Feldes beiträgt. Sie können anhand der Population und [der Beacon-Länge](choosing-beacon-length.md) ermitteln, ob die Quellfelder für ein virtuelles Feld die Sicherheit Ihres Datensatzes gewährleisten. Die Population ist die erwartete Anzahl von Einzelwerten in einem Feld. Ihre Population muss nicht exakt sein. Hilfe zur Schätzung der Grundgesamtheit eines Felds finden Sie unter [Grundgesamtheit schätzen](choosing-beacon-length.md#estimate-population). Betrachten Sie das folgende Beispiel, wenn Sie die Sicherheit Ihrer virtuellen Felder überprüfen. + Beacon1 besteht aus. `FieldA` `FieldA`hat eine Population von mehr als **2 (Beacon1-Länge)**. + Beacon2 wird aus`VirtualField`, was aus,, und aufgebaut ist`FieldA`, `FieldB` konstruiert. `FieldC` `FieldD` **Zusammen `FieldD` haben, `FieldB``FieldC`, und eine Population von mehr als 2 N** Beacon2 gewährleistet die Sicherheit von Beacon1 und Beacon2, wenn die folgenden Aussagen zutreffen: ``` N ≥ (Beacon1 length)/2 ``` und ``` N ≥ (Beacon2 length)/2 ``` ### Definition von Beacon-Stilen 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 für komplexere Datenbankoperationen zu erstellen. 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. **Anmerkung** Um Beacon-Stile zu definieren, müssen Sie Version 3.2 oder höher des Database Encryption SDK verwenden. AWS Stellen Sie die neue Version für alle Leser bereit, bevor Sie Beacon-Styles zu Ihren Beacon-Konfigurationen hinzufügen. ------ #### [ PartOnly ] Ein Standard-Beacon, das als definiert ist, `PartOnly` kann nur zur Definition eines [verschlüsselten Teils](#encrypted-parts) eines zusammengesetzten Beacons verwendet werden. Sie können ein `PartOnly` Standard-Beacon nicht direkt abfragen. **Java** ``` List standardBeaconList = new ArrayList<>(); StandardBeacon exampleStandardBeacon = StandardBeacon.builder() .name("beaconName") .length(beaconLengthInBits) .style( BeaconStyle.builder() .partOnly(PartOnly.builder().build()) .build() ) .build(); standardBeaconList.add(exampleStandardBeacon); ``` **C\$1/.NET** ``` new StandardBeacon { Name = "beaconName", Length = beaconLengthInBits, Style = new BeaconStyle { PartOnly = new PartOnly() } } ``` **Rust** ``` StandardBeacon::builder() .name("beacon_name") .length(beacon_length_in_bits) .style(BeaconStyle::PartOnly(PartOnly::builder().build()?)) .build()? ``` ------ #### [ Shared ] Standardmäßig generiert jedes Standard-Beacon einen eindeutigen HMAC-Schlüssel für die Beacon-Berechnung. Daher können Sie keine Gleichheitssuche in den verschlüsselten Feldern von zwei separaten Standard-Beacons durchführen. Ein als definierter Standard-Beacon `Shared` verwendet für seine Berechnungen den HMAC-Schlüssel eines anderen Standard-Beacons. Wenn Sie beispielsweise Felder mit `beacon1` Feldern vergleichen müssen, definieren Sie es `beacon2` `beacon2` als `Shared` Beacon, das den HMAC-Schlüssel von für seine Berechnungen verwendet. `beacon1` **Anmerkung** Berücksichtigen Sie Ihre Sicherheits- und Leistungsanforderungen, bevor Sie Beacons konfigurieren. `Shared` `Shared`Beacons können die Menge an statistischen Informationen, die über die Verteilung Ihres Datensatzes identifiziert werden können, erhöhen. Sie könnten beispielsweise Aufschluss darüber geben, welche gemeinsam genutzten Felder denselben Klartextwert enthalten. **Java** ``` List standardBeaconList = new ArrayList<>(); StandardBeacon exampleStandardBeacon = StandardBeacon.builder() .name("beacon2") .length(beaconLengthInBits) .style( BeaconStyle.builder() .shared(Shared.builder().other("beacon1").build()) .build() ) .build(); standardBeaconList.add(exampleStandardBeacon); ``` **C\$1/.NET** ``` new StandardBeacon { Name = "beacon2", Length = beaconLengthInBits, Style = new BeaconStyle { Shared = new Shared { Other = "beacon1" } } } ``` **Rust** ``` StandardBeacon::builder() .name("beacon2") .length(beacon_length_in_bits) .style(BeaconStyle::Shared( Shared::builder().other("beacon1").build()?, )) .build()? ``` ------ #### [ AsSet ] Wenn es sich bei einem Feldwert um einen Satz handelt, berechnet das AWS Database Encryption SDK standardmäßig einen einzelnen Standard-Beacon für den Satz. Daher können Sie die Abfrage nicht ausführen, `CONTAINS(a, :value)` wenn sich ein verschlüsseltes `a` Feld befindet. Ein Standard-Beacon, definiert als, `AsSet` berechnet einzelne Standard-Beacon-Werte für jedes einzelne Element des Satzes und speichert den Beacon-Wert im Element als Satz. Dadurch kann das AWS Database Encryption SDK die Abfrage durchführen. `CONTAINS(a, :value)` Um einen `AsSet` Standard-Beacon zu definieren, müssen die Elemente in der Gruppe aus derselben Population stammen, sodass sie alle dieselbe [Beacon-Länge](choosing-beacon-length.md) verwenden können. Das Beacon-Set enthält möglicherweise weniger Elemente als das Klartext-Set, wenn es bei der Berechnung der Beacon-Werte zu Kollisionen kommen sollte. **Anmerkung** Berücksichtigen Sie Ihre Sicherheits- und Leistungsanforderungen, bevor Sie Beacons konfigurieren. `AsSet` `AsSet`Beacons können die Menge an statistischen Informationen, die über die Verteilung Ihres Datensatzes identifiziert werden können, erhöhen. Sie könnten beispielsweise die Größe des Klartext-Datensatzes offenlegen. **Java** ``` List standardBeaconList = new ArrayList<>(); StandardBeacon exampleStandardBeacon = StandardBeacon.builder() .name("beaconName") .length(beaconLengthInBits) .style( BeaconStyle.builder() .asSet(AsSet.builder().build()) .build() ) .build(); standardBeaconList.add(exampleStandardBeacon); ``` **C\$1/.NET** ``` new StandardBeacon { Name = "beaconName", Length = beaconLengthInBits, Style = new BeaconStyle { AsSet = new AsSet() } } ``` **Rust** ``` StandardBeacon::builder() .name("beacon_name") .length(beacon_length_in_bits) .style(BeaconStyle::AsSet(AsSet::builder().build()?)) .build()? ``` ------ #### [ SharedSet ] Ein Standard-Beacon, definiert als, `SharedSet` kombiniert die `AsSet` Funktionen `Shared` und, sodass Sie Gleichheitssuchen für die verschlüsselten Werte einer Menge und eines Felds durchführen können. Auf diese Weise kann das AWS Database Encryption SDK die Abfrage durchführen, `CONTAINS(a, b)` bei der `a` es sich um einen verschlüsselten Satz und um ein verschlüsseltes Feld `b` handelt. **Anmerkung** Berücksichtigen Sie Ihre Sicherheits- und Leistungsanforderungen, bevor Sie `Shared` Beacons konfigurieren. `SharedSet`Beacons können die Menge an statistischen Informationen, die über die Verteilung Ihres Datensatzes identifiziert werden können, erhöhen. Sie könnten beispielsweise Aufschluss darüber geben, wie groß der Klartextsatz ist oder welche gemeinsam genutzten Felder denselben Klartextwert enthalten. **Java** ``` List standardBeaconList = new ArrayList<>(); StandardBeacon exampleStandardBeacon = StandardBeacon.builder() .name("beacon2") .length(beaconLengthInBits) .style( BeaconStyle.builder() .sharedSet(SharedSet.builder().other("beacon1").build()) .build() ) .build(); standardBeaconList.add(exampleStandardBeacon); ``` **C\$1/.NET** ``` new StandardBeacon { Name = "beacon2", Length = beaconLengthInBits, Style = new BeaconStyle { SharedSet = new SharedSet { Other = "beacon1" } } } ``` **Rust** ``` StandardBeacon::builder() .name("beacon2") .length(beacon_length_in_bits) .style(BeaconStyle::SharedSet( SharedSet::builder().other("beacon1").build()?, )) .build()? ``` ------ ## Konfiguration von Compound-Beacons Zusammengesetzte Beacons kombinieren wörtliche Klartext-Zeichenketten und Standard-Beacons, um komplexe Datenbankoperationen durchzuführen, z. B. das Abfragen von zwei verschiedenen Datensatztypen aus einem einzigen Index oder das Abfragen einer Kombination von Feldern mit einem Sortierschlüssel. Zusammengesetzte Beacons können aus Feldern, und erstellt werden. `ENCRYPT_AND_SIGN` `SIGN_ONLY` `SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT` Sie müssen für jedes verschlüsselte Feld, das im Verbund-Beacon enthalten ist, einen Standard-Beacon erstellen. **Anmerkung** Wir empfehlen, zu überprüfen, ob Ihre Compound-Beacons das erwartete Ergebnis erzielen, bevor Sie Ihre Datenbank auffüllen. Weitere Informationen finden Sie unter Beacon-Ausgaben [testen](ddb-searchable-encryption.md#ddb-beacon-testing). ### Beispiel für eine Konfigurationssyntax ------ #### [ Java ] **Konfiguration eines zusammengesetzten Beacons** Im folgenden Beispiel werden verschlüsselte und signierte Teilelisten lokal in der Konfiguration der Compound Beacons definiert. ``` List compoundBeaconList = new ArrayList<>(); CompoundBeacon exampleCompoundBeacon = CompoundBeacon.builder() .name("compoundBeaconName") .split(".") .encrypted(encryptedPartList) .signed(signedPartList) .constructors(constructorList) .build(); compoundBeaconList.add(exampleCompoundBeacon); ``` **Definition der Beacon-Version** Im folgenden Beispiel werden verschlüsselte und signierte Teilelisten global in der Beacon-Version definiert. Weitere Informationen zur Definition der Beacon-Version finden Sie unter Beacons [verwenden](using-beacons.md). ``` List beaconVersions = new ArrayList<>(); beaconVersions.add( BeaconVersion.builder() .standardBeacons(standardBeaconList) .compoundBeacons(compoundBeaconList) .encryptedParts(encryptedPartList) .signedParts(signedPartList) .version(1) // MUST be 1 .keyStore(keyStore) .keySource(BeaconKeySource.builder() .single(SingleKeyStore.builder() .keyId(branchKeyId) .cacheTTL(6000) .build()) .build()) .build() ); ``` ------ #### [ C\$1 / .NET ] **Sehen Sie sich das vollständige Codebeispiel** [an: .cs BeaconConfig](https://github.com/aws/aws-database-encryption-sdk-dynamodb/tree/main/Examples/runtimes/net/src/searchableencryption/complexexample/BeaconConfig.cs) **Konfiguration eines zusammengesetzten Beacons** Im folgenden Beispiel werden verschlüsselte und signierte Teilelisten lokal in der Konfiguration der Compound Beacons definiert. ``` var compoundBeaconList = new List(); var exampleCompoundBeacon = new CompoundBeacon { Name = "compoundBeaconName", Split = ".", Encrypted = encryptedPartList, Signed = signedPartList, Constructors = constructorList }; compoundBeaconList.Add(exampleCompoundBeacon); ``` **Definition der Beacon-Version** Im folgenden Beispiel werden verschlüsselte und signierte Teilelisten global in der Beacon-Version definiert. Weitere Informationen zur Definition der Beacon-Version finden Sie unter Beacons [verwenden](using-beacons.md). ``` var beaconVersions = new List { new BeaconVersion { StandardBeacons = standardBeaconList, CompoundBeacons = compoundBeaconList, EncryptedParts = encryptedPartsList, SignedParts = signedPartsList, Version = 1, // MUST be 1 KeyStore = keyStore, KeySource = new BeaconKeySource { Single = new SingleKeyStore { KeyId = branchKeyId, CacheTTL = 6000 } } } }; ``` ------ #### [ Rust ] **Sehen Sie sich das vollständige Codebeispiel** [an: beacon\$1config.rs](https://github.com/aws/aws-database-encryption-sdk-dynamodb/blob/main/releases/rust/db_esdk/examples/searchableencryption/complexexample/beacon_config.rs) **Konfiguration eines zusammengesetzten Beacons** Im folgenden Beispiel werden verschlüsselte und signierte Teilelisten lokal in der Konfiguration der Compound Beacons definiert. ``` let compound_beacon_list = vec![ CompoundBeacon::builder() .name("compound_beacon_name") .split(".") .encrypted(encrypted_parts_list) .signed(signed_parts_list) .constructors(constructor_list) .build()? ``` **Definition der Beacon-Version** Im folgenden Beispiel werden verschlüsselte und signierte Teilelisten global in der Beacon-Version definiert. Weitere Informationen zur Definition der Beacon-Version finden Sie unter Beacons [verwenden](using-beacons.md). ``` let beacon_versions = BeaconVersion::builder() .standard_beacons(standard_beacon_list) .compound_beacons(compound_beacon_list) .encrypted_parts(encrypted_parts_list) .signed_parts(signed_parts_list) .version(1) // MUST be 1 .key_store(key_store.clone()) .key_source(BeaconKeySource::Single( SingleKeyStore::builder() .key_id(branch_key_id) .cache_ttl(6000) .build()?, )) .build()?; let beacon_versions = vec![beacon_versions]; ``` ------ Sie können Ihre [verschlüsselten und [signierten Teile](#signed-parts)](#encrypted-parts) in lokal oder global definierten Listen definieren. Wir empfehlen, Ihre verschlüsselten und signierten Teile wann immer möglich in einer globalen Liste in der [Beacon-Version](using-beacons.md#beacon-version) zu definieren. Indem Sie verschlüsselte und signierte Teile global definieren, können Sie jedes Teil einmal definieren und die Teile dann in mehreren Compound-Beacon-Konfigurationen wiederverwenden. Wenn Sie beabsichtigen, einen verschlüsselten oder signierten Teil nur einmal zu verwenden, können Sie ihn in einer lokalen Liste in der Compound-Beacon-Konfiguration definieren. Sie können in Ihrer [Konstruktorliste](#constructor-parts) sowohl auf lokale als auch auf globale Teile verweisen. Wenn Sie Ihre verschlüsselten und signierten Teilelisten global definieren, müssen Sie eine Liste von Konstruktorteilen bereitstellen, in der alle Möglichkeiten aufgeführt sind, wie der Compound Beacon die Felder in Ihrer Compound-Beacon-Konfiguration zusammenstellen kann. **Anmerkung** Um verschlüsselte und signierte Teilelisten global zu definieren, müssen Sie Version 3.2 oder höher des AWS Database Encryption SDK verwenden. Stellen Sie die neue Version allen Lesern zur Verfügung, bevor Sie neue Teile global definieren. Sie können bestehende Beacon-Konfigurationen nicht aktualisieren, um verschlüsselte und signierte Teilelisten global zu definieren. Um eine Verbundstation zu konfigurieren, geben Sie die folgenden Werte an. **Name des Beacons** Der Name, den Sie bei der Abfrage eines verschlüsselten Felds verwenden. Ein Beacon-Name kann derselbe Name wie ein verschlüsseltes Feld oder virtuelles Feld sein, er kann jedoch nicht derselbe Name wie ein unverschlüsseltes Feld sein. Keine zwei Beacons können denselben Beacon-Namen haben. Hilfe bei der Bestimmung des besten Beacon-Namens für Ihre Implementierung finden Sie unter [Auswahl eines](choosing-beacon-name.md) Beacon-Namens. **Charakter teilen** Das Zeichen, das verwendet wird, um die Teile zu trennen, aus denen Ihr Verbundsignal besteht. Das Trennzeichen darf in den Klartextwerten der Felder, aus denen der Verbundbeacon aufgebaut ist, nicht vorkommen. **Verschlüsselte Teileliste** Identifiziert die `ENCRYPT_AND_SIGN` Felder, die im Compound Beacon enthalten sind. Jeder Teil muss einen Namen und ein Präfix enthalten. Der Teilname muss der Name des Standard-Beacons sein, der aus dem verschlüsselten Feld erstellt wurde. Das Präfix kann eine beliebige Zeichenfolge sein, muss jedoch eindeutig sein. Ein verschlüsselter Teil kann nicht dasselbe Präfix wie ein signierter Teil haben. Es wird empfohlen, einen kurzen Wert zu verwenden, der den Teil von anderen Teilen unterscheidet, die vom Compound Beacon bedient werden. Wir empfehlen, Ihre verschlüsselten Teile nach Möglichkeit global zu definieren. Sie könnten erwägen, einen verschlüsselten Teil lokal zu definieren, wenn Sie ihn nur in einem Compound Beacon verwenden möchten. Ein lokal definierter verschlüsselter Teil kann nicht dasselbe Präfix oder denselben Namen haben wie ein global definierter verschlüsselter Teil. ``` List encryptedPartList = new ArrayList<>(); EncryptedPart encryptedPartExample = EncryptedPart.builder() .name("standardBeaconName") .prefix("E-") .build(); encryptedPartList.add(encryptedPartExample); ``` ``` var encryptedPartList = new List(); var encryptedPartExample = new EncryptedPart { Name = "compoundBeaconName", Prefix = "E-" }; encryptedPartList.Add(encryptedPartExample); ``` ``` let encrypted_parts_list = vec![ EncryptedPart::builder() .name("standard_beacon_name") .prefix("E-") .build()? ]; ``` **Signierte Teileliste** Identifiziert die signierten Felder, die im Compound Beacon enthalten sind. Signierte Teile sind optional. Sie können einen Compound-Beacon konfigurieren, der keine signierten Teile referenziert. Jeder Teil muss einen Namen, eine Quelle und ein Präfix enthalten. Die Quelle ist das `SIGN_ONLY` `SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT` ODER-Feld, das der Teil identifiziert. Die Quelle muss ein Feldname oder ein Index sein, der auf den Wert eines verschachtelten Felds verweist. Wenn Ihr Teilname die Quelle identifiziert, können Sie die Quelle weglassen und das AWS Database Encryption SDK verwendet den Namen automatisch als Quelle. Wir empfehlen, wann immer möglich, die Quelle als Teilnamen anzugeben. Das Präfix kann eine beliebige Zeichenfolge sein, muss jedoch eindeutig sein. Ein signierter Teil kann nicht dasselbe Präfix wie ein verschlüsselter Teil haben. Es wird empfohlen, einen kurzen Wert zu verwenden, der den Teil von anderen Teilen unterscheidet, die vom Compound Beacon bedient werden. Wir empfehlen, Ihre signierten Teile nach Möglichkeit global zu definieren. Sie könnten erwägen, ein signiertes Teil lokal zu definieren, wenn Sie es nur in einem Compound Beacon verwenden möchten. Ein lokal definierter signierter Teil kann nicht dasselbe Präfix oder denselben Namen haben wie ein global definierter signierter Teil. ``` List signedPartList = new ArrayList<>(); SignedPart signedPartExample = SignedPart.builder() .name("signedFieldName") .prefix("S-") .build(); signedPartList.add(signedPartExample); ``` ``` var signedPartsList = new List { new SignedPart { Name = "signedFieldName1", Prefix = "S-" }, new SignedPart { Name = "signedFieldName2", Prefix = "SF-" } }; ``` ``` let signed_parts_list = vec![ SignedPart::builder() .name("signed_field_name_1") .prefix("S-") .build()?, SignedPart::builder() .name("signed_field_name_2") .prefix("SF-") .build()?, ]; ``` **Liste der Konstruktoren** Identifiziert die *Konstruktoren*, die die verschiedenen Arten definieren, wie die verschlüsselten und signierten Teile durch den Compound Beacon zusammengesetzt werden können. Sie können in Ihrer Konstruktorliste sowohl auf lokale als auch auf globale Bauteile verweisen. Wenn Sie Ihr Compound-Beacon aus global definierten, verschlüsselten und signierten Teilen erstellen, müssen Sie eine Konstruktorliste angeben. Wenn Sie keine global definierten, verschlüsselten oder signierten Teile verwenden, um Ihren Compound-Beacon zu erstellen, ist die Liste der Konstruktoren optional. Wenn Sie keine Konstruktorliste angeben, stellt das AWS Database Encryption SDK den Compound Beacon mit dem folgenden Standardkonstruktor zusammen. + Alle signierten Teile in der Reihenfolge, in der sie der signierten Teileliste hinzugefügt wurden + Alle verschlüsselten Teile in der Reihenfolge, in der sie der verschlüsselten Teileliste hinzugefügt wurden + Alle Teile sind erforderlich **Konstruktoren** Jeder Konstruktor ist eine geordnete Liste von *Konstruktorteilen*, die eine Art und Weise definiert, wie der Compound Beacon zusammengebaut werden kann. Die Konstruktorteile werden in der Reihenfolge zusammengefügt, in der sie der Liste hinzugefügt wurden, wobei jeder Teil durch das angegebene Trennzeichen getrennt wird. Jeder Konstruktorteil benennt einen verschlüsselten Teil oder einen signierten Teil und definiert, ob dieser Teil innerhalb des Konstruktors erforderlich oder optional ist. Wenn Sie beispielsweise ein zusammengesetztes Beacon für, und abfragen möchten `Field1` `Field1.Field2``Field1.Field2.Field3`, markieren Sie und `Field3` als optional `Field2` und erstellen Sie einen Konstruktor. Jeder Konstruktor muss mindestens einen erforderlichen Teil haben. Wir empfehlen, den ersten Teil in jedem Konstruktor als erforderlich festzulegen, damit Sie den `BEGINS_WITH` Operator in Ihren Abfragen verwenden können. Ein Konstruktor ist erfolgreich, wenn alle erforderlichen Teile im Datensatz vorhanden sind. Wenn Sie einen neuen Datensatz schreiben, ermittelt der Verbundbeacon anhand der Konstruktorliste, ob der Beacon aus den bereitgestellten Werten zusammengesetzt werden kann. Es versucht, den Beacon in der Reihenfolge zusammenzustellen, in der die Konstruktoren der Konstruktorliste hinzugefügt wurden, und verwendet den ersten Konstruktor, der erfolgreich ist. Wenn keine Konstruktoren erfolgreich sind, wird der Beacon nicht in den Datensatz geschrieben. Alle Leser und Autoren sollten dieselbe Reihenfolge der Konstruktoren angeben, um sicherzustellen, dass ihre Abfrageergebnisse korrekt sind. Verwenden Sie die folgenden Verfahren, um Ihre eigene Konstruktorliste anzugeben. 1. Erstellen Sie für jeden verschlüsselten und signierten Teil einen Konstruktorteil, um zu definieren, ob dieser Teil erforderlich ist oder nicht. Der Name des Konstruktorteils muss der Name des Standard-Beacons oder des signierten Felds sein, für das er steht. ------ #### [ Java ] ``` ConstructorPart field1ConstructorPart = ConstructorPart.builder() .name("Field1") .required(true) .build(); ``` ------ #### [ C\$1 / .NET ] ``` var field1ConstructorPart = new ConstructorPart { Name = "Field1", Required = true }; ``` ------ #### [ Rust ] ``` let field_1_constructor_part = ConstructorPart::builder() .name("field_1") .required(true) .build()?; ``` ------ 1. **Erstellen Sie mithilfe der Konstruktorteile, die Sie in Schritt 1 erstellt haben, einen Konstruktor für jede mögliche Art und Weise, wie das Verbundsignal zusammengebaut werden kann.** Wenn Sie beispielsweise nach `Field1.Field2.Field3` und abfragen möchten`Field4.Field2.Field3`, müssen Sie zwei Konstruktoren erstellen. `Field1`und `Field4` können beide erforderlich sein, da sie in zwei separaten Konstruktoren definiert sind. ------ #### [ Java ] ``` // Create a list for Field1.Field2.Field3 queries List field123ConstructorPartList = new ArrayList<>(); field123ConstructorPartList.add(field1ConstructorPart); field123ConstructorPartList.add(field2ConstructorPart); field123ConstructorPartList.add(field3ConstructorPart); Constructor field123Constructor = Constructor.builder() .parts(field123ConstructorPartList) .build(); // Create a list for Field4.Field2.Field1 queries List field421ConstructorPartList = new ArrayList<>(); field421ConstructorPartList.add(field4ConstructorPart); field421ConstructorPartList.add(field2ConstructorPart); field421ConstructorPartList.add(field1ConstructorPart); Constructor field421Constructor = Constructor.builder() .parts(field421ConstructorPartList) .build(); ``` ------ #### [ C\$1 / .NET ] ``` // Create a list for Field1.Field2.Field3 queries var field123ConstructorPartList = new Constructor { Parts = new List { field1ConstructorPart, field2ConstructorPart, field3ConstructorPart } }; // Create a list for Field4.Field2.Field1 queries var field421ConstructorPartList = new Constructor { Parts = new List { field4ConstructorPart, field2ConstructorPart, field1ConstructorPart } }; ``` ------ #### [ Rust ] ``` // Create a list for field1.field2.field3 queries let field1_field2_field3_constructor = Constructor::builder() .parts(vec![ field1_constructor_part, field2_constroctor_part.clone(), field3_constructor_part, ]) .build()?; // Create a list for field4.field2.field1 queries let field4_field2_field1_constructor = Constructor::builder() .parts(vec![ field4_constructor_part, field2_constroctor_part.clone(), field1_constructor_part, ]) .build()?; ``` ------ 1. **Erstellen Sie eine Konstruktorliste, die alle Konstruktoren enthält, die Sie in Schritt 2 erstellt haben.** ------ #### [ Java ] ``` List constructorList = new ArrayList<>(); constructorList.add(field123Constructor); constructorList.add(field421Constructor); ``` ------ #### [ C\$1 / .NET ] ``` var constructorList = new List { field123Constructor, field421Constructor }; ``` ------ #### [ Rust ] ``` let constructor_list = vec![ field1_field2_field3_constructor, field4_field2_field1_constructor, ]; ``` ------ 1. Geben Sie den an`constructorList`, wenn Sie Ihren Verbundbeacon erstellen. # Beispielkonfigurationen **** | | | --- | | Unsere clientseitige Verschlüsselungsbibliothek wurde in AWS Database Encryption SDK umbenannt. Dieses Entwicklerhandbuch enthält weiterhin Informationen zum [DynamoDB Encryption Client](legacy-dynamodb-encryption-client.md). | Die folgenden Beispiele zeigen, wie Standard- und Verbund-Beacons konfiguriert werden. Die folgenden Konfigurationen bieten keine Beacon-Längen. Hilfe bei der Bestimmung der geeigneten Beacon-Länge für Ihre Konfiguration finden Sie unter [Wählen Sie eine Beacon-Länge](choosing-beacon-length.md). Vollständige Codebeispiele, die die Konfiguration und Verwendung von Beacons demonstrieren, finden Sie in den durchsuchbaren Verschlüsselungsbeispielen für [Java](https://github.com/aws/aws-database-encryption-sdk-dynamodb//tree/main/Examples/runtimes/java/DynamoDbEncryption/src/main/java/software/amazon/cryptography/examples/searchableencryption), [.NET](https://github.com/aws/aws-database-encryption-sdk-dynamodb/tree/main/Examples/runtimes/net/src/searchableencryption/) und [Rust](https://github.com/aws/aws-database-encryption-sdk-dynamodb/blob/main/releases/rust/db_esdk/examples/searchableencryption/) im -dynamodb-Repository unter. aws-database-encryption-sdk GitHub **Topics** + [Standard-Beacons](#standard-config-examples) + [Zusammengesetzte Beacons](#compound-config-examples) ## Standard-Beacons Wenn Sie das `inspector_id_last4` Feld nach exakten Übereinstimmungen abfragen möchten, erstellen Sie ein Standard-Beacon mit der folgenden Konfiguration. ------ #### [ Java ] ``` List standardBeaconList = new ArrayList<>(); StandardBeacon exampleStandardBeacon = StandardBeacon.builder() .name("inspector_id_last4") .length(beaconLengthInBits) .build(); standardBeaconList.add(exampleStandardBeacon); ``` ------ #### [ C\$1 / .NET ] ``` var standardBeaconList = new List>); StandardBeacon exampleStandardBeacon = new StandardBeacon { Name = "inspector_id_last4", Length = 10 }; standardBeaconList.Add(exampleStandardBeacon); ``` ------ #### [ Rust ] ``` let last4_beacon = StandardBeacon::builder() .name("inspector_id_last4") .length(10) .build()?; let unit_beacon = StandardBeacon::builder().name("unit").length(30).build()?; let standard_beacon_list = vec![last4_beacon, unit_beacon]; ``` ------ ## Zusammengesetzte Beacons Wenn Sie die `UnitInspection` Datenbank auf `inspector_id_last4` und abfragen möchten`inspector_id_last4.unit`, erstellen Sie ein zusammengesetztes Beacon mit der folgenden Konfiguration. Für diesen Compound Beacon sind nur [verschlüsselte](configure-beacons.md#encrypted-parts) Teile erforderlich. ------ #### [ Java ] ``` // 1. Create standard beacons for the inspector_id_last4 and unit fields. List standardBeaconList = new ArrayList<>(); StandardBeacon inspectorBeacon = StandardBeacon.builder() .name("inspector_id_last4") .length(beaconLengthInBits) .build(); standardBeaconList.add(inspectorBeacon); StandardBeacon unitBeacon = StandardBeacon.builder() .name("unit") .length(beaconLengthInBits) .build(); standardBeaconList.add(unitBeacon); // 2. Define the encrypted parts. List encryptedPartList = new ArrayList<>(); // Each encrypted part needs a name and prefix // The name must be the name of the standard beacon // The prefix must be unique // For this example we use the prefix "I-" for "inspector_id_last4" // and "U-" for "unit" EncryptedPart encryptedPartInspector = EncryptedPart.builder() .name("inspector_id_last4") .prefix("I-") .build(); encryptedPartList.add(encryptedPartInspector); EncryptedPart encryptedPartUnit = EncryptedPart.builder() .name("unit") .prefix("U-") .build(); encryptedPartList.add(encryptedPartUnit); // 3. Create the compound beacon. // This compound beacon only requires a name, split character, // and list of encrypted parts CompoundBeacon inspectorUnitBeacon = CompoundBeacon.builder() .name("inspectorUnitBeacon") .split(".") .sensitive(encryptedPartList) .build(); ``` ------ #### [ C\$1 / .NET ] ``` // 1. Create standard beacons for the inspector_id_last4 and unit fields. StandardBeacon inspectorBeacon = new StandardBeacon { Name = "inspector_id_last4", Length = 10 }; standardBeaconList.Add(inspectorBeacon); StandardBeacon unitBeacon = new StandardBeacon { Name = "unit", Length = 30 }; standardBeaconList.Add(unitBeacon); // 2. Define the encrypted parts. var last4EncryptedPart = new EncryptedPart // Each encrypted part needs a name and prefix // The name must be the name of the standard beacon // The prefix must be unique // For this example we use the prefix "I-" for "inspector_id_last4" // and "U-" for "unit" var last4EncryptedPart = new EncryptedPart { Name = "inspector_id_last4", Prefix = "I-" }; encryptedPartList.Add(last4EncryptedPart); var unitEncryptedPart = new EncryptedPart { Name = "unit", Prefix = "U-" }; encryptedPartList.Add(unitEncryptedPart); // 3. Create the compound beacon. // This compound beacon only requires a name, split character, // and list of encrypted parts var compoundBeaconList = new List>); var inspectorCompoundBeacon = new CompoundBeacon { Name = "inspector_id_last4", Split = ".", Encrypted = encryptedPartList }; compoundBeaconList.Add(inspectorCompoundBeacon); ``` ------ #### [ Rust ] ``` // 1. Create standard beacons for the inspector_id_last4 and unit fields. let last4_beacon = StandardBeacon::builder() .name("inspector_id_last4") .length(10) .build()?; let unit_beacon = StandardBeacon::builder().name("unit").length(30).build()?; let standard_beacon_list = vec![last4_beacon, unit_beacon]; // 2. Define the encrypted parts. // The name must be the name of the standard beacon // The prefix must be unique // For this example we use the prefix "I-" for "inspector_id_last4" // and "U-" for "unit" let encrypted_parts_list = vec![ EncryptedPart::builder() .name("inspector_id_last4") .prefix("I-") .build()?, EncryptedPart::builder().name("unit").prefix("U-").build()?, ]; // 3. Create the compound beacon // This compound beacon only requires a name, split character, // and list of encrypted parts let compound_beacon_list = vec![CompoundBeacon::builder() .name("last4UnitCompound") .split(".") .encrypted(encrypted_parts_list) .build()?]; ``` ------ # Verwendung von Beacons **** | | | --- | | Unsere clientseitige Verschlüsselungsbibliothek wurde in AWS Database Encryption SDK umbenannt. Dieses Entwicklerhandbuch enthält weiterhin Informationen zum [DynamoDB Encryption Client](legacy-dynamodb-encryption-client.md). | Mit Beacons können Sie verschlüsselte Datensätze durchsuchen, ohne die gesamte abgefragte Datenbank zu entschlüsseln. Beacons sind so konzipiert, dass sie in neuen, nicht aufgefüllten Datenbanken implementiert werden können. Jedes Beacon, das in einer vorhandenen Datenbank konfiguriert ist, ordnet nur neue Datensätze zu, die in die Datenbank geschrieben wurden. Beacons werden anhand des Klartextwerts eines Felds berechnet. Sobald das Feld verschlüsselt ist, kann das Beacon keine vorhandenen Daten zuordnen. Nachdem Sie neue Datensätze mit einem Beacon geschrieben haben, können Sie die Konfiguration des Beacons nicht mehr aktualisieren. Sie können jedoch neue Beacons für neue Felder hinzufügen, die Sie Ihrem Datensatz hinzufügen. Nachdem Sie Ihre Beacons konfiguriert haben, müssen Sie die folgenden Schritte ausführen, bevor Sie beginnen, Ihre Datenbank zu füllen und Abfragen an Ihren Beacons durchzuführen. 1. **Erstellen Sie einen hierarchischen Schlüsselbund AWS KMS ** Um eine durchsuchbare Verschlüsselung zu verwenden, müssen Sie den [AWS KMS hierarchischen Schlüsselbund](use-hierarchical-keyring.md) verwenden, um die Datenschlüssel zu generieren, zu verschlüsseln und zu entschlüsseln, die zum Schutz Ihrer [Daten](concepts.md#data-key) verwendet werden. [Nachdem Sie Ihre Beacons konfiguriert haben, stellen Sie die Voraussetzungen für den [hierarchischen Schlüsselbund zusammen und erstellen Sie Ihren hierarchischen Schlüsselbund](use-hierarchical-keyring.md#hierarchical-keyring-prereqs).](use-hierarchical-keyring.md#initialize-hierarchical-keyring) Weitere Informationen darüber, warum der hierarchische Schlüsselbund erforderlich ist, finden Sie unter [Verwenden](use-hierarchical-keyring.md#searchable-encryption-hierarchical-keyrings) des hierarchischen Schlüsselbunds für durchsuchbare Verschlüsselung. 1. **Definieren Sie die Beacon-Version** Geben Sie Ihre`keyStore`,`keySource`, eine Liste aller von Ihnen konfigurierten Standard-Beacons, eine Liste aller von Ihnen konfigurierten Verbund-Beacons, eine Liste der verschlüsselten Teile, eine Liste der signierten Teile und eine Beacon-Version an. Sie müssen die `1` Beacon-Version angeben. Hinweise zur Definition Ihres finden Sie `keySource` unter[Definieren Sie Ihre Beacon-Schlüsselquelle](use-hierarchical-keyring.md#beacon-key-source). Das folgende Java-Beispiel definiert die Beacon-Version für eine Single-Tenant-Datenbank. Hilfe bei der Definition der Beacon-Version für eine Mehrmandantendatenbank finden Sie unter [Durchsuchbare Verschlüsselung](searchable-encryption-multitenant.md) für Mehrmandantendatenbanken. ------ #### [ Java ] ``` List beaconVersions = new ArrayList<>(); beaconVersions.add( BeaconVersion.builder() .standardBeacons(standardBeaconList) .compoundBeacons(compoundBeaconList) .encryptedParts(encryptedPartsList) .signedParts(signedPartsList) .version(1) // MUST be 1 .keyStore(keyStore) .keySource(BeaconKeySource.builder() .single(SingleKeyStore.builder() .keyId(branchKeyId) .cacheTTL(6000) .build()) .build()) .build() ); ``` ------ #### [ C\$1 / .NET ] ``` var beaconVersions = new List { new BeaconVersion { StandardBeacons = standardBeaconList, CompoundBeacons = compoundBeaconList, EncryptedParts = encryptedPartsList, SignedParts = signedPartsList, Version = 1, // MUST be 1 KeyStore = branchKeyStoreName, KeySource = new BeaconKeySource { Single = new SingleKeyStore { KeyId = branch-key-id, CacheTTL = 6000 } } } }; ``` ------ #### [ Rust ] ``` let beacon_version = BeaconVersion::builder() .standard_beacons(standard_beacon_list) .compound_beacons(compound_beacon_list) .version(1) // MUST be 1 .key_store(key_store.clone()) .key_source(BeaconKeySource::Single( SingleKeyStore::builder() // `keyId` references a beacon key. // For every branch key we create in the keystore, // we also create a beacon key. // This beacon key is not the same as the branch key, // but is created with the same ID as the branch key. .key_id(branch_key_id) .cache_ttl(6000) .build()?, )) .build()?; let beacon_versions = vec![beacon_version]; ``` ------ 1. **Konfigurieren Sie sekundäre Indizes** Nachdem Sie [Ihre Beacons konfiguriert](configure-beacons.md) haben, müssen Sie einen sekundären Index konfigurieren, der die einzelnen Beacons widerspiegelt, bevor Sie in den verschlüsselten Feldern suchen können. Weitere Informationen finden Sie unter [Konfiguration sekundärer Indizes mit Beacons](ddb-searchable-encryption.md#ddb-beacon-indexes). 1. **[Definieren Sie Ihre kryptografischen Aktionen](concepts.md#crypt-actions)** Alle Felder, die zum Aufbau eines Standard-Beacons verwendet werden, müssen markiert sein. `ENCRYPT_AND_SIGN` Alle anderen Felder, die zum Bau von Beacons verwendet werden, müssen mit oder markiert `SIGN_ONLY` sein. `SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT` 1. **Konfigurieren Sie einen AWS Database Encryption SDK-Client** Informationen zur Konfiguration eines AWS Database Encryption SDK-Clients, der die Tabellenelemente in Ihrer DynamoDB-Tabelle schützt, finden Sie unter [Clientseitige Java-Verschlüsselungsbibliothek](ddb-java.md) für DynamoDB. ## Beacons abfragen Der Typ des Beacons, den Sie konfigurieren, bestimmt die Art der Abfragen, die Sie ausführen können. Standard-Beacons verwenden Filterausdrücke, um Gleichheitssuchen durchzuführen. Zusammengesetzte Beacons kombinieren wörtliche Klartext-Zeichenketten und Standard-Beacons, um komplexe Abfragen durchzuführen. Wenn Sie verschlüsselte Daten abfragen, suchen Sie nach dem Namen des Beacons. Sie können die Werte von zwei Standard-Beacons nicht vergleichen, selbst wenn sie denselben zugrunde liegenden Klartext enthalten. Die beiden Standard-Beacons erzeugen zwei verschiedene HMAC-Tags für dieselben Klartext-Werte. Daher können Standard-Beacons die folgenden Abfragen nicht ausführen. + `beacon1 = beacon2` + `beacon1 IN (beacon2)` + `value IN (beacon1, beacon2, ...)` + `CONTAINS(beacon1, beacon2)` Compound Beacons können die folgenden Abfragen ausführen. + `BEGINS_WITH(a)`, wobei der gesamte Wert des Feldes `a` wiedergegeben wird, mit dem die zusammengestellte Verbundstation beginnt. Sie können den `BEGINS_WITH` Operator nicht verwenden, um einen Wert zu identifizieren, der mit einer bestimmten Teilzeichenfolge beginnt. Sie können jedoch, where `BEGINS_WITH(S_)``S_`, das Präfix für ein Teil verwenden, mit dem die zusammengebaute Verbundleuchte beginnt. + `CONTAINS(a)`, wobei der gesamte Wert eines Feldes `a` wiedergegeben wird, das die zusammengebaute Verbundleuchte enthält. Sie können den `CONTAINS` Operator nicht verwenden, um einen Datensatz zu identifizieren, der eine bestimmte Teilzeichenfolge oder einen Wert innerhalb eines Satzes enthält. Sie können beispielsweise keine Abfrage `CONTAINS(path, "a"` ausführen, die den Wert in einem Satz `a` widerspiegelt. + Sie können [signierte Teile](configure-beacons.md#signed-parts) von Compound-Beacons vergleichen. Wenn Sie signierte Teile vergleichen, können Sie optional das Präfix eines [verschlüsselten Teils](configure-beacons.md#encrypted-parts) an einen oder mehrere signierte Teile anhängen, aber Sie können den Wert eines verschlüsselten Felds nicht in eine Abfrage einbeziehen. Sie können beispielsweise signierte Teile vergleichen und nach `signedField1 = signedField2` oder `value IN (signedField1, signedField2, ...)` abfragen. Sie können signierte Teile auch mit dem Präfix eines verschlüsselten Bauteils vergleichen, indem Sie auf „Query on“ klicken`signedField1.A_ = signedField2.B_`. + `field BETWEEN a AND b`, wo `a` und `b` sind signierte Teile. Sie können optional das Präfix eines verschlüsselten Teils an einen oder mehrere signierte Teile anhängen, aber Sie können den Wert eines verschlüsselten Felds nicht in eine Abfrage einbeziehen. Sie müssen das Präfix für jeden Teil angeben, den Sie in eine Abfrage auf einem Compound Beacon einbeziehen. Wenn Sie beispielsweise einen Verbundbeacon aus zwei Feldern `encryptedField` und `signedField` erstellt haben`compoundBeacon`, müssen Sie bei der Abfrage des Beacons die für diese beiden Teile konfigurierten Präfixe angeben. ``` compoundBeacon = E_encryptedFieldValue.S_signedFieldValue ``` # Durchsuchbare Verschlüsselung für Multitenant-Datenbanken **** | | | --- | | Unsere clientseitige Verschlüsselungsbibliothek wurde in Database Encryption SDK umbenannt. AWS Dieses Entwicklerhandbuch enthält weiterhin Informationen zum [DynamoDB Encryption Client](legacy-dynamodb-encryption-client.md). | [Um eine durchsuchbare Verschlüsselung in Ihrer Datenbank zu implementieren, müssen Sie einen AWS KMS hierarchischen Schlüsselbund verwenden.](use-hierarchical-keyring.md) Der AWS KMS hierarchische Schlüsselbund generiert, verschlüsselt und entschlüsselt die Datenschlüssel, die zum Schutz Ihrer Datensätze verwendet werden. Er erstellt auch den Beacon-Schlüssel, der zur Generierung von Beacons verwendet wird. Wenn Sie den AWS KMS hierarchischen Schlüsselbund mit Datenbanken mit mehreren Mandanten verwenden, gibt es für jeden Mandanten einen eigenen Branch- und Beacon-Schlüssel. Um verschlüsselte Daten in einer Multitenant-Datenbank abzufragen, müssen Sie die Beacon-Schlüsselmaterialien identifizieren, die zur Generierung des abgefragten Beacons verwendet wurden. Weitere Informationen finden Sie unter [Verwendung des hierarchischen Schlüsselbunds für durchsuchbare Verschlüsselung](use-hierarchical-keyring.md#searchable-encryption-hierarchical-keyrings). Wenn Sie die [Beacon-Version](using-beacons.md#beacon-version) für eine Multitenant-Datenbank definieren, geben Sie eine Liste aller von Ihnen konfigurierten Standard-Beacons, eine Liste aller von Ihnen konfigurierten Verbund-Beacons, eine Beacon-Version und eine an. `keySource` Sie müssen [Ihre Beacon-Schlüsselquelle als eine `MultiKeyStore` Cache-Gültigkeitsdauer für den lokalen Beacon-Schlüssel-Cache und eine maximale Cachegröße für den lokalen Beacon-Schlüssel-Cache definieren](use-hierarchical-keyring.md#beacon-key-source) und diese angeben. `keyFieldName` Wenn Sie [signierte Beacons](configure.md#signed-beacons) konfiguriert haben, müssen diese in Ihrem enthalten sein. `compoundBeaconList` Signierte Beacons sind eine Art von zusammengesetzten Beacons, die komplexe Abfragen von End-Feldern indizieren und ausführen. `SIGN_ONLY` `SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT` ------ #### [ Java ] ``` List beaconVersions = new ArrayList<>(); beaconVersions.add( BeaconVersion.builder() .standardBeacons(standardBeaconList) .compoundBeacons(compoundBeaconList) .version(1) // MUST be 1 .keyStore(branchKeyStoreName) .keySource(BeaconKeySource.builder() .multi(MultiKeyStore.builder() .keyFieldName(keyField) .cacheTTL(6000) .maxCacheSize(10) .build()) .build()) .build() ); ``` ------ #### [ C\$1 / .NET ] ``` var beaconVersions = new List { new BeaconVersion { StandardBeacons = standardBeaconList, CompoundBeacons = compoundBeaconList, EncryptedParts = encryptedPartsList, SignedParts = signedPartsList, Version = 1, // MUST be 1 KeyStore = branchKeyStoreName, KeySource = new BeaconKeySource { Multi = new MultiKeyStore { KeyId = branch-key-id, CacheTTL = 6000, MaxCacheSize = 10 } } } }; ``` ------ #### [ Rust ] ``` let beacon_version = BeaconVersion::builder() .standard_beacons(standard_beacon_list) .compound_beacons(compound_beacon_list) .version(1) // MUST be 1 .key_store(key_store.clone()) .key_source(BeaconKeySource::Multi( MultiKeyStore::builder() // `keyId` references a beacon key. // For every branch key we create in the keystore, // we also create a beacon key. // This beacon key is not the same as the branch key, // but is created with the same ID as the branch key. .key_id(branch_key_id) .cache_ttl(6000) .max_cache_size(10) .build()?, )) .build()?; let beacon_versions = vec![beacon_version]; ``` ------ **keyFieldName** Das [`keyFieldName`](use-hierarchical-keyring.md#keyFieldName)definiert den Namen des Felds, in dem der dem Beacon `branch-key-id` zugeordnete Schlüssel gespeichert wird, der zur Generierung von Beacons für einen bestimmten Mandanten verwendet wurde. Wenn Sie neue Datensätze in Ihre Datenbank schreiben, wird der Beacon-Schlüssel`branch-key-id`, der zur Generierung von Beacons für diesen Datensatz verwendet wurde, in diesem Feld gespeichert. Standardmäßig `keyField` ist das ein konzeptionelles Feld, das nicht explizit in Ihrer Datenbank gespeichert wird. Das AWS Database Encryption SDK identifiziert den `branch-key-id` anhand des verschlüsselten [Datenschlüssels](concepts.md#data-key) in der [Materialbeschreibung](concepts.md#material-description) und speichert den Wert im Konzept`keyField`, sodass Sie in Ihren Compound Beacons und [signierten](configure.md#signed-beacons) Beacons darauf verweisen können. Da die Materialbeschreibung signiert ist, gilt das Konzept `keyField` als signiertes Teil. Sie können das Feld auch als ODER-Feld `keyField` in Ihre kryptografischen Aktionen aufnehmen, um das `SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT` Feld explizit in Ihrer Datenbank zu speichern. `SIGN_ONLY` In diesem Fall müssen Sie das `branch-key-id` in `keyField` jedes Mal, wenn Sie einen Datensatz in Ihre Datenbank schreiben, manuell hinzufügen. ## Abfragen von Beacons in einer mandantenfähigen Datenbank Um ein Beacon abzufragen, müssen Sie das `keyField` in Ihre Abfrage aufnehmen, um die entsprechenden Beacon-Schlüsselmaterialien zu identifizieren, die für die Neuberechnung des Beacons erforderlich sind. Sie müssen den Schlüssel angeben, der dem Beacon `branch-key-id` zugeordnet ist, der zur Generierung der Beacons für einen Datensatz verwendet wurde. Sie können den [Anzeigenamen, der den Namen](use-hierarchical-keyring.md#branch-key-id-supplier) eines Mandanten identifiziert, nicht `branch-key-id` in der Branch-Schlüssel-ID angeben. Sie können den auf folgende Weise `keyField` in Ihre Abfragen einbeziehen. **Zusammengesetzte Beacons** Unabhängig davon, ob Sie sie explizit `keyField` in Ihren Aufzeichnungen speichern oder nicht, können Sie sie `keyField` direkt als signierten Teil in Ihre Compound-Beacons aufnehmen. Der `keyField` signierte Teil muss erforderlich sein. Wenn Sie beispielsweise ein Verbundsignal aus zwei Feldern erstellen möchten`compoundBeacon`, müssen Sie auch das `keyField` als signierten Teil angeben. `encryptedField` `signedField` Auf diese Weise können Sie die folgende Abfrage ausführen`compoundBeacon`. ``` compoundBeacon = E_encryptedFieldValue.S_signedFieldValue.K_branch-key-id ``` **Signierte Beacons** Das AWS Database Encryption SDK verwendet Standard- und Verbundbeacons, um durchsuchbare Verschlüsselungslösungen bereitzustellen. Diese Beacons müssen mindestens ein verschlüsseltes Feld enthalten. Das AWS Database Encryption SDK unterstützt jedoch auch [signierte Beacons](configure.md#signed-beacons), die vollständig aus Klartext `SIGN_ONLY` und Feldern konfiguriert werden können. `SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT` Signierte Beacons können aus einem einzigen Teil aufgebaut werden. Unabhängig davon, ob Sie das explizit `keyField` in Ihren Aufzeichnungen speichern oder nicht, können Sie daraus ein signiertes Beacon erstellen `keyField` und es verwenden, um zusammengesetzte Abfragen zu erstellen, die eine Abfrage auf dem `keyField` signierten Beacon mit einer Abfrage auf einem Ihrer anderen Beacons kombinieren. Sie könnten beispielsweise die folgende Abfrage ausführen. ``` keyField = K_branch-key-id AND compoundBeacon = E_encryptedFieldValue.S_signedFieldValue ``` Hilfe zur Konfiguration signierter Beacons finden Sie unter [Signierte Beacons erstellen](configure.md#signed-beacons) **Fragen Sie direkt auf dem `keyField`** Wenn Sie das `keyField` in Ihren kryptografischen Aktionen angegeben und das Feld explizit in Ihrem Datensatz gespeichert haben, können Sie eine zusammengesetzte Abfrage erstellen, die eine Abfrage auf Ihrem Beacon mit einer Abfrage auf dem kombiniert. `keyField` Sie können eine direkte Abfrage auf dem wählen, `keyField` wenn Sie ein Standard-Beacon abfragen möchten. Sie könnten beispielsweise die folgende Abfrage ausführen. ``` keyField = branch-key-id AND standardBeacon = S_standardBeaconValue ```