Provider più recente

Nota

La nostra libreria di crittografia lato client è stata rinominata AWS Database Encryption SDK. L'argomento seguente fornisce informazioni sulle versioni 1. x —2. x del client di crittografia DynamoDB per Java e versioni 1. x —3. x del client di crittografia DynamoDB per Python. Per ulteriori informazioni, consulta AWSDatabase Encryption SDK per il supporto delle versioni di DynamoDB.

Il provider più recente è un provider di materiali crittografici (CMP) progettato per funzionare con gli archivi del provider. Ottiene i CMP dall'archivio del provider e recupera i materiali crittografici che restituisce dai CMP. In genere utilizza ciascun CMP per soddisfare più richieste di materiali crittografici. Ma puoi utilizzare le funzioni del suo archivio provider per controllare in quale misura i materiali vengono riutilizzati, stabilire la frequenza di rotazione del CMP e persino cambiare il tipo di CMP utilizzato senza cambiare il provider più recente.

Nota

Il codice associato al MostRecentProvider simbolo del provider più recente potrebbe archiviare materiali crittografici in memoria per tutta la durata del processo. Potrebbe consentire a un chiamante di utilizzare chiavi che non è più autorizzato a utilizzare.

Il MostRecentProvider simbolo è obsoleto nelle versioni precedenti supportate del client di crittografia DynamoDB e rimosso dalla versione 2.0.0. È sostituito dal CachingMostRecentProvider simbolo. Per informazioni dettagliate, consultare Aggiornamenti al provider più recente.

Il provider più recente è una buona scelta per le applicazioni che devono ridurre al minimo le chiamate all'archivio provider e all'origine crittografica e per le applicazioni che possono riutilizzare alcuni materiali crittografici senza violare i requisiti di sicurezza. Ad esempio, ti consente di proteggere i tuoi materiali crittografici con un AWS KMS keyin AWS Key Management Service(AWS KMS) senza chiamare AWS KMS ogni volta che crittografi o decrittografi un elemento.

L'archivio provider che hai scelto determina il tipo di CMP utilizzato dal provider più recente e la frequenza con cui questi ottiene un nuovo CMP. Puoi utilizzare qualsiasi archivio provider compatibile con il provider più recente, inclusi quelli personalizzati che hai progettato.

Il client di crittografia DynamoDB include un programma MetaStoreche crea e restituisce Wrapped Materials Provider (Wrapped CMP). MetaStoreSalva più versioni dei Wrapped CMP che genera in una tabella DynamoDB interna e le protegge con la crittografia lato client tramite un'istanza interna del DynamoDB Encryption Client.

Puoi configurarlo MetaStore per utilizzare qualsiasi tipo di CMP interno per proteggere i materiali nella tabella, incluso un Direct KMS Provider che genera materiali crittografici protetti dall'utenteAWS KMS key, una CMP Wrapped che utilizza le chiavi di wrapping e firma fornite o una CMP personalizzata compatibile progettata da te.

Per il codice di esempio, consulta:

• Java: MostRecentEncryptedItem

• Python: most_recent_provider_encrypted_table

Come utilizzarlo

Per creare un provider più recente devi creare e configurare un archivio provider e quindi creare un provider più recente che lo utilizzi.

Gli esempi seguenti mostrano come creare un provider più recente che utilizza MetaStore e protegge le versioni nella sua tabella DynamoDB interna con materiali crittografici di un Direct KMS Provider. In questi esempi viene utilizzato il CachingMostRecentProvidersimbolo.

Ogni provider più recente ha un nome che identifica i suoi CMP nella MetaStore tabella, un'impostazione time-to-live(TTL) e un'impostazione della dimensione della cache che determina quante voci può contenere la cache. Questi esempi impostano la dimensione della cache su 1000 voci e un TTL di 60 secondi.

Java

// Set the name for MetaStore's internal table
final String keyTableName = 'metaStoreTable'

// Set the Region and AWS KMS key
final String region = 'us-west-2'
final String keyArn = 'arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab'

// Set the TTL and cache size
final long ttlInMillis = 60000;
final long cacheSize = 1000;

// Name that identifies the MetaStore's CMPs in the provider store
final String materialName = 'testMRP'

// Create an internal DynamoDB client for the MetaStore
final AmazonDynamoDB ddb = AmazonDynamoDBClientBuilder.standard().withRegion(region).build();

