Domanda:
Cattiva pratica avere una password "dio"?
Abe Miessler
2014-02-07 23:08:51 UTC
view on stackexchange narkive permalink

È una cattiva pratica di sicurezza avere una password che ti consenta di accedere a qualsiasi account utente su un sito web per scopi di supporto? La password verrebbe memorizzata in modo sicuro e sarebbe super complessa. Enorme errore?

Perché non avere solo un account amministratore con i privilegi per modificare i dati di altri utenti?
Sembra che ciò creerebbe un altro livello tra il personale di supporto e l'account problematico senza fornire molta più sicurezza. Perché pensi che questo sarebbe più sicuro?
@Polynomnial Di solito un amministratore "vede" una schermata diversa da quella di un utente, a volte sarebbe utile per il supporto vedere la schermata esatta che un utente vede quando ha problemi. (Non dire "dio" pw è una buona idea, ma l'account amministratore non risolve questo problema specifico, * a meno che * l'amministratore non abbia la capacità di impersonare gli account.)
C'è già un modo per farlo. Si chiama `sudo` su qualsiasi sistema operativo multiutente decente.
@Polynomial O meglio ancora, non utilizzare un utente amministratore ma concedi alle persone di supporto le autorizzazioni per farlo. In questo modo è possibile conservare i registri che mostrano chi ha fatto cosa invece di "L'amministratore ha cambiato i record DNS di X come da [richiesta inviata via fax] (http://www.theguardian.com/technology/2013/oct/15/metasploit-kdms-dns- fax hackerato). " Modifica: Oh, sembra che questo sia già menzionato nelle risposte.
@Shadur [sudo non è una cosa Unix?] (Http://en.wikipedia.org/wiki/Sudo)
@Shadur Hai assolutamente ragione, dal punto di vista dell'amministratore di sistema. Sudo funziona se la rappresentazione necessaria (e potrebbe) avvenire a livello di console di sistema, ma non credo che questo sia lo spirito della domanda. Quando vedo _ "sito web" _ nella domanda originale e _ "staff di supporto" _ nella risposta al commento di Abe, mi viene da pensare che stia parlando di supporto per l'utente finale ** a ** livello dell'applicazione, per problemi ** su * * il livello dell'applicazione. In tal caso, la soluzione deve essere simile a sudo, ma estratta dalla console e fino all'app Web. Ecco perché ho fornito la risposta che ho fatto.
Quando poni domande di questo tipo, a volte è utile immaginare di parlare con un revisore interno e di cercare di spiegare perché hai inserito questa funzione. Tu: "Allora, abbiamo questa password" divina ". Auditor interno: "Password 'Dio' - un po 'come una porta sul retro, giusto?" Tu: "Ehm, beh, più o meno, ma ..." Auditor: "GUARDIE! FUORI CON 'È' EAD !!!!!" Mette tutto in prospettiva, non è vero?
Dieci risposte:
#1
+117
tylerl
2014-02-08 00:02:42 UTC
view on stackexchange narkive permalink

Questo suona molto come un account "amministratore", che normalmente ha accesso illimitato alle cose di cui è amministratore.

Le implicazioni per la sicurezza di un account amministratore sono abbastanza ben comprese, in quanto sono le migliori pratiche. Non entrerò nei 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 utilizzando la sua password, non c'è modo per un auditor a posteriori di determinare cosa è stato fatto da me rispetto a ciò che è stato fatto dall'amministratore.

Ma se invece l'amministratore accede al proprio account con la sua password super sicura, quindi tramite l'accesso che ha tramite il proprio account esegue alcune azioni che avrei potuto fare anch'io - beh, ora possiamo avere un registro che dice chi ha fatto cosa. Questa è la chiave quando il letame colpisce il ventilatore. E ancora di più quando uno degli account amministratore viene compromesso (cosa che lo farà , nonostante i tuoi migliori sforzi).

Inoltre, supponiamo che l'azienda cresca e che tu abbia bisogno di 2 amministratori. Condividono la password fantastica? NO NO NO. Entrambi ottengono i propri account amministratore, con tracciamento e registrazione separati e tutto il resto. Ora puoi dire QUALE amministratore ha fatto cosa. E, cosa più importante, puoi chiudere uno degli account quando licenzi uno degli amministratori per aver rubato le ciambelle.

In una nota correlata, sebbene sia spesso necessario disporre di un mezzo per consentire agli amministratori di modificare le password degli account, per politica non si dovrebbe fare in modo che gli amministratori impostino gli account su password utilizzabili direttamente, ma invece impostarli in modo che un utente debba impostare il proprio propria password prima di utilizzare l'account. In questo modo, qualsiasi cosa fatta con un account può essere attribuita alla persona più recente che ha impostato la password dell'account. Se Bob non è disposto ad accedere con una password non impostata da lui stesso, la sua password viene modificata lunedì e giovedì è noto che accede, questi fatti insieme implicherebbero ...
... che Bob ha impostato la sua password lunedì e tutte le azioni con l'account tra quel giorno e giovedì sono state eseguite da Bob.
e se per "scopi di supporto" OP significa non semplicemente essere in grado di fare tutto ciò che un utente può fare, ma essere in grado di vedere la schermata esatta che l'utente vede (ad esempio per aiutare a spiegare all'utente come fare qualcosa o aiutare a capire perché può fare qualcosa)?
@joshuahedlund Se l'amministratore desidera accedere all'account di un utente, cambia la password dell'utente. Può quindi dire all'utente qual è la sua nuova password.
@joshuahedlund Ecco a cosa servono gli strumenti di condivisione dello schermo come VNC, TeamViewer, Assistenza remota, WEbEx, ecc ... Non impersonerai mai l'utente. Visualizzi una copia del suo schermo come se fossi in piedi dietro di loro a guardare oltre le loro spalle.
@joshuahedlund Un sistema di backend che ho scritto di recente ha una caratteristica come questa. Un amministratore fa clic sul pulsante "accedi come questo utente" e il sistema si comporta esattamente come se l'amministratore fosse quell'utente. Tuttavia, tutto è tenuto dritto nei registri.
Vorrei aggiungere che consiglio vivamente di limitare l'accesso agli account amministratore a specifici indirizzi IP di origine, come l'intervallo IP della tua azienda e l'indirizzo IP di casa dell'amministratore. Inoltre, abilita l'autenticazione a due fattori per gli account amministratore e utilizza HTTPS con supporto TLS 1.2 sul lato server e client.
Questo account è stato chiuso per il seguente motivo: accesso non autorizzato alle ciambelle.
@Thomas: No, no. Non è l'accesso non autorizzato, è la negazione del servizio di ciambelle ad altri utenti che lo ha messo in scatola.
A seconda del tipo di applicazione, posso vedere un punto in cui un utente viene tracciato facendo qualcosa che non dovrebbe fare, ma se esiste una password "divina" che consente a un amministratore di impersonare quell'utente, allora quella persona ha un caso legittimo per negare l'affidabilità di quei registri.
@TecBrat che è _esattamente_ il motivo per cui hai bisogno che siano separati. Se qualcuno usa la tua applicazione per, ad esempio, distribuire materiale pedopornografico, hai molte più possibilità di essere in grado di dirlo se puoi dimostrare che solo quell'utente è stato coinvolto.
@AJMansfield. Sì. Questo è il punto che stavo facendo.
Questo è un punto interessante.Lavoravo IT presso un'azienda che diceva che non avevamo account di amministratore / backdoor, quindi se succede qualcosa di brutto su una macchina, il proprietario della macchina può prendersi tutta la colpa senza esitazione.Quindi questo non ha senso perché come dici tu, se ci fosse un account amministratore, le sue azioni verrebbero registrate come tali (e in teoria solo lo staff IT conoscerebbe la password).
#2
+51
Daniel Nalbach
2014-02-08 05:19:43 UTC
view on stackexchange narkive permalink

