Cattiva pratica per avere una password "dio"?

Questo suona molto simile a un account "Amministratore", che in genere altrimenti ha accesso illimitato alle cose di cui è l'amministratore.

Le implicazioni sulla sicurezza di un account amministratore sono ben comprese, così come lo sono le migliori pratiche. Non entrerò in tutti i dettagli, ma la tua implementazione rompe con le best practice su una caratteristica chiave: la tracciabilità.

Vuoi essere in grado di dire chi ha fatto cosa, soprattutto quando si tratta di amministratori. Se un amministratore può accedere al mio account usando la sua password, allora non c'è alcun modo per un auditor dopo il fatto di determinare cosa è stato fatto da me rispetto a ciò che è stato fatto dall'amministratore.

Ma se invece l'amministratore accede al suo account OWN con la sua password super-sicura, quindi attraverso l'accesso che ha attraverso il suo account esegue un'azione che avrei potuto fare anch'io - beh, ora possiamo avere un log dire chi ha fatto cosa. Questa è una chiave importante quando il letame colpisce il ventilatore. E ancora di più quando uno degli account admin viene compromesso (cosa che sarà , nonostante i tuoi migliori sforzi).

Inoltre, dì che l'azienda cresce e hai bisogno di 2 amministratori. Condividono la password superawesome? NO NO NO. Entrambi hanno i loro account di amministratore, con traccia e logging separati e tutto il resto. Ora puoi dire QUALE admin ha fatto cosa. E, soprattutto, è possibile chiudere uno dei conti quando si licenzia uno degli amministratori per aver rubato le ciambelle.

Ci sono molte ottime informazioni nelle risposte date finora che il poster originale dovrebbe leggere e prendere a cuore. Tuttavia, penso che la maggior parte delle risposte non catturino lo spirito della domanda in quanto si riferisce al sito web della loro azienda "come se fossero l'utente" a scopo di supporto. Il cuore della domanda sembra essere che questa attività si verifica sul front-end di un sito web piuttosto che sulla console di un server.

Conosco un'azienda che ha questo stesso bisogno nella sua applicazione web e l'ha già risolta in un modo che credo sia il tipo di soluzione che il poster originale stava cercando.

Hanno creato un sistema "mascherato" nella loro webapp che consente a un dipendente di un gruppo speciale di inserire una serie di pagine che possono cercare qualsiasi utente nel sistema e selezionare tale utente come credenziale per sfogliare il sistema. Traccia l'utente selezionato per il masquerade come e l'effettivo utente dipendente come due entità separate e simultanee che sono entrambe registrate in ogni momento e per ogni azione.

Dal punto di vista dell'applicazione è un "trattami come questo utente, ma ricorda che in realtà sono questo altro utente". Una sorta di versione webapp di sudo, ma integrata nel front-end.

Questo metodo:

1. Elimina l'incubo della pista di controllo, perché entrambi gli account utente vengono sempre tracciati.
2. Fornisce ai dipendenti una "visualizzazione utente" esatta delle pagine.
3. Mantiene le credenziali individuali per i dipendenti in modo che non vi sia alcuna password condivisa o "principale".
4. Mantiene la sicurezza per gli utenti, le cui password non sono mai disponibili per i dipendenti.
5. Mantiene la soluzione a livello di applicazione, sul sito Web, in modo che chiunque possa farlo senza accesso a livello di sistema o conoscenza.
6. Il dipendente può anche "smascherare" in qualsiasi momento e controllare il contenuto della pagina contro il proprio account o altri account utente, il che è molto utile per determinare se i bug sono globali o specifici dell'utente.

Sì, è un errore. Cosa succede se l'utente malintenzionato riesce a impossessarsi di questa password, indipendentemente da quanto pensi che sia sicura? Sarà in grado di manomettere le informazioni sull'account dell'utente in un modo molto probabilmente difficile da distinguere dalla normale attività.

Se controlli il sito web, hai già a disposizione molti metodi diversi per l'opzione di supporto. È possibile scrivere strumenti amministrativi adeguati per leggere e modificare le informazioni necessarie. Non ha molto senso avere una password "master".

Questa password "dio" è l'equivalente dell'accesso root / amministratore: può fare tutto. La domanda è duplice:

1. È una buona idea avere una sorta di accesso al tipo "può fare tutto"? In pratica, è più "inevitabile" che "buono", ma sì, è una cosa normale. Assicurati, però, di avere procedure di utilizzo appropriate: non vuoi che gli amministratori eseguano l'amministrazione da una macchina condivisa in un bar; e vuoi sapere "chi dunn'it". In questo senso, quando ci sono due o più individui abilitati con privilegi di amministratore, è meglio se agiscono "come se stessi" come membri di un gruppo dell'amministratore (nel mondo Unix, usa sudo so che i comandi siano registrati).