// Create an internal Direct KMS Provider for the MetaStore
final AWSKMS kms = AWSKMSClientBuilder.standard().withRegion(region).build();
final DirectKmsMaterialProvider kmsProv = new DirectKmsMaterialProvider(kms, keyArn);

// Create an item encryptor for the MetaStore,
// including the Direct KMS Provider
final DynamoDBEncryptor keyEncryptor = DynamoDBEncryptor.getInstance(kmsProv);

// Create the MetaStore
final MetaStore metaStore = new MetaStore(ddb, keyTableName, keyEncryptor);

//Create the Most Recent Provider
final CachingMostRecentProvider cmp = new CachingMostRecentProvider(metaStore, materialName, ttlInMillis, cacheSize);

Python

# Designate an AWS KMS key
kms_key_id = 'arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab'

# Set the name for MetaStore's internal table
meta_table_name = 'metaStoreTable'

# Name that identifies the MetaStore's CMPs in the provider store
material_name = 'testMRP'

# Create an internal DynamoDB table resource for the MetaStore
meta_table = boto3.resource('dynamodb').Table(meta_table_name)

# Create an internal Direct KMS Provider for the MetaStore
kms_cmp = AwsKmsCryptographicMaterialsProvider(key_id=kms_key_id)
    
# Create the MetaStore with the Direct KMS Provider
meta_store = MetaStore(
    table=meta_table,
    materials_provider=kms_cmp
)

# Create a Most Recent Provider using the MetaStore
#    Sets the TTL (in seconds) and cache size (# entries)
most_recent_cmp = MostRecentProvider(
    provider_store=meta_store,
    material_name=material_name,
    version_ttl=60.0,
    cache_size=1000
)

Come funziona

Il provider più recente riceve i CMP da un archivio provider. Quindi utilizza il CMP per generare i materiali crittografici che restituisce al componente di crittografia dell'item.

Informazioni sul provider più recente

Il provider più recente ottiene un provider di materiali crittografici (CMP) da un archivio provider. Utilizza quindi il CMP per generare i materiali crittografici che restituisce. Ciascun provider più recente è associato a un archivio provider, ma un archivio provider può fornire CMP a più provider su più host.

Il provider più recente può utilizzare qualsiasi CMP compatibile di qualsiasi archivio provider. Richiede materiali di crittografia o decrittografia dal CMP e restituisce l'output al criptatore dell'elemento. Non esegue alcuna operazione crittografica.

Per richiedere un CMP al suo archivio provider, il provider più recente fornisce il nome del materiale e la versione di un CMP esistente che desidera utilizzare. Per i materiali di crittografia, il provider più recente richiede sempre la versione massima ("più recente"). Per i materiali di decrittografia, richiede la versione del CMP che è stata utilizzata per creare i materiali di crittografia, come mostrato nel diagramma seguente.

Il provider più recente salva le versioni dei CMP che l'archivio provider restituisce nella cache degli item utilizzati meno di recente (LRU) in memoria. La cache consente al provider più recente di ottenere i CMP di cui ha bisogno senza chiamare l'archivio provider per ogni item. Puoi cancellare la cache on-demand.

Il provider più recente utilizza un time-to-livevalore configurabile che è possibile regolare in base alle caratteristiche dell'applicazione.

Informazioni su MetaStore

Puoi utilizzare un provider più recente con qualsiasi archivio provider, anche un archivio provider personalizzato compatibile. Il client di crittografia DynamoDB include un'MetaStoreimplementazione sicura che puoi configurare e personalizzare.

A MetaStoreè un provider store che crea e restituisce i Wrapped CMP configurati con la chiave di wrapping, la chiave di unwrapping e la chiave di firma richieste da Wrapped CMP. A MetaStore è un'opzione sicura per un provider più recente perché i Wrapped CMP generano sempre chiavi di crittografia degli articoli univoche per ogni elemento. Vengono riutilizzate solo la chiave di wrapping che protegge la chiave di crittografia degli item e le chiavi di firma.

Il diagramma seguente mostra i componenti MetaStore e come interagisce con il provider più recente.

MetaStoreGenera i Wrapped CMP e li archivia (in forma crittografata) in una tabella DynamoDB interna. La chiave di partizione è il nome del materiale del fornitore più recente; la chiave di ordinamento è il numero di versione. I materiali della tabella sono protetti da un client di crittografia DynamoDB interno, che include un criptatore di elementi e un fornitore interno di materiali crittografici (CMP).

