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 Hierarchical, puoi proteggere i tuoi materiali crittografici con una chiave KMS a 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 le applicazioni che possono riutilizzare alcuni materiali crittografici AWS KMS senza violare i requisiti di sicurezza.

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

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

Quando si crea un'istanza del portachiavi Hierarchical, viene creata una cache locale. Si specifica un limite di cache che definisce la quantità massima di tempo in cui i materiali chiave del branch vengono archiviati nella cache locale prima che scadano e vengano rimossi dalla cache. Il portachiavi Hierarchical effettua una AWS KMS chiamata per decrittografare la chiave del ramo e assemblare i materiali delle chiavi del ramo la prima volta che a viene specificato in un'operazione. branch-key-id I materiali delle chiavi di filiale vengono quindi 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 La memorizzazione dei materiali chiave della filiale nella cache locale riduce le chiamate. AWS KMS Ad esempio, si consideri un limite di cache di 15 minuti. Se si eseguono 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 Hierarchical deve effettuare solo una 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 assemblati a partire dalla chiave branch attiva e riutilizzati per tutte le operazioni di crittografia fino alla scadenza del limite della cache. I materiali di decrittografia vengono assemblati 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 della cache. La cache locale può memorizzare più versioni della stessa chiave di ramo contemporaneamente. Quando la cache locale è configurata per utilizzare abranch key ID supplier, può anche archiviare i materiali chiave delle branch provenienti da più chiavi di branch attive contemporaneamente.

Come funziona

Le seguenti procedure dettagliate descrivono come il portachiavi Hierarchical assembla i materiali di crittografia e decrittografia e le diverse chiamate che il portachiavi effettua per le operazioni di crittografia e decrittografia. Per i dettagli tecnici sulla derivazione delle chiavi di wrapping e sui processi di crittografia delle chiavi di dati in chiaro, consulta Dettagli tecnici del portachiavi gerarchico.AWS KMS

Crittografa e firma

La procedura dettagliata seguente descrive come il portachiavi Hierarchical assembla i materiali di crittografia e ricava una chiave di avvolgimento unica.

Decrittografa e verifica

La procedura dettagliata seguente 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 per le AWS KMS key crittografie simmetriche presenti nell'archivio delle chiavi.

Per ulteriori informazioni sul controllo dell'accesso alle chiavi di filiale e all'archivio delle chiavi, 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 chiave della filiale utilizzati nelle operazioni di crittografia e decrittografia. Prima di creare il tuo portachiavi Hierarchical, devi decidere che tipo di cache vuoi usare. È possibile utilizzare la cache predefinita o personalizzarla in base alle proprie esigenze.

Il portachiavi Hierarchical 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 con molti multithread. Quando una voce relativa ai materiali delle chiavi di branch 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 branch sta per scadere con 10 secondi di anticipo. Ciò garantisce che solo un thread invii una richiesta di aggiornamento della cache AWS KMS .

Il valore predefinito e le StormTracking 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. StormTracking cache

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

Per personalizzare la cache predefinita, specificare 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 scade l'immissione di materiali chiave in una filiale, tutti i thread verranno avvisati 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 con molti multithread. Quando una voce relativa ai materiali della chiave di filiale scade, la StormTracking cache impedisce la chiamata di più thread AWS KMS notificando in anticipo a un thread che la voce relativa ai materiali chiave della branch sta per scadere. Ciò garantisce che solo un thread invii una richiesta di aggiornamento della cache AWS KMS .

Per utilizzare la StormTracking cache, specificate 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 Hierarchical crea una nuova cache locale ogni volta che si crea un'istanza del portachiavi. Tuttavia, la cache condivisa può aiutare a risparmiare memoria consentendoti di condividere una cache tra più portachiavi gerarchici. Anziché creare una nuova cache di materiali crittografici per ogni portachiavi gerarchico istanziato, la cache condivisa archivia 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'utilizzo della memoria evitando la duplicazione di materiali crittografici tra portachiavi. I portachiavi gerarchici possono invece accedere alla stessa cache sottostante, riducendo l'ingombro complessivo della memoria.

Quando crei la cache condivisa, definisci 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 un'unica cache condivisa. Quando si crea un portachiavi gerarchico con una cache condivisa, è possibile definire un ID di partizione opzionale. L'ID di partizione distingue quale portachiavi gerarchico sta scrivendo nella cache. Se due portachiavi gerarchici fanno riferimento allo stesso ID di partizione e allo stesso ID di chiave di filialelogical key store name, i due portachiavi condivideranno le stesse voci della cache. Se si creano due portachiavi gerarchici con la stessa cache condivisa, ma una partizione diversa IDs, ogni 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 funzionare indipendentemente sulla propria partizione designata, senza interferire con i dati memorizzati nell'altra partizione.

Se si intende riutilizzare o condividere le voci della cache in una partizione, è necessario definire il proprio ID di partizione. Quando passate l'ID della partizione al portachiavi Hierarchical, il portachiavi può riutilizzare le voci della cache che sono già presenti nella cache condivisa, anziché dover recuperare e autorizzare nuovamente i materiali delle chiavi della branch. Se non si specifica un ID di partizione, un ID di partizione univoco viene assegnato automaticamente al portachiavi ogni volta che si crea un'istanza del portachiavi Hierarchical.

Crea un portachiavi gerarchico

Per creare un portachiavi gerarchico, è necessario fornire i seguenti valori:

Utilizzo del portachiavi gerarchico per una 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. Per implementare la crittografia ricercabile, è necessario utilizzare un portachiavi gerarchico.

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

La chiave branch e la chiave beacon sono protette dallo stesso AWS KMS key che hai specificato durante la creazione del servizio di archiviazione delle chiavi. Dopo che l'CreateKeyoperazione chiama AWS KMS per generare la chiave branch, 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",
      "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"
}

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

Quando configuri un beacon standard, AWS Database Encryption SDK interroga l'archivio delle chiavi per la chiave beacon. Quindi, utilizza una funzione di derivazione delle extract-and-expand chiavi basata su HMAC (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 branch, esiste una sola versione di chiave beacon per ogni chiave. branch-key-id La chiave beacon non viene mai ruotata.

Definizione della fonte della chiave del beacon

Quando si definisce la versione beacon per i beacon standard e compositi, è necessario identificare la chiave beacon e definire un TTL (cache limit time to live) per i materiali chiave del beacon. I materiali delle chiavi beacon vengono archiviati in una cache locale separata dalle chiavi branch. Il seguente frammento mostra come definire un database single-tenant. keySource Identifica la tua chiave beacon in base alla quale è 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()?,
))