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

Scelta della lunghezza e delle partizioni del faro

Quando scrivi un nuovo valore in un campo crittografato configurato per la crittografia ricercabile, AWS Database Encryption SDK calcola un valore HMAC sul valore di testo semplice combinato con un identificatore di partizione. All'interno di una determinata partizione, l'HMAC completo rappresenta in modo univoco il valore in chiaro. L'SDK tronca quindi l'output HMAC in modo che più valori di testo in chiaro distinti possano essere mappati sullo stesso beacon. Queste collisioni, note anche come falsi positivi, limitano la capacità di un utente non autorizzato di dedurre informazioni distintive sul testo in chiaro sottostante.

Il numero medio di falsi positivi generati per ogni beacon è determinato dalla lunghezza del beacon rimanente dopo il troncamento e dal numero di partizioni in uso. È 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. Distribuendo i valori su più partizioni, le collisioni vengono mantenute all'interno di ciascuna partizione, il che aiuta a ridurre la concentrazione di frequenza preservando al contempo il corretto comportamento delle query.

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. Le lunghezze dei beacon più brevi e le partizioni aggiuntive aumentano le collisioni e riducono la dispersione di frequenza, mentre lunghezze dei beacon più lunghe e un numero inferiore di partizioni migliorano la precisione delle query.

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 lunghezza dei beacon e del numero di partizioni appropriati aiuta a mitigare questi rischi e a preservare la riservatezza dei dati.

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. L'aumento della riservatezza richiede in genere la generazione di più falsi positivi, tramite beacon di lunghezza inferiore, partizioni aggiuntive o entrambi, il che a sua volta può ridurre le prestazioni delle query.

Scelta di uno schema di partizionamento

Lo schema di partizionamento determina come gli elementi vengono distribuiti tra le partizioni quando vengono derivati i beacon. La scelta di uno schema appropriato è importante per bilanciare privacy, prestazioni e prevedibilità operativa.

Quando selezionate uno schema di partizionamento, considerate i seguenti obiettivi:

Distribuzione casuale predefinita

L'impostazione predefinita consigliata è uno schema di distribuzione casuale. In questo modello, ogni elemento viene assegnato a una partizione utilizzando un valore casuale crittograficamente sicuro. La distribuzione casuale produce partizioni di dimensioni approssimativamente uguali nel tempo e garantisce che i valori frequenti siano distribuiti uniformemente.

Usa la distribuzione casuale quando:

Distribuzione deterministica

In alcuni casi, l'assegnazione delle partizioni deve essere deterministica. Uno schema deterministico assegna le partizioni in base a una funzione stabile degli attributi degli elementi. Questi schemi devono essere progettati con cura, poiché input distorti o sensibili possono causare un partizionamento irregolare o una perdita involontaria di informazioni.

Usa la distribuzione deterministica quando:

Gestione di valori caldi noti

Se il set di dati contiene valori caldi noti, puoi combinare strategie casuali e deterministiche. Ad esempio, potreste distribuire in modo casuale un piccolo set di valori ad alta frequenza assegnando tutti gli altri valori in modo deterministico.

Questo approccio riduce la concentrazione per i valori caldi preservando al contempo un comportamento prevedibile per il resto del set di dati. Poiché introduce ulteriore complessità, esaminatelo attentamente per evitare fughe involontarie di informazioni.

Esempi di schemi di partizionamento

Gli esempi seguenti illustrano gli schemi di partizionamento più comuni e mostrano come le diverse caratteristiche dei dati influenzano l'assegnazione delle partizioni. Ogni esempio dimostra come bilanciare privacy, prestazioni e semplicità operativa.

Esempio 1: dati distribuiti uniformemente

Stai creando un beacon per i numeri di telefono e i valori nel tuo set di dati sono distribuiti approssimativamente in modo uniforme. Nessun numero di telefono appare molto più spesso di altri.

In questo caso, è sufficiente configurare una singola partizione. Le partizioni aggiuntive offrono pochi vantaggi e non farebbero che aumentare il fan-out delle query.

Esempio 2: risultati binari con frequenza distorta

Hai un database che memorizza i risultati dei test medici con due valori possibili: NEGATIVO e POSITIVO. I risultati NEGATIVI si verificano circa cinque volte più spesso dei risultati POSITIVI.

Per ridurre la dispersione di frequenza, utilizzate una strategia mista:

