È consigliabile proteggere con password il database se si è protetti l'accesso al file di configurazione dell'applicazione che contiene le credenziali in chiaro. Quando si limita l'accesso in lettura solo all'account dell'applicazione, l'utente malintenzionato richiede l'accesso root per visualizzare 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 (conosciuta anche come " Layered Security " o " Defense in Depth " come visto, ad esempio , in " Sicurezza stratificata: perché funziona" whitepaper ). Se un utente malintenzionato può raggiungere la (e) macchina (e), non può ottenere l'accesso completo al database. L'applicazione dovrebbe avere un accesso limitato limitato solo alle tabelle richieste e tutto ciò che non deve essere scritto dovrebbe essere di sola lettura. Qualsiasi accesso superiore dovrebbe richiedere una password diversa mai utilizzata nell'applicazione.

Il vantaggio è che un utente malintenzionato che ha accesso alla rete al database ma che non accede al server non sarà in grado di accedere al database.

Se ciò fornisce una sicurezza aggiuntiva dipenderà dallo scenario della tua minaccia e dai tuoi obiettivi di sicurezza. Conosco almeno due situazioni in cui aggiunge sicurezza:

• Ti consente di controllare con maggiore precisione l'accesso legittimo al database: potrebbero esserci persone che hanno legittimamente bisogno di accedere al database, ma non ai dati interni, come gli amministratori di DB che eseguono la manutenzione. Un database crittografato può (in base all'impostazione) consentire la concessione dell'accesso al DB pur mantenendo i dati segreti.
  Analogamente, la crittografia di una parte del database (ad esempio, solo le colonne con password) consente un accesso limitato (ad esempio per problemi di debug, report o per un data warehouse ) proteggendo le informazioni critiche.
• Può proteggere i backup del database. Se il database viene eseguito il backup a livello di file o con uno strumento di backup che supporta i 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 (si veda ad esempio Scarsa protezione di sicurezza conduce alla perdita di dati dei client di Ameriprise ).

Vantaggi della protezione della password del DB

• Se non è possibile utilizzarlo in modo non corretto riduce il rischio che se il DB e il server debbano essere suddivisi in una fase successiva, verranno lasciati in un modo non sicuro, portando a exploit futuri.

• 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 autenticare i limiti del danno che possono fare.

• Se è possibile utilizzare un attacco per riflettere / inoltrare il traffico, è possibile che un avversario remoto si trovi sulla macchina locale (un esempio potrebbe essere un proxy che può essere convinto di caricare un'API DB o un servizio che mostra i dati ricevuti quando una connessione non riesce a un dato URL)

• Se vengono utilizzate password, è possibile impedire a sistemi e utenti diversi di utilizzare i rispettivi account, altrimenti un utente malintenzionato proveniente da qualsiasi sistema può fingere di essere qualsiasi altro sistema.

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

Mai supponiamo che il tuo database vivrà sempre sul tuo server protetto dietro a venti miliardi di firewall. La seccatura minore di una password sul DB è un piccolo prezzo da pagare per la sicurezza essenzialmente gratuita che fornisce.

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

Se l'applicazione viene eseguita come un proprio utente sul server *, alcuni database potrebbero consentire l'uso dell'autenticazione di terze parti (ad es. Postgres chiama peer authentication) 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 di destra, l'utente di shell "bob" potrebbe accedere all'account di database "bob" senza fornire una password. Avere le cose semplici può rendere più semplice la sicurezza del database e dell'applicazione.

Detto questo, come jrtapsell 's risposta suggerimenti, potrebbe essere necessario spostare l'applicazione su 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, anche se ci sono alcuni metodi principalmente all'interno delle reti private che potrebbero essere utilizzati per evitarlo.

Se pensi che ci sia una buona possibilità che in futuro avrai bisogno di una password (o di un altro segreto memorizzato), dovresti solo prendere le disposizioni ora in modo che non vengano fatte in modo insicuro da qualcuno con meno tempo o esperienza.

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

Come complemento alla risposta di Serge Ballesta.

Questo diventa particolarmente complicato se si utilizza un database NoSQL, ad es. MongoDB, come per impostazione predefinita qualsiasi utente del database avrà i privilegi di sola lettura per tutti i database, e nemmeno viene configurato per avere un db-user fuori dalla scatola . Ci sono alcuni punti deboli come stato di Spider Labs Blog qualche tempo fa (intorno al 2013), ma di solito le raccomandazioni non vengono seguite anche per le grandi aziende, ad esempio 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 , devono essere analoghi per i database SQL. Tuttavia, mi piace pensare che non ci siano overkills quando il soggetto è sicuro.