Procedura consigliata per memorizzare la password del database

Question

Sto sviluppando un'applicazione server personalizzata che accederà a un database. Devo decidere dove memorizzare le credenziali (e indirizzarle) su quel server.

Una soluzione comune consiste nel mettere le credenziali in un file di configurazione. Tuttavia, non voglio che un server compromesso significhi che l'hacker abbia accesso al DB (che è ospitato su un server separato).

Potrei memorizzare le credenziali nell'ambiente, ma questa è solo sicurezza attraverso l'oscurità. Mr. Evil può solo guardare nell'ambiente per trovarlo.

Qualcuno ha suggerito la crittografia. Tuttavia, se immagazzino la chiave nell'eseguibile, una rapida decompilazione (stiamo usando Java) e sono ancora condannata.

Voglio anche evitare di dover inserire una parafrasi ogni volta che avvio il server.

Qualche suggerimento? Mi sento come se mi mancasse qualcosa di semplice.

Grazie

Answer 1

Non penso che ti manchi qualcosa di semplice. Il server in questione può connettersi al database senza il tuo aiuto, nel qual caso lo ha le credenziali; o non può connettersi senza che tu li fornisca. Puoi prendere vari passaggi come quelli che hai elencato per renderlo più difficile per un server compromesso per rivelare le credenziali al database, ma alla fine della giornata, se deve avere quelle credenziali e fornirle al database DB server per connettersi, dovranno essere memorizzati su di esso da qualche parte   — o almeno, dovrà avere alcuni mezzi per ottenerli, e quindi sarà hackerabile in tal senso.

La cosa migliore è quello di concentrarsi sulla ricerca di conoscere le intrusioni (server compromessi) il più rapidamente possibile, mantenendo una buona off-site, i backup off-line per il caso peggiore, mettendo su un sacco di barriere all'intrusione in primo luogo , ecc.

Answer 2

Sto condividendo, il modo in cui l'avevo risolto.

• Build API, per interrogare i dettagli di autenticazione da un dominio esterno.
• Utilizzare la chiave pubblica e la chiave privata per leggere i dettagli.

Ma, onestamente l'unica cosa che questo fatto è stato complicare oltre cose semplici. Successivamente, ho creato diversi utenti nel database, con diversi privilegi.

Come

• guest può solo a SELECT
• mod può solo CREATE, INSERT, UPDATE, DELETE

etc e acceso l'utente, ogni volta che è apparso utenti autenticati.

Con la combinazione di utenti e sessione, sono stato in grado di sfuggire alle minacce finora.Ma naturalmente la vulnerabilità del codice deve essere testata a fondo.

Answer 3

Bloccarlo. Impedisci al signor Evil di guadagnare radici. Lo so, facile, vero?

Scrivere un'applicazione protetta e mantenere bloccato il server delle applicazioni. Segui le migliori pratiche lì, e questa è la maggior parte del lavoro.

Quando ho installato i database in un ambiente sicuro, l'unico server che si trovava sulla stessa rete fisica con il server del database era il server delle applicazioni. C'erano due modi per accedere al server di database:

1. server applicazioni
2. Console

Pertanto, al fine di compromettere il server di database, avrebbero dovuto compromettere il server di applicazione.

Quindi, bloccare il server delle applicazioni. Ovviamente l'unica cosa peggiore dell'essere compromessi è essere compromessi e non saperlo. Se si scopre un compromesso, è necessario correggere la vulnerabilità se ce n'era una. Le analisi forensi sono importanti qui (abilitare i log e monitorarli). Hai anche bisogno di un piano di recupero in atto.

Prevenzione, rilevamento, correzione e ripristino sono di primaria importanza.