Perché dovrei usare la crittografia a riposo sulla crittografia basata su chiave di un DB?

Question

Perché dovrei usare la crittografia a riposo sulla crittografia basata su chiave di un DB?

Naviga le tue risposte

#1 da (2 voti)

8

Obiettivo

Voglio memorizzare i dati crittografati in un database.

Vincoli

La crittografia a livello di applicazione (la crittografia prima di inviare al DB) non è un'opzione ragionevole per il mio caso d'uso.
I fornitori di DB che sto considerando non mi consentono di creare più utenti / gestire i permessi al prezzo che pagherò. Ciò significa che la separazione delle autorizzazioni per i registri rispetto a letture e scritture non è un'opzione.

Opzioni

Permetti a MySQL di gestire la crittografia AES (tramite aes_encrypt/decrypt ) per me (sono a conoscenza del problema del blocco della BCE e del fatto che MySQL registra dati sensibili in testo normale se non configurato correttamente)
Utilizza un provider DB che offre la crittografia a riposo (il tipo che avviene in modo trasparente - cripta automaticamente su SET e decrittala su SELECT )

Domande

Domanda 1

Perché dovrei mai scegliere questo tipo di crittografia a riposo su aes_encrypt ? (Come nota, non sto memorizzando informazioni sulla carta di credito o qualsiasi altra cosa che mi incoraggerebbe a criptare legalmente a riposo).

A quanto ho capito, il punto di crittografia dei dati nel database è quello di affrontare la realtà che le violazioni DB avvengono. Con questo in mente, se qualcuno ottiene l'accesso al mio DB (nel senso che possono eseguire query), questo tipo di crittografia in realtà non li aiuterebbe in quanto sarebbe semplicemente decrittografare i dati quando SELECT ? Mi sembra che stia rallentando le query senza aggiungere sicurezza.

aes_decrypt , d'altra parte, richiede che l'intruso abbia accesso a una chiave memorizzata su una macchina diversa dietro credenziali diverse. Non è più sicuro?

Domanda 2

Nello scenario descritto nella domanda 1, un utente malintenzionato ha ottenuto l'accesso alla query a un DB. Se è così, non potrebbero semplicemente abilitare la registrazione e recuperare il tasto AES in testo semplice, rendendo anche aes_encrypt inutile?

(Ricordare il numero 2 qui.)

Domanda 3

Escludendo l'iniezione sql, ci sono altri scenari in cui un utente malintenzionato sarebbe in grado di visualizzare ciò che è nel mio database senza eseguire un SELECT e quindi senza attivare una decrittazione trasparente a riposo?

raccomandazioni?

Se hai qualche suggerimento che si adatta ai miei limiti, fammelo sapere. Grazie!

mysql encryption aes databases

posta jpodwys 12.05.2016 - 21:27

fonte

1 risposta

Leggi altre domande sui tag mysql encryption aes databases

Tails Il sistema operativo non cancella la memoria video Problemi nella creazione di una catena ROP

score 2 · Answer 1

Crittografia trasparente o manuale

La crittografia trasparente può essere più semplice e sicura, poiché il provider è responsabile della gestione delle chiavi. Per loro questo è solo un altro dovere operativo, insieme a backup, monitoraggio e replica e così via.

È molto facile rovinare la gestione delle chiavi, dalla scelta delle chiavi sbagliate alla loro perdita, fino alla loro esposizione a non riuscire a ruotarle correttamente, proprio come è facile rovinare altre attività operative. E come con i backup, se le chiavi vengono perse, i dati vengono persi. Quali problemi si vuole spendere il proprio tempo risolvendo?

In termini di scenari di attacco, ci sono molti aspetti da considerare: gli hacker potrebbero avere la possibilità di monitorare passivamente il traffico sulla rete tra l'applicazione e il database; potrebbe avere la capacità di leggere i dati dai sistemi di file dell'applicazione o del database; potrebbe avere accesso ai dischi fisici; potrebbe avere accesso alle credenziali dell'account; potrebbe avere una webshell che opera nell'applicazione. Nella maggior parte degli scenari, la crittografia trasparente e manuale sono ugualmente vulnerabili.

È certamente possibile che un utente malintenzionato abbia accesso alle credenziali del database ma non all'applicazione, quindi c'è potenzialmente un ulteriore ostacolo da superare nel caso di crittografia manuale. Ma qualcuno che fa la crittografia manuale deve aver fatto un sacco di cose giuste, e un aggressore determinato con accesso ai dati crittografati ha molti potenziali percorsi da seguire. Il numero di violazioni dei dati in cui i dati sono stati segnalati come crittografati o sottoposti a hash ma successivamente esposti non è numerabile.
Accesso alle query e registrazione delle query

L'accesso all'interrogazione a un database non corrisponde all'accesso amministrativo, che di solito è necessario per abilitare la registrazione. Tuttavia, quando si parla specificamente delle offerte dei provider, le credenziali per l'accesso alle query possono forse anche essere utilizzate per configurare alcuni pannelli di controllo dal provider, il che probabilmente consentirebbe l'abilitazione di alcuni tipi di registrazione delle query.

Ma fai un passo indietro - nel caso comune, l'impatto di un utente malintenzionato che accede al database, in particolare l'accesso in scrittura, non cambia a seconda che i dati siano crittografati o meno. Prendendo una pagina da attacchi ransomware, potrebbero eseguire il proprio "UPDATE $ table SET $ encrypted_column = aes_encrypt (encrypted_column, 'attacker-key');" e richiedere la chiave di decifrazione della vittima, o solo denaro, per restituire la custodia dei dati crittografati.
Accesso ai dati al di fuori di SQL injection o del motore di query

Come sopra, ci sono molti scenari in cui un utente malintenzionato può vedere cosa c'è nel database senza passare attraverso il motore di ricerca. Qualcuno potrebbe avere visibilità sulla rete. Qualcuno potrebbe essere in grado di vedere i file di dati che sta usando il database. Qualcuno potrebbe essere in grado di raggiungere i dischi fisici quando vengono messi fuori servizio. Qualcuno potrebbe essere in grado di accedere ai backup. Tutte queste cose accadono ogni giorno.

Raccomandazione: assente un requisito per la crittografia a riposo e scenari specifici che devono essere difesi e che richiedono una gestione o considerazione speciale, è sufficiente lasciare che il provider esegua lo spettacolo.