Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

AWS KMS Portachiavi gerarchici

Con il portachiavi AWS KMS gerarchico, puoi proteggere i tuoi materiali crittografici con una chiave KMS di crittografia simmetrica senza chiamare AWS KMS ogni volta che crittografi o decrittografi un record. È una buona scelta per le applicazioni che devono ridurre al minimo le chiamate e per le applicazioni che possono riutilizzare alcuni materiali crittografici AWS KMS senza violare i requisiti di sicurezza.

Il keyring gerarchico è una soluzione di caching dei materiali crittografici che riduce il numero di AWS KMS chiamate utilizzando chiavi di filiale AWS KMS protette conservate in una tabella Amazon DynamoDB e quindi memorizzando localmente nella cache i materiali delle chiavi di filiale utilizzati nelle operazioni di crittografia e decrittografia. La tabella DynamoDB funge da archivio di chiavi che gestisce e protegge le chiavi di filiale. Memorizza la chiave di ramo attiva e tutte le versioni precedenti della chiave di ramo. La chiave di filiale attiva è la versione più recente della chiave di filiale. Il portachiavi gerarchico utilizza una chiave di crittografia dei dati univoca per ogni richiesta di crittografia e crittografa ogni chiave di crittografia dei dati con una chiave di wrapping univoca derivata dalla chiave di ramo attiva. Il portachiavi gerarchico dipende dalla gerarchia stabilita tra le chiavi di ramo attive e le relative chiavi di raggruppamento derivate.

Il portachiavi gerarchico utilizza in genere ogni versione della chiave di ramo per soddisfare più richieste. Tuttavia, sei tu a controllare la misura in cui le chiavi di ramo attive vengono riutilizzate e a determinare la frequenza con cui la chiave di ramo attiva viene ruotata. La versione attiva della chiave di diramazione rimane attiva finché non viene ruotata. Le versioni precedenti della chiave di diramazione attiva non verranno utilizzate per eseguire operazioni di crittografia, ma possono comunque essere interrogate e utilizzate nelle operazioni di decrittografia.

Quando si crea un'istanza del portachiavi gerarchico, viene creata una cache locale. Specificate un limite di cache che definisce il periodo massimo di tempo durante il quale i materiali delle chiavi del ramo vengono archiviati nella cache locale prima che scadano e vengano rimossi dalla cache. Il portachiavi gerarchico effettua una AWS KMS chiamata per decrittografare la chiave di diramazione e assemblare i materiali della chiave di diramazione la prima volta che viene specificato un elemento in un'operazione. branch-key-id Quindi, i materiali delle chiavi di filiale vengono archiviati nella cache locale e riutilizzati per tutte le operazioni di crittografia e decrittografia che lo specificano fino alla scadenza del limite di cache. branch-key-id L'archiviazione dei materiali relativi alle chiavi delle filiali nella cache locale riduce le chiamate. AWS KMS Ad esempio, considera un limite di cache di 15 minuti. Se esegui 10.000 operazioni di crittografia entro tale limite di cache, il AWS KMS portachiavi tradizionale dovrebbe effettuare 10.000 AWS KMS chiamate per soddisfare 10.000 operazioni di crittografia. Se ne hai uno attivobranch-key-id, il portachiavi gerarchico deve effettuare una sola AWS KMS chiamata per soddisfare 10.000 operazioni di crittografia.

La cache locale separa i materiali di crittografia dai materiali di decrittografia. I materiali di crittografia vengono raccolti dalla chiave di filiale attiva e riutilizzati per tutte le operazioni di crittografia fino alla scadenza del limite di cache. I materiali di decrittografia vengono raccolti a partire dall'ID e dalla versione della chiave di filiale identificati nei metadati del campo crittografato e vengono riutilizzati per tutte le operazioni di decrittografia relative all'ID e alla versione della chiave di filiale fino alla scadenza del limite di cache. La cache locale può memorizzare più versioni della stessa chiave di filiale contemporaneamente. Quando la cache locale è configurata per utilizzare abranch key ID supplier, può anche archiviare i materiali delle chiavi di filiale provenienti da più chiavi di filiale attive contemporaneamente.

Come funziona

Le seguenti procedure dettagliate descrivono come il portachiavi gerarchico assembla i materiali di crittografia e decrittografia e le diverse chiamate effettuate dal portachiavi per le operazioni di crittografia e decrittografia. Per dettagli tecnici sui processi di derivazione della chiave di wrapping e di crittografia delle chiavi di dati in chiaro, consulta Dettagli tecnici sui keyring gerarchici. AWS KMS