Questo approccio distribuisce il valore sovrarappresentato mantenendo stabile il valore più raro, riducendo le grandi classi di equivalenza senza inutili fan-out.

Esempio 3: valori caldi noti in un dominio di grandi dimensioni

Hai un database di nomi negli Stati Uniti d'America. Un insieme relativamente piccolo di nomi comuni (ad esempio, i primi 500 nomi più frequenti) appare molto più spesso degli altri.

Questo approccio ibrido mira a valori caldi noti mantenendo il partizionamento semplice e prevedibile per la maggior parte dei nomi.

Questi esempi mostrano come gli schemi di partizionamento possono essere adattati alle diverse caratteristiche dei dati. Nella maggior parte dei casi, la distribuzione casuale è sufficiente, ma l'integrazione della conoscenza del dominio può migliorare ulteriormente la privacy e le prestazioni se applicata con attenzione.

Calcolo della lunghezza del faro

La lunghezza del beacon è specificata in bit e determina quanti bit dell'uscita HMAC vengono conservati dopo il troncamento. La lunghezza consigliata dipende dalla modalità di distribuzione dei valori all'interno di ciascuna partizione, dal fatto che i dati contengano valori correlati e dai requisiti di sicurezza e prestazioni. Quando un set di dati è approssimativamente uniforme dopo l'applicazione di uno schema di partizionamento appropriato, è possibile utilizzare semplici equazioni e procedure di regolazione per stimare la lunghezza effettiva del beacon. Queste equazioni forniscono una stima del numero medio di falsi positivi che un beacon può produrre, ma non garantiscono un numero specifico di falsi positivi per ogni valore univoco del set di dati. Il primo passo è quello di stimare la popolazione.

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.

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.

La tua popolazione non deve essere 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.

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.

Calcolo della lunghezza del faro in base alla dimensione della popolazione

Quando i dati sono distribuiti approssimativamente in modo uniforme all'interno di ogni partizione e non contengono valori correlati, è possibile stimare la lunghezza del beacon appropriata utilizzando una semplice formula basata sulla popolazione.

Sia p la dimensione della popolazione del beacon, ovvero il numero di valori di testo in chiaro distinti da cui il beacon è costruito all'interno di una singola partizione. Un punto di partenza comune per la lunghezza del beacon b (in bit) è:

b = log₂(p) − 1
  

Questa formula preserva una probabilità non trascurabile di collisioni mantenendo gestibile il numero di falsi positivi. La sottrazione di un bit dal logaritmo garantisce che più valori distinti vengano mappati allo stesso beacon, il che aiuta a limitare la dispersione di frequenza e supporta l'anonimato.

Questo calcolo fornisce una stima del comportamento medio di collisione nel set di dati. Non garantisce che ogni valore produca lo stesso numero di falsi positivi, né tiene conto di distribuzioni distorte, valori correlati o modelli di dati contraddittori.

Utilizza questa formula come linea guida iniziale anziché come requisito rigoroso. Convalida sempre la configurazione risultante rispetto al modello di minaccia, alle aspettative prestazionali e alle caratteristiche dei dati osservati e regola la lunghezza del beacon o il numero di partizioni in base alle esigenze.

Argomento avanzato sulla lunghezza dei beacon

In qualità di utente esperto, hai una maggiore flessibilità nella scelta della lunghezza del faro appropriata per la tua soluzione. È necessario scegliere una lunghezza che protegga adeguatamente la riservatezza dei dati riducendo al minimo qualsiasi impatto non necessario sulle prestazioni delle query. Il livello di sicurezza garantito da un beacon dipende dalla distribuzione del set di dati e dalla correlazione dei campi da cui sono costruiti i beacon.

Se il set di dati è distribuito approssimativamente in modo uniforme, è possibile utilizzare le seguenti equazioni e procedure per stimare la lunghezza del beacon appropriata per l'implementazione. Queste equazioni forniscono una stima del numero medio di falsi positivi che un beacon può produrre, ma non garantiscono un numero specifico di falsi positivi per ogni valore univoco del set di dati. Gli argomenti seguenti presuppongono che i beacon siano distribuiti uniformemente e non contengano dati correlati.

Esempio di lunghezza del beacon avanzata

Consideriamo un database che ha contrassegnato il unit campo come ENCRYPT_AND_SIGN nelle azioni crittografiche. 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