Puoi utilizzare qualsiasi tipo di CMP interna nella tuaMetaStore, incluso un Direct KMS Provider, una CMP Wrapped con materiali crittografici che fornisci o una CMP personalizzata compatibile. Se la CMP interna del tuo MetaStore è un Direct KMS Provider, le tue chiavi di wrapping e firma riutilizzabili sono protette da un AWS KMS keyin (). AWS Key Management ServiceAWS KMS Le MetaStore chiamate AWS KMS ogni volta che aggiunge una nuova versione CMP alla tabella interna o ottiene una versione CMP dalla tabella interna.

Impostazione di un time-to-live valore

Puoi impostare un valore time-to-live (TTL) per ogni provider più recente che crei. In generale, utilizzate il valore TTL più basso possibile per la vostra applicazione.

L'uso del valore TTL viene modificato nel CachingMostRecentProvider simbolo del provider più recente.

Nota

Il MostRecentProvider simbolo del provider più recente è obsoleto nelle versioni precedenti supportate del client di crittografia DynamoDB e rimosso dalla versione 2.0.0. È sostituito dal CachingMostRecentProvider simbolo. Ti consigliamo di aggiornare il codice il prima possibile. Per informazioni dettagliate, consultare Aggiornamenti al provider più recente.

CachingMostRecentProvider

CachingMostRecentProviderUtilizza il valore TTL in due modi diversi.

• Il TTL determina la frequenza con cui il provider più recente verifica la presenza di una nuova versione della CMP nell'archivio del provider. Se è disponibile una nuova versione, il provider più recente sostituisce il suo CMP e aggiorna i materiali crittografici. Altrimenti, continua a utilizzare il suo attuale materiale CMP e crittografico.

• Il TTL determina per quanto tempo possono essere utilizzati i CMP nella cache. Prima di utilizzare una CMP memorizzata nella cache per la crittografia, il provider più recente valuta il tempo trascorso nella cache. Se il tempo di cache CMP supera il TTL, il CMP viene rimosso dalla cache e il provider più recente ottiene una nuova CMP più recente dall'archivio del provider.

MostRecentProvider

NelMostRecentProvider, il TTL determina la frequenza con cui il provider più recente verifica la presenza di una nuova versione della CMP nell'archivio del provider. Se è disponibile una nuova versione, il provider più recente sostituisce il suo CMP e aggiorna i materiali crittografici. Altrimenti, continua a utilizzare il suo attuale materiale CMP e crittografico.

Il TTL non determina la frequenza con cui viene creata una nuova versione CMP. Si creano nuove versioni CMP ruotando i materiali crittografici.

Il valore TTL ideale varia in base all'applicazione e ai suoi obiettivi di latenza e disponibilità. Un TTL inferiore migliora il profilo di sicurezza riducendo il tempo di archiviazione dei materiali crittografici in memoria. Inoltre, un TTL inferiore aggiorna le informazioni critiche più frequentemente. Ad esempio, se il tuo CMP interno è un Direct KMS Provider, verifica più frequentemente che il chiamante sia ancora autorizzato a utilizzare un. AWS KMS key

Tuttavia, se il TTL è troppo breve, le frequenti chiamate all'archivio del provider possono aumentare i costi e far sì che il negozio del provider limiti le richieste provenienti dall'applicazione e da altre applicazioni che condividono l'account del servizio. Potresti anche trarre vantaggio dal coordinamento del TTL con la velocità con cui ruotate i materiali crittografici.

Durante i test, varia il TTL e la dimensione della cache in base a diversi carichi di lavoro fino a trovare una configurazione adatta alla tua applicazione e ai tuoi standard di sicurezza e prestazioni.

Rotazione dei materiali crittografici

Quando un Most Recent Provider necessita di materiale crittografato, utilizza sempre la versione più recente della sua CMP di cui è a conoscenza. La frequenza con cui verifica la presenza di una versione più recente è determinata dal valore time-to-live(TTL) impostato durante la configurazione del provider più recente.

Alla scadenza del TTL, il provider più recente verifica la presenza di una versione più recente della CMP nell'archivio del provider. Se disponibile, il provider più recente lo ottiene e sostituisce il CMP nella sua cache. Utilizza questa CMP e il suo materiale crittografico fino a quando non scopre che il provider store ha una versione più recente.

