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 delle chiavi di filiale 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 dati unica per crittografare ogni campo e crittografa ogni chiave di 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 branch 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 è composta da due partizioni, una per le operazioni di crittografia e una seconda per le operazioni di decrittografia. La partizione di crittografia memorizza i materiali delle chiavi di branch assemblati dalla chiave branch attiva e li riutilizza per tutte le operazioni di crittografia fino alla scadenza del limite della cache. La partizione di decrittografia memorizza i materiali delle chiavi di filiale assemblati per altre versioni di chiavi di filiale identificate nelle operazioni di decrittografia. La partizione di decrittografia può memorizzare più versioni di materiali chiave di filiale attivi contemporaneamente. Quando è configurata per utilizzare un fornitore di ID di chiavi di filiale per un database multitenant, la partizione encrypt può anche archiviare più versioni di materiali relativi alle chiavi di filiale contemporaneamente. Per ulteriori informazioni, consulta Utilizzo del portachiavi Hierarchical con database multitenant.

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 univoca.

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

Il AWS Database Encryption SDK non richiede Account AWS e non dipende da nessuno. Servizio AWS Tuttavia, il portachiavi gerarchico dipende da Amazon AWS KMS DynamoDB.

Per utilizzare un portachiavi gerarchico, è necessaria una crittografia simmetrica con autorizzazioni KMS:Decrypt. AWS KMS key È inoltre possibile utilizzare una chiave multiregionale con crittografia simmetrica. Per informazioni dettagliate sulle autorizzazioni per AWS KMS keys, consulta Autenticazione e controllo degli accessi nella Guida per gli sviluppatori.AWS Key Management Service

Prima di poter creare e utilizzare un portachiavi gerarchico, è necessario creare l'archivio delle chiavi della filiale e compilarlo con la prima chiave di filiale attiva.

Crea un portachiavi gerarchico

Per inizializzare il portachiavi gerarchico, è necessario fornire i seguenti valori:

Gli esempi seguenti mostrano come inizializzare un portachiavi gerarchico con il client AWS Database Encryption SDK per DynamoDB. L'esempio seguente specifica un limite di cache TTL di 600 secondi.

Java

final MaterialProviders matProv = MaterialProviders.builder()
        .MaterialProvidersConfig(MaterialProvidersConfig.builder().build())
        .build();
final CreateAwsKmsHierarchicalKeyringInput keyringInput = CreateAwsKmsHierarchicalKeyringInput.builder()
        .keyStore(branchKeyStoreName)
        .branchKeyId(branch-key-id)
        .ttlSeconds(600)
        .build();
final Keyring hierarchicalKeyring = matProv.CreateAwsKmsHierarchicalKeyring(keyringInput);

C# / .NET

var matProv = new MaterialProviders(new MaterialProvidersConfig());
var keyringInput = new CreateAwsKmsHierarchicalKeyringInput
{
   KeyStore = keystore,
   BranchKeyIdSupplier = branchKeyIdSupplier,
   TtlSeconds = 600
};
var hierarchicalKeyring = matProv.CreateAwsKmsHierarchicalKeyring(keyringInput);

Ruota la chiave branch attiva

Può esserci una sola versione attiva per ogni chiave di ramo alla volta. Il portachiavi Hierarchical utilizza in genere ogni versione di chiave branch attiva per soddisfare più richieste. Ma sei tu a controllare la misura in cui le chiavi branch attive vengono riutilizzate e a determinare la frequenza con cui la chiave branch attiva viene ruotata.

Le chiavi branch non vengono utilizzate per crittografare le chiavi di dati in testo semplice. Vengono utilizzate per derivare le chiavi di wrapping uniche che crittografano le chiavi di dati in testo semplice. Il processo di derivazione della chiave di wrapping produce una chiave di wrapping unica da 32 byte con 28 byte di casualità. ^{Ciò significa che una chiave branch può derivare più di 79 ottilioni, o 2 96, chiavi di wrapping uniche prima che si verifichi l'usura crittografica.} Nonostante questo rischio di esaurimento molto basso, potrebbe essere necessario ruotare le chiavi di filiale attive a causa di norme aziendali o contrattuali o normative governative.

La versione attiva della chiave di filiale rimane attiva finché non viene ruotata. Le versioni precedenti della chiave branch attiva non verranno utilizzate per eseguire operazioni di crittografia e non possono essere utilizzate per derivare nuove chiavi di wrapping. Tuttavia, possono comunque essere interrogate e fornire chiavi di wrapping per decrittografare le chiavi di dati che hanno crittografato mentre erano attive.

Utilizza il servizio di archiviazione delle chiavi per ruotare VersionKey la chiave branch attiva. Quando si ruota la chiave di ramo attiva, viene creata una nuova chiave di ramo per sostituire la versione precedente. Non branch-key-id cambia quando si ruota la chiave di ramo attiva. È necessario specificare la chiave branch-key-id che identifica la chiave di ramo attiva corrente quando si chiama. VersionKey

Java

keystore.VersionKey(
    VersionKeyInput.builder()
        .branchKeyIdentifier("branch-key-id")
        .build()
);

C# / .NET

 keystore.VersionKey(new VersionKeyInput{BranchKeyIdentifier = branchKeyId});

Utilizzo del portachiavi Hierarchical con database multitenant

È possibile utilizzare la gerarchia di chiavi stabilita tra le chiavi branch attive e le relative chiavi di wrapping derivate per supportare i database multitenant creando una chiave branch per ogni tenant del database. Il portachiavi Hierarchical crittografa e firma quindi tutti i dati di un determinato tenant con la relativa chiave branch distinta. Ciò consente di archiviare i dati di più tenant in un unico database e di isolare i dati del tenant per chiave di filiale.

Ogni tenant ha la propria chiave di filiale definita da un'unica. branch-key-id Può esserci solo una versione attiva di ciascuno branch-key-id alla volta.

Branch Key ID (fornitore).

Prima di poter inizializzare il portachiavi gerarchico per l'uso multitenant, è necessario creare una chiave di filiale per ogni tenant e creare un fornitore di ID di chiave di filiale. Il fornitore dell'ID della chiave di filiale utilizza i campi memorizzati nel contesto di crittografia per determinare quale chiave di filiale del tenant è necessaria per decrittografare un record. Per impostazione predefinita, nel contesto di crittografia sono incluse solo le chiavi di partizione e ordinamento. Tuttavia, è possibile utilizzare l'azione SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT crittografica per includere campi aggiuntivi nel contesto di crittografia.

Puoi utilizzare il fornitore di codici identificativi della filiale per creare un nome branch-key-ids descrittivo per facilitare il riconoscimento di quello corretto branch-key-id per un tenant. Ad esempio, il nome descrittivo consente di fare riferimento a una chiave di filiale come tenant1 invece dib3f61619-4d35-48ad-a275-050f87e15122.

Per le operazioni di decrittografia, è possibile configurare staticamente un singolo portachiavi gerarchico per limitare la decrittografia a un singolo tenant, oppure è possibile utilizzare il fornitore di ID della chiave di filiale per identificare quale tenant è responsabile della decrittografia di un record.

Per prima cosa, segui i passaggi 1 e 2 delle procedure relative ai prerequisiti. Quindi, utilizzate le seguenti procedure per creare una chiave di filiale per ogni tenant, creare un fornitore di ID di chiavi di filiale e inizializzare il portachiavi Hierarchical per l'uso multitenant.

Utilizzo del portachiavi Hierarchical 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 branch 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, il AWS Database Encryption SDK interroga l'archivio delle chiavi del branch per cercare 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 filiale. 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
    }
}