Ci sono molte ottime informazioni nelle risposte fornite finora che il poster originale dovrebbe leggere e prendere a cuore. Tuttavia, penso che la maggior parte delle risposte non colga lo spirito della domanda in quanto si riferisce all'esplorazione del sito Web della propria azienda "come se fosse l'utente" a scopo di supporto. Il nocciolo 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 la stessa esigenza nella sua applicazione web e l'ha già risolto in un modo che credo fosse 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 entrare in una serie di pagine che possono cercare qualsiasi utente nel sistema e selezionare quell'utente come credenziali per navigare nel sistema con. Tiene traccia dell'utente selezionato per mascherarsi e dell'utente dipendente effettivo 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 quest'altro utente". Una specie di versione webapp di sudo, ma integrata nel front-end.

Questo metodo:

  1. Elimina l'incubo dell'audit trail, 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 ci siano password condivise o "master".
  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 o conoscenza a livello di sistema.
  6. Il dipendente può anche "smascherare" in qualsiasi momento e controllare il contenuto della pagina rispetto al proprio account o ad altri account utente, il che è molto utile per determinare se i bug sono globali o specifici dell'utente.
Mi sembra che questa risposta sia la più vicina al problema OP. Un account amministrativo non è la soluzione in quanto ha una visibilità / comportamento diverso da quello dell'utente che viene risolto.
Sono d'accordo con questa risposta. Al mio lavoro abbiamo una funzionalità simile incorporata nei nostri siti che consente a un amministratore di "impersonare" qualsiasi altro utente. Consente all'amministratore di vedere e utilizzare il sito esattamente come l'utente impersonato pur consentendo la protezione e la registrazione appropriate.
Il software del forum phpBB ha questa funzionalità incorporata, per un buon esempio.
#3
+11
user10211
2014-02-07 23:13:10 UTC
view on stackexchange narkive permalink

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

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

