Modo migliore per memorizzare una password di database in uno script di avvio / config file?

Question

Quindi, il nostro server web apps necessario per la connessione al database, e alcune altre applicazioni sono gli script di avvio di esecuzione al momento dell'avvio.

Qual è il modo migliore per memorizzare il nome/password per queste applicazioni, in termini di

• di sicurezza, ad es.forse non vogliamo che gli amministratori di sistema per conoscere la password del database
• manutenibilità, ad es.rendere la configurazione facile cambiare quando cambia la password, etc.

windows e linux soluzioni apprezzato!

Answer 1

Il modo migliore per proteggere la tua password è quello di interrompere l'utilizzo di uno.Utilizzare una connessione di fiducia:Come:Connettersi a SQL Server Utilizzando l'Autenticazione di Windows in ASP.NET 2.0.Allora non hai nulla da nascondere - pubblicazione del web.config e l'origine del mondo, che ancora non è possibile colpire il vostro database.

Se questo non funziona per voi, utilizzare il built in configurazione di sistema di crittografia in ASP.NET.

Answer 2

PostgreSQL offre un bella soluzione per questo tipo di situazione nella loro documentazione.In sostanza, è possibile utilizzare ssh per il ponte di porta per il server PostgreSQL porta sulla macchina remota.Questo ha tre fasi di autenticazione:

1. Limitare l'accesso alla porta locale, come solo lasciare che un particolare utente di connettersi ad esso.
2. Impostare la password di connessione al PostgreSQL in ssh con un particolare utente.
3. Consentire all'utente ssh si connette come per disporre di accesso a PostgreSQL senza una password.

Questo riduce la sicurezza se il vostro account dell'utente sono protette e la vostra configurazione di ssh è sana, e tu non hai bisogno di una password memorizzata.

Modifica:Devo aggiungere che questo funziona con qualsiasi database che ascolta una porta TCP/IP.Succede solo essere descritto in PostgreSQL.E si vuole iptables (o l'equivalente off Linux) per fare le restrizioni di porta.Vedere questo.

Answer 3

Sono d'accordo con lomaxx:se qualcuno è già sul server o è ampia accesso ad esso (come un sysadmin), la partita è praticamente finita.Quindi l'idea sarebbe quella di utilizzare un server di fiducia che è sicuro per il grado che si desidera essere.In particolare:

• Hai bisogno di fiducia, gli amministratori di sistema
• Hai bisogno di fidarsi di qualcuno che è il codice in esecuzione sullo stesso server (questo è il motivo per cui l'hosting condiviso è un grande no-no per me)

Oltre a questo, le variabili di ambiente sembrano essere una scelta popolare per la memorizzazione di questi tipi di credenziali, perché questo significa che l'accesso alla sorgente (per esempio da compromettere il dev casella) di non rivelare direttamente e può anche essere ben localizzato per ogni server (sviluppo, test, ecc).

Answer 4

testo normale?Se sono sul tuo server, spero che il server è abbastanza sicura di non consentire l'accesso non autorizzato.Se è possibile accedere ai propri file di configurazione sul server, qualcosa è andato storto, molto prima.

Answer 5

chiarimento:in termini di sicurezza, manutenibilità (ad es.se il login ha bisogno di cambiare, posso trovare un secondo momento, ecc)

@lomax:forse non vuole che chiunque può accedere al server fisico (ad es.gli amministratori di sistema) per vedere la password.

Grazie!

Answer 6

Nella maggior parte dei casi, credo che sia sufficiente per offuscare la password in un file di testo (es.con base64).Non è possibile proteggere completamente una password memorizzata contro un determinato sysadmin con accesso root, quindi non c'è alcun bisogno di provare.Semplice offuscamento, tuttavia, protegge contro accidentalmente rivelare la password a una spalla surfer.

Più complesso alternativa è istituito un apposito password sicura server che:

• fornisce un servizio di decodifica password
• in realtà memorizza la password per l'utilizzo da parte di altri meno server sicuri

A seconda dei protocolli di rete utilizzati, questo non può proteggere contro un rogue sysadmin con tcpdump.E probabilmente non ha la protezione contro un determinato sysadmin con un debugger,.A quel punto, potrebbe essere il momento di guardare qualcosa come i ticket Kerberos.

Answer 7

Si può cuocere una chiave di crittografia simmetrica nel binario e binario di leggere un nome utente/password da un file su disco quando si avvia.

Tuttavia, questo non è davvero molto di più di offuscamento, dal momento che il codice è probabile essere memorizzati nel repository dei sorgenti da qualche parte.

Vorrei suggerire che sarebbe meglio servita per controllare l'accesso al tuo server sia fisicamente che attraverso la rete utilizzando un firewall e una rete privata bolla, e memorizzare la password in chiaro (o codificato in base 64) sul disco con autorizzazioni bloccato per l'esecuzione di utente per l'applicazione web.

È inoltre possibile bloccare il database server per accettare solo connessioni da web app macchine da IP.

In definitiva, il problema è che la chiave (il DB coppia nome utente/password) deve essere disponibile per programmatico, in automatico l'utilizzo da parte di applicazioni web.