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üsselanhänger

Mit dem AWS KMS hierarchischen Schlüsselbund können Sie Ihre kryptografischen Materialien mit einem symmetrischen KMS Verschlüsselungsschlüssel schützen, ohne AWS KMS jedes Mal, wenn Sie einen Datensatz ver- oder entschlüsseln, erneut aufrufen zu müssen. Es ist eine gute Wahl für Anwendungen, bei denen die Anzahl der Aufrufe minimiert werden muss AWS KMS, und für Anwendungen, die kryptografisches Material wiederverwenden können, ohne ihre Sicherheitsanforderungen zu verletzen.

Der hierarchische Schlüsselbund 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 bei Verschlüsselungs- und Entschlüsselungsvorgängen verwendete Zweigschlüsselmaterial lokal zwischengespeichert wird. Die DynamoDB-Tabelle dient als Schlüsselspeicher, der Zweigschlüssel verwaltet und schützt. Sie speichert den aktiven Branch-Schlüssel und alle vorherigen Versionen des Branch-Schlüssels. Der aktive Zweigschlü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 Filialschlüssel abgeleitet wird. Der hierarchische Schlüsselbund hängt von der Hierarchie ab, die zwischen aktiven Zweigschlüsseln und ihren abgeleiteten Umschließungsschlüsseln festgelegt wurde.

Der hierarchische Schlüsselbund verwendet in der Regel jede Version des Zweigschlüssels, um mehrere Anfragen zu erfüllen. Sie kontrollieren jedoch, in welchem Umfang aktive Zweigschlüssel wiederverwendet werden, und Sie bestimmen, wie oft der aktive Zweigschlüssel rotiert wird. Die aktive Version des Abzweigschlüssels bleibt aktiv, bis Sie ihn drehen. Frühere Versionen des aktiven Zweigschlüssels werden nicht zur Ausführung von Verschlüsselungsvorgängen verwendet, sie können jedoch weiterhin abgefragt und bei Entschlüsselungsvorgängen verwendet werden.

Wenn Sie den hierarchischen Schlüsselbund instanziieren, erstellt er einen lokalen Cache. Sie geben ein Cache-Limit an, das die maximale Zeitspanne definiert, für die die Branch-Schlüsselmaterialien 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 einem Vorgang angegeben branch-key-id wird. Anschließend werden die Materialien der Verzweigungsschlüssel im lokalen Cache gespeichert und für alle Verschlüsselungs- und Entschlüsselungsvorgänge, die dies spezifizieren, wiederverwendet, bis das Cache-Limit abläuft. branch-key-id Das Speichern von Zweigschlüsselmaterialien 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 zu erfüllen. 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üsselungsmaterialien von Entschlüsselungsmaterialien. Die Verschlüsselungsmaterialien werden aus dem aktiven Zweigschlüssel zusammengesetzt und für alle Verschlüsselungsvorgänge wiederverwendet, bis das Cache-Limit abgelaufen ist. Die Entschlüsselungsmaterialien werden aus der Zweigschlüssel-ID und der Version zusammengestellt, die in den Metadaten des verschlüsselten Felds identifiziert wurden, und sie werden für alle Entschlüsselungsvorgänge im Zusammenhang mit der Branch-Schlüssel-ID und -version wiederverwendet, bis das Cache-Limit abläuft. Im lokalen Cache können mehrere Versionen desselben Zweigschlüssels gleichzeitig gespeichert werden. Wenn der lokale Cache für die Verwendung von konfiguriert istbranch key ID supplier, kann er auch Zweigschlüsselmaterial von mehreren aktiven Branch-Schlü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 verwendet. Technische Einzelheiten zur Ableitung von 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üsselungsmaterialien 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

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

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

Durch den hierarchischen Schlüsselbund wird die Anzahl der Aufrufe reduziert, AWS KMS indem die für Ver- und Entschlüsselungsvorgänge verwendeten Zweigschlüsselmaterialien lokal zwischengespeichert werden. 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 so anpassen, dass er Ihren Bedürfnissen am besten entspricht.

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-Schlüssel-Materialien abläuft, verhindert der Standard-Cache den Aufruf mehrerer Threads, AWS KMS indem ein Thread 10 Sekunden im Voraus darüber informiert wird, dass der Eintrag für Branch-Schlüssel-Materialien abläuft. Dadurch wird sichergestellt, dass nur ein Thread eine Anfrage AWS KMS zur Aktualisierung des Caches sendet.

Standard und 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 den. StormTracking Zwischenspeicher

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

MultiThreaded Cache

Der MultiThreaded Cache kann sicher in Multithread-Umgebungen verwendet werden, bietet jedoch keine Funktionen zur Minimierung AWS KMS von Amazon DynamoDB DynamoDB-Aufrufen. Daher werden alle Threads gleichzeitig benachrichtigt, wenn ein Eintrag für wichtige Materialien in einer Branche abläuft. Dies kann zu mehreren AWS KMS Aufrufen führen, um den Cache zu aktualisieren.

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

StormTracking Zwischenspeicher