Strumenti amministrativi adeguati non rappresenterebbero la stessa (o almeno una minaccia molto simile)?
@AbeMiessler No ... Perché se utilizzi account di amministratore individuali, la registrazione mostra cosa è successo e chi licenziare per aver inserito la password su un post-it.
#4
+7
Tom Leek
2014-02-08 00:09:21 UTC
view on stackexchange narkive permalink

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

  1. È una buona idea avere una sorta di accesso del 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 è il dunn'it". In questo senso, quando ci sono due o più individui dotati di privilegi di amministratore, è meglio che agiscano "come se stessi" come membri di un gruppo di amministratori (nel mondo Unix, usa sudo in modo che i comandi vengano registrati).

  2. È una buona idea fare in modo che gli amministratori esercitino i loro privilegi tramite la normale API utente ? Questo è discutibile. Consentire una "password di dio" significa installare l '"eccezione di dio" in tutta l'applicazione, che corre 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 nella complessità. Una "password divina" può essere utile durante lo sviluppo, ma, in generale, tende ad aumentare la probabilità di una falla di sicurezza devastante, quindi usala con estrema cautela.

Ovviamente il contesto è tutto e le risposte di cui sopra si limitano normalmente . Tuttavia, fai attenzione alle backdoor amministrative, in particolare le backdoor che non mantengono una buona registrazione dell'origine delle richieste amministrative.

Il tuo commento su "inevitabile" contro "buono" solleva un punto interessante. Se la progettazione di un sistema è tale che qualcuno con accesso fisico sarebbe in grado di fare qualsiasi cosa, inclusa la modifica non rilevabile della traccia di controllo, potrebbe essere ragionevole consentire a coloro che hanno accesso fisico di fare tali cose in modo conveniente. Il fatto che tali cose siano scomode ma non impossibili introdurrebbe inconvenienti ma non si otterrebbero i vantaggi di tracciabilità che ne deriverebbero dall'impossibilità. Una cosa che a volte ho pensato sarebbe stato un prodotto utile per qualcuno ...
... vendere sarebbe una "cassetta di registrazione" progettata in modo che i record di registro che sono stati impegnati non possano essere rimossi entro un certo periodo di tempo senza entrare fisicamente in esso. Se il dispositivo fosse limitato ad accettare dati a una velocità di 30 MB / minuto, ad esempio, un dispositivo con 64 GB di flash potrebbe garantire che ci vorrebbe più di un giorno di inondazione della velocità massima costante per qualcuno per sovrascrivere una voce di registro. Se la scatola includesse crittografia a chiave pubblica nelle sue funzioni di lettura / stato, qualcuno potrebbe avere un accesso totalmente illimitato a una macchina con una tale scatola ...
... ma se il log-box registrasse chi ha acquisito tale accesso, quel record sarebbe quasi indelebile (se qualche altra macchina periodicamente interrogasse il log-box, e squittirebbe se non potesse accedervi per qualche ora, quello potrebbe notificare personale di sicurezza che qualcosa non andava e che avevano una certa quantità di tempo per intervenire prima che le informazioni di controllo potessero essere distrutte).
#5
+4
The Spooniest
2014-02-08 03:06:57 UTC
view on stackexchange narkive permalink

