In precedenza ho implementato la crittografia dei dati lato client utilizzando Azure Key Vault utilizzando il seguente approccio:
Approccio alla crittografia:
- Ogni record che deve essere crittografato ottiene una Content Encryption Key (CEK)
- Il contenuto è crittografato simmetricamente usando questo CEK.
- Il CEK viene quindi crittografato in modo asimmetrico utilizzando una chiave master memorizzata in Azure Key Vault.
- Il CEK crittografato, l'identificatore della chiave master e i dati crittografati vengono mantenuti nel database Mongo.
Approccio alla decifrazione: 1. Quando un utente necessita di informazioni decodificate, il CEK crittografato viene prima decrittografato utilizzando la chiave master 2. Il CEK decrittografato viene quindi utilizzato per decodificare simmetricamente i dati crittografati.
Questo approccio funziona alla grande se vuoi decifrare i record un record alla volta.
Questo approccio ha un overhead delle prestazioni quando si considera la decrittografia di 100s di record contemporaneamente.
Per ogni record, è necessario prima decrittografare il CEK. Questa è una chiamata costosa sulla rete che utilizza l'API Azure Key Vault Rest. Immagina qualcuno che voglia esportare migliaia di record decifrati (come nel mio caso ora). Questa non sarebbe solo un'operazione che richiede tempo, ma anche costosa.
Qualcuno ha qualche suggerimento su come farlo? Mi sono dilettato con i seguenti approcci:
-
Stabilire una chiave giornaliera (o mensile) e usarla come CEK per tutti gli ordini del giorno / mese in modo che il numero di CEK da decrittografare diminuisca durante l'esportazione / estrazione dei report per la visualizzazione in massa. Utilizza le strategie di memorizzazione nella cache in memoria per memorizzare i CEK decrittografati e effettua una chiamata di rete solo quando non viene decodificato CEK non trovato nella cache.
-
Stabilisci una volta CEK per il cliente e usalo per tutti i record.
-
Non utilizzare affatto un CEK e semplicemente crittografare tutti i dati utilizzando una chiave master (il suicidio, a mio avviso, poiché la crittografia asimmetrica dei dati di grandi dimensioni non è consigliata affatto) e aumenterà i costi generali.
Ti chiedi se le persone hanno suggerimenti!