Best Practice: "Una chiave ssh per utente" o "più chiavi ssh per host" [duplicato]

Question

Best Practice: "Una chiave ssh per utente" o "più chiavi ssh per host" [duplicato]

#1 da (14 voti)
#2 da (3 voti)

19

Ho partecipato a una conversazione la scorsa settimana su quale approccio alle chiavi SSH è più "sicuro". Si noti che quando si considera "sicuro" si cercava di considerare il comportamento umano (la parte più insicura di qualsiasi sistema di sicurezza).

L'ambiente ssh è principalmente macchine Unix / Linux (anche alcune PuTTY). U sers di ssh sono "utenti umani" e "account di automazione" che vengono utilizzati per eseguire operazioni / script programmati che richiedono scp / ssh per copiare file o eseguire comandi remoti.

Nel tentativo di proporre una best practice per i nostri utenti, stiamo prendendo in considerazione le seguenti raccomandazioni:

"una chiave ssh per utente" - L'utente genera una singola coppia di chiavi e invia la chiave pubblica al nostro processo automatizzato che copia la chiave pubblica nel file authorized_keys dell'utente su host a cui l'utente può accedere. All'utente viene richiesto di utilizzare la stessa chiave privata protetta con password valida su tutti gli host che utilizzano come client ssh. Questo approccio produce una coppia di chiavi per ogni utente.

"multiple" chiavi ssh per client-host "- Gli utenti devono generare una coppia di chiavi ssh per ogni client SSH. L'utente invia la chiave pubblica a un processo automatizzato che copia la chiave nel file authorized_keys autorizzato_keys file su host a cui l'utente può accedere. Questo approccio produce coppie di chiavi "u x c"; dove "u" è il numero di utenti e "c" è il numero di client.

Nelle nostre discussioni abbiamo notato vantaggi / svantaggi per ciascun approccio. Ad esempio: l'approccio "one ssh key per-user" ha il vantaggio di impressionare nella mente dell'utente l'importanza della loro unica chiave, oltre alla possibilità per noi di controllare la presenza di un pubblico dell'utente nelle verifiche di authorized_key File. D'altro canto, l'approccio "multiple" per client-host "chiavi ssh" ha il vantaggio di consentire l'audit dei file authorized_key per determinare l'utente e il computer client che è in grado di accedere - il che sembra particolarmente utile per comprendere i tipi di accesso che gli account non umani (eseguono script che chiamano SSH / SCP) hanno.

Sarei molto interessato a sentire cosa ha funzionato bene per le persone su questo forum. Grazie in anticipo.

identity key-management

posta Srinivas 20.08.2012 - 18:24

fonte

2 risposte

Leggi altre domande sui tag identity key-management

In che modo dovresti ragionare e lavorare con il paranoico della sicurezza nella tua squadra? Quanto è sicuro il portachiavi su OS X?

score 14 · Answer 1

Raccomando di adottare il modello "una chiave ssh per utente". È facile da usare per gli utenti finali, è semplice da spiegare agli utenti ed è probabile che soddisfi i requisiti di sicurezza.

La facilità d'uso è molto importante. Se un meccanismo di sicurezza è troppo difficile da usare, le persone troveranno un modo per aggirare il tuo meccanismo di sicurezza. Un meccanismo di sicurezza piuttosto semplice e di facile utilizzo è di gran lunga migliore di un meccanismo di sicurezza difficile da usare che in teoria è altamente sicuro (perché in pratica, se è difficile da usare, probabilmente non sarà così sicuro come aspettati che le persone trovino un modo per aggirare il meccanismo di sicurezza in modo che possano svolgere il proprio lavoro).

Penso che "una chiave ssh per il client, per utente" sia una cattiva idea. Sembra un casino. Sinceramente, sembra che l'IT stia impazzendo, in un modo che dà alla sicurezza un brutto nome e fa sì che la gente odia i reparti IT. Vuoi dire che devo generare una chiave SSH separata per ogni cliente e gestirli tutti? Tutto per un beneficio di sicurezza amorfo che non è chiaro? Ugh! Mi dispiacerebbe essere responsabile della vendita di questo agli utenti.

Suggerisco di pensare a questo tipo di decisioni in termini di "budget di conformità". I dipendenti assumeranno una certa quantità di fastidiosi obblighi di conformità (ad esempio, requisiti di sicurezza) imposti su di essi. Fino ad un certo punto, seguiranno questi mandati. Tuttavia, se diventa troppo, alla fine si infastidiscono e fanno semplicemente tutto ciò che devono fare per portare a termine il loro lavoro, anche se viola tutti i principi di sicurezza. Pertanto, imporre troppi requisiti o troppi inconvenienti può essere controproducente per la sicurezza. Quindi, prima di imporre agli utenti qualsiasi tipo di requisito di sicurezza o inconveniente relativo alla sicurezza, pensa molto attentamente. Immagina di avere un budget molto limitato per imporre mandati. È questo l'elemento migliore per spendere il tuo "budget di conformità" limitato?

Su una nota correlata, penso che i vantaggi di "una chiave ssh per la macchina client, per utente" siano piuttosto limitati. Non capisco perché qualcuno dovrebbe preoccuparsi di tutto ciò che account posso accedere con il mio portatile, contro il mio desktop. È solo microgestione? Che importa? Sono io, in entrambi i casi. Se ti fidi di me, ti fidi di me, non importa quale delle mie macchine sto usando, giusto? Non è chiaro per me che questo è un grosso problema che renderesti i tuoi utenti più difficili a causa di ciò.

P.S. Lei menziona qualcosa sulla gestione di quali privilegi non hanno gli umani. Non ho seguito abbastanza a cosa si riferiva. Hai citato script che chiamano SSH / SCP, ma chi sta invocando quegli script? Se si tratta di una persona, allora presumibilmente quella persona sta autorizzando l'attività, giusto? Se non viene invocato da una persona, non sono chiaro su come funzionerebbe (in base alla mia esperienza, tali script non hanno accesso alla chiave privata SSH, poiché non conoscono la passphrase e non lo sono collegato a qualsiasi sessione di ssh-agent che consenta loro di accedere alla chiave privata SSH). Non so se mi manca qualcosa di importante in questa affermazione.

score 3 · Answer 2

Ho difficoltà a pensare che l'esperienza dell'utente sull'approccio molti-a-molti sia accettabile. La confusione che circonda il tentativo di ricordare quale coppia di chiavi pub / priv va con il sistema che sembra eccessivamente ingombrante.

Lo spirito dell'approccio chiave one-to-many sembra migliore in termini di aspetti gestionali e di esperienza dell'utente. Dico lo spirito perché penso che se si dispone di più di un numero molto piccolo di utenti e sistemi, il pezzo di gestione diventerà difficile rapidamente. Stai andando verso una soluzione di gestione degli accessi centralizzata, quindi perché non andare fino in fondo? Configura un server LDAP (AD / OpenLDAP / questo thread ha alcune idee ), definire i ruoli per gli utenti, dare a tali ruoli l'accesso ai server / ai sistemi di cui hanno bisogno e assegnare ruoli agli utenti quando ne hanno bisogno. Ciò consente di eseguire il provisioning / deprovisioning di molti sistemi con un semplice cambio di ruolo e di mantenere tutti i log di controllo in una posizione centrale.

È una grande domanda che merita seriamente di riflettere sulla scalabilità e sulla praticità di una soluzione in quanto la tua organizzazione cresce in termini di numero e complessità.