Dove dovremmo mantenere nomi utente e password esterni (subappaltatori)?

3

Abbiamo tre ambienti:

  • Test e sviluppo
  • preproduzione
  • Produzione

Nella nostra azienda tutti i tecnici, inclusi amministratori di sistema e amministratori di rete, sono subappaltatori, quindi molti di loro (ma non tutti) hanno bisogno di accedere a quasi tutto.

Dove dovremmo mantenere le credenziali esterne (subappaltatori)?

Oggi abbiamo un dominio diverso per loro, un dominio diverso per ogni ambiente: "EXTERNALSTEST", "EXTERNALSPRE" e "EXTERNALSPRO" (abbiamo anche domini per i nostri dipendenti ("COMPANYTEST", "COMPANYPRE" e "COMPANYPRO") ").

Diamo anche nomi utente diversi a quelli esterni a seconda dell'ambiente: test_username per "Ambiente di test e sviluppo" e "Preproduzione" ambienti e nome utente per l'ambiente "Produzione".

Cerchiamo di farlo in modo più semplice ma sicuro.

Possiamo avere un nome utente univoco e un dominio univoco "EXTERNALS" memorizzati in "Produzione" per tutti i dipendenti esterni?

Il rischio che vedo qui è che se abbiamo il dominio EXTERNAL solo nella produzione dovremo aprire la comunicazione dagli altri ambienti alla produzione e oggi abbiamo una buona segregazione di questi ambienti con le regole dei firewall.

È questa la migliore organizzazione degli utenti esterni? È sicuro?

    
posta Eloy Roldán Paredes 11.11.2016 - 10:50
fonte

1 risposta

2

Non sono un architetto di rete, ma un teamer rosso. Le reti che sono state le più difficili da una prospettiva di gestione delle password e di segregazione sono state quelle degli amministratori che hanno bisogno di un account utente e di un account amministratore. Quindi, se sono esterni, utilizzerebbero il loro account utente con autenticazione a due fattori per accedere alla VPN per l'ambiente di cui hanno bisogno. Dopo aver effettuato l'accesso alla VPN tramite l'autenticazione a due fattori, è necessario accedere al vault della password per "verificare" le proprie credenziali amministrative. Lieberman sembra essere un'opzione decente. Richiederei anche l'autenticazione a due fattori per il vault della password con un diverso token soft / hard. Dopo che gli amministratori hanno estratto la loro password e poi hanno finito con loro, cambiano le password, so che Lieberman fa questo errrr lol. Ciò aiuterà a mitigare la possibilità che le credenziali siano ottenute da memoria, cache, segreti, ecc.

Penso che la segregazione dei domini sia buona, assicurati di verificare la relazione di fiducia tra loro. I diversi domini non dovrebbero avere trust stabiliti (indipendentemente da ciò che qualcuno dice), altrimenti qual è il punto di un dominio diverso? Ecco un link al sito Web Lieberman che fornisce una descrizione approfondita su come tentano di mitigare l'attacco alle credenziali: link

Per quanto riguarda l'opzione di usare LDAP e Kerberos su Internet ... per favore ... non farlo ... Non ho abbastanza punti per rispondere direttamente al commento. Ho letto la documentazione fornita: prima di tutto non sembra offrire la possibilità di utilizzare l'autenticazione a 2 fattori, che è orribile in sé, ma ancor più quando si chiede una soluzione utilizzata principalmente dagli amministratori. Inoltre, ho appena guardato e offre la console di amministrazione per la gestione degli utenti e dell'autenticazione su Internet, con un semplice nome utente e password di amministratore. Ciò lascerebbe tutto il giorno vulnerabile alla forza bruta ... le chiavi del regno. Alcuni potrebbero dire che non devi metterli su internet, tuttavia sembra che la maggior parte dei server "MarkLogic" provengano da una semplice ricerca shodan. Sembra alquanto impreciso.

Posso dire per esperienza che l'autenticazione a 2 fattori crea un enorme mal di testa e disturbo per gli hacker durante le loro operazioni. Soprattutto quando è accoppiato con una buona gestione delle password delle credenziali amministrative, vale a dire che le credenziali cambiano frequentemente, sono diverse dalle credenziali dell'utente e un'altra barriera di autenticazione a 2 fattori è necessaria per accedervi.

ANCHE !!!!! Non lasciare che il token soft venga richiesto e approvato automaticamente dall'utente che lo sta richiedendo, AKA un portale self-service per token soft. Questo deve essere un processo di convalida manuale. Non credo che questa sia una soluzione completa, comunque un buon inizio. Spero che questa prospettiva aiuti in ogni caso.

    
risposta data 26.11.2016 - 00:50
fonte

Leggi altre domande sui tag