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à.
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. |
Un beacon è un tag HMAC ( Hash-Based Message Authentication Code) troncato che associa il valore di un campo di testo semplice a un identificatore crittografato e ricercabile memorizzato insieme ai dati crittografati nel database. Il beacon non altera lo stato crittografato del campo. Quando scrivi un valore in un campo configurato per la crittografia ricercabile, l'SDK AWS Database Encryption calcola un HMAC sul valore di testo in chiaro e ricava il beacon nel contesto di una partizione. L'HMAC completo corrisponde in modo univoco al valore di testo in chiaro, ma l'SDK tronca intenzionalmente l'output in modo che più valori di testo in chiaro distinti possano essere mappati sullo stesso beacon. Queste collisioni (falsi positivi) limitano la capacità di un utente non autorizzato di dedurre informazioni distintive sul testo in chiaro sottostante.
Nota
Un Hash-based Message Authentication Code (HMAC) è una funzione hash crittografica con chiave comunemente utilizzata per fornire integrità e autenticità. Nei sistemi di crittografia ricercabili, l'HMAC viene spesso utilizzato per derivare in modo deterministico i beacon da valori di testo in chiaro in modo che possano essere indicizzati e interrogati.
Un HMAC completo è deterministico: per una determinata chiave, lo stesso valore di testo in chiaro produce sempre lo stesso beacon. Questo determinismo si traduce in una mappatura individuale tra valori in chiaro e beacon, preservando la distribuzione di frequenza originale dei dati. Tutti i record che condividono lo stesso valore in chiaro vengono mappati sullo stesso beacon e quindi formano una classe di equivalenza. La dimensione di ogni classe di equivalenza riflette direttamente la frequenza con cui il valore di testo in chiaro corrispondente appare nel set di dati.
Questa conservazione della frequenza consente attacchi di analisi della frequenza, in cui un osservatore deduce probabili valori in chiaro correlando le frequenze dei beacon osservate con distribuzioni di dati note o previste.
Per mitigare gli attacchi di analisi della frequenza, l'SDK ricava i beacon utilizzando il troncamento e il partizionamento. Il troncamento dell'HMAC introduce collisioni controllate, in modo che non tutti i record all'interno di una classe di equivalenza condividano necessariamente lo stesso valore di beacon. Inoltre, l'incorporazione di un identificatore di partizione nella derivazione dei beacon consente di mappare valori di testo in chiaro identici a beacon diversi tra le partizioni. Insieme, queste tecniche promuovono una maggiore casualità per i set di dati distribuiti in modo non uniforme, preservando al contempo un comportamento di interrogazione corretto ed efficiente.
I beacon possono essere creati solo a partire da campi contrassegnati o nelle azioni ENCRYPT_AND_SIGN crittograficheSIGN_ONLY. SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT Il beacon stesso non è firmato o crittografato. Non è possibile costruire un beacon con campi contrassegnati. DO_NOTHING
Dopo aver configurato i beacon, è 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.
Comprendere la derivazione dei beacon tra le partizioni
Il partizionamento è una parte fondamentale della configurazione dei beacon e si applica a tutti i beacon, compresi quelli che utilizzano una singola partizione. Questo modello garantisce una derivazione dei beacon coerente e compatibile con il futuro su tutti i dati e consente di aumentare il numero di partizioni nel tempo al variare del volume o della distribuzione dei dati. In questo modo, è possibile ridurre le perdite di frequenza e rafforzare le protezioni per i set di dati distribuiti in modo non uniforme senza riscrivere gli elementi esistenti.
Le partizioni introducono la casualità controllata distribuendo gli elementi su più gruppi logici. Ciò riduce la dispersione di frequenza, limita la dimensione delle classi di equivalenza dei beacon e migliora la sicurezza e la privacy per gli attributi con distribuzioni asimmetriche.
Quando un elemento viene assegnato a una partizione, il numero di partizione viene incorporato nella derivazione del beacon. All'interno della stessa partizione, valori di testo in chiaro identici producono lo stesso beacon, preservando la semantica di ricerca dell'uguaglianza. In diverse partizioni, lo stesso valore di testo in chiaro produce valori beacon diversi. Ciò suddivide le grandi classi di equivalenza in gruppi più piccoli per partizione e aiuta ad appiattire la distribuzione complessiva della frequenza dei beacon.
Hai il pieno controllo su come ogni elemento del database viene assegnato a una partizione. Gli elementi possono essere collocati in partizioni specifiche in modo deterministico oppure possono essere distribuiti in modo casuale per facilitare le distribuzioni irregolari dei dati. L'assegnazione casuale è particolarmente utile per i valori ad alta frequenza, perché distribuisce tali valori su più partizioni e riduce la concentrazione visibile in ogni singola partizione. L'assegnazione deterministica può essere utilizzata quando la conoscenza del dominio indica che determinati valori devono essere limitati a un minor numero di partizioni.
L'identificatore di partizione non è esposto nel record crittografato. Il numero di partizione viene invece incorporato nel processo di derivazione del beacon, codificato insieme al valore di testo in chiaro, in modo che non possa essere dedotto esaminando i dati crittografati o il beacon stesso. Questo design garantisce che le assegnazioni delle partizioni rimangano riservate pur continuando a fornire i vantaggi di distribuzione e privacy dei beacon partizionati.
- Impatto del partizionamento sulle interrogazioni
-
Il partizionamento influisce sul modo in cui vengono eseguite le operazioni.
QueryPoiché le query DynamoDB richiedono una corrispondenza esatta sul valore del beacon indicizzato e i valori del beacon differiscono tra le partizioni, il chiamante deve interrogare ogni partizione in modo indipendente. SeNuna tabella ha delle partizioni:-
Il recupero di tutti gli elementi corrispondenti richiede
Ninterrogazioni separate. -
Solo è interessato
Query. -
ScaneGetle operazioni si comportano come prima.
Il motivo è strutturale:
Scanlegge tutti gli elementi eGetopera su una chiave specifica;Querydipende solo dall'esatta uguaglianza nell'indice, che diventa specifico della partizione.Nota
Fan-out si riferisce al numero di query DynamoDB che devono essere emesse per soddisfare una singola richiesta logica quando si utilizzano beacon partizionati. Il sistema fornisce un fan-out limitato, il che significa che il numero massimo di query a livello di partizione è fisso e prevedibile in base al numero di partizioni configurate.
Considerazioni sulle prestazioni
L'utilizzo delle partizioni influisce sul numero di query DynamoDB richieste per richiesta logica. L'impatto sulle prestazioni dipende dalla dimensione prevista del risultato:
-
Set di risultati di grandi dimensioni: quando le query restituiscono molte pagine, le query aggiuntive a livello di partizione aggiungono un sovraccarico minimo.
-
Single-item ricerche: se una richiesta normalmente restituisce un elemento e sono configurate cinque partizioni, vengono emesse cinque query, quattro delle quali non restituiscono risultati, con conseguente rallentamento quasi lineare.
-
Località ridotta: gli elementi possono essere distribuiti tra le partizioni, aumentando il tempo di recupero.
Poiché ogni partizione attiva una query aggiuntiva, il fan-out è un fattore importante nella pianificazione delle prestazioni e della capacità.
Vantaggi prestazionali
Nonostante il sovraccarico di query aggiuntivo, le partizioni possono migliorare le prestazioni in determinati scenari:
-
Riduzione delle classi di equivalenza di grandi dimensioni: quando un valore raro condivide un beacon troncato con un valore ricorrente di frequente, le query relative al valore raro devono elaborare molte corrispondenze irrilevanti. Il partizionamento limita la dimensione di ogni classe di equivalenza e riduce questo sovraccarico.
-
Supporto di beacon di lunghezza maggiore: la configurazione di più partizioni può consentire l'uso di beacon di lunghezza maggiore, il che riduce la frequenza di falsi positivi e la quantità di filtri di post-decrittografia necessari.
-
Tipi di beacon
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.
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 dei beacon standard. Puoi anche usare partizioni con beacon per promuovere la casualità quando i dati sottostanti hanno una distribuzione non uniforme.
Di seguito sono riportati alcuni concetti importanti per i beacon standard.
- Fonte Beacon
-
Il campo da cui è costruito un beacon standard è chiamato sorgente beacon. 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.
È 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_SIGNSIGN_ONLYSIGN_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.
Nota
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 e della correlazione per i beacon.
Ad esempio, se si desidera eseguire ricerche di uguaglianza sulla concatenazione di
LastNamecampiFirstNameand, è possibile creare uno dei seguenti campi virtuali.-
Un
NameTagcampo virtuale, composto dalla prima lettera delFirstNamecampo, seguito dal campo, tutto inLastNameminuscolo. Questo campo virtuale consente di eseguire interrogazioni.NameTag=mjones -
Un
LastFirstcampo virtuale, costruito a partire dalLastNamecampo, seguito dalFirstNamecampo. Questo campo virtuale consente di eseguire interrogazioniLastFirst=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
IPAddresscampo crittografato utilizzando i primi tre segmenti dell'indirizzo IP, crea il seguente campo virtuale.-
Un
IPSegmentcampo virtuale, costruito daSegments(‘.’, 0, 3). Questo campo virtuale consente di eseguire interrogazioniIPSegment=192.0.2. La query restituisce tutti i record con unIPAddressvalore 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 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.
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 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 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 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.
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
