Ha senso proteggere il database con una password se si protegge l'accesso al file di configurazione dell'applicazione che contiene le credenziali di testo in chiaro. Quando si limita l'accesso in lettura solo all'account dell'applicazione, l'attaccante richiede l'accesso come root per vedere la password. Nel caso in cui abbia violato qualsiasi altro account (meno privilegiato), non sarà in grado di accedere al database.

Questa è una specie di protezione onion (nota anche come " Sicurezza a più livelli " o " Difesa in profondità " come visto, ad esempio , nel white paper " Layered Security: Why It Works" di SANS). Se un utente malintenzionato riesce a raggiungere le macchine, non può ottenere l'accesso completo al database. L'applicazione dovrebbe avere un accesso limitato limitato alle sole tabelle richieste e tutto ciò che non deve essere scritto dovrebbe essere di sola lettura. Qualsiasi accesso più elevato dovrebbe richiedere una password diversa mai utilizzata nell'applicazione.

Il vantaggio è che un utente malintenzionato che ha accesso di rete al database ma non l'accesso al file system al server non sarà in grado di accedere effettivamente al database.

Se questo fornisce una sicurezza aggiuntiva dipenderà dal tuo scenario di minaccia e dai tuoi obiettivi di sicurezza. Conosco almeno due situazioni in cui aggiunge sicurezza:

• Ti consente di controllare più accuratamente l'accesso legittimo al database: potrebbero esserci persone che hanno legittimamente bisogno l'accesso al database, ma non ai dati all'interno, come gli amministratori di DB che eseguono la manutenzione. Un database crittografato può (a seconda della configurazione) consentire la concessione dell'accesso al database pur mantenendo segreti i dati.
  In modo simile, la crittografia di una parte del database (ad es. Solo colonne con password) consente un accesso limitato (ad esempio per problemi di debug, per la segnalazione o per un data warehouse ) proteggendo le informazioni critiche.
• Può proteggere i backup del database. Se viene eseguito il backup del database a livello di file o con uno strumento di backup che supporta database crittografati, il backup verrà crittografato. Ciò è utile perché i backup possono essere una fonte di violazioni dei dati, poiché spesso non sono protetti così come i server da cui sono stati prelevati (vedere ad esempio La scarsa sicurezza del backup porta alla perdita di dati del client Ameriprise).

Vantaggi della protezione tramite password del DB

• Se non è possibile utilizzarlo in modo insicuro, si riduce il rischio che se DB e server devono essere divisi in una fase successiva, essi verrà lasciato in modo insicuro, portando a futuri exploit.

• Se un utente malintenzionato può violare la macchina con un account limitato, potrebbe essere in grado di connettersi ai servizi locali, ma non reimpostare la password del database; richiedere all'autore dell'attacco di autenticarsi limita il danno che può fare.

• Se un attacco può essere utilizzato per riflettere / ritrasmettere il traffico, allora un avversario remoto può sembrare essere sulla macchina locale ( un esempio potrebbe essere un proxy che può essere convinto a caricare un'API DB o un servizio che mostra i dati ricevuti quando una connessione non riesce a un determinato URL)

• Se vengono utilizzate le password quindi è possibile impedire a diversi sistemi e utenti di utilizzare gli account degli altri, altrimenti un utente malintenzionato di qualsiasi sistema può fingere di essere qualsiasi altro sistema.

Se non hai grandi problemi di ridimensionamento in futuro, potrebbe non aggiungere alcuna sicurezza avere una password , anche se tieni presente che "no avere una password " non è la stessa cosa " fidarsi di chiunque affermi di essere la tua applicazione ".

Se la tua applicazione viene eseguita come un proprio utente sul server *, alcuni database possono consentire di utilizzare l'autenticazione di terze parti (ad esempio, ciò che Postgres chiama autenticazione peer ) che consente al server di utilizzare meccanismi di rete o del sistema operativo per determinare quali utenti sono chi dicono di essere. Ad esempio, sotto la configurazione corretta, l'utente della shell "bob" potrebbe accedere all'account del database "bob" senza fornire una password. Fare in modo che le cose siano semplici può rendere più facile la protezione del database e dell'applicazione.

Detto questo, come suggerisce jrtapsell answer, potresti dover spostare il tuo applicazione a un altro server per motivi di costi o prestazioni. In tal caso, probabilmente avrai bisogno di una password memorizzata o di un altro segreto come una chiave privata, sebbene ci siano alcuni metodi principalmente all'interno di reti private che potrebbero essere utilizzati per evitarlo.

Se pensi che ci siano buone probabilità di aver bisogno di una password (o di un altro segreto memorizzato) in futuro, allora dovresti solo prendere accordi ora in modo che non siano resi insicuri in seguito da qualcuno con meno tempo o esperienza.

_{* Idealmente, quell'account dovrebbe essere protetto da password o disponibile solo per accedere tramite sudo o meccanismo equivalente}

Conosci tutte quelle violazioni dei dati avvenute di recente? Quelli in cui le persone hanno trovato backup di database non protetti da password in bucket Amazon S3 non protetti? Sì.

Mai presumere che il tuo database vivrà solo sul tuo server protetto dietro venti miliardi di firewall. Il piccolo fastidio di una password sul tuo DB è un piccolo prezzo da pagare per la sicurezza essenzialmente gratuita che fornisce.

Come complemento alla risposta di Serge Ballesta.

Questo diventa particolarmente complicato se stai usando un database NoSQL, ad es. MongoDB, poiché per impostazione predefinita qualsiasi utente di database avrà i privilegi di sola lettura per tutti i database e non viene nemmeno configurato per avere un utente di database pronto all'uso . Ci sono alcuni punti deboli come affermato da Spider Labs Blog qualche tempo fa (intorno al 2013), ma le raccomandazioni di solito non vengono seguite nemmeno per le grandi aziende, ad es. MacKeeper incidente (fine 2015).

In entrambi i riferimenti, troverai un elenco delle vulnerabilità più comuni. Se preferisci leggere le linee guida "ufficiali", puoi trovarle qui, saranno analoghe per i database SQL. Tuttavia, mi piace pensare che non ci siano sovraccarichi quando l'argomento è la sicurezza.