Un amministratore può comunque agire solo come se stesso: qualcuno con una password divina può impersonare chiunque nel sistema. Si potrebbe sostenere che se l'amministratore ha abbastanza potere, questo non fa molto per limitare il danno effettivo che un utente malintenzionato con quell'account potrebbe fare. Ma un utente malintenzionato con la password divina avrebbe molto più tempo per coprire le sue tracce.

#6
+4
broc.seib
2014-02-09 01:28:11 UTC
view on stackexchange narkive permalink

Avere una password "dio" è una soluzione semplice, ma è semplicemente una "autorizzazione" per conoscere la password principale, e non si presta a una buona gestione degli accessi (ovvero controllare chi può farlo), né responsabilità (chi ha fatto veramente cosa).

Cambia invece la struttura dei dati delle tue credenziali per avere un campo utente effettivo:

  {user: alice, actual_user: bob,}  

Il contenuto delle tue pagine web dovrebbe essere visualizzato per l ' utente_effettivo , a meno che non si tratti di una pagina amministrativa interna che deve sapere chi è realmente navigazione. Tieni presente che la maggior parte delle persone esterne che navigano nel tuo sito avrà sempre lo stesso ID per entrambi i campi:

  {user: alice, actual_user: alice,}  

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

Questa soluzione ti consente anche di scegliere quali pagine il tuo staff può "guardare alle spalle" di un altro utente. Puoi scegliere di scrivere una pagina che non viene visualizzata in base all ' utente_effettivo , quindi nessuna di quella pagina può essere vista dal tuo staff anche se ha il privilegio di modificare il proprio ID utente effettivo.

A proposito, ho implementato il concetto di utente efficace sul web e ho anche implementato la password del dio. Quest'ultimo è facile da inserire quando tutte le infrastrutture sono già presenti. Ma in realtà non è la soluzione migliore in termini di sapere chi ha fatto cosa e gestire l'accesso. Dai un'occhiata da vicino a quanto sia realmente coinvolto il refactoring per aggiungere il campo utente effettivo: potrebbe essere inferiore a quanto pensi.

#7
+3
Tonny
2014-02-08 05:18:44 UTC
view on stackexchange narkive permalink

Non impersonare mai l'utente. (Per vari motivi di tracciabilità / responsabilità, come altri già menzionati).
Al contrario, visualizzi una copia dello schermo dello schermo degli utenti come se fossi in piedi dietro di loro a guardare sopra le loro spalle.
Questo è lo schermo / strumenti di condivisione desktop come VNC, TeamViewer, Assistenza remota, ecc ... sono per.

Non credo che tu abbia riflettuto sugli aspetti pratici di questa affermazione. Ad esempio quando sono su Facebook e voglio vedere il risultato dei miei permessi invece di usare 'visualizza come ...' dovrei andare a chiedere a uno dei miei amici di installare vnc e visitare la mia pagina? Sebbene una condivisione dello schermo possa essere appropriata per la risoluzione dei problemi, ci sono molti casi in cui vedere il comportamento del sito Web come un determinato utente non dovrebbe mai coinvolgere l'utente stesso, ad es. test / convalida delle impostazioni o correzione di un bug.
#8
+1
AJ Henderson
2014-02-08 01:04:10 UTC
view on stackexchange narkive permalink

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

Con qualsiasi root Il tipo di funzionalità / superuser / admin, la registrazione e il controllo del comportamento sono fondamentali e ciò significa che devi sapere chi stava facendo cosa. Se più utenti devono essere in grado di apportare modifiche in questo modo, dovrebbe essere presente un contrassegno sul loro account per consentirlo.

Potresti comunque voler avere una password aggiuntiva e più complicata che deve essere inseriti anche quando hanno accesso, ma dovresti richiedere l'autenticazione sicura di una persona che sta apportando modifiche prima di fare qualsiasi cosa di questa natura.

#9
  0
Timothy Swan
2014-02-09 05:48:12 UTC
view on stackexchange narkive permalink

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

#10
  0
James
2014-02-16 20:12:44 UTC
view on stackexchange narkive permalink

Penso che tu abbia bisogno di avere una sicurezza basata sui ruoli piuttosto che un account con 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ò andare a fare la correzione.

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



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...