Configurazione del Database Encryption SDK AWS - AWS SDK per la crittografia del database

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

Configurazione del Database Encryption SDK AWS

La nostra libreria di crittografia lato client è stata rinominata Database Encryption SDK. AWS Questa guida per sviluppatori fornisce ancora informazioni sul DynamoDB Encryption Client.

Il AWS Database Encryption SDK è progettato per essere facile da usare. Sebbene AWS Database Encryption SDK abbia diverse opzioni di configurazione, i valori predefiniti vengono scelti con cura per essere pratici e sicuri per la maggior parte delle applicazioni. Tuttavia, potrebbe essere necessario modificare la configurazione per migliorare le prestazioni o includere una funzionalità personalizzata nella progettazione.

Selezione di un linguaggio di programmazione

Il AWS Database Encryption SDK per DynamoDB è disponibile in diversi linguaggi di programmazione. Le implementazioni del linguaggio sono progettate per essere completamente interoperabili e per offrire le stesse funzionalità, sebbene possano essere implementate in modi diversi. In genere, si utilizza la libreria compatibile con l'applicazione.

Selezione delle chiavi di avvolgimento

Il AWS Database Encryption SDK genera una chiave dati simmetrica unica per crittografare ogni campo. Non è necessario configurare, gestire o utilizzare le chiavi dati. AWS Database Encryption SDK lo fa per te.

Tuttavia, è necessario selezionare una o più chiavi di wrapping per crittografare ogni chiave di dati. AWS Database Encryption SDK supporta AWS Key Management Service(AWS KMS) chiavi KMS di crittografia simmetrica e chiavi KMS RSA asimmetriche. Supporta anche chiavi simmetriche AES e chiavi asimmetriche RSA fornite in diverse dimensioni. Sei responsabile della sicurezza e della durata delle tue chiavi di wrapping, quindi ti consigliamo di utilizzare una chiave di crittografia in un modulo di sicurezza hardware o in un servizio di infrastruttura chiave, ad esempio. AWS KMS

Per specificare le chiavi di avvolgimento per la crittografia e la decrittografia, si utilizza un portachiavi. A seconda del tipo di portachiavi utilizzato, è possibile specificare una chiave di avvolgimento o più chiavi di avvolgimento dello stesso tipo o di tipi diversi. Se utilizzi più chiavi di wrapping per racchiudere una chiave dati, ogni chiave di wrapping crittograferà una copia della stessa chiave dati. Le chiavi dati crittografate (una per chiave di avvolgimento) vengono memorizzate nella descrizione del materiale memorizzata accanto al campo crittografato. Per decrittografare i dati, il AWS Database Encryption SDK deve prima utilizzare una delle chiavi di wrapping per decrittografare una chiave dati crittografata.

