

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.

# Konfiguration des Database Encryption SDK AWS
<a name="configure"></a>


****  

|  | 
| --- |
| 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). | 

Das AWS Database Encryption SDK ist so konzipiert, dass es einfach zu bedienen ist. Obwohl das AWS Database Encryption SDK über mehrere Konfigurationsoptionen verfügt, wurden die Standardwerte sorgfältig ausgewählt, damit sie für die meisten Anwendungen praktisch und sicher sind. Möglicherweise müssen Sie jedoch Ihre Konfiguration anpassen, um die Leistung zu verbessern, oder eine benutzerdefinierte Funktion in Ihr Design aufnehmen.

**Topics**
+ [Auswahl einer Programmiersprache](#config-language)
+ [Auswahl von Wraping-Schlüsseln](#config-keys)
+ [Einen Discovery-Filter erstellen](#config-discovery)
+ [Arbeiten mit Mehrmandantendatenbanken](#config-multitenant-databases)
+ [Signierte Beacons erstellen](#signed-beacons)

## Auswahl einer Programmiersprache
<a name="config-language"></a>

Das AWS Database Encryption SDK für DynamoDB ist in mehreren [Programmiersprachen](ddb-programming-languages.md) verfügbar. Die Sprachimplementierungen sind so konzipiert, dass sie vollständig interoperabel sind und dieselben Funktionen bieten, obwohl sie möglicherweise auf unterschiedliche Weise implementiert werden. In der Regel verwenden Sie die Bibliothek, die mit Ihrer Anwendung kompatibel ist.

## Auswahl von Wraping-Schlüsseln
<a name="config-keys"></a>

Das AWS Database Encryption SDK generiert einen eindeutigen symmetrischen Datenschlüssel, um jedes Feld zu verschlüsseln. Sie müssen die Datenschlüssel nicht konfigurieren, verwalten oder verwenden. Das AWS Database Encryption SDK erledigt das für Sie.

Sie müssen jedoch einen oder mehrere Wrapping-Schlüssel auswählen, um jeden Datenschlüssel zu verschlüsseln. Das AWS Database Encryption SDK unterstützt [AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/)(AWS KMS) symmetrische Verschlüsselungs-KMS-Schlüssel und asymmetrische RSA-KMS-Schlüssel. Es unterstützt auch symmetrische AES-Schlüssel und asymmetrische RSA-Schlüssel, die Sie in verschiedenen Größen bereitstellen. Sie sind für die Sicherheit und Haltbarkeit Ihrer Wrapping-Schlüssel verantwortlich. Wir empfehlen Ihnen daher, einen Verschlüsselungsschlüssel in einem Hardware-Sicherheitsmodul oder einem wichtigen Infrastrukturdienst zu verwenden, wie z. AWS KMS

Um Ihre Verpackungsschlüssel für die Verschlüsselung und Entschlüsselung anzugeben, verwenden Sie einen [Schlüsselbund](concepts.md#keyring-concept). Je nach [Art des verwendeten Schlüsselbundes können Sie einen Wrapping-Schlüssel](keyrings.md) oder mehrere Wrap-Schlüssel desselben oder verschiedener Typen angeben. Wenn Sie für den Umbruch eines Datenschlüssels mehrere Schlüssel verwenden, verschlüsselt jeder Umbruchschlüssel eine Kopie desselben Datenschlüssels. Die verschlüsselten Datenschlüssel (einer pro Umschließungsschlüssel) werden in der [Materialbeschreibung](concepts.md#material-description) gespeichert, die neben dem verschlüsselten Feld gespeichert wird. Um die Daten zu entschlüsseln, muss das AWS Database Encryption SDK zunächst einen Ihrer Verpackungsschlüssel verwenden, um einen verschlüsselten Datenschlüssel zu entschlüsseln. 

Wir empfehlen, wann immer möglich, einen der AWS KMS Schlüsselringe zu verwenden. Das AWS Database Encryption SDK stellt den [AWS KMS Schlüsselbund](use-kms-keyring.md) und den [AWS KMS hierarchischen Schlüsselbund](use-hierarchical-keyring.md) bereit, wodurch die Anzahl der Aufrufe reduziert wird. AWS KMS Um einen AWS KMS key in einem Schlüsselbund anzugeben, verwenden Sie eine unterstützte Schlüssel-ID. AWS KMS Wenn Sie den AWS KMS hierarchischen Schlüsselbund verwenden, müssen Sie den Schlüssel-ARN angeben. *Einzelheiten zu den Schlüsselbezeichnern für einen AWS KMS Schlüssel finden Sie unter [Schlüsselkennungen](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#key-id) im Entwicklerhandbuch.AWS Key Management Service *
+ Wenn Sie mit einem AWS KMS Schlüsselbund verschlüsseln, können Sie eine beliebige gültige Schlüssel-ID (Schlüssel-ARN, Aliasname, Alias-ARN oder Schlüssel-ID) für einen KMS-Schlüssel mit symmetrischer Verschlüsselung angeben. Wenn Sie einen asymmetrischen RSA-KMS-Schlüssel verwenden, müssen Sie den Schlüssel-ARN angeben.

  Wenn Sie bei der Verschlüsselung einen Aliasnamen oder Alias-ARN für einen KMS-Schlüssel angeben, speichert das AWS Database Encryption SDK den Schlüssel-ARN, der derzeit mit diesem Alias verknüpft ist; es speichert den Alias nicht. Änderungen am Alias wirken sich nicht auf den KMS-Schlüssel aus, der zum Entschlüsseln Ihrer Datenschlüssel verwendet wird.
+ Standardmäßig entschlüsselt der AWS KMS Schlüsselbund Datensätze im strikten Modus (in dem Sie bestimmte KMS-Schlüssel angeben). Sie müssen einen Schlüssel-ARN verwenden, um sich AWS KMS keys für die Entschlüsselung zu identifizieren.

  Wenn Sie mit einem AWS KMS Schlüsselbund verschlüsseln, speichert das AWS Database Encryption SDK den Schlüssel ARN von AWS KMS key in der Materialbeschreibung zusammen mit dem verschlüsselten Datenschlüssel. Bei der Entschlüsselung im strikten Modus überprüft das AWS Database Encryption SDK, ob derselbe Schlüssel-ARN im Schlüsselbund erscheint, bevor es versucht, den Wrapping-Schlüssel zum Entschlüsseln des verschlüsselten Datenschlüssels zu verwenden. Wenn Sie eine andere Schlüssel-ID verwenden, erkennt oder verwendet das AWS Database Encryption SDK diese nicht AWS KMS key, auch wenn sich die Kennungen auf denselben Schlüssel beziehen.
+ Beim Entschlüsseln im [Discovery-Modus](#config-discovery) geben Sie keine Wrapping-Schlüssel an. Zunächst versucht das AWS Database Encryption SDK, den Datensatz mit dem Schlüssel ARN zu entschlüsseln, der in der Materialbeschreibung gespeichert ist. Wenn das nicht funktioniert, fordert das AWS Database Encryption SDK auf, den Datensatz mit dem KMS-Schlüssel AWS KMS zu entschlüsseln, mit dem er verschlüsselt wurde, unabhängig davon, wem dieser KMS-Schlüssel gehört oder wer Zugriff darauf hat.

Um einen [AES-Rohschlüssel](use-raw-aes-keyring.md) oder ein [RSA-Rohschlüsselpaar](use-raw-rsa-keyring.md) als Umschließungsschlüssel in einem Schlüsselbund anzugeben, müssen Sie einen Namespace und einen Namen angeben. Beim Entschlüsseln müssen Sie für jeden Rohverpackungsschlüssel genau denselben Namespace und denselben Namen verwenden wie beim Verschlüsseln. Wenn Sie einen anderen Namespace oder Namen verwenden, erkennt oder verwendet das AWS Database Encryption SDK den Wrapping-Schlüssel nicht, selbst wenn das Schlüsselmaterial identisch ist.

## Einen Discovery-Filter erstellen
<a name="config-discovery"></a>

Beim Entschlüsseln von Daten, die mit KMS-Schlüsseln verschlüsselt wurden, hat es sich bewährt, im *strikten Modus* zu entschlüsseln, d. h., die verwendeten Wrapping-Schlüssel auf die von Ihnen angegebenen zu beschränken. Bei Bedarf können Sie jedoch auch im *Discovery-Modus* entschlüsseln, in dem Sie keine Umschließungsschlüssel angeben. In diesem Modus AWS KMS können Sie den verschlüsselten Datenschlüssel mithilfe des KMS-Schlüssels entschlüsseln, mit dem er verschlüsselt wurde, unabhängig davon, wem dieser KMS-Schlüssel gehört oder wer Zugriff darauf hat.

[Wenn Sie im Discovery-Modus entschlüsseln müssen, empfehlen wir, immer einen *Discovery-Filter* zu verwenden, der die KMS-Schlüssel, die verwendet werden können, auf diejenigen beschränkt, die sich in einer bestimmten Partition befinden AWS-Konto .](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html) Der Discovery-Filter ist optional, hat sich aber bewährt.

Verwenden Sie die folgende Tabelle, um den Partitionswert für Ihren Discovery-Filter zu ermitteln.


| Region | Partition | 
| --- | --- | 
| AWS-Regionen | aws | 
| Regionen in China | aws-cn | 
| AWS GovCloud (US) Regions | aws-us-gov | 

Das folgende Beispiel zeigt, wie Sie einen Discovery-Filter erstellen. Bevor Sie den Code verwenden, ersetzen Sie die Beispielwerte durch gültige Werte für Ihre Partition AWS-Konto und.

------
#### [ Java ]

```
// Create the discovery filter
DiscoveryFilter discoveryFilter = DiscoveryFilter.builder()
        .partition("aws")
        .accountIds(111122223333)
        .build();
```

------
#### [ C\$1 / .NET ]

```
var discoveryFilter = new DiscoveryFilter
{
    Partition = "aws",
    AccountIds = 111122223333
};
```

------
#### [ Rust ]

```
// Create discovery filter
let discovery_filter = DiscoveryFilter::builder()
    .partition("aws")
    .account_ids(111122223333)
    .build()?;
```

------

## Arbeiten mit Mehrmandantendatenbanken
<a name="config-multitenant-databases"></a>

Mit dem AWS Database Encryption SDK können Sie die clientseitige Verschlüsselung für Datenbanken mit einem gemeinsamen Schema konfigurieren, indem Sie jeden Mandanten mit unterschiedlichen Verschlüsselungsmaterialien isolieren. Wenn Sie eine mehrinstanzenfähige Datenbank in Betracht ziehen, sollten Sie sich etwas Zeit nehmen, um Ihre Sicherheitsanforderungen zu überprüfen und zu überprüfen, wie sich die Mehrmandantenfähigkeit darauf auswirken könnte. Beispielsweise kann die Verwendung einer Mehrmandantendatenbank Ihre Fähigkeit beeinträchtigen, das AWS Database Encryption SDK mit einer anderen serverseitigen Verschlüsselungslösung zu kombinieren.

Wenn mehrere Benutzer Verschlüsselungsvorgänge in Ihrer Datenbank durchführen, können Sie einen der AWS KMS Schlüsselbunde verwenden, um jedem Benutzer einen eigenen Schlüssel zur Verfügung zu stellen, den er für seine kryptografischen Operationen verwenden kann. Die Verwaltung der Datenschlüssel für eine clientseitige Verschlüsselungslösung mit mehreren Mandanten kann kompliziert sein. Wir empfehlen, Ihre Daten wann immer möglich nach Mandanten zu organisieren. Wenn der Mandant anhand der Primärschlüsselwerte identifiziert wird (z. B. der Partitionsschlüssel in einer Amazon DynamoDB-Tabelle), ist die Verwaltung Ihrer Schlüssel einfacher.

Sie können den [AWS KMS Schlüsselbund](use-kms-keyring.md) verwenden, um jeden Mandanten mit einem eigenen AWS KMS Schlüsselbund und zu isolieren. AWS KMS keys Je nach Anzahl der pro Mandant AWS KMS getätigten Anrufe möchten Sie möglicherweise den AWS KMS hierarchischen Schlüsselbund verwenden, um die Anzahl der Anrufe zu minimieren. AWS KMS Der [AWS KMS hierarchische Schlüsselbund](use-hierarchical-keyring.md) ist eine Lösung zum Zwischenspeichern von kryptografischem Material, die die Anzahl der AWS KMS Aufrufe reduziert, indem AWS KMS geschützte *Branch-Schlüssel* verwendet werden, die in einer Amazon DynamoDB-Tabelle gespeichert sind, und anschließend das lokale Zwischenspeichern von Zweigschlüsselmaterialien, die bei Verschlüsselungs- und Entschlüsselungsvorgängen verwendet werden, erfolgt. [Sie müssen den hierarchischen Schlüsselbund verwenden, um eine durchsuchbare Verschlüsselung in Ihrer Datenbank zu AWS KMS implementieren.](searchable-encryption.md)

## Signierte Beacons erstellen
<a name="signed-beacons"></a>

Das AWS Database Encryption SDK verwendet [Standardbeacons](beacons.md#standard-beacon-overview) und [zusammengesetzte Beacons](beacons.md#compound-beacon-overview), um [durchsuchbare Verschlüsselungslösungen](searchable-encryption.md) bereitzustellen, mit denen Sie verschlüsselte Datensätze durchsuchen können, ohne die gesamte abgefragte Datenbank entschlüsseln zu müssen. Das AWS Database Encryption SDK unterstützt jedoch auch *signierte Beacons, die vollständig aus Klartext-signierten* Feldern konfiguriert werden können. Signierte Beacons sind eine Art von zusammengesetzten Beacons, die komplexe Abfragen von Feldern indizieren und ausführen. `SIGN_ONLY` `SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT`

Wenn Sie beispielsweise über eine Mehrmandantendatenbank verfügen, möchten Sie möglicherweise ein signiertes Beacon erstellen, mit dem Sie Ihre Datenbank nach Datensätzen abfragen können, die mit einem bestimmten Mandantenschlüssel verschlüsselt wurden. Weitere Informationen finden Sie unter [Abfragen von Beacons in einer mandantenfähigen Datenbank](searchable-encryption-multitenant.md#query-multitenant-beacons).

Sie müssen den AWS KMS hierarchischen Schlüsselbund verwenden, um signierte Beacons zu erstellen.

Um ein signiertes Beacon zu konfigurieren, geben Sie die folgenden Werte an.

------
#### [ Java ]

**Konfiguration eines zusammengesetzten Beacons**

Im folgenden Beispiel werden die signierten Teilelisten lokal innerhalb der signierten Beacon-Konfiguration definiert.

```
List<CompoundBeacon> compoundBeaconList = new ArrayList<>();
CompoundBeacon exampleCompoundBeacon = CompoundBeacon.builder()
    .name("compoundBeaconName")
    .split(".") 
    .signed(signedPartList)                       
    .constructors(constructorList) 
    .build();
compoundBeaconList.add(exampleCompoundBeacon);
```

**Definition der Beacon-Version**

Das folgende Beispiel definiert die signierten Teilelisten global in der Beacon-Version. Weitere Informationen zur Definition der Beacon-Version finden Sie unter Beacons [verwenden](using-beacons.md).

```
 List<BeaconVersion> beaconVersions = new ArrayList<>();
beaconVersions.add(
    BeaconVersion.builder()
        .standardBeacons(standardBeaconList)
        .compoundBeacons(compoundBeaconList)
        .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)

**Signierte Beacon-Konfiguration**

Das folgende Beispiel definiert die signierten Teilelisten lokal innerhalb der signierten Beacon-Konfiguration.

```
var compoundBeaconList = new List<CompoundBeacon>();       
var exampleCompoundBeacon = new CompoundBeacon
 {
    Name = "compoundBeaconName",
    Split = ".",
    Signed = signedPartList,                        
    Constructors = constructorList 
 };
compoundBeaconList.Add(exampleCompoundBeacon);
```

**Definition der Beacon-Version**

Das folgende Beispiel definiert die signierten Teilelisten global in der Beacon-Version. Weitere Informationen zur Definition der Beacon-Version finden Sie unter Beacons [verwenden](using-beacons.md).

```
var beaconVersions = new List<BeaconVersion>
{
    new BeaconVersion
    {
        StandardBeacons = standardBeaconList,
        CompoundBeacons = compoundBeaconList,
        SignedParts = signedPartsList,
        Version = 1, // MUST be 1
        KeyStore = keyStore,
        KeySource = new BeaconKeySource
        {
            Single = new SingleKeyStore
            {
                KeyId = branchKeyId,
                CacheTTL = 6000
            }
        }
    }
};
```

------

Sie können Ihre signierten Teile in lokal oder global definierten Listen definieren. Wir empfehlen, Ihre signierten Teile wann immer möglich in einer globalen Liste in der [Beacon-Version](using-beacons.md#beacon-version) zu definieren. Durch die globale Definition signierter Teile können Sie jedes Teil einmal definieren und die Teile dann in mehreren Compound-Beacon-Konfigurationen wiederverwenden. Wenn Sie beabsichtigen, ein signiertes Teil nur einmal zu verwenden, können Sie es in einer lokalen Liste in der signierten Beacon-Konfiguration definieren. Sie können in Ihrer [Konstruktorliste](configure-beacons.md#constructor-parts) sowohl auf lokale als auch auf globale Teile verweisen.

Wenn Sie Ihre signierten Teilelisten global definieren, müssen Sie eine Liste von Konstruktorteilen bereitstellen, die alle Möglichkeiten aufzeigt, wie der signierte Beacon die Felder in Ihrer Beacon-Konfiguration zusammenstellen kann.

**Anmerkung**  
Um 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 signierte Teilelisten global zu definieren.

**Name des Beacons**  
Der Name, den Sie bei der Abfrage des Beacons verwenden.  
Ein signierter Beacon-Name darf nicht derselbe Name wie ein unverschlüsseltes Feld sein. Keine zwei Beacons können denselben Beacon-Namen haben.

**Charakter teilen**  
Das Zeichen, das verwendet wird, um die Teile zu trennen, aus denen Ihr signiertes Beacon besteht.  
Das Trennzeichen darf in den Klartextwerten der Felder, aus denen der signierte Beacon aufgebaut ist, nicht vorkommen.

**Liste der signierten Teile**  
Identifiziert die signierten Felder, die im signierten Beacon enthalten sind.  
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. Keine zwei signierten Teile in einem signierten Beacon dürfen dasselbe Präfix haben. Wir empfehlen, 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 Teil kann nicht dasselbe Präfix oder denselben Namen haben wie ein global definierter Teil.  

```
List<SignedPart> signedPartList = new ArrayList<>();
    SignedPart signedPartExample = SignedPart.builder()
        .name("signedFieldName")
        .prefix("S-")
        .build();
    signedPartList.add(signedPartExample);
```

```
var signedPartsList = new List<SignedPart>
{
    new SignedPart { Name = "signedFieldName1", Prefix = "S-" },
    new SignedPart { Name = "signedFieldName2", Prefix = "SF-" }
};
```

**Konstruktorliste (optional)**  
Identifiziert die *Konstruktoren*, die die verschiedenen Arten definieren, wie die signierten Teile durch den signierten Beacon zusammengebaut werden können.  
Wenn Sie keine Konstruktorliste angeben, baut das AWS Database Encryption SDK den signierten Beacon mit dem folgenden Standardkonstruktor zusammen.  
+ Alle signierten Teile in der Reihenfolge, in der sie der signierten Teileliste hinzugefügt wurden
+ Alle Teile sind erforderlich  
**Konstruktoren**  
Jeder Konstruktor ist eine geordnete Liste von *Konstruktorteilen*, die eine Art und Weise definiert, wie das signierte 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 Teil mit Vorzeichen und definiert, ob dieser Teil innerhalb des Konstruktors erforderlich oder optional ist. Wenn Sie beispielsweise ein signiertes Beacon auf`Field1`, und abfragen möchten `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, bestimmt der signierte Beacon 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 jedes signierte Teil ein Konstruktorteil, um zu definieren, ob dieses Teil erforderlich ist oder nicht.

   Der Name des Konstruktorteils muss der Name des signierten Felds sein.

   Das folgende Beispiel zeigt, wie ein Konstruktorteil für ein signiertes Feld erstellt wird.

------
#### [ Java ]

   ```
   ConstructorPart field1ConstructorPart = ConstructorPart.builder()
           .name("Field1")
           .required(true)
           .build();
   ```

------
#### [ C\$1 / .NET ]

   ```
   var field1ConstructorPart = new ConstructorPart { Name = "Field1", Required = true };
   ```

------

1. **Erstellen Sie einen Konstruktor für jede mögliche Art und Weise, wie das signierte Beacon zusammengebaut werden kann. Verwenden Sie dazu die Konstruktorteile, die Sie in Schritt 1 erstellt haben.**

   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<ConstructorPart> 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<ConstructorPart> 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<ConstructorPart> { field1ConstructorPart, field2ConstructorPart, field3ConstructorPart }
   };
   // Create a list for Field4.Field2.Field1 queries        
   var field421ConstructorPartList = new Constructor
   {
       Parts = new List<ConstructorPart> { field4ConstructorPart, field2ConstructorPart, field1ConstructorPart }
   };
   ```

------

1. **Erstellen Sie eine Konstruktorliste, die alle Konstruktoren enthält, die Sie in Schritt 2 erstellt haben.**

------
#### [ Java ]

   ```
   List<Constructor> constructorList = new ArrayList<>();
   constructorList.add(field123Constructor);
   constructorList.add(field421Constructor);
   ```

------
#### [ C\$1 / .NET ]

   ```
   var constructorList = new List<Constructor>
   {
       field123Constructor,
       field421Constructor
   };
   ```

------

1. Geben Sie an`constructorList`, wann Sie Ihr signiertes Beacon erstellen.