PCI DSS 2.0 e chiavi ssh

Dato che il tuo negozio è raddoppiato nell'organico, aumenta il rischio che qualcuno maneggi involontariamente o intenzionalmente una o più chiavi SSH. L'utilizzo delle chiavi SSH senza passare attraverso LDAP crea la vulnerabilità che qualcuno può, ad esempio, effettuare una connessione con l'account di sistema e estrarre tutti i dati del titolare dal database, tutto come utente autorizzato e sovvertendo controllo / gestione degli accessi.

Vedi 2.3, 3.6, 8.1.

Vedi anche link

e

I migliori Esercitazione: "Una chiave ssh per utente" o "più chiavi ssh per host"

Ho sempre avuto un problema con le chiavi SSH quando ero un QSA. Soprattutto perché la gente fondamentalmente li costruisce una volta e poi li ignora.

Come tester di penetrazione ci sono molti modi per accedere ai sistemi. Per me è stato più semplice accedere a un sistema di amministrazione di sistema con chiavi SSH, oppure utilizzare un browser o un altro exploit locale (attacco di phishing) per estrarre le chiavi e l'amp; email o web / inviarli se non potessi accedere direttamente al sistema. O semplicemente acquistare vecchi hardware che il personale sta vendendo con aggiornamenti annuali; Sono sicuro che non sono stati cancellati e uno di essi ha lasciato una chiave. Ci sono molti modi per accedere ai tasti.

Una volta avuto le chiavi ssh ho quindi avuto accesso a tutto . I migliori account da trovare erano gli amministratori che non erano più con la compagnia. Senza una gestione centralizzata, tali account erano probabilmente ancora presenti nel sistema.

Chiediti questo. Cosa stai facendo per gestire le chiavi ssh e gli account sui sistemi? Se si hanno account di sistema locali con sudo locale e si usano le chiavi ssh per accedere, cosa si fa quando qualcuno cambia ruolo nella società o si assume una nuova persona o qualcuno lascia. O peggio, quando si ha qualcuno malintenzionato che sa che se ne va che pre-costruisce account e chiavi ssh prima che se ne vadano. Come controlli e controlli per questo?

Le chiavi SSH di solito lasciano i tuoi sistemi come dozzine o centinaia o comunque molti dei tuoi sistemi.

Sì, le password sono un dolore, ma molti amministratori in questi giorni; specialmente quelli che sono addestrati e hanno gli strumenti giusti per costruire password sicure.

Inoltre, con chiavi ssh, anche con una passphrase; come lo stai controllando? Non c'è modo di imporre a livello centrale la modifica della passphrase o anche una passphrase strong. Ho visto molte passphrase chiave ssh con la password come "una" o "password" ...

Se vuoi davvero sicurezza, dovresti esaminare una soluzione token basata su raggio; ma in entrambi i casi dovresti considerare la gestione e il controllo centralizzati degli account. winbind o anche solo ldap possono essere utilizzati per la verifica dell'account utente e per l'appropriata autorizzazione del gruppo utente in modo da poter controllare correttamente l'accesso ai sistemi.

Non è una risposta facile; ma la domanda che devi porre è se desideri questo per comodità o sicurezza?

Le chiavi SSH sono OK indipendentemente dalle dimensioni della tua azienda.

Andiamo più a fondo nel PCI DSS (estratto dalla versione 3.0, ma anche in 2.0):

8.2 In addition to assigning a unique ID, ensure proper user-authentication management for non-consumer users and administrators on all system components by employing at least one of the following methods to authenticate all users:
*Something you know, such as a password or passphrase
*Something you have, such as a token device or smart card
*Something you are, such as a biometric.

"almeno": una delle 3 opzioni sopra è OK.

Guida ufficiale su "qualcosa che hai":

 Note that a digital certificate is a valid option for “something you have” as long as it is unique for a particular user.

Conclusione:

Le chiavi SSH sono conformi fino a quando ogni SysAdmin ha la sua coppia di chiavi.

In deve aggiungere che le best practice (e quindi PCI DSS req 2) richiederanno la protezione della chiave privata con una passphrase strong.