Crittografa e firma

La seguente procedura dettagliata descrive come il portachiavi gerarchico assembla i materiali crittografici e ricava una chiave di wrapping univoca.

Decifra e verifica

La seguente procedura dettagliata descrive come il portachiavi gerarchico assembla i materiali di decrittografia e decrittografa la chiave di dati crittografata.

Prerequisiti

Prima di creare e utilizzare un portachiavi gerarchico, assicurati che siano soddisfatti i seguenti prerequisiti.

Autorizzazioni richieste

Il AWS Database Encryption SDK non richiede Account AWS e non dipende da nessuno Servizio AWS. Tuttavia, per utilizzare un portachiavi gerarchico, sono necessarie le seguenti autorizzazioni Account AWS minime sulle AWS KMS key crittografie simmetriche nel tuo archivio di chiavi.

Per ulteriori informazioni sul controllo dell'accesso alle chiavi di filiale e al key store, consulta. Implementazione di autorizzazioni con privilegio minimo

Scegli una cache

Il portachiavi gerarchico riduce il numero di chiamate effettuate AWS KMS memorizzando localmente nella cache i materiali delle chiavi di filiale utilizzati nelle operazioni di crittografia e decrittografia. Prima di creare il portachiavi gerarchico, è necessario decidere il tipo di cache da utilizzare. È possibile utilizzare la cache predefinita o personalizzare la cache per adattarla al meglio alle proprie esigenze.

Il portachiavi gerarchico supporta i seguenti tipi di cache:

Cache predefinita

Per la maggior parte degli utenti, la cache predefinita soddisfa i requisiti di threading. La cache predefinita è progettata per supportare ambienti fortemente multithread. Quando una voce relativa ai materiali della chiave di filiale scade, la cache predefinita impedisce la chiamata di più thread AWS KMS notificando a un thread che la voce relativa ai materiali della chiave di filiale scadrà con 10 secondi di anticipo. Ciò garantisce che solo un thread invii una richiesta di aggiornamento della cache AWS KMS .

L'impostazione predefinita e StormTracking le cache supportano lo stesso modello di threading, ma è sufficiente specificare la capacità di ingresso per utilizzare la cache predefinita. Per personalizzazioni più granulari della cache, usa il. StormTracking cache

A meno che non si desideri personalizzare il numero di voci relative ai materiali chiave di filiale che possono essere archiviate nella cache locale, non è necessario specificare un tipo di cache quando si crea il portachiavi gerarchico. Se non si specifica un tipo di cache, il portachiavi gerarchico utilizza il tipo di cache predefinito e imposta la capacità di immissione su 1000.

Per personalizzare la cache predefinita, specificate i seguenti valori:

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

La MultiThreaded cache è sicura da usare in ambienti multithread, ma non fornisce alcuna funzionalità per ridurre al minimo AWS KMS le chiamate Amazon DynamoDB. Di conseguenza, quando una voce relativa ai materiali chiave di una filiale scade, tutti i thread verranno notificati contemporaneamente. Ciò può comportare più AWS KMS chiamate per aggiornare la cache.

Per utilizzare la MultiThreaded cache, specificate i seguenti valori:

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 cache

La StormTracking cache è progettata per supportare ambienti fortemente multithread. Quando una voce relativa ai materiali della chiave di filiale scade, la StormTracking cache impedisce la chiamata di più thread AWS KMS notificando a un thread che la voce relativa ai materiali della chiave di filiale scadrà in anticipo. Ciò garantisce che solo un thread invii una richiesta AWS KMS a per aggiornare la cache.

Per utilizzare la StormTracking cache, specifica i seguenti valori:

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

Cache condivisa

Per impostazione predefinita, il portachiavi gerarchico crea una nuova cache locale ogni volta che si crea un'istanza del portachiavi. Tuttavia, la cache condivisa può aiutare a risparmiare memoria consentendo di condividere una cache tra più portachiavi gerarchici. Anziché creare una nuova cache dei materiali crittografici per ogni keyring gerarchico creato, la cache condivisa memorizza solo una cache in memoria, che può essere utilizzata da tutti i portachiavi gerarchici che vi fanno riferimento. La cache condivisa aiuta a ottimizzare l'uso della memoria evitando la duplicazione di materiali crittografici tra i portachiavi. Invece, i portachiavi gerarchici possono accedere alla stessa cache sottostante, riducendo l'ingombro complessivo della memoria.