Per indicare all'archivio provider di creare una nuova versione di un CMP per un provider più recente, richiama l'operazione Create New Provider (Crea nuovo provider) dell'archivio provider con il nome del materiale del provider più recente. L'archivio provider crea un nuovo CMP e salva una copia crittografata nel suo storage interno con un numero di versione superiore: Restituisce anche un CMP, ma puoi ignorarlo. Di conseguenza, la prossima volta che il provider più recente interroga l'archivio del provider per il numero massimo di versioni dei suoi CMP, ottiene il nuovo numero di versione maggiore e lo utilizza nelle successive richieste allo store per verificare se è stata creata una nuova versione della CMP.

Puoi programmare le chiamate Create New Provider (Crea nuovo provider) sulla base del tempo, del numero di item o di attributi elaborati o su qualsiasi altro parametro rilevante per la tua applicazione.

Ottenere materiali di crittografia

Il provider più recente utilizza il seguente processo, mostrato in questo diagramma, per ottenere i materiali di crittografia che restituisce al componente di crittografia dell'item. L'output dipende dal tipo di CMP restituito dall'archivio provider. Il provider più recente può utilizzare qualsiasi provider store compatibile, incluso MetaStore quello incluso nel client di crittografia DynamoDB.

Quando si crea un provider più recente utilizzando il CachingMostRecentProvidersimbolo, si specifica un archivio provider, un nome per il provider più recente e un valore time-to-live(TTL). È inoltre possibile specificare una dimensione della cache, che determina il numero massimo di materiali crittografici che possono esistere nella cache.

Quando il componente di crittografia dell'item chiede al provider più recente i materiali di crittografia, il provider più recente inizia a cercare nella sua cache la versione più recente del suo CMP.

• Se trova la versione CMP più recente nella sua cache e la CMP non ha superato il valore TTL, il provider più recente utilizza la CMP per generare materiali di crittografia. Quindi restituisce i materiali di crittografia al componente di crittografia dell'item. Questa operazione non richiede una chiamata dell'archivio provider.

• Se la versione più recente della CMP non è nella cache o se si trova nella cache ma ha superato il suo valore TTL, il provider più recente richiede una CMP dall'archivio del provider. La richiesta include il nome del materiale del provider più recente e il numero della versione massima che conosce.

  1. L'archivio provider restituisce un CMP dal suo storage persistente. Se l'archivio del provider è unMetaStore, ottiene una CMP Wrapped crittografata dalla sua tabella DynamoDB interna utilizzando il nome del materiale del provider più recente come chiave di partizione e il numero di versione come chiave di ordinamento. MetaStoreUtilizza il suo criptatore interno per gli elementi e la CMP interna per decrittografare la Wrapped CMP. Quindi restituisce il CMP come testo normale al provider più recente. Se il CMP interno è un provider KMS diretto, questa fase prevede una chiamata a AWS Key Management Service (AWS KMS).

  2. Il CMP aggiunge il campo amzn-ddb-meta-id alla descrizione dei materiali effettivi. Il suo valore è il nome del materiale e la versione del CMP nella sua tabella interna. L'archivio provider restituisce al provider più recente il CMP come testo normale.

  3. Il provider più recente archivia il CMP nella cache.

  4. Il provider più recente utilizza il CMP per generare i materiali di crittografia. Quindi restituisce i materiali di crittografia al componente di crittografia dell'item.

Mostra piùMostra meno

Ottenere materiali di decrittografia

Quando il componente di crittografia dell'item chiede al provider più recente i materiali di decrittografia, il provider più recente utilizza il seguente processo per ottenerli e restituirli.

1. Il provider più recente chiede all'archivio provider il numero di versione dei materiali crittografici utilizzati per crittografare l'item. Passa la descrizione dei materiali effettivi dall'attributo di descrizione del materiale dell'item.

2. L'archivio provider riceve il numero di versione del CMP di crittografia dal campo amzn-ddb-meta-id nella descrizione dei materiali effettivi e lo restituisce al provider più recente.

3. Il provider più recente ricerca nella sua cache la versione del CMP utilizzata per crittografare e firmare l'item.

• Se rileva che la versione corrispondente della CMP è nella sua cache e la CMP non ha superato il valore time-to-live (TTL), il provider più recente utilizza la CMP per generare materiali di decrittografia. Quindi restituisce i materiali di decrittografia al componente di crittografia dell'item. Questa operazione non richiede una chiamata dell'archivio provider o a qualsiasi altro CMP.

