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 AWS SDK di crittografia del database
| 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 sono 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 nel progetto.
Argomenti
Selezione di un linguaggio di programmazione
Il AWS Database Encryption SDK per DynamoDB è disponibile in diversi linguaggi di programmazione. Le implementazioni linguistiche sono progettate per essere completamente interoperabili e offrire le stesse funzionalità, sebbene possano essere implementate in modi diversi. In genere, si utilizza la libreria compatibile con l'applicazione.
Selezione dei tasti di raggruppamento
Il AWS Database Encryption SDK genera una chiave dati simmetrica univoca per crittografare ogni campo. Non è necessario configurare, gestire o utilizzare le chiavi di dati. AWS Database Encryption SDK lo fa per te.
Tuttavia, è necessario selezionare una o più chiavi di wrapping per crittografare ciascuna 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 le chiavi simmetriche AES e le 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 wrapping per la crittografia e la decrittografia, si utilizza un portachiavi. Portachiavi A seconda del tipo di portachiavi utilizzato, è possibile specificare una chiave di wrapping o più chiavi di wrapping dello stesso tipo o di tipi diversi. Se si utilizzano più chiavi di wrapping per raggruppare una chiave di dati, ciascuna chiave di wrapping crittograferà una copia della stessa chiave di dati. Le chiavi di dati crittografate (una per chiave di wrapping) sono memorizzate nella descrizione del materiale archiviata accanto al campo crittografato. Per decrittografare i dati, AWS Database Encryption SDK deve prima utilizzare una delle chiavi di wrapping per decrittografare una chiave di dati crittografata.
Ti consigliamo di utilizzare uno dei portachiavi quando 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 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 informazioni dettagliate sugli identificatori chiave di una chiave, consulta AWS KMS Key Identifiers nella Developer Guide. AWS Key Management Service
-
Quando si esegue la crittografia con un AWS KMS portachiavi, è possibile specificare qualsiasi identificatore di chiave valido (chiave ARN, nome alias, ARN alias o ID chiave) per una chiave KMS di crittografia simmetrica. Se si utilizza una chiave KMS RSA 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 tale alias; non salva l'alias. Le modifiche all'alias non influiscono sulla chiave KMS utilizzata per decrittografare le chiavi di dati.
-
Per impostazione predefinita, il AWS KMS portachiavi decrittografa i record in modalità rigorosa (in cui si specificano particolari chiavi KMS). È necessario utilizzare una chiave ARN per identificarli e decrittografarli. AWS KMS keys
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 insieme alla chiave dati crittografata. Quando si decrittografa in modalità rigorosa, AWS Database Encryption SDK verifica che la stessa chiave ARN appaia nel portachiavi prima di tentare di utilizzare la chiave di wrapping per decrittografare la chiave di dati crittografata. Se si utilizza un identificatore di chiave diverso, AWS Database Encryption SDK non riconoscerà né utilizzerà il, anche se gli identificatori si riferiscono alla AWS KMS key stessa chiave.
-
Quando si decrittografa in modalità discovery, non si specifica 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 tale chiave KMS.
Per specificare una chiave AES non elaborata o una coppia di chiavi RSA non elaborata come chiave di inserimento in un portachiavi, è necessario specificare uno spazio dei nomi e un nome. Durante la decrittografia, è necessario utilizzare esattamente lo stesso namespace e lo stesso nome per ogni chiave di wrapping non elaborata utilizzati durante la crittografia. Se utilizzate 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 scoperta
Quando si decifrano i dati crittografati con chiavi KMS, è consigliabile decrittografarli in modalità rigorosa, ovvero limitare le chiavi di wrapping utilizzate solo a quelle specificate. Tuttavia, se necessario, è possibile decrittografare anche in modalità discovery, in cui non si specifica alcuna chiave di wrapping. In questa modalità, è AWS KMS possibile decrittografare la chiave dati crittografata utilizzando la chiave KMS 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 limiti le chiavi KMS utilizzabili a quelle contenute in una partizione e specificata. Account AWS https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html Il filtro di rilevamento è facoltativo, ma è una procedura consigliata.
Utilizzate la seguente tabella per determinare il valore della partizione per il filtro di rilevamento.
| Region | 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 vostra partizione Account AWS and.
Utilizzo di 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 tuoi requisiti di sicurezza e l'impatto che il multitenancy potrebbe avere 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 hai più utenti che eseguono operazioni di crittografia all'interno del tuo database, puoi utilizzare uno dei AWS KMS portachiavi per fornire a ciascun utente una chiave distinta da utilizzare nelle proprie operazioni di crittografia. La gestione delle chiavi di dati per una soluzione di crittografia multitenant lato client 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 utilizzare 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 tenant, potresti voler utilizzare il portachiavi AWS KMS gerarchico per ridurre al minimo le chiamate verso. AWS KMS Il keyring AWS KMS gerarchico è una soluzione di caching dei materiali crittografici che riduce il numero di AWS KMS chiamate utilizzando chiavi di filiale AWS KMS protette conservate in una tabella Amazon DynamoDB e quindi memorizzando localmente nella cache i materiali delle chiavi di filiale utilizzati nelle operazioni di crittografia e decrittografia. È necessario utilizzare il portachiavi gerarchico per implementare la crittografia ricercabile nel database. AWS KMS Crittografia ricercabile
Creazione di beacon firmati
Il AWS Database Encryption SDK utilizza beacon standard e beacon composti per fornire soluzioni di crittografia ricercabili che consentono di ricercare i record crittografati senza decrittografare l'intero database interrogato. Tuttavia, AWS Database Encryption SDK supporta anche beacon firmati che possono essere configurati interamente da campi firmati in testo normale. I beacon firmati sono un tipo di beacon composto che indicizza ed esegue query complesse su e campi. SIGN_ONLY SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT
Ad esempio, se disponi di un database multitenant, potresti voler creare un beacon firmato che ti consenta di interrogare il database per i 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, fornisci i seguenti valori.
È 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 ciascuna parte una volta e quindi riutilizzarle in più configurazioni composte beacon. Se intendete utilizzare una parte firmata una sola volta, potete definirla in un elenco locale nella configurazione Signed beacon. È possibile fare riferimento a parti locali e globali nell'elenco dei costruttori.
Se si definiscono gli elenchi delle parti firmate a livello globale, è necessario fornire un elenco di parti del costruttore che identifichi tutti i modi possibili in cui il beacon firmato può assemblare i campi nella configurazione del beacon.
Nota
Per definire gli elenchi di parti firmate a livello globale, è necessario utilizzare la versione 3.2 o successiva del 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 beacon esistenti per definire elenchi di parti firmate a livello globale.
- Nome del beacon
-
Il nome che usi quando interroghi il beacon.
Il nome di un beacon firmato non può essere uguale a un campo non crittografato. Non possono esserci due beacon con lo stesso nome.
- Personaggio diviso
-
Il carattere usato per separare le parti che compongono il tuo faro autografato.
Il carattere diviso non può apparire nei valori in chiaro di nessuno dei campi da cui è stato creato 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_CONTEXTcampoSIGN_ONLYo 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 l'origine, è possibile ometterla e AWS Database Encryption SDK utilizzerà automaticamente il nome come origine. Consigliamo di specificare la fonte come nome della parte quando possibile. Il prefisso può essere qualsiasi stringa, ma deve essere univoco. Due parti firmate di 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 possibilità di definire una parte firmata localmente 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.
- 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 beacon firmato può essere assemblato. Le parti del costruttore vengono unite nell'ordine in cui vengono aggiunte all'elenco, con ciascuna parte separata dal carattere diviso specificato.
Ogni parte del costruttore nomina una parte firmata e definisce se tale parte è obbligatoria o opzionale all'interno del costruttore. Ad esempio, se desideri interrogare un beacon firmato su
Field1,, eField1.Field2Field1.Field2.Field3, contrassegna eField3come opzionaleField2e crea un costruttore.Ogni costruttore deve avere almeno una parte obbligatoria. Ti consigliamo di rendere obbligatoria la prima parte di ogni costruttore in modo da poter utilizzare l'
BEGINS_WITHoperatore nelle tue domande.Un costruttore ha successo se tutte le parti richieste 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 ha esito positivo. Se nessun costruttore ha esito positivo, 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 loro query siano corretti.
Utilizzate le seguenti procedure per specificare il vostro elenco di costruttori.
-
Create una parte costruttore per ogni parte firmata per definire se tale parte è obbligatoria o meno.
Il nome della parte del costruttore deve essere il nome del campo firmato.
L'esempio seguente dimostra come creare una parte del costruttore per un campo firmato.
-
Create un costruttore per ogni possibile modo in cui il beacon firmato può essere assemblato utilizzando le parti del costruttore create nel passaggio 1.
Ad esempio, se si desidera eseguire una query su
Field1.Field2.Field3andField4.Field2.Field3, è necessario creare due costruttori.Field1eField4possono essere entrambi obbligatori perché sono definiti in due costruttori separati. -
Create un elenco di costruttori che includa tutti i costruttori creati nel passaggio 2.
-
Specifica la
constructorListdata di creazione del beacon firmato.
-