Configurazione della crittografia del database AWS SDK - AWS Crittografia database SDK

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 della crittografia del database AWS SDK

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

La crittografia del AWS database SDK è progettata per essere facile da usare. Sebbene la crittografia del AWS database 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

La crittografia del AWS database 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

La crittografia del AWS database SDK genera una chiave dati simmetrica unica per crittografare ogni campo. Non è necessario configurare, gestire o utilizzare le chiavi dati. La crittografia del AWS database lo SDK fa per te.

Tuttavia, è necessario selezionare una o più chiavi di wrapping per crittografare ciascuna chiave di dati. La crittografia del AWS database SDK supporta AWS Key Management Service(AWS KMS) chiavi di crittografia simmetriche e KMS chiavi asimmetriche. RSA KMS Supporta anche chiavi AES simmetriche e chiavi RSA asimmetriche 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, la crittografia del AWS database SDK deve prima utilizzare una delle chiavi di wrapping per decrittografare una chiave di dati crittografata.

Ti consigliamo di utilizzare uno dei portachiavi ogni volta che è possibile. AWS KMS La crittografia del AWS database 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, utilizzate un identificatore di chiave supportato. AWS KMS Se si utilizza il portachiavi AWS KMS gerarchico, è necessario specificare la chiave. ARN 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 (chiaveARN, nome alias, alias o ID chiave) per una chiave di crittografia simmetrica. ARN KMS Se si utilizza una chiave asimmetrica RSAKMS, è necessario specificare la chiave. ARN

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

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

    Quando si esegue la crittografia con un AWS KMS portachiavi, la crittografia del AWS database SDK memorizza la chiave presente AWS KMS key nella descrizione ARN del materiale con la chiave dei dati crittografata. Quando si esegue la decrittografia in modalità rigorosa, la crittografia del AWS database SDK verifica che la stessa chiave sia ARN 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, la crittografia del AWS database non riconoscerà né SDK utilizzerà il AWS KMS key, anche se gli identificatori si riferiscono alla stessa chiave.

  • Durante la decrittografia in modalità di rilevamento, non si specifica alcuna chiave di avvolgimento. Innanzitutto, la crittografia del AWS database SDK tenta di decrittografare il record con la chiave ARN memorizzata nella descrizione del materiale. Se ciò non funziona, la crittografia del AWS database SDK chiede AWS KMS di decrittografare il record utilizzando la KMS chiave che lo ha crittografato, indipendentemente da chi possiede o ha accesso a quella chiave. KMS

Per specificare una AESchiave grezza o una coppia di RSA chiavi non elaborate come chiave di avvolgimento 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 utilizzati durante la crittografia. Se si utilizza un namespace o un nome diverso, AWS Database Encryption non riconoscerà né SDK 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 KMS chiavi, è 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 possibile decrittografare la chiave dati crittografata utilizzando la KMS chiave che l'ha crittografata, indipendentemente da chi possiede o ha accesso a tale chiave. KMS

Se è necessario decrittografare in modalità di rilevamento, si consiglia di utilizzare sempre un filtro di rilevamento, che limita le KMS chiavi che possono essere utilizzate a quelle presenti in una partizione e specificata. Account AWS Il filtro di individuazione è 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 la crittografia del AWS databaseSDK, è possibile 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 tuoi 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 la crittografia del database con un'altra soluzione di crittografia lato server. AWS SDK

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

La crittografia del AWS database 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, la crittografia del AWS database supporta SDK anche beacon firmati che possono essere configurati interamente da campi firmati in testo non crittografato. I beacon firmati sono un tipo di beacon composto che indicizza ed esegue interrogazioni 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 solo una 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. AWS SDK Distribuite 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. Due beacon non possono avere lo stesso nome.

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 la crittografia del AWS database SDK utilizzerà automaticamente il nome come fonte. Si consiglia 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 beacon firmato.

Se non si specifica 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.