• Se la versione corrispondente della CMP non è nella cache o se quella memorizzata nella cache AWS KMS key ha superato il suo valore TTL, il provider più recente richiede una CMP dall'archivio del provider. Nella richiesta invia il nome del materiale e il numero di versione del suo CMP di crittografia.

  1. L'archivio provider ricerca nello storage persistente il CMP utilizzando il nome del provider più recente come chiave di partizione e il numero di versione come chiave di ordinamento.

     • Se il nome e il numero di versione non sono nello storage persistente, l'archivio provider rileva un'eccezione. Se l'archivio provider è stato utilizzato per generare il CMP, il CMP dovrebbe essere archiviato nel suo storage persistente, a meno che non sia stato volutamente eliminato.

     • Se il CMP con il numero di versione e il nome corrispondenti sono disponibili nello storage persistente dell'archivio provider, quest'ultimo restituisce il CMP specificato al provider più recente.

       Se l'archivio del provider è unMetaStore, ottiene la CMP crittografata dalla relativa tabella DynamoDB. Quindi utilizza i materiali crittografici dal suo CMP interno per decrittografare il CMP crittografato prima di restituire il CMP al provider più recente. Se il CMP interno è un provider KMS diretto, questa fase prevede una chiamata a AWS Key Management Service (AWS KMS).

  2. Il provider più recente archivia il CMP nella cache.

  3. Il provider più recente utilizza il CMP per generare i materiali di decrittografia. Quindi restituisce i materiali di decrittografia al componente di crittografia dell'item.

Mostra piùMostra meno

Aggiornamenti al provider più recente

Il simbolo del provider più recente viene modificato da MostRecentProvider aCachingMostRecentProvider.

Nota

Il MostRecentProvider simbolo, che rappresenta il provider più recente, è obsoleto nella versione 1.15 del client di crittografia DynamoDB per Java e nella versione 1.3 del client di crittografia DynamoDB per Python e rimosso dalle versioni 2.0.0 del client di crittografia DynamoDB in entrambe le implementazioni linguistiche. Anziché, usa ilCachingMostRecentProvider.

CachingMostRecentProviderImplementa le seguenti modifiche:

• Rimuove CachingMostRecentProvider periodicamente i materiali crittografici dalla memoria quando il loro tempo in memoria supera il valore configurato time-to-live (TTL).

  MostRecentProviderPotrebbero archiviare materiali crittografici in memoria per tutta la durata del processo. Di conseguenza, il fornitore più recente potrebbe non essere a conoscenza delle modifiche alle autorizzazioni. Potrebbe utilizzare chiavi di crittografia dopo la revoca delle autorizzazioni del chiamante per utilizzarle.

  Se non riesci ad eseguire l'aggiornamento a questa nuova versione, puoi ottenere un effetto simile chiamando periodicamente il clear() metodo nella cache. Questo metodo svuota manualmente il contenuto della cache e richiede al provider più recente di richiedere una nuova CMP e nuovi materiali crittografici.

• Include CachingMostRecentProvider anche un'impostazione della dimensione della cache che offre un maggiore controllo sulla cache.

Per eseguire l'aggiornamento alCachingMostRecentProvider, devi modificare il nome del simbolo nel tuo codice. Sotto tutti gli altri aspetti, CachingMostRecentProvider è completamente retrocompatibile con. MostRecentProvider Non è necessario crittografare nuovamente alcun elemento della tabella.

Tuttavia, CachingMostRecentProvider genera più chiamate all'infrastruttura chiave sottostante. Chiama l'archivio del provider almeno una volta in ogni intervallo time-to-live (TTL). È probabile che le applicazioni con numerose CMP attive (a causa della rotazione frequente) o le applicazioni con flotte di grandi dimensioni siano sensibili a questo cambiamento.

Prima di rilasciare il codice aggiornato, testalo attentamente per assicurarti che le chiamate più frequenti non compromettano l'applicazione o causino limitazioni da parte dei servizi da cui dipende il tuo provider, come AWS Key Management Service (AWS KMS) o Amazon DynamoDB. Per mitigare eventuali problemi di prestazioni, regola la dimensione e la time-to-live della cache in CachingMostRecentProvider base alle caratteristiche prestazionali osservate. Per le linee guida, consulta Impostazione di un time-to-live valore.