Gestione e distribuzione di password per le app Web

Question

Gestione e distribuzione di password per le app Web

#1 da (1 voti)
#2 da (0 voti)

4

Quali sono alcune best practice per la gestione e la distribuzione di password per app Web e chiavi private? Per esempio. la password per accedere a un database o servizi esterni come l'API di Facebook. Mi riferisco in genere all'utilizzo di hardware dedicato o di un provider cloud generale e non a provider specifici come Heroku o EC2.

È il meglio che puoi fare senza un HSM è quello di distribuire le credenziali in un file di testo normale in una directory protetta da lettura accessibile solo all'utente della web app? Dovresti avere un file con tutte le password o un file per utente o negozio in variabili d'ambiente? Come gestisci effettivamente metterli sui server? Puoi utilizzare uno strumento di gestione della configurazione (ad esempio chef / fantoccio) per distribuirli e mantenerli aggiornati? Come dovrebbero essere archiviate queste credenziali? Dovrebbero essere memorizzati in formato crittografato nella directory di controllo del codice sorgente contenente le configurazioni di gestione della configurazione? Qualche raccomandazione sugli strumenti da usare che potrebbero essere utili? (ad esempio keyczar, server segreto, ecc.) Se le password sono crittografate, qual è un buon modo per condividere la chiave di decrittazione tra il team DevOps? (LastPass, KeePass, ecc.?)

So che è una lunga lista di domande, ma queste sono tutte cose alle quali non ho trovato risposte valide. Sono interessato a qualsiasi informazione se si tratta di un caso di studio di qualcuno che lo fa bene, di compromessi tra alternative diverse, cose che dovrebbero essere chiaramente evitate o mirate. Non so davvero quali siano le migliori pratiche e strumenti utili contro ciò che dobbiamo decidere per la nostra situazione e risolvere da soli.

passwords webserver password-management web-application key-management

posta Ben McCann 19.11.2013 - 19:49

fonte

2 risposte

Leggi altre domande sui tag passwords webserver password-management web-application key-management

Esistono degli attacchi temporali di confronto delle stringhe proof-of-concept? Esiste un concetto di password di crittografia PXE / disco completo come questo?

score 1 · Answer 1

La tua domanda è molto vaga e copre una serie di aree. Un esempio sarebbe molto utile.

In base al titolo della tua domanda, sembra che ti interessi sapere come gestire in modo sicuro le credenziali richieste da un'applicazione. Se si tratta di un ambiente Microsoft, è possibile crittografare sezioni di web.config che vengono utilizzate per memorizzare informazioni sensibili (credenziali di accesso SQL, ecc.). Questo post offre una buona spiegazione: perché da usare-rsa-per-DPAPI-web-farm-crittografia . In breve, se hai un solo server web DPAPI è la soluzione consigliata mentre chiavi RSA sono preferite per le web farm.

Tuttavia, credo che tu sia interessato anche a una soluzione di gestione delle password aziendali. L'istruttore SANS Jason Fossen ha pubblicato un ottimo articolo sul suo Blog sulla sicurezza di Windows . Ha scritto uno script che assegnerà una password univoca agli account locali e sfrutta la crittografia asimmetrica per salvare la password in una posizione centralizzata. Nella voce menziona anche una serie di prodotti commerciali nello spazio Password Vault o Enterprise Password Management.

HSM viene in genere utilizzato solo per account critici come amministratori di dominio / impresa o per certificati utilizzati dall'infrastruttura critica. Per uso generale o quotidiano, queste soluzioni di gestione delle password aziendali sono eccezionali.

Parecchio tempo fa ho esaminato la soluzione Lieberman e l'ho trovata molto interessante. C'è un auditing completo per registrare l'utente che accede alle credenziali, quali sono le credenziali accessibili e, naturalmente, quando. C'è anche la flessibilità per configurare gli account temporanei (validi solo per x time) che è utile per gli appaltatori, i consulenti, ecc.

score 0 · Answer 2

Penso che sarebbe di aiuto tornare ad alcuni principi di base. Un buon punto di partenza è progettare cose tali che non c'è MAI un motivo per l'applicazione o per gli amministratori di conoscere una password in testo semplice per gli utenti. Dovresti sempre avere la versione hash / crittografata della password. Se non conosci mai la password, non hai mai bisogno o non hai nemmeno la possibilità di comunicarlo con l'utente.

La prossima cosa da fare è una valutazione dei rischi e delle conseguenze. Quali sono i principali rischi e quali sarebbero le conseguenze se tali rischi vengono identificati. Questo ti darà un'idea del livello di sicurezza richiesto e quali opzioni sono accettabili.

Il problema diventa quindi una delle gout di lavoro su come configurare / registrare nuovi utenti in modo sicuro che soddisfi la valutazione del rischio. Ci sono un certo numero di opzioni, molte delle quali dipendono da quali informazioni hai. La maggior parte delle soluzioni si basa sulla possibilità di fornire una password monouso o un collegamento una tantum che è possibile utilizzare. Entrambi avrebbero un timeout, dopodiché non sarebbero più utilizzabili. Quando usano la password o il link, sarebbero costretti a impostare la loro 'vera' password ecc.

Il problema diventa quindi quello di elaborare il modo migliore per comunicare questa unica password o collegamento all'utente. Ciò dipenderà da una combinazione di entrambe le opzioni disponibili, ad esempio e-mail privata, SMS, telefono, ecc., Nonché i rischi e le conseguenze nel caso in cui le informazioni razionino nelle mani sbagliate.

La valutazione dei rischi e delle conseguenze è fondamentale. Se il livello di sicurezza e protezione non è ben proporzionato al livello di rischio e alle conseguenze, è probabile che gli utenti non siano soddisfatti del servizio. O penseranno che non è abbastanza sicuro ed eviterà di usarlo o lo troveranno troppo difficile da usare ed eviterà di usarlo.