Se devo memorizzare diversi tipi di dati sensibili, diciamo: campo1 nella tabella A e campo2 nella tabella B e i dati non sono correlati, dovrei usare una chiave diversa per ogni campo?
Aggiungi informazioni 1: La crittografia / decodifica sta per essere eseguita nel codice dell'applicazione e il database memorizzerà solo i dati crittografati.
Aggiungi informazioni 2: Al momento, sto pensando di utilizzare AES-256-CBC e il database è MongoDB.
Sulla base delle informazioni fornite nell'aggiornamento, suggerirei di utilizzare la stessa chiave per ogni campo. Le chiavi diverse potrebbero essere eccessive, in quanto potresti voler crittografare anche altri campi, inoltre sarebbe scomodo mappare i campi con chiavi diverse.
I seguenti punti possono essere considerati con questo approccio:
Modifica 1:
Dipende.
In generale, il motivo principale per l'utilizzo di chiavi diverse è: potresti voler fornire parti diverse dei dati a diversi sottosistemi. Se ci sono alcune colonne elaborate da un sistema A e alcune colonne elaborate da un sistema B, potresti voler usare chiavi diverse per questi gruppi di colonne. (Questa considerazione può essere applicata anche se un sottosistema ha bisogno di accedere a tutte le colonne e un altro a solo alcuni.)
Se, tuttavia, tutta l'elaborazione avviene all'interno di un singolo sottosistema - vale a dire, tutte le chiavi sono distribuite insieme e tutte le parti dei dati sono sempre decifrate insieme -, la gestione di chiavi separate non sarà molto utile in termini di il mantenimento della riservatezza e i benefici quasi zero saranno probabilmente superati dai costi di una complessità extra.
Quindi, questo è l'asse dello spazio. Tuttavia, a seconda del contesto, potrebbe essere necessario considerare anche l'asse temporale, in cui le chiavi di crittografia possono cambiare nel tempo e / o i dati crittografati con chiavi diverse potrebbero dover essere conservati nelle stesse colonne . Ad esempio, una combinazione di una politica di modifica periodica della chiave di crittografia e dei costi di decrittografia e ricodifica di una grande serie di dati potrebbe richiedere la protezione dell'aspetto accessibilità della sicurezza dei dati eseguendo la ri-crittografia processo con piccoli passaggi, il che significa che durante il passaggio all'euro, il tuo sistema potrebbe incontrare sia i dati crittografati con la vecchia chiave che scadono, sia i dati crittografati con quello nuovo rilasciato di recente.
Tornando a ciò che hai chiesto - è piuttosto insolito che un database strutturato non sia considerato attendibile per avere accesso ai dati al suo interno, quindi non ci sono best practice consolidate per questo tipo di situazioni. È più comune eseguire l'intero database su un'archiviazione di dati crittografati, solitamente sotto forma di un file system di qualche tipo, o in alternativa trattare il database come una sorta di dispositivo a blocchi, servendo solo blob crittografati opachi il cui intero significato sarà quindi determinato nella parte del sistema di cui ti fidi abbastanza per avere le chiavi di crittografia. Analizza, ad esempio, che tipo di attacchi potenziali vuoi proteggere contro il tuo sistema. Se sei preoccupato che un utente malintenzionato sia in grado di leggere i dati dal tuo database, dovresti anche preoccuparti che l'autore dell'attacco possa essere in grado di inserire dati fasulli, possibilmente dati che potrebbe non comprendere, nel tuo database, o sostituire buoni dati con dati errati o spazzatura?
Leggi altre domande sui tag encryption databases