Kerberos per la gestione delle chiavi?

Question

Kerberos per la gestione delle chiavi?

#1 da (3 voti)

2

Abbiamo implementato a metà la corretta gestione delle chiavi presso il nostro dev shop. Abbiamo un servizio Web SOAP (il servizio web di gestione delle chiavi ) che può essere utilizzato per recuperare le password per altri sistemi. Quindi, ad esempio, potrei fare una richiesta a questo servizio per la password, ad esempio, per un DB PostgreSQL di produzione. Colpisco il servizio web con le mie credenziali AD e determina se sono autorizzato a ricevere o meno la password del DB. Se lo sono, viene inviato nella risposta. Posso quindi utilizzare questo servizio su tutti gli altri componenti software invece di memorizzare la password del DB in un file di configurazione statico (come context.xml di Tomcat, ecc.).

Il problema, naturalmente, è che con un processo automatizzato le credenziali AD passate nel servizio web devono essere memorizzate da qualche parte. Quindi, per ottenere la password per un DB (o qualsiasi altra risorsa protetta), è sufficiente accedere a ciò che viene utilizzato per memorizzare le credenziali AD e quindi inviarli a questo servizio Web, che quindi li autentica / autorizza e restituire la password per la risorsa richiesta. Classico problema di gestione delle chiavi.

Quindi, sto cercando di capire un modo per proteggere le credenziali AD utilizzate per accedere al servizio. Qualcuno ha parlato di Kerberos con me e ho iniziato a scavare un po '.

La mia comprensione è che, con Kerberos, ci sarebbero 3 componenti:

Un client del servizio web di gestione delle chiavi
Il servizio web di gestione delle chiavi
Un server Kerberos (ticket che garantisce ticket, TGT )

La mia comprensione è questa:

Il client (in qualche modo) ottiene un TGT da Kerberos
Il client invia quindi una richiesta per alcune risorse, ad esempio un DB, al servizio web di gestione delle chiavi, ma non fornisce le credenziali AD, ma invece fornisce il TGT
Il servizio web di gestione delle chiavi viene quindi riconfigurato per ricevere questo TGT e eseguire il ping del server Kerberos con un " questo TGT è valido? " - tipo richiesta
Il server Kerberos risponde e dice " yes " (o "no") e onora la richiesta per la password del DB, inviandola al client nella risposta

Quindi, prima di tutto, se qualcosa sulla mia comprensione non è corretto, per favore inizia correggendomi!

Supponendo che sia più o meno corretto, allora ho alcune domande su questa configurazione:

Come potrebbe il client ottenere prima il TGT da Kerberos?
I TGT di Kerberos hanno date di scadenza? In che modo il client "richiede nuovamente" un nuovo TGT?
Il servizio web di gestione delle chiavi deve implementare uno specifico protocollo TCP per parlare con Kerberos, oppure HTTP è sufficiente? Se Kerberos ha il proprio protocollo, esistono delle librerie Java che lo implementano? (So che è facile con Google "java kerberos" ma non sono sicuro di cosa sia esattamente la ricerca, perché di nuovo, non sono sicuro di aver capito l'architettura qui).

java passwords

posta herpylderp 07.08.2014 - 03:16

fonte

1 risposta

Leggi altre domande sui tag java passwords

Aggiunte relative all'infrastruttura nei commenti di commit Funzionalità di esternalizzazione dalla vista Django a C / C ++

score 3 · Answer 1

Il client ottiene un TGT (= ticket di concessione ticket) inviando credenziali al server Kerberos.

E ora questo è il punto in cui vedo il primo grosso problema. Hai bisogno di alcune credenziali. C'è davvero abbastanza vantaggio nell'avere le credenziali A solo per poter richiedere le credenziali B di cui hai effettivamente bisogno invece di avere le credenziali B in primo luogo? Una credenziale o altre credenziali. Non vedo come risolverebbe qualsiasi problema.

Ok, quindi hai inviato le credenziali al server Kerberos e hai ricevuto il tuo ticket. Quindi usi GSSAPI nell'altro protocollo per autenticarti utilizzando il tuo ticket e il servizio chiederà a kerberos quali permessi dovrebbe concederti.

Bene, così ora avete le credenziali A che passate al servizio W (kerberos), ottenete le credenziali B (il biglietto), passate al servizio X, ottenete le credenziali C (che è di nuovo username e password, presumibilmente) e usalo per richiedere il servizio effettivo Y. Ora questo è un passaggio in più e non ha ancora apportato alcun beneficio. Fortunatamente puoi sbarazzarti di quel passaggio in più. Il servizio Y quasi certamente può fare anche GSSAPI. PostgreSQL fa certamente come qualsiasi cosa Microsoft, perché la parte di autenticazione di Active Domain è Kerberos. Quindi puoi sostituire X con Kerberos. Chiedete a Kerberos un biglietto e poi usate quel biglietto per accedere al database.

Quindi torniamo a utilizzare le credenziali A per richiedere le credenziali B, sostituendo semplicemente sostituito con gli standard del settore. Se hai bisogno di credenziali A nella configurazione dell'applicazione, non abbiamo ottenuto assolutamente nulla. Lì potrebbe essere due vantaggi a seconda delle altre condizioni:

È possibile utilizzare le stesse credenziali per più servizi. Ciò non ha alcun vantaggio reale per le credenziali archiviate nel file di configurazione, ma ha un grande vantaggio per le credenziali fornite dall'utente. Quindi se le credenziali A provengono da un utente , vuoi farlo, quindi l'utente ha solo bisogno di un nome utente e una password.
La password non viene inviata in chiaro al server del database. Se la connessione non è crittografata e c'è il rischio che venga sniffata, allora è un punto. Ma in questo caso probabilmente vuoi evitare anche i dati da sniffare, nel qual caso hai bisogno comunque di SSL e la password di cleartext in SSL non è un problema.

I dettagli tecnici sono troppo ampi. O devi chiedere specificamente (impostazione dell'autenticazione Kerberos nella lingua X usando la libreria Y ecc., Quel tipo di domande dovrebbe appartenere a Stack Overflow, non qui) o hai bisogno di leggi la documentazione .