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.

AWS KMS Hierarchische Schlüsselringe

Mit dem AWS KMS hierarchischen Schlüsselbund können Sie Ihre kryptografischen Materialien mit einem KMS-Schlüssel für die symmetrische Verschlüsselung schützen, ohne AWS KMS jedes Mal aufrufen zu müssen, wenn Sie einen Datensatz ver- oder entschlüsseln. Es ist eine gute Wahl für Anwendungen, die möglichst wenige Aufrufe benötigen, und für Anwendungen AWS KMS, die einige kryptografische Materialien wiederverwenden können, ohne ihre Sicherheitsanforderungen zu verletzen.

Beim hierarchischen Schlüsselbund handelt es sich um eine Lösung zum Zwischenspeichern kryptografischer Materialien, die die Anzahl der AWS KMS Aufrufe reduziert, indem AWS KMS geschützte Zweigschlüssel verwendet werden, die in einer Amazon DynamoDB-Tabelle gespeichert sind, und anschließend das für Verschlüsselungs- und Entschlüsselungsvorgänge verwendete Zweigschlüsselmaterial lokal zwischenspeichert. Die DynamoDB-Tabelle dient als Schlüsselspeicher, der Zweigschlüssel verwaltet und schützt. Sie speichert den aktiven Zweigschlüssel und alle früheren Versionen des Zweigschlüssels. Der aktive Filialschlüssel ist die neueste Version des Zweigschlüssels. Der hierarchische Schlüsselbund verwendet für jede Verschlüsselungsanforderung einen eindeutigen Datenverschlüsselungsschlüssel und verschlüsselt jeden Datenverschlüsselungsschlüssel mit einem eindeutigen Umschließungsschlüssel, der vom aktiven Zweigschlüssel abgeleitet wird. Der hierarchische Schlüsselbund hängt von der Hierarchie ab, die zwischen aktiven Zweigschlüsseln und ihren abgeleiteten Umhüllungsschlüsseln eingerichtet wurde.

Der hierarchische Schlüsselbund verwendet in der Regel jede Zweigschlüsselversion, um mehrere Anforderungen zu erfüllen. Sie steuern jedoch, in welchem Umfang aktive Abzweigschlüssel wiederverwendet werden, und bestimmen, wie oft der aktive Abzweigschlüssel rotiert wird. Die aktive Version der Abzweigtaste bleibt aktiv, bis Sie sie Drehe deinen aktiven Filialschlüssel drehen. Frühere Versionen des aktiven Zweigschlüssels werden nicht für Verschlüsselungsvorgänge verwendet, können aber trotzdem abgefragt und bei Entschlüsselungsvorgängen verwendet werden.

Wenn Sie den hierarchischen Schlüsselbund instanziieren, wird ein lokaler Cache erstellt. Sie geben ein Cache-Limit an, das die maximale Zeitdauer definiert, für die die Branch-Key-Materialien im lokalen Cache gespeichert werden, bevor sie ablaufen und aus dem Cache entfernt werden. Der hierarchische Schlüsselbund führt einen AWS KMS Aufruf durch, um den Zweigschlüssel zu entschlüsseln und die Zweigschlüsselmaterialien zusammenzustellen, wenn a zum ersten Mal in einer Operation angegeben branch-key-id wird. Anschließend werden die Zweigschlüsselmaterialien im lokalen Cache gespeichert und für alle Verschlüsselungs- und Entschlüsselungsvorgänge, die dies angeben, wiederverwendet, bis das Cache-Limit abläuft. branch-key-id Das Speichern von Zweigschlüsselmaterial im lokalen Cache reduziert die Anzahl der Aufrufe. AWS KMS Stellen Sie sich beispielsweise ein Cache-Limit von 15 Minuten vor. Wenn Sie 10.000 Verschlüsselungsvorgänge innerhalb dieses Cache-Limits ausführen, müsste der herkömmliche AWS KMS Schlüsselbund 10.000 AWS KMS Aufrufe tätigen, um 10.000 Verschlüsselungsvorgänge abzuwickeln. Wenn Sie einen aktiven Schlüsselbund habenbranch-key-id, muss der hierarchische Schlüsselbund nur einen AWS KMS Aufruf tätigen, um 10.000 Verschlüsselungsvorgänge abzuwickeln.

