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