2. È una buona idea far sì che gli amministratori eseguano i loro privilegi tramite la normale API utente ? Questo è discutibile. Consentire una "password divina" significa installare "l'eccezione divina" in tutta l'applicazione, il che comporta il rischio che venga abusato. Aumenta la complessità del sistema di autenticazione + autorizzazione nel tuo sito e la complessità è l'unica cosa che vuoi evitare in sicurezza. Gli insetti prosperano in complessità. Una "password divina" può essere utile durante lo sviluppo, ma, in generale, tende ad aumentare la probabilità di un buco di sicurezza devastante, quindi usa con estrema cautela.

Ovviamente il contesto è tutto, e le risposte sopra riportate semplicemente di solito si applicano. Tuttavia, fai attenzione alle backdoor amministrative, in particolare alle backdoor che non mantengono una buona traccia dell'origine delle richieste amministrative.

Un amministratore può ancora agire come se stesso: qualcuno con una password divina può impersonare chiunque sul sistema. Si potrebbe obiettare che se l'amministratore ha abbastanza potenza, questo non fa molto per limitare il danno effettivo che un utente malintenzionato potrebbe fare con quell'account. Ma un utente malintenzionato con la password del dio avrebbe un tempo molto più facile di coprire le sue tracce.

Avere una password "dio" è una soluzione semplice, ma è semplicemente una "autorizzazione" per mezzo della conoscenza della password principale e non si presta a una buona gestione degli accessi (ad esempio, il controllo di chi può farlo), né la responsabilità (chi ha fatto veramente cosa).

Invece, modifica la struttura dei dati delle credenziali per avere un campo utente efficace:

{
  user: alice,
  effective_user: bob,
}

Il contenuto delle tue pagine web deve essere visualizzato per effective_user , a meno che non si tratti di una pagina amministrativa interna che deve sapere chi è veramente che sta navigando. Tieni presente che la maggior parte delle persone esterne che esplorano il tuo sito avrà sempre lo stesso ID per entrambi i campi:

{
  user: alice,
  effective_user: alice,
}

Questo accordo ti consente di controllare meglio chi è autorizzato a diventare un altro utente, e ti permette anche di registrare / controllare chi ha fatto cosa per conto di chi. (Puoi semplicemente registrare sia l'utente che l'utente efficace su ciò che ti interessa guardare.) Unix fa questo tipo di cose utente (e gruppo) efficace internamente se guardi alle fonti per ciò che definisce un processo. Imitare questo sul Web sta sfruttando un paradigma conosciuto e di successo.

Questa soluzione ti consente anche di scegliere quali pagine il tuo staff può "guardare oltre le spalle" di un altro utente. Puoi scegliere di scrivere una pagina che non esegue il rendering in base a effective_user , quindi nessuna di quelle pagine può essere vista dal tuo staff, anche se hanno il privilegio di cambiare il loro id utente effettivo.

A proposito, ho implementato il concetto di utente efficace sul web e ho anche implementato la password divina. Quest'ultimo è facile da abbandonare quando tutta l'infrastruttura è già installata. Ma in realtà non è la soluzione migliore in termini di sapere chi ha fatto cosa e gestire l'accesso. Dai un'occhiata a quanta parte del refactoring è realmente coinvolto per aggiungere il campo utente efficace - potrebbe essere inferiore a quello che pensi.

Non impersoni mai l'utente. (Per vari motivi di tracciabilità / responsabilità come altri già menzionati.)
Invece, guardi una copia della schermata dello schermo degli utenti come se ti trovassi dietro di loro guardando da sopra la spalla.
Ecco a cosa servono gli strumenti di condivisione schermo / desktop come VNC, TeamViewer, Assistenza remota, ecc.

Se solo una persona ha accesso, allora non è necessariamente un problema, tuttavia può essere fatto altrettanto facilmente avendo un'impostazione per un account utente che consente questo accesso.

Con qualsiasi tipo di funzionalità di root / superutente / amministratore, la registrazione e il controllo del comportamento sono fondamentali e ciò significa che è necessario sapere chi sta facendo cosa. Se più utenti devono essere in grado di apportare modifiche come questa, allora dovrebbe essere una bandiera sul loro account per consentirle.

Puoi ancora avere una password aggiuntiva, più complicata che deve essere inserita anche quando hanno accesso, ma devi richiedere l'autenticazione sicura di una persona che sta apportando modifiche prima di fare qualcosa di simile.

Potresti non avere scelta, ma avere una password di "dio". Indipendentemente da ciò che ha detto tylerl sull'avere due diverse password di amministratore, come sarebbe possibile avere un log e un tracciamento a meno che qualcuno non fosse responsabile anche di questo? Dovresti letteralmente crittografare il log e tutto contro te stesso in modo tale che sia letto solo al mondo esterno ma possa ancora scrivere da solo. In che modo determina se le informazioni che riceve sono legittime o meno? Ovviamente se non si ha accesso, allora nessuno lo fa e quindi non funzionerebbe.

Penso che sia necessario avere una sicurezza basata sui ruoli piuttosto che un account con le abilità in modalità "dio". In questo modo puoi avere più persone che hanno gli stessi ruoli con capacità simili in modo che se il tuo dio / amministratore non è disponibile, qualcun altro può entrare in una soluzione.

So che questo è preferibile specialmente se stai per essere controllato.