Ti consigliamo di utilizzare uno dei portachiavi ogni volta che è possibile. AWS KMS Il AWS Database Encryption SDK fornisce il AWS KMS portachiavi e il portachiavi AWS KMS gerarchico, che riducono il numero di chiamate effettuate a. AWS KMS Per specificare un elemento AWS KMS key in un portachiavi, utilizza un identificatore di chiave supportato. AWS KMS Se si utilizza il portachiavi AWS KMS gerarchico, è necessario specificare l'ARN della chiave. Per i dettagli sugli identificatori chiave per una chiave, consulta Identificatori AWS KMS chiave nella Guida per gli sviluppatori.AWS Key Management Service

  • Quando si esegue la crittografia con un AWS KMS portachiavi, è possibile specificare qualsiasi identificatore di chiave valido (ARN della chiave, nome alias, alias ARN o ID chiave) per una chiave KMS di crittografia simmetrica. Se si utilizza una chiave RSA KMS asimmetrica, è necessario specificare la chiave ARN.

    Se si specifica un nome alias o un alias ARN per una chiave KMS durante la crittografia, AWS Database Encryption SDK salva la chiave ARN attualmente associata a quell'alias; non salva l'alias. Le modifiche all'alias non influiscono sulla chiave KMS utilizzata per decrittografare le chiavi dati.

  • Per impostazione predefinita, il AWS KMS portachiavi decripta i record in modalità rigorosa (dove si specificano particolari chiavi KMS). È necessario utilizzare una chiave ARN per l'identificazione AWS KMS keys per la decrittografia.

    Quando si esegue la crittografia con un AWS KMS portachiavi, AWS Database Encryption SDK memorizza l'ARN della chiave AWS KMS key nella descrizione del materiale con la chiave dati crittografata. Durante la decrittografia in modalità rigorosa, AWS Database Encryption SDK verifica che la stessa chiave ARN sia presente nel portachiavi prima di tentare di utilizzare la chiave di wrapping per decrittografare la chiave dati crittografata. Se si utilizza un identificatore di chiave diverso, AWS Database Encryption SDK non lo riconoscerà né lo utilizzerà, anche se gli identificatori si riferiscono alla AWS KMS key stessa chiave.

  • Durante la decrittografia in modalità Discovery, non viene specificata alcuna chiave di wrapping. Innanzitutto, il AWS Database Encryption SDK tenta di decrittografare il record con la chiave ARN memorizzata nella descrizione del materiale. Se ciò non funziona, AWS Database Encryption SDK chiede AWS KMS di decrittografare il record utilizzando la chiave KMS che lo ha crittografato, indipendentemente da chi possiede o ha accesso a quella chiave KMS.

Per specificare una chiave AES non elaborata o una coppia di chiavi RSA non elaborata come chiave di wrapping in un portachiavi, è necessario specificare uno spazio dei nomi e un nome. Durante la decrittografia, è necessario utilizzare lo stesso identico spazio dei nomi e lo stesso nome per ogni chiave di wrapping non elaborata utilizzata durante la crittografia. Se utilizzi un namespace o un nome diverso, AWS Database Encryption SDK non riconoscerà né utilizzerà la chiave di wrapping, anche se il materiale della chiave è lo stesso.

Creazione di un filtro di rilevamento

Quando si decifrano dati crittografati con chiavi KMS, è consigliabile decrittografarli in modalità rigorosa, ovvero limitare le chiavi di wrapping utilizzate solo a quelle specificate dall'utente. Tuttavia, se necessario, puoi anche decrittografare in modalità di scoperta, in cui non specifichi alcuna chiave di wrapping. In questa modalità, AWS KMS puoi decrittografare la chiave dati crittografata utilizzando la chiave KMS che l'ha crittografata, indipendentemente da chi possiede o ha accesso a quella chiave KMS.

Se è necessario decrittografare in modalità di rilevamento, si consiglia di utilizzare sempre un filtro di rilevamento, che limita le chiavi KMS che possono essere utilizzate a quelle presenti in una partizione e specificata. Account AWS Il filtro di rilevamento è facoltativo, ma è una procedura consigliata.

Utilizza la tabella seguente per determinare il valore della partizione per il filtro di rilevamento.

Regione Partizione
Regioni AWS aws
Regioni della Cina aws-cn
AWS GovCloud (US) Regions aws-us-gov

L'esempio seguente mostra come creare un filtro di rilevamento. Prima di utilizzare il codice, sostituite i valori di esempio con valori validi per la partizione Account AWS and.

Java
// Create the discovery filter DiscoveryFilter discoveryFilter = DiscoveryFilter.builder() .partition("aws") .accountIds(111122223333) .build();
C# / .NET
var discoveryFilter = new DiscoveryFilter { Partition = "aws", AccountIds = 111122223333 };

Lavorare con database multitenant

Con AWS Database Encryption SDK, puoi configurare la crittografia lato client per i database con uno schema condiviso isolando ogni tenant con materiali di crittografia distinti. Quando prendi in considerazione un database multitenant, dedica del tempo a esaminare i requisiti di sicurezza e il modo in cui la multitenancy potrebbe influire su di essi. Ad esempio, l'utilizzo di un database multitenant potrebbe influire sulla capacità di combinare Database Encryption SDK con un'altra soluzione di crittografia lato server AWS .

