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à. # Crittografia ricercabile **** | | | --- | | La nostra libreria di crittografia lato client è stata rinominata Database Encryption SDK. AWS Questa guida per sviluppatori fornisce ancora informazioni sul [DynamoDB Encryption Client](legacy-dynamodb-encryption-client.md). | La crittografia ricercabile consente di cercare record crittografati senza decrittografare l'intero database. Questa operazione viene eseguita utilizzando *i beacon*, che creano una mappa tra il valore di testo in chiaro scritto in un campo e il valore crittografato effettivamente memorizzato nel database. Il AWS Database Encryption SDK memorizza il beacon in un nuovo campo che aggiunge al record. A seconda del tipo di beacon utilizzato, è possibile eseguire ricerche con corrispondenza esatta o query complesse più personalizzate sui dati crittografati. **Nota** [La crittografia ricercabile nel AWS Database Encryption SDK è diversa dalla crittografia simmetrica ricercabile definita nella ricerca accademica, come la crittografia simmetrica ricercabile.](https://dl.acm.org/doi/10.1145/1180405.1180417) Un beacon è un tag HMAC (Hash-Based Message Authentication Code) troncato che crea una mappa tra il testo semplice e i valori crittografati di un campo. Quando scrivi un nuovo valore in un campo crittografato configurato per la crittografia ricercabile, AWS Database Encryption SDK calcola un HMAC sul valore di testo in chiaro. Questo output HMAC corrisponde uno a uno (1:1) per il valore in chiaro di quel campo. L'output HMAC viene troncato in modo che più valori di testo in chiaro distinti vengano mappati allo stesso tag HMAC troncato. Questi falsi positivi limitano la capacità di un utente non autorizzato di identificare informazioni distintive sul valore del testo in chiaro. Quando si esegue una query su un beacon, il AWS Database Encryption SDK filtra automaticamente questi falsi positivi e restituisce il risultato in testo non crittografato della query. Il numero medio di falsi positivi generati per ogni beacon è determinato dalla lunghezza del beacon rimanente dopo il troncamento. [Per informazioni sulla determinazione della lunghezza del beacon appropriata per l'implementazione, consulta Determinazione della lunghezza del beacon.](choosing-beacon-length.md) **Nota** La crittografia ricercabile è progettata per essere implementata in nuovi database non popolati. Qualsiasi beacon configurato in un database esistente mapperà solo i nuovi record caricati nel database, non è possibile per un beacon mappare i dati esistenti. **Argomenti** + [I beacon sono adatti al mio set di dati?](#are-beacons-right-for-me) + [Scenario di crittografia ricercabile](#beacon-overview-example) ## I beacon sono adatti al mio set di dati? L'uso dei beacon per eseguire query su dati crittografati riduce i costi prestazionali associati ai database crittografati lato client. Quando si utilizzano i beacon, esiste un compromesso intrinseco tra l'efficienza delle query e la quantità di informazioni rivelate sulla distribuzione dei dati. Il beacon non altera lo stato crittografato del campo. Quando si crittografa e si firma un campo con AWS Database Encryption SDK, il valore in chiaro del campo non viene mai esposto al database. Il database memorizza il valore crittografato e randomizzato del campo. I beacon vengono memorizzati insieme ai campi crittografati da cui vengono calcolati. Ciò significa che anche se un utente non autorizzato non è in grado di visualizzare i valori in chiaro di un campo crittografato, potrebbe essere in grado di eseguire analisi statistiche sui beacon per saperne di più sulla distribuzione del set di dati e, in casi estremi, identificare i valori di testo in chiaro a cui un beacon è mappato. Il modo in cui configuri i beacon può mitigare questi rischi. In particolare, [la scelta della giusta lunghezza del beacon](choosing-beacon-length.md) può aiutarti a preservare la riservatezza del tuo set di dati. **Sicurezza vs. prestazioni** + Più breve è la lunghezza del faro, maggiore è la sicurezza. + Maggiore è la lunghezza del faro, maggiori sono le prestazioni preservate. La crittografia ricercabile potrebbe non essere in grado di fornire i livelli desiderati di prestazioni e sicurezza per tutti i set di dati. Esamina il modello di minaccia, i requisiti di sicurezza e le esigenze prestazionali prima di configurare qualsiasi beacon. Prendi in considerazione i seguenti requisiti di unicità del set di dati per determinare se la crittografia ricercabile è adatta al tuo set di dati. **Distribuzione** La quantità di sicurezza garantita da un beacon dipende dalla distribuzione del set di dati. Quando configuri un campo crittografato per una crittografia ricercabile, AWS Database Encryption SDK calcola un HMAC sui valori di testo in chiaro scritti in quel campo. Tutti i beacon calcolati per un determinato campo vengono calcolati utilizzando la stessa chiave, ad eccezione dei database multitenant che utilizzano una chiave distinta per ogni tenant. Ciò significa che se lo stesso valore di testo in chiaro viene scritto più volte nel campo, viene creato lo stesso tag HMAC per ogni istanza di quel valore di testo in chiaro. Dovresti evitare di creare beacon a partire da campi che contengono valori molto comuni. Ad esempio, si consideri un database che memorizza l'indirizzo di tutti i residenti dello stato dell'Illinois. Se costruisci un faro utilizzando il `City` campo criptato, il beacon calcolato su «Chicago» sarà sovrarappresentato a causa della grande percentuale della popolazione dell'Illinois che vive a Chicago. Anche se un utente non autorizzato può leggere solo i valori crittografati e i valori del beacon, potrebbe essere in grado di identificare quali record contengono dati relativi ai residenti di Chicago se il beacon mantiene questa distribuzione. Per ridurre al minimo la quantità di informazioni distintive rivelate sulla distribuzione, è necessario troncare sufficientemente il beacon. La lunghezza del beacon necessaria per nascondere questa distribuzione irregolare comporta costi prestazionali significativi che potrebbero non soddisfare le esigenze dell'applicazione. È necessario analizzare attentamente la distribuzione del set di dati per determinare in che misura i beacon devono essere troncati. La lunghezza del beacon rimanente dopo il troncamento è direttamente correlata alla quantità di informazioni statistiche che è possibile identificare sulla distribuzione. Potrebbe essere necessario scegliere beacon di lunghezza inferiore per ridurre al minimo la quantità di informazioni distintive rivelate sul set di dati. In casi estremi, non è possibile calcolare la lunghezza del beacon per un set di dati distribuito in modo non uniforme che bilanci efficacemente prestazioni e sicurezza. Ad esempio, non si dovrebbe costruire un faro partendo da un campo che memorizza il risultato di un test medico per una malattia rara. Poiché si prevede che `NEGATIVE` i risultati siano significativamente più diffusi all'interno del set di dati, i `POSITIVE` risultati possono essere facilmente identificati in base alla loro rarità. È molto difficile nascondere la distribuzione quando il campo ha solo due valori possibili. Se si utilizza una lunghezza del beacon sufficientemente breve da nascondere la distribuzione, tutti i valori in testo semplice vengono mappati allo stesso tag HMAC. Se si utilizza un beacon di lunghezza maggiore, è ovvio quali beacon vengono mappati su valori in chiaro. `POSITIVE` **Correlazione** Si consiglia vivamente di evitare di creare beacon distinti a partire da campi con valori correlati. I beacon creati da campi correlati richiedono beacon di lunghezza inferiore per ridurre al minimo in misura sufficiente la quantità di informazioni rivelate sulla distribuzione di ciascun set di dati a un utente non autorizzato. È necessario analizzare attentamente il set di dati, compresa l'entropia e la distribuzione congiunta dei valori correlati, per determinare in che misura i beacon devono essere troncati. Se la lunghezza del beacon risultante non soddisfa le esigenze prestazionali, i beacon potrebbero non essere adatti al set di dati. Ad esempio, non dovreste creare due beacon `City` e due `ZIPCode` campi separati perché il codice postale sarà probabilmente associato a una sola città. In genere, i falsi positivi generati da un beacon limitano la capacità di un utente non autorizzato di identificare le informazioni distintive sul set di dati. Tuttavia, la correlazione tra i `ZIPCode` campi `City` e significa che un utente non autorizzato può identificare facilmente quali risultati sono falsi positivi e distinguere i diversi codici postali. È inoltre consigliabile evitare di creare beacon a partire da campi che contengono gli stessi valori in chiaro. Ad esempio, non dovreste costruire un beacon partendo da `preferredPhone` campi `mobilePhone` e perché probabilmente contengono gli stessi valori. Se costruisci beacon distinti da entrambi i campi, AWS Database Encryption SDK crea i beacon per ogni campo con chiavi diverse. Ciò si traduce in due tag HMAC diversi per lo stesso valore di testo in chiaro. È improbabile che i due beacon distinti abbiano gli stessi falsi positivi e un utente non autorizzato potrebbe essere in grado di distinguere numeri di telefono diversi. Anche se il set di dati contiene campi correlati o ha una distribuzione non uniforme, è possibile creare beacon che preservino la riservatezza del set di dati utilizzando beacon di lunghezza inferiore. Tuttavia, la lunghezza del beacon non garantisce che ogni valore univoco nel set di dati produca una serie di falsi positivi che riducono efficacemente al minimo la quantità di informazioni distintive rivelate sul set di dati. La lunghezza del beacon stima solo il numero medio di falsi positivi prodotti. Più il set di dati è distribuito in modo non uniforme, minore è la lunghezza del faro nel determinare il numero medio di falsi positivi prodotti. Valuta attentamente la distribuzione dei campi da cui costruisci i beacon e valuta quanto ti servirà per troncare la lunghezza del beacon per soddisfare i tuoi requisiti di sicurezza. Gli argomenti seguenti di questo capitolo presuppongono che i beacon siano distribuiti uniformemente e non contengano dati correlati. ## Scenario di crittografia ricercabile L'esempio seguente illustra una semplice soluzione di crittografia ricercabile. In applicazione, i campi di esempio utilizzati in questo esempio potrebbero non soddisfare le raccomandazioni sull'unicità di distribuzione e correlazione per i beacon. Puoi usare questo esempio come riferimento mentre leggi i concetti di crittografia ricercabile in questo capitolo. Prendiamo in considerazione un database denominato `Employees` che tiene traccia dei dati dei dipendenti di un'azienda. *Ogni record del database contiene campi denominati *EmployeeID *LastName*FirstName***, e Address.* Ogni campo del `Employees` database è identificato dalla chiave primaria. `EmployeeID` Di seguito è riportato un esempio di record di testo in chiaro nel database. ``` { "EmployeeID": 101, "LastName": "Jones", "FirstName": "Mary", "Address": { "Street": "123 Main", "City": "Anytown", "State": "OH", "ZIPCode": 12345 } } ``` Se hai contrassegnato i `FirstName` campi `LastName` and come `ENCRYPT_AND_SIGN` nelle tue [azioni crittografiche](concepts.md#crypt-actions), i valori in questi campi vengono crittografati localmente prima di essere caricati nel database. I dati crittografati caricati sono completamente randomizzati, il database non riconosce questi dati come protetti. Rileva solo le immissioni di dati tipiche. Ciò significa che il record effettivamente archiviato nel database potrebbe avere il seguente aspetto. ``` { "PersonID": 101, "LastName": "1d76e94a2063578637d51371b363c9682bad926cbd", "FirstName": "21d6d54b0aaabc411e9f9b34b6d53aa4ef3b0a35", "Address": { "Street": "123 Main", "City": "Anytown", "State": "OH", "ZIPCode": 12345 } } ``` Se devi interrogare il database per verificare le corrispondenze esatte sul `LastName` campo, [configura un beacon standard](configure-beacons.md#config-standard-beacons) denominato *LastName*per mappare i valori in chiaro scritti nel `LastName` campo ai valori crittografati memorizzati nel database. Questo beacon esegue il calcolo in base ai valori in chiaro presenti nel HMACs campo. `LastName` Ogni output HMAC viene troncato in modo che non corrisponda più esattamente al valore del testo in chiaro. Ad esempio, l'hash completo e l'hash troncato per potrebbero essere simili ai seguenti. `Jones` **Hash completo** `2aa4e9b404c68182562b6ec761fcca5306de527826a69468885e59dc36d0c3f824bdd44cab45526f70a2a18322000264f5451acf75f9f817e2b35099d408c833` **Hash troncato** `b35099d408c833` Dopo aver configurato il beacon standard, è possibile eseguire ricerche di uguaglianza sul campo. `LastName` Ad esempio, se desideri cercare`Jones`, usa il *LastName*beacon per eseguire la seguente query. ``` LastName = Jones ``` AWS Database Encryption SDK filtra automaticamente i falsi positivi e restituisce il risultato in testo non crittografato della query. # Fari **** | | | --- | | La nostra libreria di crittografia lato client è stata rinominata Database Encryption SDK. AWS Questa guida per sviluppatori fornisce ancora informazioni sul [DynamoDB Encryption Client](legacy-dynamodb-encryption-client.md). | Un beacon è un tag HMAC (Hash-Based Message Authentication Code) troncato che crea una mappa tra il valore in chiaro scritto in un campo e il valore crittografato effettivamente memorizzato nel database. Il beacon non altera lo stato crittografato del campo. Il beacon calcola un HMAC sul valore di testo in chiaro del campo e lo memorizza insieme al valore crittografato. Questo output HMAC corrisponde uno a uno (1:1) per il valore in chiaro di quel campo. L'output HMAC viene troncato in modo che più valori di testo in chiaro distinti vengano mappati allo stesso tag HMAC troncato. Questi falsi positivi limitano la capacità di un utente non autorizzato di identificare informazioni distintive sul valore del testo in chiaro. [I beacon possono essere creati solo a partire da campi contrassegnati o nelle azioni `ENCRYPT_AND_SIGN` crittografiche`SIGN_ONLY`. `SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT`](concepts.md#crypt-actions) Il beacon stesso non è firmato o crittografato. Non è possibile costruire un beacon con campi contrassegnati. `DO_NOTHING` Il tipo di beacon configurato determina il tipo di interrogazioni che è possibile eseguire. Esistono due tipi di beacon che supportano la crittografia ricercabile. *I beacon standard eseguono* ricerche di uguaglianza. *I beacon composti* combinano stringhe letterali in chiaro e beacon standard per eseguire operazioni complesse sul database. Dopo aver [configurato i beacon, è necessario configurare un indice secondario per ogni beacon](configure-beacons.md) prima di poter eseguire la ricerca nei campi crittografati. Per ulteriori informazioni, consulta [Configurazione degli indici secondari con beacon](ddb-searchable-encryption.md#ddb-beacon-indexes). **Topics** + [Beacon standard](#standard-beacon-overview) + [Beacon composti](#compound-beacon-overview) ## Beacon standard I beacon standard sono il modo più semplice per implementare la crittografia ricercabile nel database. Possono eseguire ricerche di uguaglianza solo per un singolo campo crittografato o virtuale. Per informazioni su come configurare i beacon standard, vedere [Configurazione](configure-beacons.md#config-standard-beacons) dei beacon standard. *Il campo da cui è costruito un beacon standard è chiamato beacon source.* Identifica la posizione dei dati che il beacon deve mappare. *La fonte del beacon può essere un campo crittografato o un campo virtuale.* La fonte del beacon in ogni beacon standard deve essere unica. Non è possibile configurare due beacon con la stessa sorgente beacon. I beacon standard possono essere utilizzati per eseguire ricerche di uguaglianza per un campo crittografato o virtuale. In alternativa, possono essere utilizzati per costruire beacon composti per eseguire operazioni di database più complesse. Per aiutarvi a organizzare e gestire i beacon standard, il AWS Database Encryption SDK fornisce i seguenti *stili di beacon opzionali che definiscono l'uso previsto di un beacon* standard. [Per ulteriori informazioni, consulta Definizione degli stili di beacon.](configure-beacons.md#define-beacon-styles) È possibile creare un beacon standard che esegue ricerche di uguaglianza per un singolo campo crittografato oppure creare un beacon standard che esegue ricerche di uguaglianza sulla concatenazione di più campi e creando un campo virtuale. `ENCRYPT_AND_SIGN` `SIGN_ONLY` `SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT` **Campi virtuali** Un campo virtuale è un campo concettuale costruito da uno o più campi di origine. La creazione di un campo virtuale non comporta la scrittura di un nuovo campo nel record. Il campo virtuale non è archiviato in modo esplicito nel database. Viene utilizzato nella configurazione standard del beacon per fornire al beacon istruzioni su come identificare un segmento specifico di un campo o concatenare più campi all'interno di un record per eseguire una query specifica. Un campo virtuale richiede almeno un campo crittografato. L'esempio seguente illustra i tipi di trasformazioni e interrogazioni che è possibile eseguire con un campo virtuale. In applicazione, i campi di esempio utilizzati in questo esempio potrebbero non soddisfare le raccomandazioni sull'unicità della [distribuzione](searchable-encryption.md#searchable-encryption-distribution) e della [correlazione](searchable-encryption.md#searchable-encryption-correlated-values) per i beacon. Ad esempio, se si desidera eseguire ricerche di uguaglianza sulla concatenazione di `LastName` campi `FirstName` and, è possibile creare uno dei seguenti campi virtuali. + Un `NameTag` campo virtuale, composto dalla prima lettera del `FirstName` campo, seguito dal campo, tutto in `LastName` minuscolo. Questo campo virtuale consente di eseguire interrogazioni. `NameTag=mjones` + Un `LastFirst` campo virtuale, costruito a partire dal `LastName` campo, seguito dal `FirstName` campo. Questo campo virtuale consente di eseguire interrogazioni`LastFirst=JonesMary`. Oppure, se desideri eseguire ricerche di uguaglianza su un segmento specifico di un campo crittografato, crea un campo virtuale che identifichi il segmento su cui desideri eseguire la query. Ad esempio, se desideri interrogare un `IPAddress` campo crittografato utilizzando i primi tre segmenti dell'indirizzo IP, crea il seguente campo virtuale. + Un `IPSegment` campo virtuale, costruito da`Segments(‘.’, 0, 3)`. Questo campo virtuale consente di eseguire interrogazioni`IPSegment=192.0.2`. La query restituisce tutti i record con un `IPAddress` valore che inizia con «192.0.2". I campi virtuali devono essere univoci. Non è possibile creare due campi virtuali a partire dagli stessi campi sorgente. Per informazioni sulla configurazione dei campi virtuali e dei beacon che li utilizzano, consulta [Creazione di un](configure-beacons.md#create-virtual-field) campo virtuale. ## Beacon composti I beacon composti creano indici che migliorano le prestazioni delle query e consentono di eseguire operazioni di database più complesse. È possibile utilizzare i beacon composti per combinare stringhe di testo in chiaro letterali e beacon standard per eseguire query complesse su record crittografati, ad esempio interrogare due diversi tipi di record da un singolo indice o interrogare una combinazione di campi con una chiave di ordinamento. [Per altri esempi di soluzioni beacon composte, consulta Scegliere un tipo di beacon.](choosing-beacon-type.md) I beacon composti possono essere costruiti a partire da beacon standard o da una combinazione di beacon standard e campi firmati. Sono costituiti da un elenco di parti. Tutti i beacon composti devono includere un elenco di [parti crittografate](configure-beacons.md#encrypted-parts) che identifichi i `ENCRYPT_AND_SIGN` campi inclusi nel beacon. Ogni `ENCRYPT_AND_SIGN` campo deve essere identificato da un beacon standard. I beacon composti più complessi potrebbero includere anche un elenco di [parti firmate](configure-beacons.md#signed-parts) che identificano il testo in chiaro `SIGN_ONLY` o i `SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT` campi inclusi nel beacon e un elenco di [parti del costruttore](configure-beacons.md#constructor-parts) che identificano tutti i possibili modi in cui il beacon composto può assemblare i campi. **Nota** *Il AWS Database Encryption SDK supporta anche beacon firmati che possono essere configurati interamente da testo in chiaro e campi.* `SIGN_ONLY` `SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT` I beacon firmati sono un tipo di beacon composto che indicizza ed esegue query complesse su campi firmati, ma non crittografati. Per ulteriori informazioni, consulta [Creazione di beacon firmati](configure.md#signed-beacons). [Per informazioni sulla configurazione dei beacon composti, consultate Configurazione dei beacon composti.](configure-beacons.md#config-compound-beacons) Il modo in cui configuri il beacon composto determina i tipi di query che può eseguire. Ad esempio, è possibile rendere opzionali alcune parti crittografate e firmate per consentire una maggiore flessibilità nelle query. Per ulteriori informazioni sui tipi di interrogazioni che i beacon composti possono eseguire, vedere. [Interrogazione dei beacon](using-beacons.md#querying-beacons) # Fari di pianificazione **** | | | --- | | La nostra libreria di crittografia lato client è stata rinominata Database Encryption SDK. AWS Questa guida per sviluppatori fornisce ancora informazioni sul [DynamoDB Encryption Client](legacy-dynamodb-encryption-client.md). | I beacon sono progettati per essere implementati in nuovi database non popolati. Qualsiasi beacon configurato in un database esistente mapperà solo i nuovi record scritti nel database. I beacon vengono calcolati in base al valore in chiaro di un campo, una volta crittografato il campo non è più possibile per il beacon di mappare i dati esistenti. Dopo aver scritto nuovi record con un beacon, non è possibile aggiornare la configurazione del beacon. Tuttavia, puoi aggiungere nuovi beacon per i nuovi campi che aggiungi al tuo record. Per implementare la crittografia ricercabile, è necessario utilizzare il [portachiavi AWS KMS gerarchico](use-hierarchical-keyring.md) per generare, crittografare e decrittografare le chiavi dati utilizzate per proteggere i record. Per ulteriori informazioni, consulta [Utilizzo del portachiavi gerarchico per una crittografia ricercabile](use-hierarchical-keyring.md#searchable-encryption-hierarchical-keyrings). Prima di poter configurare [i beacon](searchable-encryption.md#beacon-definition) per la crittografia ricercabile, è necessario esaminare i requisiti di crittografia, i modelli di accesso al database e il modello di minaccia per determinare la soluzione migliore per il database. Il [tipo di beacon](beacons.md) configurato determina il tipo di query che è possibile eseguire. La [lunghezza del beacon](choosing-beacon-length.md) specificata nella configurazione standard del beacon determina il numero previsto di falsi positivi prodotti per un determinato beacon. Consigliamo vivamente di identificare e pianificare i tipi di interrogazioni da eseguire prima di configurare i beacon. Dopo aver utilizzato un beacon, la configurazione non può essere aggiornata. Si consiglia vivamente di esaminare e completare le seguenti attività prima di configurare qualsiasi beacon. + [Determina se i beacon sono adatti al tuo set di dati](searchable-encryption.md#are-beacons-right-for-me) + [Scegli un tipo di faro](choosing-beacon-type.md) + [Scegli la lunghezza del faro](choosing-beacon-length.md) + [Scegli il nome del faro](choosing-beacon-name.md) Ricorda i seguenti requisiti di unicità dei beacon quando pianifichi la soluzione di crittografia ricercabile per il tuo database. + **[Ogni beacon standard deve avere una fonte di beacon unica](beacons.md#beacon-source)** Non è possibile creare più beacon standard a partire dallo stesso campo criptato o virtuale. Tuttavia, è possibile utilizzare un singolo beacon standard per costruire più beacon composti. + **Evitate di creare un campo virtuale con campi sorgente che si sovrappongono ai beacon standard esistenti** La creazione di un beacon standard a partire da un campo virtuale che contiene un campo sorgente utilizzato per creare un altro beacon standard può ridurre la sicurezza di entrambi i beacon. Per ulteriori informazioni, consulta [Considerazioni sulla sicurezza per i campi virtuali](configure-beacons.md#virtual-field-considerations). ## Considerazioni per i database multitenant Per interrogare i beacon configurati in un database multitenant, è necessario includere nella query il campo che memorizza il record `branch-key-id` associato al tenant che ha crittografato il record. [Questo campo viene definito quando si definisce la fonte della chiave beacon.](use-hierarchical-keyring.md#beacon-key-source) Affinché la query abbia esito positivo, il valore in questo campo deve identificare i materiali chiave del beacon appropriati necessari per ricalcolare il beacon. Prima di configurare i beacon, è necessario decidere in che modo intendi includerli nelle query. `branch-key-id` Per ulteriori informazioni sui diversi modi in cui puoi includerli `branch-key-id` nelle tue query, consulta. [Interrogazione dei beacon in un database multi-tenant](searchable-encryption-multitenant.md#query-multitenant-beacons) # Scelta del tipo di faro **** | | | --- | | La nostra libreria di crittografia lato client è stata rinominata Database Encryption SDK. AWS Questa guida per sviluppatori fornisce ancora informazioni sul [DynamoDB Encryption Client](legacy-dynamodb-encryption-client.md). | *Con la crittografia ricercabile, puoi cercare record crittografati mappando i valori in chiaro in un campo crittografato con un beacon.* Il tipo di beacon configurato determina il tipo di interrogazioni che è possibile eseguire. Consigliamo vivamente di identificare e pianificare i tipi di query da eseguire prima di configurare i beacon. Dopo aver [configurato i beacon](configure-beacons.md), è necessario configurare un indice secondario per ogni beacon prima di poter eseguire la ricerca nei campi crittografati. Per ulteriori informazioni, consulta [Configurazione degli indici secondari con beacon](ddb-searchable-encryption.md#ddb-beacon-indexes). I beacon creano una mappa tra il valore in chiaro scritto in un campo e il valore crittografato effettivamente memorizzato nel database. Non è possibile confrontare i valori di due beacon standard, anche se contengono lo stesso testo in chiaro sottostante. I due beacon standard produrranno due tag HMAC diversi per gli stessi valori di testo in chiaro. Di conseguenza, i beacon standard non possono eseguire le seguenti interrogazioni. + `beacon1 = beacon2` + `beacon1 IN (beacon2)` + `value IN (beacon1, beacon2, ...)` + `CONTAINS(beacon1, beacon2)` È possibile eseguire le query precedenti solo se si confrontano le [parti firmate](configure-beacons.md#signed-parts) dei beacon composti, ad eccezione dell'`CONTAINS`operatore, che è possibile utilizzare con i beacon composti per identificare l'intero valore di un campo crittografato o firmato contenuto nel beacon assemblato. Quando si confrontano parti firmate, è possibile includere facoltativamente il prefisso di una [parte crittografata, ma non il valore crittografato](configure-beacons.md#encrypted-parts) di un campo. [Per ulteriori informazioni sui tipi di interrogazioni che i beacon standard e composti possono eseguire, vedete Interrogazione dei beacon.](using-beacons.md#querying-beacons) Prendi in considerazione le seguenti soluzioni di crittografia ricercabili quando esamini i modelli di accesso al database. Gli esempi seguenti definiscono quale beacon configurare per soddisfare diversi requisiti di crittografia e interrogazione. ## Beacon standard [I beacon standard possono eseguire](beacons.md#standard-beacon-overview) solo ricerche di uguaglianza. È possibile utilizzare i beacon standard per eseguire le seguenti interrogazioni. ### Interroga un singolo campo crittografato Se desideri identificare i record che contengono un valore specifico per un campo crittografato, crea un beacon standard. #### Esempi Per l'esempio seguente, si consideri un database denominato `UnitInspection` che tiene traccia dei dati di ispezione per un impianto di produzione. Ogni record del database contiene campi denominati `work_id``inspection_date`,`inspector_id_last4`, e`unit`. L'ID ispettore completo è un numero compreso tra 0 e 99.999.999. Tuttavia, per garantire che il set di dati sia distribuito uniformemente, memorizza `inspector_id_last4` solo le ultime quattro cifre dell'ID dell'ispettore. Ogni campo del database è identificato dalla chiave primaria. `work_id` I `unit` campi `inspector_id_last4` e sono contrassegnati `ENCRYPT_AND_SIGN` nelle [azioni crittografiche](concepts.md#crypt-actions). Di seguito è riportato un esempio di voce in chiaro nel database. `UnitInspection` ``` { "work_id": "1c7fcff3-6e74-41a8-b7f7-925dc039830b", "inspection_date": 2023-06-07, "inspector_id_last4": 8744, "unit": 229304973450 } ``` **Interroga un singolo campo crittografato in un record** Se il `inspector_id_last4` campo deve essere crittografato, ma è comunque necessario interrogarlo per verificare le corrispondenze esatte, costruisci un beacon standard a partire dal campo. `inspector_id_last4` Quindi, utilizzate il beacon standard per creare un indice secondario. È possibile utilizzare questo indice secondario per eseguire query sul campo `inspector_id_last4` crittografato. Per informazioni sulla configurazione dei beacon standard, vedere [Configurazione](configure-beacons.md#config-standard-beacons) dei beacon standard. ### Interroga un campo virtuale Un [campo virtuale](beacons.md#virtual-field) è un campo concettuale costruito da uno o più campi di origine. Se desideri eseguire ricerche di uguaglianza per un segmento specifico di un campo crittografato o eseguire ricerche di uguaglianza sulla concatenazione di più campi, costruisci un beacon standard da un campo virtuale. Tutti i campi virtuali devono includere almeno un campo sorgente crittografato. #### Esempi Gli esempi seguenti creano campi virtuali per il `Employees` database. Di seguito è riportato un esempio di record di testo in chiaro nel `Employees` database. ``` { "EmployeeID": 101, "SSN": 000-00-0000, "LastName": "Jones", "FirstName": "Mary", "Address": { "Street": "123 Main", "City": "Anytown", "State": "OH", "ZIPCode": 12345 } } ``` **Interroga un segmento di un campo crittografato** Per questo esempio, il `SSN` campo è crittografato. Se desideri interrogare il `SSN` campo utilizzando le ultime quattro cifre di un numero di previdenza sociale, crea un campo virtuale che identifichi il segmento che intendi interrogare. Un `Last4SSN` campo virtuale, costruito da, `Suffix(4)` consente di eseguire interrogazioni. `Last4SSN=0000` Usa questo campo virtuale per costruire un beacon standard. Quindi, usa il beacon standard per creare un indice secondario. È possibile utilizzare questo indice secondario per eseguire interrogazioni sul campo virtuale. Questa query restituisce tutti i record con un `SSN` valore che termina con le ultime quattro cifre specificate. **Interroga la concatenazione di più campi** L'esempio seguente illustra i tipi di trasformazioni e interrogazioni che è possibile eseguire con un campo virtuale. In applicazione, i campi di esempio utilizzati in questo esempio potrebbero non soddisfare le raccomandazioni sull'unicità della [distribuzione](searchable-encryption.md#searchable-encryption-distribution) e della [correlazione](searchable-encryption.md#searchable-encryption-correlated-values) per i beacon. Se desideri eseguire ricerche di uguaglianza su una concatenazione di `LastName` campi `FirstName` and, puoi creare un `NameTag` campo virtuale, composto dalla prima lettera del campo, seguito dal `FirstName` campo, tutto in minuscolo. `LastName` Usa questo campo virtuale per costruire un beacon standard. Quindi, usa il beacon standard per creare un indice secondario. È possibile utilizzare questo indice secondario per eseguire interrogazioni `NameTag=mjones` sul campo virtuale. Almeno uno dei campi di origine deve essere crittografato. `FirstName`O `LastName` potrebbero essere crittografati oppure potrebbero essere crittografati entrambi. Tutti i campi sorgente in testo semplice devono essere contrassegnati come `SIGN_ONLY` o `SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT` nelle azioni [crittografiche](concepts.md#crypt-actions). [Per informazioni sulla configurazione dei campi virtuali e dei beacon che li utilizzano, consulta Creazione di un campo virtuale.](configure-beacons.md#create-virtual-field) ## Beacon composti [I beacon composti](beacons.md#compound-beacon-overview) creano un indice a partire da stringhe letterali in chiaro e beacon standard per eseguire operazioni complesse sul database. È possibile utilizzare i beacon composti per eseguire le seguenti interrogazioni. ### Interroga una combinazione di campi crittografati su un singolo indice Se devi interrogare una combinazione di campi crittografati su un singolo indice, crea un beacon composto che combini i singoli beacon standard costruiti per ogni campo crittografato per formare un unico indice. Dopo aver configurato il beacon composto, è possibile creare un indice secondario che lo specifichi come chiave di partizione per eseguire query con corrispondenza esatta o con una chiave di ordinamento per eseguire query più complesse. Gli indici secondari che specificano il beacon composto come chiave di ordinamento possono eseguire query di corrispondenza esatta e query complesse più personalizzate. #### Esempi Per gli esempi seguenti, prendete in considerazione un database denominato `UnitInspection` che tiene traccia dei dati di ispezione per un impianto di produzione. Ogni record del database contiene campi denominati `work_id``inspection_date`,`inspector_id_last4`, e`unit`. L'ID ispettore completo è un numero compreso tra 0 e 99.999.999. Tuttavia, per garantire che il set di dati sia distribuito uniformemente, memorizza `inspector_id_last4` solo le ultime quattro cifre dell'ID dell'ispettore. Ogni campo del database è identificato dalla chiave primaria. `work_id` I `unit` campi `inspector_id_last4` e sono contrassegnati `ENCRYPT_AND_SIGN` nelle [azioni crittografiche](concepts.md#crypt-actions). Di seguito è riportato un esempio di voce in chiaro nel database. `UnitInspection` ``` { "work_id": "1c7fcff3-6e74-41a8-b7f7-925dc039830b", "inspection_date": 2023-06-07, "inspector_id_last4": 8744, "unit": 229304973450 } ``` **Esegue ricerche di uguaglianza su una combinazione di campi crittografati** Se desideri interrogare il `UnitInspection` database per verificare le corrispondenze esatte`inspector_id_last4.unit`, crea innanzitutto beacon standard distinti per i `inspector_id_last4` campi and. `unit` Quindi, create un faro composto dai due beacon standard. Dopo aver configurato il beacon composto, create un indice secondario che specifichi il beacon composto come chiave di partizione. Utilizzate questo indice secondario per ricercare le corrispondenze esatte su. `inspector_id_last4.unit` Ad esempio, è possibile interrogare questo faro per trovare un elenco di ispezioni eseguite da un ispettore per una determinata unità. **Esegui interrogazioni complesse su una combinazione di campi crittografati** Se desideri interrogare il `UnitInspection` database su `inspector_id_last4` and`inspector_id_last4.unit`, crea innanzitutto beacon standard distinti per i `inspector_id_last4` campi and. `unit` Quindi, create un beacon composto dai due beacon standard. Dopo aver configurato il beacon composto, create un indice secondario che specifichi il beacon composto come chiave di ordinamento. Utilizzate questo indice secondario per interrogare il `UnitInspection` database alla ricerca di voci che iniziano con un determinato ispettore o interrogare il database per ottenere un elenco di tutte le unità all'interno di uno specifico intervallo di ID di unità che sono state ispezionate da un determinato ispettore. Puoi anche eseguire ricerche con corrispondenze esatte su. `inspector_id_last4.unit` [Per informazioni sulla configurazione dei beacon composti, consulta Configurazione dei beacon composti.](configure-beacons.md#config-compound-beacons) ### Interroga una combinazione di campi crittografati e di testo semplice su un singolo indice Se devi interrogare una combinazione di campi crittografati e di testo in chiaro su un singolo indice, crea un beacon composto che combini singoli beacon standard e campi di testo in chiaro per formare un unico indice. [I campi di testo in chiaro utilizzati per costruire il beacon composto devono essere contrassegnati o nelle azioni crittografiche. `SIGN_ONLY``SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT`](concepts.md#crypt-actions) Dopo aver configurato il beacon composto, è possibile creare un indice secondario che specifichi il beacon composto come chiave di partizione per eseguire query con corrispondenza esatta o con una chiave di ordinamento per eseguire query più complesse. Gli indici secondari che specificano il beacon composto come chiave di ordinamento possono eseguire query di corrispondenza esatta e query complesse più personalizzate. #### Esempi Per gli esempi seguenti, prendete in considerazione un database denominato `UnitInspection` che tiene traccia dei dati di ispezione per un impianto di produzione. Ogni record del database contiene campi denominati `work_id``inspection_date`,`inspector_id_last4`, e`unit`. L'ID ispettore completo è un numero compreso tra 0 e 99.999.999. Tuttavia, per garantire che il set di dati sia distribuito uniformemente, memorizza `inspector_id_last4` solo le ultime quattro cifre dell'ID dell'ispettore. Ogni campo del database è identificato dalla chiave primaria. `work_id` I `unit` campi `inspector_id_last4` e sono contrassegnati `ENCRYPT_AND_SIGN` nelle [azioni crittografiche](concepts.md#crypt-actions). Di seguito è riportato un esempio di voce in chiaro nel database. `UnitInspection` ``` { "work_id": "1c7fcff3-6e74-41a8-b7f7-925dc039830b", "inspection_date": 2023-06-07, "inspector_id_last4": 8744, "unit": 229304973450 } ``` **Esegue ricerche di uguaglianza su una combinazione di campi** Se desideri interrogare il `UnitInspection` database per verificare le ispezioni condotte da un ispettore specifico in una data specifica, crea innanzitutto un beacon standard per il campo. `inspector_id_last4` [Il `inspector_id_last4` campo è contrassegnato `ENCRYPT_AND_SIGN` nelle azioni crittografiche.](concepts.md#crypt-actions) Tutte le parti crittografate richiedono un proprio beacon standard. Il `inspection_date` campo è contrassegnato `SIGN_ONLY` e non richiede un beacon standard. Quindi, create un faro composto dal `inspection_date` campo e dal faro standard. `inspector_id_last4` Dopo aver configurato il beacon composto, create un indice secondario che specifichi il beacon composto come chiave di partizione. Utilizzate questo indice secondario per interrogare i database alla ricerca di record con corrispondenze esatte con una determinata data di ispezione e ispezione. Ad esempio, è possibile interrogare il database per ottenere un elenco di tutte le ispezioni `8744` condotte dall'ispettore il cui ID termina in una data specifica. **Esegui interrogazioni complesse su una combinazione di campi** Se desideri interrogare il database per le ispezioni condotte all'interno di un `inspection_date` intervallo o interrogare il database per le ispezioni `inspection_date` condotte su un particolare vincolo `inspector_id_last4` o`inspector_id_last4.unit`, crea prima beacon standard distinti per i campi and. `inspector_id_last4` `unit` Quindi, create un beacon composto dal campo di testo in chiaro e dai due beacon standard. `inspection_date` Dopo aver configurato il beacon composto, create un indice secondario che specifichi il beacon composto come chiave di ordinamento. Utilizzate questo indice secondario per eseguire interrogazioni relative alle ispezioni condotte in date specifiche da un ispettore specifico. Ad esempio, è possibile interrogare il database per ottenere un elenco di tutte le unità ispezionate nella stessa data. In alternativa, è possibile interrogare il database per ottenere un elenco di tutte le ispezioni eseguite su un'unità specifica tra un determinato intervallo di date di ispezione. [Per informazioni sulla configurazione dei beacon composti, consulta Configurazione dei beacon composti.](configure-beacons.md#config-compound-beacons) # Scelta della lunghezza del faro **** | | | --- | | La nostra libreria di crittografia lato client è stata rinominata Database Encryption SDK. AWS Questa guida per sviluppatori fornisce ancora informazioni sul [DynamoDB Encryption Client](legacy-dynamodb-encryption-client.md). | Quando scrivi un nuovo valore in un campo crittografato configurato per la crittografia ricercabile, AWS Database Encryption SDK calcola un HMAC sul valore di testo in chiaro. Questo output HMAC corrisponde uno a uno (1:1) per il valore in chiaro di quel campo. L'output HMAC viene troncato in modo che più valori di testo in chiaro distinti vengano mappati allo stesso tag HMAC troncato. Queste collisioni, o *falsi positivi, limitano la capacità di un utente non autorizzato di identificare informazioni distintive sul* valore del testo in chiaro. Il numero medio di falsi positivi generati per ogni beacon è determinato dalla lunghezza del beacon rimanente dopo il troncamento. È necessario definire la lunghezza del beacon solo quando si configurano i beacon standard. I beacon composti utilizzano le lunghezze dei beacon standard da cui sono costruiti. Il beacon non altera lo stato crittografato del campo. Tuttavia, quando si utilizzano i beacon, esiste un compromesso intrinseco tra l'efficienza delle query e la quantità di informazioni rivelate sulla distribuzione dei dati. L'obiettivo della crittografia ricercabile è ridurre i costi prestazionali associati ai database crittografati lato client utilizzando i beacon per eseguire query su dati crittografati. I beacon vengono archiviati insieme ai campi crittografati da cui vengono calcolati. Ciò significa che possono rivelare informazioni distintive sulla distribuzione del set di dati. In casi estremi, un utente non autorizzato potrebbe essere in grado di analizzare le informazioni rivelate sulla distribuzione e utilizzarle per identificare il valore di testo in chiaro di un campo. La scelta della giusta lunghezza del beacon può aiutare a mitigare questi rischi e preservare la riservatezza della distribuzione. Esamina il tuo modello di minaccia per determinare il livello di sicurezza di cui hai bisogno. Ad esempio, maggiore è il numero di persone che hanno accesso al database, ma non dovrebbero avere accesso ai dati in chiaro, più potreste voler proteggere la riservatezza della distribuzione del set di dati. Per aumentare la riservatezza, un beacon deve generare più falsi positivi. Una maggiore riservatezza si traduce in una riduzione delle prestazioni delle query. **Sicurezza vs. prestazioni** + Una lunghezza del faro **troppo lunga** produce un numero insufficiente di falsi positivi e potrebbe rivelare informazioni distintive sulla distribuzione del set di dati. + Una lunghezza del beacon **troppo corta produce troppi** falsi positivi e aumenta il costo delle prestazioni delle query perché richiede una scansione più ampia del database. Nel determinare la lunghezza del beacon appropriata per la soluzione, è necessario trovare una lunghezza che preservi adeguatamente la sicurezza dei dati senza influire sulle prestazioni delle query più del necessario. Il livello di sicurezza garantito da un beacon dipende dalla [distribuzione](searchable-encryption.md#searchable-encryption-distribution) del set di dati e dalla [correlazione](searchable-encryption.md#searchable-encryption-correlated-values) dei campi da cui sono costruiti i beacon. Gli argomenti seguenti presuppongono che i beacon siano distribuiti uniformemente e non contengano dati correlati. **Topics** + [Calcolo della lunghezza del faro](#calculate-beacon-length) + [Esempio](#beacon-length-example) ## Calcolo della lunghezza del faro La lunghezza del beacon è definita in *bit e si riferisce al numero di bit* del tag HMAC che vengono conservati dopo il troncamento. La lunghezza del beacon consigliata varia in base alla distribuzione del set di dati, alla presenza di valori correlati e ai requisiti specifici di sicurezza e prestazioni. Se il set di dati è distribuito in modo uniforme, è possibile utilizzare le seguenti equazioni e procedure per identificare la lunghezza del beacon ottimale per l'implementazione. Queste equazioni stimano solo il numero medio di falsi positivi che il beacon produrrà, ma non garantiscono che ogni valore univoco del set di dati produca un numero specifico di falsi positivi. **Nota** L'efficacia di queste equazioni dipende dalla distribuzione del set di dati. Se il set di dati non è distribuito uniformemente, vedi. [I beacon sono adatti al mio set di dati?](searchable-encryption.md#are-beacons-right-for-me) In generale, più il set di dati è lontano da una distribuzione uniforme, più è necessario ridurre la lunghezza del beacon. 1. **Stima la popolazione** La popolazione è il numero previsto di valori univoci nel campo da cui è costruito il beacon standard, non è il numero totale previsto di valori memorizzati nel campo. Ad esempio, si consideri un `Room` campo crittografato che identifica la sede delle riunioni dei dipendenti. Il `Room` campo dovrebbe memorizzare 100.000 valori totali, ma ci sono solo 50 sale diverse che i dipendenti possono prenotare per le riunioni. Ciò significa che la popolazione è 50 perché nel `Room` campo possono essere memorizzati solo 50 valori univoci possibili. **Nota** Se il beacon standard è costruito a partire da un [campo virtuale](beacons.md#virtual-field), la popolazione utilizzata per calcolare la lunghezza del beacon è il numero di combinazioni uniche create dal campo virtuale. Quando stimate la popolazione, assicuratevi di considerare la crescita prevista del set di dati. Dopo aver scritto nuovi record con il beacon, non è possibile aggiornare la lunghezza del beacon. Esamina il tuo modello di minaccia e tutte le soluzioni di database esistenti per creare una stima del numero di valori univoci che ti aspetti che questo campo memorizzi nei prossimi cinque anni. Non è necessario che la tua popolazione sia precisa. Innanzitutto, identifica il numero di valori univoci nel tuo database corrente o stima il numero di valori univoci che prevedi di archiviare nel primo anno. Successivamente, utilizza le seguenti domande per determinare la crescita prevista di valori univoci nei prossimi cinque anni. + Prevedi che i valori univoci si moltiplichino per 10? + Ti aspetti che i valori univoci si moltiplichino per 100? + Ti aspetti che i valori univoci si moltiplichino per 1000? La differenza tra 50.000 e 60.000 valori univoci non è significativa ed entrambi daranno come risultato la stessa lunghezza del beacon consigliata. Tuttavia, la differenza tra 50.000 e 500.000 valori univoci influirà in modo significativo sulla lunghezza del beacon consigliata. Prendi in considerazione la possibilità di esaminare i dati pubblici sulla frequenza dei tipi di dati più comuni, come codici postali o cognomi. Ad esempio, ci sono 41.707 codici postali negli Stati Uniti d'America. La popolazione che utilizzi deve essere proporzionale al tuo database. Se il `ZIPCode` campo del database include dati provenienti da tutti gli Stati Uniti d'America, è possibile definire la popolazione come 41.707, anche se al momento `ZIPCode` il campo *non* ha 41.707 valori univoci. Se il `ZIPCode` campo del database include solo dati di un singolo stato e includerà sempre e solo i dati di un singolo stato, puoi definire la tua popolazione come il numero totale di codici postali in quello stato anziché 41.704. 1. **Calcola l'intervallo consigliato per il numero previsto di collisioni** Per determinare la lunghezza del faro appropriata per un determinato campo, è necessario innanzitutto identificare un intervallo appropriato per il numero previsto di collisioni. Il numero previsto di collisioni rappresenta il numero medio previsto di valori di testo in chiaro univoci mappati a un particolare tag HMAC. Il numero previsto di falsi positivi per un valore di testo in chiaro univoco è inferiore di uno rispetto al numero previsto di collisioni. È consigliabile che il numero previsto di collisioni sia maggiore o uguale a due e inferiore alla radice quadrata della popolazione. Le seguenti equazioni funzionano solo se la popolazione ha 16 o più valori univoci. ``` 2 ≤ number of collisions < √(Population) ``` Se il numero di collisioni è inferiore a due, il faro produrrà troppo pochi falsi positivi. Consigliamo due come numero minimo di collisioni previste perché significa che, in media, ogni valore univoco nel campo genererà almeno un falso positivo mappando un altro valore univoco. 1. **Calcola l'intervallo consigliato per le lunghezze dei beacon** Dopo aver identificato il numero minimo e massimo di collisioni previste, utilizzate la seguente equazione per identificare un intervallo di lunghezze di beacon appropriate. ``` number of collisions = Population * 2-(beacon length) ``` Innanzitutto, stabilite la **lunghezza del faro** in cui il numero di collisioni previste è uguale a due (il numero minimo consigliato di collisioni previste). ``` 2 = Population * 2-(beacon length) ``` Quindi, stabilite la **lunghezza del faro** in modo che il numero previsto di collisioni sia uguale alla radice quadrata della popolazione (il numero massimo consigliato di collisioni previste). ``` √(Population) = Population * 2-(beacon length) ``` Consigliamo di arrotondare l'output prodotto da questa equazione alla lunghezza del faro più corta. Ad esempio, se l'equazione produce una lunghezza del faro di 15,6, si consiglia di arrotondare tale valore per difetto a 15 bit anziché arrotondarlo a 16 bit. 1. **Scegliete la lunghezza del faro** Queste equazioni identificano solo l'intervallo consigliato di lunghezze dei beacon per il tuo campo. Ti consigliamo di utilizzare un beacon di lunghezza inferiore per preservare la sicurezza del set di dati quando possibile. Tuttavia, la lunghezza del beacon effettivamente utilizzata è determinata dal modello di minaccia in uso. Considerate i vostri requisiti prestazionali quando esaminate il modello di minaccia per determinare la lunghezza del beacon migliore per il vostro campo. L'utilizzo di un beacon di lunghezza inferiore riduce le prestazioni delle query, mentre l'utilizzo di un beacon di lunghezza maggiore riduce la sicurezza. In generale, se il set di dati è [distribuito](searchable-encryption.md#searchable-encryption-distribution) in modo non uniforme o se si creano beacon distinti a partire da campi [correlati](searchable-encryption.md#searchable-encryption-correlated-values), è necessario utilizzare beacon di lunghezza inferiore per ridurre al minimo la quantità di informazioni rivelate sulla distribuzione dei set di dati. Se esamini il tuo modello di minaccia e decidi che qualsiasi informazione distintiva rivelata sulla distribuzione di un campo non rappresenta una minaccia per la tua sicurezza generale, puoi scegliere di utilizzare una lunghezza del beacon superiore all'intervallo consigliato che hai calcolato. Ad esempio, se l'intervallo consigliato di lunghezze dei beacon per un campo è compreso tra 9 e 16 bit, è possibile scegliere di utilizzare una lunghezza del beacon di 24 bit per evitare perdite di prestazioni. Scegliete con attenzione la lunghezza del vostro faro. Dopo aver scritto nuovi record con il beacon, non è possibile aggiornare la lunghezza del beacon. ## Esempio [Prendiamo in considerazione un database che contrassegna il `unit` campo come `ENCRYPT_AND_SIGN` nelle azioni crittografiche.](concepts.md#crypt-actions) Per configurare un beacon standard per il `unit` campo, dobbiamo determinare il numero previsto di falsi positivi e la lunghezza del beacon per il campo. `unit` 1. Stima la popolazione Dopo aver esaminato il nostro modello di minaccia e l'attuale soluzione di database, prevediamo che alla fine il `unit` campo avrà 100.000 valori univoci. Ciò significa che **Popolazione = 100.000**. 1. Calcola l'intervallo consigliato per il numero previsto di collisioni. Per questo esempio, il numero previsto di collisioni deve essere compreso tra 2 e 316. ``` 2 ≤ number of collisions < √(Population) ``` 1. ``` 2 ≤ number of collisions < √(100,000) ``` 1. ``` 2 ≤ number of collisions < 316 ``` 1. Calcola l'intervallo consigliato per la lunghezza del faro. Per questo esempio, la lunghezza del faro deve essere compresa tra 9 e 16 bit. ``` number of collisions = Population * 2-(beacon length) ``` 1. **Calcola la lunghezza del faro in cui il numero previsto di collisioni è uguale al minimo identificato nella Fase 2.** ``` 2 = 100,000 * 2-(beacon length) ``` Lunghezza del faro = 15,6 o 15 bit 1. **Calcola la lunghezza del faro in cui il numero previsto di collisioni è uguale al massimo identificato nella Fase 2.** ``` 316 = 100,000 * 2-(beacon length) ``` Lunghezza del faro = 8,3 o 8 bit 1. Determinate la lunghezza del beacon appropriata per i vostri requisiti di sicurezza e prestazioni. Per ogni bit inferiore a 15, il costo delle prestazioni e la sicurezza raddoppiano. + 16 bit + In media, ogni valore univoco verrà mappato a 1,5 altre unità. + Sicurezza: due record con lo stesso tag HMAC troncato hanno il 66% di probabilità che abbiano lo stesso valore di testo in chiaro. + Prestazioni: una query recupererà 15 record ogni 10 record effettivamente richiesti. + 14 bit + In media, ogni valore univoco verrà mappato a 6,1 altre unità. + Sicurezza: due record con lo stesso tag HMAC troncato hanno il 33% di probabilità che abbiano lo stesso valore di testo in chiaro. + Prestazioni: una query recupererà 30 record ogni 10 record effettivamente richiesti. # Scelta del nome del faro **** | | | --- | | La nostra libreria di crittografia lato client è stata rinominata Database Encryption SDK. AWS Questa guida per sviluppatori fornisce ancora informazioni sul [DynamoDB Encryption Client](legacy-dynamodb-encryption-client.md). | *Ogni beacon è identificato da un nome univoco.* Una volta configurato un beacon, il nome del beacon è il nome utilizzato quando si esegue una query su un campo crittografato. Il nome di un beacon può avere lo stesso nome di un campo crittografato o di un campo [virtuale, ma non può avere lo stesso nome di un campo](beacons.md#virtual-field) non crittografato. Due beacon diversi non possono avere lo stesso nome beacon. [Per esempi che dimostrano come denominare e configurare i beacon, vedere Configurazione dei beacon.](configure-beacons.md) **Denominazione dei beacon standard** [*Quando si assegnano nomi ai beacon standard, si consiglia vivamente di convertire il nome del beacon nella fonte del beacon, quando possibile.*](beacons.md#beacon-source) Ciò significa che il nome del beacon e il nome del campo criptato o [virtuale](beacons.md#virtual-field) da cui è costruito il beacon standard sono gli stessi. Ad esempio, se state creando un beacon standard per un campo criptato denominato`LastName`, dovrebbe esserlo anche il nome del beacon. `LastName` Se il nome del beacon è lo stesso della fonte del beacon, puoi omettere la fonte del beacon dalla configurazione e AWS Database Encryption SDK utilizzerà automaticamente il nome del beacon come fonte del beacon. # Configurazione dei beacon **** | | | --- | | La nostra libreria di crittografia lato client è stata rinominata Database Encryption SDK. AWS Questa guida per sviluppatori fornisce ancora informazioni sul [DynamoDB Encryption Client](legacy-dynamodb-encryption-client.md). | Esistono due tipi di beacon che supportano la crittografia ricercabile. I beacon standard eseguono ricerche di uguaglianza. Sono il modo più semplice per implementare la crittografia ricercabile nel database. I beacon composti combinano stringhe letterali in chiaro e beacon standard per eseguire query più complesse. I beacon sono progettati per essere implementati in nuovi database non popolati. Qualsiasi beacon configurato in un database esistente mapperà solo i nuovi record scritti nel database. I beacon vengono calcolati in base al valore in chiaro di un campo, una volta crittografato il campo non è più possibile per il beacon di mappare i dati esistenti. Dopo aver scritto nuovi record con un beacon, non è possibile aggiornare la configurazione del beacon. Tuttavia, puoi aggiungere nuovi beacon per i nuovi campi che aggiungi al tuo record. Dopo aver determinato i modelli di accesso, la configurazione dei beacon dovrebbe essere il secondo passaggio dell'implementazione del database. Quindi, dopo aver configurato tutti i beacon, è necessario creare un [portachiavi AWS KMS gerarchico](use-hierarchical-keyring.md), definire la versione del beacon, configurare un [indice secondario per ogni beacon, definire le azioni [crittografiche](concepts.md#crypt-actions) e configurare](ddb-searchable-encryption.md#ddb-beacon-indexes) il database e il client Database Encryption SDK. AWS [Per ulteriori informazioni, consulta Utilizzo dei beacon.](using-beacons.md) Per semplificare la definizione della versione beacon, consigliamo di creare elenchi per beacon standard e composti. Aggiungi ogni beacon che crei al rispettivo elenco di beacon standard o compositi man mano che li configuri. **Topics** + [Configurazione dei beacon standard](#config-standard-beacons) + [Configurazione dei beacon composti](#config-compound-beacons) + [Configurazioni di esempio](beacon-config-examples.md) ## Configurazione dei beacon standard [I beacon standard](beacons.md#standard-beacon-overview) sono il modo più semplice per implementare la crittografia ricercabile nel database. Possono eseguire ricerche di uguaglianza solo per un singolo campo crittografato o virtuale. ### Esempio di sintassi di configurazione ------ #### [ Java ] ``` List standardBeaconList = new ArrayList<>(); StandardBeacon exampleStandardBeacon = StandardBeacon.builder() .name("beaconName") .length(beaconLengthInBits) .build(); standardBeaconList.add(exampleStandardBeacon); ``` ------ #### [ C\$1 / .NET ] ``` var standardBeaconList = new List(); StandardBeacon exampleStandardBeacon = new StandardBeacon { Name = "beaconName", Length = 10 }; standardBeaconList.Add(exampleStandardBeacon); ``` ------ #### [ Rust ] ``` let standard_beacon_list = vec![ StandardBeacon::builder().name("beacon_name").length(beacon_length_in_bits).build()?, ``` ------ Per configurare un beacon standard, fornite i seguenti valori. **Nome del beacon** Il nome che usi per interrogare un campo crittografato. Il nome di un beacon può avere lo stesso nome di un campo crittografato o di un campo virtuale, ma non può avere lo stesso nome di un campo non crittografato. Se possibile, consigliamo vivamente di utilizzare il nome del campo crittografato o del [campo virtuale](beacons.md#virtual-field) da cui è costruito il beacon standard. Due beacon diversi non possono avere lo stesso nome di beacon. [Per informazioni su come determinare il nome del beacon migliore per l'implementazione, consulta Scelta del nome del beacon.](choosing-beacon-name.md) **Lunghezza del faro** Il numero di bit del valore hash del beacon che vengono conservati dopo il troncamento. La lunghezza del faro determina il numero medio di falsi positivi prodotti da un determinato faro. [Per ulteriori informazioni e assistenza nella determinazione della lunghezza del beacon appropriata per l'implementazione, vedere Determinazione della lunghezza del beacon.](choosing-beacon-length.md) **Fonte del beacon (opzionale)** Il campo da cui è costruito un beacon standard. La fonte del beacon deve essere un nome di campo o un indice che si riferisce al valore di un campo annidato. Quando il nome del beacon è lo stesso della fonte del beacon, puoi omettere la fonte del beacon dalla configurazione e AWS Database Encryption SDK utilizzerà automaticamente il nome del beacon come fonte del beacon. ### Creazione di un campo virtuale Per creare un [campo virtuale](beacons.md#virtual-field), è necessario fornire un nome per il campo virtuale e un elenco dei campi di origine. L'ordine in cui vengono aggiunti i campi di origine all'elenco delle parti virtuali determina l'ordine in cui vengono concatenati per creare il campo virtuale. L'esempio seguente concatena due campi sorgente nella loro interezza per creare un campo virtuale. **Nota** Ti consigliamo di verificare che i campi virtuali producano il risultato previsto prima di popolare il database. Per ulteriori informazioni, consulta [Testing beacon](ddb-searchable-encryption.md#ddb-beacon-testing) outputs. ------ #### [ Java ] **[Vedi l'esempio di codice completo: .java VirtualBeaconSearchableEncryptionExample](https://github.com/aws/aws-database-encryption-sdk-dynamodb//blob/main/Examples/runtimes/java/DynamoDbEncryption/src/main/java/software/amazon/cryptography/examples/searchableencryption/VirtualBeaconSearchableEncryptionExample.java)** ``` List virtualPartList = new ArrayList<>(); virtualPartList.add(sourceField1); virtualPartList.add(sourceField2); VirtualField virtualFieldName = VirtualField.builder() .name("virtualFieldName") .parts(virtualPartList) .build(); List virtualFieldList = new ArrayList<>(); virtualFieldList.add(virtualFieldName); ``` ------ #### [ C\$1 / .NET ] **[Guarda l'esempio di codice completo: .cs VirtualBeaconSearchableEncryptionExample](https://github.com/aws/aws-database-encryption-sdk-dynamodb/tree/main/Examples/runtimes/net/src/searchableencryption/VirtualBeaconSearchableEncryptionExample.cs)** ``` var virtualPartList = new List { sourceField1, sourceField2 }; var virtualFieldName = new VirtualField { Name = "virtualFieldName", Parts = virtualPartList }; var virtualFieldList = new List { virtualFieldName }; ``` ------ #### [ Rust ] **Guarda l'esempio di codice completo**[: virtual\$1beacon\$1searchable\$1encryption.rs](https://github.com/aws/aws-database-encryption-sdk-dynamodb/blob/main/releases/rust/db_esdk/examples/searchableencryption/virtual_beacon_searchable_encryption.rs) ``` let virtual_part_list = vec![source_field_one, source_field_two]; let state_and_has_test_result_field = VirtualField::builder() .name("virtual_field_name") .parts(virtual_part_list) .build()?; let virtual_field_list = vec![virtual_field_name]; ``` ------ Per creare un campo virtuale con un segmento specifico di un campo sorgente, è necessario definire tale trasformazione prima di aggiungere il campo di origine all'elenco delle parti virtuali. #### Considerazioni sulla sicurezza per i campi virtuali I beacon non alterano lo stato crittografato del campo. Tuttavia, quando si utilizzano i beacon, esiste un compromesso intrinseco tra l'efficienza delle query e la quantità di informazioni rivelate sulla distribuzione dei dati. Il modo in cui configuri il beacon determina il livello di sicurezza che viene mantenuto da quel beacon. Evitate di creare un campo virtuale con campi sorgente che si sovrappongono ai beacon standard esistenti. La creazione di campi virtuali che includono un campo sorgente che è già stato utilizzato per creare un beacon standard può ridurre il livello di sicurezza di entrambi i beacon. La misura in cui la sicurezza viene ridotta dipende dal livello di entropia aggiunto dai campi sorgente aggiuntivi. Il livello di entropia è determinato dalla distribuzione di valori univoci nel campo sorgente aggiuntivo e dal numero di bit con cui il campo sorgente aggiuntivo contribuisce alla dimensione complessiva del campo virtuale. È possibile utilizzare la popolazione e la [lunghezza del beacon](choosing-beacon-length.md) per determinare se i campi di origine di un campo virtuale preservano la sicurezza del set di dati. La popolazione è il numero previsto di valori univoci in un campo. Non è necessario che la tua popolazione sia precisa. Per informazioni sulla stima della popolazione di un campo, vedi [Stima della popolazione](choosing-beacon-length.md#estimate-population). Considera il seguente esempio quando esamini la sicurezza dei tuoi campi virtuali. + Beacon1 è costruito da. `FieldA` `FieldA`ha una popolazione superiore a **2 (lunghezza Beacon1**). + Beacon2 è costruito da`VirtualField`, che è costruito da,, e. `FieldA` `FieldB` `FieldC` `FieldD` **Insieme, `FieldB``FieldC`, e `FieldD` hanno una popolazione superiore a 2 N** Beacon2 preserva la sicurezza sia di Beacon1 che di Beacon2 se le seguenti affermazioni sono vere: ``` N ≥ (Beacon1 length)/2 ``` and ``` N ≥ (Beacon2 length)/2 ``` ### Definizione degli stili dei beacon I beacon standard possono essere utilizzati per eseguire ricerche di uguaglianza per un campo crittografato o virtuale. In alternativa, possono essere utilizzati per costruire beacon composti per eseguire operazioni di database più complesse. Per aiutarvi a organizzare e gestire i beacon standard, il AWS Database Encryption SDK fornisce i seguenti *stili di beacon opzionali che definiscono l'uso previsto di un beacon* standard. **Nota** Per definire gli stili dei beacon, è necessario utilizzare la versione 3.2 o successiva di Database Encryption SDK. AWS Distribuisci la nuova versione a tutti i lettori prima di aggiungere stili beacon alle configurazioni dei beacon. ------ #### [ PartOnly ] [Un beacon standard definito come `PartOnly` può essere utilizzato solo per definire una parte crittografata di un beacon composto.](#encrypted-parts) Non è possibile interrogare direttamente un beacon standard. `PartOnly` **Java** ``` List standardBeaconList = new ArrayList<>(); StandardBeacon exampleStandardBeacon = StandardBeacon.builder() .name("beaconName") .length(beaconLengthInBits) .style( BeaconStyle.builder() .partOnly(PartOnly.builder().build()) .build() ) .build(); standardBeaconList.add(exampleStandardBeacon); ``` **C\$1 /.NET** ``` new StandardBeacon { Name = "beaconName", Length = beaconLengthInBits, Style = new BeaconStyle { PartOnly = new PartOnly() } } ``` **Rust** ``` StandardBeacon::builder() .name("beacon_name") .length(beacon_length_in_bits) .style(BeaconStyle::PartOnly(PartOnly::builder().build()?)) .build()? ``` ------ #### [ Shared ] Per impostazione predefinita, ogni beacon standard genera una chiave HMAC unica per il calcolo del beacon. Di conseguenza, non è possibile eseguire una ricerca di uguaglianza sui campi crittografati utilizzando due beacon standard separati. Un beacon standard definito come `Shared` utilizza la chiave HMAC di un altro beacon standard per i suoi calcoli. Ad esempio, se devi confrontare `beacon1` campi con `beacon2` campi, definiscilo `beacon2` come un `Shared` beacon che utilizza la chiave HMAC di per i suoi calcoli. `beacon1` **Nota** Considerate le vostre esigenze di sicurezza e prestazioni prima di configurare qualsiasi beacon. `Shared` `Shared`i beacon potrebbero aumentare la quantità di informazioni statistiche identificabili sulla distribuzione del set di dati. Ad esempio, potrebbero rivelare quali campi condivisi contengono lo stesso valore di testo in chiaro. **Java** ``` List standardBeaconList = new ArrayList<>(); StandardBeacon exampleStandardBeacon = StandardBeacon.builder() .name("beacon2") .length(beaconLengthInBits) .style( BeaconStyle.builder() .shared(Shared.builder().other("beacon1").build()) .build() ) .build(); standardBeaconList.add(exampleStandardBeacon); ``` **C\$1 /.NET** ``` new StandardBeacon { Name = "beacon2", Length = beaconLengthInBits, Style = new BeaconStyle { Shared = new Shared { Other = "beacon1" } } } ``` **Rust** ``` StandardBeacon::builder() .name("beacon2") .length(beacon_length_in_bits) .style(BeaconStyle::Shared( Shared::builder().other("beacon1").build()?, )) .build()? ``` ------ #### [ AsSet ] Per impostazione predefinita, se il valore di un campo è un set, AWS Database Encryption SDK calcola un singolo beacon standard per il set. Di conseguenza, non è possibile eseguire la query `CONTAINS(a, :value)` dove si `a` trova un campo crittografato. Un beacon standard definito come `AsSet` calcola i singoli valori del beacon standard per ogni singolo elemento del set e memorizza il valore del beacon nell'elemento come set. Ciò consente al AWS Database Encryption SDK di eseguire la query. `CONTAINS(a, :value)` [Per definire un beacon `AsSet` standard, gli elementi del set devono appartenere alla stessa popolazione in modo che possano utilizzare tutti la stessa lunghezza del beacon.](choosing-beacon-length.md) Il set beacon potrebbe contenere un numero inferiore di elementi rispetto al set di testo in chiaro in caso di collisioni durante il calcolo dei valori del beacon. **Nota** Considerate le vostre esigenze di sicurezza e prestazioni prima di configurare qualsiasi beacon. `AsSet` `AsSet`i beacon potrebbero aumentare la quantità di informazioni statistiche identificabili sulla distribuzione del set di dati. Ad esempio, potrebbero rivelare la dimensione del set di testo in chiaro. **Java** ``` List standardBeaconList = new ArrayList<>(); StandardBeacon exampleStandardBeacon = StandardBeacon.builder() .name("beaconName") .length(beaconLengthInBits) .style( BeaconStyle.builder() .asSet(AsSet.builder().build()) .build() ) .build(); standardBeaconList.add(exampleStandardBeacon); ``` **C\$1 /.NET** ``` new StandardBeacon { Name = "beaconName", Length = beaconLengthInBits, Style = new BeaconStyle { AsSet = new AsSet() } } ``` **Rust** ``` StandardBeacon::builder() .name("beacon_name") .length(beacon_length_in_bits) .style(BeaconStyle::AsSet(AsSet::builder().build()?)) .build()? ``` ------ #### [ SharedSet ] Un beacon standard definito come `SharedSet` combina le `AsSet` funzioni `Shared` and in modo da poter eseguire ricerche di uguaglianza sui valori crittografati di un set e di un campo. Ciò consente al AWS Database Encryption SDK di eseguire la query `CONTAINS(a, b)` in cui si `a` trova un set crittografato e `b` un campo crittografato. **Nota** Considerate le vostre esigenze di sicurezza e prestazioni prima di configurare qualsiasi `Shared` beacon. `SharedSet`i beacon potrebbero aumentare la quantità di informazioni statistiche identificabili sulla distribuzione del set di dati. Ad esempio, potrebbero rivelare la dimensione del set di testo in chiaro o quali campi condivisi contengono lo stesso valore di testo in chiaro. **Java** ``` List standardBeaconList = new ArrayList<>(); StandardBeacon exampleStandardBeacon = StandardBeacon.builder() .name("beacon2") .length(beaconLengthInBits) .style( BeaconStyle.builder() .sharedSet(SharedSet.builder().other("beacon1").build()) .build() ) .build(); standardBeaconList.add(exampleStandardBeacon); ``` **C\$1 /.NET** ``` new StandardBeacon { Name = "beacon2", Length = beaconLengthInBits, Style = new BeaconStyle { SharedSet = new SharedSet { Other = "beacon1" } } } ``` **Rust** ``` StandardBeacon::builder() .name("beacon2") .length(beacon_length_in_bits) .style(BeaconStyle::SharedSet( SharedSet::builder().other("beacon1").build()?, )) .build()? ``` ------ ## Configurazione dei beacon composti I beacon composti combinano stringhe letterali in chiaro e beacon standard per eseguire operazioni complesse sul database, come interrogare due diversi tipi di record da un singolo indice o interrogare una combinazione di campi con una chiave di ordinamento. I beacon composti possono essere costruiti da, e campi. `ENCRYPT_AND_SIGN` `SIGN_ONLY` `SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT` È necessario creare un beacon standard per ogni campo crittografato incluso nel beacon composto. **Nota** Ti consigliamo di verificare che i beacon composti producano il risultato previsto prima di popolare il database. [Per ulteriori informazioni, consulta Testing beacon outputs.](ddb-searchable-encryption.md#ddb-beacon-testing) ### Esempio di sintassi di configurazione ------ #### [ Java ] **Configurazione del beacon composto** L'esempio seguente definisce gli elenchi di parti crittografati e firmati localmente all'interno della configurazione del beacon composto. ``` List compoundBeaconList = new ArrayList<>(); CompoundBeacon exampleCompoundBeacon = CompoundBeacon.builder() .name("compoundBeaconName") .split(".") .encrypted(encryptedPartList) .signed(signedPartList) .constructors(constructorList) .build(); compoundBeaconList.add(exampleCompoundBeacon); ``` **Definizione della versione del beacon** L'esempio seguente definisce gli elenchi di parti crittografati e firmati a livello globale nella versione beacon. [Per ulteriori informazioni sulla definizione della versione beacon, vedete Uso dei beacon.](using-beacons.md) ``` List beaconVersions = new ArrayList<>(); beaconVersions.add( BeaconVersion.builder() .standardBeacons(standardBeaconList) .compoundBeacons(compoundBeaconList) .encryptedParts(encryptedPartList) .signedParts(signedPartList) .version(1) // MUST be 1 .keyStore(keyStore) .keySource(BeaconKeySource.builder() .single(SingleKeyStore.builder() .keyId(branchKeyId) .cacheTTL(6000) .build()) .build()) .build() ); ``` ------ #### [ C\$1 / .NET ] **Guarda l'esempio di codice completo**[: .cs BeaconConfig](https://github.com/aws/aws-database-encryption-sdk-dynamodb/tree/main/Examples/runtimes/net/src/searchableencryption/complexexample/BeaconConfig.cs) **Configurazione del beacon composto** L'esempio seguente definisce gli elenchi di parti crittografati e firmati localmente all'interno della configurazione del beacon composto. ``` var compoundBeaconList = new List(); var exampleCompoundBeacon = new CompoundBeacon { Name = "compoundBeaconName", Split = ".", Encrypted = encryptedPartList, Signed = signedPartList, Constructors = constructorList }; compoundBeaconList.Add(exampleCompoundBeacon); ``` **Definizione della versione del beacon** L'esempio seguente definisce gli elenchi di parti crittografati e firmati a livello globale nella versione beacon. [Per ulteriori informazioni sulla definizione della versione beacon, vedete Uso dei beacon.](using-beacons.md) ``` var beaconVersions = new List { new BeaconVersion { StandardBeacons = standardBeaconList, CompoundBeacons = compoundBeaconList, EncryptedParts = encryptedPartsList, SignedParts = signedPartsList, Version = 1, // MUST be 1 KeyStore = keyStore, KeySource = new BeaconKeySource { Single = new SingleKeyStore { KeyId = branchKeyId, CacheTTL = 6000 } } } }; ``` ------ #### [ Rust ] **Guardate l'esempio completo** [di codice: beacon\$1config.rs](https://github.com/aws/aws-database-encryption-sdk-dynamodb/blob/main/releases/rust/db_esdk/examples/searchableencryption/complexexample/beacon_config.rs) **Configurazione del beacon composto** L'esempio seguente definisce gli elenchi di parti crittografati e firmati localmente all'interno della configurazione del beacon composto. ``` let compound_beacon_list = vec![ CompoundBeacon::builder() .name("compound_beacon_name") .split(".") .encrypted(encrypted_parts_list) .signed(signed_parts_list) .constructors(constructor_list) .build()? ``` **Definizione della versione del beacon** L'esempio seguente definisce gli elenchi di parti crittografati e firmati a livello globale nella versione beacon. [Per ulteriori informazioni sulla definizione della versione beacon, vedete Uso dei beacon.](using-beacons.md) ``` let beacon_versions = BeaconVersion::builder() .standard_beacons(standard_beacon_list) .compound_beacons(compound_beacon_list) .encrypted_parts(encrypted_parts_list) .signed_parts(signed_parts_list) .version(1) // MUST be 1 .key_store(key_store.clone()) .key_source(BeaconKeySource::Single( SingleKeyStore::builder() .key_id(branch_key_id) .cache_ttl(6000) .build()?, )) .build()?; let beacon_versions = vec![beacon_versions]; ``` ------ È possibile definire le [parti crittografate e le parti](#encrypted-parts) [firmate](#signed-parts) in elenchi definiti localmente o globalmente. Ti consigliamo di definire le parti crittografate e firmate in un elenco globale nella [versione beacon, quando possibile](using-beacons.md#beacon-version). Definendo le parti crittografate e firmate a livello globale, è possibile definire ogni parte una volta e quindi riutilizzarle in più configurazioni beacon composte. Se intendete utilizzare una parte crittografata o firmata una sola volta, potete definirla in un elenco locale nella configurazione del beacon composto. È possibile fare riferimento sia alle parti locali che a quelle globali nell'elenco dei [costruttori](#constructor-parts). Se definite gli elenchi di parti crittografati e firmati a livello globale, dovete fornire un elenco di parti del costruttore che identifichi tutti i modi possibili in cui il beacon composto può assemblare i campi nella configurazione del beacon composto. **Nota** Per definire elenchi di parti crittografati e firmati 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 crittografati e firmati a livello globale. Per configurare un beacon composto, fornite i seguenti valori. **Nome del beacon** Il nome che usi per interrogare un campo crittografato. Il nome di un beacon può avere lo stesso nome di un campo crittografato o di un campo virtuale, ma non può avere lo stesso nome di un campo non crittografato. Due beacon non possono avere lo stesso nome di beacon. [Per informazioni su come determinare il nome del beacon migliore per l'implementazione, consulta Scelta del nome del beacon.](choosing-beacon-name.md) **Carattere diviso** Il personaggio usato per separare le parti che compongono il faro composto. Il carattere diviso non può apparire nei valori in chiaro di nessuno dei campi da cui è costruito il beacon composto. **Elenco delle parti crittografato** Identifica i `ENCRYPT_AND_SIGN` campi inclusi nel beacon composto. Ogni parte deve includere un nome e un prefisso. Il nome della parte deve essere il nome del beacon standard costruito a partire dal campo crittografato. Il prefisso può essere qualsiasi stringa, ma deve essere univoco. Una parte crittografata non può avere lo stesso prefisso di una parte firmata. Si consiglia di utilizzare un valore breve che distingua la parte dalle altre parti servite dal beacon composto. Ti consigliamo di definire le parti crittografate a livello globale quando possibile. Potresti prendere in considerazione la definizione locale di una parte crittografata se intendi utilizzarla solo in un beacon composto. Una parte crittografata definita localmente non può avere lo stesso prefisso o nome di una parte crittografata definita a livello globale. ``` List encryptedPartList = new ArrayList<>(); EncryptedPart encryptedPartExample = EncryptedPart.builder() .name("standardBeaconName") .prefix("E-") .build(); encryptedPartList.add(encryptedPartExample); ``` ``` var encryptedPartList = new List(); var encryptedPartExample = new EncryptedPart { Name = "compoundBeaconName", Prefix = "E-" }; encryptedPartList.Add(encryptedPartExample); ``` ``` let encrypted_parts_list = vec![ EncryptedPart::builder() .name("standard_beacon_name") .prefix("E-") .build()? ]; ``` **Elenco delle parti firmate** Identifica i campi firmati inclusi nel beacon composto. Le parti firmate sono opzionali. È possibile configurare un beacon composto che non faccia riferimento a parti firmate. 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. Una parte firmata non può avere lo stesso prefisso di una parte crittografata. 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 firmata definita localmente non può avere lo stesso prefisso o nome di una parte firmata definita a livello globale. ``` List signedPartList = new ArrayList<>(); SignedPart signedPartExample = SignedPart.builder() .name("signedFieldName") .prefix("S-") .build(); signedPartList.add(signedPartExample); ``` ``` var signedPartsList = new List { new SignedPart { Name = "signedFieldName1", Prefix = "S-" }, new SignedPart { Name = "signedFieldName2", Prefix = "SF-" } }; ``` ``` let signed_parts_list = vec![ SignedPart::builder() .name("signed_field_name_1") .prefix("S-") .build()?, SignedPart::builder() .name("signed_field_name_2") .prefix("SF-") .build()?, ]; ``` **Elenco dei costruttori** Identifica i *costruttori* che definiscono i diversi modi in cui le parti crittografate e firmate possono essere assemblate dal beacon composto. È possibile fare riferimento sia alle parti locali che a quelle globali nell'elenco dei costruttori. Se costruite il vostro beacon composto da parti crittografate e firmate definite a livello globale, dovete fornire un elenco di costruttori. Se non utilizzate parti crittografate o firmate definite a livello globale per costruire il beacon composto, l'elenco dei costruttori è facoltativo. Se non specificate un elenco di costruttori, AWS Database Encryption SDK assembla il beacon composto con il seguente costruttore predefinito. + Tutte le parti firmate nell'ordine in cui sono state aggiunte all'elenco delle parti firmate + Tutte le parti crittografate nell'ordine in cui sono state aggiunte all'elenco delle parti crittografate + Tutte le parti sono obbligatorie **Costruttori** Ogni costruttore è un elenco ordinato di *parti del costruttore* che definisce un modo in cui il faro composto 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 crittografata o firmata e definisce se tale parte è obbligatoria o facoltativa all'interno del costruttore. Ad esempio, se si desidera interrogare un beacon composto su`Field1`, e `Field1.Field2``Field1.Field2.Field3`, contrassegnarlo `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_WITH`operatore nelle query. Un costruttore ha successo se tutte le parti necessarie sono presenti nel record. Quando si scrive un nuovo record, il beacon composto 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 riesce, 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 crittografata e parte firmata per definire se quella parte è necessaria o meno. Il nome della parte del costruttore deve essere il nome del beacon standard o del campo firmato che rappresenta. ------ #### [ Java ] ``` ConstructorPart field1ConstructorPart = ConstructorPart.builder() .name("Field1") .required(true) .build(); ``` ------ #### [ C\$1 / .NET ] ``` var field1ConstructorPart = new ConstructorPart { Name = "Field1", Required = true }; ``` ------ #### [ Rust ] ``` let field_1_constructor_part = ConstructorPart::builder() .name("field_1") .required(true) .build()?; ``` ------ 1. **Create un costruttore per ogni possibile modo in cui il beacon composto può essere assemblato utilizzando le parti del costruttore create nel passaggio 1.** Ad esempio, se si desidera eseguire un'interrogazione su `Field1.Field2.Field3` and`Field4.Field2.Field3`, è necessario creare due costruttori. `Field1`e `Field4` possono essere entrambi obbligatori perché sono definiti in due costruttori separati. ------ #### [ Java ] ``` // Create a list for Field1.Field2.Field3 queries List 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 field421ConstructorPartList = new ArrayList<>(); field421ConstructorPartList.add(field4ConstructorPart); field421ConstructorPartList.add(field2ConstructorPart); field421ConstructorPartList.add(field1ConstructorPart); Constructor field421Constructor = Constructor.builder() .parts(field421ConstructorPartList) .build(); ``` ------ #### [ C\$1 / .NET ] ``` // Create a list for Field1.Field2.Field3 queries var field123ConstructorPartList = new Constructor { Parts = new List { field1ConstructorPart, field2ConstructorPart, field3ConstructorPart } }; // Create a list for Field4.Field2.Field1 queries var field421ConstructorPartList = new Constructor { Parts = new List { field4ConstructorPart, field2ConstructorPart, field1ConstructorPart } }; ``` ------ #### [ Rust ] ``` // Create a list for field1.field2.field3 queries let field1_field2_field3_constructor = Constructor::builder() .parts(vec![ field1_constructor_part, field2_constroctor_part.clone(), field3_constructor_part, ]) .build()?; // Create a list for field4.field2.field1 queries let field4_field2_field1_constructor = Constructor::builder() .parts(vec![ field4_constructor_part, field2_constroctor_part.clone(), field1_constructor_part, ]) .build()?; ``` ------ 1. **Create un elenco di costruttori che includa tutti i costruttori creati nel passaggio 2.** ------ #### [ Java ] ``` List constructorList = new ArrayList<>(); constructorList.add(field123Constructor); constructorList.add(field421Constructor); ``` ------ #### [ C\$1 / .NET ] ``` var constructorList = new List { field123Constructor, field421Constructor }; ``` ------ #### [ Rust ] ``` let constructor_list = vec![ field1_field2_field3_constructor, field4_field2_field1_constructor, ]; ``` ------ 1. Specificate `constructorList` quando create il beacon composto. # Configurazioni di esempio **** | | | --- | | La nostra libreria di crittografia lato client è stata rinominata Database Encryption SDK. AWS Questa guida per sviluppatori fornisce ancora informazioni sul [DynamoDB Encryption Client](legacy-dynamodb-encryption-client.md). | Gli esempi seguenti mostrano come configurare beacon standard e composti. Le seguenti configurazioni non forniscono le lunghezze dei beacon. [Per informazioni sulla determinazione della lunghezza del beacon appropriata per la configurazione, consulta Scelta della lunghezza del beacon.](choosing-beacon-length.md) Per vedere esempi di codice completi che dimostrano come configurare e utilizzare i beacon, consulta gli esempi di crittografia ricercabile in [Java](https://github.com/aws/aws-database-encryption-sdk-dynamodb//tree/main/Examples/runtimes/java/DynamoDbEncryption/src/main/java/software/amazon/cryptography/examples/searchableencryption), [.NET](https://github.com/aws/aws-database-encryption-sdk-dynamodb/tree/main/Examples/runtimes/net/src/searchableencryption/) e [Rust](https://github.com/aws/aws-database-encryption-sdk-dynamodb/blob/main/releases/rust/db_esdk/examples/searchableencryption/) nel repository -dynamodb on. aws-database-encryption-sdk GitHub **Topics** + [Beacon standard](#standard-config-examples) + [Fari composti](#compound-config-examples) ## Beacon standard Se desideri interrogare il `inspector_id_last4` campo per verificare le corrispondenze esatte, crea un beacon standard utilizzando la seguente configurazione. ------ #### [ Java ] ``` List standardBeaconList = new ArrayList<>(); StandardBeacon exampleStandardBeacon = StandardBeacon.builder() .name("inspector_id_last4") .length(beaconLengthInBits) .build(); standardBeaconList.add(exampleStandardBeacon); ``` ------ #### [ C\$1 / .NET ] ``` var standardBeaconList = new List>); StandardBeacon exampleStandardBeacon = new StandardBeacon { Name = "inspector_id_last4", Length = 10 }; standardBeaconList.Add(exampleStandardBeacon); ``` ------ #### [ Rust ] ``` let last4_beacon = StandardBeacon::builder() .name("inspector_id_last4") .length(10) .build()?; let unit_beacon = StandardBeacon::builder().name("unit").length(30).build()?; let standard_beacon_list = vec![last4_beacon, unit_beacon]; ``` ------ ## Fari composti Se vuoi interrogare il `UnitInspection` database su `inspector_id_last4` and`inspector_id_last4.unit`, crea un beacon composto con la seguente configurazione. [Questo beacon composto richiede solo parti criptate.](configure-beacons.md#encrypted-parts) ------ #### [ Java ] ``` // 1. Create standard beacons for the inspector_id_last4 and unit fields. List standardBeaconList = new ArrayList<>(); StandardBeacon inspectorBeacon = StandardBeacon.builder() .name("inspector_id_last4") .length(beaconLengthInBits) .build(); standardBeaconList.add(inspectorBeacon); StandardBeacon unitBeacon = StandardBeacon.builder() .name("unit") .length(beaconLengthInBits) .build(); standardBeaconList.add(unitBeacon); // 2. Define the encrypted parts. List encryptedPartList = new ArrayList<>(); // Each encrypted part needs a name and prefix // The name must be the name of the standard beacon // The prefix must be unique // For this example we use the prefix "I-" for "inspector_id_last4" // and "U-" for "unit" EncryptedPart encryptedPartInspector = EncryptedPart.builder() .name("inspector_id_last4") .prefix("I-") .build(); encryptedPartList.add(encryptedPartInspector); EncryptedPart encryptedPartUnit = EncryptedPart.builder() .name("unit") .prefix("U-") .build(); encryptedPartList.add(encryptedPartUnit); // 3. Create the compound beacon. // This compound beacon only requires a name, split character, // and list of encrypted parts CompoundBeacon inspectorUnitBeacon = CompoundBeacon.builder() .name("inspectorUnitBeacon") .split(".") .sensitive(encryptedPartList) .build(); ``` ------ #### [ C\$1 / .NET ] ``` // 1. Create standard beacons for the inspector_id_last4 and unit fields. StandardBeacon inspectorBeacon = new StandardBeacon { Name = "inspector_id_last4", Length = 10 }; standardBeaconList.Add(inspectorBeacon); StandardBeacon unitBeacon = new StandardBeacon { Name = "unit", Length = 30 }; standardBeaconList.Add(unitBeacon); // 2. Define the encrypted parts. var last4EncryptedPart = new EncryptedPart // Each encrypted part needs a name and prefix // The name must be the name of the standard beacon // The prefix must be unique // For this example we use the prefix "I-" for "inspector_id_last4" // and "U-" for "unit" var last4EncryptedPart = new EncryptedPart { Name = "inspector_id_last4", Prefix = "I-" }; encryptedPartList.Add(last4EncryptedPart); var unitEncryptedPart = new EncryptedPart { Name = "unit", Prefix = "U-" }; encryptedPartList.Add(unitEncryptedPart); // 3. Create the compound beacon. // This compound beacon only requires a name, split character, // and list of encrypted parts var compoundBeaconList = new List>); var inspectorCompoundBeacon = new CompoundBeacon { Name = "inspector_id_last4", Split = ".", Encrypted = encryptedPartList }; compoundBeaconList.Add(inspectorCompoundBeacon); ``` ------ #### [ Rust ] ``` // 1. Create standard beacons for the inspector_id_last4 and unit fields. let last4_beacon = StandardBeacon::builder() .name("inspector_id_last4") .length(10) .build()?; let unit_beacon = StandardBeacon::builder().name("unit").length(30).build()?; let standard_beacon_list = vec![last4_beacon, unit_beacon]; // 2. Define the encrypted parts. // The name must be the name of the standard beacon // The prefix must be unique // For this example we use the prefix "I-" for "inspector_id_last4" // and "U-" for "unit" let encrypted_parts_list = vec![ EncryptedPart::builder() .name("inspector_id_last4") .prefix("I-") .build()?, EncryptedPart::builder().name("unit").prefix("U-").build()?, ]; // 3. Create the compound beacon // This compound beacon only requires a name, split character, // and list of encrypted parts let compound_beacon_list = vec![CompoundBeacon::builder() .name("last4UnitCompound") .split(".") .encrypted(encrypted_parts_list) .build()?]; ``` ------ # Utilizzo dei beacon **** | | | --- | | La nostra libreria di crittografia lato client è stata rinominata Database Encryption SDK. AWS Questa guida per sviluppatori fornisce ancora informazioni sul [DynamoDB Encryption Client](legacy-dynamodb-encryption-client.md). | I beacon consentono di cercare record crittografati senza decrittografare l'intero database su cui viene eseguita la query. I beacon sono progettati per essere implementati in nuovi database non popolati. Qualsiasi beacon configurato in un database esistente mapperà solo i nuovi record scritti nel database. I beacon vengono calcolati in base al valore in chiaro di un campo, una volta crittografato il campo non è più possibile per il beacon di mappare i dati esistenti. Dopo aver scritto nuovi record con un beacon, non è possibile aggiornare la configurazione del beacon. Tuttavia, puoi aggiungere nuovi beacon per i nuovi campi che aggiungi al tuo record. Dopo aver configurato i beacon, è necessario completare i seguenti passaggi prima di iniziare a popolare il database ed eseguire query sui beacon. 1. ** AWS KMS Crea un portachiavi gerarchico** [Per utilizzare la crittografia ricercabile, è necessario utilizzare il [portachiavi AWS KMS gerarchico per generare, crittografare e decrittografare le chiavi](use-hierarchical-keyring.md) dati utilizzate per proteggere i record.](concepts.md#data-key) [[Dopo aver configurato i beacon, assemblate i prerequisiti del portachiavi gerarchico e create il portachiavi gerarchico.](use-hierarchical-keyring.md#initialize-hierarchical-keyring)](use-hierarchical-keyring.md#hierarchical-keyring-prereqs) [Per maggiori dettagli sul motivo per cui è necessario il portachiavi gerarchico, consulta Utilizzo del portachiavi gerarchico per la crittografia ricercabile.](use-hierarchical-keyring.md#searchable-encryption-hierarchical-keyrings) 1. **Definisci la versione del beacon** Specificate il vostro `keyStore``keySource`, un elenco di tutti i beacon standard che avete configurato, un elenco di tutti i beacon composti che avete configurato, un elenco di parti crittografate, un elenco di parti firmate e una versione del beacon. È necessario specificare la versione beacon. `1` Per indicazioni sulla definizione del tuo`keySource`, vedi. [Definizione della fonte della chiave del beacon](use-hierarchical-keyring.md#beacon-key-source) Il seguente esempio di Java definisce la versione beacon per un database a tenant singolo. [Per informazioni sulla definizione della versione beacon per un database multitenant, vedere Crittografia ricercabile per database multitenant.](searchable-encryption-multitenant.md) ------ #### [ Java ] ``` List beaconVersions = new ArrayList<>(); beaconVersions.add( BeaconVersion.builder() .standardBeacons(standardBeaconList) .compoundBeacons(compoundBeaconList) .encryptedParts(encryptedPartsList) .signedParts(signedPartsList) .version(1) // MUST be 1 .keyStore(keyStore) .keySource(BeaconKeySource.builder() .single(SingleKeyStore.builder() .keyId(branchKeyId) .cacheTTL(6000) .build()) .build()) .build() ); ``` ------ #### [ C\$1 / .NET ] ``` var beaconVersions = new List { new BeaconVersion { StandardBeacons = standardBeaconList, CompoundBeacons = compoundBeaconList, EncryptedParts = encryptedPartsList, SignedParts = signedPartsList, Version = 1, // MUST be 1 KeyStore = branchKeyStoreName, KeySource = new BeaconKeySource { Single = new SingleKeyStore { KeyId = branch-key-id, CacheTTL = 6000 } } } }; ``` ------ #### [ Rust ] ``` let beacon_version = BeaconVersion::builder() .standard_beacons(standard_beacon_list) .compound_beacons(compound_beacon_list) .version(1) // MUST be 1 .key_store(key_store.clone()) .key_source(BeaconKeySource::Single( SingleKeyStore::builder() // `keyId` references a beacon key. // For every branch key we create in the keystore, // we also create a beacon key. // This beacon key is not the same as the branch key, // but is created with the same ID as the branch key. .key_id(branch_key_id) .cache_ttl(6000) .build()?, )) .build()?; let beacon_versions = vec![beacon_version]; ``` ------ 1. **Configura gli indici secondari** Dopo aver [configurato i beacon](configure-beacons.md), è necessario configurare un indice secondario che rifletta ogni beacon prima di poter eseguire la ricerca nei campi crittografati. Per ulteriori informazioni, consulta [Configurazione degli indici secondari con beacon](ddb-searchable-encryption.md#ddb-beacon-indexes). 1. **[Definisci le tue azioni crittografiche](concepts.md#crypt-actions)** Tutti i campi utilizzati per costruire un beacon standard devono essere contrassegnati. `ENCRYPT_AND_SIGN` Tutti gli altri campi utilizzati per costruire i beacon devono essere contrassegnati o. `SIGN_ONLY` `SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT` 1. **Configurare un client AWS Database Encryption SDK** Per configurare un client AWS Database Encryption SDK che protegge gli elementi della tabella DynamoDB, [consulta Libreria di crittografia lato client Java](ddb-java.md) per DynamoDB. ## Interrogazione dei beacon Il tipo di beacon configurato determina il tipo di interrogazioni che è possibile eseguire. I beacon standard utilizzano espressioni di filtro per eseguire ricerche di uguaglianza. I beacon composti combinano stringhe letterali in chiaro e beacon standard per eseguire query complesse. Quando si interrogano dati crittografati, si esegue la ricerca in base al nome del beacon. Non è possibile confrontare i valori di due beacon standard, anche se contengono lo stesso testo in chiaro sottostante. I due beacon standard produrranno due tag HMAC diversi per gli stessi valori di testo in chiaro. Di conseguenza, i beacon standard non possono eseguire le seguenti interrogazioni. + `beacon1 = beacon2` + `beacon1 IN (beacon2)` + `value IN (beacon1, beacon2, ...)` + `CONTAINS(beacon1, beacon2)` I beacon composti possono eseguire le seguenti interrogazioni. + `BEGINS_WITH(a)`, dove `a` riflette l'intero valore del campo con cui inizia il faro composto assemblato. Non è possibile utilizzare l'`BEGINS_WITH`operatore per identificare un valore che inizia con una particolare sottostringa. Tuttavia, è possibile utilizzare`BEGINS_WITH(S_)`, where `S_` riflette il prefisso per una parte con cui inizia il faro composto assemblato. + `CONTAINS(a)`, dove `a` riflette l'intero valore di un campo contenuto nel beacon composto assemblato. Non è possibile utilizzare l'`CONTAINS`operatore per identificare un record che contiene una particolare sottostringa o un valore all'interno di un set. Ad esempio, non è possibile eseguire un'interrogazione `CONTAINS(path, "a"` in cui `a` rifletta il valore in un set. + È possibile confrontare [parti firmate](configure-beacons.md#signed-parts) di beacon composti. Quando si confrontano parti firmate, è possibile aggiungere facoltativamente il prefisso di una [parte crittografata](configure-beacons.md#encrypted-parts) a una o più parti firmate, ma non è possibile includere il valore di un campo crittografato in nessuna query. Ad esempio, è possibile confrontare parti firmate ed eseguire una query su o. `signedField1 = signedField2` `value IN (signedField1, signedField2, ...)` È inoltre possibile confrontare le parti firmate e il prefisso di una parte crittografata mediante interrogazione su`signedField1.A_ = signedField2.B_`. + `field BETWEEN a AND b`, dove `a` e `b` sono le parti firmate. È possibile aggiungere facoltativamente il prefisso di una parte crittografata a una o più parti firmate, ma non è possibile includere il valore di un campo crittografato in nessuna query. È necessario includere il prefisso per ogni parte inclusa in una query su un beacon composto. Ad esempio, se avete creato un beacon composto a partire da due campi `encryptedField` e `compoundBeacon``signedField`, dovete includere i prefissi configurati per queste due parti quando interrogate il beacon. ``` compoundBeacon = E_encryptedFieldValue.S_signedFieldValue ``` # Crittografia ricercabile per database multitenant **** | | | --- | | La nostra libreria di crittografia lato client è stata rinominata Database Encryption SDK. AWS Questa guida per sviluppatori fornisce ancora informazioni sul [DynamoDB Encryption Client](legacy-dynamodb-encryption-client.md). | [Per implementare la crittografia ricercabile nel database, è necessario utilizzare un portachiavi gerarchico AWS KMS .](use-hierarchical-keyring.md) Il portachiavi AWS KMS gerarchico genera, crittografa e decrittografa le chiavi dati utilizzate per proteggere i record. Crea anche la chiave beacon utilizzata per generare beacon. Quando si utilizza il portachiavi AWS KMS Hierarchical con database multitenant, esistono una chiave branch e una chiave beacon distinte per ogni tenant. Per interrogare i dati crittografati in un database multitenant, è necessario identificare i materiali chiave del beacon utilizzati per generare il beacon su cui si sta interrogando. Per ulteriori informazioni, consulta [Utilizzo del portachiavi gerarchico per una crittografia ricercabile](use-hierarchical-keyring.md#searchable-encryption-hierarchical-keyrings). Quando definisci la [versione beacon](using-beacons.md#beacon-version) per un database multitenant, specifica un elenco di tutti i beacon standard che hai configurato, un elenco di tutti i beacon composti che hai configurato, una versione beacon e un. `keySource` È necessario [definire la fonte della chiave beacon](use-hierarchical-keyring.md#beacon-key-source) come e includere a) un `MultiKeyStore` tempo di permanenza della cache per la cache della chiave beacon locale e la dimensione massima della cache per la cache locale delle chiavi beacon. `keyFieldName` Se hai configurato dei [beacon firmati](configure.md#signed-beacons), questi devono essere inclusi nel tuo. `compoundBeaconList` 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` ------ #### [ Java ] ``` List beaconVersions = new ArrayList<>(); beaconVersions.add( BeaconVersion.builder() .standardBeacons(standardBeaconList) .compoundBeacons(compoundBeaconList) .version(1) // MUST be 1 .keyStore(branchKeyStoreName) .keySource(BeaconKeySource.builder() .multi(MultiKeyStore.builder() .keyFieldName(keyField) .cacheTTL(6000) .maxCacheSize(10) .build()) .build()) .build() ); ``` ------ #### [ C\$1 / .NET ] ``` var beaconVersions = new List { new BeaconVersion { StandardBeacons = standardBeaconList, CompoundBeacons = compoundBeaconList, EncryptedParts = encryptedPartsList, SignedParts = signedPartsList, Version = 1, // MUST be 1 KeyStore = branchKeyStoreName, KeySource = new BeaconKeySource { Multi = new MultiKeyStore { KeyId = branch-key-id, CacheTTL = 6000, MaxCacheSize = 10 } } } }; ``` ------ #### [ Rust ] ``` let beacon_version = BeaconVersion::builder() .standard_beacons(standard_beacon_list) .compound_beacons(compound_beacon_list) .version(1) // MUST be 1 .key_store(key_store.clone()) .key_source(BeaconKeySource::Multi( MultiKeyStore::builder() // `keyId` references a beacon key. // For every branch key we create in the keystore, // we also create a beacon key. // This beacon key is not the same as the branch key, // but is created with the same ID as the branch key. .key_id(branch_key_id) .cache_ttl(6000) .max_cache_size(10) .build()?, )) .build()?; let beacon_versions = vec![beacon_version]; ``` ------ **keyFieldName** [`keyFieldName`](use-hierarchical-keyring.md#keyFieldName)definisce il nome del campo che memorizza la chiave beacon `branch-key-id` associata alla chiave beacon utilizzata per generare i beacon per un determinato tenant. Quando si scrivono nuovi record nel database, la chiave `branch-key-id` che identifica la chiave beacon utilizzata per generare i beacon per quel record viene memorizzata in questo campo. Per impostazione predefinita, `keyField` è un campo concettuale che non è memorizzato in modo esplicito nel database. [Il AWS Database Encryption SDK identifica la `branch-key-id`[chiave dei dati](concepts.md#data-key) crittografati nella [descrizione del materiale](concepts.md#material-description) e memorizza il valore concettuale `keyField` a cui potete fare riferimento nei beacon composti e nei beacon firmati.](configure.md#signed-beacons) Poiché la descrizione del materiale è firmata, la parte concettuale è considerata una parte firmata. `keyField` Puoi anche includerlo `keyField` nelle tue azioni crittografiche come `SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT` campo `SIGN_ONLY` or per memorizzare esplicitamente il campo nel tuo database. Se si esegue questa operazione, è necessario includerli manualmente `keyField` ogni volta che si scrive un record `branch-key-id` nel database. ## Interrogazione dei beacon in un database multi-tenant Per interrogare un beacon, è necessario includere `keyField` nella query i materiali chiave del beacon appropriati necessari per ricalcolare il beacon. È necessario specificare la chiave `branch-key-id` associata alla chiave beacon utilizzata per generare i beacon per un record. Non è possibile specificare il [nome descrittivo](use-hierarchical-keyring.md#branch-key-id-supplier) che identifica il fornitore dell'ID della chiave di filiale di `branch-key-id` un tenant. Puoi includerli `keyField` nelle tue domande nei seguenti modi. **Fari composti** Che li memorizziate esplicitamente o meno `keyField` nei vostri archivi, potete includerli `keyField` direttamente nei vostri beacon compositi come parte firmata. La parte `keyField` firmata deve essere obbligatoria. Ad esempio, se si desidera creare un faro composto da due campi `encryptedField` e `compoundBeacon``signedField`, è necessario includerlo anche `keyField` come parte firmata. Ciò consente di eseguire la seguente interrogazione su. `compoundBeacon` ``` compoundBeacon = E_encryptedFieldValue.S_signedFieldValue.K_branch-key-id ``` **Fari firmati** Il AWS Database Encryption SDK utilizza beacon standard e composti per fornire soluzioni di crittografia ricercabili. Questi beacon devono includere almeno un campo crittografato. Tuttavia, AWS Database Encryption SDK supporta anche [beacon firmati](configure.md#signed-beacons) che possono essere configurati interamente da testo e campi in chiaro. `SIGN_ONLY` `SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT` I beacon firmati possono essere costruiti da un'unica parte. Indipendentemente dal fatto che lo memorizziate esplicitamente `keyField` nei vostri archivi o meno, potete costruire un beacon firmato da `keyField` e utilizzarlo per creare query composte che combinano una query sul beacon `keyField` firmato con una query su uno degli altri beacon. Ad esempio, è possibile eseguire la seguente query. ``` keyField = K_branch-key-id AND compoundBeacon = E_encryptedFieldValue.S_signedFieldValue ``` Per informazioni sulla configurazione dei beacon firmati, vedere [Creazione di beacon firmati](configure.md#signed-beacons) **Effettua una query direttamente su `keyField`** Se hai specificato il `keyField` nelle tue azioni crittografiche e lo hai archiviato in modo esplicito nel tuo record, puoi creare una query composta che combina una query sul tuo beacon con una query su. `keyField` Puoi scegliere di interrogare direttamente su `keyField` se desideri interrogare un beacon standard. Ad esempio, è possibile eseguire la seguente query. ``` keyField = branch-key-id AND standardBeacon = S_standardBeaconValue ```