Der lokale Cache trennt Verschlüsselungsmaterial von Entschlüsselungsmaterial. Das Verschlüsselungsmaterial wird aus dem aktiven Zweigschlüssel zusammengestellt und für alle Verschlüsselungsvorgänge wiederverwendet, bis das Cache-Limit abläuft. Die Entschlüsselungsmaterialien werden aus der Zweigschlüssel-ID und der Version zusammengestellt, die in den Metadaten des verschlüsselten Felds identifiziert sind. Sie werden für alle Entschlüsselungsvorgänge im Zusammenhang mit der Zweigschlüssel-ID und Version wiederverwendet, bis das Cache-Limit abläuft. Der lokale Cache kann mehrere Versionen desselben Zweigschlüssels gleichzeitig speichern. Wenn der lokale Cache für die Verwendung von a konfiguriert istbranch key ID supplier, kann er auch Filialschlüsselmaterial aus mehreren aktiven Zweigschlüsseln gleichzeitig speichern.

Funktionsweise

In den folgenden exemplarischen Vorgehensweisen wird beschrieben, wie der hierarchische Schlüsselbund Verschlüsselungs- und Entschlüsselungsmaterialien zusammenstellt und welche verschiedenen Aufrufe der Schlüsselbund für Verschlüsselungs- und Entschlüsselungsvorgänge ausführt. Technische Details zu den Verfahren zur Ableitung von Wrapping-Schlüsseln und zur Verschlüsselung von Klartext-Datenschlüsseln finden Sie unter Technische Details zum hierarchischen Schlüsselbund. AWS KMS

Verschlüsseln und signieren

In der folgenden exemplarischen Vorgehensweise wird beschrieben, wie der hierarchische Schlüsselbund Verschlüsselungsmaterialien zusammenstellt und daraus einen eindeutigen Umschließungsschlüssel ableitet.

Entschlüsseln und verifizieren

In der folgenden exemplarischen Vorgehensweise wird beschrieben, wie der hierarchische Schlüsselbund Entschlüsselungsmaterial zusammenstellt und den verschlüsselten Datenschlüssel entschlüsselt.

Voraussetzungen

Bevor Sie einen hierarchischen Schlüsselbund erstellen und verwenden, stellen Sie sicher, dass die folgenden Voraussetzungen erfüllt sind.

Erforderliche Berechtigungen

Das AWS Database Encryption SDK benötigt keine AWS-Konto und ist von keiner abhängig AWS-Service. Um jedoch einen hierarchischen Schlüsselbund verwenden zu können, benötigen Sie eine AWS-Konto und die folgenden Mindestberechtigungen für die symmetrische (n) Verschlüsselung AWS KMS key(en) in Ihrem Schlüsselspeicher.

Weitere Informationen zur Steuerung des Zugriffs auf Ihre Filialschlüssel und Ihren Schlüsselspeicher finden Sie unterImplementieren der geringsten Berechtigungen.

Wählen Sie einen Cache

Der hierarchische Schlüsselbund reduziert die Anzahl der Aufrufe, AWS KMS indem das bei Ver- und Entschlüsselungsvorgängen verwendete Zweigschlüsselmaterial lokal zwischengespeichert wird. Bevor Sie Ihren hierarchischen Schlüsselbund erstellen, müssen Sie entscheiden, welche Art von Cache Sie verwenden möchten. Sie können den Standard-Cache verwenden oder den Cache an Ihre Bedürfnisse anpassen.

Der hierarchische Schlüsselbund unterstützt die folgenden Cachetypen:

Standard-Cache

Für die meisten Benutzer erfüllt der Standard-Cache ihre Threading-Anforderungen. Der Standard-Cache ist so konzipiert, dass er Umgebungen mit hohem Multithreading-Anteil unterstützt. Wenn ein Eintrag für Branch Key Materials abläuft, verhindert der Standard-Cache den Aufruf mehrerer Threads, AWS KMS indem er einen Thread darüber informiert, dass der Eintrag für Branch Key Materials 10 Sekunden im Voraus abläuft. Dadurch wird sichergestellt, dass nur ein Thread eine Anfrage AWS KMS zur Aktualisierung des Caches sendet.

Der Default und die StormTracking Caches unterstützen dasselbe Threading-Modell, aber Sie müssen nur die Eingangskapazität angeben, um den Standard-Cache verwenden zu können. Für detailliertere Cache-Anpassungen verwenden Sie die. StormTracking zwischenspeichern

Sofern Sie nicht die Anzahl der Materialeinträge für Branch Key anpassen möchten, die im lokalen Cache gespeichert werden können, müssen Sie bei der Erstellung des hierarchischen Schlüsselbundes keinen Cachetyp angeben. Wenn Sie keinen Cachetyp angeben, verwendet der hierarchische Schlüsselbund den Standard-Cachetyp und legt die Eintragskapazität auf 1000 fest.