Der StormTracking Cache ist so konzipiert, dass er Umgebungen mit vielen Threads unterstützt. Wenn ein Eintrag für Branch-Schlüssel-Materialien abläuft, verhindert der StormTracking Cache den Aufruf mehrerer Threads, AWS KMS indem ein Thread im Voraus darüber informiert wird, dass der Eintrag für Branch-Schlüssel-Materialien abläuft. Dadurch wird sichergestellt, dass nur ein Thread eine Anfrage AWS KMS zur Aktualisierung 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(20)
        .sleepMilli(20)                                        
        .build())

C# / .NET

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

Gemeinsamer Cache

Standardmäßig erstellt der hierarchische Schlüsselbund jedes Mal, wenn Sie den Schlüsselbund instanziieren, einen neuen lokalen Cache. Der Shared Cache kann jedoch dabei helfen, Speicherplatz zu sparen, indem er es Ihnen ermöglicht, einen Cache für mehrere hierarchische Schlüsselbunde gemeinsam zu nutzen. Anstatt für jeden hierarchischen Schlüsselbund, den Sie instanziieren, einen neuen Cache für kryptografisches Material zu erstellen, speichert der Shared Cache nur einen Cache im Arbeitsspeicher, der von allen hierarchischen Schlüsselbunden verwendet werden kann, die auf ihn verweisen. Der gemeinsam genutzte Cache trägt zur Optimierung der Speichernutzung bei, indem verhindert wird, dass kryptografisches Material in mehreren Schlüsselbunden doppelt vorhanden ist. Stattdessen können die hierarchischen Schlüsselbunde auf denselben zugrunde liegenden Cache zugreifen, wodurch der Gesamtspeicherbedarf reduziert wird.

Wenn Sie Ihren Shared Cache erstellen, definieren Sie immer noch den Cachetyp. Sie können einen Standard-CacheMultiThreaded Cache, oder StormTracking Zwischenspeicher als Cachetyp angeben oder einen beliebigen kompatiblen benutzerdefinierten Cache ersetzen.

Partitionen

Ein einziger gemeinsam genutzter Cache kann von mehreren hierarchischen Schlüsselbunden verwendet werden. Wenn Sie einen hierarchischen Schlüsselbund mit einem gemeinsam genutzten 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üsselbunde auf dieselbe Partitions-ID und dieselbe Zweigschlüssel-ID verweisenlogical key store name, teilen sich die beiden Schlüsselbunde dieselben Cache-Einträge im Cache. Wenn Sie zwei hierarchische Schlüsselbunde mit demselben Shared Cache, aber unterschiedlicher Partition IDs erstellen, greift jeder Schlüsselbund nur auf die Cache-Einträge von der eigenen zugewiesenen Partition innerhalb des Shared Caches zu. Die Partitionen dienen als logische Unterteilungen innerhalb des gemeinsam genutzten Caches, sodass jeder hierarchische Schlüsselbund unabhängig auf seiner eigenen zugewiesenen Partition betrieben werden 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 wiederverwenden, die bereits im Shared Cache vorhanden sind, anstatt die Branch-Schlüsselmaterialien erneut abrufen und autorisieren zu müssen. Wenn Sie keine Partitions-ID angeben, wird dem Schlüsselbund bei jeder Instanziierung des hierarchischen Schlüsselbunds 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:

Verwendung des hierarchischen Schlüsselbunds für durchsuchbare Verschlüsselung

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

Der CreateKey Schlüsselspeichervorgang generiert sowohl einen Zweigschlüssel als auch einen Beacon-Schlüssel. Der Zweigschlüssel wird bei der Verschlüsselung und Entschlüsselung von Datensätzen verwendet. Der Beacon-Schlüssel wird zur Generierung von Beacons verwendet.

Der Branch-Schlüssel und der Beacon-Schlüssel sind durch dasselbe geschützt AWS KMS key , das Sie bei der Erstellung Ihres Schlüsselspeicherdienstes angegeben haben. Nachdem der CreateKey Vorgang AWS KMS zur Generierung des Branch-Schlü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",
      "logical-key-store-name" : "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-Schlüssel und den Beacon-Schlüssel in Ihrem Branch-Schlüsselspeicher speichern.

Wenn Sie ein Standard-Beacon konfigurieren, SDK fragt AWS Database Encryption den Schlüsselspeicher nach dem Beacon-Schlüssel ab. Anschließend verwendet sie eine HMAC basierte extract-and-expand Schlüsselableitungsfunktion (HKDF), um den Beacon-Schlüssel mit dem Namen des Standard-Beacons zu kombinieren, um den HMAC Schlüssel für einen bestimmten Beacon zu erstellen.

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

Definieren Sie Ihre Beacon-Schlüsselquelle

Wenn Sie die Beacon-Version für Ihre Standard- und Verbund-Beacons definieren, müssen Sie den Beacon-Schlüssel identifizieren und ein Cache-Limit Time to Live (TTL) für die Beacon-Schlüsselmaterialien definieren. Beacon-Schlüsselmaterialien werden in einem von den Branch-Schlüsseln getrennten lokalen Cache gespeichert. Der folgende Ausschnitt zeigt, wie die 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
    }
}