Se più utenti eseguono operazioni di crittografia all'interno del database, puoi utilizzare uno dei AWS KMS portachiavi per fornire a ciascun utente una chiave distinta da utilizzare nelle proprie operazioni crittografiche. La gestione delle chiavi dati per una soluzione di crittografia lato client multitenant può essere complicata. Ti consigliamo di organizzare i dati per tenant quando possibile. Se il tenant è identificato dai valori della chiave primaria (ad esempio, la chiave di partizione in una tabella Amazon DynamoDB), la gestione delle chiavi è più semplice.

Puoi usare il AWS KMS portachiavi per isolare ogni tenant con un portachiavi distinto e. AWS KMS AWS KMS keys In base al volume di AWS KMS chiamate effettuate per inquilino, potresti voler utilizzare il portachiavi AWS KMS gerarchico per ridurre al minimo le chiamate a. AWS KMS Il portachiavi AWS KMS 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. È necessario utilizzare il portachiavi Hierarchical per implementare la crittografia ricercabile nel database. AWS KMS

Creazione di beacon firmati

AWS Database Encryption SDK utilizza beacon standard e beacon composti per fornire soluzioni di crittografia ricercabili che consentono di cercare record crittografati senza decrittografare l'intero database interrogato. Tuttavia, AWS Database Encryption SDK supporta anche beacon firmati che possono essere configurati interamente a partire da campi firmati in testo semplice. I beacon firmati sono un tipo di beacon composto che indicizza ed esegue query complesse su campi e. SIGN_ONLY SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT

Ad esempio, se disponete di un database multitenant, potreste voler creare un beacon firmato che consenta di interrogare il database alla ricerca di record crittografati dalla chiave di un tenant specifico. Per ulteriori informazioni, consulta Interrogazione dei beacon in un database multi-tenant.

È necessario utilizzare il portachiavi AWS KMS gerarchico per creare beacon firmati.

Per configurare un beacon firmato, fornite i seguenti valori.

Java

Configurazione del beacon composto

L'esempio seguente definisce gli elenchi delle parti firmate localmente all'interno della configurazione del beacon firmato.

List<CompoundBeacon> compoundBeaconList = new ArrayList<>(); CompoundBeacon exampleCompoundBeacon = CompoundBeacon.builder() .name("compoundBeaconName") .split(".") .signed(signedPartList) .constructors(constructorList) .build(); compoundBeaconList.add(exampleCompoundBeacon);

Definizione della versione del beacon

L'esempio seguente definisce gli elenchi delle parti firmate a livello globale nella versione beacon. Per ulteriori informazioni sulla definizione della versione beacon, vedete Uso dei beacon.

