Proteggi i dati del database da tutti, inclusi amministratori di sistema, ecc

3

Una delle cose che mi ha sempre infastidito sulla semplice crittografia dei dati del database: se il server viene compromesso, il database viene effettivamente compromesso. L'utente malintenzionato può utilizzare lo stesso codice dell'app per interrogare i dati come desiderato. Una semplice revisione del codice dell'app mostrerà dove / come è memorizzata la chiave e quali sono i parametri di connessione del database.

Naturalmente, la crittografia dei dati può essere utile per la memorizzazione di backup fuori server, ecc., ma a tale scopo i file di backup potrebbero essere crittografati interamente, anziché i campi, risparmiando qualche mal di testa con le query, ecc.

In generale, accertarsi che il server sia sicuro è la procedura migliore. Ma, cosa succede se i dati devono essere protetti da tutti, inclusi gli amministratori di sistema (proprio come il modo in cui trattiamo le password degli utenti, attraverso l'hashing)?

In definitiva, mi chiedo, come può essere protetta una chiave di crittografia, in modo che non sia accessibile da chiunque senza il segreto, anche il codice dell'applicazione. L'unico approccio che posso pensare è che la chiave deve essere fornita dall'utente in fase di esecuzione (non è persistente sulla macchina host, punto).

Immagino che il primo problema è che se un utente ha accesso al server, probabilmente c'è un modo in cui il segreto potrebbe essere annusato al punto di entrata, o se la chiave è archiviata in memoria dall'app (ad es. una variabile di sessione) potrebbe essere probabilmente sfruttata anche.

Quali sono gli altri problemi (probabilmente evidenti) con questo approccio? Sta solo reinventando la ruota? In tal caso, qual è la migliore pratica quando la sicurezza dei dati è fondamentale, anche dai ruoli di super utente?

Questa domanda potrebbe essere in qualche modo simile a: Come accedere e crittografare i dati con la stessa password / chiave , tranne per il fatto che sto chiedendo se il concetto è anche buono, non come implementarlo.

    
posta RogerRoger 25.08.2014 - 19:59
fonte

4 risposte

1

Se vuoi proteggere contro una chiave o un altro segreto esposto a seguito di un compromissione del sistema, dovresti cercare un HSM per eseguire attività crittografiche. Dato che HSM è essenzialmente un suo piccolo computer, l'HSM dovrebbe quindi essere compromesso, il che è molto più difficile.

È anche possibile utilizzare un'architettura distribuita o di livello superiore tra l'applicazione, il database e la decrittografia in modo che la compromissione di un sistema non si traduca in una compromissione degli altri componenti (e..g, inserire il DB nel relativo proprio server con meno servizi e accesso (host bastion).

Altre misure dipenderebbero da chi ha effettivamente bisogno del testo in chiaro, ad es. Se si tratta solo del soggetto / utente che inserisce i dati, è possibile utilizzare un tipo di decrittazione locale tramite password o dispositivo di sicurezza locale / cryptocard.

Modifica: Inoltre ha postato questo nei commenti ad altre risposte, ma rilevante per questa conversazione è la crittografia omomorfica. In base al tuo commento qui sotto, se vuoi che solo soggetti specifici abbiano accesso, guarda un sistema come Mylar del MIT. Tuttavia, cambi il panorama se vuoi parlare di dati che devono essere accessibili sia dagli umani che dagli account di servizio.

    
risposta data 25.08.2014 - 23:31
fonte
2

Per creare un database live che crittografa i suoi dati, il database stesso dovrebbe avere accesso alle chiavi. Con questo token, qualsiasi amministratore può su nell'account e trovarli. Le tue preoccupazioni sono valide.

La tua idea di avere l'utente a presentare una chiave sicura (ad esempio RSA) se l'hai fatta tramite una connessione protetta SSH o SSL non è una cattiva idea. @Eric G ha menzionato Mylar nei commenti qui sotto che fa questo tipo di cose, e altro ancora. Vale la pena esaminarlo.

Se invece di crittografare il database, crittografare i dati prima che vengano inseriti nel database, allora si avrebbe una possibilità diversa - questa è solo una possibile alternativa:

I dati devono essere crittografati prima di essere pubblicati e decrittografati da un programma client in seguito. Il database non sarebbe crittografato, solo i dati al suo interno.

... o per il vero paranoico della sicurezza: esegui entrambi: crittografia dei database e crittografia dei dati, ognuno con metodi diversi.

Altro è descritto e discusso di seguito nei commenti.

    
risposta data 25.08.2014 - 20:31
fonte
1

Penso che le altre risposte siano sbagliate o, nel migliore dei casi, poco pratiche.

Per proteggere i dati nel database e averli accessibili solo su richiesta dell'utente, possiamo fare quanto segue.

Al momento della registrazione dell'utente generiamo due hash.

  • Hash A : la nostra password, bcrypt hash, memorizzata nel DB
  • Hash B : la nostra chiave di crittografia, non lo stesso hash della password, non memorizzata ovunque

Utilizziamo Hash B per crittografare i dati dell'utente.

Quando un utente accede, possiamo creare Hash B. Possiamo usare questo hash per decrittografare i loro dati su richiesta. Questo hash può essere conservato nella memoria del server o in una cache lato client protetta.

In questo modo garantiamo che tutti i dati siano crittografati e accessibili solo dall'utente.

Se un utente desidera cambiare la sua password, decifriamo con Hash B, ricreamo Hash B e poi ri-cifriamo con il nuovo hash in memoria e aggiorniamo il database.

Se l'utente perde o dimentica la sua password, perderanno i suoi dati. Ci sono modi per evitare questo.

L'unico modo per impedire agli amministratori di raccogliere i dati o le chiavi non crittografati a un certo punto è che il client cripta / decifri sulla loro estremità. Il processo che ho descritto sopra è l'approccio più pratico alla protezione dei dati.

    
risposta data 29.06.2016 - 15:48
fonte
-2

I database sono particolarmente dannosi per questo.

Se i dati sono così critici, non dovresti memorizzare le informazioni in un DB. Salva un blob criptato e decifrati lato client (gpg forse?)

    
risposta data 26.08.2014 - 00:34
fonte

Leggi altre domande sui tag