Quando si crea la cache condivisa, si definisce comunque il tipo di cache. È possibile specificare un Cache predefinitaMultiThreaded cache, o StormTracking cache come tipo di cache o sostituire qualsiasi cache personalizzata compatibile.

Partizioni

Più portachiavi gerarchici possono utilizzare una singola cache condivisa. Quando si crea un portachiavi gerarchico con una cache condivisa, è possibile definire un ID di partizione opzionale. L'ID di partizione distingue il portachiavi gerarchico che sta scrivendo nella cache. Se due portachiavi gerarchici fanno riferimento allo stesso ID di partizione e allo stesso ID di chiave di ramological key store name, i due portachiavi condivideranno le stesse voci della cache nella cache. Se si creano due portachiavi gerarchici con la stessa cache condivisa, ma ID di partizione diversi, ciascun portachiavi accederà alle voci della cache solo dalla propria partizione designata all'interno della cache condivisa. Le partizioni agiscono come divisioni logiche all'interno della cache condivisa, consentendo a ciascun portachiavi gerarchico di operare in modo indipendente sulla propria partizione designata, senza interferire con i dati memorizzati nell'altra partizione.

Se intendi riutilizzare o condividere le voci della cache in una partizione, devi definire il tuo ID di partizione. Quando si passa l'ID della partizione al portachiavi gerarchico, il portachiavi può riutilizzare le voci della cache già presenti nella cache condivisa, anziché dover recuperare e autorizzare nuovamente i materiali delle chiavi di ramo. Se non si specifica un ID di partizione, al portachiavi viene assegnato automaticamente un ID di partizione univoco ogni volta che si crea un'istanza del portachiavi gerarchico.

Crea un portachiavi gerarchico

Per creare un portachiavi gerarchico, devi fornire i seguenti valori:

Gli esempi seguenti mostrano come configurare un key store con una configurazione statica. Scegli la tua lingua preferita:

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)?;

Dopo aver configurato il key store, utilizzate l'oggetto key store risultante per creare il portachiavi gerarchico. Gli esempi di portachiavi gerarchici che seguono utilizzano l'oggetto key store configurato.

Utilizzo del portachiavi gerarchico per la crittografia ricercabile

La crittografia ricercabile consente di cercare record crittografati senza decrittografare l'intero database. Ciò si ottiene indicizzando il valore in chiaro di un campo crittografato con un beacon. Fari Per implementare la crittografia ricercabile, è necessario utilizzare un portachiavi gerarchico.

L'CreateKeyoperazione di archiviazione delle chiavi genera sia una chiave di filiale che una chiave beacon. La chiave di derivazione viene utilizzata nelle operazioni di crittografia e decrittografia dei record. La chiave beacon viene utilizzata per generare beacon.

La chiave di filiale e la chiave beacon sono protette dalla stessa AWS KMS key che specifichi durante la creazione del servizio di archiviazione delle chiavi. Dopo le chiamate dell'CreateKeyoperazione AWS KMS per generare la chiave di filiale, chiama kms: GenerateDataKeyWithoutPlaintext una seconda volta per generare la chiave beacon utilizzando la seguente richiesta.

{
   "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"
}

Dopo aver generato entrambe le chiavi, l'CreateKeyoperazione chiama ddb: TransactWriteItems per scrivere due nuovi elementi che mantengano la chiave di ramo e la chiave beacon nell'archivio delle chiavi della filiale.

Quando si configura un beacon standard, AWS Database Encryption SDK interroga l'archivio di chiavi per la chiave beacon. Quindi, utilizza una funzione di HMAC-based estrazione ed espansione della chiave (HKDF) per combinare la chiave beacon con il nome del beacon standard per creare la chiave HMAC per un determinato beacon.

A differenza delle chiavi di filiale, esiste una sola versione di chiave beacon per ogni key store. branch-key-id La chiave beacon non viene mai ruotata.

Definizione della fonte della chiave beacon

Quando si definisce la versione del beacon per i beacon standard e composti, è necessario identificare la chiave beacon e definire un limite di tempo di vita della cache (TTL) per i materiali della chiave beacon. I materiali delle chiavi beacon sono archiviati in una cache locale separata dalle chiavi di filiale. Lo snippet seguente mostra come definire il per un database single-tenant. keySource Identifica la tua chiave beacon in base alla chiave a cui è associata. branch-key-id

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