Come gestire in modo sicuro le chiavi private per le coppie di chiavi gestite da EC2?

Per avviare un'istanza EC2 è necessaria una coppia di chiavi. Come gestite la situazione in cui un ingegnere con accesso alla chiave privata per quella coppia di chiavi lascia l'azienda? Funzionerebbe per aggiungere un singolo accesso ssh e rimuovere l'autorizzazione della coppia di chiavi iniziale, immediatamente dopo l'avvio dell'istanza?

Quando un dipendente o un appaltatore lascia l'azienda, è necessario disabilitare qualsiasi accesso privilegiato alle risorse aziendali. Ciò include (ma non si limita a) le tue preoccupazioni chiave ssh:

1. Rimuovere la chiave ssh pubblica da tutti i file authorized_keys su tutte le istanze in esecuzione. Sostituiscili con una chiave ssh pubblica di nuova generazione che è nota solo alle persone che dovrebbero avere accesso.

2. Rimuovere tutte le voci di coppia di chiavi in ​​EC2 che erano conosciute dai defunti in modo che non possano essere avviate nuove istanze con quelle coppie di chiavi. Sostituiscili con nuove voci di coppia di chiavi, forse con gli stessi nomi se il tuo

Anche il metodo alternativo che proponi è buono ed è quello che uso: Disabilita la chiave ssh iniziale e aggiungi singole chiavi ssh pubbliche per ogni sviluppatore in modo che possano accedere con la loro normale chiave ssh privata. Questo può essere fatto per l'accesso a un account condiviso o con ogni sviluppatore che ottiene il proprio account utente individuale (il mio preferito).

Dopo che un dipendente se ne va, non solo dovrai ripulire i server in esecuzione, ma anche il processo che aggiunge le chiavi ssh ai nuovi server. E, quando un dipendente si unisce, dovrai fare il contrario: aggiungi le chiavi ssh ai server in esecuzione e aggiorna il nuovo processo del server.

Questo può essere un po 'più di lavoro per mantenere molte chiavi ssh su molti server, ma è qui che entra in gioco l'automazione.

Non si dovrebbe mai dare questa chiave privata agli utenti finali. Agli utenti finali dovrebbe essere fornito il proprio mezzo di accesso, come l'autenticazione con chiave pubblica (usando la propria chiave privata PROPRIA protetta da password), seguita dall'autorizzazione LDAP.

La distribuzione della chiave privata fornita da ec2 rende impossibile il deprovisioning degli utenti. Questo è esattamente il motivo per cui l'uso di credenziali condivise è completamente vietato da tutte le normative di sicurezza e conformità.

Quando si consente l'uso di credenziali condivise:

• È impossibile utilizzare i registri per sapere chi è / era realmente su un host
• È impossibile effettuare il provisioning di un utente senza effettuare il provisioning di tutti gli utenti (incluso l'accesso di emergenza, che è ciò a cui la chiave privata EC2 è realmente destinata)

Consulta la documentazione di Amazon sulla rotazione delle credenziali di accesso .

Usa qualcosa come pupazzo o solido script ssh per correre e sostituire tutte le istanze della vecchia chiave se non vuoi rilanciare tutto ... o semplicemente rilanciare tutto.