List<BeaconVersion> beaconVersions = new ArrayList<>(); beaconVersions.add( BeaconVersion.builder() .standardBeacons(standardBeaconList) .compoundBeacons(compoundBeaconList) .signedParts(signedPartList) .version(1) // MUST be 1 .keyStore(keyStore) .keySource(BeaconKeySource.builder() .single(SingleKeyStore.builder() .keyId(branchKeyId) .cacheTTL(6000) .build()) .build()) .build() );
C# / .NET

Guarda l'esempio di codice completo: .cs BeaconConfig

Configurazione del beacon firmato

L'esempio seguente definisce gli elenchi delle parti firmate localmente all'interno della configurazione del beacon firmato.

var compoundBeaconList = new List<CompoundBeacon>(); var exampleCompoundBeacon = new CompoundBeacon { Name = "compoundBeaconName", Split = ".", Signed = signedPartList, Constructors = constructorList }; compoundBeaconList.Add(exampleCompoundBeacon);

Definizione della versione del beacon

L'esempio seguente definisce gli elenchi delle parti firmate a livello globale nella versione beacon. Per ulteriori informazioni sulla definizione della versione beacon, vedete Uso dei beacon.

var beaconVersions = new List<BeaconVersion> { new BeaconVersion { StandardBeacons = standardBeaconList, CompoundBeacons = compoundBeaconList, SignedParts = signedPartsList, Version = 1, // MUST be 1 KeyStore = keyStore, KeySource = new BeaconKeySource { Single = new SingleKeyStore { KeyId = branchKeyId, CacheTTL = 6000 } } } };

È possibile definire le parti firmate in elenchi definiti localmente o globalmente. Ti consigliamo di definire le parti firmate in un elenco globale nella versione beacon, quando possibile. Definendo le parti firmate a livello globale, è possibile definire ogni parte una volta e quindi riutilizzare le parti in più configurazioni beacon composte. Se intendete utilizzare una parte firmata una sola volta, potete definirla in un elenco locale nella configurazione del beacon firmato. È possibile fare riferimento sia alle parti locali che a quelle globali nell'elenco dei costruttori.

Se definite gli elenchi di parti firmate a livello globale, dovete fornire un elenco di parti del costruttore che identifichi tutti i possibili modi in cui il beacon firmato può assemblare i campi nella configurazione del beacon.

Nota

Per definire gli elenchi delle parti firmate a livello globale, è necessario utilizzare la versione 3.2 o successiva di Database Encryption SDK. AWS Distribuisci la nuova versione a tutti i lettori prima di definire nuove parti a livello globale.

Non è possibile aggiornare le configurazioni dei beacon esistenti per definire elenchi di parti firmate a livello globale.

Nome del beacon

Il nome che usi quando interroghi il faro.

Il nome di un beacon firmato non può avere lo stesso nome di un campo non crittografato. Non è possibile assegnare lo stesso nome a due beacon.

Carattere diviso

Il carattere usato per separare le parti che compongono il faro firmato.

Il carattere diviso non può apparire nei valori in chiaro di nessuno dei campi da cui è costruito il beacon firmato.

Elenco delle parti firmate

Identifica i campi firmati inclusi nel beacon firmato.

Ogni parte deve includere un nome, una fonte e un prefisso. L'origine è il SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT campo SIGN_ONLY o il campo identificato dalla parte. L'origine deve essere un nome di campo o un indice che si riferisce al valore di un campo annidato. Se il nome della parte identifica la fonte, puoi omettere la fonte e AWS Database Encryption SDK utilizzerà automaticamente il nome come fonte. Ti consigliamo di specificare l'origine come nome della parte quando possibile. Il prefisso può essere qualsiasi stringa, ma deve essere univoco. Due parti firmate in un beacon firmato non possono avere lo stesso prefisso. Si consiglia di utilizzare un valore breve che distingua la parte dalle altre parti servite dal beacon composto.

Ti consigliamo di definire le parti firmate a livello globale quando possibile. Potresti prendere in considerazione la definizione locale di una parte firmata se intendi utilizzarla solo in un beacon composto. Una parte definita localmente non può avere lo stesso prefisso o nome di una parte definita globalmente.

Java
List<SignedPart> signedPartList = new ArrayList<>); SignedPart signedPartExample = SignedPart.builder() .name("signedFieldName") .prefix("S-") .build(); signedPartList.add(signedPartExample);
C# / .NET
var signedPartsList = new List<SignedPart> { new SignedPart { Name = "signedFieldName1", Prefix = "S-" }, new SignedPart { Name = "signedFieldName2", Prefix = "SF-" } };
Elenco dei costruttori (opzionale)

Identifica i costruttori che definiscono i diversi modi in cui le parti firmate possono essere assemblate dal faro firmato.

Se non specificate un elenco di costruttori, AWS Database Encryption SDK assembla il beacon firmato con il seguente costruttore predefinito.

  • Tutte le parti firmate nell'ordine in cui sono state aggiunte all'elenco delle parti firmate

  • Tutte le parti sono obbligatorie

Costruttori

Ogni costruttore è un elenco ordinato di parti del costruttore che definisce un modo in cui il faro firmato può essere assemblato. Le parti del costruttore vengono unite nell'ordine in cui vengono aggiunte all'elenco, con ogni parte separata dal carattere di divisione specificato.

Ogni parte del costruttore nomina una parte firmata e definisce se tale parte è obbligatoria o facoltativa all'interno del costruttore. Ad esempio, se si desidera interrogare un faro firmato suField1, and Field1.Field2Field1.Field2.Field3, contrassegnare e Field3 come facoltativo Field2 e creare un costruttore.

Ogni costruttore deve avere almeno una parte obbligatoria. Si consiglia di rendere obbligatoria la prima parte di ogni costruttore in modo da poter utilizzare l'BEGINS_WITHoperatore nelle query.

Un costruttore ha successo se tutte le parti necessarie sono presenti nel record. Quando si scrive un nuovo record, il beacon firmato utilizza l'elenco dei costruttori per determinare se il beacon può essere assemblato in base ai valori forniti. Tenta di assemblare il beacon nell'ordine in cui i costruttori sono stati aggiunti all'elenco dei costruttori e utilizza il primo costruttore che riesce. Se nessun costruttore ha successo, il beacon non viene scritto nel record.

Tutti i lettori e gli scrittori devono specificare lo stesso ordine di costruttori per garantire che i risultati delle query siano corretti.

Utilizzate le seguenti procedure per specificare il vostro elenco di costruttori.

  1. Create una parte costruttore per ogni parte firmata per definire se quella parte è necessaria o meno.

    Il nome della parte del costruttore deve essere il nome del campo firmato.

    L'esempio seguente dimostra come creare una parte costruttore per un campo firmato.

    Java
    ConstructorPart field1ConstructorPart = ConstructorPart.builder() .name("Field1") .required(true) .build();
    C# / .NET
    var field1ConstructorPart = new ConstructorPart { Name = "Field1", Required = true };
  2. Create un costruttore per ogni modo possibile in cui il faro firmato può essere assemblato utilizzando le parti del costruttore create nel passaggio 1.

    Ad esempio, se si desidera eseguire un'interrogazione su Field1.Field2.Field3 andField4.Field2.Field3, è necessario creare due costruttori. Field1e Field4 possono essere entrambi obbligatori perché sono definiti in due costruttori separati.

    Java
    // Create a list for Field1.Field2.Field3 queries List<ConstructorPart> field123ConstructorPartList = new ArrayList<>(); field123ConstructorPartList.add(field1ConstructorPart); field123ConstructorPartList.add(field2ConstructorPart); field123ConstructorPartList.add(field3ConstructorPart); Constructor field123Constructor = Constructor.builder() .parts(field123ConstructorPartList) .build(); // Create a list for Field4.Field2.Field1 queries List<ConstructorPart> field421ConstructorPartList = new ArrayList<>(); field421ConstructorPartList.add(field4ConstructorPart); field421ConstructorPartList.add(field2ConstructorPart); field421ConstructorPartList.add(field1ConstructorPart); Constructor field421Constructor = Constructor.builder() .parts(field421ConstructorPartList) .build();
    C# / .NET
    // Create a list for Field1.Field2.Field3 queries var field123ConstructorPartList = new Constructor { Parts = new List<ConstructorPart> { field1ConstructorPart, field2ConstructorPart, field3ConstructorPart } }; // Create a list for Field4.Field2.Field1 queries var field421ConstructorPartList = new Constructor { Parts = new List<ConstructorPart> { field4ConstructorPart, field2ConstructorPart, field1ConstructorPart } };
  3. Create un elenco di costruttori che includa tutti i costruttori creati nel passaggio 2.

    Java
    List<Constructor> constructorList = new ArrayList<>(); constructorList.add(field123Constructor) constructorList.add(field421Constructor)
    C# / .NET
    var constructorList = new List<Constructor> { field123Constructor, field421Constructor };
  4. Specificate constructorList quando create il beacon firmato.