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

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. Quando scrivi un valore in un campo crittografato configurato per la crittografia ricercabile, Database Encryption SDK calcola un HMAC sul valore di testo in chiaro AWS . Questo output HMAC corrisponde uno a uno (1:1) per il valore di testo in chiaro di quel campo. L'SDK tronca intenzionalmente l'output HMAC in modo che più valori di testo in chiaro distinti si scontrino sullo stesso beacon. Queste collisioni (falsi positivi) limitano la capacità di un utente non autorizzato di dedurre informazioni sensibili dai modelli di frequenza. 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. Per risolvere ulteriormente questo problema di dispersione di frequenza, i beacon vengono partizionati, in modo da consentire a valori di testo in chiaro identici di produrre valori beacon diversi tra le partizioni. Quando la tabella utilizza solo una singola partizione, questo comportamento corrisponde naturalmente ai beacon tradizionali non partizionati.

Il numero medio di falsi positivi per ogni beacon dipende dalla lunghezza residua del beacon dopo il troncamento e dal numero di partizioni. Per informazioni sulla determinazione della lunghezza del beacon appropriata per l'implementazione, consulta Determinazione della lunghezza del beacon.

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. Una corretta configurazione dei beacon è essenziale per mitigare questi rischi. La scelta della lunghezza e dello schema di partizionamento del faro appropriati preserva la riservatezza garantendo un numero sufficiente di collisioni e mitigando gli attacchi basati sulla frequenza limitando la concentrazione dei valori in ogni singolo beacon.

In molti scenari pratici, una configurazione ben scelta può bilanciare questi obiettivi contrastanti. Tuttavia, la crittografia ricercabile potrebbe non essere in grado di fornire i livelli desiderati di sicurezza e prestazioni per ogni set di dati.

Prima di configurare qualsiasi beacon, esamina attentamente il modello di minaccia, i requisiti di sicurezza e le esigenze prestazionali e considera le caratteristiche di unicità del set di dati per determinare se la crittografia ricercabile è una scelta appropriata.

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 che scegli di rendere beaconizzati e determina la quantità di troncamento necessaria per soddisfare i tuoi requisiti di sicurezza. Gli argomenti seguenti di questo capitolo presuppongono che, all'interno di ogni partizione, i valori dei beacon siano distribuiti uniformemente e che i dati sottostanti non introducano correlazioni che indebolirebbero questi presupposti.

Scenario di crittografia ricercabile

L'esempio seguente illustra una soluzione di crittografia ricercabile e illustra i concetti fondamentali discussi in questo capitolo. In questo scenario, alcuni valori di campo si verificano molto frequentemente, il che porterebbe a classi di equivalenza ampie e a una maggiore dispersione di frequenza se si utilizzasse una singola partizione. Per risolvere questo problema, la configurazione utilizza più partizioni in modo che i valori più frequenti vengano distribuiti in modo più uniforme, riducendo le perdite e preservando la capacità di eseguire ricerche di uguaglianza efficienti.

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 LastNameFirstName, 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, 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 denominato LastNameper mappare i valori in chiaro scritti nel LastName campo ai valori crittografati memorizzati nel database.

Questo beacon calcola gli HMAC a partire dai valori in chiaro presenti nel 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

In un set di dati con molti dipendenti, alcuni cognomi come Jones, Smith o Johnson possono comparire molto più frequentemente di altri. Per ridurre la dispersione di frequenza e limitare la dimensione delle classi di equivalenza dei beacon, è necessario configurare il LastNamebeacon in modo che utilizzi più di una partizione.

Quando le partizioni sono abilitate, ogni elemento viene assegnato a una partizione in fase di scrittura e il numero di partizione viene incorporato nella derivazione del beacon. Di conseguenza, i dipendenti con lo stesso cognome possono mappare valori beacon diversi tra le partizioni. Ciò distribuisce nomi molto frequenti su più partizioni, riducendo la sovrarappresentazione di ogni singolo valore del beacon.

Dopo aver configurato il beacon standard, è possibile eseguire ricerche di uguaglianza sul campo. LastName Ad esempio, se desideri cercareJones, usa il LastNamebeacon per eseguire la seguente query.

LastName = Jones

Quando si esegue una query per uno specifico cognome ad alta frequenza, ad esempio Jones, l'applicazione deve emettere una query per partizione utilizzando il beacon. LastName Il AWS Database Encryption SDK decripta quindi i risultati e filtra automaticamente i falsi positivi, restituendo i record di testo in chiaro corretti.