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 Ihr kryptografisches Material mit einem KMS-Schlüssel mit symmetrischer Verschlüsselung schützen, ohne AWS KMS jedes Mal anrufen zu müssen, wenn Sie Daten 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 einen eindeutigen Datenschlüssel, um jede Nachricht zu verschlüsseln. Er verschlüsselt jeden Datenverschlüsselungsschlüssel für jede Verschlüsselungsanforderung und verschlüsselt jeden Datenverschlüsselungsschlüssel mit einem eindeutigen Umhüllungsschlü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.

Kompatibilität mit Programmiersprachen

Der hierarchische Schlüsselbund wird von den folgenden Programmiersprachen und Versionen unterstützt:

Funktionsweise

In den folgenden exemplarischen Vorgehensweisen wird beschrieben, wie der hierarchische Schlüsselbund Verschlüsselungs- und Entschlüsselungsmaterial zusammenstellt, sowie die verschiedenen Aufrufe, die 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 erfordert AWS Encryption SDK keinen AWS-Konto und es hängt von keinem ab AWS-Service. Um einen hierarchischen Schlüsselbund verwenden zu können, benötigen Sie jedoch eine AWS-Konto und die folgenden Mindestberechtigungen für die symmetrische (n) Verschlüsselung AWS KMS key(en) in Ihrem Schlüsselspeicher.

Erforderliche Amazon DynamoDB-Berechtigungen für die Schlüsselspeichertabelle

Die Principals, die mit Ihrem Schlüsselspeicher interagieren, benötigen ebenfalls Berechtigungen für die DynamoDB-Tabelle. Der Satz von Berechtigungen hängt von der Rolle ab.

Weitere Informationen zur Steuerung des Zugriffs auf Ihre Filialschlüssel und Ihren Schlüsselspeicher finden Sie unter. Implementieren 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}
};

Python

default_cache = CacheTypeDefault(
    value=DefaultCache(
        entry_capacity=100
    )
)

Rust

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

Go

cache := mpltypes.CacheTypeMemberDefault{
		Value: mpltypes.DefaultCache{
			EntryCapacity: 100,
		},
	}

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
    }
};

Python

multithreaded_cache = CacheTypeMultiThreaded(
    value=MultiThreadedCache(
        entry_capacity=100,
        entry_pruning_tail_size=1
    )
)

Rust

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

Go

var entryPruningTailSize int32 = 1
	cache := mpltypes.CacheTypeMemberMultiThreaded{
		Value: mpltypes.MultiThreadedCache{
			EntryCapacity:        100,
			EntryPruningTailSize: &entryPruningTailSize,
		},
	}

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 zur Aktualisierung des Caches AWS KMS an sendet. Weitere Informationen finden Sie unter Storm Tracking Cryptographic Materials Cache im Repository GitHub aws-encryption-sdk-Spezifikation.

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

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
    }
};

Python

storm_tracking_cache = CacheTypeStormTracking(
    value=StormTrackingCache(
        entry_capacity=100,
        entry_pruning_tail_size=1,
        fan_out=20,
        grace_interval=1,
        grace_period=10,
        in_flight_ttl=10,
        sleep_milli=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()?)

Go

var entryPruningTailSize int32 = 1
	cache := mpltypes.CacheTypeMemberStormTracking{
		Value: mpltypes.StormTrackingCache{
			EntryCapacity:        100,
			EntryPruningTailSize: &entryPruningTailSize,
			GraceInterval:        1,
			GracePeriod:          10,
			FanOut:               20,
			InFlightTTL:          10,
			SleepMilli:           20,
		},
	}

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

Ein gemeinsamer Cache kann von mehreren hierarchischen Schlüsselbänden verwendet werden. 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: