Pensieri sulla strategia di crittografia dei dati per un numero elevato di record MongoDB e Azure Key Vault

0

In precedenza ho implementato la crittografia dei dati lato client utilizzando Azure Key Vault utilizzando il seguente approccio:

Approccio alla crittografia:

  1. Ogni record che deve essere crittografato ottiene una Content Encryption Key (CEK)
  2. Il contenuto è crittografato simmetricamente usando questo CEK.
  3. Il CEK viene quindi crittografato in modo asimmetrico utilizzando una chiave master memorizzata in Azure Key Vault.
  4. 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:

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

  2. Stabilisci una volta CEK per il cliente e usalo per tutti i record.

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

    
posta Anup Marwadi 27.01.2018 - 05:53
fonte

1 risposta

0

L'opzione 1 che hai suggerito sembra un approccio ragionevole. Quando abbiamo avuto un problema molto simile (tecnologie diverse, ma lo stesso modello di chiave crittografato) abbiamo fornito dati che sono stati sempre interrogati insieme allo stesso CEK (nel nostro caso i dati per un utente). Abbiamo usato un microcache per contenere i CEK. Fondamentalmente abbiamo memorizzato nella cache ogni CEK con una scadenza di soli 15 secondi, poiché la maggior parte delle volte usavamo la chiave in un breve periodo di tempo, quindi non del tutto.

Raccomando anche di fare tutto il possibile nella memoria cache dei dati decrittografati. In generale, i dati in memoria sono in modo affidabile inaccessibili ad altre applicazioni, purché non si utilizzi una sorta di strumento di memorizzazione nella cache condiviso. A seconda del tuo caso d'uso, potresti essere in grado di conservare in modo permanente una parte considerevole del tuo data set di lavoro in memoria.

    
risposta data 29.01.2018 - 15:35
fonte

Leggi altre domande sui tag