Um den Standard-Cache anzupassen, geben Sie die folgenden Werte an:

Java

.cache(CacheType.builder()
        .Default(DefaultCache.builder()
        .entryCapacity(100)
        .build())

C# / .NET

CacheType defaultCache = new CacheType
{
    Default = new DefaultCache{EntryCapacity = 100}
};

Rust

let cache: CacheType = CacheType::Default(
    DefaultCache::builder()
        .entry_capacity(100)
        .build()?,
);

MultiThreaded Cache

Der MultiThreaded Cache kann sicher in Multithread-Umgebungen verwendet werden, bietet jedoch keine Funktionen zur Minimierung AWS KMS von Amazon DynamoDB-Aufrufen. Daher werden alle Threads gleichzeitig benachrichtigt, wenn ein Eintrag zu Branch Key Materials abläuft. Dies kann zu mehreren AWS KMS Aufrufen zur Aktualisierung des Caches führen.

Um den MultiThreaded Cache zu verwenden, geben Sie die folgenden Werte an:

Java

.cache(CacheType.builder()
        .MultiThreaded(MultiThreadedCache.builder()
        .entryCapacity(100)
        .entryPruningTailSize(1)                                        
        .build())

C# / .NET

CacheType multithreadedCache = new CacheType
{
    MultiThreaded = new MultiThreadedCache
    {
        EntryCapacity = 100,
        EntryPruningTailSize = 1
    }
};

Rust

CacheType::MultiThreaded(
            MultiThreadedCache::builder()
                    .entry_capacity(100)
                    .entry_pruning_tail_size(1)
                    .build()?)

StormTracking zwischenspeichern

Der StormTracking Cache ist so konzipiert, dass er Umgebungen mit hohem Multithreading-Anteil unterstützt. Wenn ein Eintrag für Branch Key Materials abläuft, verhindert der StormTracking Cache, dass mehrere Threads aufgerufen AWS KMS werden, indem er einen Thread im Voraus darüber informiert, dass der Branch Key Materials Eintrag abläuft. Dadurch wird sichergestellt, dass nur ein Thread eine Anfrage AWS KMS zum Aktualisieren des Caches sendet.

Um den StormTracking Cache zu verwenden, geben Sie die folgenden Werte an:

Java

.cache(CacheType.builder()
        .StormTracking(StormTrackingCache.builder()
        .entryCapacity(100)
        .entryPruningTailSize(1)
        .gracePeriod(10)
        .graceInterval(1)
        .fanOut(20) 
        .inFlightTTL(10)
        .sleepMilli(20)                                        
        .build())

C# / .NET

CacheType stormTrackingCache = new CacheType
{
    StormTracking = new StormTrackingCache
    {
        EntryCapacity = 100,
        EntryPruningTailSize = 1,
        FanOut = 20,
        GraceInterval = 1,
        GracePeriod = 10,
        InFlightTTL = 10,
        SleepMilli = 20
    }
};

Rust

CacheType::StormTracking(
                StormTrackingCache::builder()
                    .entry_capacity(100)
                    .entry_pruning_tail_size(1)
                    .grace_period(10)
                    .grace_interval(1)
                    .fan_out(20)
                    .in_flight_ttl(10)
                    .sleep_milli(20)
                    .build()?)

Gemeinsam genutzter Cache

Standardmäßig erstellt der hierarchische Schlüsselbund jedes Mal, wenn Sie den Schlüsselbund instanziieren, einen neuen lokalen Cache. Der gemeinsame Cache kann jedoch dazu beitragen, Speicherplatz zu sparen, indem er es Ihnen ermöglicht, einen Cache über mehrere hierarchische Schlüsselringe hinweg gemeinsam zu nutzen. Anstatt für jeden hierarchischen Schlüsselbund, den Sie instanziieren, einen neuen Cache für kryptografische Materialien zu erstellen, speichert der gemeinsame Cache nur einen Cache im Speicher, der von allen hierarchischen Schlüsselbunden verwendet werden kann, die auf ihn verweisen. Der gemeinsame Cache trägt zur Optimierung der Speichernutzung bei, indem verhindert wird, dass kryptografisches Material über mehrere Schlüsselringe hinweg dupliziert wird. Stattdessen können die hierarchischen Schlüsselringe auf denselben zugrundeliegenden Cache zugreifen, wodurch der gesamte Speicherbedarf reduziert wird.

Wenn Sie Ihren gemeinsamen Cache erstellen, definieren Sie trotzdem den Cachetyp. Sie können einen Standard-Cache oder StormTracking zwischenspeichern als Cachetyp angeben oder einen beliebigen kompatiblen benutzerdefinierten Cache ersetzen. MultiThreaded Cache

Partitionen

Mehrere hierarchische Schlüsselringe können einen einzigen gemeinsamen Cache verwenden. Wenn Sie einen hierarchischen Schlüsselbund mit einem gemeinsamen Cache erstellen, können Sie eine optionale Partitions-ID definieren. Die Partitions-ID unterscheidet, welcher hierarchische Schlüsselbund in den Cache schreibt. Wenn zwei hierarchische Schlüsselringe auf dieselbe Partitions-ID und Zweigschlüssel-ID verweisenlogical key store name, teilen sich die beiden Schlüsselringe dieselben Cache-Einträge im Cache. Wenn Sie zwei hierarchische Schlüsselringe mit demselben gemeinsamen Cache, aber unterschiedlichen Partitions-IDs erstellen, greift jeder Schlüsselbund nur auf die Cache-Einträge von seiner eigenen angegebenen Partition innerhalb des gemeinsamen Caches zu. Die Partitionen fungieren als logische Unterteilungen innerhalb des gemeinsamen Caches, sodass jeder hierarchische Schlüsselbund unabhängig auf seiner eigenen zugewiesenen Partition arbeiten kann, ohne die in der anderen Partition gespeicherten Daten zu beeinträchtigen.

Wenn Sie beabsichtigen, die Cache-Einträge in einer Partition wiederzuverwenden oder gemeinsam zu nutzen, müssen Sie Ihre eigene Partitions-ID definieren. Wenn Sie die Partitions-ID an Ihren hierarchischen Schlüsselbund übergeben, kann der Schlüsselbund die Cache-Einträge, die bereits im gemeinsamen Cache vorhanden sind, wiederverwenden, sodass Sie das Zweigschlüsselmaterial nicht erneut abrufen und autorisieren müssen. Wenn Sie keine Partitions-ID angeben, wird dem Schlüsselbund jedes Mal, wenn Sie den hierarchischen Schlüsselbund instanziieren, automatisch eine eindeutige Partitions-ID zugewiesen.

Erstellen Sie einen hierarchischen Schlüsselbund

Um einen hierarchischen Schlüsselbund zu erstellen, müssen Sie die folgenden Werte angeben:

Die folgenden Beispiele zeigen, wie ein Schlüsselspeicher mit einer statischen Konfiguration konfiguriert wird. Wählen Sie Ihre bevorzugte Sprache:

Java

import software.amazon.awssdk.services.dynamodb.DynamoDbClient;
import software.amazon.awssdk.services.kms.KmsClient;
import software.amazon.cryptography.keystore.KeyStore;
import software.amazon.cryptography.keystore.model.KeyStoreConfig;
import software.amazon.cryptography.keystore.model.KMSConfiguration;

final KeyStore keystore = KeyStore.builder()
        .KeyStoreConfig(KeyStoreConfig.builder()
                .ddbClient(DynamoDbClient.create())
                .ddbTableName(keyStoreName)
                .logicalKeyStoreName(logicalKeyStoreName)
                .kmsClient(KmsClient.create())
                .kmsConfiguration(KMSConfiguration.builder()
                        .kmsKeyArn(kmsKeyArn)
                        .build())
                .build())
        .build();

C# / .NET

using Amazon.DynamoDBv2;
using Amazon.KeyManagementService;
using AWS.Cryptography.KeyStore;

var kmsConfig = new KMSConfiguration { KmsKeyArn = kmsKeyArn };
var keystoreConfig = new KeyStoreConfig
{
    KmsClient = new AmazonKeyManagementServiceClient(),
    KmsConfiguration = kmsConfig,
    DdbTableName = keyStoreName,
    DdbClient = new AmazonDynamoDBClient(),
    LogicalKeyStoreName = logicalKeyStoreName
};
var keystore = new KeyStore(keystoreConfig);

Rust

use aws_db_esdk::key_store::client as keystore_client;
use aws_db_esdk::key_store::types::key_store_config::KeyStoreConfig;
use aws_db_esdk::key_store::types::KmsConfiguration;

let sdk_config = aws_config::load_defaults(aws_config::BehaviorVersion::latest()).await;
let key_store_config = KeyStoreConfig::builder()
    .kms_client(aws_sdk_kms::Client::new(&sdk_config))
    .ddb_client(aws_sdk_dynamodb::Client::new(&sdk_config))
    .ddb_table_name(key_store_name)
    .logical_key_store_name(logical_key_store_name)
    .kms_configuration(KmsConfiguration::KmsKeyArn(kms_key_arn.to_string()))
    .build()?;

let keystore = keystore_client::Client::from_conf(key_store_config)?;

Nachdem Sie Ihren Schlüsselspeicher konfiguriert haben, verwenden Sie das resultierende Schlüsselspeicherobjekt, um Ihren hierarchischen Schlüsselbund zu erstellen. In den folgenden Beispielen für hierarchische Schlüsselringe wird das von Ihnen konfigurierte Schlüsselspeicherobjekt verwendet.

Verwendung des hierarchischen Schlüsselbundes für eine durchsuchbare Verschlüsselung

Durchsuchbare VerschlüsselungMit der durchsuchbaren Verschlüsselung können Sie nach verschlüsselten Datensätzen suchen, ohne die gesamte Datenbank zu entschlüsseln. Dies wird erreicht, indem der Klartextwert eines verschlüsselten Felds mit einem Beacon indexiert wird. Leuchtfeuer Um eine durchsuchbare Verschlüsselung zu implementieren, müssen Sie einen hierarchischen Schlüsselbund verwenden.

Bei der CreateKey Schlüsselspeicheroperation werden sowohl ein Abzweigschlüssel als auch ein Beacon-Schlüssel generiert. Der Zweigschlüssel wird für Verschlüsselungs- und Entschlüsselungsvorgänge von Datensätzen verwendet. Der Beacon-Schlüssel wird zum Generieren von Beacons verwendet.

Der Zweigschlüssel und der Beacon-Schlüssel sind durch denselben Schutz geschützt AWS KMS key , den Sie bei der Erstellung Ihres Schlüsselspeicherdienstes angegeben haben. Nachdem der CreateKey Vorgang AWS KMS zur Generierung des Zweigschlüssels aufgerufen hat, ruft er kms: GenerateDataKeyWithoutPlaintext ein zweites Mal auf, um den Beacon-Schlüssel mithilfe der folgenden Anforderung zu generieren.

{
   "EncryptionContext": { 
      "branch-key-id" : "branch-key-id",
      "type" : type,
      "create-time" : "timestamp",
      "tablename" : "the logical table name for your key store",
      "kms-arn" : the KMS key ARN,
      "hierarchy-version" : 1
   },
   "KeyId": "the KMS key ARN",
   "NumberOfBytes": "32"
}

Nachdem beide Schlüssel generiert wurden, ruft die CreateKey Operation ddb: TransactWriteItems auf, um zwei neue Elemente zu schreiben, die den Branch Key und den Beacon-Schlüssel in Ihrem Branch Key Store beibehalten.

Wenn Sie ein Standard-Beacon konfigurieren, fragt das AWS Database Encryption SDK den Schlüsselspeicher nach dem Beacon-Schlüssel ab. Anschließend verwendet es eine Funktion zum HMAC-based Extrahieren und Erweitern der Schlüsselableitung (HKDF), um den Beacon-Schlüssel mit dem Namen des Standard-Beacons zu kombinieren, um den HMAC-Schlüssel für ein bestimmtes Beacon zu erstellen.

Im Gegensatz zu Branch-Schlüsseln gibt es in einem Schlüsselspeicher nur eine Beacon-Schlüsselversion pro Schlüssel. branch-key-id Der Beacon-Schlüssel wird niemals gedreht.

Definieren Sie die Quelle Ihres Beacon-Schlüssels

Wenn Sie die Beacon-Version für Ihre Standard- und Compound-Beacons definieren, müssen Sie den Beacon-Schlüssel identifizieren und eine Cache-Limit Time to Live (TTL) für die Beacon-Schlüsselmaterialien definieren. Die Beacon-Schlüsselmaterialien werden in einem von den Branch-Schlüsseln getrennten lokalen Cache gespeichert. Der folgende Ausschnitt zeigt, wie das keySource für eine Single-Tenant-Datenbank definiert wird. Identifizieren Sie Ihren Beacon-Schlüssel anhand dessen, mit dem branch-key-id er verknüpft ist.

Java

keySource(BeaconKeySource.builder()
        .single(SingleKeyStore.builder()
                .keyId(branch-key-id)
                .cacheTTL(6000)
                .build())
        .build())

C# / .NET

KeySource = new BeaconKeySource
{
    Single = new SingleKeyStore
    {
       KeyId = branch-key-id,
       CacheTTL = 6000
    }
}

Rust

 .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()?,
))