Gestione dell'accesso chiave SSH ai server AWS dietro il bastione

Question

Gestione dell'accesso chiave SSH ai server AWS dietro il bastione

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

2

Al momento ho un setup AWS con 3 VPC, uno per il bastione, poi un Dev e un Prod VPC, gli ultimi due sono solo SSH accessibili tramite il bastione naturalmente (layout da questa ottima guida ). Sto cercando il modo migliore per gestire tra 3-5 utenti che accedono ai sistemi. A lungo termine spero di avere l'automazione e il logging esterno in un posto dove nessuno ha accesso a SSH, ma per ora, SSH lo è.

Dopo aver letto le idee di questa domanda sulla gestione delle chiavi ssh Sto pensando di configurare il mio accesso AWS come segue:

2 account su bastione, sudoable @ bastion e non-sudoable @ bastion. gli amministratori di sistema passano attraverso uno, gli sviluppatori attraverso l'altro. (gli sviluppatori non hanno motivo di fare altro che passare attraverso il bastione)
il file authorized_keys in ogni account del bastione contiene la chiave pubblica del sysadmins o degli sviluppatori, rispettivamente
Istanze VPC di Dev / Prod hanno un singolo account sudoable: it @ devVPC e it @ prodVPC.
Gli sviluppatori ricevono la chiave privata per le istanze @ devVPC, gli amministratori di sistema ottengono la chiave privata per entrambe le istanze di VPC.
Se qualcuno entra / esce dalla compagnia, il suo pubkey viene aggiunto / rimosso dal file authorized_keys corretto sul bastione.
Poiché le istanze di devVPC / prodVPC sono dietro il bastione, anche se il lavoratore che è partito può ancora avere la chiave privata per quei server, non c'è modo di accedervi poiché il bastione non le permetterà attraverso

Penso che questo dovrebbe impedirmi di dover gestire singoli account useradd / userdel su ogni istanza. Senza entrare in LDAP e cose che non vorrei comunque a lungo termine (di nuovo, si spera che nessuno abbia bisogno di SSH nei server AWS in futuro), sembra una configurazione legittima / sicura per un piccolo team?

Non l'ho usato ma ho anche visto AWS OpsWorks menzionato come metodo per controllare SSH chiavi? La mia situazione sembra un buon uso per questo?

ssh

posta xref 27.08.2015 - 19:36

fonte

3 risposte

Leggi altre domande sui tag ssh

Il fattore 2 di Google "Ricorda questo computer" è protetto contro gli avversari con accesso root? Dovremmo cambiare la propensione al rischio quando intraprendiamo un viaggio di trasformazione digitale?

score 1 · Answer 1

C'è un grosso buco in questo, che è difficile dimostrare chi ha fatto quale azione con account condivisi. Non impossibile, solo più difficile. Inoltre, la chiave privata condivisa è una cattiva idea da una strategia di difesa approfondita. Puoi risolvere entrambi i problemi gestendo singolarmente gli account, il che crea un maggiore overhead di gestione, ma non dovrebbe essere significativo con solo 5 utenti.

Non posso commentare a fondo l'idea di opsworks, non l'ho usata. Sulla base di una rapida lettura del documento che hai fornito, sembra proprio che esso configuri account sulle tue istanze e quindi sul file authorized_keys, che è un'attività piuttosto piccola. Devi anche trascorrere il tempo impostando tutti gli utenti con account IAM AWS, il che non sembra un buon compromesso.

score 1 · Answer 2

Utilizza chiavi SSH separate per ogni utente e account utente separati per ciascun sistema.

Creiamo utenti, li assegniamo ai ruoli e abilitiamo l'accesso tramite pubkey utilizzando il cookbook utenti con Chef, che è il progetto Open Source su cui OpsWorks è basato.

score 1 · Answer 3

Utilizzare il mio metodo come pubblicato renderebbe molto più difficile controllare le azioni lungo la linea se dovessimo farlo, come ha sottolineato Jesse, quindi penso che dovrò scegliere un'opzione migliore.

1) Guardando in OpsWorks o semplicemente usando Ansible che già facciamo per alcuni provisioning del server, come suggerisce Alain, sembra promettente. Non sembra che aggiungerebbe troppo overhead.

2) Ho anche trovato il servizio Foxpass che sembra che integrerebbe la gestione delle chiavi SSH con i nostri account Google Apps esistenti. Ciò potrebbe alleviare alcune delle mie preoccupazioni per il sovraccarico dei dipendenti di bordo (e disoccupati)