Gateway di accesso SSH per molti server

Gestione di più server, oltre 90 attualmente con 3 devops tramite Ansible. Tutto funziona alla grande, tuttavia al momento esiste un enorme problema di sicurezza. Ogni devop utilizza la propria chiave ssh locale per accedere direttamente ai server. Ogni devop utilizza un laptop e ogni laptop potrebbe essere potenzialmente compromesso, aprendo così l'intera rete di server prod a un attacco.

Sto cercando una soluzione per gestire centralmente l'accesso, e quindi bloccare l'accesso per una determinata chiave. Non dissimile da come le chiavi vengono aggiunte a bitbucket o github.

Dalla parte superiore della mia testa presumo che la soluzione sarebbe un tunnel da una macchina, il gateway, al server prod desiderato ... mentre passando il gateway la richiesta prenderebbe una nuova chiave e userebbe per accedere al prod server. Il risultato sarebbe che possiamo eliminare in modo rapido ed efficiente l'accesso per qualsiasi sviluppatore in pochi secondi negando l'accesso al gateway.

Questa è una buona logica? Qualcuno ha già visto una soluzione là fuori per contrastare questo problema?

È troppo complicato (verificare se una chiave ha accesso a uno specifico server prod). Utilizzare il server gateway come jump host che accetta ogni chiave valida (ma può rimuovere facilmente l'accesso per una chiave specifica che rimuove a sua volta l'accesso a tutti i server) e quindi aggiungere solo le chiavi consentite a ciascun rispettivo server. Successivamente, assicurarsi di poter raggiungere la porta SSH di ogni server solo tramite l'host di salto.

Questo è l'approccio standard.

Gli ingegneri non dovrebbero essere in grado di rispondere direttamente dal proprio laptop, a meno che non si tratti di un ambiente di sviluppo / test.

Invece, disporre di un server centrale che estrae i runbook da Git. Ciò consente controlli aggiuntivi (quattro occhi, revisione del codice).

Combina questo con un bastione o jump-host per limitare ulteriormente l'accesso.

Netflix ha implementato la tua configurazione e rilasciato alcuni software gratuiti per aiutare quella situazione.

Guarda questo video https://www.oreilly.com/learning/how-netflix-gives-all-its-engineers-ssh-access o questa presentazione su https://speakerdeck.com/rlewis/how-netflix-gives- all-its-engineer-ssh-accesso-alle-istanze-in esecuzione-in-produzione con il punto centrale:

Esamineremo la nostra architettura del bastione SSH, che al suo interno utilizza SSO per autenticare gli ingegneri, quindi emettere le credenziali per utente con certificati di breve durata per l'autenticazione SSH del bastione in un'istanza. Queste credenziali di breve durata riducono il rischio associato alla perdita. Tratteremo come questo approccio ci consente di controllare e avvisare automaticamente dopo il fatto, invece di rallentare gli ingegneri prima di concedere l'accesso.

Il loro software è disponibile qui: https://github.com/Netflix/bless

Alcuni aspetti interessanti anche se non si implementa l'intera soluzione:

• usano i certificati SSH anziché solo le chiavi; puoi inserire molti più metadati nel certificato, abilitando quindi molti vincoli per requisiti e consentendo anche audit più semplici
• utilizzando la validità dei certificati a brevissimo termine (come 5 minuti) (le sessioni SSH rimangono aperte anche dopo la scadenza del certificato)
• l'utilizzo di 2FA per rendere difficile anche lo scripting e costringere gli sviluppatori a trovare altre soluzioni
• un sottomodulo specifico, al di fuori della propria infrastruttura e adeguatamente protetto attraverso i meccanismi di sicurezza offerti dal cloud in cui viene eseguito, gestisce la generazione dinamica dei certificati in modo che ogni sviluppatore possa accedere a qualsiasi host

OneIdentity (ex Balabit) SPS è esattamente ciò di cui hai bisogno in questo scenario. Con questo dispositivo è possibile gestire le identità degli utenti praticamente su qualsiasi macchina, tenere traccia del comportamento degli utenti, monitorare e avvisare e indicizzare qualsiasi cosa gli utenti facciano per le revisioni successive.

Il mio suggerimento è di impedire l'accesso SSH dai computer degli utenti.

Invece dovresti

1. Ospita i playbook in Git.
2. Trasforma il "Server di accesso" in un server Jenkins.
3. Concedere solo l'accesso Jenkins agli utenti devops.
4. Esegui le riproduzioni Ansible su Jenkins sui lavori di compilazione tramite HTTP.
5. Come ulteriore misura di sicurezza, disabilitare l'interfaccia della riga di comando Jenkins, se necessario.

Il modello di esecuzione del campione,

1. Plug-in Jenkins Ansible: https://wiki.jenkins.io/display/JENKINS/Ansible+Plugin

O

2. Shell classico: tipo di lavoro eseguito. Aggiungi i tuoi passaggi di compilazione manualmente, incluso il checkout di Git.

Se sei limitato con le risorse del server, lo stesso server Jenkins può ospitare anche Git (scm-manager), sebbene ci sia un ulteriore rischio per la sicurezza se uno dei computer degli sviluppatori è infetto. Potresti essere in grado di mitigarlo scollegando il server Jenkins da Internet e risolvendo le dipendenze Ansible localmente.